Re: [tlp-interest] [Trustees] [IAB] Boilerplate changes Required for TLP 4.0

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

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
> 
> On 1/13/2010 3:16 PM, Brian E Carpenter wrote:
>> 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:
>>> 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
>>> 
>>> _______________________________________________
>>> tlp-interest mailing list
>>> tlp-interest@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tlp-interest
>>> 
>> 
> _______________________________________________
> Trustees mailing list
> Trustees@ietf.org
> https://www.ietf.org/mailman/listinfo/trustees