PMP Mail Archive: RE: PMP> [delete ppmPrinterEnabled] Restru

PMP Mail Archive: RE: PMP> [delete ppmPrinterEnabled] Restru

RE: PMP> [delete ppmPrinterEnabled] Restructured Port MIB (18 Jul y 2005)

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Sun Jul 31 2005 - 13:42:01 EDT

  • Next message: Wijnen, Bert (Bert): "RE: PMP> [delete ppmPrinterEnabled] Restructured Port MIB (18 Jul y 2005)"

    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