[AFS3-std] Options for AFS Standardisation

Russ Allbery rra@stanford.edu
Wed, 23 Jul 2008 22:37:42 -0700


Jeffrey Altman <jaltman@secure-endpoints.com> writes:

> This is fine except that an Independent Submission to the RFC Editor is
> not an IETF document and BCP 78 does not apply.  All Independent
> Submissions to the RFC Editor for publication include an explicit
> statement that the document is not an IETF Document.  All of the
> requirements and specifications governing the Independent Submission
> process is instead described in RFC 4846.
>
> http://www.rfc-editor.org/rfc/rfc4846.txt
>
> The normative reference to BCP 78 in that document is there because the
> relevant material from BCP 78 that applies to the Independent Submission
> process was copied from BCP 78.  Note the requirements in Section 8 that
> assign rights not just to the RFC Editor but to the community.

Ah, thank you.  I completely missed that.

This is almost sufficient.  Here's the relevant provision:

   By submission of an RFC Editor Contribution, each person actually
   submitting the RFC Editor Contribution, and each named co-
   Contributor, is deemed to agree to the following terms and
   conditions, and to grant the following rights, on his or her own
   behalf and on behalf of the organization the Contributor represents
   or is sponsored by (if any) when submitting the RFC Editor
   Contribution.

[...]

       B.  unless explicitly disallowed in the notices contained in an
           RFC Editor Contribution, to prepare derivative works (other
           than translations) that are based on or incorporate all or
           part of the RFC Editor Contribution, or comment upon it.  The
           license to such derivative works shall not grant the IETF
           Trust, the IETF, or other party preparing a derivative work
           any more rights than the license to the original RFC Editor
           Contribution, and

Provided that we rule out disallowing this (which I think Simon's language
is designed to do), the only flaw in this is that it doesn't explicity
state that such derivative works (and the original work for that matter)
may be redistributed freely, and it doesn't define community explicitly to
mean everyone in the world without limitation.

Unfortunately, given the creative interpretation of the Pine license, it's
worth spelling out, even if a license allows redistribution and derivative
works, that it *also* allows redistributing the derivative works.

If we can close those two loopholes and make it clear (it probably is for
people who know the process, but I didn't find it so from the plain
language) that even the I-Ds are "RFC Editor Contributions" for the
purposes of this section, I'm content.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>