Hi Bert,
You're right of course. We haven't before wrestled with OID
assignment by the PWG for MIBs. In fact only the IEEE-ISTO PWG
Secretary (currently Jerry Thrasher of Lexmark) has the authority
to assign/approve the base MIB arc when the Candidate Standard
is published.
In the future, we'll adopt the 'nnnn -- to be assigned by PWG'
approach. Of course, when we have a prototyping interop test,
we'll have to choose _something_ for an experimental number
(for documents still in working drafts stage).
What do the IETF chartered working groups do during development?
Do they very use 'experimental' for this?
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@sharplabs.com
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: Sunday, July 31, 2005 2:45 AM
> To: McDonald, Ira; 'thrasher@lexmark.com'; Bergman, Ron
> Cc: pmp@pwg.org
> Subject: RE: PMP> [delete ppmPrinterEnabled] Restructured Port MIB (18
> Jul y 2005)
>
>
> Ira, I cannot stop you. I just want to help you realize
> what it means. W.r.t.
>
> > Bert said that IETF WGs sometimes moved around OIDs in
> Internet-Drafts
> > (working documents).
>
> In principle only when the module itself does not have an OID assigned
> yet. And so there is no real OID registered. They all are not
> fixed untill the MIB module itself gets an OID assigned.
>
> > 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.
> >
> not smart in my view. But who is me?
>
> > Bert - none of these working documents has EVER been approved or
> > promised ANY stability of OIDs.
> >
> Maybe not approved. But you had documents that DID have complete OIDs
> defined, and so one never knows who has used them. Changing them
> in my view is against the base proinciples of the OID assignment
> process/concenpts.
>
> But I won't loose sleep of that is what PWG/PMP wants to do.
> It is their name that is on the block, not mine.
>
> Bert
> > -----Original Message-----
> > From: pmp-owner@pwg.org [mailto:pmp-owner@pwg.org]On Behalf
> > Of McDonald,
> > Ira
> > Sent: Friday, July 29, 2005 02:44
> > To: 'thrasher@lexmark.com'; Bergman, Ron
> > Cc: pmp@pwg.org
> > Subject: RE: PMP> [delete ppmPrinterEnabled] Restructured
> Port MIB (18
> > Jul y 2005)
> >
> >
> > 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@sharplabs.com
> >
> > > -----Original Message-----
> > > From: pmp-owner@pwg.org [mailto:pmp-owner@pwg.org]On Behalf Of
> > > thrasher@lexmark.com
> > > Sent: Thursday, July 28, 2005 8:17 PM
> > > To: Bergman, Ron
> > > Cc: pmp@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@rpsa To:
> > > "Mike Fenelon" <mfenelon@windows.microsoft.com>, "Wijnen,
> > > Bert
> > > .ricoh.com> \(Bert\)"
> > > <bwijnen@lucent.com>, "McDonald, Ira"
> > <imcdonald@sharplabs.com>,
> > >
> > > <thrasher@lexmark.com>
> > >
> > > 07/28/2005 08:02 cc:
> > > <pmp@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@pwg.org [mailto:pmp-owner@pwg.org]On Behalf
> > > Of Mike Fenelon
> > > Sent: Thursday, July 28, 2005 4:55 PM
> > > To: Wijnen, Bert (Bert); McDonald, Ira; thrasher@lexmark.com
> > > Cc: pmp@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@lucent.com]
> > > Sent: Thursday, July 28, 2005 11:20 AM
> > > To: Mike Fenelon; McDonald, Ira; thrasher@lexmark.com
> > > Cc: pmp@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@windows.microsoft.com]
> > > Sent: Thursday, July 28, 2005 17:44
> > > To: Wijnen, Bert (Bert); McDonald, Ira; thrasher@lexmark.com
> > > Cc: pmp@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@pwg.org [mailto:pmp-owner@pwg.org] On Behalf
> > > Of Wijnen,
> > > Bert (Bert)
> > > Sent: Thursday, July 28, 2005 8:28 AM
> > > To: McDonald, Ira; 'thrasher@lexmark.com'
> > > Cc: 'pmp@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@pwg.org [mailto:pmp-owner@pwg.org]On Behalf
> > > Of McDonald,
> > > Ira
> > > Sent: Thursday, July 28, 2005 16:59
> > > To: 'thrasher@lexmark.com'; McDonald, Ira
> > > Cc: 'pmp@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@sharplabs.com
> > > -----Original Message-----
> > > From: thrasher@lexmark.com [mailto:thrasher@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@sharplabs.com>
> > > 07/23/2005 01:56 PM
> > >
> > > To: "McDonald, Ira" <imcdonald@sharplabs.com>,
> > > "'thrasher@lexmark.com'" <thrasher@lexmark.com>
> > > cc: "'pmp@pwg.org'" <pmp@pwg.org>,
> > > "'Ron.Bergman@rpsa.ricoh.com'"
> <Ron.Bergman@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@sharplabs.com
> > > -----Original Message-----
> > > From: McDonald, Ira
> > > Sent: Friday, July 22, 2005 1:37 PM
> > > To: 'thrasher@lexmark.com'; McDonald, Ira
> > > Cc: pmp@pwg.org; Ron.Bergman@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@sharplabs.com
> > > -----Original Message-----
> > > From: thrasher@lexmark.com [mailto:thrasher@lexmark.com]
> > > Sent: Friday, July 22, 2005 1:28 PM
> > > To: McDonald, Ira
> > > Cc: pmp@pwg.org; Ron.Bergman@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@sharplabs.com>
> > > Sent by: pmp-owner@pwg.org
> > > 07/22/2005 12:13 PM
> > >
> > > To: "'Bergman, Ron'" <Ron.Bergman@rpsa.ricoh.com>,
> "McDonald,
> > > Ira" <imcdonald@sharplabs.com>, "Wijnen, Bert (Bert)"
> > > <bwijnen@lucent.com>,
> > > pmp@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@sharplabs.com
> > >
> > > > -----Original Message-----
> > > > From: Bergman, Ron [mailto:Ron.Bergman@rpsa.ricoh.com]
> > > > Sent: Thursday, July 21, 2005 8:24 PM
> > > > To: McDonald, Ira; Wijnen, Bert (Bert); pmp@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@sharplabs.com]
> > > > Sent: Wednesday, July 20, 2005 8:38 AM
> > > > To: Bergman, Ron; McDonald, Ira; Wijnen, Bert (Bert);
> pmp@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@sharplabs.com
> > > >
> > > > > -----Original Message-----
> > > > > From: Bergman, Ron [mailto:Ron.Bergman@rpsa.ricoh.com]
> > > > > Sent: Tuesday, July 19, 2005 7:40 PM
> > > > > To: McDonald, Ira; Wijnen, Bert (Bert); pmp@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@pwg.org [mailto:pmp-owner@pwg.org]On Behalf
> > > > > Of McDonald,
> > > > > Ira
> > > > > Sent: Tuesday, July 19, 2005 9:46 AM
> > > > > To: 'Wijnen, Bert (Bert)'; McDonald, Ira; 'pmp@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@sharplabs.com
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> > > > > > Sent: Tuesday, July 19, 2005 9:08 AM
> > > > > > To: McDonald, Ira; 'pmp@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)
> > >
> > >
> > >
> >
>
This archive was generated by hypermail 2b29 : Sun Jul 31 2005 - 13:41:06 EDT