Subject: [OPSAWG] I-D ACTION:draft-ietf-opsawg-smi-datatypes-in-xsd-00.txt

From: [email-masked]
Date: Mon, 11 Feb 2008 14:45:01 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF.

	Title		: Expressing SNMP SMI Datatypes in XML Schema Definition Language
	Author(s)	: B. Natale, Y. Li
	Filename	: draft-ietf-opsawg-smi-datatypes-in-xsd-00.txt
	Pages		: 13
	Date		: 2008-2-11
	
This memo defines the IETF standard expression of Simple Network
   Management Protocol (SNMP) Structure of Management Information (SMI)
   datatypes in eXtensible Markup Language (XML) Schema Definition (XSD)
   language.  The primary objective of this memo is to enable production
   of XML documents that are as faithful to the SMI as possible, using
   XSD as the validation mechanism.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-opsawg-smi-datatypes-in-xsd-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-opsawg-smi-datatypes-in-xsd-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-opsawg-smi-datatypes-in-xsd-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
OPSAWG mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/opsawg

---

From: David Harrington <[email-masked]>
Date: Mon, 18 Feb 2008 14:09:39 -0800

Hi,

I reviewed this document and have some comments.

1) throughout the document, there is reference to this defining a
standard. I am of the impression internet-drafts are not supposed to
say this, except to say the document is intended for standards-track.
I could not find the text that says this in RFC2223 or 2223bis or the
id guidelines, though.

2) I am concerned that the claim is this document is THE standard XSD.
I believe it may be important to permit different XSD translations of
SMI for different purposes, so I think this should be "A" standard
XSD.

3) Throughout the document there is reference to "MIBs". Common usage
is to refer to MIBs, but this is incorrect usage. There is one
Management Information Base (MIB), composed of MIB modules. 

The distinction may become more important as we have multiple types of
modules that contain management information. It is unclear at this
time whether the IETF will consider, for example, Netconf data models
to be part of the Management Information Base. I don't want to open
this point up for discussion; I want to be sure the document doesn't
imply unwarranted assumptions that "the MIB" contains only SMIv1 and
SMIv2 MIB modules.

4) "SNMP MIBs" is inaccurate, both because "MIBs" is incorrect, but
the SNMP adjective is incorrect. MIB modules are written using the
SMI, which is a different set of standards (STD16,58) than SNMP
(STD15,62). MIB modules are supposed to be able to be used by
different protocols. In practice, only SNMP uses them, but the IETF
Standard Management Framework still makes the distinction that a MIB
module may be used by non-SNMP protocols. Therefore, it is incorrect
to refer to a MIB module as an SNMP MIB module.

5) s/MIB datatypes/SMI datatypes/g
/will define/defines/
/[RFC2578]"/[RFC2578]/

6) In section 3, R3 says "and only those values"; is that redundant
with R5?

7) in R7, what is "most direct"?

8) section 4 - if the integr data types don't describe the differences
between counters and guages, for example, does this contradict R5? Can
we validate using these translations?

9) section 5 talks about canonical being assumed. Is this a clear and
unambiguous specification of what implementers need to do?

10) section 5.2 says hexBinary "complies" with the standard  encoding
rules associated with the corresponding SMI datatype. Are we changing
the encoding here? How does it "comply"?

11) section 5.2. mentins encoding rules for the first two octets of an
OID. Where is this restriction documented? Is this part of ASN.1? BER?
or SMI?

12) section 6 discusses SNMPv3 security. As mentioned in point 4), MIB
modules are not SNMP MIB modules. In addition, not all SNMP usage is
SNMPv3 (it could be SNMPv99 in the future ;-). It is OK to mention
SNMPv3 as an example, but not as the only SNMP version or the only
protocol to consider. This text should talk about security features,
including authentication, encryption, integrity checking, and
authorization, such as those found in SNMPv3, rather than saying that
"SNMPv3 security mechanisms are supported". (look at the wording of
the boilerplate Security Considerations for MIB modules).

13) There is a [TODO] to add an information references section about
prior development publications. You will need to e careful not to
reference expired I-Ds.

14) Some of the normative references seem more informational.

David Harrington
[email-masked]
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of
[email-masked]
> Sent: Monday, February 11, 2008 2:45 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [OPSAWG] I-D 
> ACTION:draft-ietf-opsawg-smi-datatypes-in-xsd-00.txt
> 
> This draft is a work item of the Operations and Management 
> Area Working Group Working Group of the IETF.
> 
> 	Filename	:
draft-ietf-opsawg-smi-datatypes-in-xsd-00.txt

> You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce 
> 	"FILE 
> /internet-drafts/draft-ietf-opsawg-smi-datatypes-in-xsd-00.txt".
>

---

From: "Natale, Bob" <[email-masked]>
Date: Tue, 19 Feb 2008 16:18:11 -0500

Hi Dave,

Thanks for the review...preliminary responses inline below...I hope to
get out the -01 update over the coming weekend incorporating most, if
not all, of your comments...and I have already incorporated the earlier
comment from Juergen into that version.

Let me know if any of the responses miss the point or fall short of an
acceptable resolution.

Cheers,
BobN

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of David Harrington
Sent: Monday, February 18, 2008 5:10 PM
To: [email-masked]
Subject: [OPSAWG] a review of
draft-ietf-opsawg-smi-datatypes-in-xsd-00.txt

Hi,

<BobN>
I don't mind adding words along the lines of "(when approved as a
standards-track RFC)" wherever the raw assertion appears now, if that
would be acceptable...?
</BobN>

<BobN>
I would like WG consensus on this point, one way or the other.
Personally, I believe that endorsing multiple standards for validating
values in XML documents which represent SMI datatypes via XSD is
ill-advised.
</BobN>

<BobN>
Will edit all occurrences of "MIBs" to read "MIB modules", and related
adjustments (if any).
</BobN>

<BobN>
Will correct throughout.
</BobN>

<BobN>
Will fix.
</BobN>

<BobN>
Effectively, yes.  I will remove the phrase from R3.
</BobN>

<BobN>
The phrase is meant to explain the intention of the foregoing
requirements wrt the XML output, avoiding superfluous "decoration".
For example, "1" rather than "0000000001".  Do you feel R7 should be
deleted?
</BobN>

<BobN>
You can validate the raw values, and that is the fundamental purpose --
Are the values in this XML document valid?.  However, the [DISCUSS]
item just before the start of Section 5 asks whether we should include
more explanation about SMI datatype restrictions (as "documentation" or
"appInfo" elements).  Explaining Counter vs Gauge *behavior* _seems_
out-of-scope to me here.  But maybe since a primary "consumer" of this
spec is ultimately the non-SNMP management community, perhaps we ought
to go into more detail...?  I'm still leaning toward the leanest
possible text that accomplishes the primary purpose.  Other views?
</BobN>

<BobN>
I will add further explanation/references about the canonical
implications for each datatype.
</BobN>

<BobN>
No, we are not changing encoding here.  The section seems to clearly
indicate how hexBinary complies with the requirements (and also
explains the canonical implications for this datatype).
</BobN>

<BobN>
The restriction is, to the best of my knowledge, a part of ASN.1/BER.
I will try to find my copy of Stedham's book (from ~15 years ago! ;)
and include a reference if possible.
</BobN>

<BobN>
Will adjust the text.
</BobN>

<BobN>
Ok...I was thinking more about some journal papers I read along the
way.
</BobN>

<BobN>
Ok...will check 'em...the References sections need some cleanup overall
(in the XML, at least).
</BobN>

David Harrington
[email-masked]
[email-masked]

[email-masked]