Note: This ballot was opened for revision 05 and is now closed.
Summary: Needs 8 more YES or NO OBJECTION positions to pass.
I have cleared my Discuss in anticipation of the new text to
explain how TCs are handled.
Acronyms such as SNMP and SMI should be expanded in the Abstract
I think the regex for IpAddress could be shortened to something like this (but
I am not a regex expert!):
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?
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:
This XSD datatype corresponds to the SMI "OBJECT IDENTIFIER"
The XSD "string" datatype is also the natural choice to represent an
ObjectIdentifier as XML output, for the same reasons as for the
I did a lot of flipping back and forth between sections to sort this out. It
might be clearer to say something like
The XSD datatype "ObjectIdentifier" corresponds to the SMI "OBJECT
"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/