Subject: copyright boilerplate for independent submissions

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 09 Aug 2007 09:28:49 -0600

When attempting to submit several non-WG I-Ds recently, I discovered
that xml2rfc produces copyright boilerplate that the Secretariat finds
unacceptable. The offending text seems to be:

"and at http://www.rfc-editor.org/copyright.html"

Bill Fenner suggests [1] that this construct was "accidentally outlawed"
when RFC 3978 was published, and that fixing the problem is presumably a
work item of the IPR WG. Is this indeed an active work item? (The
xml2rfc workaround -- removing submissionType='independent' in the XML
source -- seems to defeat the purpose of flagging the submission type.)

Thanks!

Peter

[1]
http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/2007-August/003155.html

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

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 09 Aug 2007 20:27:12 +0200

Making it possible to fix the boilerplate requirements without issuing a 
new RFC is indeed part of what we hope to achieve with the documents now 
in front of this WG. I hope our currently proposed text achieves that.
We're not trying to fix any specific problem with the existing procedure.

                   Harald

Peter Saint-Andre wrote:
> ------------------------------------------------------------------------
>

---

From: "todd glassey" <[email-masked]>
Date: Thu, 9 Aug 2007 11:42:31 -0700

The problem there is that the Boiler Plate on previously issued documents is 
what is in force regarding their licensing, use and control, so when the 
plating is changed, it would be of value to reissue those flawed RFC's with 
the same RFC Numbers and updated boilerplate. Otherwise, it makes the 
process of separating rights/process vs. content a pain in the lower 
backside.

T.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Aug 2007 09:38:11 +0200

> We're not trying to fix any specific problem with the existing procedure.

I agree with that, but...

>> when RFC 3978 was published, 

I'm not sure it was an accident. I suspect there was concern
about creating legal ambiguity by citing two different sets of rules
without stating which one takes precedence in case of conflict.
When the Trust composes the future boilerplate, they'll need
to consider this.

     Brian

>> and that fixing the problem is presumably a

---

From: "Bill Fenner" <[email-masked]>
Date: Sat, 11 Aug 2007 17:22:05 -0400

> without stating which one takes precedence in case of conflict.

While this may have been true of RFC 3667, the RFC Editor noted this
problem during the AUTH48 of RFC 3978, brought it up via Harald, and
the WG came to consensus on the updated wording.  The RFC was
subsequently published without the words the WG agreed upon.

I'm not interested in rehashing history, but I do think that the
current state of affairs is different than the RFC Editor desires and
also different than what the WG had consensus on at the time.

  Bill

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Aug 2007 10:25:12 +0200

Bill,

> also different than what the WG had consensus on at the time.

I think that now we have some clarity on what should (not) go into
I-Ds, it's easier to understand how we can end up with appropriate
text in RFCs too. We've agreed to punt the wording to the Trust,
but it seems that for non-IETF RFCs there is a need for words that
(a) assert appropriate rights for the Trust,
(b) cite RFC Editor rules that apply to non-IETF documents,
and (c) state which rules take precedence in case of ambiguity.

Do you think we need some text about this in one of the drafts?

    Brian

---

From: "todd glassey" <[email-masked]>
Date: Wed, 15 Aug 2007 07:56:57 -0700

There is a problem... more inline below.

----- Original Message ----- 
From: "Brian E Carpenter" <[email-masked]>
To: "Bill Fenner" <[email-masked]>
Cc: "Harald Alvestrand" <[email-masked]>; <[email-masked]>
Sent: Wednesday, August 15, 2007 1:25 AM
Subject: Re: copyright boilerplate for independent submissions

> and (c) state which rules take precedence in case of ambiguity.

There is a simple question to answer here - what is the purpose of an I-D? 
is it to introduce some IP to the IETF? If so then the I-D should not be a 
referencable document for any purpose other that the advancement of the 
IETF's Standard's process relative to that initiative. I-D's should NOT 
replace RFC's and as such RFC's should be the ONLY documents published with 
Free Use Rights attached (if that was the Intent), otherwise the power of 
the IETF's processes are wasted IMHO.

> Do you think we need some text about this in one of the drafts?

yes...

But there is a bigger issue here and that is that ONLY standards track 
documents should go into the Trust. The Trust is NOT the receptical for 
BCP's and ION's per se, since many of them may pertain to the IETF itself 
and the Trust's purpose is to protect and develop the Intellectual 
Properties developed.

Instead, what placing these documents into the Trust with the same use 
provisio's as the technical IP does is allows anyone else to copy the IETF 
itslef and publish IETF documents outside the IETF itself since those 
documents (like BCP78 and BCP79 for instance) are exactly RFC's which are 
licensed 'for any and all uses'.

Its arguable that by publishing the IETF's Templates for any and all uses 
that it also gave away a license to use the TM's as well meaning that the 
IETF CANNOT STOP ANYONE FROM ePUBLISHING A DOCUMENT AND CLAIMING ITS AN IETF 
DOCUMENT. Nice move that eh? Seriously, my take is that by doing this, the 
IETF has created a situation where ANYONE can self-publish a RFC or IETF 
submission outside of the Editor's and the IETF has nothing to say about it 
anymore. Again - Nice move eh?

FWIW - I brought this up several times before and Harald, you had me thrown 
out of the IPR-WG group for a month for it too, and you are still wrong 
about this.  That said, maybe the Group would like to review this concept 
now, and possibly maybe even make a determination as to whether it thinks I 
am right or not...

The model I propose is simple. The IETF's licenses for technologies should 
not extend to the IETF's internal or external processes, and they do because 
this WG (and Harald) insisted on making those additions to those processes 
under the RFC publishing provisions already on file. Hence the new rules can 
be used for any and all uses by anyone forever...

Based on that the IETF cannot even stop others from publishing what would be 
'official IETF Documents' which must only meet the same publication 
requirements as are defined by the templates. Worse - those outsides can 
publish those documents under RFC2026 now too whether the IETF likes it or 
not and so they dont have to obey the conveyance to the IETF that BCP78 
demands.

What needs to be done is the following:

    1)    BCP78 is amended to reflect that:
            a)    Only the IETF and its Publishing Agent may publish IETF 
Drafts and IETF RFC's
            b)    IETF IP License Rules DO NOT APPLY to the IETF Workflow 
and Operations Rules, but rather ONLY to the work product submitted for 
publication to the IETF as part of a Network Technologies or Protocol 
Initiative. As such the IETF itself and NOT THE TRUST retains any and all 
rights to 'IETF Process Models' and the Intellectual Property implementing 
them. meaning that BCP78 and 79 as well as the related documents stay the 
property of the IETF and not the IETF's Trust.

    2)    BCP79 is amended to reflect that:
            a)    That IETF process IP is not licensed for use by anyone 
outside of the IETF's operations and that the outgoing license does not 
reflect 'any and all uses' for the IETF's operations documents but rather 
only for Standards Initiative materials (primary filings and supporting 
filings)
            b)    That for any and all IP's developed or passed through the 
IETF for standardization post-approval for BCP79 (i.e. after BCP79 was 
approved) are totally controlled by those IETF IP Management Documents 
superseeding RFC2026, and that while RFC2026 is still in publication, it is 
no longer a controlling document.

Nice move eh? [Jorge? as the IETF's lawyer and someone skilled in writing 
contracts, do you have any comments?]

Todd Glassey

---

From: "Bill Fenner" <[email-masked]>
Date: Mon, 20 Aug 2007 08:15:34 -0400

On 8/15/07, Brian E Carpenter <[email-masked]> wrote:
> We've agreed to punt the wording to the Trust,

-incoming is quite confusing in this regard.  It changes the
definition of "IETF Document" to no longer exclude what 3978 calls
"RFC Editor Documents", but then in section 4 says that different
rules apply to RFC Editor Documents.  However, section 6 seems to lay
out rules for "IETF Document"s, which from the definitions section
includes RFC Editor Documents.

Perhaps I'm just used to the 3978 terminology but I think -incoming as
it stands now is not very clear about which set of rules apply
(although both section 4 and section 6 refer to the Legend
Instructions, so perhaps it's OK to be confusing as long as the Legend
Instructions aren't).

  Bill

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Aug 2007 12:44:28 +0200

Bill,

> Instructions, so perhaps it's OK to be confusing as long as the Legend

I think you're correct that there's an inconsistency between section 4
and section 6. Probably something is needed in s.6 to resolve this,
e.g. after the second paragraph:

In the case of Internet-Drafts intended to become RFC Editor documents
(see Section 4) the Legend Instructions should be developed in agreement
with the RFC Editor, but should include conditional statements allowing
for the case where such a draft is later approved by the IETF itself.

    Brian

---

From: John C Klensin <[email-masked]>
Date: Wed, 22 Aug 2007 08:15:47 -0400

--On Tuesday, 21 August, 2007 12:44 +0200 Brian E Carpenter
<[email-masked]> wrote:

>...

Brian,

As should be evident from the recent debate on the IETF list
over draft-hartman-webauth-phishing, there is no consensus that
approval of publication of an informational RFC by the IESG (aka
"on the IETF track") is "approval by the IETF".  I have argued
elsewhere, as have others, that "approval by the IETF" requires
a Last Call.  IESG approval of documents for IESG-sponsored
informational publication has not traditionally required an IETF
Last Call, although the IESG certainly has the option of
conducting one.  The  more recent debate over
draft-hartman-webauth-phishing indicates that some members of
the community believe that such a Last Call must explicitly
indicate that it is a call for consensus if there is to be any
claim of "IETF approval" or "IETF endorsement".

So, while I don't disagree with the principle behind your
suggestion above, any wording along those lines would need to be
_very_ carefully constructed... and the wording in your note is
certainly not either sufficient or appropriate.

best,
     john

---

From: Russ Housley <[email-masked]>
Date: Wed, 22 Aug 2007 15:06:33 -0400

Current practice (as documented in an ION) is to issue a Last Call 
for all Informational documents that as sponsored by an AD.  There is 
an exception for documents that come from the IRTF via the IRSG, and 
there is a document in the works to describe that situation.

Russ

At 08:15 AM 8/22/2007, John C Klensin wrote:
>I have argued
>conducting one.

---

From: John C Klensin <[email-masked]>
Date: Wed, 22 Aug 2007 17:03:24 -0400

--On Wednesday, 22 August, 2007 15:06 -0400 Russ Housley
<[email-masked]> wrote:

> Current practice (as documented in an ION) is to issue a Last
> Call for all Informational documents that as sponsored by an
> AD.  There is an exception for documents that come from the
> IRTF via the IRSG, and there is a document in the works to
> describe that situation.

Russ, while I think this is worthwhile, I will note, as others
have, that a call for comments is different from a call for
consensus.  The IAB has issued calls for comments, sometimes as
a notice of intent to publish, on many or all of its documents
for some time, but still publishes them as IAB documents, not
IETF ones.  Unless IESG is going to start issuing consensus
calls, or rejecting the AD sponsorship and leaving the document
to the author and RFC Editor unless a clear IETF consensus
emerges, I don't think these calls change the key issue.

     john

---

From: "TS Glassey" <[email-masked]>
Date: Wed, 22 Aug 2007 14:42:06 -0700

----- Original Message ----- 
From: "John C Klensin" <[email-masked]>
To: "Brian E Carpenter" <[email-masked]>; "Bill Fenner" 
<[email-masked]>
Cc: "Harald Alvestrand" <[email-masked]>; <[email-masked]>
Sent: Wednesday, August 22, 2007 5:15 AM
Subject: Re: copyright boilerplate for independent submissions

> "on the IETF track") is "approval by the IETF".

OK let me ask then "Why is the IESG approving ANYTHING?" are they not 
servents to the process and not the other way around? That said - the IETF 
itself shouldnt be approving anything except as "compliant to the IETF's 
processes". If the IETF or IESG become 'approvers of the technology included 
in any posting' then their arm's length from the content of their 
publications evaporates and this creates all kinds of liabiltiy and process 
issues which the IETF's current oversight doesnt address.

> claim of "IETF approval" or "IETF endorsement".

Again the IETF and its parental orgs afe not endorsers of any specific 
technology and when they become such they lose their objective distance from 
that IP and become liable to other's who's IP was not given the same 
endorsement within the IETF. That said, the simple way to protect oneself 
from that liability is to not endorse anything except as 'being complaint to 
the IETF's process and standards milestone requirements'.

All a  concensus call means really then is "the working group is done with 
some formal round of vetting/re-engineering and that the IP is to be 
submitted to the IESG for verification that those milestone requirement were 
functionally and mechanically met", and that is symbolic (and possibly 
contractually too) of that the WG has fulfulled the requirements of that 
standards process model such that this IP is ready for executive review by 
the IESG.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Aug 2007 09:06:41 +0200

John,

I agree that my text needs wordsmithing for consistency
with the broader definitions in the RFC 4844/45/46 series.
I'm otherwise occupied right now, so feel free to
rewrite.

    Brian

---

From: Russ Housley <[email-masked]>
Date: Thu, 23 Aug 2007 11:25:56 -0400

John:

I suppose that different ADs had different concerns, but the point is 
that people have the opportunity to voice support and concern, even 
for documents that are going to be published an Informational.  I 
recognize that standards-track and BCP documents require rough 
consensus, while other categories do not.

Russ