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

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

I trust your native English speaker skills :-) 

I believe that a somehow more verbose definition could help. 

Dan
 

> -----Original Message-----
> From: David Harrington [mailto:[e-mail]] 
> Sent: Wednesday, June 17, 2009 1:18 AM
> To: 'Natale, Bob'; Romascanu, Dan (Dan)
> Cc: [e-mail]
> Subject: RE: [OPSAWG] AD Review 
> ofdraft-ietf-opsawg-smi-datatypes-in-xsd-05.txt
> 
> Hi,
> 
> Personally, I think fidelity and faithful are the right words.
> 
> From Merriam-Webstre Dictionary:
> 1 a: the quality or state of being faithful b: accuracy in details :
> exactness
> 2: the degree to which an electronic device (as a record 
> player, radio, or television) accurately reproduces its 
> effect (as sound or
> picture) 
> 
> I think that Bob could state how this word was used to 
> describe "the most exact reproduction of the SMIv2 datatype 
> possible with XSD". He could also quote from the 
> Merriam-Webster definition.
> 
> "most direct" also says ""the most exact reproduction of the 
> SMIv2 datatype possible with XSD"
> 
> Of course, you could use exactness:
> 1 : exhibiting or marked by strict, particular, and complete 
> accordance with fact or a standard
> 2 : marked by thorough consideration or minute measurement of 
> small factual details 
> 
> #1 applies when you can do an exact translation, and #2 
> applies when you need to find the "most direct" almost-equivalent.
> 
> dbh
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Natale, Bob
> > Sent: Tuesday, June 16, 2009 2:15 PM
> > To: Romascanu, Dan (Dan)
> > Cc: [e-mail]
> > Subject: Re: [OPSAWG] AD Review
> > ofdraft-ietf-opsawg-smi-datatypes-in-xsd-05.txt
> > 
> > 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 c  
> orresponding 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
> > _______________________________________________
> > OPSAWG mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/opsawg
> > 
> 
>