To the members of the IESG (and to Scott Bradner, who's really
performed one of the labors of Hercules on these docs),
First, thank you for your consideration of my remarks upon the
previous drafts of these documents. These drafts are very close
and because it is hard to see the remaining changes/typos, I've
taken the liberty of attaching Word documents with revision marks
in hopes that this will be editorially useful. I've also added
some remarks in this cover note to explain in more depth some
of the points I'd noted in the documents.
>From my previous comments:
Valerie See <vsee@microsoft.com> wrote:
> 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.
[vsee] thank you for going over both docs on this issue. These revs
have all but about 1/3 of the original occurrences caught; the Word
docs I've attached flag with revisions the last ones that slid through.
> 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.
[vsee] Thanks again on this - I surmise that this was addressed via
changing "and" to "or" in the definition of "Contribution?" However,
this change only got made in tech-rights and didn't get made in
submission-rights, so it is also needed there. (Noted in the Word
docs as a suggested revision).
> 3. ... 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.
[vsee] I've marked this as a suggested change in the attached
Word documents - this edit wasn't made in this revision and
although it is a lower priority, I think it does help with the
clarity.
> In tech-rights alone:
>
> 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."
[vsee] Thank you very much for this change. There is a minor
typo in the new text ("participants" should be "participant")
that I've flagged in the attached Word doc.
> 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).
[vsee] I'm sorry to ask about this, but I'm really curious if it's
intentional that third party IPR disclosures are only encouraged
for IETF Contributions, and not RFC Editor Contributions. Based on
the text remaining unchanged in this draft, I assume that this is
the case, but why is the standard different between these two cases?
> 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).
[vsee] I'm happy to have this practice be the rule, but I am still
concerned that people may be caught on the horns of a dilemma between
this doc and the Brim guidelines document. Is there any way to harmonize
the guidance - perhaps by having the Brim document conform to the
guidance in this document?
> 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.)
[vsee] Thanks for the "in an" fix, but I think the other change is
still needed to clarify that this is about Contributors and their
own Contributions - I've flagged this in the attached Word doc.
> 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_.
[vsee] Similarly, this change is also needed to make it clear that this
section addresses Participants and situations involving the
Contributions of third parties that may implicate IP of the
Participant (or their represented company, or whatever). I've also
flagged this in the attached Word document.
> 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.....)
[vsee] Again, I am sorry to ask about this one, but I think this
particular issue really _is_ critically important. The reason I say
this is that the omission of the language about RAND leaves the door
open for blanket statements that are _only_ royalty free, and that
might have other, _non-RAND_ terms and conditions (such as those
you might see associated with commercial licenses in a non-standards
sort of transactional relationship - which might be perfectly fine in
those types of circumstances, but which may not be at all what one
would hope to see in a standards context). In this case, adding the
text about "and under other reasonable and non-discriminatory terms and
conditions" provides a level of clarity that I think strikes the
balance that you are seeking to protect both the interests of
implementers and IPR holders in the standards-setting work that is
done in the IETF.
> Submission-rights:
>
> 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?
[vsee] I'm sorry to ask, but could I understand why this is the
way it is? I know it was not changed in this draft, but rather than
just proposing language, I'm wondering if there is a nuance here
that I'm just not understanding?
> 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).
[vsee] Apologies again for asking to understand the thinking here,
but noticing that this didn't change in this draft, I was hoping to
understand why you aren't seeing this as a problem for implementers?
To revisit this, what I'm concerned about, and am trying to ensure,
is that the new shortened copyright notice in Section 5.4, coupled
with this Section 7.5 is not read as narrowing the rights of
implementers. In this regard, it's useful to recall that the prior
copyright notice in RFC 2026 stated "This document and translations
of it may be copied and furnished to others, and derivative works that
comment on or otherwise explain it _or assist in its implementation_
[[vsee] my emphasis] may be prepared, copied, published and distributed,
in whole or in part, without restriction of any kind, provided that the
above copyright notice and this paragraph are included on all such
copies and derivative works." The current language seems to restrict
much more tightly the rights of implementers. If that is not the intent,
perhaps one way to address this would be to add the following at the
end of 7.5: "Nothing herein shall prohibit any implementer of an IETF
specification from using all or a part of an Internet-Draft or RFC to
assist it in such implementation."
Many thanks again for your attention,
-- Valerie See
Attachment:
draft-ietf-ipr-submission-rights-08.doc
Description: draft-ietf-ipr-submission-rights-08.doc
Attachment:
draft-ietf-ipr-technology-rights-12.doc
Description: draft-ietf-ipr-technology-rights-12.doc