Subject: Uncommented diff: define expected <path-identity>

From: Russ Allbery <[email-masked]>
Date: Thu, 11 Dec 2008 19:40:26 -0800

I proposed the following diff in response to one of the previous
discussions, but I don't think I ever got any feedback and hence never
applied it.  Could people look this over and tell me if it should be
included?

This change goes into the section defining the Path header field.

Index: usepro.xml
===================================================================
--- usepro.xml	(revision 5041)
+++ usepro.xml	(working copy)
@@ -405,7 +405,13 @@
                   followed by the FQDN, IP address, or expected
                   &lt;path-identity> of the source.</t>
                 </list>
-              Be aware that <xref target="RFC1036" /> did not include
+              The "expected &lt;path-identity> of the source of the
+              article" is a &lt;path-identity> for the injecting or
+              relaying agent that passed the article to this relaying or
+              serving agent, determined by properties of connection via
+              which the article was received (for example, an
+              authentication identity or a peer IP address).  Be aware
+              that <xref target="RFC1036" /> did not include
               &lt;path-diagnostic>.  Implementations which predate this
               specification will add only single "!" characters between
               &lt;path-identity> strings.</t>

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 12 Dec 2008 17:51:13 GMT

>applied it.  Could people look this over and tell me if it should be

+1, modulo typo below.

>Index: usepro.xml
                                                          ^
                                                         the

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: Russ Allbery <[email-masked]>
Date: Fri, 12 Dec 2008 21:23:15 -0800

"Charles Lindsey" <[email-masked]> writes:
> Russ Allbery <[email-masked]> writes:

>>applied it.  Could people look this over and tell me if it should be

Thanks.  This is uncontroversial enough that I'm going to go ahead and
make the change based on that confirmation; if anyone objects, let me
know, and we can talk about it further.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 16 Dec 2008 09:25:14 +0100

> This change goes into the section defining the Path header field.
Looks fine to me; I think the same is said or implied elsewhere 
(including in USEFOR), but repetition isn't very harmful, and might be 
helpful.

---

From: Russ Allbery <[email-masked]>
Date: Tue, 16 Dec 2008 13:33:03 -0800

> (including in USEFOR), but repetition isn't very harmful, and might be

Thanks, it's in -13.

BTW, there's some current dust-up about the legal boilerplate in RFCs and
some debate over whether it implies that the I-D author has to verify the
legal status of all submissions to the I-D.  To be perfectly clear in a
public forum, I have *not* done this.  I posted -13 on the basis of the
following sentence in RFC 5378:

   This memo does not retroactively obtain additional rights from
   Contributions that predate the date that the IETF Trust announces the
   adoption of these procedures.

and therefore made no attempt to check the rights status of any
submissions that went into this draft prior to when I became aware of
these rules (which was a couple of days ago).

RFC 5378 is a long, ugly legal document that I have no particular desire
to read, understand, or analyze.  I'm hoping that the IETF will clearly
resolve the current question, which appears to revolve around this text:

   To the extent that a Contribution or any portion thereof is protected
   by copyright or other rights of authorship, the Contributor and each
   named co-Contributor grant a perpetual, irrevocable, non-exclusive,
   royalty-free, world-wide, sublicensable right and license to the IETF
   Trust under all such copyrights and other rights in the Contribution:

   a. to copy, publish, display, and distribute the Contribution, in
      whole or in part,

   b. to prepare translations of the Contribution into languages other
      than English, in whole or in part, and to copy, publish, display,
      and distribute such translations or portions thereof,

   c. to modify or prepare derivative works (in addition to
      translations) that are based on or incorporate all or part of the
      Contribution, and to copy, publish, display, and distribute such
      derivative works, or portions thereof unless explicitly disallowed
      in the notices contained in a Contribution (in the form specified
      by the Legend Instructions), and

   d. to reproduce any trademarks, service marks, or trade names which
      are included in the Contribution solely in connection with the
      reproduction, distribution, or publication of the Contribution and
      derivative works thereof as permitted by this Section 5.3,
      provided that when reproducing Contributions, trademark and
      service mark identifiers used in the Contribution, including TM
      and (R), will be preserved.

and:

   Subject to each Contributor's (or its sponsor's) ownership of its
   underlying Contributions as described in Section 5.6 (which ownership
   is qualified by the irrevocable licenses granted under Section 5.3),
   each Contributor hereby acknowledges that the copyright in any RFC in
   which such Contribution is included, other than an RFC that is an RFC
   Editor Contribution, shall be owned by the IETF Trust.  Such
   Contributor shall be deemed to assign to the IETF Trust such
   Contributor's copyright interest in the collective work constituting
   such RFC upon the submission of such RFC for publication, and
   acknowledges that a copyright notice acknowledging the IETF Trust's
   ownership of the copyright in such RFC will be included in the
   published RFC.

I have no problem granting the IETF Trust such a license and copyright
assignment for the collective copyright for all of my contributions to
this I-D.  However, I want to make very explicitly clear that I can speak
only for my own contributions, I have not verified the contributions of
anyone else involved in this draft (named or otherwise), and have no
intention of doing so.

If it becomes the job of the I-D Author to verify such legal details
regarding the draft, I will be resigning as document author for this
working group, as I have neither the time nor the inclination to be a
legal bookkeeper.

Furthermore, please note that while I have no difficulty doing this, I
have not signed any legal document transferring copyright, and as a matter
of law, I do not believe that the IETF is legally permitted to transfer
copyright in a manner such as that described above without such a legal
document.  So as a matter of law, I believe section 5.9 is, in fact, void.
I am, however, not a lawyer and am not taking action on that basis.

Other contributors can and should speak for themselves regarding the
implications of the above (and the rest of RFC 5378) for their work.  I
very explicitly refuse to make any representations on behalf of anyone
else, and if it is made clear to me that by submitting an I-D I am doing
so, I will immediately cease to submit any further I-Ds to the IETF until
such time as that changes.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 17 Dec 2008 08:44:20 +0100

> these rules (which was a couple of days ago).
Sigh.... as chair of the IPR WG, I'm at least in part responsible for 
this :-( - and yes, it's a mess.

In this case, my understanding of copyright law would say that if 
Charles or Henry Spencer were to object to submission under RFC 5378, 
they would have standing to do so; the requirement from RFC 5378 that 
they have "materially and substantially" contributed would leave most of 
the rest of us without a copyright to assert.
> to read, understand, or analyze.
all I can say in its defense is that it's 2 pages shorter than 3978, its 
predecessor :-(
>   I'm hoping that the IETF will clearly
Understood. Since the only person left to do the bookkeeping is the WG 
chair, I guess it's my job.
> I am, however, not a lawyer and am not taking action on that basis.
It's not a copyright transfer - it's a license, and a statement that you 
won't object to the IETF Trust asserting copyright in the resulting RFC.

That's the only way it can work according to copyright law without 
requiring real signed copyright transfer documents, according to the 
lawyer. And the WG was very much vehemently opposed to requiring such 
copyright transfer documents.
> such time as that changes.
well, 3978 wasn't much better in that regard. The reason it worked was 
the assumption (without basis in law, as it turns out - the construction 
of the permissions was unsound, but the shared belief that we could is 
probably good enough that a challenge wouldn't pass muster) that we had 
permission to copy from all contributions, including emails and old I-Ds.

The particular problem here is whether material submitted under 3978 can 
be incorporated into material submitted under 5378 without asking the 
authors.

The Trust is working on finding a reasonable solution.

                    Harald