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

["tom.petch" <[e-mail]>]

----- 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]