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

["Romascanu, Dan (Dan)" <[e-mail]>]

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