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

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