Hi,
We're going to eliminate the hole! Nobody really wants to keep it.
Bert said that IETF WGs sometimes moved around OIDs in Internet-Drafts
(working documents). We've already moved around the OIDs at LEAST
three times in our working documents and we're going to do it once
more and quit, because we agree that we've got all the necessary
objects.
Bert - none of these working documents has EVER been approved or
promised ANY stability of OIDs.
Cheers,
- Ira
PS - As I promised Jerry Thrasher earlier today, new ASN.1 by
end-of-day tomorrow (Friday) or sooner if I can.
PPS - Jerry or Mike still needs to incorporate the rewritten
Requirements section into the right place in the boilerplate.
PPPS - And I need to write edits for Internationalization and
Security sections, because we moved some elements up (logically)
from the previous ppmPortTable to the new ppmPrinterTable.
Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
phone: +1-906-494-2434
email: imcdonald at sharplabs.com
> -----Original Message-----
> From: pmp-owner at pwg.org [mailto:pmp-owner at pwg.org]On Behalf Of
>thrasher at lexmark.com> Sent: Thursday, July 28, 2005 8:17 PM
> To: Bergman, Ron
> Cc: pmp at pwg.org> Subject: RE: PMP> [delete ppmPrinterEnabled] Restructured Port MIB (18
> Jul y 2005)
>>>> Ron,
>> I'm not aware of any company that's already implemented the
> restructured
> MIB that's going
> to lie down in the road and object to removing the object and
> moving the
> other objects up in
> the table.....:).....just grumble a bit.....
>> Jerry
>>>>> "Bergman, Ron"
>> <Ron.Bergman at rpsa To:
> "Mike Fenelon" <mfenelon at windows.microsoft.com>, "Wijnen,
> Bert
> .ricoh.com> \(Bert\)"
> <bwijnen at lucent.com>, "McDonald, Ira" <imcdonald at sharplabs.com>,
>> <thrasher at lexmark.com>
>> 07/28/2005 08:02 cc:
> <pmp at pwg.org>
>> PM Subject: RE:
> PMP> [delete ppmPrinterEnabled] Restructured Port MIB (18 Jul y
> 2005)
>>>>>>>> I vote to eliminate the hole. We know only 6 companies impemented the
> previous draft, so I doubt
> if more than 6 have implemented this update in the last
> several days. I
> also don't believe this draft
> has been formally accepted to even be published as a draft.
>> Has anyone implemented this version and is objecting to removing the
> deleted object?
>> Ron
> -----Original Message-----
> From: pmp-owner at pwg.org [mailto:pmp-owner at pwg.org]On Behalf
> Of Mike Fenelon
> Sent: Thursday, July 28, 2005 4:55 PM
> To: Wijnen, Bert (Bert); McDonald, Ira; thrasher at lexmark.com> Cc: pmp at pwg.org> Subject: RE: PMP> [delete ppmPrinterEnabled] Restructured
> Port MIB (18 Jul
> y 2005)
>>> So what does that mean to us?? It is ridiculous to have an
> obsolete OID in
> the MIB because we changed our mind during development.
>> Mike Fenelon
> Microsoft
>>> _____
>> From: Wijnen, Bert (Bert) [mailto:bwijnen at lucent.com]
> Sent: Thursday, July 28, 2005 11:20 AM
> To: Mike Fenelon; McDonald, Ira; thrasher at lexmark.com> Cc: pmp at pwg.org> Subject: RE: PMP> [delete ppmPrinterEnabled] Restructured
> Port MIB (18 Jul
> y 2005)
>> It does not matter how long the OID has been out.
> What matters is if it was formally assigned (by whoever controls
> assignments in
> enterprises pwg(2699) mibs(1)
> and it seems (from the doc/mic that was posted) that ppmMIB
> did get and OID
> assigned, namely
> enterprises pwg(2699) mibs(1) ppmMIB(2)
>> And so I claim it has been published and so in my view you would not
> re-order OIDs.
> There are sound technical reasons why that is the case, read
> RFC2579-2580
> for that.
>> If you had like an experimental tree somewhere under pwg,
> then you could do
> it
> there if you made VERY CLEAR statements that those are all
> for experimental
> and/or pre-release testing and so no-one should assume that
> OIDs in there
> are
> ever going to be permanent. You would still (in my view)
> re-root under some
> other
> branch at the top level of the ppmMIB module if you started reordering
> OIDs.
>> Just trying to explain and help.
>> Bert
>> -----Original Message-----
> From: Mike Fenelon [mailto:mfenelon at windows.microsoft.com]
> Sent: Thursday, July 28, 2005 17:44
> To: Wijnen, Bert (Bert); McDonald, Ira; thrasher at lexmark.com> Cc: pmp at pwg.org> Subject: RE: PMP> [delete ppmPrinterEnabled] Restructured
> Port MIB (18 Jul
> y 2005)
> The oid was only out for a few days. I think it would be much more
> confusing to have a hole for something we took out of a draft, than to
> simply move everything up after deleting the oid.
>> Mike Fenelon
> Microsoft
>>> _____
>> From: pmp-owner at pwg.org [mailto:pmp-owner at pwg.org] On Behalf
> Of Wijnen,
> Bert (Bert)
> Sent: Thursday, July 28, 2005 8:28 AM
> To: McDonald, Ira; 'thrasher at lexmark.com'
> Cc: 'pmp at pwg.org'
> Subject: RE: PMP> [delete ppmPrinterEnabled] Restructured
> Port MIB (18 Jul
> y 2005)
>> I have not followed detailed discussion on this... but
>> - SMI rules state that one a document with a MIB is published, you can
> NEVER
> re-use an OID for some other purpose. All you can do is obsolete the
> old object and add a new one.
> - In IETF, when we just have internet drafts, we allow people
> to re-use an
> OID
> (supposedly no-one has used the OID while at internet draft state,
> besides.
> such MIB modules normally have a
>> ::= { mib-2 xxxx } -- xxxx to be assigned by IANA
>> so there is no definite complete OID, and people who want
> to do early
> implementations
> fill in a number under their enterprise prerelease branch or so.
>> the final xxxx gets assigned by IANA upon document approval
> (right before
> RFC
> publication) and so no OID changes are allowed anymore.
> See the SMI documents for the rationale.
>> - But once published as RFC, we never re-use an OID, not even
> when a new
> rev is
> being published as a intrenet-draft.
>> Hope this helps,
>> Bert
> -----Original Message-----
> From: pmp-owner at pwg.org [mailto:pmp-owner at pwg.org]On Behalf
> Of McDonald,
> Ira
> Sent: Thursday, July 28, 2005 16:59
> To: 'thrasher at lexmark.com'; McDonald, Ira
> Cc: 'pmp at pwg.org'
> Subject: RE: PMP> [delete ppmPrinterEnabled] Restructured
> Port MIB (18 Jul
> y 2005)
> Hi Jerry,
>> There's no such thing as a reserved no-access object, but I'd
> be happy to
> leave
> the hole (so that the OIDs don't change for any other
> columnar objects).
> Would
> you prefer that?
>> Note that ALL of the columnar objects were cleaned up and
> reordered (and
> renumbered) in this latest revision, so it would be hard for
> there to be
> too many
> implementations of the new OIDs already.
>> Others - shall I leave the hole and leave the other new OID
> assignments
> stable?
>> Cheers,
> - Ira
>> Ira McDonald (Musician / Software Architect)
> Blue Roof Music / High North Inc
> PO Box 221 Grand Marais, MI 49839
> phone: +1-906-494-2434
> email: imcdonald at sharplabs.com> -----Original Message-----
> From: thrasher at lexmark.com [mailto:thrasher at lexmark.com]
> Sent: Thursday, July 28, 2005 10:33 AM
> To: McDonald, Ira
> Subject: RE: PMP> [delete ppmPrinterEnabled] Restructured
> Port MIB (18 Jul
> y 2005)
>> Ira,
>> Are you just planning on creating a reserved no-access object where
> ppmPortEnabled "used" to be, or are
> you going to delete the entry and shift everything else in
> the table up.??
>> Jerry
>>>>> "McDonald, Ira" <imcdonald at sharplabs.com>
> 07/23/2005 01:56 PM
>> To: "McDonald, Ira" <imcdonald at sharplabs.com>,
> "'thrasher at lexmark.com'" <thrasher at lexmark.com>
> cc: "'pmp at pwg.org'" <pmp at pwg.org>,
> "'Ron.Bergman at rpsa.ricoh.com'" <Ron.Bergman at rpsa.ricoh.com>
> Subject: RE: PMP> [delete ppmPrinterEnabled]
> Restructured
> Port MIB (18 Jul y 2005)
>>>> Hi,
>> Let's delete ppmPrinterEnabled, because the 'false' is redundant
> with ppmPortEnabled of 'false' for all supported ports. And
> because otherwise, we must say "ignore ppmPortEnabled of 'true'
> for installation if ppmPrinterEnabled is 'false'". Which leads
> me to agree that we should delete ppmPrinterEnabled.
>> When a Printer is permanently removed from an ENA interface,
> the whole ppmPrinterTable row and all subordinate rows in
> ppmPortTable can just be deleted.
>> For 'ppmPortProtocolType' using 'PrtChannelTypeTC', we're working
> to get 'unknown(2)' registered quickly with IANA, so that we can
> do the 'right thing' that Bert Wijnen pointed out.
>> Cheers,
> - Ira
>> Ira McDonald (Musician / Software Architect)
> Blue Roof Music / High North Inc
> PO Box 221 Grand Marais, MI 49839
> phone: +1-906-494-2434
> email: imcdonald at sharplabs.com> -----Original Message-----
> From: McDonald, Ira
> Sent: Friday, July 22, 2005 1:37 PM
> To: 'thrasher at lexmark.com'; McDonald, Ira
> Cc: pmp at pwg.org; Ron.Bergman at rpsa.ricoh.com> Subject: RE: PMP> Restructured Port MIB (18 July 2005)
>>> Hi Jerry,
>> I agree that feedback from the clients (Microsoft and Apple)
> on how they'd
> like this to work would be helpful.
>> Remember, that a value of 'ppmPrinterIndex' must NEVER be reassigned
> to a different instance of a Printer at a later date. While
> the MIB may
> grow and shrink, the base 'ppmPrinterIndex' should be immutably
> associated with exactly one specific instance of a Printer.
> This is both
> correct MIB practice and required by the object definition in
> the current
> MIB draft.
>> Cheers,
> - Ira
>> Ira McDonald (Musician / Software Architect)
> Blue Roof Music / High North Inc
> PO Box 221 Grand Marais, MI 49839
> phone: +1-906-494-2434
> email: imcdonald at sharplabs.com> -----Original Message-----
> From: thrasher at lexmark.com [mailto:thrasher at lexmark.com]
> Sent: Friday, July 22, 2005 1:28 PM
> To: McDonald, Ira
> Cc: pmp at pwg.org; Ron.Bergman at rpsa.ricoh.com> Subject: RE: PMP> Restructured Port MIB (18 July 2005)
>>>> I would think that the usefullness of the ppmPrinterEnabled for an
> ENA would only be for the "transcient" case of the plugging/unplugging
> of the related printer. However at some point (in the case that the
> printer
>> stays unplugged "permanently") the printer entry and
> associated protocol
> tables would be removed such that the the MIB could grow and shrink
> over time.....
>> For example, an ENA with a USB host interface that supports up to
> 128 attached printers, In my opinion, shouldn't need to have
> 128 printer
> entries
> in the MIB tables from first power on......only the entries that have
> detected (valid 1284ID)
> printers etc. attached.....otherwise you'd end up in most
> cases with 127
> default printer entries
> with associated port tables that don't actually go anywhere.
>> Of course this behaviour is different from the current TCPMON.ini file
> which has static entries.......
>> I think maybe the clients should give guidance on how they
> want it to work.
>> Jerry Thrasher
>>>>> "McDonald, Ira" <imcdonald at sharplabs.com>
> Sent by: pmp-owner at pwg.org> 07/22/2005 12:13 PM
>> To: "'Bergman, Ron'" <Ron.Bergman at rpsa.ricoh.com>, "McDonald,
> Ira" <imcdonald at sharplabs.com>, "Wijnen, Bert (Bert)"
> <bwijnen at lucent.com>,
>pmp at pwg.org> cc:
> Subject: RE: PMP> Restructured Port MIB (18 July 2005)
>>>> Hi Ron,
>> If the Printer entry is deleted when an ENA interface
> is disconnected, then all the subordinate Port entries
> MUST be deleted too (because they are indexed by the
> object ppmPrinterIndex). This is ugly if the local
> printer is promptly plugged _back_ into the interface.
>> If the Printer entry is left in place but _not_ clearly
> marked 'disabled', then ppmPrinterIEEE1284DeviceId,
> ppmPrinterHrDeviceIndex and all the other Printer
> columnar objects must be reset (to default values).
>> That's why the ppmPrinterEnabled object should be kept.
>> The WG concensus was strong that ppmPortEnabled was
> required to keep the port list static (fixed number
> of ports for an interface). Therefore, I added the
> ppmPrinterEnabled object.
>> If others want ppmPrinterEnabled removed, would they
> please speak up soon?
>> Cheers,
> - Ira
>> PS - Remember that this MIB is supposed to work for
> Network Spoolers too, where the concept of 'the printer
> is removed' is fuzzy. The 'printer' is just some
> configured downstream network printer that may well
> be administratively disabled _without_ removing the
> configuration at the Network Spooler.
>> Ira McDonald (Musician / Software Architect)
> Blue Roof Music / High North Inc
> PO Box 221 Grand Marais, MI 49839
> phone: +1-906-494-2434
> email: imcdonald at sharplabs.com>> > -----Original Message-----
> > From: Bergman, Ron [mailto:Ron.Bergman at rpsa.ricoh.com]
> > Sent: Thursday, July 21, 2005 8:24 PM
> > To: McDonald, Ira; Wijnen, Bert (Bert); pmp at pwg.org> > Subject: RE: PMP> Restructured Port MIB (18 July 2005)
> >
> >
> > Ira,
> >
> > Base on my experience with ENAs, they do not provide a feature to
> > disable an output port unless the printer is removed. Normally,
> > this is to replace a worn-out unit or upgrade a printer.
> > In this case the old printer is gone forever. So how does your
> > "STATIC entries" handle this situation?
> >
> > Ron
> >
> > -----Original Message-----
> > From: McDonald, Ira [mailto:imcdonald at sharplabs.com]
> > Sent: Wednesday, July 20, 2005 8:38 AM
> > To: Bergman, Ron; McDonald, Ira; Wijnen, Bert (Bert); pmp at pwg.org> > Subject: RE: PMP> Restructured Port MIB (18 July 2005)
> >
> >
> > Hi Ron,
> >
> > Based on previous IPP experience, it will take MONTHS to add one
> > new enum to the PrtChannelTypeTC with IANA - that would stop the
> > Port Mon MIB dead in its tracks until it was accepted by IANA.
> >
> > About ppmPrinterEnabled - same rationale as ppmPortEnabled - keeps
> > the number of Printer entries STATIC in an implementation - lets
> > the user see that the one Printer (i.e., hardward output interface)
> > on an External Network Adapter should presently be ignored.
> >
> > Remember that the Port Mon MIB MUST NOT depend on either Host
> > Resources or Printer MIB, by common concensus - it may only
> > AUGMENT them, if they are present.
> >
> > Cheers,
> > - Ira
> >
> > Ira McDonald (Musician / Software Architect)
> > Blue Roof Music / High North Inc
> > PO Box 221 Grand Marais, MI 49839
> > phone: +1-906-494-2434
> > email: imcdonald at sharplabs.com> >
> > > -----Original Message-----
> > > From: Bergman, Ron [mailto:Ron.Bergman at rpsa.ricoh.com]
> > > Sent: Tuesday, July 19, 2005 7:40 PM
> > > To: McDonald, Ira; Wijnen, Bert (Bert); pmp at pwg.org> > > Subject: RE: PMP> Restructured Port MIB (18 July 2005)
> > >
> > >
> > > Ira,
> > >
> > > I am not sure what value ppmPrinterEnabled adds to the MIB.
> > > This appears to be analogous to
> > > On Line/Off Line. If I want to create a driver for the
> > > printer I don't care what the current
> > > state is. That information is only necessary when I am ready
> > > to print and then this MIB is
> > > not used.
> > >
> > > I believe that Bert has a valid point in using
> > > ppmPortProtocolType. It is not a major effort
> > > to add unknown(2) to the IANA registrations.
> > >
> > > Otherwise, the changes are inline with our discussions
> > > following the test.
> > >
> > > Ron
> > >
> > > -----Original Message-----
> > > From: pmp-owner at pwg.org [mailto:pmp-owner at pwg.org]On Behalf
> > > Of McDonald,
> > > Ira
> > > Sent: Tuesday, July 19, 2005 9:46 AM
> > > To: 'Wijnen, Bert (Bert)'; McDonald, Ira; 'pmp at pwg.org'
> > > Subject: RE: PMP> Restructured Port MIB (18 July 2005)
> > >
> > >
> > > Hi Bert,
> > >
> > > Thanks for your quick feedback. My replies inline below.
> > >
> > > Cheers,
> > > - Ira
> > >
> > >
> > > Ira McDonald (Musician / Software Architect)
> > > Blue Roof Music / High North Inc
> > > PO Box 221 Grand Marais, MI 49839
> > > phone: +1-906-494-2434
> > > email: imcdonald at sharplabs.com> > >
> > > > -----Original Message-----
> > > > From: Wijnen, Bert (Bert) [mailto:bwijnen at lucent.com]
> > > > Sent: Tuesday, July 19, 2005 9:08 AM
> > > > To: McDonald, Ira; 'pmp at pwg.org'
> > > > Subject: RE: PMP> Restructured Port MIB (18 July 2005)
> > > >
> > > >
> > > > Only did a very very quick scan.
> > > >
> > > > Comments.
> > > >
> > > > - ppmPortProtocolTargetPort OBJECT-TYPE
> > > > SYNTAX Integer32 (0..65535)
> > > > I propose that you use InetPortNumber TC from RFC4001
> > > >
> > >
> > > Won't work, because this port is not limited to Internet Suite
> > > protocols. The 'service:' URI in ppmPortServiceNameOrURI may
> > > also be for non-Internet suites (AppleTalk, NetWare, etc.).
> > >
> > > I'll correct the DESCRIPTION in the MIB and make clear that
> > > (as with the Printer MIB) ports/channels may be from multiple
> > > protocol suites.
> > >
> > >
> > > > - ppmPortProtocolType OBJECT-TYPE
> > > > SYNTAX Integer32 (0..2147483647)
> > > >
> > > > WHy not use TC PrtChannelTypeTC as the SYNTAX?
> > > > I do see that you want to use zero (meaning not supported).
> > > > But maybe better is to use none(1) in that case, or maybe
> > > > adding an enumeration to the TC of notSupported(xx) ??
> > > > It is now an IANA-maintained TC, so it should not be that
> > > > difficult to get a label added.
> > > >
> > >
> > > Won't work. PrtChannelTypeTC currently only defines 'other(1)'
> > > and (foolishly) does NOT define 'unknown(2)' (unlike every other
> > > textual convention in the Printer MIB). Because the Printer MIB
> > > v2 still doesn't define DEFVAL clauses for most objects, this
> > > oversight has not surfaced before. We could register 'unknown(2)'
> > > with IANA, but _not_ fast enough (because this MIB's going into OS
> > > and printer vendor products right now).
> > >
> > >
> > > > - ppmPortPrtChannelIndex has a reference to RFC1213, while I
> > > > think I would reather reference RFC2863 (the current IF-MIB)
> > > >
> > > > Bert
> > > >
> > >
> > > Agreed. My mistake from the old Printer MIB (RFC 1759).
> > >
> > > I'll correct the references in the MIB.
> > > - Ira
> > >
> >
> (See attached file: C.htm)
>>>