Re: [Trustees] Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)

2009-07-20 Thread Harald Alvestrand
Andrew Sullivan wrote: On Mon, Jul 20, 2009 at 02:56:01PM -0400, Joel M. Halpern wrote: Rather, what it does is the RfC says "the code must include whatever license the trust document says. When the code is produced, that link is dereferenced, the license is determined, and the license is

Re: [Trustees] Objection to reworked para 6.d (Re: Rationale forProposed TLP Revisions)

2009-07-20 Thread Andrew Sullivan
On 2009-07-20, at 16:44, "Contreras, Jorge" > wrote: I apologize if my unfortunate use of the term "future-proofing" has caused angst. But I was referring to the proposal made by Harald Alvestrand, as a member of the community, not a proposal made by the Trust. Harald's proposal should n

Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard

2009-07-20 Thread Dan Harkins
Certicom's IPR statement dated 13 October 2008 lists some patents that "may be necessary and essential to implementations of..." the TLS extractor draft "when used with either: " RFC4492, RFC5289 or draft-rescorla-tls-suiteb. Check it out: http://www.certicom.com/images/pdfs/certicom%20-ipr-con

Re: [Trustees] Objection to reworked para 6.d (Re: Rationale forProposed TLP Revisions)

2009-07-20 Thread Barry Leiba
On Mon, Jul 20, 2009 at 4:53 PM, Joel M. Halpern wrote: > I think Harald's suggestion makes sense and should be implemented. I agree. Barry ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf

Re: [Trustees] Objection to reworked para 6.d (Re: Rationale forProposed TLP Revisions)

2009-07-20 Thread Joel M. Halpern
I think Harald's suggestion makes sense and should be implemented. Joel Contreras, Jorge wrote: Ok. So is the point then just not to have to issue a new RFC if the Trust decides they want a different license? I.e. is that the "future-proofing" that the proposed change is supposed to provid

RE: [Trustees] Objection to reworked para 6.d (Re: Rationale forProposed TLP Revisions)

2009-07-20 Thread Contreras, Jorge
> Ok. So is the point then just not to have to issue a new RFC if the > Trust decides they want a different license? I.e. is that the > "future-proofing" that the proposed change is supposed to provide? I apologize if my unfortunate use of the term "future-proofing" has caused angst. But I

Re: [Trustees] Proposed Revisions to the IETF Trust Legal Provisions(TLP)

2009-07-20 Thread Henk Uijterwaal
John, * There is, as far as I know, no precedent for an IETF-related body to announce a public comment period on a document, make a series of "interim decisions" and announce them five days before the end of that period, and then leave the comment period termination date in place

Re: [Trustees] Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)

2009-07-20 Thread Andrew Sullivan
On Mon, Jul 20, 2009 at 02:56:01PM -0400, Joel M. Halpern wrote: > Rather, what it does is the RfC says "the code must include whatever > license the trust document says. > When the code is produced, that link is dereferenced, the license is > determined, and the license is inserted in the code

Re: [Trustees] Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)

2009-07-20 Thread Joel M. Halpern
I don't think it means that. Rather, what it does is the RfC says "the code must include whatever license the trust document says. When the code is produced, that link is dereferenced, the license is determined, and the license is inserted in the code. No, no one can reasonably produce code un

Re: [Trustees] Proposed Revisions to the IETF Trust Legal Provisions (TLP)

2009-07-20 Thread Pete Resnick
On 7/20/09 at 9:09 AM -0700, Fred Baker wrote: On Jul 18, 2009, at 6:18 PM, Scott O. Bradner wrote: [Numbering mine...] The IETF Trust determines that there is a specific legal risk that must be countered. In this case (***1***) the IETF Trust posts a description of the specific risk and t

Re: [Trustees] Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)

2009-07-20 Thread Andrew Sullivan
On Mon, Jul 20, 2009 at 02:19:24PM -0400, Contreras, Jorge wrote: > > I also think that Harald's alternate language would work. Is it a problem that this means that shipping code's license could change at some time in the future? Are there practical issues to that if (for instance) the Trust d

RE: [Trustees] Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)

2009-07-20 Thread Contreras, Jorge
> -Original Message- > From: trustees-boun...@ietf.org > [mailto:trustees-boun...@ietf.org] On Behalf Of Russ Housley > Sent: Monday, July 20, 2009 8:41 AM > To: ietf@ietf.org > Cc: trust...@ietf.org; wgcha...@ietf.org; > rfc-inter...@rfc-editor.org; i...@iab.org; i...@ietf.org > Subje

Re: [rfc-i] Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)

2009-07-20 Thread Harald Alvestrand
John C Klensin wrote: --On Monday, July 20, 2009 14:20 +0200 Julian Reschke wrote: Julian Reschke wrote: ... 3) If I *extract* ABNF from these documents (such as for the purpose of generating an input file for an ABNF parser), do I need to include the BSD license text? If so, can so

Re: [rfc-i] Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)

2009-07-20 Thread Harald Alvestrand
Julian Reschke wrote: Harald Alvestrand wrote: ... Hi, I'm trying to understand whether this change affects me. So... 1) Many specs I'm editor of contain ABNF. Does it need to be labeled as code component (I believe not). In my understanding, all ABNF is code by definition (included in the

Re: [rfc-i] Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)

2009-07-20 Thread John C Klensin
You are correct. I remembered the text differently, but should have checked. I apologize. john --On Monday, July 20, 2009 12:23 -0400 Russ Housley wrote: > At 08:25 AM 7/20/2009, John C Klensin wrote: > > >> --On Monday, July 20, 2009 14:20 +0200 Julian Reschke >> wrote: >> >> > Julia

Re: Stockholm airport

2009-07-20 Thread Fredrik Jervfors
>> I just got approval to attend IETF, and I am getting 2 airports for >> Stockholm. >> >> Which is the one to use? > > As others have mentioned, there are several. Ryan Air uses Skavsta (NYO > / ESKN) and Västerås (VST / ESOW). Those are fairly remote; count on > several hours of bus transit. > >

Re: [rfc-i] Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)

2009-07-20 Thread Russ Housley
At 08:25 AM 7/20/2009, John C Klensin wrote: --On Monday, July 20, 2009 14:20 +0200 Julian Reschke wrote: > Julian Reschke wrote: >> ... >> 3) If I *extract* ABNF from these documents (such as for the >> purpose of generating an input file for an ABNF parser), do >> I need to include the BS

Re: [Trustees] Proposed Revisions to the IETF Trust Legal Provisions (TLP)

2009-07-20 Thread Fred Baker
On Jul 18, 2009, at 6:18 PM, Scott O. Bradner wrote: 2nd way: The IETF Trust determines that there is a specific legal risk that must be countered. In this case the IETF Trust posts a description of the specific risk and the proposed change to counter the risk. In this case the Trust pu

Re: Last Call: draft-ietf-mpls-tp-requirements (MPLS-TP Requirements)toProposed Standard

2009-07-20 Thread Adrian Farrel
Thanks for the input Tom, I see some difficulties with the references in this I-D. a) The security section of this I-D says see[I-D.ietf-mpls-mpls-and-gmpls-security-framework] which is an informative reference. I believe that security should be normative, not informative, even in this, a

Re: Re: [Trustees] Proposed Revisions to the IETF Trust Legal Provisions(TLP)

2009-07-20 Thread John C Klensin
FWIW, while I think that I may be even more concerned than Scott is --partially as a matter of personality and partially because I've seen what I consider more symptoms-- we are in basic agreement about the problem and the concerns. This is really about Trust behavior vis-a-vis the community (or c

Re: Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)

2009-07-20 Thread Russ Housley
I think that the alternate text proposed by Harald meets the current need without constraining the future. Russ Apologies for this being a month late. From the rationale: 4.e -- this new section clarifies the legend requirements for Code Components that are used in software under the BSD Li

Re: Re: [Trustees] Proposed Revisions to the IETF Trust Legal Provisions(TLP)

2009-07-20 Thread Scott O. Bradner
Some history that may explain some of my and some other reaction to the recent postings by the Trust When the Trust was formed a number of us were quite worried that it would begin to see itself as self directed and not as a function whose purpose was to act at the direction of and in support of

Re: [Trustees] Proposed Revisions to the IETF Trust Legal Provisions (TLP)

2009-07-20 Thread Eliot Lear
On 7/19/09 1:29 PM, Scott O. Bradner wrote: Isn't this what has essentially happened in this case? I did not see a statement from the IETF asking for changes nor did I see a statement from the Trust saying that there are these issues that need to be fixed for legal or cosmetic reasons

Re: [Trustees] Proposed Revisions to the IETF Trust Legal Provisions (TLP)

2009-07-20 Thread Scott O. Bradner
> Aren't RFC 5377/5378 (and subsequent discussion) such a statement? did I miss the posting that lists each of the proposed chages with a pointer to the specific request for change (or specific need for change) in these RFCs? Scott ___ Ietf mailing list

Re: [rfc-i] Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)

2009-07-20 Thread John C Klensin
--On Monday, July 20, 2009 14:20 +0200 Julian Reschke wrote: > Julian Reschke wrote: >> ... >> 3) If I *extract* ABNF from these documents (such as for the >> purpose of generating an input file for an ABNF parser), do >> I need to include the BSD license text? If so, can somebody >> explain

Re: [Trustees] Proposed Revisions to the IETF Trust Legal Provisions(TLP)

2009-07-20 Thread John C Klensin
--On Monday, July 20, 2009 10:32 +0200 Henk Uijterwaal wrote: > John, > >>* There is, as far as I know, no precedent for an >>IETF-related body to announce a public comment period on a >>document, make a series of "interim decisions" and announce >>them five days before the end

Re: [rfc-i] Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)

2009-07-20 Thread Julian Reschke
Julian Reschke wrote: ... 3) If I *extract* ABNF from these documents (such as for the purpose of generating an input file for an ABNF parser), do I need to include the BSD license text? If so, can somebody explain how to do that given the constraints of the ABNF syntax? ... Explanation: fo

Re: [Trustees] Proposed Revisions to the IETF Trust Legal Provisions (TLP)

2009-07-20 Thread Scott O. Bradner
> Aren't RFC 5377/5378 (and subsequent discussion) such a statement? sorry - I must have missed the announcement by the trust that they were responding to these RFCs Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf

Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)

2009-07-20 Thread Harald Alvestrand
Apologies for this being a month late. From the rationale: 4.e -- this new section clarifies the legend requirements for Code Components that are used in software under the BSD License. In short, the user must include the full BSD License text or a shorter pointer to it (which is set forth i

Re: [Trustees] Proposed Revisions to the IETF Trust Legal Provisions (TLP)

2009-07-20 Thread Henk Uijterwaal
Scott O. Bradner wrote: Isn't this what has essentially happened in this case? I did not see a statement from the IETF asking for changes Aren't RFC 5377/5378 (and subsequent discussion) such a statement? (At least, that is where people told me to start when I asked why we are doing this). H

Re: [rfc-i] Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)

2009-07-20 Thread Julian Reschke
Harald Alvestrand wrote: ... Hi, I'm trying to understand whether this change affects me. So... 1) Many specs I'm editor of contain ABNF. Does it need to be labeled as code component (I believe not). 2) These specs also collect all ABNF fragments into an appendix, containing the collecte

Re: [Trustees] Proposed Revisions to the IETF Trust Legal Provisions(TLP)

2009-07-20 Thread Henk Uijterwaal
John, * There is, as far as I know, no precedent for an IETF-related body to announce a public comment period on a document, make a series of "interim decisions" and announce them five days before the end of that period, and then leave the comment period termination date in place