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

From: [email-masked] (Scott Bradner)
Date: Tue, 18 Oct 2005 08:11:51 -0400 (EDT)

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipr-wg

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 18 Oct 2005 14:53:25 +0200

>>> I'd think that a pointer to the correct RFC section would be useful

Doesn't the RFC editor check, and sometimes reject, errata proposals?
If they don't agree with my typographical changes, I am back in the
position I am in now.  Further, the RFC editor process is slow.  If
the change was for a security critical matter in the source code that
had to be dealt with within a few days, relying on the RFC editor to
publish the errata first, before I can use the resulting update,
doesn't seem like a good solution to me.

You forgot about the forward reference column.  I don't believe RFC
3978, including your updates, give me the right to do that, and I also
believe the RFC editor would not publish such an errata.

>>> should be done through the IETF standards process

No, it doesn't impact interoperability.  I said that explicitly.
Modifying the ASN.1 schema slightly is done by all Kerberos 5
implementations that I have access to, for various reasons.

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

Can you quote the license text that permit this?  I find nothing in
that document that give me the right to do that.  There is some rights
granted in section 2.3, but it doesn't permit modifying the extracted
portion.  I am modifying the extracted portion above.

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

Same here.

>>> should be done through the IETF standards process

No, it doesn't impact interoperability.  The table content is the
same.

>>> append improvement to end of extracted material or just replace 

I want to be able to modify the actual text, so the resulting function
description become readable.

>>> changes should be done through the IETF Standards Process for IETF

I don't see anything in your document that permit me to make these
cosmetic changes.  My significant changes does not impact
interoperability, so I believe they should be permitted.

Thanks,
Simon

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 24 Oct 2005 14:28:53 +0200

On Tue, Oct 18, 2005 at 08:11:51AM -0400,
 Scott Bradner <[email-masked]> wrote 

> http://www.rfc-editor.org/errata.html

On 9 January 2005, I sent an errata (RFC 3981) to the RFC editor, I
received an ack but, ten months later, there is still nothing on the
Web site of the RFC editor.

So, Simon is right, the errata process can not be relied upon.

(It has other problems for instance, the RFC published by the RFC
editor contains no reference to a potential errata.)

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 24 Oct 2005 15:28:05 +0200

> editor contains no reference to a potential errata.)

Further, BCP 78 does not appear to grant you the right to take text
from RFCs, modify it and send it to the RFC editor.

I suspect it was intended to permit sending revised text to the RFC
errata, but careful reading of the terminology in section 1 preclude
this usage, as far as I can see.

If I'm correct in my interpretation of BCP 78, this would be another
example when the supposed intention does not match the license text in
BCP 78.  It would also be another example of when the BCP 78 license
differ from the RFC 2026 license.

Btw, a -01 version of my draft (which fix the above problem, and many
others) will be published shortly.  As always, you can review the live
document from <http://josefsson.org/bcp78broken/>.

Regards,
Simon

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 24 Oct 2005 22:46:44 +0200

Stephane Bortzmeyer wrote:

> On 9 January 2005, I sent an errata (RFC 3981) to the RFC
> editor, I received an ack but, ten months later, there is
> still nothing on the Web site of the RFC editor.

Hi, maybe ask again with a Cc: on the rfc-interest list, then
it's at least documented in a puplic archive:

http://dir.gmane.org/gmane.ietf.rfc.interest

Of course it's not really an IETF list, but still "related".

> So, Simon is right, the errata process can not be relied

If the author submits an erratum it can be fast, example.
<http://www.rfc-editor.org/cgi-bin/errataSearch.pl?rfc=3696>

If the authors have no idea what the real problem is it's
probably a hopeless case, and you have to go through the say
"updates 3986" troubles or forget it.

For RfC 3978 they (= RfC editor) accepted the obvious typo,
but not my real problem, where I have no clue what RfC 3978
wants to say.

One way to protect your rights as author might be to publish
an I-D first as private text (with e.g. CC BY SA), and later
as IETF I-D.  With xml2rfc you could publish the source as
the "real thing" (= your text) and its output as "derived" (?)

                          Bye, Frank