attachment-0001

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns="http://www.w3.org/TR/REC-html40" xmlns:v = "urn:schemas-microsoft-com:vml" xmlns:o = "urn:schemas-microsoft-com:office:office" xmlns:w = "urn:schemas-microsoft-com:office:word"><HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"> <META content=Word.Document name=ProgId> <META content="MSHTML 6.00.2800.1505" name=GENERATOR> <META content="Microsoft Word 11" name=Originator><LINK href="cid:filelist.xml@01C59350.7D47C750" rel=File-List><LINK href="cid:editdata.mso" rel=Edit-Time-Data> <STYLE>@font-face { font-family: MS Mincho; } @font-face { font-family: Tahoma; } @font-face { font-family: sans-serif; } @font-face { font-family: @MS Mincho; } @page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; mso-header-margin: .5in; mso-footer-margin: .5in; mso-paper-source: 0; } P.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; mso-style-parent: ""; mso-pagination: widow-orphan; mso-fareast-font-family: "MS Mincho" } LI.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; mso-style-parent: ""; mso-pagination: widow-orphan; mso-fareast-font-family: "MS Mincho" } DIV.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; mso-style-parent: ""; mso-pagination: widow-orphan; mso-fareast-font-family: "MS Mincho" } H1 { FONT-WEIGHT: bold; FONT-SIZE: 16pt; MARGIN: 12pt 0in 3pt 0.3in; TEXT-INDENT: -0.3in; FONT-FAMILY: Arial; mso-pagination: widow-orphan; mso-style-next: Normal; mso-outline-level: 1; mso-list: l0 level1 lfo1; tab-stops: list -2.0in; mso-bidi-font-size: 10.0pt; mso-bidi-font-family: "Times New Roman"; mso-font-kerning: 14.0pt; mso-bidi-font-weight: normal } H2 { FONT-WEIGHT: bold; FONT-SIZE: 14pt; MARGIN: 12pt 0in 6pt 0.4in; TEXT-INDENT: -0.4in; FONT-FAMILY: Arial; mso-pagination: widow-orphan; mso-style-next: Normal; mso-outline-level: 2; mso-list: l0 level2 lfo1; tab-stops: list -2.0in; mso-bidi-font-size: 10.0pt; mso-bidi-font-family: "Times New Roman"; mso-bidi-font-weight: normal } H4 { FONT-WEIGHT: bold; FONT-SIZE: 11pt; MARGIN: 12pt 0in 3pt 0.6in; TEXT-INDENT: -0.6in; FONT-FAMILY: Arial; mso-pagination: widow-orphan; mso-style-next: Normal; mso-outline-level: 4; mso-list: l0 level4 lfo1; tab-stops: list 0in; mso-bidi-font-family: "Times New Roman"; mso-bidi-font-weight: normal } H5 { FONT-WEIGHT: normal; FONT-SIZE: 11pt; MARGIN: 12pt 0in 3pt 0.7in; TEXT-INDENT: -0.7in; FONT-FAMILY: Arial; mso-pagination: widow-orphan; mso-style-next: Normal; mso-outline-level: 5; mso-list: l0 level5 lfo1; tab-stops: list 0in; mso-bidi-font-size: 10.0pt; mso-bidi-font-family: "Times New Roman" } H6 { FONT-WEIGHT: normal; FONT-SIZE: 11pt; MARGIN: 12pt 0in 3pt 0.8in; TEXT-INDENT: -0.8in; FONT-FAMILY: Arial; mso-pagination: widow-orphan; mso-style-next: Normal; mso-outline-level: 6; mso-list: l0 level6 lfo1; tab-stops: list 0in; mso-bidi-font-size: 10.0pt; mso-bidi-font-family: "Times New Roman" } P.MsoHeading7 { FONT-SIZE: 10pt; MARGIN: 12pt 0in 3pt 0.9in; TEXT-INDENT: -0.9in; FONT-FAMILY: Arial; mso-pagination: widow-orphan; mso-fareast-font-family: "MS Mincho"; mso-style-next: Normal; mso-outline-level: 7; mso-list: l0 level7 lfo1; tab-stops: list -2.0in; mso-bidi-font-family: "Times New Roman" } LI.MsoHeading7 { FONT-SIZE: 10pt; MARGIN: 12pt 0in 3pt 0.9in; TEXT-INDENT: -0.9in; FONT-FAMILY: Arial; mso-pagination: widow-orphan; mso-fareast-font-family: "MS Mincho"; mso-style-next: Normal; mso-outline-level: 7; mso-list: l0 level7 lfo1; tab-stops: list -2.0in; mso-bidi-font-family: "Times New Roman" } DIV.MsoHeading7 { FONT-SIZE: 10pt; MARGIN: 12pt 0in 3pt 0.9in; TEXT-INDENT: -0.9in; FONT-FAMILY: Arial; mso-pagination: widow-orphan; mso-fareast-font-family: "MS Mincho"; mso-style-next: Normal; mso-outline-level: 7; mso-list: l0 level7 lfo1; tab-stops: list -2.0in; mso-bidi-font-family: "Times New Roman" } P.MsoHeading8 { FONT-SIZE: 10pt; MARGIN: 12pt 0in 3pt 1in; TEXT-INDENT: -1in; FONT-FAMILY: Arial; mso-pagination: widow-orphan; mso-fareast-font-family: "MS Mincho"; mso-style-next: Normal; mso-outline-level: 8; mso-list: l0 level8 lfo1; tab-stops: list -2.0in; mso-bidi-font-family: "Times New Roman" } LI.MsoHeading8 { FONT-SIZE: 10pt; MARGIN: 12pt 0in 3pt 1in; TEXT-INDENT: -1in; FONT-FAMILY: Arial; mso-pagination: widow-orphan; mso-fareast-font-family: "MS Mincho"; mso-style-next: Normal; mso-outline-level: 8; mso-list: l0 level8 lfo1; tab-stops: list -2.0in; mso-bidi-font-family: "Times New Roman" } DIV.MsoHeading8 { FONT-SIZE: 10pt; MARGIN: 12pt 0in 3pt 1in; TEXT-INDENT: -1in; FONT-FAMILY: Arial; mso-pagination: widow-orphan; mso-fareast-font-family: "MS Mincho"; mso-style-next: Normal; mso-outline-level: 8; mso-list: l0 level8 lfo1; tab-stops: list -2.0in; mso-bidi-font-family: "Times New Roman" } P.MsoHeading9 { FONT-SIZE: 9pt; MARGIN: 12pt 0in 3pt 1.1in; TEXT-INDENT: -1.1in; FONT-FAMILY: Arial; mso-pagination: widow-orphan; mso-fareast-font-family: "MS Mincho"; mso-style-next: Normal; mso-outline-level: 9; mso-list: l0 level9 lfo1; tab-stops: list -2.0in; mso-bidi-font-size: 10.0pt; mso-bidi-font-family: "Times New Roman" } LI.MsoHeading9 { FONT-SIZE: 9pt; MARGIN: 12pt 0in 3pt 1.1in; TEXT-INDENT: -1.1in; FONT-FAMILY: Arial; mso-pagination: widow-orphan; mso-fareast-font-family: "MS Mincho"; mso-style-next: Normal; mso-outline-level: 9; mso-list: l0 level9 lfo1; tab-stops: list -2.0in; mso-bidi-font-size: 10.0pt; mso-bidi-font-family: "Times New Roman" } DIV.MsoHeading9 { FONT-SIZE: 9pt; MARGIN: 12pt 0in 3pt 1.1in; TEXT-INDENT: -1.1in; FONT-FAMILY: Arial; mso-pagination: widow-orphan; mso-fareast-font-family: "MS Mincho"; mso-style-next: Normal; mso-outline-level: 9; mso-list: l0 level9 lfo1; tab-stops: list -2.0in; mso-bidi-font-size: 10.0pt; mso-bidi-font-family: "Times New Roman" } A:link { COLOR: blue; TEXT-DECORATION: underline; text-underline: single } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline; text-underline: single } A:visited { COLOR: purple; TEXT-DECORATION: underline; text-underline: single } SPAN.MsoHyperlinkFollowed { COLOR: purple; TEXT-DECORATION: underline; text-underline: single } P { FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: "Times New Roman"; mso-pagination: widow-orphan; mso-fareast-font-family: "MS Mincho"; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto } TT { FONT-FAMILY: "Courier New"; mso-fareast-font-family: "MS Mincho"; mso-bidi-font-family: "Courier New"; mso-ascii-font-family: "Courier New"; mso-hansi-font-family: "Courier New" } P.XMLExample { FONT-SIZE: 8pt; BACKGROUND: #eeeeee; MARGIN: 0in 0in 0pt 0.5in; FONT-FAMILY: "Courier New"; mso-pagination: widow-orphan; mso-fareast-font-family: "MS Mincho"; tab-stops: .25in .5in .75in 1.0in 1.25in 1.5in 1.75in 2.0in 2.25in 2.5in 2.75in 3.0in 3.5in 4.0in 4.5in 5.0in; mso-style-name: "XML Example"; mso-style-update: auto } LI.XMLExample { FONT-SIZE: 8pt; BACKGROUND: #eeeeee; MARGIN: 0in 0in 0pt 0.5in; FONT-FAMILY: "Courier New"; mso-pagination: widow-orphan; mso-fareast-font-family: "MS Mincho"; tab-stops: .25in .5in .75in 1.0in 1.25in 1.5in 1.75in 2.0in 2.25in 2.5in 2.75in 3.0in 3.5in 4.0in 4.5in 5.0in; mso-style-name: "XML Example"; mso-style-update: auto } DIV.XMLExample { FONT-SIZE: 8pt; BACKGROUND: #eeeeee; MARGIN: 0in 0in 0pt 0.5in; FONT-FAMILY: "Courier New"; mso-pagination: widow-orphan; mso-fareast-font-family: "MS Mincho"; tab-stops: .25in .5in .75in 1.0in 1.25in 1.5in 1.75in 2.0in 2.25in 2.5in 2.75in 3.0in 3.5in 4.0in 4.5in 5.0in; mso-style-name: "XML Example"; mso-style-update: auto } SPAN.EmailStyle20 { COLOR: navy; FONT-FAMILY: Arial; mso-bidi-font-size: 10.0pt; mso-bidi-font-family: Arial; mso-ascii-font-family: Arial; mso-hansi-font-family: Arial; mso-style-type: personal-reply; mso-style-noshow: yes; mso-ansi-font-size: 10.0pt } SPAN.SpellE { mso-style-name: ""; mso-spl-e: yes } DIV.Section1 { page: Section1 } OL { MARGIN-BOTTOM: 0in } UL { MARGIN-BOTTOM: 0in } </STYLE> </HEAD> <BODY lang=EN-US style="tab-interval: .5in" vLink=purple link=blue> <DIV>It does not matter how long the OID has been out.</DIV> <DIV>What matters is if it was formally assigned (by whoever controls assignments in</DIV> <DIV>    enterprises pwg(2699) mibs(1)</DIV> <DIV>and it seems (from the doc/mic that was posted) that ppmMIB did get and OID</DIV> <DIV>assigned, namely</DIV> <DIV>     enterprises pwg(2699) mibs(1) ppmMIB(2)</DIV> <DIV> </DIV> <DIV>And so I claim it has been published and so in my view you would not re-order OIDs.</DIV> <DIV>There are sound technical reasons why that is the case, read RFC2579-2580 for that.</DIV> <DIV> </DIV> <DIV>If you had like an experimental tree somewhere under pwg, then you could do it</DIV> <DIV>there if you made VERY CLEAR statements that those are all for experimental</DIV> <DIV>and/or pre-release testing and so no-one should assume that OIDs in there are</DIV> <DIV>ever going to be permanent. You would still (in my view) re-root under some other</DIV> <DIV>branch at the top level of the ppmMIB module if you started reordering OIDs.</DIV> <DIV> </DIV> <DIV>Just trying to explain and help.</DIV> <DIV> </DIV> <DIV> Bert</DIV> <DIV> </DIV> <BLOCKQUOTE dir=ltr style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px"> <DIV class=OutlookMessageHeader dir=ltr align=left>-----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) </DIV> <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 style="TEXT-ALIGN: center" align=center> <HR tabIndex=-1 align=center width="100%" SIZE=2> </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-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; MARGIN: 5pt 0in 5pt 3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: medium none"> -----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-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; MARGIN-TOP: 5pt; PADDING-LEFT: 4pt; MARGIN-BOTTOM: 5pt; PADDING-BOTTOM: 0in; MARGIN-LEFT: 3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: medium none"> -----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 style="WIDTH: 100%; mso-cellspacing: 1.5pt" cellPadding=0 width="100%" border=0> <TBODY> <TR style="mso-yfti-irow: 0; mso-yfti-firstrow: yes; mso-yfti-lastrow: yes"> <TD style="PADDING-RIGHT: 0.75pt; PADDING-LEFT: 0.75pt; PADDING-BOTTOM: 0.75pt; PADDING-TOP: 0.75pt" vAlign=top> <o:p> </o:p></TD> <TD style="PADDING-RIGHT: 0.75pt; PADDING-LEFT: 0.75pt; PADDING-BOTTOM: 0.75pt; PADDING-TOP: 0.75pt" vAlign=top> "McDonald, Ira" <imcdonald@sharplabs.com> <o:p></o:p> 07/23/2005 01:56 PM <o:p></o:p></TD> <TD style="PADDING-RIGHT: 0.75pt; PADDING-LEFT: 0.75pt; PADDING-BOTTOM: 0.75pt; PADDING-TOP: 0.75pt" vAlign=top>                 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></TBODY></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></BLOCKQUOTE></BODY></HTML>