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

["David Harrington" <[e-mail]>]

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
>