Re: draft-josefsson-ipr-rules-update-00

[[e-mail] (Scott Bradner)]

Simon lists:
A list of modifications forbidden by RFC 3978 that I want to be able
to do:

* Typographical changes.  Compare the table at:
  http://josefsson.org/gss/manual/gss.html#Context_002dLevel-Routines
  with the table in section 2 of RFC 2744.  I have added punctuation
  because the RFC uses inconsistent punctuation, and I have removed
  the "section" column because that column refer to RFC internal
  section numbers.

>> if the punctuation difference is significant use the errata process
>> http://www.rfc-editor.org/errata.html
>> I'd think that a pointer to the correct RFC section would be useful

* Modify ASN.1 schemas to make minor adjustments.  Compare the ASN.1
  schema I use for Kerberos 5 in Shishi:
  http://josefsson.org/cgi-bin/viewcvs.cgi/shishi/lib/kerberos5.asn1?rev=1.8&view=auto
  with the ASN.1 schema in RFC 4120.  I had to change 'INTEGER
  (0..429467295)' into 'INTEGER' because my ASN.1 library do not
  handle bignums.  This doesn't result in any change of protocol
  behavior, of course.  Other Kerberos 5 implementation need the same
  right.  I looked at both MIT Kerberos 5 and Heimdal, and they both
  ship modified ASN.1 schemas.  In fact, they have modified the
  schemas considerably more than I have.

>> sounds like significant changes - i.e., impact interoperability - 
>> should be done through the IETF standards process

* Remove non-applicable portions of introductory sections, when
  incorporating them into my manual.  Compare section 3 of RFC 2222
  <with http://josefsson.org/gsasl/manual/gsasl.html#SASL-Overview>.
  I have removed some forward references, such as a sentence:

   SASL mechanism names must be registered with the IANA.  Procedures
   for registering new SASL mechanisms are given in the section
   "Registration procedures".

  Having that specific sentence in my manual isn't useful for the
  reader, but the rest of that text is very useful.

>> enabled by draft-ietf-ipr-rules-update-01.txt

* Extract portions of RFCs into source code comment, after removing
  line breaks and other material.  See:
  http://josefsson.org/cgi-bin/viewcvs.cgi/gsasl/lib/digest-md5/validate.c?rev=1.8&view=auto
  Most of the comments are taken from the RFC, to document which
  MUST/SHOULD requirements are translated into 'if' tests.

>> extracts (not modified) enabled by draft-ietf-ipr-rules-update-01.txt

* Use tables with Unicode code points from RFCs, e.g., compare RFC
  3454 with how my Libidn is incorporated in GNU Libc:
  http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/libidn/rfc3454.c?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=glibc
  The tables are modified heavily, typographically, from the RFC.

>> sounds like significant changes - i.e., impact interoperability - 
>> should be done through the IETF standards process

* Extract function comments into source code, and be able to improve
  them over time.  E.g., compare RFC 2744 with:
  http://josefsson.org/cgi-bin/viewcvs.cgi/gss/lib/context.c?rev=1.31&view=auto
  That file contain comments derived from the RFC, but sometimes I
  have improved on the function description with more information that
  the end-user may find helpful.

>> extracts (not modified) enabled by draft-ietf-ipr-rules-update-01.txt
>> append improvement to end of extracted material or just replace 
>> extract

>> looks like the significant difference is where you want to make
>> significant (in terms of interoperability) changes (the rest of your 
>> examples seem cosmetic) - it is my opinion that inetroperability-impacting
>> changes should be done through the IETF Standards Process for IETF
>> documents

Scott

_______________________________________________
Ipr-wg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ipr-wg