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

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

Hi,

This document is not a "greenfield" document. Unless Bob gets all the
authors of SMIv2 and its predecessors and the earlier versions of this
document to grant permission to apply the new rfc5378 copyright terms
to this document, from my perspective, it is correct to use the
pre5378 clause. 

I believe Bob will have a hard time reaching some of the authors, who
have stopped participating in IETF and whose contact information is no
longer valid.

I think idnits correctly prompts authors to understand and verify that
not using the pre5378 clause is the correct choice from a legal
perspective.

dbh

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of tom.petch
> Sent: Wednesday, June 17, 2009 8:46 AM
> To: Natale, Bob; Romascanu, Dan (Dan)
> Cc: [e-mail]
> Subject: Re: [OPSAWG] AD 
> Reviewofdraft-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]
> 
> _______________________________________________
> OPSAWG mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/opsawg
>