To the members of the IESG,
Scott Bradner had suggested that I send these comments your way
as last call comments on these documents given their current
status. I apologize for the length of this mail, but unfortunately
the length was unavoidable due to the subtleties in some of these
points. I would also like to comment how much I appreciate all the
hard work that Scott has put into these docs; this truly was a
thankless task and my hat is off to him; he's done a great job.
In both tech-rights and submission-rights:
1. In several places in both documents, the docs speak of publishing
an IETF Contribution or an RFC Editor Contribution "as an" Internet-
Draft or "as an" RFC. To be consistent with the changes in Sections
6.1.1 and 6.1.2 in these most recent drafts, which acknowledged that
a Contribution might not be published "as" the entire I-D or RFC but
simply "in" an I-D or RFC, this change needs to be made in all the
other places in those documents where this pops up. I am not sure
how best to provide you these changes that will make it easiest for
you - I can do them individually as substitution statements, but
(sorry) a Word doc may be easier for you to see them all.
Unfortunately there is no global search and replace that catches
them all as there are some variants on how this is expressed in the
documents.
2. The definition of "Contributor". I think this needs to be "an
individual submitting an IETF Contribution _or_ an RFC Editor
Contribution". I had mentioned this before in WG discussions, but
I may not have explained sufficiently why this is needed -
"Contribution" is defined to include _both_ IETF Contributions
_and_ RFC Editor Contributions, and from that, as presently written,
a Contributor could be viewed as someone who makes _both_ types of
contributions, which I don't think is the intent.
3. The definition of "RFC Editor Internet-Drafts". This definition is
not used anywhere in either document - should it not be deleted?
Another alternative, if it's desirable to keep it, would be to alter
the definitions of "IETF Documents" and "RFC Editor Documents" so
that they use the definition for "RFC Editor Internet-Drafts", as
follows:
"IETF Documents": RFCs and Internet-Drafts except for RFC
Editor Internet-Drafts and the RFCs that are published from them.
"RFC Editor Documents": RFC Editor Internet-Drafts and the RFCs
that may be published from them.
Even if you don't want to accept these changes, there is at least
reason to delete the leading "RFCs and" from the "RFC Editor
Documents" definition, to wit:
Change "RFCs and Internet-Drafts that are RFC Editor
Contributions and the RFCs that may be published from them"
to "Internet-Drafts that are RFC Editor Contributions and the
RFCs that may be published from them"
reason being that you're talking about RFCs that may be published
from I-Ds, not RFCs themselves, so it does seem as though that
leading "RFCs" needs to go.
..............
In tech-rights alone:
1. Abstract: Does this document really replace all of reference 2 in
RFC 2418 (i.e. RFC 2028??) It doesn't quite seem to cover the same
ground....
2. Section 2 (c).
Change ".... others represented by the participants, that is
reasonably and personally known to the person making the disclosure"
to ".... others represented by the participant, that is
reasonably and personally known to the participant."
This is important - it makes clear that what is important is the
reasonable and personal knowledge of the actual IETF participant, not
the person making the disclosure. In my parochial case, I'm the IETF
participant, but a paralegal in our legal department submits
disclosures for me (and for other MS IETF participants), and
obviously you want my personal knowledge, not hers.
3. Section 6.1.3. I wanted to check my understanding of what is
intended here, and indeed throughout the entire section 6, on _what
kinds of_ contributions require IPR disclosures (and that will be
asked for licensing commitments if none are otherwise supplied). The
way I read this text in Section 6.1.3 as written now - it seems that
third-party IPR disclosures are only encouraged for _IETF_
Contributions, and _not_ for RFC Editor Contributions. Is that true?
If so, then I think some tweaking may be needed to make this concept
consistent throughout section 6, as "Contribution" is used rather
than "IETF Contribution" in all other sections of section 6 other
than Section 6.1.3. Or is the intent to ask Contributors and
participants for IPR disclosure on _all_ contributions, both IETF and
RFC Editor Contributions, but the only place where licensing
commitments would be asked for is IETF Contributions per Section
4(D)? I think that I recall from our prior WG discussions that the
disclosure obligations were only for IETF Contributions, but I wanted
to check my understanding - if that's the case then I think some
minor rewrites for clarity may be needed, such as inserting "IETF"
before Contribution throughout Section 6 (and I can provide text if
that will help, but didn't want to do that until I was sure that I
was correctly processing what's here).
I am also wondering in any case if it might be prudent to delete the
last sentence of Section 6.1.3: "Such a notice should be sent..." lest
it be misinterpreted as a _requirement_ to disclose knowledge of 3rd
party IPR despite the fact that this is only encouraged. I'm also
thinking about this in light of the cautionary note that the Brim
guidelines doc strikes - I know that isn't targeted to be a BCP but
I'm concerned that people may be somewhat confused by what seems to
be perhaps conflicting guidance (i.e., this sentence tells them they
should make a third-party disclosure "as soon as reasonably possible",
whereas the Brim document (Section 5.7.1) tells them to first contact
the WG chairs, etc. before making a disclosure).
4. Section 6.2.1. 3rd para: A change to make clear that this section
is about "Contributors" and their own Contributions:
Change "Participants who realize that a Contribution will be or
has been incorporated into a submission to be published as an
Internet-Draft...."
To "Contributors who realize that a Contribution of theirs will
be or has been incorporated into a submission to be published in an
Internet-Draft..."
(This also caught one of the "in an" changes I mentioned earlier.)
5. Section 6.2.2. First para
Change "Participants who realize that the IPR will be or has been
incorporated into a submission to be published as an Internet
Draft..."
To "Participants who realize that the Contribution of another
party that implicates the participant's IPR will be or has been
incorporated into a submission to be published in an Internet-Draft
or RFC...."
Changes make this sentence consistent with the equivalent sentence
for Contributors in Section 6.2.1; also adding the words "or RFC" to
make this sentence consistent with the other sentences in this
paragraph that refer to both I-Ds _and RFCs_.
Section 6.2.2 Second para: (again to clarify - this section is
about other "participants" rather than the Contributor)
Change "If a Contributor first learns of IPR..."
To "If a participant first learns of IPR..."
Change "reasonably and personally known to the Contributor."
To "reasonably and personally known to the participant."
6. Section 6.4.3. I think the original language needs to be restored
before the new language Scott added, because I think
we need to make clear that the _other_ terms and conditions in the
blanket RF statement must be RAND. So the revised sentence would
read "However, the requirement for an IPR disclosure is satisfied by
a blanket statement of the IPR holder's willingness to license all of
its potential IPR meeting the requirements of Section 6.6 (and either
Section 6.1.1 or 6.1.2) to implementers of an IETF specification on a
royalty-free basis and under other reasonable and non-discriminatory
terms and conditions, so long as any such other terms and conditions
are disclosed in the IPR disclosure statement." I recall Jorge
stating that was the original intent of this language, but I think
it's critically important to make it clear here. (I have to state
privately that the addition of the new requirement in this sentence
to disclose the specific RAND terms feels like a "change" in policy
to me, and I am concerned about that as it seems to go beyond a
clarification, but if it's going to stay, I do think the above edit
is a must have.....)
............
Submission-rights:
1. Section 3. I think I'd previously suggested adding the "IETF"
qualifier before "Contribution" throughout this section (to mirror
the "RFC Editor Contribution" usage in Section 4). This didn't
happen - I realize that perhaps there is some thought that the
title of Section 3 "Rights in IETF Contributions" would be enough
to clarify that RFC Editor Contributions are not implicated, but
I thought I would ask this again - not to be redundant, just to
clarify it for the reader. There are also instances - at least two,
in Section 3.4.a and 3.6 where "IETF Contribution" is used instead
of "Contribution" (including both RFC Editor and IETF Contributions),
so I'm thinking if this doesn't happen throughout we may have some
folks incorrectly interpreting what's here.
2. Section 3.5 - change "co-contributor" to "co-Contributor" (I think
this one slipped through as it's the latter everywhere else in the
document).
3. Section 4.2.(a) Shouldn't this grant also be irrevocable at least
for the life of the I-D? (The grant is irrevocable for IETF
Contributions and I can't think why it shouldn't be here as well).
4. Section 4.2.(a).B. The language "(other than translations)" makes
it sound as though ISOC/IETF expressly does _not_ have a right to do
translations with respect to RFC Editor Contributions. Is that the
intent? (If not, perhaps "to prepare or allow the preparation of
translations of the RFC Editor Contribution into languages other than
English" would play here like it does in 3.3.a(B) for IETF
Contributions.) A secondary note - there does not appear to be a
right to extract MIBs or PIBs from RFC Editor Contributions like
there is for IETF Contributions. Might this not be needed?
5. Section 7.5. In re-reading this provision, I am now wondering if
it is possible for this to be construed as cutting back on the rights
of implementors to copy, etc. parts of IETF RFCs to facilitate their
implementations. In conversations here, people thought about this in
the context of punycode but I'm sure there's tons of other places
this could be asked as well. The new, shortened Copyright notice in
Section 5.4 (which doesn't mention implementers as the existing
Copyright notice does) together with the new language here (which
expressly limits the beneficiaries of a Contributor's copyright
license to other IETF participants, but not to their employers) seems
like it could be read as restricting such implementer copying. I
don't remember any discussion of such a goal on the list, and so I'm
sort of wondering if this is an accidental side effect of the new
language that needs to be rectified - it seems a most undesireable
new limitation versus the rights that the current copyright notice
provides. (This may be a Jorge kind of question).
Again, sorry this is so long.
With sincere thanks for your consideration,
Valerie See