Subject: Announcement of the new Trust Legal Provisions (TLP 4.0)

From: Marshall Eubanks <[email-masked]>
Date: Mon, 28 Dec 2009 14:22:26 -0500

Season's Greetings!

This message is to announce that the IETF Trustees have adopted
on a new version of the Trust Legal Provisions (TLP), to be effective 28
December, 2009. The Grace period for old-boilerplate will begin on  
that date,
and last through 1 February, 2010.

The new document updating the Trust Legal Provisions is available in  
PDF and HTML formats from

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

and the PDF version is available directly at

http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf .

Please note that this URL always points to the current TLP. A
stable URI for the TLP effective 28 December, 2009 is

http://trustee.ietf.org/docs/IETF-Trust-License-Policy-20091228.pdf  .

The new document updating the Trust Legal Provisions was approved by the
Trustees after a consideration of "last call" comments in a telechat on
December 17, 2009, subject to there being no further substantive  
public comments.

Informally, this version has been referred to as "TLP Version 4.0."
The requests for comments for this change were issued on November 25,  
2009
4:34:48 PM EST in a message entitled "Request for comments on proposed  
changes
to the IETF Trust Legal Provisions (TLP)." An editorial change to this  
document
was proposed on December 7, 2009, 4:23:24 PM EST in a message entitled  
"Proposed
Editorial Change to the Legal Provisions Relating to IETF Documents  
(TLP)."

The Trustees would like to thank everyone who participated in the  
vigorous
discussion about these changes.

Regards
Marshall Eubanks
Chair / IETF Trust

---

From: Julian Reschke <[email-masked]>
Date: Tue, 29 Dec 2009 00:11:59 +0100

Marshall Eubanks wrote:
> ...
> December, 2009. The Grace period for old-boilerplate will begin on that 
> date,
> ...

So, unless xml2rfc gets updated in time, people using that tool won't be 
able to submit Internet Drafts after February 1 without additional 
post-processing? Why the early cut-over date, compared to the last 
change (which had a 2+ month transition period)????

Best regards, Julian

---

From: Sam Hartman <[email-masked]>
Date: Mon, 28 Dec 2009 22:02:08 -0500

>>>>> "Julian" == Julian Reschke <[email-masked]> writes:

    Julian> Marshall Eubanks wrote:
    >> ...  This message is to announce that the IETF Trustees have
    >> adopted on a new version of the Trust Legal Provisions (TLP), to
    >> be effective 28 December, 2009. The Grace period for
    >> old-boilerplate will begin on that date, and last through 1
    >> February, 2010.  ...

    Julian> So, unless xml2rfc gets updated in time, people using that
    Julian> tool won't be able to submit Internet Drafts after February
    Julian> 1 without additional post-processing? Why the early cut-over
    Julian> date, compared to the last change (which had a 2+ month
    Julian> transition period)????

I'd like to take this a step further: why do we need to update our
boiler plate at all?  It's my understanding that the incoming rights
have not been changed at all here; that should and I think does require
a BCP.

The trust is updating what rights they give others outside the IETF
process.  I guess Ic can see why that might affect the boiler plate the
RFC editor uses.  However, I don't understand why I as an internet draft
author should have to join the boiler plate of the month club.  I
thought one reason we set up the inbound vs outbound split was to avoid
exactly this sort of mess.

--Sam

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 29 Dec 2009 16:55:19 +1300

>     Julian> transition period)????

Wait, I had assumed that the grace period had been negotiated
with the tools maintainers. If not, the Trustees need to hold
that negotiation and then adjust the grace period accordingly.
I thought we had learned the hard way to do this every time.

(Hence I have with some reluctance added to the cross-posting
of this thread.)

> exactly this sort of mess.

My understanding, as a bystander, is that we really couldn't achieve
that state of nirvana until the recent batch of related RFCs was out
(5741 through 5745), so that all the streams, and not just the IETF
stream, are covered.

    Brian

---

From: [email-masked]
Date: Tue, 29 Dec 2009 08:47:01 -0800 (PST)

> exactly this sort of mess.

+1

				Ned

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 30 Dec 2009 11:00:58 -0500

On Dec 28, 2009, at 6:11 PM, Julian Reschke wrote:

> So, unless xml2rfc gets updated in time, people using that tool  
> won't be able to submit Internet Drafts after February 1 without  
> additional post-processing? Why the early cut-over date, compared to  
> the last change (which had a 2+ month transition period)????
>

Because it was the date you suggested in your email December 2, 2009  
10:00:47 AM EST :

>
> For rfc2629.xslt, the answer is "I'd prefer not to". The reason  
> being that cutover dates on day 1 of a month will be much easier to  
> maintain in the long term, and also I'd like to see all boilerplate  
> related changes (see draft-iab-streams-headers-boilerplates-08)  
> being done at the same time. So for rfc2629.xslt, I'd potentially  
> support a cutover date for *both* on Feb 01.

If we need more time, we can certainly do this, however I raised this  
issue with the tools team a month ago and February 1 was the latest  
date suggested.

Regards
Marshall

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 Dec 2009 17:21:45 +0100

Marshall Eubanks wrote:
>> For rfc2629.xslt, the answer is "I'd prefer not to". The reason being 
>> that cutover dates on day 1 of a month will be much easier to maintain 
>> in the long term, and also I'd like to see all boilerplate related 
>> changes (see draft-iab-streams-headers-boilerplates-08) being done at 
>> the same time. So for rfc2629.xslt, I'd potentially support a cutover 
>> date for *both* on Feb 01.
> 
> issue with the tools team a month ago and February 1 was the latest date 
> suggested.
> ...

Yes, I stated that for *rfc2629.xslt*. What you seem to miss is that we 
need somebody to make the change in xml2rfc as well, and right now, that 
code is looking for a new maintainer (reminder: TCL code).

Best regards, Julian