Subject: [OPSAWG] AD Review of draft-ietf-opsawg-smi-datatypes-in-xsd-05.txt

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 16 Jun 2009 13:25:45 +0200

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

---

From: "Natale, Bob" <[email-masked]>
Date: Tue, 16 Jun 2009 14:14:54 -0400

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 corresponding 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: [email-masked] [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Tuesday, June 16, 2009 7:26 AM
To: [email-masked]
Subject: [OPSAWG] AD Review of draft-ietf-opsawg-smi-datatypes-in-xsd-05.txt

Thanks and Regards,

Dan
_______________________________________________
OPSAWG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsawg

---

From: "David Harrington" <[email-masked]>
Date: Tue, 16 Jun 2009 18:17:53 -0400

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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Natale, Bob
> Sent: Tuesday, June 16, 2009 2:15 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]
> Subject: Re: [OPSAWG] AD Review 
> ofdraft-ietf-opsawg-smi-datatypes-in-xsd-05.txt
> 
> Hi Dan,
> 
> 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?
> 
> 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.
> 
> 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
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
> Subject: [OPSAWG] AD Review of 
> draft-ietf-opsawg-smi-datatypes-in-xsd-05.txt
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 17 Jun 2009 06:41:32 +0200

> you need to find the "most direct" almost-equivalent.

Well, I could easily claim that the "most exact" or "most direct" or
"faithful" translation of OCTET STRING (SIZE(4)) would be a hexBinary
of the same length. Still, we translate IpAddress into a textual
string containing a dotted number representation of the 4 octet value.

I am not questioning this translation of IpAddress here - but I do
share Dan's concerns about a marketing like language that claims that
this translation is the "most exact" or "most direct" or "as faithful
as possible" translation.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Natale, Bob" <[email-masked]>
Date: Wed, 17 Jun 2009 02:48:37 -0400

Hi Juergen,

You were extremely helpful in getting to the correct XSD representation of IpAddress, so I hate to respond critically to your comment below...but I feel I must on two counts:

1. The requirements list for the selection of mappings also says this:
- - - - -
   R4.  The XSD datatype specified for a given SMI datatype MUST
        represent any special encoding rules associated with that SMI
        datatype.

   R5.  The XSD datatype specified for a given SMI datatype MUST include
        any restrictions on values associated with the SMI datatype.
- - - - -
So, the selected mappings for IpAddress and ObjectIdentifier go to "string" to enable the proper restrictions on values in a reasonable way.

2. I believe that tossing "marketing" into the ring is either a red herring or a low blow or both (nothing like getting smacked below the belt with a red herring :).  I personally consider it a worthy engineering goal when doing coding translations to be as faithful (in the sense of fidelity to the original) and direct (in the sense of the minimum necessary "extras" to achieve the true meaning of the original.  It's reasonable to suggest more accurate synonyms, but the objective is engineering quality, regardless.

Man, this is a tough place to complete a simple task. :(

Or, maybe I'm just too sensitive and/or in too much of a rush...after all, what's a couple of years for what should be a straightforward mapping of a few datatypes...?

Cheers,
BobN

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Wednesday, June 17, 2009 12:42 AM
To: David Harrington
Cc: Natale, Bob; 'Romascanu, Dan (Dan)'; [email-masked]
Subject: Re: [OPSAWG] AD Review ofdraft-ietf-opsawg-smi-datatypes-in-xsd-05.txt

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 17 Jun 2009 09:50:25 +0200

I trust your native English speaker skills :-) 

I believe that a somehow more verbose definition could help. 

Dan

> From: David Harrington [mailto:[email-masked]] 
> Sent: Wednesday, June 17, 2009 1:18 AM
> To: 'Natale, Bob'; Romascanu, Dan (Dan)
> Cc: [email-masked]
> Subject: RE: [OPSAWG] AD Review 
> 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"
> 
> 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
> 
> > 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?
> > 
> 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 
> > (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)
> (insert other 
> > text) to explicitly apply some other license grant (or usage 
> > restrictions).  Do you read that policy differently?
> > 
> management 
> > layers/technologies to complete a task is likely to also result in 
> > overall faster operations and overall fewer errors in operations.
> > 
> 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.
> > 
> 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"
> the SMIv2 
> > 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.
> 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"
> XSD could 
> > definitely include whatever comments the application creating the 
> > document deemed useful.  Only the datatypes and c  
> orresponding data 
> > E10: Will replace "faithful" to a term corresponding with 
> the change 
> > to be made per E6.
> > 
> > E11: Will do.
> > 
> > E12: Will do.
> > 
> > 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.
> > 
> > 
> >       controlling the copyright in such materials, this 
> document may 
> > not
> > 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
> > 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
> > 
> > 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
> >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 17 Jun 2009 12:54:30 +0200

On Wed, Jun 17, 2009 at 08:48:37AM +0200, Natale, Bob wrote:
 
> You were extremely helpful in getting to the correct XSD
> representation of IpAddress, so I hate to respond critically to your
> comment below...but I feel I must on two counts:

[...]

It seems I did not get my message across too well. To make things
simple, let me simply state that I support Dan's comments concerning
the language in the requirements.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 17 Jun 2009 13:02:21 +0200

Hi Bob,

Thanks for the quick answer. See a few clarification answers back below.

Please do not issue a revised I-D by now. I believe that this version is
mature enough for last call. 

Dan

> From: Natale, Bob [mailto:[email-masked]] 
> Sent: Tuesday, June 16, 2009 9:15 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]
> Subject: RE: AD Review of 

Yes. 

> the terms of the warning.  Do you feel that was the wrong conclusion?

It's OK - I just wanted to make sure you are aware about the warning. 

> grant (or usage restrictions).  Do you read that policy differently?

 The RFC will need to include the full text of the full BSD license but
exact location and the text to become part of the code is still being
discussed. I suggest no edits by now as the exact text is not yet
approved by the Trustees.

> datatypes and corresponding data values are addressed by this 
> I-D (RFC).

'no comments included' are my words for what I was reading in R7. I
understand now and accept your intention.

---

From: "tom.petch" <[email-masked]>
Date: Wed, 17 Jun 2009 14:46:28 +0200

----- Original Message -----
From: "Natale, Bob" <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, June 16, 2009 8:14 PM
Subject: Re: [OPSAWG] AD Review ofdraft-ietf-opsawg-smi-datatypes-in-xsd-05.txt

> 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
> 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
> Thanks again, Dan, and please let me know if any of the above responses are
unacceptable to you or could be further improved.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 17 Jun 2009 18:14:14 +0200

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

Dan

> From: tom.petch [mailto:[email-masked]] 
> Sent: Wednesday, June 17, 2009 3:46 PM
> To: Natale, Bob; Romascanu, Dan (Dan)
> Cc: [email-masked]
> > that the
> answer to its question "Should you add the disclaimer?" was 
> warning.  Do you feel that was the wrong conclusion?
> >
> 
> 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.
> 
> > time I
> got through the end of its Sec. 4.3, it seemed to me that it 
> of text to include for XSDs and such.
> (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
> I agree and see the text in the .pdf you cite but it is the 
> whole text, starting with 'Copyright ...'
> and ending with
> > 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 
> > 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.
> >
> > "fidelity"...the
> original intent of that word here was something like "the 
> most exact reproduction of the SMIv2 datatype possible with 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.
> >
> 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
> > to be
> made per E6.
> > responses are
> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of
> Romascanu, Dan (Dan)

---

From: "David Harrington" <[email-masked]>
Date: Wed, 17 Jun 2009 12:32:12 -0400

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

> [mailto:[email-masked]] On Behalf Of tom.petch
> Sent: Wednesday, June 17, 2009 8:46 AM
> Subject: Re: [OPSAWG] AD 
> Reviewofdraft-ietf-opsawg-smi-datatypes-in-xsd-05.txt
> 
> decided that the
> no, because it did
> made outside the
> quickly.  By time I
> was saying that the
> grant for the XSD
> predicate here is that
> reduce the text w/o
> improved in this respect
> defined XSD datatypes
> smallest set of XSD
> I-D, so I'm not sure
> misreading (which
> this document only.
> consumption at the
> human users via
> the application
> the change to be

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 17 Jun 2009 09:42:35 -0700

Hi -

> From: "David Harrington" <[email-masked]>
> To: "'tom.petch'" <[email-masked]>; "'Natale, Bob'" <[email-masked]>; "'Romascanu, Dan (Dan)'" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, June 17, 2009 9:32 AM
> Subject: Re: [OPSAWG] ADReviewofdraft-ietf-opsawg-smi-datatypes-in-xsd-05.txt
...
> to this document, from my perspective, it is correct to use the

Use of the pre5378 clause is only necessary if the document contains
passages copied from the earlier work. (This is about *COPY*right,
after all.)  Merely referencing the ideas or names of data types isn't
enough to make it necessary.  Likewise, a properly credited quote
from earlier work would also not trigger the need for the pre5378
clause.

Randy