Re: Last Call: 'IETF Rights in Contributions' to BCP

On Mon, 4 Aug 2003, C. M. Heard wrote (off-line):
> With regard to the following [last call comments on
> <draft-ietf-ipr-submission-rights-06.txt>]: do you
> want me to propose specific text?

On Mon, 4 Aug 2003, Scott Bradner replied (off-line):
> sure

After struggling with this for a couple of days, I have to admit
that it's not clear to me exactly what to do, because I've been
only a fringe participant in the WG and have an imperfect
understanding of the _intent_ of the document.  So I now have to
ask for some clarification.

Regarding this:
> First, in Section 5.4, "Copyright Notice (required for all IETF
> Documents)", it says:
> 
>    (Normally placed at the end of the IETF Document.)
> 
>       "Copyright (C) The Internet Society (year). This document is
>       subject to the rights, licenses and restrictions contained in RFC
>       XXXX and except as set forth therein, the authors retain all their
>       rights."
> 
>    [note to the RFC Editor - XXXX above to be replaced with the number
>    of this document]
> 
>    Additional copyright notices are not permitted in IETF Documents
>    except in the case where the document is the product of a joint
>    development effort between the IETF and another standards development
>    organization.  Such exceptions must be approved on an individual
>    basis by the IAB.

Just to make sure that I have not misinterpreted what's being said
here, my understanding is that it will change the rules set forth in
RFC 2026 10.4(C) in the following two ways, once
draft-ietf-ipr-submission-rights is published as RFC XXXX:

(a) all IETF Internet-Drafts and all RFCs published from them will
not contain the full copyright statement from RFC 2026 10.4(C) but
rather will contain the shorter notice shown above;

(b) the requirement to include this notice applies to _all_ IETF
Documents, not just "standards-related documentation" (to use the
phrase from RFC 2026).

I also understand that this section does not NOT apply to RFC Editor
documents and that draft-ietf-ipr-submission-rights is deliberately
silent about requirements for copyright notices in such documents.

> It seems to me that this does not adequately cover the cases where a
> proprietary specification or a standard that is the product of
> another SDO is being republished in an informational RFC.  In many
> if not most such cases the RFC will require a copyright notice that
> does not grant the right to create derivative works (or, as per the
> second comment below, grants only very limited rights).  Note that
> such a variant copyright (without the right to produce derivative
> works) has appeared in many such works in the past (RFC 3394 being
> the most recent one that I could find).  Also, it seems to me
> unreasonable that the copyright notice in such an RFC could not
> (even with IAB approval) mention the organization that originally
> produced the specification that is being republished and that
> retains change control over it.

The problem, I think, may be in the term "IETF Documents", which
according to the submission-rights draft are any documents other
than RFC Editor documents.  It seems that its scope includes a draft
intended for publication as an Informational RFC that contains a
standard developed by another SDO if that draft is submitted to a
working group, rather than directly to the RFC Editor.  An example
of such is <draft-ietf-bridge-8021x-02.txt>.  It seems odd that
there should be different requirements that depend on the submission
route rather than the content and purpose of the document.  (I
assume here that there is no intent to change the current "running
code" policy that allows for for such documents a full copyright
statement that permits translations into other languages but not
other forms of derivative works ... see RFC 3394 for an example.)

I'm not sure if the correct way to fix this is to tinker with the
"(required for all IETF Documents)" language in Section 5.4, or if
the definition of "IETF Contributions" needs to be revised to
exclude drafts containing external specifications that are intended
just to republish those specs as Information or Experimental RFCs,
even if said drafts are not submitted directly to the RFC Editor.

> The second issue has specifically to do with MIB or PIB modules that
> are included an informational RFC of this sort ... the
> IEEE8021-PAE-MIB in draft-ietf-bridge-8021x-02.txt being an example.
> Now, Section 5.2 (entitled "Derivative Works Limitation") says what
> needs to be done in an Internet-Draft if a contributor wants to
> disallow derivative works except for extraction of a MIB or PIB
> module:
> 
>    If the Contributor desires to eliminate the IETF's right to make
>    modifications and derivative works of an Contribution (other than
>    translations), one of the two the following notices may be included
>    in the Status of memo section of an Internet-Draft and included in a
>    published RFC:
> 
>    a. "This document may not be modified, and derivative works of it may
>       not be created, except to publish it as a RFC and to translate it
>       into languages other than English."
> 
>    b. "This document may not be modified, and derivative works of it may
>       not be created."
> 
>    In the cases of MIB or PIB modules and in other cases where the
>    Contribution includes material that is meant to be extracted in order
>    to be used, the following should be appended to statement 5.2 (a) or
>    5.2 (b):
> 
>       "other than to extract section XX as-is for separate use."
> 
>    Notice 5.2(a) is used if the Contributor intends for the Contribution
>    to be published as a RFC.  Notice 5.2(b) is used along with the
>    Publication Limitation in Section 5.3 when the Contributor does not
>    intend for the Contribution to be published as a RFC.
> 
> So far, so good.  For draft-ietf-bridge-8021x-02.txt notice 5.2 (a)
> with the extra statement appended would probably be appropriate.
> However, the extra statement would need to need to find its way into
> the Full Copyright Statement in the published RFC, and I didn't see
> a mechanism in the submission-rights draft for this to happen.

The same comments as above apply here.

> A third issue is that the abbreviated notice for MIB and PIB modules
> in Section 5.6 does not seem to seem to be entirely appropriate for
> a MIB or PIB module for which the IETF does not own change control.
> The submission-rights draft says:
> 
>    a. in MIB modules, PIB modules and similar material commonly
>       extracted from IETF Documents, except for material that is being
>       placed under IANA maintenance, the following abbreviated notice
>       shall be included in the body of the material that will be
>       extracted in lieu of the notices otherwise required by Section 5:
> 
>          "Copyright (C) <year> The Internet Society.  This version of
>          this MIB module is part of RFC XXXX;  see the RFC itself for
>          full legal notices."
> 
> Specifically, it does not seem reasonable to me to require mention of
> ISOC but not to allow mention of the organization that originally
> produced the MIB module and that retains change control over it.  In
> fact, I would think that the nature of the copyright notice in the MIB
> module (and even whether there is one) should probably be determined
> by the party that is granting permission to republish it;  after all,
> the abbreviated copyright notice covers a derivative work (the
> extracted MIB module), not the RFC from which it was extracted.

And here too.

Mike Heard

_______________________________________________
Ipr-wg mailing list
Ipr-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/ipr-wg