Subject: XML2RFC updated to latest Trust provisions

From: Tom Taylor <[email-masked]>
Date: Sun, 04 Apr 2010 20:54:42 -0400

The XML2RFC maintenance team has updated the tool so that the output contains 
the latest boilerplate and passes idNits. Thanks to Julian Reshke and Tony 
Hansen, with help from Henrik.

I am currently working on updating the templates at 
http://tools.ietf.org/tools/templates/ to reflect the latest ipr values.

Tom Taylor

---

From: Blake Ramsdell <[email-masked]>
Date: Mon, 5 Apr 2010 16:16:17 -0700

On Sun, Apr 4, 2010 at 5:54 PM, Tom Taylor <[email-masked]> wrote:
> The XML2RFC maintenance team has updated the tool so that the output
> contains the latest boilerplate and passes idNits. Thanks to Julian Reshke
> and Tony Hansen, with help from Henrik.

I'm not sure what's the right forum for this, and my apologies if this
has been covered. Public / private beatings welcome.

I have a WG member who relies on this tool for his drafts unable to
submit new versions until the tool was updated (submissions were
rejected due to old IPR statement).

Is there a plan to ensure that this doesn't happen again? And I'm not
trying to harp on the people maintaining the tool -- Tom, Julian,
Tony, I'm glad you put in the effort and were able to get the tool up
to date.

But it's not clear to me why we ended up in this state to begin with
-- shouldn't we keep the submission process compatible with the
current version of xml2rfc?

Blake

---

From: Tom Taylor <[email-masked]>
Date: Mon, 05 Apr 2010 19:43:57 -0400

XML2RFC was a volunteer development several years ago, and not part of the 
"official" IETF tool set. The original authors have wearied of the task. A new 
set of volunteers has moved in this year, set up a formal development 
environment (svn) on the the IETF tools web site, and will probably be good for 
a couple of years, anyway. We intend to keep tight version control, and the 
people doing the work will set the priorities.

There is an XML2RFC discussion list (list info at 
http://lists.xml.resource.org/mailman/listinfo/xml2rfc, 
mailto:[email-masked] to subscribe). I'm new to it 
myself, and haven't gotten around to looking at the archives to see what people 
said in the past.

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 5 Apr 2010 20:36:24 -0400

On Apr 4, 2010, at 8:54 PM, Tom Taylor wrote:

> contains the latest boilerplate and passes idNits. Thanks to Julian  
> Reshke and Tony Hansen, with help from Henrik.
>
> I am currently working on updating the templates at http://tools.ietf.org/tools/templates/ 
>  to reflect the latest ipr values.
>
> Tom Taylor
>

Thank you for your efforts here.

Regards
Marshall

---

From: "John R. Levine" <[email-masked]>
Date: 5 Apr 2010 21:28:45 -0400

> "official" IETF tool set. The original authors have wearied of the task. A 
> new set of volunteers has moved in this year, set up a formal development 
> environment (svn) on the the IETF tools web site, and will probably be good 
> for a couple of years, anyway. We intend to keep tight version control, and 
> the people doing the work will set the priorities.

Quite right.  The current volunteers seem to be doing a great job, so 
we're OK until life catches up with them.

>> Is there a plan to ensure that this doesn't happen again?

In a word, no.  Within the IETF, the line between what's volunteer and 
what's paid for has always been fuzzy, and the tools have been on the 
volunteer side.  It seems to me that it's past time to define a budget to 
pay people to support the tools on which the IETF depends, round up the 
money (probably a one page proposal to ISOC would do it) and make this a 
professional function, just like running the meetings is.

R's,
John

---

From: Tony Hansen <[email-masked]>
Date: Mon, 05 Apr 2010 23:17:15 -0400

Call it the perfect storm with multiple confluences conspiring against 
us: there were multiple changes to the boilerplates in a relatively 
short amount of time, the changes were not expressed in a way that was 
easily translated into terms needed for tool maintenance, the original 
author of the xml2rfc tool was getting tired of trying to keep up such 
"busy" work, there was no one readily available to pick up the gauntlet, 
and there was no established way for anyone else to deliver updates to 
the xml2rfc tool set.

We've now set up a core team of developers who are willing to work on 
the code, and we've set up the code as part of our ietf tools structure, 
so the xml2rfc tools cadre can change over time.

     Tony Hansen

On 4/5/2010 7:16 PM, Blake Ramsdell wrote:
> ... Is there a plan to ensure that this doesn't happen again? And I'm not

---

From: Brian Rosen <[email-masked]>
Date: Tue, 06 Apr 2010 07:32:47 -0400

Are you sure that your WG member didn't take the idnits warning as an error?

idnits has been noting the lack of the current IPR statement, but documents
have been accepted and posted with the IPR statements xml2rfc puts out.
That has been true at least up to deadline day last cycle, and probably
beyond.

The warning gets some people nervous, but documents go through.

There are a WHOLE LOT of people dependent on the tool these days.  If it
couldn't put out acceptable documents, there would have been a very large
hew and cry.

Brian

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 6 Apr 2010 09:12:00 -0400

> That has been true at least up to deadline day last cycle, and probably

Well, documents that were produced with the release candidate version
of xml2rfc could be posted.  You had to dig a little to find that out,
however, and I'm not entirely sure everyone knew it.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 06 Apr 2010 11:44:44 -0400

I think the question on the table is:
"Was is irresponsible of the IETF Trust to require submissions
with new templates, while the tools that most people use to
generate ID' had not been updated?".

	Olafur

On 05/04/2010 8:17 PM, joel jaeggli wrote:
> So, if you want to make sure that xml2rfc gets better than best effort service, you should communicate with the iaoc and the iad, that some of the tools budget is expended accordingly.
>
> I personally am shocked that the tool has keep up with with the document changes required since the process that produces the changes doesn't bear the cost (in human capital) associated with the reuirements they generate for the tool.
>
> Peace
> Joel
>
> Tom Taylor<[email-masked]>  wrote:
>
>>> On Sun, Apr 4, 2010 at 5:54 PM, Tom Taylor<[email-masked]>  wrote:

---

From: Joe Touch <[email-masked]>
Date: Tue, 06 Apr 2010 09:50:52 -0700

> generate ID' had not been updated?".

Nobody forces you to use any of the templates - XML, Word, or otherwise.

Yes, the IETF Trust should be more clear about what is actually needed
when they update the requirements; IMO, they should be *required* to
provide a sample txt of the desired result.

Joe

>> So, if you want to make sure that xml2rfc gets better than best effort
>> service, you should communicate with the iaoc and the iad, that some
>> of the tools budget is expended accordingly.
>>
>> I personally am shocked that the tool has keep up with with the
>> document changes required since the process that produces the changes
>> doesn't bear the cost (in human capital) associated with the
>> reuirements they generate for the tool.
>>
>> Peace
>> Joel
>>

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 6 Apr 2010 13:02:25 -0400

> provide a sample txt of the desired result.

This should probably be added to the Trust's procedures for modifying  
the TLP :

http://trustee.ietf.org/docs/Standard-Procedure-for-Modifying-the-TLP.txt

I will make sure this gets taken up.

Regards
Marshall

>>>> mailto:[email-masked] to subscribe). I'm  
>>>> new
>>>> to it

---

From: Tony Hansen <[email-masked]>
Date: Tue, 06 Apr 2010 13:09:16 -0400

Having an accurate sample of the desired result would have made life 
MUCH easier.

     Tony Hansen
     [email-masked]

---

From: Adam Roach <[email-masked]>
Date: Tue, 06 Apr 2010 12:14:31 -0500

+1

---

From: Joe Touch <[email-masked]>
Date: Tue, 06 Apr 2010 12:48:47 -0700

FWIW, here's the kind of sample txt I was thinking of, generated from
the current Word template I maintain.

Joe

>>>>> current version of xml2rfc?
<Working Group Name>                                <Initial. Lastname>
Internet Draft                                            <Affiliation>
Intended status: <e.g., Informational>                    April 6, 2010
Expires: October 2010

                                  <Title>
                     draft-ietf-wgname-docname-00.txt

   INFO (REMOVE): NOTE- remove all paragraphs with the label of this
   paragraph (including this one) after following instructions therein.

Status of this Memo

   INFO (REMOVE): Choose ONE of the following three paragraphs and omit
   others (see BCP 78 for explanation):

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

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79. 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.

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79. This document may not be modified,
   and derivative works of it may not be created, except to publish it
   as an RFC and to translate it into languages other than English.

   INFO (REMOVE): Leave in the following paragraph if this IETF
   Contribution 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 (see BCP 78 for explanation):

   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

<Lastname>             Expires October 6, 2010                 [Page 1]

Internet-Draft                 <Title>                       April 2010

   it for publication as an RFC or to translate it into languages other
   than English.

   INFO (REMOVE): Leave the remaining paragraphs (through to the
   copyright notice) unmodified.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on October 6, 2010.

Copyright Notice

   INFO (REMOVE): Leave the following paragraph unmodified.

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   INFO (REMOVE): Choose ONE of the following two paragrahs (see BCP 78
   for explanation):

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document. 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.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of

<Lastname>             Expires October 6, 2010                 [Page 2]

Internet-Draft                 <Title>                       April 2010

   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document.

Abstract

   <Type your abstract here. Typically 5-10 lines, never less than 3
   lines nor more than 20 lines>

Table of Contents

   1. Introduction...................................................3
   2. Security Considerations........................................3
   3. IANA Considerations............................................3
   4. Conclusions....................................................3
   5. References.....................................................4
      5.1. Normative References......................................4
      5.2. Informative References....................................4
   6. Acknowledgments................................................4
   Appendix A. First Appendix.............Error! Bookmark not defined.

1. Introduction

   <First section of text; add others as needed>

2. Security Considerations

   INFO (REMOVE):    Every draft MUST have a security section.

   <Add any security considerations>

3. IANA Considerations

   INFO (REMOVE):    Every draft MUST have an IANA section, although it
   may be removed prior to publication by the RFC Editor if null.

   <Add any IANA considerations>

4. Conclusions

   <Add any conclusions>

<Lastname>             Expires October 6, 2010                 [Page 3]

Internet-Draft                 <Title>                       April 2010

5. References

5.1. Normative References

   INFO (REMOVE): Normative refs are references to standards documents
   **required** to understand this doc. These are usually Standards-
   track and BCP RFCs, or external (IEEE, ANSI, etc.) standards, but
   may include other publications.

5.2. Informative References

   INFO (REMOVE):  Informative refs are those that are not standards or
   standards not required to understand this doc. These are usually
   informative RFCs, internet-drafts (avoid if possible), and other
   external documents.

6. Acknowledgments

   <Add any acknowledgements>

<Lastname>             Expires October 6, 2010                 [Page 4]

Internet-Draft                 <Title>                       April 2010

Appendix A.                 Sample Code

   INFO (REMOVE): The following 'abbreviated statement' or the
   subsequent 'full statement' are required if the document contains
   any code (see BCP 78 for further information). The first is an
   'abbreviated statement':

   Copyright (c) 2010 IETF Trust and the persons identified as authors
   of the code. All rights reserved.

   Redistribution and use in source and binary forms, with or without
   modification, is permitted pursuant to, and subject to the license
   terms contained in, the Simplified BSD License set forth in Section
   4.c of the IETF Trust's Legal Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info).

   INFO (REMOVE): or use this 'full statement' (through the end of this
   doc):

   Copyright (c) 2010 IETF Trust and the persons identified as authors
   of the code. All rights reserved.

   Redistribution and use in source and binary forms, with or without
   modification, are permitted provided that the following conditions
   are met:

   o  Redistributions of source code must retain the above copyright
      notice, this list of conditions and the following disclaimer.

   o  Redistributions in binary form must reproduce the above copyright
      notice, this list of conditions and the following disclaimer in
      the documentation and/or other materials provided with the
      distribution.

   o  Neither the name of Internet Society, IETF or IETF Trust, nor the
      names of specific contributors, may be used to endorse or promote
      products derived from this software without specific prior
      written permission.

   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
   FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
   COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
   INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
   BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
   LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER

<Lastname>             Expires October 6, 2010                 [Page 5]

Internet-Draft                 <Title>                       April 2010

   CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
   LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
   ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
   POSSIBILITY OF SUCH DAMAGE.

<Lastname>             Expires October 6, 2010                 [Page 6]

Internet-Draft                 <Title>                       April 2010

Authors' Addresses

   <Firstname> <Lastname>
   <Affiliation>
   <Address>

   Phone: <optional>
   Email: <Your email address>

   <Firstname> <Lastname>
   <Affiliation>
   <Address>

   Phone: <optional>
   Email: <Your email address>

<Lastname>             Expires October 6, 2010                 [Page 7]

---

From: Lars Eggert <[email-masked]>
Date: Wed, 7 Apr 2010 11:47:31 +0300

Hi,

> Is there a plan to ensure that this doesn't happen again?

it is always possible to edit the ASCII output generated by xml2rfc by hand in cases where it needs to be tweaked (e.g., when there is a new boilerplate text.) It's not ideal, but nobody is prevented from submitting IDs even when xml2rfc is a little bit behind.

Lars

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Apr 2010 10:12:11 -0400

> it is always possible to edit the ASCII output generated by xml2rfc by hand in cases where it needs to be tweaked (e.g., when there is a new boilerplate text.) It's not ideal, but nobody is prevent…

Yeah. But lets distinguish what is *possible* from what is *practical*.
Most people that I know of who submit drafts don't spend a lot of time 
tracking changes to the required boilerplate. Rather, there is an 
expectation that the tools will deal with it so we don't have to.

It would be much better to simply define what is required by what idnits 
allows, and refrain from releasing new restrictions in idnits until they 
are covered by xml2rfc.

	Thanks,
	Paul

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 7 Apr 2010 10:51:13 -0400

> allows, and refrain from releasing new restrictions in idnits until they  

I think it would be better to have a setting of ipr="current" for
xml2rfc that would allow the inclusion of whatever the "current"
boilerplate is.  At generation time, the tool could go and fetch the
boilerplate, maybe with a TTL so that it could cache its idea locally
(for offline operation).  If I knew anything at all about TCL, I might
even try to make a patch to do this, even though I'm maybe the worst
coder I know.  (My main point is that the tool ought not to have to
have the boilerplate "inside" it.  It should be able to include it
somehow.  That way if the boilerplate changes, the tool itself need
not be updated.)

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "David Harrington" <[email-masked]>
Date: Wed, 7 Apr 2010 10:56:40 -0400

The problem with your approach is that the copyright notice is
actually important, and it is important that editors know what it
says. Having the tool automatically insert a legal agreement between
the authors and the IETF without the authors bothering to read it is
not really a good thing.

dbh 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Wednesday, April 07, 2010 10:12 AM
> To: Lars Eggert
> Cc: Working Group Chairs
> Subject: Re: XML2RFC updated to latest Trust provisions
> 
> 
> 
> Lars Eggert wrote:
> > Hi,
> > 
> > it is always possible to edit the ASCII output generated by 
> xml2rfc by hand in cases where it needs to be tweaked (e.g., 
> when there is a new boilerplate text.) It's not ideal, but 
> nobody is prevented from submitting IDs even when xml2rfc is 
> a little bit behind.
>

---

From: Ray Pelletier <[email-masked]>
Date: Wed, 7 Apr 2010 11:00:19 -0400

> the authors and the IETF without the authors bothering to read it is

For an understanding of what "current" means perhaps there is a way to  
connect
  Current to the Current TLP at http://trustee.ietf.org/license-info/

Ray

---

From: "John R. Levine" <[email-masked]>
Date: 7 Apr 2010 11:04:45 -0400

> the authors and the IETF without the authors bothering to read it is

Why do you think that authors read the copyright notice now?  I just cut 
and paste whatever's necessary to make idnits stop complaining, which I 
expect is pretty typical.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

---

From: Al Morton <[email-masked]>
Date: Wed, 07 Apr 2010 11:04:58 -0400

>somehow.  That way if the boilerplate changes, the tool itself need
Along the same lines, why not a few "stable" sentences, and a
reference (URL) to the IETF Trust Provisions that govern use of the memo?

zero tool interaction, the text at the URL is all that changes,
Al

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 7 Apr 2010 11:06:40 -0400

> the authors and the IETF without the authors bothering to read it is

But people are already blindly cutting and pasting all this stuff
anyway.  Or just allowing the tool to insert the boilerplate.  I
certainly don't read the provisions every time: I check it when it
changes (especially after the rule changes that made me agree to
things I couldn't possibly assert).

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 7 Apr 2010 17:08:08 +0200

I would note that if the copyright notice is so important, then the help given on the XML2RFC pages don't exactly get me there.

The how to file http://xml.resource.org/xml2rfcFAQ.html#anchor9 gives obsolete information.

The main page gives me in the notice for the current version:

"To generate acceptable boilerplate, please use these settings in your .xml source file: 
in the <rfc /> element: use one of these attributes: 
ipr='trust200902' 
ipr='noModificationTrust200902' 
ipr='noDerivativesTrust200902' 
ipr='pre5378Trust200902' 
and in the <date /> element (which controls the date in the document header):
use year= and month= to indicate a date of 2010-04-01 or later, or simply year="2010" (or later). "

which I suspect will disappear when a new version is created. Further what is there leaves me guessing as to which switch I should use, which I guess is ipr='trust200902'.

Personally, I assume that as I work for a large corporation, providing I put in the current one, other processes in the company will have dealt with any company issues with the current copyright.

regards

Keith

> [mailto:[email-masked]] On Behalf Of David Harrington
> Sent: Wednesday, April 07, 2010 3:57 PM
> To: 'Paul Kyzivat'; 'Lars Eggert'
> Cc: 'Working Group Chairs'
> Subject: RE: XML2RFC updated to latest Trust provisions
> 
> The problem with your approach is that the copyright notice 
> is actually important, and it is important that editors know 
> what it says. Having the tool automatically insert a legal 
> agreement between the authors and the IETF without the 
> authors bothering to read it is not really a good thing.
> 
> dbh 
> 
> > xml2rfc by hand in cases where it needs to be tweaked (e.g., when 
> > there is a new boilerplate text.) It's not ideal, but nobody is 
> > prevented from submitting IDs even when xml2rfc is a little bit 
> > behind.
> > 
> > It would be much better to simply define what is required by what 
> > idnits allows, and refrain from releasing new restrictions 
> in idnits 
> > until they are covered by xml2rfc.
> > 
> > 	Thanks,
> > 	Paul
> > 
> 
>

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 7 Apr 2010 11:18:42 -0400

> zero tool interaction, the text at the URL is all that changes,

People asked about this the last time, and some of the IPR people
insisted it wasn't good enough.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Apr 2010 11:23:55 -0400

> the authors and the IETF without the authors bothering to read it is

If I'm so inclined I can read the draft once its generated.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Apr 2010 11:27:00 -0400

> somehow.  That way if the boilerplate changes, the tool itself need

I like that approach. But I think it needs tweaking because it seems 
there are "alternatives" that must be selected among at any point in 
time. Perhaps just the "type" of alternative could be selected, and the 
specific version that applies for that type could be chosen based on the 
Date in the submission.

	Thanks,
	Paul

---

From: Tony Hansen <[email-masked]>
Date: Wed, 07 Apr 2010 12:18:11 -0400

Shazam! Abracadabra! Poof!

 From xml.resource.org:
     To generate acceptable boilerplate, please use these settings in 
your .xml source file:
     in the <rfc /> element: use one of these attributes:
         * ipr='trust200902'
         * ipr='noModificationTrust200902'
         * ipr='noDerivativesTrust200902'
         * ipr='pre5378Trust200902'

     and in the <date /> element (which controls the date in the 
document header):
     use year= and month= to indicate a date of 2010-04-01 or later, or 
simply year="2010" (or later).

Pick the type of alternative, and the specific version that applies for 
that type will be chosen by the date in the submission.

One can argue that the names aren't the greatest, and we may decide to 
provide nicer alternative aliases in the future, but I think the above 
provides exactly what you were asking for.

We'd also like to update the text on the web page to actually help you 
pick which alternative is preferable, but we're not there yet. 
Suggestions for wording are gratefully accepted.

     Tony Hansen
     [email-masked]

On 4/7/2010 11:27 AM, Paul Kyzivat wrote:
> time. Perhaps just the "type" of alternative could be selected, and 
> the specific version that applies for that type could be chosen based 
> on the Date in the submission.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Apr 2010 13:28:34 -0400

> provides exactly what you were asking for.

 From your description, maybe it does.
All those date-looking things in the attributes made me think these are 
date-specific.

I'd think that for some generic setting you would get the effect of 
pre5378Trust200902 if you document was dated prior to some time in 2009, 
  and trust200902 if your document is dated later than that (and prior 
to the *next* change.) And then maybe "noModification" and 
"noDerivatives" would be alternatives that would themselves be 
date-qualified.

Presumably there should be some way to select specific boilerplate if 
you know exactly what you want.

> pick which alternative is preferable, but we're not there yet. 

I'm no help - you must need lawyers for that.

	Thanks,
	Paul

---

From: "John R. Levine" <[email-masked]>
Date: 7 Apr 2010 13:48:17 -0400

Here's some proposed text.  The descriptions are adapted from the TLP.

>    in the <rfc /> element: use one of these attributes:

This is appropriate for most drafts, where the entire content of the draft 
is written by the draft's authors, or all authors of other material have 
given explicit permission to use their work.

>        * ipr='noModificationTrust200902'

This is appropriate for drafts where the authors wish to place the 
additional condition that if the draft is published as an RFC, it must 
have no changes other than formatting.  An example might be a document 
published by another organization that permits copying but not 
modification.

>        * ipr='noDerivativesTrust200902'

This is appropriate for drafts not intended to be published as RFCs.

>        * ipr='pre5378Trust200902'

This is appropriate for drafts that include material taken from RFCs prior 
to RFC 5378, where the authors of those RFCs have not given explicit 
permission to use their work in this draft.  An example might be a draft 
using material from an RFC whose author has died or cannot be located, or 
who thinks your draft is stupid.

R's,
John

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 7 Apr 2010 10:54:26 -0700

Hi -

> From: "Ray Pelletier" <[email-masked]>
> To: "David Harrington" <[email-masked]>
> Cc: "'Working Group Chairs'" <[email-masked]>
> Sent: Wednesday, April 07, 2010 8:00 AM
...

The documents listed at that URL range from baffling to incomprehensible.
I doubt that an automated process to extract "the right thing" from them
in their current form is practical.  Humans are having enough trouble
figuring out what to do.

But to David's point: I agree it's not a good thing, but even if one reads
the incantations (and I admit that I generally don't - I'm only interested in getting
the document past the submission checks) what are the odds that the reader
will understand whether that is indeed the correct text for his / her particular
situation?  My suspicion is that most submitters are just happy to have hit
upon a combination of xml2rfc options that will let the file be posted.

Randy

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 07 Apr 2010 14:03:05 -0400

--On Wednesday, April 07, 2010 10:54:26 AM -0700 Randy Presuhn 
<[email-masked]> wrote:

> the incantations (and I admit that I generally don't - I'm only
> interested in getting the document past the submission checks) what are
> the odds that the reader will understand whether that is indeed the
> correct text for his / her particular situation?  My suspicion is that
> most submitters are just happy to have hit upon a combination of xml2rfc
> options that will let the file be posted.

I think maybe we're going about this the wrong way.  We currently require 
boilerplate in incoming documents by which the submitter grants various 
rights to the IETF trust and makes various other assertions.  We do it that 
way...

- Because we've ~always done it that way, but so what?

- Because it was convenient to bundle the rights and warranties with
  the document in this way when documents were submitted via email,
  but we don't use email for this any more.

- Because it's an effective means to grant rights to everyone who gets
  a copy of a widely-distributed document.  But while internet-drafts
  are widely-distributed, the authors don't grant rights to everyone
  who receives them -- the authors grant rights only to the trust.

It seems like the thing to do is eliminate the authors' assertions and 
rights grants from the document entirely, and instead require authors to 
explicitly agree to whatever the current terms are as part of the web-based 
submission process.

-- Jeff

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 7 Apr 2010 11:05:09 -0700

+1

Moreover, if we think it's really important to have these with the document,
have the submission process attach them automatically.

-Ekr

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 7 Apr 2010 14:50:38 -0500

Umm,

> who thinks your draft is stupid.

I thought that this was used for any material taken from an ID submitted to 
the IETF prior to RFC 5378, whether it was published as an RFC or not, where 
the authors have not given the assurances now required under RFC 5378 ... 
was I confused?

Thanks,

Spencer

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 7 Apr 2010 15:59:56 -0400

On Wed, Apr 07, 2010 at 02:50:38PM -0500, Spencer Dawkins wrote:
> I thought that this was used for any material taken from an ID submitted 
> to the IETF prior to RFC 5378, whether it was published as an RFC or not, 
> where the authors have not given the assurances now required under RFC 
> 5378 ... was I confused?

Surely not just I-Ds, either.  What about stuff discussed in meetings
prior to that date?  &c.  It point is that 5378 requires the submitter
to assert permissions s/he might not have obtained, and rather than
forcing everyone to lie the right answer is to use the alternative
formulation.  The RFC Editor is a little cheeky when accepting this
boilerplate, but in the end the people who submitted the I-D are the
ones who have to make the assertion.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "John R. Levine" <[email-masked]>
Date: 7 Apr 2010 16:00:06 -0400

> the authors have not given the assurances now required under RFC 5378 ... was 
> I confused?

The TLP says "material from IETF Contributions or IETF Documents published 
or made publicly available before November 10, 2008 as to which the 
persons controlling the copyright in such material have not granted rights 
to the IETF Trust under the terms of RFC 5378" so your guess is as good 
as mine.

R's,
John

---

From: "John R. Levine" <[email-masked]>
Date: 7 Apr 2010 16:09:35 -0400

Perhaps this is better for pre5378

This is appropriate for drafts that include material submitted to the
IETF prior to RFC 5378 (10 Nov 2008), where the authors of that
material have not given explicit permission to use their work in this
draft.  An example might be a draft using material from an RFC whose
author has died or cannot be located, or who thinks your draft is
stupid.

Regards,

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 7 Apr 2010 15:22:01 -0500

John,

> author has died or cannot be located, or who thinks your draft is

That's the way I thought it works (IANAL, but I have submitted Internet 
Drafts :-)

Spencer

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 7 Apr 2010 13:30:02 -0700

Hi -

> From: "John R. Levine" <[email-masked]>
> To: "Spencer Dawkins" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, April 07, 2010 1:09 PM

...

I think the issue is that it's not just material that previously showed up
in an RFC.  Under the expansive definition of "contributions", it could
also be something that was said in a WG meeting or appeared on
an mailing list or in an I-D, for example.  So I'd suggest replacing
"an RFC" with "a statement made at a WG meeting".

Randy

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 7 Apr 2010 16:55:16 -0400

On Wed, Apr 07, 2010 at 10:16:04PM +0200, Carsten Bormann wrote:

> You can't grant (or claim) copyright in "stuff discussed in
> meetings", only in actual expressions of these ideas (sentences,
> pieces of code) so the text in the TLP seems right.

What I would have thought, too, except that 5378 saith:

   a. "Contribution": any submission to the IETF intended by the
      Contributor for publication as all or part of an Internet-Draft or
      RFC (except for RFC Editor Contributions described in Section 4
      below) and any statement made within the context of an IETF
      activity.  Such statements include oral statements in IETF
      sessions as well as written and electronic communications, made at
      any time or place, that are addressed to:

      o the IETF plenary session,
      o any IETF working group or portion thereof,
      o any Birds of a Feather (BOF) session,
      o the IESG, or any member thereof on behalf of the IESG,
      o the IAB, or any member thereof on behalf of the IAB,
      o any IETF mailing list, including the IETF list itself, any
        working group or design team list, or any other list functioning
        under IETF auspices,
      o the RFC Editor or the Internet-Drafts function (except for RFC
        Editor Contributions, as described in Section 4 below).

      Statements made outside of an IETF session, mailing list, or other
      function, that are clearly not intended to be input to an IETF
      activity, group, or function are not IETF Contributions in the
      context of this document.

   b. "Contributor": an individual submitting a Contribution.

Under full TLP terms with no pre-5378 disclaimer you're required to
assert that you have rights in any "contribution".  I have no idea why
the people who wrote this decided that contributions were to be
extended to things in which someone couldn't have a copyright anyway,
but that's what they said so that's what I cleave to.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 07 Apr 2010 17:05:17 -0400

> but that's what they said so that's what I cleave to.

you can have a copyright in the words you say, just not in the idea they 
express.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 7 Apr 2010 17:14:51 -0400

> you can have a copyright in the words you say, just not in the idea they  

Of course.  And are you willing to assert that you're sure you haven't
hit upon exactly the words someone used at the mic?  I'm not.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "John R. Levine" <[email-masked]>
Date: 7 Apr 2010 17:22:24 -0400

> you can have a copyright in the words you say, just not in the idea they 

They're not copyrighted until they are "fixated".  I suppose that if one 
got them off tapes or MP3s that would count as fixation, but if you just 
heard someone say them in a meeting, there's no copyright.

In any event, if you think we need to change my description of pre5378, 
please suggest rewording.

Regards,

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 7 Apr 2010 22:16:04 +0200

On Apr 7, 2010, at 21:59, Andrew Sullivan wrote:

> stuff discussed in meetings
> prior to that date?

You can't grant (or claim) copyright in "stuff discussed in meetings", only in actual expressions of these ideas (sentences, pieces of code) so the text in the TLP seems right.

BTW, kudos to the new posse of XML2RFC hackers, even if I wish we hadn't inherited the Most Inappropriate Programming Language with that code (except maybe for REXX or COBOL).  I'm a little bit unhappy about forking out the XSLT, but Julian has explained the reasons to me.  I think the XSLT (and the way it can be used with modern browsers as a tool for working with I-Ds) deserves a lot more advertisement.

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 8 Apr 2010 00:26:05 +0200

On Apr 7, 2010, at 22:55, Andrew Sullivan wrote:

> 5378 saith:
>   a. "Contribution":

Ah, that's the usual mess you get from the anti-intellectual "IPR" term-of-combat[1].
Conflating the legal concepts of copyright and patents (throw in trademarks, if you want) under one term muddies the water sufficiently that mistakes like this make it into well-considered documents.

That definition is good for discussing the issues related to patent claims.
The oral part of that definition is pretty much irrelevant to literary copyrights, as has been explained by others on this list.

With literary copyrights, you have to have "copy" (written material) before you have "rights".

(Yes, there are artistic and musical copyrights, too, so if somebody hums a tune they just invented or recites the perfect poem into an IETF microphone, or dances a choreography at a plenary, that is then published as an RFC, maybe you need yet another definition.)

[IANAL and certainly know more about German law than about the US law relevant here.]

Gruesse, Carsten

[1] If you speak German, an 8-minute short course from an actual appellate court judge and law professor:
http://www.elektrischer-reporter.de/rohstoff/video/143/
http://www.youtube.com/watch?v=_25QHpdce00

---

From: John C Klensin <[email-masked]>
Date: Wed, 07 Apr 2010 16:33:28 -0400

--On Wednesday, April 07, 2010 11:05 -0700 Eric Rescorla
<[email-masked]> wrote:

>> It seems like the thing to do is eliminate the authors'
>> assertions and rights grants from the document entirely, and
>> instead require authors to explicitly agree to whatever the
>> current terms are as part of the web-based submission process.
> 
> +1
> 
> Moreover, if we think it's really important to have these with
> the document, have the submission process attach them
> automatically.

Gentlemen,

IANAL.  In this area, I'm not even willing to play one on TV.
But...

(1) If we are really going to have this discussion about
fine-tuning the boilerplate and/or mechanisms, the discussion
should probably be on the IPR list (since that WG's efforts
created large parts of this mess) or directly with the IETF
Trust (since they are responsible for both the language and the
procedures).

(2) It is my understanding that, as with the complex legal
questions surrounding the use of "shrink wrap" licenses, there
is apparently an ongoing debate within the legal system (at
least within the US) about what it is that someone has to do to
accept and be bound by a license.  One hears opinions (at least
from amateurs) that range from ("read in front of competent
witnesses and then sign in blood" to "have had some opportunity
to read the license if one knew it was there, excavated it, and
could read the language in which it was written").  Reality
almost certainly lies somewhere in between, but proposals to
move text from one place to another or to substitute one
procedure for another, are, IMO, fairly useless in the absence
of competent and relevant  legal advice (i.e., from someone whom
one is paying or has otherwise retained in a way that creates
responsibility for the advice).

    john

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 8 Apr 2010 16:08:53 -0400

> responsibility for the advice).

And, just to complete this circle, the current system has received and  
is
the result of for-hire legal advice from the Trust's Counsel and others.

I also agree with John about the venue. If you want to gripe about the  
current system, this
list is OK I guess. If you want to change it, it would be better to  
discuss it on
the IPR WG list.

https://www.ietf.org/mailman/listinfo/ipr-wg

Regards
Marshall

---

From: Tom Yu <[email-masked]>
Date: Wed, 07 Apr 2010 22:44:34 -0400

"John R. Levine" <[email-masked]> writes:

>> you can have a copyright in the words you say, just not in the idea
>> they express.
>
> They're not copyrighted until they are "fixated".  I suppose that if
> one got them off tapes or MP3s that would count as fixation, but if
> you just heard someone say them in a meeting, there's no copyright.

We have MP3 archives of most meeting sessions...