Inline
> -----Original Message-----
> From: McDonald, Ira [mailto:imcdonald at sharplabs.com]
> Sent: Thursday, March 10, 2005 20:19
> To: 'Wijnen, Bert (Bert)'; McDonald, Ira; 'pmp at pwg.org'; 'pwg at pwg.org'
> Subject: RE: PMP> Posted Last Call draft of Port Mon MIB (10
> March 2005)
>>> Hi Bert,
>> I knew I'd forgotten to fix the four-digit years and that
> darn REVISION clause. The uses of DisplayString were all
> intentional for strings that can't reasonably be non-ASCII.
>Then it makes sense. Migth add a comment about that so that
a novice (not as much involved) reader understands
> Several years ago, the SNMPv3 WG wasted a lot of time finding
> out that using non-ASCII strings in community names mostly
> broke existing SNMP libraries - I could certainly change
> that one - the 'ppmPortSnmpCommunityName' object was from
> the original Microsoft request - these printers and external
> network adapters are all running SNMPv1 with no security,
> but they seem to use a different read community name for
> each printer port - we can't really throw out the Microsoft
> requirements, because they're the motivating force for the
> MIB.
>
Well, there maybe broken SNMP implementation that only accept ASCII for
community string. But I think you are now swinging the other way to
not accept compliant SNMP implementations that DO accept non-ascii
charatcers in community string.
In any event, I find continued use of community string very scary.
Too much opportunity for people to break in.
> I agree with your suggestion about SnmpAdminString. I was
> following the usage in the just-published Printer MIB v2
> (RFC 3805) where we were told to use a dedicated TC whose
> semantics were that a specific SNMP object contained the
> language tag (same as here). Should we change these fields
> to SnmpAdminString?
>I just posted what I noticed. I cannot mandate use of SnmpAdminString.
As long as you do things consciously and as long as they are not
broken, then it is you (and your group) who decides.
> We'll probably accept your comments as Last Call comments,
> because we're on a short fuse to start our PWG Last Call.
>OK
Bert
> Cheers,
> - Ira
>> Ira McDonald (Musician / Software Architect)
> Blue Roof Music / High North Inc
> PO Box 221 Grand Marais, MI 49839
> phone: +1-906-494-2434
> email: imcdonald at sharplabs.com>> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen at lucent.com]
> Sent: Thursday, March 10, 2005 11:47 AM
> To: 'McDonald, Ira'; 'pmp at pwg.org'; 'pwg at pwg.org'
> Subject: RE: PMP> Posted Last Call draft of Port Mon MIB (10
> March 2005)
>>> Not sure which level of SMICng you tried, but I get:
>> C:\bwijnen\smicng\work>smicmfm wd-pmpportmib10-20050310_mib.mi2
> E: f(wd-pmpportmib10-20050310_mib.mi2), (12,18)
> Date/time(0503100000Z)
> must have
> a year greater than 89
> ** 1 error and 0 warnings in parsing
>> Years (in LAST-UPDATE and REVISION clauses are 4 digits (yyyy)
>> I also get:
>> C:\bwijnen\smicng\work>smicng wd-pmpportmib10-20050310_mib.inc
> W: f(wd-pmpportmib10-20050310_mib.mi2), (43,21) The first
> revision should
> match
> the last update for MODULE-IDENTITY ppmMIB
>> *** 0 errors and 1 warning in parsing
>> And... in general, a REVISION clause is normally only present for each
> revision
> that was actually formally published. Not sure how it works in PMP
> organisation.
> In IETF, revisions in various Internte-Drafts will not have a separate
> REVISION
> clause, only revisions that are published as RFCs.
>> I did a very quick browse.
>> I wonder why you do not use SnmpAdminString (RFC3411) instead
> of defining
> your
> own TC.
>> I see: ppmPortProtocolPortNumber and wonder if you not better use
> the InetPortNumber TC from RFC4001
>> This:
>> ppmPortSnmpCommunityName OBJECT-TYPE
> SYNTAX DisplayString (SIZE (0..255))
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "The SNMP read community name, specified in US-ASCII,
> for access
> to the printer status information in IETF MIB-II (RFC 1213),
> IETF Host Resources MIB (RFC 1514/2790), and IETF Printer MIB
> (RFC 1759/3805) for this port.
>> If this object is empty, then the SNMP read community name for
> this port MUST default to 'public'."
> REFERENCE
> "See: 'snmpCommunityName' in SNMP Community MIB (RFC 3584)."
> DEFVAL { ''H } -- no SNMP read community name
> ::= { ppmPortEntry 7 }
>> seems pretty INSECURE, plus, a valid SNMP communityName is allowewd to
> contain non-ASCII characters. So I find this very questional stuff
>> I am also worried somewhat by the use of all the DisplaySTring types
> (US NVT ASCII). Does not seem to be of current time anymore and
> certainly does not seem to be future proof to me
>> Just my initial 2 cents
>> Bert
> > -----Original Message-----
> > From: pmp-owner at pwg.org [mailto:pmp-owner at pwg.org]On Behalf
> > Of McDonald,
> > Ira
> > Sent: Thursday, March 10, 2005 16:56
> > To: 'pmp at pwg.org'; 'pwg at pwg.org'
> > Subject: PMP> Posted Last Call draft of Port Mon MIB (10 March 2005)
> >
> >
> > Hi folks, Thursday (10
> > March 2005)
> >
> > Mike Fenelon converted the PWG Printer Port Monitor MIB to
> MS Word and
> > added PWG boilerplate for v1.0 - status of 'Stable' - now posted at:
> >
> > ftp://ftp.pwg.org/pub/pwg/pmp/wd/wd-pmpportmib10-20050310.doc> > - MS Word document source
> >
> > ftp://ftp.pwg.org/pub/pwg/pmp/wd/wd-pmpportmib10-20050310.mib> > - ASN.1 MIB source - SMIv2 format
> >
> > ftp://ftp.pwg.org/pub/pwg/pmp/wd/wd-pmpportmib10-20050310.pdf> > - Acrobat PDF - PWG boilerplate, introduction, model, references
> >
> > This MIB compiles without warnings in both Epilogue Emissary
> > and SMICng.
> >
> > We will start a PWG Last Call on this document within the
> > next week, to
> > span the PWG face-to-face meeting in Tokyo in April and
> > finish during a
> > special PWG plenary telecon the following week.
> >
> > Cheers,
> > - Editors of PWG Printer Port Monitor MIB
> > o Mike Fenelon (Microsoft)
> > o Ivan Pavicevic (Microsoft)
> > o Ron Bergman (Ricoh)
> > o Ira McDonald (High North Inc)
> >
> > ----------------------------------------
> > [change log - to be deleted before Candidate Standard publication]
> >
> > 8 March 2005 (v1.0)
> > - Converted to official PWG working draft
> > - Expanded the background section
> >
>