Subject: Boilerplate changes Required for TLP 4.0

From: Marshall Eubanks <[email-masked]>
Date: Wed, 13 Jan 2010 06:47:32 -0500

Colleagues,

Some concerns have been raised about tooling issues and boilerplate  
changes. At present, for example, xml2rfc is not supported, and  
because of this it is not clear when it will be possible to update it  
to support the new boilerplate.  However, Alternate Stream documents  
have been blocked for some time waiting for the new Trust Legal  
Provisions (TLP), and it was decided to unblock these documents with  
TLP 4.0 even in the absence of xml2rfc support. (There is an open call  
for volunteers to support xml2rfc, and I would encourage interested  
parties to contact Russ Housley.)

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
     NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in
     RFC 2119.

If for any reason the tool of your choice has not been upgraded by the  
end of the grace period on February 1 then the following two minor  
changes need to be made to Internet-Draft boilerplates before  
submission. Note that the changes are different for IETF Stream and  
for Alternate Stream Documents. The changes for the IETF stream are  
editorial (as noted by a SHOULD in the text below) and drafts produced  
by the current tools for that stream are therefore compliant with TLP  
4.0.  The changes for the other streams are required (as noted by a  
MUST in the text below).

-----

For IETF Stream Documents the following changes SHOULD be made :

Change 1 :
OLD:
This Internet-Draft is submitted to IETF in full conformance with the  
provisions of BCP 78 and
BCP 79.

NEW:
This Internet-Draft is submitted in full conformance with the  
provisions of BCP 78 and BCP 79.

EXPLANATION:
Dropped the words "to IETF" as there is some ambiguity with respect to  
Internet drafts that are not submitted to be published as IETF Stream  
RFCs.

Change 2 :

Second : Different Treatment for IETF and non-IETF stream documents  
regarding potential BSD licenses for code components.

OLD:
Code Components extracted from this document must include Simplified  
BSD License text as described in Section 4.e of the Trust Legal  
Provisions and are provided without warranty as described in the BSD  
License.

NEW:
Code Components extracted from this document must include Simplified  
BSD License text as described in Section 4.e of the Trust Legal  
Provisions and are provided without warranty as described in the  
Simplified BSD License.

EXPLANATION: Introduction of the word "Simplified" at the second use  
of "BSD License" for clarity.

-----

For Alternate Stream Documents the following changes MUST be made

Change 1 :
OLD:
This Internet-Draft is submitted to IETF in full conformance with the  
provisions of BCP 78 and
BCP 79.

NEW:
This Internet-Draft is submitted in full conformance with the  
provisions of BCP 78 and BCP 79.

EXPLANATION:
Dropped the words "to IETF" as there is some ambiguity with respect to  
Internet drafts that are not submitted to be published as IETF Stream  
RFCs.

Change 2 :

OLD:
Code Components extracted from this document must include Simplified  
BSD License text as described in Section 4.e of the Trust Legal  
Provisions and are provided without warranty as described in the BSD  
License.

NEW: This sentence must not be included (note that this text MUST NOT  
be inserted in the document).

EXPLANATION: The BSD license is not available for code components from  
Alternate Stream documents.

Regards
Marshall Eubanks

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Jan 2010 09:16:58 +1300

I don't think the Trust has got the message.

The message is that the grace period needs to be extended until
the tools are ready, as far as drafts are concerned.

It's fine for the RFC Editor to make these changes in the final
text, which the authors will accept by saying OK to the AUTH48 ping.
But seriously expecting drafts to be munged this way, especially during
the last minute panic before the cut-off dates, is just not OK.

Shall we discuss this on the ietf list?

Regards
   Brian Carpenter

On 2010-01-14 00:47, Marshall Eubanks wrote:
> changes. At present, for example, xml2rfc is not supported, and because
> of this it is not clear when it will be possible to update it to support
> the new boilerplate.  However, Alternate Stream documents have been
> blocked for some time waiting for the new Trust Legal Provisions (TLP),
> and it was decided to unblock these documents with TLP 4.0 even in the
> absence of xml2rfc support. (There is an open call for volunteers to
> support xml2rfc, and I would encourage interested parties to contact
> Russ Housley.)
> 
> submission. Note that the changes are different for IETF Stream and for
> Alternate Stream Documents. The changes for the IETF stream are
> 4.0.  The changes for the other streams are required (as noted by a MUST
> in the text below).
> 
> -----
> 
> This Internet-Draft is submitted in full conformance with the provisions
> of BCP 78 and BCP 79.
> 
> EXPLANATION:
> Internet drafts that are not submitted to be published as IETF Stream RFCs.
> 
> Change 2 :
> 
> Code Components extracted from this document must include Simplified BSD
> License text as described in Section 4.e of the Trust Legal Provisions
> and are provided without warranty as described in the BSD License.
> 
> NEW:
> Code Components extracted from this document must include Simplified BSD
> License text as described in Section 4.e of the Trust Legal Provisions
> and are provided without warranty as described in the Simplified BSD
> License.
> 
> EXPLANATION: Introduction of the word "Simplified" at the second use of
> "BSD License" for clarity.
> 
> -----
> 
> This Internet-Draft is submitted in full conformance with the provisions
> of BCP 78 and BCP 79.
> 
> EXPLANATION:
> Internet drafts that are not submitted to be published as IETF Stream RFCs.
> 
> Change 2 :
> 
> OLD:
> Code Components extracted from this document must include Simplified BSD
> License text as described in Section 4.e of the Trust Legal Provisions
> and are provided without warranty as described in the BSD License.
> 
> NEW: This sentence must not be included (note that this text MUST NOT be
> inserted in the document).
> 
> _______________________________________________
> tlp-interest mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tlp-interest
>

---

From: Russ Housley <[email-masked]>
Date: Wed, 13 Jan 2010 16:42:07 -0500

Brian:

The most recent approved changes do not prevent the posting of I-Ds. 
For this reason, I do not understand your comments.

The most recent changes allow non-IETF stream RFCs to include different 
license for code; they rejected the Simplified BSD license that the 
tools team recommended to the Trust for the IETF stream.  I-Ds for these 
streams can be posted using the earlier boilerplate, as they have been 
for the last several months.  When the tools are updated, I-Ds for these 
alternate streams will have alternate boilerplate if they wish to use 
it, but they will not be required to use it to get their I-D posted.

Russ

---

From: Bob Hinden <[email-masked]>
Date: Wed, 13 Jan 2010 13:50:09 -0800

Brian,

On Jan 13, 2010, at 1:42 PM, Russ Housley wrote:

> Brian:
> 
> The most recent approved changes do not prevent the posting of I-Ds. For this reason, I do not understand your comments.

This is stated in the end of the third paragraph:

>>> The changes for the IETF stream are

It may have been better to make this clearer at the top of the email, and possibly in all caps.

Or am I misinterpreting you comments?

Bob

> 
> The most recent changes allow non-IETF stream RFCs to include different license for code; they rejected the Simplified BSD license that the tools team recommended to the Trust for the IETF stream.  I-Ds for these streams can be posted using the earlier boilerplate, as they have been for the last several months.  When the tools are updated, I-Ds for these alternate streams will have alternate boilerplate if they wish to use it, but they will not be required to use it to get their I-D posted.
> 
> Russ
> 
> Trustees mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trustees

---

From: Henk Uijterwaal <[email-masked]>
Date: Thu, 14 Jan 2010 10:20:31 +0100

Brian,

> the tools are ready, as far as drafts are concerned.

For the IETF stream, the changes are a SHOULD and the current tools
produce drafts that are acceptable.  This effectively extends the
grace period forever.   For other documents, I think all contributors
are capable to make a quick hack in the TCL code and have it print the
right text until there is a version of xml2rfc that does this in a
nice way.

Henk

-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.xs4all.nl/~henku
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

Nobody ever went broke underestimating the taste of the American public.
                                                                  H.L.Mencken

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Jan 2010 11:57:33 +1300

Russ,

I was going by what Marshall wrote:

> If for any reason the tool of your choice has not been upgraded by the end of the grace period on February 1 then the following two minor changes need to be made to Internet-Draft boilerplates before submission.

"need" reads more strongly than "SHOULD" to me. And in fact what you say is
not really a SHOULD; it's that IETF-stream submissions MAY ignore the changes,
which is much more acceptable.

Peace. But I think we need to discuss in the community once and for all
how to get a single, maintained tool for I-D production. Not easy, but
the current confusion is hurting us.

Regards
   Brian Carpenter

On 2010-01-14 10:42, Russ Housley wrote:
> Brian:
> 
> The most recent approved changes do not prevent the posting of I-Ds. For
> this reason, I do not understand your comments.
>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 14 Jan 2010 09:51:54 +0100

Russ Housley wrote:
> ...

Exactly *which* previous boilerplate?

The boilerplate as of 2009-02 can't be produced by xml2rfc.tcl for new 
IDs, as it decides on the boilerplate based on the publication date.

The boilerplate as of 2008-11 never could be produced by xml2rfc.tcl.

I may be missing something; maybe you should post a sample source for 
xml2rfc.tcl that produces the boilerplate that is needed?

Best regards, Julian

---

From: Lou Berger <[email-masked]>
Date: Tue, 19 Jan 2010 08:37:32 -0500

FYI -

The current version of idnits (rev 2.11.17 obtained today from 
http://tools.ietf.org/tools/idnits/idnits) still requires the old form
of the Section 6.a Notice of Compliance, i.e., "This Internet-Draft is 
submitted *to IETF*...".

Anyone know when idnits will be updated?

Lou

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 19 Jan 2010 15:49:47 +0100

Hi Lou,

> Anyone know when idnits will be updated?

I'm currently doing regression testing of 2.12.00 which should handle this
correctly.

Best,

	Henrik