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

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

I believe  that this input should be addressed to the ipr wg with copy
to the iesg and [e-mail]. 

Dan


> -----Original Message-----
> From: tom.petch [mailto:[e-mail]] 
> Sent: Wednesday, June 17, 2009 3:46 PM
> To: Natale, Bob; Romascanu, Dan (Dan)
> Cc: [e-mail]
> Subject: Re: [OPSAWG] AD Review 
> ofdraft-ietf-opsawg-smi-datatypes-in-xsd-05.txt
> 
> ----- Original Message -----
> From: "Natale, Bob" <[e-mail]>
> To: "Romascanu, Dan (Dan)" <[e-mail]>
> Cc: <[e-mail]>
> Sent: Tuesday, June 16, 2009 8:14 PM
> 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:
> >
> <snip>
> >
> > 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?
> >
> 
> I think that idnits is maintained by someone who does not 
> approve of RFC5378:-(
> 
> The aim should be for all future RFC to allow changes to be 
> made outside the IETF process, with permission of the Trust, 
> and that is what RFC5378 seeks to establish.  The revised 
> Note Well, which came into force on 10Nov2008 (even if many 
> did not see it for days or months afterwards) requires us to 
> grant those rights for our Contributions. But, the Sam 
> Hartman problem, we are going to go on reusing material from 
> before 10Nov2008 for years to come, for which no such grant 
> has been made so idnits checks for a pre-10Nov2008 date and 
> then tries to bully you into not granting RFC5378 rights.  If 
> you are solely responsible for the Contribution, or have got 
> consent from any significant others, then of course you can 
> and should grant RFC5378 rights and no disclaimer is needed.  
> In which case, just ignore idnits.
> 
> > 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?
> >
> 
> I agree and see the text in the .pdf you cite but it is the 
> whole text, starting with 'Copyright ...'
> and ending with
> '...POSSIBILITY OF SUCH DAMAGE'
> 
> MIB modules (what else?) give an exemplar of how to do it, eg 
> draft-ietf-isms-secshell.
> 
> Tom Petch
> >
> > 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]
> 
>