Subject: Last Call for Comments: Proposed work-around to the Pre-5378 Problem

From: Ed Juskevicius <[email-masked]>
Date: Fri, 6 Feb 2009 00:28:11 -0500

The IETF Trustees met via telechat on February 5th to decide on some
proposed revisions to the "Legal Provisions Relating to IETF Documents"
policy, based on comments received from the community in the last two
weeks.  Please recall this work is being done to provide a work-around for
authors having the 'pre-5378 problem'.

The telechat was productive.  The Trustees reached consensus to do the
following:

1)  Clarify the copyright text at the beginning of the BSD license in
Section 4.1 to read as follows:

Copyright (c) <insert year> IETF Trust and the persons identified as its
authors.  All rights reserved.
2)  Replace the word "and" by the word "or" in one place so that the last
sentence of Section 6.c.iii becomes:

Without obtaining an adequate license from the person(s) controlling the
copyright in such materials, this document may not be modified outside the
IETF Standards Process, and derivative works of it may not be created
outside the IETF Standards Process, except to format it for publication as
an RFC or to translate it into languages other than English.

3)  Fix some nits with respect to the inappropriate use of square brackets
'[' and ']' in two places.

The IETF Trust website has been updated with a new version of the draft
"Legal Provisions Relating to IETF Documents" including the changes
described in this message.  Please look for the documents dated 2009-02-05
at:
http://trustee.ietf.org/policyandprocedures.html .

If you have any final comments on this, please post them before the end of
February 7th.  This is the last call for comments.

Regards,

Ed Juskevicius, on behalf of the IETF Trustees
[email-masked]

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 06 Feb 2009 12:46:40 +0100

One comment, below:

> authors.  All rights reserved.

This doesn't work for me.  I read 'it' in the sentence above as referring
back to "IETF Trust" -- there's nothing else it can refer back to when
the code has been lifted out of the enclosing document, and complemented
by a license file holding the proposed license.  I propose instead:

    Copyright (c) <insert year> IETF Trust and the persons identified as
    authors of the code.  All rights reserved.

Best,

	Henrik

---

From: "Tom.Petch" <[email-masked]>
Date: Fri, 6 Feb 2009 13:57:38 +0100

Reading this, and reading it and reading it again, I think we are going
backwards more than is desirable where code is concerned.

I expect that for some years, the s.6.iii.c clause will be common ie no
derivative works outside the Standards process without obtaining an adequate
licence.  The s.5.c clause then explains this as meaning that the IETF Trust
will not grant such rights without obtaining sufficient rights to do so from the
person controlling the pre-5378 material. This seems to trump the additional
rights granted for code in s.4.

Where code is concerned, IETF counsel has stated that RFC3978 already gives us
such rights for code, in response to which Simon Joseffson has pointed out
clauses which might be construed differently to which counsel has agreed it
could be clearer but has not changed his advice (eg IPR WG July 2006).

My lay reading of this new text is that it does not give us an exemption for
code or if it does, then it does so even more obscurely than RFC3978 does and
this I would regard as a retrograde step.  It seems to depend on the reading of
"unless and until it has obtained sufficient rights to do so" while the request
to clearly identify pre-5378 material is likely to put the wrong attribution on
code for which the RFC3978 licence currently applies.

My particular concern is MIB modules.

Apologies for the to/cc list, most of which will generate bounces, but the
legally correct thing to do seems to be to leave it unchanged, at least for a
first iteration.

Tom Petch

----- Original Message -----
From: "Ed Juskevicius" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: "Trustees" <[email-masked]>; "Contreras,Jorge"
<[email-masked]>
Sent: Friday, February 06, 2009 6:28 AM
Subject: Last Call for Comments: Proposed work-around to the Pre-5378 Problem

---

From: TSG <[email-masked]>
Date: Fri, 06 Feb 2009 07:10:50 -0800

Ed Juskevicius wrote:
> proposed revisions to the "Legal Provisions Relating to IETF 
> Documents" policy, based on comments received from the community in 
> the last two weeks.  Please recall this work is being done to provide 
> a work-around for authors having the 'pre-5378 problem'.
>
> its authors.  All rights reserved.
>
ALL of those owning IP Rights then must also be listed or at the very 
least this creates a responsibility on the IETF to properly manage those 
contact addresses in perpetuity.
>
> 2)  Replace the word "and" by the word "or" in one place so that the 
> last sentence of Section 6.c.iii becomes:
>
> Without obtaining an adequate license from the person(s) controlling 
> the copyright in such materials, this document may not be modified 
> outside the IETF Standards Process, and derivative works of it may not 
> be created outside the IETF Standards Process, except to format it for 
> publication as an RFC or to translate it into languages other than 
> English.
How would this process be done then? What is the liability and what is 
the actual process that needs to be put in place to satisfy 'reasonable 
diligence' in the use of the IETF IP's???
>
> 3)  Fix some nits with respect to the inappropriate use of square 
> brackets '[' and ']' in two places.
>
>
> The IETF Trust website has been updated with a new version of the 
> draft "Legal Provisions Relating to IETF Documents" including the 
> changes described in this message.  Please look for the documents 
> dated 2009-02-05 at:
> If you have any final comments on this, please post them before the 
> end of February 7th.  This is the last call for comments.
>
>
> Regards,
>
>
> [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Thomas Narten <[email-masked]>
Date: Fri, 06 Feb 2009 10:30:32 -0500

A couple of issues with the motivating text:

> Derivative Works and Publication Limitations.  If a Contributor
> desires to limit the right to make modifications and derivative
> works of an IETF Contribution, or to limit its publication, one of
> the following notices must be included.

For cases i) (publication as RFC only) and ii) (publication only as
ID), the above is fine, because "the Contributor" refers to the author
of the document.

But for case iii), there are two "contributors" at issue. The one
submitting the document, and possible pre-5378 contributors who's text
has been included in the document.

For case iii), it should remain clear that the document
author/contributor is agreeing to the full 5378 coverage for his/her
contribution (made subequent to 5378), but that they take no position
regarding the pre-5378 text that may have been incorporated.

Thus:

> iii. If a Contribution includes Pre-5378 Material and the
>  Contributor does not wish to allow modifications of such Pre-5378
>  Material to be made outside the IETF Standards Process:

"does not wish" is not right. The issue is that the current author of
the document is unable (for whatever reason) to make assertions about
the pre-5378 material.

The actual text that goes into the contribution under this condition
seems OK, but the motivating text needs to be fixed to make the intent
clear.

I'd suggest:

Old:

> Derivative Works and Publication Limitations.  If a Contributor
> desires to limit the right to make modifications and derivative
> works of an IETF Contribution, or to limit its publication, one of
> the following notices must be included.

New

	c. Derivative Works and Publication Limitations.  If a
	Contributor desires to limit its publication, or the
	Contribution includes pre-5378 Material that limits the right
	to make modifications and derivative works of an IETF
	Contribution, one of the following notices must be included.
	The notices set forth in clauses (i) and (ii) below may not be
	used with any standards-track document, nor with most working
	group documents.

and

OLD:

> iii. If a Contribution includes Pre-5378 Material and the
>  Contributor does not wish to allow modifications of such Pre-5378
>  Material to be made outside the IETF Standards Process:

NEW:

    iii. If a Contribution includes Pre-5378 Material and the
    Contributor is unable (for whatever reason) to obtain the
    necessary permissions to allow modifications of such Pre-5378
    Material to be made outside the IETF Standards Process:

Thomas

---

From: John C Klensin <[email-masked]>
Date: Fri, 06 Feb 2009 11:10:59 -0500

--On Friday, February 06, 2009 10:30 -0500 Thomas Narten
<[email-masked]> wrote:

> But for case iii), there are two "contributors" at issue. The
> one submitting the document, and possible pre-5378
> contributors who's text has been included in the document.
>...
> author/contributor is agreeing to the full 5378 coverage for
> his/her contribution (made subequent to 5378), but that they
> take no position regarding the pre-5378 text that may have
> been incorporated.
>...

Yes.  I thought I pointed this distinction out weeks ago, but
perhaps I'm losing my mind.  The goal is not to exempt authors
from asserting their own compliance to 5378, but to avoid their
having to make any assertions on behalf of others (or even to
explicitly identify those other beyond our normal requirements
for acknowledgement).

     john

---

From: "Ed Juskevicius" <[email-masked]>
Date: Fri, 6 Feb 2009 11:18:41 -0500

Agreed.  Good comments!   Thank You.

Best Regards,

Ed  J.

-----Original Message-----
From: John C Klensin [mailto:[email-masked]] 
Sent: February 6, 2009 11:11 AM
To: Thomas Narten; Ed Juskevicius
Cc: Trustees; [email-masked]; Contreras, Jorge; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Re: Last Call for Comments: Proposed work-around to the Pre-5378
Problem

     john

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 06 Feb 2009 19:18:11 +0100

> rights granted for code in s.4.

I agree.  But that is true only for document that exercises the
pre-RFC5378 rule, which in the long term, from what I understand, will
be the exception rather than the rule.  There is nothing we can do about
pre-RFC 5378 contributions except to ask the authors to release more
rights to their work.

> could be clearer but has not changed his advice (eg IPR WG July 2006).

RFC 5378 makes the code licensed under a free software compatible
license, i.e., the BSD license.  The RFC 3978 rights, even if they were
granted to third parties, were evaluated by the FSF to be non-free.  I
haven't seen anyone claim that the RFC 3978 is a useful software
license.  Thus, RFC 5378 is considerably better than RFC 3978 for code.

> this I would regard as a retrograde step.

I disagree.  The legal provisions from the Trust seems clear to me that
code can be extracted and used under the BSD license.  This is a
considerably step forward, and the rules around it does not strike me as
obscure.  I wish the rules were less complex, but section 4 of the legal
provisions seems relatively low-complex compared to the rest.

/Simon

---

From: Ray Pelletier <[email-masked]>
Date: Fri, 6 Feb 2009 13:32:05 -0500

> regarding the pre-5378 text that may have been incorporated.

Agreed.  Good point.
>    Material to be made outside the IETF Standards Process:

The language suggests a tasking to obtain 5378 licenses from  
contributors
of pre-5378 material.  I think that is something we want to avoid.  I  
think the following
language obtains the same results but with less stress on the  
participants.

iii. If a Contribution includes Pre-5378 Material for which the
    Contributor of the pre-5378 material has not or may not have  
granted the
    necessary permissions to the IETF Trust to allow modifications of  
such Pre-5378
    Material to be made outside the IETF Standards Process:

Ray

> Trustees mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trustees

---

From: Thomas Narten <[email-masked]>
Date: Fri, 06 Feb 2009 14:02:08 -0500

Ray,

> contributors of pre-5378 material.  I think that is something we
> want to avoid.  I think the following language obtains the same
> results but with less stress on the participants.

I agree, but that might also be seen to be getting closer to
overruling what RFC 5378 says, something that I understand to be out
of scope.

>     granted the necessary permissions to the IETF Trust to allow
>     modifications of such Pre-5378 Material to be made outside the
>     IETF Standards Process:

IMO, this is improved wording I support it.

Thanks,
Thomas

---

From: Ray Pelletier <[email-masked]>
Date: Fri, 6 Feb 2009 14:49:27 -0500

On Feb 6, 2009, at 6:46 AM, Henrik Levkowetz wrote:

>> Documents"

This works for me.

Ray

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 6 Feb 2009 15:20:48 -0500

On Feb 6, 2009, at 2:57 PM, Sandra Murphy wrote:

>
>
> On Fri, 6 Feb 2009, Ray Pelletier wrote:
>
>>
> code?

This is Section 4.1, which is the BSD "License to Code Components. "

Regards
Marshall

> --Sandy

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 06 Feb 2009 21:50:37 +0100

>>    authors of the code.  All rights reserved.

I don't have a problem with this version.

/Simon

---

From: "Contreras, Jorge" <[email-masked]>
Date: Sun, 8 Feb 2009 17:24:21 -0500

Sorry for jumping into this thread late, but I would recommend leaving
6.c and 6.c.iii as proposed in the TLP draft that was circulated.

6.c.iii

> the document is unable (for whatever reason) to make assertions about

I think "does not wish" is right, as it gives the new Contributor
maximum flexibility in withholding the right to make non-IETF derivative
works if his Contribution includes pre-5378 Material.  I don't see any
of the proposed changes making this clearer or better.  

PROPOSED

> >     modifications of such Pre-5378 Material to be made outside the

This language seems unnecessarily dense, and since it includes "may
not", it has the same effect as "does not wish", doesn't it?  In other
words, if a Contribution includes pre-5378 Material, the (new)
Contributor should have the absolute discretion whether or not to
withhold the derivatives right and should not have to make any kind of
legal determination whether or not the old Contributor has granted
necessary permissions.

6.c

OLD

c. Derivative Works and Publication Limitations.  If a Contributor
desires to limit the right to make modifications and derivative
works of an IETF Contribution, or to limit its publication, one of
the following notices must be included.

PROPOSED
> 	used with any standards-track document, nor with most working

Same issue (other than the problem that there is no antecedent to the
pronoun "its" in line 2).  Using "that limits" in line 3 implies that
the new Contributor must make a legal determination about the rights in
pre-5378 Material, which I do not think is the desired approach.

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Thomas Narten
> Sent: Friday, February 06, 2009 2:02 PM
> To: Ray Pelletier
> Cc: Trustees; [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [Trustees] Last Call for Comments: Proposed 
> work-around to thePre-5378 Problem
> 
> Ray,
> 
> > > NEW:
> > >

---

From: John C Klensin <[email-masked]>
Date: Sun, 08 Feb 2009 17:38:10 -0500

--On Sunday, February 08, 2009 5:24 PM -0500 "Contreras, Jorge" 
<[email-masked]> wrote:

> Sorry for jumping into this thread late, but I would recommend
> leaving 6.c and 6.c.iii as proposed in the TLP draft that was
> circulated.
>
> 6.c.iii
>
>> OLD:
>>
>> >  Contributor does not wish to allow modifications of such
>> >  Pre-5378 Material to be made outside the IETF Standards
>> >  Process:
>>
>> "does not wish" is not right. The issue is that the current
>> author of the document is unable (for whatever reason) to
>> make assertions about the pre-5378 material.
>
> I think "does not wish" is right, as it gives the new
> Contributor maximum flexibility in withholding the right to
> make non-IETF derivative works if his Contribution includes
> pre-5378 Material.  I don't see any of the proposed changes
> making this clearer or better.
>...

Jorge,

I think people are trying to make two specific points.  If you 
tell us that both are irrelevant, then I, for one, will accept 
that and move on.  The points are:

(1) This language should not let a submitting author (a term 
that is a tad more precise than "Contributor" for this purpose, 
but substitute as you like) off the hook for compliance with the 
letter and intent of 5378 for his or her one new, post 
whenever-November-10-is, contribution.  If the Note Well, or 
5378 itself, or something else, takes care of that regardless of 
what the workaround text says, it would be helpful to clarify 
that somewhere.

(2) As a submitting author, I may be so convinced that 5378 is a 
wonderful thing that I would dearly wish, with all of my might, 
that I could offer a document in full compliance with its text 
and intent.  But I may just not have enough rights to do that 
(something wishing is unlikely to cure)  and hence have to opt 
for IETF use only.   Some of us would like to avoid an assertion 
that we "wish" to not provide the broader rights as it may be 
counterfactual.   That distinction may make absolutely no 
difference from an IPR standpoint, but some of us have an 
allergy to IETF procedural rules that require people to assert 
things that aren't true.

    john

---

From: SM <[email-masked]>
Date: Sun, 08 Feb 2009 16:03:51 -0800

>6.c and 6.c.iii as proposed in the TLP draft that was circulated.

[snip]

>of the proposed changes making this clearer or better.

I'm writing this in plain English.  The trustees can convert it to legalese.

The new Contributor is using text from pre-5378 Material in a 
document after RFC 5378 was published.  The text was only available 
for reuse within the IETF Standards Process as the Contributor has 
not been given rights according to RFC 5378 from the author of that 
text for reasons stated previously.

The new Contributor would like to say that the document contains 
Pre-5378 Material and he/she can only give rights for modifications 
within the IETF Standards Process.  The new Contributor is unable to 
give any rights for non-IETF derivative works as that falls outside 
the Internet Standards Process.

This is not about the new Contributor "does not wish" or "elects" to 
withhold the rights as he/she does not have a choice in the matter.

Regards,
-sm

---

From: John C Klensin <[email-masked]>
Date: Sun, 08 Feb 2009 20:02:26 -0500

--On Sunday, February 08, 2009 4:03 PM -0800 SM 
<[email-masked]> wrote:

>...
> The new Contributor would like to say that the document
> contains Pre-5378 Material and he/she can only give rights for
> modifications within the IETF Standards Process.  The new
> Contributor is unable to give any rights for non-IETF
> derivative works as that falls outside the Internet Standards
> Process.

Not quite, and I think this is where some of us are getting 
confused.

(1) The IETF should be utterly indifferent to what the new 
Contributor "likes", "wishes", or even "feels affection for".

(2) The new Contributor does not have discretion as to whether 
5378 applies to the new parts of the work.   It does.  Full 
stop.  The only question is when 5378 became sufficiently 
effective to be relevant to this.

(3) The submitting author (who will usually be the same person 
as the new Contributor) is simply unable to make any assertions 
at all about the rights to older material in the document other 
than that it is available for use in the IETF process.

(4) Your last sentence above would be correct if it said 
"...give any rights _to the complete document and all of its 
elements_...".

The key here is clearly what the submitting author(s) are "able" 
to do, not what they "wish", "elect", "would be willing to do if 
they could", etc.

> This is not about the new Contributor "does not wish" or
> "elects" to withhold the rights as he/she does not have a
> choice in the matter.

yea, except that the new Contributor cannot "withhold" anything 
either.  He or she can't even guarantee that 5378 rights are not 
available.  All the new Contributor knows is the he or she 
doesn't inherently have those rights to grant the trust to grant 
to others.

    john

---

From: Ray Pelletier <[email-masked]>
Date: Sun, 8 Feb 2009 20:33:06 -0500

One more clarification ...
On Feb 8, 2009, at 5:24 PM, Contreras, Jorge wrote:

> <snip>

>> 	used with any standards-track document, nor with most working

The 'or' clause requires a certainty that the Legend at 6.c.iii does  
not require.
I think it should read:

or the Contribution includes pre-5378 Material that limits
s/limits/ may limit
the right to make modifications and derivative works of an IETF
Contribution, one of the following notices must be included.

Ray

---

From: "Contreras, Jorge" <[email-masked]>
Date: Mon, 9 Feb 2009 12:29:13 -0500

Ok, I think (hope) I understand the intention now.  How about the
following as a friendly clarifying amendment to the proposed text:

Proposed Yesterday:

c. Derivative Works and Publication Limitations.
If a Contributor desires to limit its publication, or the
Contribution includes pre-5378 Material that may limit the right
to make modifications and derivative works of an IETF
Contribution, one of the following notices must be included.
The notices set forth in clauses (i) and (ii) below may not be
used with any standards-track document, nor with most working
group documents.

The "Proposed Yesterday" text blurs the distinction between c.i/ii
and c.iii.  I think that this could be done more clearly, as suggested
in NEW PROPOSED below.  In the first sentence of c, the old concept of
clauses
i and ii is preserved.  The new concept in iii is treated in the next
sentence.

NEW PROPOSED

c. Derivative Works and Publication Limitations.  If a Contributor
desires to limit the right to make modifications and derivative works
of, or to publish, an IETF Contribution that is not a standards-track
document or, in most cases, a working group document, then one of the
notices in clause (i) or (ii) below must be included.  If an IETF
Contribution contains pre-5378 Material as to which the IETF Trust has
not been granted, or may not have been granted, the necessary
permissions to allow modification of such pre-5378 Material outside the
IETF Standards Process, then the notice in clause (iii) may be included
by the Contributor of such IETF Contribution to limit the right to make
modifications to such pre-5378 Material outside the IETF Standards
Process.

NEW PROPOSED c.iii. introduction (Notice stays the same)

For consistency and clarity the introduction to c.iii is made to conform
with 6.c as follows

iii. If an IETF Contribution contains pre-5378 Material as to which the
IETF Trust has
not been granted, or may not have been granted, the necessary
permissions to allow modification of such pre-5378 Material outside the
IETF Standards Process:

> From: SM [mailto:[email-masked]] 
> Sent: Sunday, February 08, 2009 7:04 PM
> To: Contreras, Jorge
> Cc: Trustees; [email-masked]
> Subject: RE: [Trustees] Last Call for Comments: Proposed

---

From: John C Klensin <[email-masked]>
Date: Mon, 09 Feb 2009 13:01:44 -0500

Jorge,

Yes, that takes us much closer, perhaps all the way there, at 
least for the purposes of this workaround/patch.

IMO, at least.
     john

--On Monday, February 09, 2009 12:29 PM -0500 "Contreras, Jorge" 
<[email-masked]> wrote:

> Ok, I think (hope) I understand the intention now.  How about
> the following as a friendly clarifying amendment to the
> proposed text:
>...
> NEW PROPOSED
>
> Contributor desires to limit the right to make modifications
> and derivative works of, or to publish, an IETF Contribution
> that is not a standards-track document or, in most cases, a
> working group document, then one of the notices in clause (i)
> or (ii) below must be included.  If an IETF Contribution
> contains pre-5378 Material as to which the IETF Trust has not
> been granted, or may not have been granted, the necessary
> permissions to allow modification of such pre-5378 Material
> outside the IETF Standards Process, then the notice in clause
> (iii) may be included by the Contributor of such IETF
> Contribution to limit the right to make modifications to such
> pre-5378 Material outside the IETF Standards Process.
>...

Much better.  This still, IMO, has the matter of discretion 
wrong (i.e., it does not appear to apply the extended 
modification rights even to the new material), but I think it is 
workable until we can really get things straightened out.

Note to anyone planning an IPR (or 5378-fixup) BOF for IETF 74: 
in the long term, the question of whether material created and 
contributed to the IETF after the effective date of 5378 can 
effectively be exempted from its key provisions by being used in 
a document containing pre-5738 material is going to be 
important.  Indeed, it is a key part of determining how long the 
long term will have to extend.  Jorge's text above seems to fuzz 
that issue over which, I believe, moves it onto the agenda of 
the BOF.

    john

---

From: SM <[email-masked]>
Date: Mon, 09 Feb 2009 10:57:46 -0800

>Ok, I think (hope) I understand the intention now.  How about the

John posted a reply ( 
http://www.ietf.org/mail-archive/web/ietf/current/msg55265.html ) to 
my message yesterday.  Although there hasn't been any discussion 
about the second item on his list, we agree that RFC 5378 applies to 
the new parts of the work.  I won't get into the details of that.  I 
think that items 1, 3 and 4 clearly spells out the intention.

>modifications to such pre-5378 Material outside the IETF Standards

As John said, the IETF is utterly indifferent to what the new 
Contributor desires.  Quoting him:

  'The key here is clearly what the submitting author(s) are "able" 
to do, not what
   they "wish", "elect", "would be willing to do if they could", etc. " '

Does your "If a Contributor desires to limit the right to make 
modifications ..." convey that?

The "an IETF Contribution that is not a standards-track document or, 
in most cases, a working group document" is not correct in my 
opinion.  Would it be possible to refer to the IETF Standards 
Process?  It is defined in RFC 3978.

Does the following convey the idea:

c. Derivative Works and Publication Limitations.  If a Contributor 
does not reasonably and personally know whether modifications and 
derivative works of pre-5378 Material can be made, or published, for 
contributions within the IETF Standards Process, then one of the 
following notices in clause (i) or (ii) below must be included.  If 
an IETF Contribution contains pre-5378 Material as to which the IETF 
Trust has not been granted, or may not have been granted, the 
necessary permissions to allow modification of such pre-5378 Material 
outside the IETF Standards Process, then the notice in clause (iii) 
may be included by the Contributor of such IETF Contribution to limit 
the right to make modifications to such pre-5378 Material outside the 
IETF Standards Process.

>permissions to allow modification of such pre-5378 Material outside the

That sounds fine.

Regards,
-sm

---

From: Ray Pelletier <[email-masked]>
Date: Mon, 9 Feb 2009 14:16:27 -0500

This works for me.

Ray

On Feb 9, 2009, at 1:01 PM, John C Klensin wrote:

> Jorge,
>
> Yes, that takes us much closer, perhaps all the way there, at least  
> for the purposes of this workaround/patch.
>
> IMO, at least.
>    john
>
>
>
> --On Monday, February 09, 2009 12:29 PM -0500 "Contreras, Jorge" <[email-masked] 
> > wrote:
>
> Much better.  This still, IMO, has the matter of discretion wrong  
> (i.e., it does not appear to apply the extended modification rights  
> even to the new material), but I think it is workable until we can  
> really get things straightened out.
>
> Note to anyone planning an IPR (or 5378-fixup) BOF for IETF 74: in  
> the long term, the question of whether material created and  
> effectively be exempted from its key provisions by being used in a  
> document containing pre-5738 material is going to be important.   
> Indeed, it is a key part of determining how long the long term will  
> have to extend.  Jorge's text above seems to fuzz that issue over  
> which, I believe, moves it onto the agenda of the BOF.
>
>   john
>

---

From: Thomas Narten <[email-masked]>
Date: Mon, 09 Feb 2009 17:26:57 -0500

> following as a friendly clarifying amendment to the proposed text:

Sorry, I'm still not happy with the proposed text. I think it is still
not clear. It is the simple English I have issue with. But maybe I
have just been looking at this too hard for too long now. :-(

> of,

Right. This presumably handles the case where the contributer doesn't
allow anything but publication as an ID. i.e., case (i)

> or to publish,

Publish as what? an RFC?

Also, now we are already getting ambiguous. I assume that "limit the
right to" prepends this, but this is not 100% clear. Maybe the
contributer only desires to "publish" the document. :-)

> an IETF Contribution that is not a standards-track
> document or, in most cases, a working group document,

I'm not sure why this text is needed actually. This text is really
supposed to point out that documents that don't allow the IETF the
right to produce derivative works can't normally be WG documents or
standards track. But that is an implication of the contributer
choosing to limit derivative works. Normally, the contributor is NOT
submiting a document with such a restriction because they wish that it
not be standards track or a WG document.

This clause has been in the document for sometime. I wonder if it is
even needed at all to address the motivation for using the modified
boilerplate. 

> then one of the
> notices in clause (i) or (ii) below must be included.

For the above text to be more clear, I'd suggest something like:

NEW PROPOSED

    c. Derivative Works and Publication Limitations.  If a Contributor
       desires to limit the right to make modifications and derivative
       works of an IETF Contribution, then one of the notices in
       clause (i) or (ii) below must be included. Note that a
       contribution with such a clause cannot become a Standards Track
       document or, in most cases, a working group document,

IMO, the specific clauses (i) and (ii) make it amply clear why one
would choose one or the other, so no additional elaboration is needed
above.

The rest of the proposed text:

	If an IETF Contribution contains pre-5378 Material as to which
	the IETF Trust has not been granted, or may not have been
	granted, the necessary permissions to allow modification of
	such pre-5378 Material outside the IETF Standards Process,
	then the notice in clause (iii) may be included by the
	Contributor of such IETF Contribution to limit the right to
	make modifications to such pre-5378 Material outside the IETF
	Standards Process.

is OK with me.

Thomas

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 9 Feb 2009 18:11:05 -0500

>       desires to limit the right to make modifications and derivative

s/desires/needs/

I don't think that "desires" is appropriate here - as John pointed  
out, the contributor has no discretion here, except for their  
judgement as to whether rights are available.

Regards
Marshall

---

From: Thomas Narten <[email-masked]>
Date: Mon, 09 Feb 2009 18:23:18 -0500

> judgement as to whether rights are available.

Actually, in this case, it is the submitters choice, since we are
talking about case (i) or (ii) (and not (iii) which has been the
challenging case).  And "desires" is the wording that has been used
here for a while. 

But that said, a more neutral term is fine by me, since the
motivations for needing to select this may vary.

How about "chooses"?

Thomas

---

From: "Contreras, Jorge" <[email-masked]>
Date: Mon, 9 Feb 2009 19:41:16 -0500

> From: Thomas Narten [mailto:[email-masked]] 
> Sent: Monday, February 09, 2009 6:23 PM
> To: Marshall Eubanks
> Cc: Contreras, Jorge; Trustees; SM; [email-masked]
> Contributor

"chooses" is fine with me

---

From: "Contreras, Jorge" <[email-masked]>
Date: Mon, 9 Feb 2009 19:43:52 -0500

>        document or, in most cases, a working group document,
That works for me.  For what it's worth, in clauses (i) and (ii) we were
just being deferential to that historical language, which has been
around since, I think 2026.  I'm all for clearing it up.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 10 Feb 2009 11:10:01 -0700

I've gotten a bit lost on all the changes. Would it be possible to  
send to the list a single email that summarizes the current proposed  
changes to the document published on the web sight? or just a new copy  
of the document?

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 10 Feb 2009 13:37:01 -0500

Dear Cullen;

On Feb 10, 2009, at 1:10 PM, Cullen Jennings wrote:

> changes to the document published on the web sight? or just a new  
> copy of the document?
>

See

Draft Legal Provisions Relating to IETF Documents after Community Last  
Call (2009-02-09)

in

http://trustee.ietf.org/policyandprocedures.html

Both redlined and a clean copy are provided, in both pdf and MS word  
for each.

Regards
Marshall

---

From: Ed Juskevicius <[email-masked]>
Date: Tue, 10 Feb 2009 13:48:47 -0500

Cullen, in answer to your question, Yes.

A penultimate draft of the proposed changes to the Legal Provisions
document is available from the IETF Trust website at
http://trustee.ietf.org/policyandprocedures.html

Please look at the version labelled:
  Draft Legal Provisions Relating to IETF Documents after Community Last
Call (2009-02-09)
FYI this draft is currently before the Trustees, for a decision by end of
tomorrow.  If the Trustees accept this draft, then two final edits will be
required to formally adopt this policy document.  The edits will be:

1) To finalize and identify the "Effective Date" in the title on page 1, and
2) To insert the effective date into the header information of pages 2-7 of
the document.

Regards,

Ed Juskevicius

On Tue, Feb 10, 2009 at 1:10 PM, Cullen Jennings <[email-masked]> wrote:

>
> I've gotten a bit lost on all the changes. Would it be possible to send to
> the list a single email that summarizes the current proposed changes to the
> document published on the web sight? or just a new copy of the document?
>
>
>>>>     desires to limit the right to make modifications
>>>>>
>>>> and derivative
>>>
>>> s/desires/needs/
>>>>
>>>

---

From: Ed Juskevicius <[email-masked]>
Date: Thu, 12 Feb 2009 19:53:04 -0500

I am pleased to announce that the IETF Trustees have just finished work on a
revision to our "Legal Provisions Relating to IETF Documents" policy.  The
revision includes optional new legend text in Section 6.c.iii of the
policy to serve as a work-around for people experiencing the "pre-5378
problem."

Please note the newly approved policy is dated 2009-02-12.  Please also note
that the Effective Date of this revised policy has been set to 2009-02-15.
The old policy (effective from November 10, 2008) remains in force until
00h00 UTC on February 15th.

The approved text is available now on IETF Trust website at
 http://trustee.ietf.org/policyandprocedures.html

Please look for the document dated 2009-02-12, just below the heading
labeled "DRAFT Policy and Procedures Being Developed."

On or shortly after February 15th, the Trust website will be updated so as
to archive all of the recent draft versions of the new policy, and to make
it easier to navigagte to the newly approved policy.

Please review the new policy so you are aware of the latest copyright
statements and other boilerplate legend text that will be required on
all contributions to the IETF starting on February 15, 2009.

Regards, and Thanks in advance,

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Fri, 13 Feb 2009 13:54:09 -0500

When will http://xml.resource.org/ and xml2rfc be updated to include
this?
 
Are there any changes we need to make to our input xml files?
 
- Wes

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ed Juskevicius
Sent: Thursday, February 12, 2009 7:53 PM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Cc: Trustees; Contreras,Jorge
Subject: Re: Last Call for Comments: Proposed work-around to the
Pre-5378 Problem

I am pleased to announce that the IETF Trustees have just finished work
on a revision to our "Legal Provisions Relating to IETF Documents"
policy.  The revision includes optional new legend text in Section
6.c.iii of the policy to serve as a work-around for people experiencing
the "pre-5378 problem."
 
Please note the newly approved policy is dated 2009-02-12.  Please also
note that the Effective Date of this revised policy has been set to
2009-02-15.  The old policy (effective from November 10, 2008) remains
in force until 00h00 UTC on February 15th.

 
On or shortly after February 15th, the Trust website will be updated so
as to archive all of the recent draft versions of the new policy, and to
make it easier to navigagte to the newly approved policy.

---

From: Ray Pelletier <[email-masked]>
Date: Fri, 20 Feb 2009 10:57:46 -0500

> When will http://xml.resource.org/ and xml2rfc be updated to include  

It is in work.  A precise date is uncertain today, but is anticipated  
early next week.
> Are there any changes we need to make to our input xml files?

Those instructions will be provided with the update.

Ray
Trustee
IAD

>
> - Wes
>
> From: [email-masked] [mailto:[email-masked]] On Behalf  
> Of Ed Juskevicius
> To: [email-masked]; [email-masked]; [email-masked]; [email-masked] 
> ; [email-masked]; [email-masked]
> I am pleased to announce that the IETF Trustees have just finished  
> work on a revision to our "Legal Provisions Relating to IETF  
> Documents" policy.  The revision includes optional new legend text  
> in Section 6.c.iii of the policy to serve as a work-around for  
> people experiencing the "pre-5378 problem."
>
> Please note the newly approved policy is dated 2009-02-12.  Please  
> also note that the Effective Date of this revised policy has been  
> set to 2009-02-15.  The old policy (effective from November 10,  
> 2008) remains in force until 00h00 UTC on February 15th.
>
> Please look for the document dated 2009-02-12, just below the  
> heading labeled "DRAFT Policy and Procedures Being Developed."
>
> On or shortly after February 15th, the Trust website will be updated  
> so as to archive all of the recent draft versions of the new policy,  
> and to make it easier to navigagte to the newly approved policy.
>
> Please review the new policy so you are aware of the latest  
> copyright statements and other boilerplate legend text that will be  
> required on all contributions to the IETF starting on February 15,  
> 2009.
>

---

From: John C Klensin <[email-masked]>
Date: Fri, 20 Feb 2009 15:20:03 -0500

--On Friday, February 20, 2009 10:57 -0500 Ray Pelletier
<[email-masked]> wrote:

>> When will http://xml.resource.org/ and xml2rfc be updated to
>> include   this?
> 
> It is in work.  A precise date is uncertain today, but is
> anticipated early next week.
>> 

Ray,

The problems that we would have if the decisions needed to build
tools were not available by the 15th or some earlier date were
discussed on the list, I believe in late January.   There were
some rather clear commitments that we would not have this
problem, i.e., that the ducks would be sufficiently lined up
that changes could be made and people could post documents with
the workaround not later than the 16th, if not earlier.  

So the announcement was made and, despite those commitments, the
ducks obviously were not lined up, the tools were not ready, and
we still can't, in practice, post drafts that need the
workaround text.  Even if we could cut and paste the text in, we
have no statements about where it goes or decisions/opinions
from Counsel as to whether it can be dropped into a random place
in the document or needs to be next to the front-matter
copyright statements.

And, today, you respond, not to that January discussion or the
associated commitments, but to a note posted last Friday... one
that it took you a week to get around to responding to when the
commitments indicated that we've have answers contemporary with
the announcement of the new text.

For all of the reasons cited in the January discussion, this has
gone far enough.  Independent of promises about what might get
done next week, I want to know --and I think the community is
entitled to know -- who is accountable.

     john

---

From: Ray Pelletier <[email-masked]>
Date: Fri, 20 Feb 2009 15:46:26 -0500

On Feb 20, 2009, at 3:20 PM, John C Klensin wrote:

> workaround text.

So, the Trustees went through a process of community review of the  
changes to the TLP
posted on 6 January that resulted in some good suggestions that led to  
iterations and
posting of changes on 22 Jan, 5 Feb, 9 Feb and finally 12 Feb.  They  
even caught where
a change was unintentionally made.

On 11 Feb I notified the 5 volunteers maintaining the tools and  
templates that the Trustees
were voting on what I expected to be the last set of changes; advised  
them of the changes and asked if they
could have the changes completed in a few days, e.g, 14 Feb.    I  
asked for estimated delivery dates.
Not all were able to get the changes made.  And as I said above I am  
uncertain as to the
final tools being completed, but anticipated next week.

>  Even if we could cut and paste the text in, we

Section 6b of the Policy says: The following text must be included on  
the first page of each IETF Document,
so I am not sure what the controversy is about.

> the announcement of the new text.

It has taken from last Friday to the other day to ascertain where the  
volunteers
stood in the process of updating those tools and templates.

Ray

---

From: John C Klensin <[email-masked]>
Date: Fri, 20 Feb 2009 16:06:36 -0500

Ray,

The expectation in that January discussion was that the Trustees
and IAOC were going to be proactive about this and take
responsibility to make sure things got done.   I don't consider
your "notifying the volunteers" and asking for a schedule to be
consistent with that.   They are, after all, volunteers.  

Indeed, if the IASA were taking this seriously, I would have
expected that you would approach the various maintenance groups
and said "look, we know that text is going to need to go in, and
go into this place, we just aren't sure about the text yet,
obtained the source code and patching instructions, and then
arranged for either the Secretariat or someone on a short-term
contract to be on standby to get those changes made.

Perhaps I'm the only one in the community who feels that way,
but I'd be a little surprised.

As far as the "where does it go" question, the answer may be
clear to you, but it apparently was not clear to the Trustee
Chair (and poster of the announcement) who, according to
comments on the XML2RFC list, apparently indicated that it would
be ok to put it at the end.  

I hope that there is real testing going on to verify that the
none of the relevant servers and connections will fail when the
load hits.  That is "real testing", and additional
configurations if needed, not your sending out a note indicating
that people should be aware of the risk.

Please recall that the supposed purpose of the IASA and its
current organizational model was to protect the IAB, IESG, and
the community from having to deal with these sorts of
administrative problems, and even more to protect against
depending on mad scrambles by volunteers to get things done in
order to prevent administrative  meltdowns.   If this is an
example, I don't think that is working out very well but, again,
maybe I'm the only member of the community who feels that way.

     john

--On Friday, February 20, 2009 15:46 -0500 Ray Pelletier
<[email-masked]> wrote:

>> So the announcement was made and, despite those commitments,
>> the ducks obviously were not lined up, the tools were not
>> ready, and we still can't, in practice, post drafts that need
>> the workaround text.
> 
> So, the Trustees went through a process of community review of
> the changes to the TLP
> posted on 6 January that resulted in some good suggestions
> that led to iterations and
> posting of changes on 22 Jan, 5 Feb, 9 Feb and finally 12 Feb.
> They even caught where
> On 11 Feb I notified the 5 volunteers maintaining the tools
> and templates that the Trustees
> were voting on what I expected to be the last set of changes;
> advised them of the changes and asked if they
> could have the changes completed in a few days, e.g, 14 Feb.
> I asked for estimated delivery dates.
> Not all were able to get the changes made.  And as I said
> above I am uncertain as to the
>> from Counsel as to whether it can be dropped into a random
>> place in the document or needs to be next to the front-matter
>> copyright statements.
> 
> Section 6b of the Policy says: The following text must be
> included on the first page of each IETF Document,
>> associated commitments, but to a note posted last Friday...
>> one that it took you a week to get around to responding to
>> when the commitments indicated that we've have answers
>> contemporary with the announcement of the new text.
> 
> It has taken from last Friday to the other day to ascertain
> where the volunteers
>> For all of the reasons cited in the January discussion, this
>> has gone far enough.  Independent of promises about what
>> might get done next week, I want to know --and I think the
>> community is entitled to know -- who is accountable.
>> 
>> 
>>     john
>> 
>> 
>> 
>> 
>> 
>> 
>

---

From: "Ed Juskevicius" <[email-masked]>
Date: Fri, 20 Feb 2009 17:22:03 -0500

John, this is to respond to one of your points, below:

> comments on the XML2RFC list, apparently indicated that it
> would be ok to put it at the end.  

For the record, I received a question on January 23rd about whether it might
be better to move all of the copyright and associated boilerplate text
required on Contributions from the first page, to the back of every
document.  The basis of the question was that the length of the legal
statements needed on documents was growing, and it might not all fit neatly
at the front.

I replied on the same day.  I thanked the sender for the question, and took
an action to discuss this with the Trustees.  Please note that I did not
post this on the XML2RFC list, so you may be the victim of "here-say" in
this case.  Many things have transpired since January 23rd.  One is that I
failed to explicitly close the loop with the person who asked me if the
legal text might be moved to back matter.

We have had four revisions to the "Legal Provisions" policy since the first
call for community comments was posted on January 6th.  Two versions of the
draft were posted before January 23rd, two more were posted afterwards, and
then the last (fifth) revision is the one that was approved on February
12th, and made Effective as of February 15th.  The guidance with respect to
where legal text in Contributions is to appear was consistent in all of
these drafts.  Legal text is to appear in the front matter of Contributions.

Regards,

Ed Juskevicius

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John
C Klensin
Sent: February 20, 2009 4:07 PM
To: Ray Pelletier
Cc: Trustees; [email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: IASA irresponsibility? (was: Re: [IAB] [Trustees] LastCall for
Comments: Proposed work-around to the Pre-5378 Problem)

Ray,

     john

---

From: John C Klensin <[email-masked]>
Date: Fri, 20 Feb 2009 18:28:49 -0500

Ed,

I very much appreciate the clarification.  And, yes, I was
relying on my impression of what someone else reported on the
list, not on anything I heard directly from you.

Of course, that does not make me any happier with the
relationship between what I thought were commitments to have
tools, or a plan for using tools, in place, right after your
announcement appeared (originally committed for not later than
February 15, but posted on the 12th as you note) and Ray's note
today indicating "next week".

regards,
    john

--On Friday, February 20, 2009 17:22 -0500 Ed Juskevicius
<[email-masked]> wrote:

> For the record, I received a question on January 23rd about
> whether it might be better to move all of the copyright and
> associated boilerplate text required on Contributions from the
> first page, to the back of every document.  The basis of the
> question was that the length of the legal statements needed on
> documents was growing, and it might not all fit neatly at the
> front.
> 
> I replied on the same day.  I thanked the sender for the
> question, and took an action to discuss this with the
> Trustees.  Please note that I did not post this on the XML2RFC
> list, so you may be the victim of "here-say" in this case.
> Many things have transpired since January 23rd.  One is that I
> failed to explicitly close the loop with the person who asked
> me if the legal text might be moved to back matter.
> 
> We have had four revisions to the "Legal Provisions" policy
> since the first call for community comments was posted on
> January 6th.  Two versions of the draft were posted before
> January 23rd, two more were posted afterwards, and then the
> last (fifth) revision is the one that was approved on February
> 12th, and made Effective as of February 15th.  The guidance
> with respect to where legal text in Contributions is to appear
> was consistent in all of these drafts.  Legal text is to
> appear in the front matter of Contributions.
> 
> 
> Regards,
> 
> 
> Ed Juskevicius
> 
> 
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of John C Klensin
> Subject: IASA irresponsibility? (was: Re: [IAB] [Trustees]
> LastCall for Comments: Proposed work-around to the Pre-5378
> Problem)
> 
> Ray,
> 
> The expectation in that January discussion was that the
> Trustees and IAOC were going to be proactive about this and
> take responsibility to make sure things got done.   I don't
> consider your "notifying the volunteers" and asking for a
> schedule to be consistent with that.   They are, after all,
> volunteers.  
> 
> and said "look, we know that text is going to need to go in,
> and go into this place, we just aren't sure about the text yet,
> configurations if needed, not your sending out a note
> indicating that people should be aware of the risk.
> 
> example, I don't think that is working out very well but,
> again, maybe I'm the only member of the community who feels
> that way.
> 
>      john
> 
> 
>>> And, today, you respond, not to that January discussion or
>>> the associated commitments, but to a note posted last
>>> Friday... one that it took you a week to get around to
>>> responding to when the commitments indicated that we've have
>>> answers contemporary with the announcement of the new text.
>>

---

From: Julian Reschke <[email-masked]>
Date: Sun, 22 Feb 2009 13:30:16 +0100

Ray Pelletier wrote:
> could have the changes completed in a few days, e.g, 14 Feb.    I asked 
> for estimated delivery dates.

As one of these volunteers, I'm still waiting for clarifications on:

- where should the escape clause appear in an I-D (in "Status of this 
Memo", or in "Copyright Notice")?

- where should the escape clause appear in an RFC (in the "Copyright 
Notice" on the front page, or somewhere else?)?

- should authors be able to specify what variant of 6b ("and" vs "or") 
they want or should we just silently change it?

None of these are show stoppers, but I'd really appreciate not to have 
to figure that out myself.

BR, Julian

---

From: Ray Pelletier <[email-masked]>
Date: Sun, 22 Feb 2009 15:36:55 -0500

On Feb 22, 2009, at 7:30 AM, Julian Reschke wrote:

>> Not all were able to get the changes made.  And as I said above I  
>> am uncertain as to the
> - where should the escape clause appear in an I-D (in "Status of  
> this Memo", or in "Copyright Notice")?
Copyright Notice

> Notice" on the front page, or somewhere else?)?

Copyright Notice on the front page
>
>
> - should authors be able to specify what variant of 6b ("and" vs  
> "or") they want or should we just silently change it?

Do you mean in 6.c.i where it has the 'and' changed to 'or'?
If so, yes just silently change it.

Please advise if there are other questions.

Ray

>
>
> None of these are show stoppers, but I'd really appreciate not to  
> have to figure that out myself.
>
> BR, Julian

---

From: [email-masked]
Date: Mon, 23 Feb 2009 13:42:11 -0800 (PST)

> Ray and Trustees,

> Please note that this is exactly the sort of issue that I
> believed we had a commitment to have sorted out and in the hands
> of the tool maintainers by the 15th (or earlier).  It doesn't
> depend on the specific text to by used, so could, and IMO
> should, have been worked through in parallel with, or in advance
> of, any considerations of text.

> While getting things working is more important in the short term
> than understanding what happened here, I believe that the fact
> that fairly explicit commitments were made and then the ball was
> dropped is something that should be visible to the community and
> that calls for a review of the IASA's way of doing business.

+1

				Ned

---

From: Bob Hinden <[email-masked]>
Date: Tue, 24 Feb 2009 07:15:41 -0800

Bill,

> I believe this change from historic practice (moving ipr-related
> statements from "Status of this Memo" to "Copyright Notice") will
> require a new spin of the xml2rfc changes that I completed over the
> weekend.  Is this really a good change to make right now?

No, I think we should move forward with the current tool.  The  
deadline for publication for the San Francisco IETF is coming up soon  
and it's more important to get new Internet Drafts published than  
making the boiler plate formatting perfect.

Many thanks to you and others for doing the xml2rfc tool updated.

Bob

---

From: Bill Fenner <[email-masked]>
Date: Mon, 23 Feb 2009 12:18:40 -0800

> Please advise if there are other questions.

Section 6 requires that the text be included on the first page.  With
the 6.c.iii workaround, and the heretofore-standard page lengths, and
the 1id-guidelines-required text, several lines spill onto the second
page.

Ah, simplification, isn't it grand?

  Bill

---

From: Bill Fenner <[email-masked]>
Date: Mon, 23 Feb 2009 11:16:04 -0800

Bill

---

From: John C Klensin <[email-masked]>
Date: Mon, 23 Feb 2009 14:40:41 -0500

Ray and Trustees,

    john

--On Monday, February 23, 2009 11:16 -0800 Bill Fenner
<[email-masked]> wrote:

>>> - where should the escape clause appear in an I-D (in
>>> "Status of this Memo", or in "Copyright Notice")?
>> Copyright Notice
> 
> I believe this change from historic practice (moving
> ipr-related statements from "Status of this Memo" to
> "Copyright Notice") will require a new spin of the xml2rfc
> changes that I completed over the weekend.  Is this really a
> good change to make right now?
> 
>   Bill