Hi - Forwarded for your information. Randy ----- Original Message ----- > From: "Marshall Eubanks" <tme at americafree.tv> > To: <tlp-interest at ietf.org> > Cc: "Trustees" <trustees at ietf.org>; "Working Group Chairs" <wgchairs at ietf.org>; "Internet Research Steering Group" <irsg at isi.edu>; "RFC Interest" <rfc-interest at rfc-editor.org> > Sent: Wednesday, January 13, 2010 3:47 AM > Subject: Boilerplate changes Required for TLP 4.0 > > 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 >
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.