----- Original Message ----- From: <ietf-request@xxxxxxxx> To: <ietf@xxxxxxxx> Sent: Friday, December 09, 2005 9:27 AM Subject: Ietf Digest, Vol 20, Issue 24 > Send Ietf mailing list submissions to > ietf@xxxxxxxx > > To subscribe or unsubscribe via the World Wide Web, visit > https://www1.ietf.org/mailman/listinfo/ietf > or, via email, send a message with subject or body 'help' to > ietf-request@xxxxxxxx > > You can reach the person managing the list at > ietf-owner@xxxxxxxx > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Ietf digest..." > > > Today's Topics: > > 1. The Trust Agreement Proposal (John C Klensin) > 2. Re: [IAOC] Re: The IETF Trust License is too restricted > (Simon Josefsson) > 3. Re: The IETF Trust License is too restricted (Sam Hartman) > 4. Any Final Comments on the IETF Trust (Lucy E. Lynch) > 5. Re: [IAOC] I know I am dumb stupid but I am also dumb > stubborn [was IETF Trust license is too restricted] (Lucy E. Lynch) > 6. The Trust Agreement Proposal (Bob Hinden) > 7. Re: Appeal: Publication of draft-lyon-senderid-core-01 in > conflict with referenced draft-schlitt-spf-classic-02 > (Frank Ellermann) > 8. Re: Last Call: 'NETCONF Configuration Protocol' to Proposed > Standard (Sam Hartman) > 9. Re: [IAOC] I know I am dumb stupid but I am also dumb > stubborn [was IETF Trust license is too restricted] > (JFC (Jefsey) Morfin) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 08 Dec 2005 14:00:49 -0500 > From: John C Klensin <john-ietf@xxxxxxx> > Subject: The Trust Agreement Proposal > To: "Lucy E. Lynch" <llynch@xxxxxxxxxxxxxxxxxxxx> > Cc: ietf@xxxxxxxx > Message-ID: <21B2C7D31E873A43417F4C0A@xxxxxxxxxxxx> > Content-Type: text/plain; charset=us-ascii > > Lucy and IAOC, > > I've reviewed the notes on the list, the FAQs, the Settlor > agreements, and what I assume is the new 9.5 text. First of > all, I'd like to express thanks to the IAOC for being willing to > open the agreement up to community review, comment, and approval > and for making changes that process seemed to call for. I think > that, as the result of this process, critical provisions of the > document are vastly better than they were and hope that the IAOC > and the rest of the community agree. > > Some of the provisions of the current version are not what I > would have preferred in a more perfect world. On the other > hand, in such a world, I don't know whether we would have the > Trust model at all and certainly would have preferred that the > IAOC not spend a large fraction of the last year negotiating it. > But this is not, as we all know, a perfect world. Given the > actual world in which we live, it is as important to know where > to stop, approve a document, and move on, rather than letting > the quest for perfection drag things out and block other > important tasks. > > It appears to me that we have reached that point. I would urge > others to consider whether more discussion and tuning is really > worth the possible benefits. > > The more recent discussion about the rights the IETF might have > and want to grant seems largely irrelevant to the Trust > agreement given the new wording (it did not appear irrelevant > under the old agreement). It seems to me that the IETF (or the > IASA, or either or both Settlors) might lay full or partial > claim to two fundamentally different types of IPR: > > (i) Materials associated with the development, approval, > or publication of standards. These are materials > contributed to the IETF by its participants or prepared > for the IETF, under contract or other arrangement, in > support of those materials. Those materials now appear > to be excluded from the scope of 9.5. I say "appear" > under the IANAL disclaimer, but, if counsel has advised > the IAOC that the wording is adequate, then I think that > case is taken care of. > > (ii) Materials associated with, or developed as a > consequence of, the operation of the IETF or > administration of the standards process. Those > materials might be developed under contract, or might > include documents or tools contributed to the IETF to > make its processes more efficient. These are the > materials that appear to be covered under 9.5 now and, > as far as I can tell, they are not covered at all by RFC > 3979. Even in my most vivid imaginings, I cannot > imagine a legitimate purpose for which another body > would want most of that stuff, much less one under which > a "share alike" provision would be clearly > inappropriate. Exceptions might occur with tools or > similar material contributed to the IETF, but the > solution there is for the author to reserve some rights, > giving the IETF/IASA only the right to use the tools and > perhaps to modify them for specialized purposes. So > while, in principle, I would prefer to see no > restrictions on the choices the IETF might make, I don't > see these restrictions as having any significant impact. > > So, from my point of view, while the IPR Licensing debate should > continue in its own right, we have gotten past the point at > which it has enough interaction with the Trust to justify > holding the latter up. > > In conclusion, I think we have reached the point at which it is > appropriate to approve this thing and get one with the > standards-creation and definition business of the IETF. > > john > > > > > ------------------------------ > > Message: 2 > Date: Thu, 08 Dec 2005 20:05:49 +0100 > From: Simon Josefsson <jas@xxxxxxxxxxx> > Subject: Re: [IAOC] Re: The IETF Trust License is too restricted > To: Brian E Carpenter <brc@xxxxxxxxxxxxxx> > Cc: IAOC <iaoc@xxxxxxxx>, Sam Hartman <hartmans-ietf@xxxxxxx>, > ietf@xxxxxxxx, Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx> > Message-ID: <iluacfbpfxu.fsf@xxxxxxxxxxxxxxxxxxx> > Content-Type: text/plain; charset=us-ascii > > Brian E Carpenter <brc@xxxxxxxxxxxxxx> writes: > >> Lucy E. Lynch wrote: >>> On Thu, 8 Dec 2005, Simon Josefsson wrote: >>> >>>>Sam Hartman <hartmans-ietf@xxxxxxx> writes: >>>> >>>>>I think it is sufficient the trust be able to operate under any set of >>>>>outbound rights we come up with. >>>> >>>>That won't be possible, given the current (and even the updated) IETF >>>>Trust agreement. >>>> >>>>The IETF may decide that third parties should be given rights to all >>>>contributions, not only to RFCs/I-Ds. >>>> >>>>Currently, the IETF Trust would be unable to comply to such a wish >>>>from the IETF, because the Trust agreement prevent them from doing so. >>> explain please, I don't understand this. >>> Straw man? >> >> To me, the new phrase "IETF >> standards-related documents (such as RFCs, Internet Drafts and the >> like)" clearly covers contributions to the standards process, i.e. >> the same scope as RFC 3978. I don't see a problem here. > > RFC 3978 define Contributions as: > > c. "IETF 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 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, > which are addressed to: > > o the IETF plenary session, > o any IETF working group or portion thereof, > 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 described below). > > That is considerably more than what even a lax interpretation of "IETF > standards-related documents" would mean. > > So I do see a (minor) problem. > > Thanks, > Simon > > > > ------------------------------ > > Message: 3 > Date: Thu, 08 Dec 2005 14:19:54 -0500 > From: Sam Hartman <hartmans-ietf@xxxxxxx> > Subject: Re: The IETF Trust License is too restricted > To: Simon Josefsson <jas@xxxxxxxxxxx> > Cc: Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx>, ietf@xxxxxxxx, > IAOC <iaoc@xxxxxxxx> > Message-ID: <tslbqzro0px.fsf@xxxxxxxxxx> > Content-Type: text/plain; charset=us-ascii > > I don't see the problem here. For example, I believe the IETF could > license a tool under the GPL if it wanted to. I believe it would need > to require that work it paid for was assigned to the trust but that's > a fairly common practice. > > > > > ------------------------------ > > Message: 4 > Date: Thu, 8 Dec 2005 12:50:28 -0800 (PST) > From: "Lucy E. Lynch" <llynch@xxxxxxxxxxxxxxxxxxxx> > Subject: Any Final Comments on the IETF Trust > To: ietf@xxxxxxxx > Message-ID: <Pine.GSO.4.58.0512081239350.1595@xxxxxxxxxxxxxxxxxxxx> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > All - > > I'll be closing the Consensus Call on the the IETF Trust at 5:00PM > PST today. The current version of the document, incorporating the new > language for Section 9.5 can be found here: > > http://koi.uoregon.edu/~iaoc/docs/IETF-Trust-12-08-05.pdf > > Please send any final comments to: ietf@xxxxxxxx or iaoc@xxxxxxxx > > Thanks > > Lucy E. Lynch Academic User Services > Computing Center University of Oregon > llynch @darkwing.uoregon.edu (541) 346-1774 > > > > ------------------------------ > > Message: 5 > Date: Thu, 8 Dec 2005 12:55:47 -0800 (PST) > From: "Lucy E. Lynch" <llynch@xxxxxxxxxxxxxxxxxxxx> > Subject: Re: [IAOC] I know I am dumb stupid but I am also dumb > stubborn [was IETF Trust license is too restricted] > To: "JFC (Jefsey) Morfin" <jefsey@xxxxxxxxxx> > Cc: IAOC <iaoc@xxxxxxxx>, ietf@xxxxxxxx > Message-ID: <Pine.GSO.4.58.0512081252590.1595@xxxxxxxxxxxxxxxxxxxx> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Mon, 5 Dec 2005, JFC (Jefsey) Morfin wrote: > >> At 15:50 05/12/2005, Brian E Carpenter wrote: >> >Simon, >> >You are bit behind real time. We already updated this text. >> >http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg01837.html >> >> Dear Brian, >> Great! the three stupid points I am stubbornly interested in are >> gathered here! Please read what follows with humour, however the >> three issues are serious. > > <snip> > >> If I copy all the RFCs, sort their content, add a legal blabla paying >> my respects to all those who contributed through the IETF, make an >> open use e-book from them all, class their proposition in some >> orders, updating it when they change, mixing them with other SSDOs >> propositions, etc. translating parts in various languages, adding >> comments on their usage cons and pros and testing, linking the >> various comments people may have made on them, etc. quoting available >> open source/commercial libraries and their variations, etc. and the >> various registry repositories where they can find the values of the >> related parameters, i.e. what the users long for a while, will the >> IAOC sue me and send me to jail as the US DMCA and the French DADVSI would do? > > Tounge firmly in cheek: > > Of course we won't send you to jail. We'll make you come live in a > country with no real cheese and a lot of overly oak-y white wine. > > far worse. ;-) > > - lel > >> thank you >> jfc >> >> >> >> _______________________________________________ >> IAOC mailing list >> IAOC@xxxxxxxx >> https://www1.ietf.org/mailman/listinfo/iaoc >> > > > > ------------------------------ > > Message: 6 > Date: Thu, 8 Dec 2005 13:48:27 -0800 > From: Bob Hinden <bob.hinden@xxxxxxxxx> > Subject: The Trust Agreement Proposal > To: "Lucy E. Lynch" <llynch@xxxxxxxxxxxxxxxxxxxx> > Cc: IETF discussion list <ietf@xxxxxxxx> > Message-ID: <2B73E8B7-83EA-42EE-8D09-D6497C260783@xxxxxxxxx> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > Lucy and IAOC, > > As John Klenson, said we don't live in a perfect world. I think the > trust agreement as written solves some very important problems we > have now (e.g., getting rights to things like the IETF's domain name, > past meeting proceedings, email archives, etc.). It is probably not > perfect, but more than good enough to go forward with. I think that > we can work around any issues that come up and have the ability to > revise it in the future. > > I support it and urge others to do so. > > I also want to thank Lucy and the other members of IAOC for the all > the time and hard work they have put into this. It's an important > step for the IETF. > > Bob > > > > > > ------------------------------ > > Message: 7 > Date: Thu, 08 Dec 2005 23:05:49 +0100 > From: Frank Ellermann <nobody@xxxxxxxxxxxxxxxxx> > Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 in > conflict with referenced draft-schlitt-spf-classic-02 > To: ietf@xxxxxxxx > Cc: spf-discuss@xxxxxxxxxxxxxx > Message-ID: <4398AE3D.512D@xxxxxxxxxxxxxxxxx> > Content-Type: text/plain; charset=us-ascii > > The IESG decided: > >> while we have found merit in Julian Mehnle's technical >> concerns, we will not change our decision to publish the >> draft as an Experimental RFC without change to its technical >> content. > >> The IESG did consider this conflict in its original >> discussions, and that is one of the reasons why we crafted >> the original IESG note to be included in these documents, >> which highlights that there are concerns about using these >> mechanisms in tandem. > > That's beside the point. Of course "consenting adults" can use > "spf2.0/mfrom,pra", and that's semantically almost the same as > "v=spf1" plus an identical "spf2.0/pra" policy. There are no > technical issues with using these mechanisms in tandem for all > senders explicitly wishing to participate in both experiments. > > The issue are senders _not_ wishing to participate in the later > PRA experiment: "v=spf1" is semantically almost the same as > "spf2.0/mfrom" _without_ "spf2.0/pra". > > That's what the v=spf1 spec. says with its "NOT RECOMMENDED" in > chapter 2.4. It simply reflects what all v=spf1 specifications > and implementations did since 2003. > >> It is quite clear that this conflict would not be acceptable >> for a standards track specification. > > It's also unacceptale for a standards organization with a bare > minimum of ethical and engineering principles. > >> document the different approaches as they were considered in >> the MARID working group. > > The MARID WG came to the conclusion that PRA (spf2.0/pra) is in > fact so different from SPF (v=spf1 or spf2.0/mfrom) that they > should be clearly separated. That was the last MARID decision > before this WG was dissolved unilaterally by Mr. Hardie. > > [he = Julian] >> he requested that we modify draft-lyon-senderid-core to >> address the conflict. > > Yes, backed by the SPF community and more than 200 signatures > <http://old.openspf.org/cgi-bin/openspf_pledge.cgi>. This does > not include several competent voices who don't like v=spf1, but > still agree that (ab)using v=spf1 for PRA without the explicit > consent of the v=spf1 participants is an ethical and technical > nightmare. > >> his proposed modification amounted to a substantive technical >> change. > > That's not the case. His proposal affects _four characters_ in > a chapter about the alleged spf2.0 "backwards" compatibility: > > Instead of 'treat v=spf1 like spf2.0/mfrom,pra' this should be > 'treat v=spf1 like spf2.0/mfrom'. > >> The IESG did not consider this an appropriate action to take >> in this case. > > Well, you are wrong, and everybody can see it. If one draft > says "SHOULD do x", and another draft says "SHOULD NOT do x", > then something has to give. > >> Depending on the content of the record, this may mean that >> Sender-ID heuristics would be applied incorrectly to a >> message. > > This does _not_ depend on the content of the v=spf1 record. It > depends on a PRA being identical to the MAIL FROM. Which isn't > the case for a significant portion of all mails. > >> Participants publishing SPF experiment DNS records should >> consider the advice given in section 3.4 of RFC XXXX >> (draft-lyon-senderid-core) and may wish to publish both >> v=spf1 and v=spf2.0 records to avoid the conflict. > > There's no such thing as "v=spf2.0 records". This "advice" is > completely bogus, there are more than a million v=spf1 records, > and it will take years to migrate this installed base to use > the new SPF RR. > > For this migration period the best they can do is to publish > both SPF and TXT records, "v=spf1" or "spf2.0". Asking the > participants of the older "experiment" to publish four records > instead of two won't fly, let alone anytime soon. > > Besides, since when favours the IESG "opt-out" for experiments > with non-consenting participants ? > >> we hope that this augmented IESG note will address his >> concerns. > > I seriously doubt it. Bye, Frank > > > > > > ------------------------------ > > Message: 8 > Date: Thu, 08 Dec 2005 17:34:34 -0500 > From: Sam Hartman <hartmans-ietf@xxxxxxx> > Subject: Re: Last Call: 'NETCONF Configuration Protocol' to Proposed > Standard > To: iesg@xxxxxxxx > Cc: ietf@xxxxxxxx > Message-ID: <tsl8xuvmd51.fsf@xxxxxxxxxx> > Content-Type: text/plain; charset=us-ascii > > > > Hi. This is not a blocking comment nor am I even asking for a change; > I'm just asking people consider this for netconf and future work. > > Netconf currently recommends that netconf over ssh be run over a > different port than the normal ssh port. > > That seems like a fine idea. I think there are cases where you might > want to allow access to netconf but not allow access to the CLI > through the normal ssh port. > > However I think in many cases it would not be a security problem if > the netconf subsystem were available over the normal ssh port. In > many applications the same privileges will be granted to users over > the CLI as to the same users over netconf. In many cases the > functionality available through netconf will also be available through > the CLI. > > --Sam > > > > > ------------------------------ > > Message: 9 > Date: Fri, 09 Dec 2005 01:44:49 +0100 > From: "JFC (Jefsey) Morfin" <jefsey@xxxxxxxxxx> > Subject: Re: [IAOC] I know I am dumb stupid but I am also dumb > stubborn [was IETF Trust license is too restricted] > To: "Lucy E. Lynch" <llynch@xxxxxxxxxxxxxxxxxxxx> > Cc: IAOC <iaoc@xxxxxxxx>, ietf@xxxxxxxx > Message-ID: <6.2.3.4.2.20051209013831.04d982e0@xxxxxxxxxxxxxxx> > Content-Type: text/plain; charset="us-ascii"; format=flowed > > At 21:55 08/12/2005, Lucy E. Lynch wrote: >>On Mon, 5 Dec 2005, JFC (Jefsey) Morfin wrote: >> > At 15:50 05/12/2005, Brian E Carpenter wrote: >> > >Simon, >> > >You are bit behind real time. We already updated this text. >> > >http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg01837.html >> > >> > Dear Brian, >> > Great! the three stupid points I am stubbornly interested in are >> > gathered here! Please read what follows with humour, however the >> > three issues are serious. >> >><snip> >> >> > If I copy all the RFCs, sort their content, add a legal blabla paying >> > my respects to all those who contributed through the IETF, make an >> > open use e-book from them all, class their proposition in some >> > orders, updating it when they change, mixing them with other SSDOs >> > propositions, etc. translating parts in various languages, adding >> > comments on their usage cons and pros and testing, linking the >> > various comments people may have made on them, etc. quoting available >> > open source/commercial libraries and their variations, etc. and the >> > various registry repositories where they can find the values of the >> > related parameters, i.e. what the users long for a while, will the >> > IAOC sue me and send me to jail as the US DMCA and the French >> DADVSI would do? >> >>Tounge firmly in cheek: >>Of course we won't send you to jail. We'll make you come live in a >>country with no real cheese and a lot of overly oak-y white wine. >>far worse. ;-) > > This response is recorded. And taken as an unusual but formal > permission, due to circumstances and repeated denial of response. It > will be acted upon as described. Any possible opposition will be > objected this response and Brian's one, and unanswered request of > authoritative comments. > > NB1: I fully understand that people from the darkwing are jealous > from those living on the brightside. :-) > NB2: I still wait for my response concerning the legal responsibility > of the Trust. > Thank you. > jfc > > > > > ------------------------------ > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > > > End of Ietf Digest, Vol 20, Issue 24 > ************************************ _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf