Re: [OPSAWG] AD Review of draft-ietf-opsawg-smi-datatypes-in-xsd-05.txt

["Natale, Bob" <[e-mail]>]

Hi Dan,

Thanks for the comments and for moving the IETF process forward.

Concerning your comments:

T1: Yes, that is the intent of the R2: An SMIv1 MIB module must be converted to SMIv2 (insofar as datatypes are concerned) in accordance with RFC 3584 *prior to mapping to XSD as specified in this I-D* (or eventual RFC).  Perhaps I should make that last part explicit in the wording of R2...?

E1: I examined the idnits warning carefully at the time and decided that the answer to its question "Should you add the disclaimer?" was no, because it did not seem necessary per the terms of the warning.  Do you feel that was the wrong conclusion?

E2: Reading RFC 5377 gives me a headache, literally, and quickly.  By time I got through the end of its Sec. 4.3, it seemed to me that it was saying that the IETF Trustees "should define" some kind of text to include for XSDs and such.  So, I then reviewed the text of http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf (much bigger headache now) and it seems to me that it says that the BSD license grant for the XSD "code" is implicitly granted by virtue of the "Copyright Notice" in the I-D (RFC) -- and that authors would have to do something concrete (insert other text) to explicitly apply some other license grant (or usage restrictions).  Do you read that policy differently?

E3: Will apply your change.

E4: "attendant improvements" means "expected corresponding improvements from more unified management" (or words to that effect)...the predicate here is that technology that helps to eliminate the need for discrete operations across multiple management layers/technologies to complete a task is likely to also result in overall faster operations and overall fewer errors in operations.

E5: You are probably right.  I will take a look at how to reduce the text w/o loss of anything important.  I am sure that it can be improved in this respect using your specific observations as a guide.

E6: I will use one of your suggested alternatives in place of "fidelity"...the original intent of that word here was something like "the most exact reproduction of the SMIv2 datatype possible with XSD".

E7: "most direct" in R6 means the choice among the W3C defined XSD datatypes that most closely matches the SMIv2 datatype, with only the smallest set of XSD "restriction" required (if any) to provide "fidelity" (word to change) to the SMIv2 datatype.

E8: I don't find the phrase "no comments included" in the I-D, so I'm not sure how to respond to this exactly.  However, perhaps you are misreading (which would be my fault) the purpose of the requirements listed in Sec. 3:  They are requirements applied to the selection of XSD datatypes in this document only.  The output produced (in either direction) is intended for consumption at the machine-to-machine level.  When brought up to the level of human users via management applications, the application may do whatever it deems best in terms of XML (or other) output.  The XSDMI "standard" will have done its job at a lower layer...i.e., ensuring that the raw SNMP data (or the SMIv2 datatype for pure data modeling applications) was represented correctly at the protocol level.  Even at the "raw data" level, an XML document produced and validated against this XSD could definitely include whatever comments the application creating the document deemed useful.  Only the datatypes and corresponding data values are addressed by this I-D (RFC).

E9: Will do.

E10: Will replace "faithful" to a term corresponding with the change to be made per E6.

E11: Will do.

E12: Will do.

Thanks again, Dan, and please let me know if any of the above responses are unacceptable to you or could be further improved.

Cheers,
BobN

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Romascanu, Dan (Dan)
Sent: Tuesday, June 16, 2009 7:26 AM
To: [e-mail]
Subject: [OPSAWG] AD Review of draft-ietf-opsawg-smi-datatypes-in-xsd-05.txt

Please find below the AD review for
draft-ietf-opsawg-smi-datatypes-in-xsd-05.txt. I believe that this
document is mature enough to be sent to IETF Last Call. Unless there are
any last minute comments I plan to send it to IETF Last Call by
tomorrow. 

The requirements below are dived into Technical and Editorial. Please
consider them together with the other Last Call comments.

T1. I am not sure that I understand requirement R2 in Section 3. It does
not look like it imposes any requirement for the mapping. It is
sufficient I think that we dully state that version SMIv2 is the version
that is supported, and that any SMIv1 MIB module should be first
translated into SMIv2. Maybe this is actually the intention, but this is
not a requirement on the mapping. 


E1. Running idnits results in the following warning: 

 == The document seems to lack a disclaimer for pre-RFC5378 work, but
was
     first submitted before 10 November 2008.  Should you add the
disclaimer?
     (See the Legal Provisions document at
     http://trustee.ietf.org/license-info for more information.). 

     trust-12-feb-2009 Section 6.c.iii text:
     "This document may contain material from IETF Documents or IETF
      Contributions published or made publicly available before November
      10, 2008.  The person(s) controlling the copyright in some of this
      material may not have granted the IETF Trust the right to allow
      modifications of such material outside the IETF Standards Process.

      Without obtaining an adequate license from the person(s)
      controlling the copyright in such materials, this document may not
      be modified outside the IETF Standards Process, and derivative
      works of it may not be created outside the IETF Standards Process,
      except to format it for publication as an RFC or to translate it
      into languages other than English."

E2. According to RFC 5377 he Section 4 'code' will need to include a
full version of the full BSD license or a statement agreed by the IETF
Trust. The exact formulation of the statement is still in discussions,
please follow the latest instructions available at
http://trustee.ietf.org/license-info/

E3. Section 1 - s/legacy MIBs/legacy MIB modules/

E4. same - what does 'with attendant improvements' mean? 

E5. same - it looks to me like some paragraphs are redundant and this
section can be shortened. For example the paragraphs starting with 'The
objective of this memo ...' and 'Having such a standard mapping ...' do
not seem to bring any new information, they just say what was already
said earlier in the same section.

E6. same - 'The goal of fidelity ...' I am not sure that 'fidelity' is
the right term - maybe 'consistency' or 'accurate translation' or
'accurate mapping'

E7. Section 3, R6 - it is not clear to me what 'the most direct' means

E8. same, R7 - again 'the most direct'. Also, I am not sure that saying
'no comments included' is a requirement. In many cases comments are
useful and not superfluous 'decoration'

E9. Section 5 -  It would be good to include the exact reference to W3C
XSD in the text

E10. Section 5.1 - 'faithful' does not sound like the right term

E11. Section 5.4 - although trivial for people familiar with SMI it may
be helpful for some to explain why only IPv4 addresses are described in
the document

E12. Section 5.5 - It would be better rather then use a tutorial as a
reference to refer to the standard directly for ASN.1 / BER Encoding.
Reference [4] in RFC 2578 seems to be the right one. 

Thanks and Regards,

Dan
_______________________________________________
OPSAWG mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/opsawg