Subject: PMP> Posted Last Call draft of Port Mon MIB (10 March 2005)

From: "McDonald, Ira" <[email-masked]>
Date: Thu, 10 Mar 2005 07:56:05 -0800

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

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 10 Mar 2005 17:46:33 +0100

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: [email-masked] [mailto:[email-masked]]On Behalf 
> Of McDonald,
> Ira
> Sent: Thursday, March 10, 2005 16:56
> To: [email-masked]'; [email-masked]'
> Subject: PMP> Posted Last Call draft of Port Mon MIB (10 March 2005)
> 
> 
> Hi folks,                                       Thursday (10 
> March 2005)
>

---

From: "McDonald, Ira" <[email-masked]>
Date: Thu, 10 Mar 2005 11:18:46 -0800

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.

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.

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?

We'll probably accept your comments as Last Call comments,
because we're on a short fuse to start our PWG Last Call.

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: [email-masked]

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Thursday, March 10, 2005 11:47 AM
To: 'McDonald, Ira'; [email-masked]'; [email-masked]'
Subject: RE: PMP> Posted Last Call draft of Port Mon MIB (10 March 2005)

  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

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

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 wonder why you do not use SnmpAdminString (RFC3411) instead of defining
your
own TC. 

This:

Just my initial 2 cents

Bert

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 10 Mar 2005 20:53:01 +0100

Inline

> From: McDonald, Ira [mailto:[email-masked]]
> Sent: Thursday, March 10, 2005 20:19
> To: 'Wijnen, Bert (Bert)'; McDonald, Ira; [email-masked]'; [email-masked]'
Then it makes sense. Migth add a comment about that so that
a novice (not as much involved) reader understands

> requirements, because they're the motivating force for the

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.

> language tag (same as here).  Should we change these fields
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.

> because we're on a short fuse to start our PWG Last Call.
OK

Bert

---

From: "Mike Fenelon" <[email-masked]>
Date: Thu, 10 Mar 2005 14:28:41 -0800

Inline also..

Mike Fenelon
Microsoft

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Wijnen,
> Bert (Bert) 
> Sent: Thursday, March 10, 2005 11:53 AM

>Too much opportunity for people to break in.

[MFenelon] The key here is we are not trying to use Community String as
a mechanism of security.. We know that doesn't work. It added to this
MIB because some devices use different Community Strings to segregate
request to different parts of the device.

---

From: "McDonald, Ira" <[email-masked]>
Date: Sun, 13 Mar 2005 19:49:13 -0800

Hi Bert,

I think we need some technical advice here about the syntax of
SNMP community strings.  You said recently (in this thread):

"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 the Printer Port Monitor MIB, I made our community string object
have a syntax of 'DisplayString' (NVT-ASCII).  

Strangely, in the SNMP-COMMUNITY-MIB (RFC 3854), they use a syntax 
of 'OCTET STRING'.  Which seems the worst of all possible worlds.  
Since the charset is completely ambiguous, it's impossible to 
display to users.  Several years ago on the SNMPv3 list I argued 
(unsuccessfully) that the syntax should be 'SnmpAdminString', 
so that meaningful user display was possible.  I remain unpersuaded 
that mixing charsets across an enterprise network for community 
strings can possibly ever be beneficial.

Care to offer us some advice?

Cheers,
- Ira

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 14 Mar 2005 11:09:41 +0100

The CommunityString (in SNMPv1 and v2c) is intended as a (albeit)
weak secret, and not to be a human-consumable string.  Such
has been the case since the origins of SNMP, and it has ALWAYS been
an OCTET STRING. So any agent (and manager) is supposed to be
able to handle any octet value (also those that are NOT in the
NVT ASCII set). ANd by using a DisplayString in your MIB module,
you seem to be telling compliant implementations that they
would not be compliant with your MIB module.

Does this help?

In general, I do not think that using community strings is wise at
all in this world. But ymmv.

Bert

> Sent: Monday, March 14, 2005 04:49

---

From: "McDonald, Ira" <[email-masked]>
Date: Mon, 14 Mar 2005 12:24:44 -0800

Hi,

[Deleted [email-masked]' from this thread - only for announcements]

Well - since free packet sniffers (including SNMP header decoding)
are widely available on the Web, I keep telling people that using
community strings as ANY form of security is broken - I think Mike
Fenelon's point was that the external network adaptor (direct
connect printers to Ethernet) vendors just use separate community
strings for "poor man's MIB views" in SNMPv1.

To date, I personally know of only one printer vendor that ever
implemented SNMPv2 and one other more recently implemented SNMPv3.

Every default SNMPv1 agent I've ever seen used 'public' (in 
NVT-ASCII) as their default read community string.  

But since OCTET STRING has no charset the encoding of 'public' 
itself is utterly ambiguous (since the majority of the legacy 
charsets in existence do NOT have NVT-ASCII as a proper subset).

We'll fix this object to OCTET STRING and note that display is
inherently ambiguous (and security is non-existent).

Cheers,
- Ira

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Monday, March 14, 2005 5:10 AM
To: 'McDonald, Ira'; Wijnen, Bert (Bert); [email-masked]'; [email-masked]'
Subject: RE: PMP> Posted Last Call draft of Port Mon MIB (10 March 2005)

Does this help?

Bert