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

[Simon Josefsson <[e-mail]>]

[e-mail] (Scott Bradner) writes:

> 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

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.

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

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.

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

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.

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

Same here.

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

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

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

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

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

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

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