attachment-0001

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40"> <head> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"> <meta name=ProgId content=Word.Document> <meta name=Generator content="Microsoft Word 11"> <meta name=Originator content="Microsoft Word 11"> <link rel=File-List href="cid:filelist.xml@01C59350.7D47C750"> <link rel=Edit-Time-Data href="cid:editdata.mso">  <style>  </style>  </head> <body lang=EN-US link=blue vlink=purple style='tab-interval:.5in'> <div class=Section1> 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.<o:p></o:p> <o:p> </o:p> <div> Mike Fenelon Microsoft<o:p></o:p> </div> <o:p> </o:p> <div> <div class=MsoNormal align=center style='text-align:center'> <hr size=2 width="100%" align=center tabindex=-1> </div> 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)<o:p></o:p> </div> <o:p> </o:p> <div> I have not followed detailed discussion on this... but<o:p></o:p> </div> <div>  <o:p></o:p> </div> <div> - SMI rules state that one a document with a MIB is published, you can NEVER<o:p></o:p> </div> <div>   re-use an OID for some other purpose. All you can do is obsolete the<o:p></o:p> </div> <div>   old object and add a new one.<o:p></o:p> </div> <div> - In IETF, when we just have internet drafts, we allow people to re-use an OID<o:p></o:p> </div> <div>   (supposedly no-one has used the OID while at internet draft state, besides.<o:p></o:p> </div> <div>   such MIB modules normally have a <o:p></o:p> </div> <div>  <o:p></o:p> </div> <div>      ::= { mib-2 xxxx } -- xxxx to be assigned by IANA<o:p></o:p> </div> <div>  <o:p></o:p> </div> <div>   so there is no definite complete OID, and people who want to do early implementations<o:p></o:p> </div> <div>   fill in a number under their enterprise prerelease branch or so.<o:p></o:p> </div> <div>  <o:p></o:p> </div> <div>   the final xxxx gets assigned by IANA upon document approval (right before RFC<o:p></o:p> </div> <div>   publication) and so no OID changes are allowed anymore.<o:p></o:p> </div> <div>   See the SMI documents for the rationale.<o:p></o:p> </div> <div>  <o:p></o:p> </div> <div> - But once published as RFC, we never re-use an OID, not even when a new rev is<o:p></o:p> </div> <div>   being published as a intrenet-draft.<o:p></o:p> </div> <div>  <o:p></o:p> </div> <div> Hope this helps,<o:p></o:p> </div> <div>  <o:p></o:p> </div> <div> Bert<o:p></o:p> </div> <blockquote style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt; margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'> -----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)<o:p></o:p> <div> Hi Jerry,<o:p></o:p> </div> <div>  <o:p></o:p> </div> <div> There's no such thing as a reserved no-access object, but I'd be happy to leave<o:p></o:p> </div> <div> the hole (so that the OIDs don't change for any other columnar objects).  Would<o:p></o:p> </div> <div> you prefer that?<o:p></o:p> </div> <div>  <o:p></o:p> </div> <div> Note that ALL of the columnar objects were cleaned up and reordered (and<o:p></o:p> </div> <div> renumbered) in this latest revision, so it would be hard for there to be too many<o:p></o:p> </div> <div> implementations of the new OIDs already.<o:p></o:p> </div> <div>  <o:p></o:p> </div> <div> Others - shall I leave the hole and leave the other new OID assignments stable?<o:p></o:p> </div> <div>  <o:p></o:p> </div> <div> Cheers,<o:p></o:p> </div> <div> - Ira<o:p></o:p> </div> <div>  <o:p></o:p> </div> 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 <o:p></o:p> <blockquote style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt; margin-left:3.75pt;margin-top:5.0pt;margin-bottom:5.0pt'> -----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)<o:p></o:p> 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 <![if !supportLineBreakNewLine]> <![endif]><o:p></o:p> <table class=MsoNormalTable border=0 cellpadding=0 width="100%" style='width:100.0%;mso-cellspacing:1.5pt'> <tr style='mso-yfti-irow:0;mso-yfti-firstrow:yes;mso-yfti-lastrow:yes'> <td valign=top style='padding:.75pt .75pt .75pt .75pt'> <o:p> </o:p> </td> <td valign=top style='padding:.75pt .75pt .75pt .75pt'> "McDonald, Ira" <imcdonald@sharplabs.com> <o:p></o:p> 07/23/2005 01:56 PM <o:p></o:p> </td> <td valign=top style='padding:.75pt .75pt .75pt .75pt'>                 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)<o:p></o:p> </td> </tr> </table> <tt>Hi,</tt> <tt>Let's delete ppmPrinterEnabled, because the 'false' is redundant</tt> <tt>with ppmPortEnabled of 'false' for all supported ports.  And</tt> <tt>because otherwise, we must say "ignore ppmPortEnabled of 'true'</tt> <tt>for installation if ppmPrinterEnabled is 'false'".  Which leads</tt> <tt>me to agree that we should delete ppmPrinterEnabled.</tt> <tt>When a Printer is permanently removed from an ENA interface,</tt> <tt>the whole ppmPrinterTable row and all subordinate rows in</tt> <tt>ppmPortTable can just be deleted.</tt> <tt>For 'ppmPortProtocolType' using 'PrtChannelTypeTC', we're working</tt> <tt>to get 'unknown(2)' registered quickly with IANA, so that we can</tt> <tt>do the 'right thing' that Bert Wijnen pointed out.</tt> <tt>Cheers,</tt> <tt>- Ira</tt> <tt>Ira McDonald (Musician / Software Architect)</tt> <tt>Blue Roof Music / High North Inc</tt> <tt>PO Box 221  Grand Marais, MI  49839</tt> <tt>phone: +1-906-494-2434</tt> <tt>email: imcdonald@sharplabs.com</tt> <tt>-----Original Message-----</tt> <tt>From: McDonald, Ira</tt> <tt>Sent: Friday, July 22, 2005 1:37 PM</tt> <tt>To: 'thrasher@lexmark.com'; McDonald, Ira</tt> <tt>Cc: pmp@pwg.org; Ron.Bergman@rpsa.ricoh.com</tt> <tt>Subject: RE: PMP> Restructured Port MIB (18 July 2005)</tt> <tt>Hi Jerry,</tt> <tt>I agree that feedback from the clients (Microsoft and Apple) on how they'd</tt> <tt>like this to work would be helpful.</tt> <tt>Remember, that a value of 'ppmPrinterIndex' must NEVER be reassigned</tt> <tt>to a different instance of a Printer at a later date.  While the MIB may</tt> <tt>grow and shrink, the base 'ppmPrinterIndex' should be immutably</tt> <tt>associated with exactly one specific instance of a Printer.  This is both</tt> <tt>correct MIB practice and required by the object definition in the current</tt> <tt>MIB draft.</tt> <tt>Cheers,</tt> <tt>- Ira</tt> <tt>Ira McDonald (Musician / Software Architect)</tt> <tt>Blue Roof Music / High North Inc</tt> <tt>PO Box 221  Grand Marais, MI  49839</tt> <tt>phone: +1-906-494-2434</tt> <tt>email: imcdonald@sharplabs.com</tt> <tt>-----Original Message-----</tt> <tt>From: thrasher@lexmark.com [mailto:thrasher@lexmark.com]</tt> <tt>Sent: Friday, July 22, 2005 1:28 PM</tt> <tt>To: McDonald, Ira</tt> <tt>Cc: pmp@pwg.org; Ron.Bergman@rpsa.ricoh.com</tt> <tt>Subject: RE: PMP> Restructured Port MIB (18 July 2005)</tt> <tt>I would think that the usefullness of the ppmPrinterEnabled for an</tt> <tt>ENA would only be for the "transcient" case of the plugging/unplugging</tt> <tt>of the related printer.  However at some point (in the case that the printer</tt> <tt>stays unplugged "permanently") the printer entry and associated protocol</tt> <tt>tables would be removed such that the the MIB could grow and shrink</tt> <tt>over time.....</tt> <tt>For example, an ENA with a USB host interface that supports up to</tt> <tt>128 attached printers, In my opinion, shouldn't need to have 128 printer</tt> <tt>entries</tt> <tt>in the MIB tables from first power on......only the entries that have</tt> <tt>detected (valid 1284ID)</tt> <tt>printers etc. attached.....otherwise you'd end up in most cases with 127</tt> <tt>default printer entries</tt> <tt>with associated port tables that don't actually go anywhere.</tt> <tt>Of course this behaviour is different from the current TCPMON.ini file</tt> <tt>which has static entries.......</tt> <tt>I think maybe the clients should give guidance on how they want it to work.</tt> <tt>Jerry Thrasher</tt> <tt>"McDonald, Ira" <imcdonald@sharplabs.com></tt> <tt>Sent by: pmp-owner@pwg.org</tt> <tt>07/22/2005 12:13 PM</tt> <tt>To:        "'Bergman, Ron'" <Ron.Bergman@rpsa.ricoh.com>, "McDonald,</tt> <tt>Ira" <imcdonald@sharplabs.com>, "Wijnen, Bert (Bert)" <bwijnen@lucent.com>,</tt> <tt>pmp@pwg.org</tt> <tt>cc:</tt> <tt>Subject:        RE: PMP> Restructured Port MIB (18 July 2005)</tt> <tt>Hi Ron,</tt> <tt>If the Printer entry is deleted when an ENA interface</tt> <tt>is disconnected, then all the subordinate Port entries</tt> <tt>MUST be deleted too (because they are indexed by the</tt> <tt>object ppmPrinterIndex).  This is ugly if the local</tt> <tt>printer is promptly plugged _back_ into the interface.</tt> <tt>If the Printer entry is left in place but _not_ clearly</tt> <tt>marked 'disabled', then ppmPrinterIEEE1284DeviceId,</tt> <tt>ppmPrinterHrDeviceIndex and all the other Printer</tt> <tt>columnar objects must be reset (to default values).</tt> <tt>That's why the ppmPrinterEnabled object should be kept.</tt> <tt>The WG concensus was strong that ppmPortEnabled was</tt> <tt>required to keep the port list static (fixed number</tt> <tt>of ports for an interface).  Therefore, I added the</tt> <tt>ppmPrinterEnabled object.</tt> <tt>If others want ppmPrinterEnabled removed, would they</tt> <tt>please speak up soon?</tt> <tt>Cheers,</tt> <tt>- Ira</tt> <tt>PS - Remember that this MIB is supposed to work for</tt> <tt>Network Spoolers too, where the concept of 'the printer</tt> <tt>is removed' is fuzzy.  The 'printer' is just some</tt> <tt>configured downstream network printer that may well</tt> <tt>be administratively disabled _without_ removing the</tt> <tt>configuration at the Network Spooler.</tt> <tt>Ira McDonald (Musician / Software Architect)</tt> <tt>Blue Roof Music / High North Inc</tt> <tt>PO Box 221  Grand Marais, MI  49839</tt> <tt>phone: +1-906-494-2434</tt> <tt>email: imcdonald@sharplabs.com</tt> <tt>> -----Original Message-----</tt> <tt>> From: Bergman, Ron [mailto:Ron.Bergman@rpsa.ricoh.com]</tt> <tt>> Sent: Thursday, July 21, 2005 8:24 PM</tt> <tt>> To: McDonald, Ira; Wijnen, Bert (Bert); pmp@pwg.org</tt> <tt>> Subject: RE: PMP> Restructured Port MIB (18 July 2005)</tt> <tt>></tt> <tt>></tt> <tt>> Ira,</tt> <tt>></tt> <tt>> Base on my experience with ENAs, they do not provide a feature to</tt> <tt>> disable an output port unless the printer is removed.  Normally,</tt> <tt>> this is to replace a worn-out unit or upgrade a printer.</tt> <tt>> In this case the old printer is gone forever.  So how does your</tt> <tt>> "STATIC entries" handle this situation?</tt> <tt>></tt> <tt>>         Ron</tt> <tt>></tt> <tt>> -----Original Message-----</tt> <tt>> From: McDonald, Ira [mailto:imcdonald@sharplabs.com]</tt> <tt>> Sent: Wednesday, July 20, 2005 8:38 AM</tt> <tt>> To: Bergman, Ron; McDonald, Ira; Wijnen, Bert (Bert); pmp@pwg.org</tt> <tt>> Subject: RE: PMP> Restructured Port MIB (18 July 2005)</tt> <tt>></tt> <tt>></tt> <tt>> Hi Ron,</tt> <tt>></tt> <tt>> Based on previous IPP experience, it will take MONTHS to add one</tt> <tt>> new enum to the PrtChannelTypeTC with IANA - that would stop the</tt> <tt>> Port Mon MIB dead in its tracks until it was accepted by IANA.</tt> <tt>></tt> <tt>> About ppmPrinterEnabled - same rationale as ppmPortEnabled - keeps</tt> <tt>> the number of Printer entries STATIC in an implementation - lets</tt> <tt>> the user see that the one Printer (i.e., hardward output interface)</tt> <tt>> on an External Network Adapter should presently be ignored.</tt> <tt>></tt> <tt>> Remember that the Port Mon MIB MUST NOT depend on either Host</tt> <tt>> Resources or Printer MIB, by common concensus - it may only</tt> <tt>> AUGMENT them, if they are present.</tt> <tt>></tt> <tt>> Cheers,</tt> <tt>> - Ira</tt> <tt>></tt> <tt>> Ira McDonald (Musician / Software Architect)</tt> <tt>> Blue Roof Music / High North Inc</tt> <tt>> PO Box 221  Grand Marais, MI  49839</tt> <tt>> phone: +1-906-494-2434</tt> <tt>> email: imcdonald@sharplabs.com</tt> <tt>></tt> <tt>> > -----Original Message-----</tt> <tt>> > From: Bergman, Ron [mailto:Ron.Bergman@rpsa.ricoh.com]</tt> <tt>> > Sent: Tuesday, July 19, 2005 7:40 PM</tt> <tt>> > To: McDonald, Ira; Wijnen, Bert (Bert); pmp@pwg.org</tt> <tt>> > Subject: RE: PMP> Restructured Port MIB (18 July 2005)</tt> <tt>> ></tt> <tt>> ></tt> <tt>> > Ira,</tt> <tt>> ></tt> <tt>> > I am not sure what value ppmPrinterEnabled adds to the MIB.</tt> <tt>> > This appears to be analogous to</tt> <tt>> > On Line/Off Line.  If I want to create a driver for the</tt> <tt>> > printer I don't care what the current</tt> <tt>> > state is.  That information is only necessary when I am ready</tt> <tt>> > to print and then this MIB is</tt> <tt>> > not used.</tt> <tt>> ></tt> <tt>> > I believe that Bert has a valid point in using</tt> <tt>> > ppmPortProtocolType.  It is not a major effort</tt> <tt>> > to add unknown(2) to the IANA registrations.</tt> <tt>> ></tt> <tt>> > Otherwise, the changes are inline with our discussions</tt> <tt>> > following the test.</tt> <tt>> ></tt> <tt>> >         Ron</tt> <tt>> ></tt> <tt>> > -----Original Message-----</tt> <tt>> > From: pmp-owner@pwg.org [mailto:pmp-owner@pwg.org]On Behalf</tt> <tt>> > Of McDonald,</tt> <tt>> > Ira</tt> <tt>> > Sent: Tuesday, July 19, 2005 9:46 AM</tt> <tt>> > To: 'Wijnen, Bert (Bert)'; McDonald, Ira; 'pmp@pwg.org'</tt> <tt>> > Subject: RE: PMP> Restructured Port MIB (18 July 2005)</tt> <tt>> ></tt> <tt>> ></tt> <tt>> > Hi Bert,</tt> <tt>> ></tt> <tt>> > Thanks for your quick feedback.  My replies inline below.</tt> <tt>> ></tt> <tt>> > Cheers,</tt> <tt>> > - Ira</tt> <tt>> ></tt> <tt>> ></tt> <tt>> > Ira McDonald (Musician / Software Architect)</tt> <tt>> > Blue Roof Music / High North Inc</tt> <tt>> > PO Box 221  Grand Marais, MI  49839</tt> <tt>> > phone: +1-906-494-2434</tt> <tt>> > email: imcdonald@sharplabs.com</tt> <tt>> ></tt> <tt>> > > -----Original Message-----</tt> <tt>> > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]</tt> <tt>> > > Sent: Tuesday, July 19, 2005 9:08 AM</tt> <tt>> > > To: McDonald, Ira; 'pmp@pwg.org'</tt> <tt>> > > Subject: RE: PMP> Restructured Port MIB (18 July 2005)</tt> <tt>> > ></tt> <tt>> > ></tt> <tt>> > > Only did a very very quick scan.</tt> <tt>> > ></tt> <tt>> > > Comments.</tt> <tt>> > ></tt> <tt>> > > - ppmPortProtocolTargetPort OBJECT-TYPE</tt> <tt>> > >     SYNTAX      Integer32 (0..65535)</tt> <tt>> > >   I propose that you use InetPortNumber TC from RFC4001</tt> <tt>> > ></tt> <tt>> ></tt> <tt>> > Won't work, because this port is not limited to Internet Suite</tt> <tt>> > protocols.  The 'service:' URI in ppmPortServiceNameOrURI may</tt> <tt>> > also be for non-Internet suites (AppleTalk, NetWare, etc.).</tt> <tt>> ></tt> <tt>> > I'll correct the DESCRIPTION in the MIB and make clear that</tt> <tt>> > (as with the Printer MIB) ports/channels may be from multiple</tt> <tt>> > protocol suites.</tt> <tt>> ></tt> <tt>> ></tt> <tt>> > > - ppmPortProtocolType OBJECT-TYPE</tt> <tt>> > >     SYNTAX      Integer32 (0..2147483647)</tt> <tt>> > ></tt> <tt>> > >   WHy not use TC PrtChannelTypeTC as the SYNTAX?</tt> <tt>> > >   I do see that you want to use zero (meaning not supported).</tt> <tt>> > >   But maybe better is to use none(1) in that case, or maybe</tt> <tt>> > >   adding an enumeration to the TC of notSupported(xx) ??</tt> <tt>> > >   It is now an IANA-maintained TC, so it should not be that</tt> <tt>> > >   difficult to get a label added.</tt> <tt>> > ></tt> <tt>> ></tt> <tt>> > Won't work.  PrtChannelTypeTC currently only defines 'other(1)'</tt> <tt>> > and (foolishly) does NOT define 'unknown(2)' (unlike every other</tt> <tt>> > textual convention in the Printer MIB).  Because the Printer MIB</tt> <tt>> > v2 still doesn't define DEFVAL clauses for most objects, this</tt> <tt>> > oversight has not surfaced before.  We could register 'unknown(2)'</tt> <tt>> > with IANA, but _not_ fast enough (because this MIB's going into OS</tt> <tt>> > and printer vendor products right now).</tt> <tt>> ></tt> <tt>> ></tt> <tt>> > > - ppmPortPrtChannelIndex has a reference to RFC1213, while I</tt> <tt>> > >   think I would reather reference RFC2863 (the current IF-MIB)</tt> <tt>> > ></tt> <tt>> > > Bert</tt> <tt>> > ></tt> <tt>> ></tt> <tt>> > Agreed.  My mistake from the old Printer MIB (RFC 1759).</tt> <tt>> ></tt> <tt>> > I'll correct the references in the MIB.</tt> <tt>> > - Ira</tt> <tt>> ></tt> <tt>> </tt><o:p></o:p> </blockquote> </blockquote> </div> </body> </html>