Expressing SNMP SMI Datatypes in XML Schema Definition Language
RFC 5935

Note: This ballot was opened for revision 05 and is now closed.

Jari Arkko (was Discuss) Yes

Comment (2010-04-22)
I have cleared my Discuss in anticipation of the new text to
explain how TCs are handled.

( David Harrington ) (was Discuss) Yes

( Alexey Melnikov ) Yes

( Dan Romascanu ) Yes

( Ron Bonica ) No Objection

( Stewart Bryant ) No Objection

( Gonzalo Camarillo ) No Objection

Comment (2010-04-22)
Acronyms such as SNMP and SMI should be expanded in the Abstract

( Ralph Droms ) No Objection

( Lars Eggert ) No Objection

( Adrian Farrel ) No Objection

( Russ Housley ) No Objection

( Tim Polk ) (was No Record, Discuss) No Objection

Comment (2010-04-21)
Global nit

The phrasing is inconsistent when datatypes are named.  Here are a few examples:
    XSD datatype "hexBinary"
   "hexBinary" XSD datatype
    XSD "string" datatype
This is a nitpick, but a consistent phrasing is a little easier on the reader.

(1) I suspect this is clear to the expected audience, so this is a comment rather than a
discuss, but I found sections 5.2 through 5.5 a bit confusing since the simple types defined
in section 4 (e.g., OctetString and IpAddress) seem to be used interchangably with their XSD base types.  

Consider 5.5 as an example:

  5.5.  ObjectIdentifier

   This XSD datatype corresponds to the SMI "OBJECT IDENTIFIER"
   datatype.

   The XSD "string" datatype is also the natural choice to represent an
   ObjectIdentifier as XML output, for the same reasons as for the
   IpAddress choice. 

I did a lot of flipping back and forth between sections to sort this out.  It might be
clearer to say something like

  5.5.  ObjectIdentifier

   The XSD datatype "ObjectIdentifier" corresponds to the SMI "OBJECT IDENTIFIER"
   datatype.

   "Objectidentifier" has the XSD base type "string", which is the natural choice to
   represent an ObjectIdentifier as XML output, for the same reasons as for the
   IpAddress choice. 


(2) Security Considerations nit

s/are likely to be relevant/will be relevant/

( Peter Saint-Andre ) No Objection

Comment (2010-04-21)
I think the regex for IpAddress could be shortened to something like this (but I am not a regex expert!):

((0|[1-9]?[0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}(0|[1-9]?[0-9]|1[0-
9][0-9]|2[0-4][0-9]|25[0-5])

( Robert Sparks ) No Objection

( spt ) No Objection

Comment (2010-04-19)
I have two comments wrt to this ID:

1) In the security considerations it says:

  "Security considerations for any given SMI MIB module are
   likely to be relevant to any XSD/XML mapping of that MIB module"

Shouldn't the phrase "likely to be" be removed?  When is it not relevant?

2) Is there any reason we can't refer to a later version of the ASN.1?  I.e., instead of '87 point to '02?