![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
All;Several tools to publish Internet Drafts have implemented the IETF Trust's recent policy changes that provide a work-around to the issues raised by the inclusion of material from contributions published before 10 November 2008. You may have already been aware of one or more of the tools from other lists, or discussions on this list, but the Trust wanted to consolidate the information to ensure its general and aggregated availability, even at this time, just 24 hours before the -00 deadline for IETF 74.
If your Internet Draft contains pre-5378 Material as to which the IETF Trust has not been granted, or may not have been granted, the necessary permissions to allow modification of such pre-5378 Material outside the IETF Standards Process then section 6.c.iii from http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf must be included in the draft.
Volunteers who created and maintain the tools have implemented the updates:
1. idnits - (thanks Henrik Levkowetz) 2. Word template - (thanks Joe Touch) 3. xml2rfc - (thanks Bill Fenner and Marshall Rose) The tools can be found at: 1. idnits - http://tools.ietf.org/tools/ 2. Word template - http://tools.ietf.org/inventory/author-tools.shtml 3. xml2rfc - http://xml.resource.org/experimental.htmlA little more info on the xml2rfc variants (borrowed from Julian Reschke - thanks)
This version, v1.34pre3, implements the IETF Trust language of November, 2008 and
February, 2009.Briefly, you want to set the 'ipr' attribute of the <rfc/> element to one of these values:
trust200811 noModificationTrust200811 noDerivativesTrust200811 trust200902 noModificationTrust200902 noDerivativesTrust200902 pre5378Trust20090The final value in the list above is probably the one of interest to most folks.
At this point, only the *200902* variants should be relevant (not all of those changed from 200811, but we added all of them for consistency).(1) "trust200902" is the value to choose when no restrictions are being made.
(2) "noModificationTrust200902" adds "This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English." as defined in Section 6.c.i of <http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf>. (3) "noDerivativesTrust200902" adds "This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft." as defined in Section 6.c.ii of <http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf>. (4) "pre5378Trust200902" adds "This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English." as defined in Section 6.c.iii of <http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf>. This is the new variant that was introduced because of the problems discovered in November with RFC 5378. Ray
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.