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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
-Ursprungligt meddelande-
Från: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org]
För Fredrik Jervfors
Skickat: den 19 juli 2009 09:34
Till: ietf@ietf.org
Ämne: Re: Stockholm airport
That's a good and extensive guide, Måns.
Date:Tue, 21 Jul 2009 08:57:01 +0200
From:Harald Alvestrand har...@alvestrand.no
Message-ID: 4a6566bd.1080...@alvestrand.no
| We have two possibilities:
|
| 1 - the update consists of revisions of *every single RFC* that
| references the BSD license
| 2 -
Hi,
WG description is missing in a number of (perhaps all of them?) WG
charter webpages. E.g. on
http://www.ietf.org/dyn/wg/charter/behave-charter.html, under
Description of Working Group header, I read No description
available.
I wonder whether it is just me. Pointer, please?
It's come to my attention that there is an error in the above referenced
announcement
(http://www.ietf.org/ibin/c5i?mid=6rid=49gid=0k1=934k2=6759tid=12481845
60). The announcement says The IESG has received a request from an
individual submitter to consider the following document: - 'EAP
Could you try again ? This appears to have been a glitch / bug in the
computer system, and I
was told at 10:27 AM EDT that this was resolved.
Regards
Marshall
On Jul 21, 2009, at 9:11 AM, Chew, Kar Ann, VF-Group wrote:
Hi,
WG description is missing in a number of (perhaps all of them?) WG
On Tue, Jul 21, 2009 at 08:57:01AM +0200, Harald Alvestrand wrote:
We have two possibilities:
1 - the update consists of revisions of *every single RFC* that
references the BSD license
2 - some RFCs continue to carry the BSD license, even while the real
current license is different.
1
NO, I believe he is suggesting something slightly different.
First, realize that the structure does not include any license statement
with the code in the RFC. That is covered by the boilerplate.
Second, the issue being addressed is the instruction to someone who
extracts the code from the
It now works!
Thanks,
Kar Ann
-Original Message-
From: Marshall Eubanks [mailto:t...@americafree.tv]
Sent: 21 July 2009 15:43
To: Chew, Kar Ann, VF-Group
Cc: ietf list; Working Group Chairs
Subject: Re: Charter Description Missing?
Could you try again ? This appears to have been a
On Jul 21, 2009, at 10:27 AM, Andrew Sullivan wrote:
On Tue, Jul 21, 2009 at 08:57:01AM +0200, Harald Alvestrand wrote:
We have two possibilities:
1 - the update consists of revisions of *every single RFC* that
references the BSD license
2 - some RFCs continue to carry the BSD license, even
On Tue, Jul 21, 2009 at 10:52:30AM -0400, Joel M. Halpern wrote:
Clearly, any change in IETF policy can not change the text in an RFC.
Only if by the text you exclude all the implicitly included text
that is the resolution of a pointer in the text strictly construed.
If the actual text says,
Andrew Sullivan wrote:
On Tue, Jul 21, 2009 at 08:57:01AM +0200, Harald Alvestrand wrote:
We have two possibilities:
1 - the update consists of revisions of *every single RFC* that
references the BSD license
2 - some RFCs continue to carry the BSD license, even while the real
current
Robert Elz wrote:
Date:Tue, 21 Jul 2009 08:57:01 +0200
From:Harald Alvestrand har...@alvestrand.no
Message-ID: 4a6566bd.1080...@alvestrand.no
| We have two possibilities:
|
| 1 - the update consists of revisions of *every single RFC* that
| references the
At 3:15 PM -0400 7/20/09, Dean Anderson wrote:
I am against this standard because of its patent encumbrances and
non-free licencing terms.
In the past, I think that Dean Anderson has stated that he is not a lawyer
(although I can't find the specific reference). Note that the statement above
is
I have implemented draft-ietf-tls-extractor-06 in the TLS v1.0
implementation in OpenSSL. I found the draft easy to implement with
no ambiguities or concerns. I believe that the functionality provided
by the draft will be extremely valuable for building application-level
security
The IESG is considering an experiment for IETF 73 in Minneapolis, and
we would like community comments before we proceed. Face-to-face
meeting time is very precious, especially with about 120 IETF WGs
competing for meeting slots. Several WGs are not able to get as much
meeting time as they
Nikos Mavrogiannopoulos wrote:
I'd propose to add this text to the standard:
This protocol MUST NOT be used with RFC4492, RFC5289 and
draft-rescorla-tls-suiteb.
How much longer are we going to beat that dead horse?
I'm not aware of information that the Certicom patents apply to
TLS
The Certicom IPR disclosure says that their patent claims cover
pretty much all of the TLS documents when TLS is used with ECC Crypto.
You're constantly arguing that Certicoms patent claims *APPLY*
to TLS extractors -- which it is not, and which no one from
Certicom seems to claim.
The
Greetings!
It appears that during the website cut-over, the script that updates
the Working Group charters stopped picking up the group descriptions.
The script has been fixed, and the charters have been updated.
We apologize for the inconvenience.
Matt, on behalf of the Secretariat.
I'd propose to add this text to the standard:
This protocol MUST NOT be used with RFC4492, RFC5289 and
draft-rescorla-tls-suiteb.
That way the certicom's patents are not applicable.
On Mon, Jul 20, 2009 at 11:24 PM, Dan Harkinsdhark...@lounge.org wrote:
Certicom's IPR statement dated 13
I think Andrew makes a lot of sense. I really can't envision a situation where
the IETF would want to change licence terms en masse, given the impact Andrew
demonstrates on deployed or ready-to-deploy product.
Andrew Sullivan wrote:
On Tue, Jul 21, 2009 at 10:52:30AM -0400, Joel M. Halpern
- Original Message -
From: Adrian Farrel adr...@olddog.co.uk
To: Tom.Petch sisyp...@dial.pipex.com
Cc: ietf ietf@ietf.org
Sent: Monday, July 20, 2009 5:47 PM
Subject: Re: Last Call: draft-ietf-mpls-tp-requirements (MPLS-TP
Requirements)toProposed Standard
Thanks for the input Tom,
I
What are we smoking? The license can't be changed after the RFC is
published. At least, it can't be made more restrictive. I can't imagine
the chaos if one must prove your right to follow a particular set of
license rules based on proving exactly when you extracted code from a
published RFC.
The folks contributing the code have a different constraint. They ahve
agreed separately to let the IETF have all rights to do anything we want
with the source, including giving it to anyone else, and giving them any
rights we want.
(Note, this is copyright related rights only. This has
On Tue, Jul 21, 2009 at 03:07:15PM -0400, Joel M. Halpern wrote:
And, even more specifically, it is only about how we describe that
license in the event that we want to change forward-going extractors.
I think it is exactly this premise that some are wondering about. Is
there any
On Tue, 21 Jul 2009, Joel M. Halpern wrote:
The text we are discussing is only about what license we require other folks
to put on code they extract from an RFC.
And, even more specifically, it is only about how we describe that license in
the event that we want to change forward-going
Yes, I believe that there is a real world example.
Without creating needless FUD, let me say that someone did recently
point out possible implications of the BSD license that we did not
intend. Fairly awkward implications.
1) It may well be possible to fix that with a clarification.
2) But
No matter what, we have to be clear in our records about when things
change, and folks who extract things need to somehow record when they
did so. That is actually true no matter what, since once the code is
extracted, without some backtrace there is no way verify things. I
would expect
On Tue, Jul 21, 2009 at 03:35:31PM -0400, Joel M. Halpern wrote:
Without creating needless FUD, let me say that someone did recently
point out possible implications of the BSD license that we did not
intend. Fairly awkward implications.
1) It may well be possible to fix that with a
Dean Anderson wrote:
I think you misunderstand how patents work or what the license says.
The licence is available for the case when used with either It is
not the case that a patent only applies to specific RFCs. RFC's aren't
mentioned in patents. Patent claims covering tls-extractor
Hi Tom,
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
requirements (as opposed to a protocol) draft.
I hear you. Security
I object to this document being published as a Proposed Standard. When
this document was discussed in the EMU meeting at IETF-71 there was much
concern raised with respect to existing IPR in the area of secure
password methods used by this draft. Additionally, soon after its
initial publication
Hi Joe,
As I mentioned in the EMU meeting at IETF-71 I have not patented this
exchange, my employer has not patented this exchange, Glen has not
patented this exchange, and neither has his employer. I am unaware of
any patents on this exchange by others and I believe no existing patents
On Tue, 21 Jul 2009 17:54:23 -0700 (PDT)
Dan Harkins dhark...@lounge.org wrote:
If specification of patented algorithms and drafts subject to IPR
disclosure is not enough to knock a draft of the Standards Track then
I don't know why FUD about a possible patent _maybe_ existing that
_might_
Date:Tue, 21 Jul 2009 18:40:52 +0200
From:Harald Alvestrand har...@alvestrand.no
Message-ID: 4a65ef94.2050...@alvestrand.no
| I'm afraid that your perception disagrees with the structure that RFC
| 5378 set up.
I was misunderstanding what's going on, Joel has
At Mon, 20 Jul 2009 15:15:53 -0400 (EDT),
Dean Anderson wrote:
I am against this standard because of its patent encumbrances and
non-free licencing terms. The working group did not get any clear
answers on what particular patents this draft may infringe, but a patent
holder (Certicom) did
By chance (I assume it was chance), CNN's travel section just ran a
piece on Stockholm:
http://www.cnn.com/2009/TRAVEL/getaways/07/21/stockholm.travel/index.html
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Hi Steve,
On Tue, July 21, 2009 6:16 pm, Steven M. Bellovin wrote:
On Tue, 21 Jul 2009 17:54:23 -0700 (PDT)
Dan Harkins dhark...@lounge.org wrote:
If specification of patented algorithms and drafts subject to IPR
disclosure is not enough to knock a draft of the Standards Track then
I
On 22 jul 2009, at 03.49, Steven M. Bellovin wrote:
By chance (I assume it was chance), CNN's travel section just ran a
piece on Stockholm:
http://www.cnn.com/2009/TRAVEL/getaways/07/21/stockholm.travel/index.html
I am pretty sure it was our excellent hosts at .SE (Staffan, Anne-
Marie,
The IESG has received a request from the Diameter Maintenance and
Extensions WG (dime) to consider the following document:
- 'Diameter Quality of Service Application '
draft-ietf-dime-diameter-qos-09.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and
The IESG has received a request from the Diameter Maintenance and
Extensions WG (dime) to consider the following document:
- 'Diameter User-Name and Realm Based Request Routing Clarifications '
draft-ietf-dime-nai-routing-02.txt as a Proposed Standard
The IESG plans to make a decision in the
The IESG has approved the following document:
- 'AES Galois Counter Mode for the Secure Shell Transport Layer Protocol '
draft-igoe-secsh-aes-gcm-03.txt as an Informational RFC
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG contact
A modified charter has been submitted for the Mobility for IPv4 (mip4)
working group in the Internet Area of the IETF. The IESG has not made any
determination as yet. The modified charter is provided below for
informational purposes only. Please send your comments to the IESG
mailing list
The IESG has received a request from the Application-Layer Traffic
Optimization WG (alto) to consider the following document:
- 'Application-Layer Traffic Optimization (ALTO) Problem Statement '
draft-ietf-alto-problem-statement-02.txt as an Informational RFC
The IESG plans to make a
44 matches
Mail list logo
