copyright boilerplate for independent submissions

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/piperma
il/xml2rfc/2007-August/003155.html



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

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:
> 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/piperma
il/xml2rfc/2007-August/003155.html
>
>
>   
>
------------------------------------------------------------
------------
>
> _______________________________________________
> Ipr-wg mailing list
> Ipr-wgietf.org
> https:/
/www1.ietf.org/mailman/listinfo/ipr-wg
>   


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

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.
----- Original Message ----- 
From: "Harald Alvestrand" <haraldalvestrand.no>
To: "Peter Saint-Andre" <stpeterjabber.org>
Cc: <ipr-wgietf.org>
Sent: Thursday, August 09, 2007 11:27 AM
Subject: Re: copyright boilerplate for independent
submissions


> 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:
>> 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/piperma
il/xml2rfc/2007-August/003155.html
>>
>>
>>  
------------------------------------------------------------
------------
>>
>> _______________________________________________
>> Ipr-wg mailing list
>> Ipr-wgietf.org
>> https:/
/www1.ietf.org/mailman/listinfo/ipr-wg
>>
>
>
> _______________________________________________
> Ipr-wg mailing list
> Ipr-wgietf.org
> https:/
/www1.ietf.org/mailman/listinfo/ipr-wg 


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

On 2007-08-09 20:27, Harald Alvestrand wrote:
> 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.

I agree with that, but...

> 
>                   Harald
> 
> Peter Saint-Andre wrote:
>> 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, 

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
>> 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/piperma
il/xml2rfc/2007-August/003155.html
>>
>>
>>   
>>
------------------------------------------------------------
------------
>>
>> _______________________________________________
>> Ipr-wg mailing list
>> Ipr-wgietf.org
>> https:/
/www1.ietf.org/mailman/listinfo/ipr-wg
>>   
> 
> 
> _______________________________________________
> Ipr-wg mailing list
> Ipr-wgietf.org
> https:/
/www1.ietf.org/mailman/listinfo/ipr-wg
> 

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

On 8/10/07, Brian E Carpenter <brian.e.carpentergmail.com> wrote:
> > Peter Saint-Andre wrote:
> >> Bill Fenner suggests [1] that this construct
was "accidentally outlawed"
> >> 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.

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

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

Bill,

On 2007-08-11 23:22, Bill Fenner wrote:
> On 8/10/07, Brian E Carpenter <brian.e.carpentergmail.com> wrote:
>>> Peter Saint-Andre wrote:
>>>> Bill Fenner suggests [1] that this
construct was "accidentally outlawed"
>>>> 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.
> 
> 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.

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

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

There is a problem... more inline below.

----- Original Message ----- 
From: "Brian E Carpenter"
<brian.e.carpentergmail.com>
To: "Bill Fenner" <fennergmail.com>
Cc: "Harald Alvestrand" <haraldalvestrand.no>; <ipr-wgietf.org>
Sent: Wednesday, August 15, 2007 1:25 AM
Subject: Re: copyright boilerplate for independent
submissions


> Bill,
>
> On 2007-08-11 23:22, Bill Fenner wrote:
>> On 8/10/07, Brian E Carpenter
<brian.e.carpentergmail.com> wrote:
>>>> Peter Saint-Andre wrote:
>>>>> Bill Fenner suggests [1] that this
construct was "accidentally 
>>>>> outlawed"
>>>>> 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.
>>
>> 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.
>
> 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.

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

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


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

On 8/15/07, Brian E Carpenter <brian.e.carpentergmail.com> wrote:
> 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?

-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

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

Bill,

On 2007-08-20 14:15, Bill Fenner wrote:
> On 8/15/07, Brian E Carpenter <brian.e.carpentergmail.com> wrote:
>> 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?
> 
> -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).

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





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

--On Tuesday, 21 August, 2007 12:44 +0200 Brian E Carpenter
<brian.e.carpentergmail.com> wrote:

>...
> 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,

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


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