ECRIT Phone Conference

Hi all, we are planning to have a "virtual interim meeting" in the ECRIT working group (i.e. a phone conference). The information can be found here: http://trac.tools.ietf.org/wg/ecrit/trac/wiki Ciao Hannes ___ Ietf mailing list Ietf@ietf.org https:

DIME Phone Conference

Hi all, we are planning to have a "virtual interim meeting" in the DIME working group (i.e. a phone conference). The information can be found here: http://trac.tools.ietf.org/wg/dime/trac/wiki/ConferenceBridge Ciao Hannes ___ Ietf mailing list Ietf

Re: The Dean list

Andrew Sullivan wrote: I also was resubscribed. I received the usual totally clarifying message one has come to expect from Mr Anderson. None of this suggests to me, however, that we ought to do something. My understanding (and I'd appreciate being disabused if I'm wrong) is that Mr Anderson

Re: Review of draft-ietf-tls-authz-extns-07

Thierry Moreau writes: > Simon Josefsson wrote: > >> >> When evaluating whether to implement a particular technology, you need >> to evaluate all the risks. The text of patent (applications) helps in >> the evaluation. My point is that the actions of patent holders is >> significantly more rele

Re: yet another comment on draft-housley-tls-authz-extns-07.txt

Stephan Wenger writes: > Hi Simon, > > > On 2/11/09 4:43 PM, "Simon Josefsson" wrote: > >> Stephan Wenger writes: >> >>> [...] >>> The way to address this misalignment is to work in the IETF >>> towards an FSF-compatible patent regime, and not rant about one specific >>> draft that somehow got

IETF and open source license compatibility (Was: Re: yet another comment on draft-housley-tls-authz-extns-07.txt)

Simon, That's not possible because the IETF policies does not permit free software compatible licensing on Internet drafts published by the IETF. ... See RFC 5378: It is also important to note that additional copyright notices are not permitted in IETF Documents except ... ...

Re: IETF and open source license compatibility (Was: Re: yet another comment on draft-housley-tls-authz-extns-07.txt)

On Thu, 12 Feb 2009, Jari Arkko wrote: > > I agree that there are problematic case, but I believe I hope everyone > realizes this is only the case if the RFC in question has code. > Otherwise it really does not matter. Only some RFCs have code. Except that it prevents using the text of an RFC as c

Re: IETF and open source license compatibility (Was: Re: yet another comment on draft-housley-tls-authz-extns-07.txt)

On Thursday 12 February 2009 14:39:53 ext Jari Arkko, you wrote: > I support experiments in this space, though. And it would be really good > to get more of the open source folk participate in IETF specification > work. There are many important open source extensions and protocols that > fit in IET

Re: Review of draft-ietf-tls-authz-extns-07

Simon, Thanks for these clarifications. They explain how you, and how "apparently" the FSF came to the conclusion about the current Redphone IPR situation. (No need to repeat my opposite views already on the record.) - Thierry Simon Josefsson wrote: Thierry Moreau writes: Simon Josefs

Re: IETF and open source license compatibility (Was: Re: yet another comment on draft-housley-tls-authz-extns-07.txt)

Tony, Except that it prevents using the text of an RFC as comments in an implementation. OK -- I can see how that would be useful, but its not clear to me that it would necessarily be a blocking requirement. Reality check: I'm writing this e-mail to you and at least my side application, OS,

Re: IETF and open source license compatibility (Was: Re: yet another comment on draft-housley-tls-authz-extns-07.txt)

Excerpts from Rémi Denis-Courmont on Thu, Feb 12, 2009 03:03:02PM +0200: > Oh, I was one relevant working group mailing lists. But from my > experience, I was not at all taken seriously, until I started > showing up at the meetings. In other words, remote participation > does _not_ really work, in

Re: IETF and open source license compatibility (Was: Re: yet another comment on draft-housley-tls-authz-extns-07.txt)

Jari Arkko wrote: >> Except that it prevents using the text of an RFC as comments in an >> implementation. >> > OK -- I can see how that would be useful, but its not clear to me that > it would necessarily be a blocking requirement. Jari is right about this. For a bit of perspective, FSF dist

Re: IETF and open source license compatibility (Was: Re: yet another comment on draft-housley-tls-authz-extns-07.txt)

Hi Tony, On Feb 12, 2009, at 7:45 AM, Tony Finch wrote: On Thu, 12 Feb 2009, Jari Arkko wrote: I agree that there are problematic case, but I believe I hope everyone realizes this is only the case if the RFC in question has code. Otherwise it really does not matter. Only some RFCs have co

Re: IETF and open source license compatibility (Was: Re: yet another comment on draft-housley-tls-authz-extns-07.txt)

Tony Finch wrote: On Thu, 12 Feb 2009, Jari Arkko wrote: I agree that there are problematic case, but I believe I hope everyone realizes this is only the case if the RFC in question has code. Otherwise it really does not matter. Only some RFCs have code. Except that it prevents using t

Re: IETF and open source license compatibility (Was: Re: yet another comment on draft-housley-tls-authz-extns-07.txt)

On Thu, 12 Feb 2009, Harald Alvestrand wrote: > > actually that's intended to be permitted by RFC 5377 section 4.2: Oh, that's nice :-) Tony. -- f.anthony.n.finchhttp://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD.

Re: IETF and open source license compatibility (Was: Re: yet another comment on draft-housley-tls-authz-extns-07.txt)

Harald, Margaret, and Simon, Harald wrote actually that's intended to be permitted by RFC 5377 section 4.2: and Margaret wrote: However, I don't think that anyone actually believes that the IETF will track down people who copy RFC text into comments and sue them or attempt to get injunction

Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07

At Wed, 11 Feb 2009 16:20:14 -0500 (EST), Dean Anderson wrote: > ... And as > programmer and developer, I will probably have some non-patented > alternatives to present. > > --Dean Dean, that's really laudable progress, leading

Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07

Alfred, neither of the cited KeyNote drafts (nor the KeyNote system itself) is patent-encumbered. However, I admit to not (yet) having paid close attention to the details of the IPR issues around tls-authz-extns itself and their potential impact to tls-authz-keynote. I have started draft-k

No to patent emcumbered standards

Dear Internet Engineering Task Force, I'm writing to you as I'm very concerned about patent encumbered technology being embedded within standards. As I'm sure you are aware the entity holding the patent(s) would expect remuneration for the use of their technology. This is obviously unworkable for

draft-housley-tls-authz-extns

To Whom It May Concern: I am writing to express my opposition to any standard encumbered by any patent. If a standard is to be a standard, it MUST be free to implement and use. It appears that RedPhone Security's intellectual property claims affect only particular implementations of the prop

"TLS authorization"

Dear IETF I read on the Free Software Foundation's website tonight on how you plan to recommend a communication protocol that has a patent on it. I believe this is a horrible idea as the world wide web was founded on patent free standards; the W3 continued existence is because the web standard

Re: Fourth Last Call: draft-housley-tls-authz-extns

> This Last Call is intended to determine whether the IETF community > had consensus to publish draft-housley-tls-authz-extns as a > proposed standard given IPR Disclosure 1026. In Disclosure 1026 RedPhone Security states the following: When an implementation generates the authorizations or pr

Comment on TLS-authz proposal

I object to this move to standards track status because I find IPR 1026 completely inadequate as protection. I strongly urge the IETF to reject draft-housley-tls-authz-extns for that reason. Perhaps the IPR's range of choices for section VI, Licensing Declaration, is too limited. "No License Re

TLS authz licensing problem

Hello, I'm writing you this mail because I read the following article written by the Free Software Foundation: Having read this I couldn't agree more to what they say: the IETF work is useful for the entire Internet and we would

Re: Last Call: draft-hoffman-dac-vbr (Vouch By Reference) to Proposed Standard

Apologies for the lateness of this comment. I only recently found the time to review this draft. Althogh I share Chris Newman's concerns about possible uses of this draft and support the addition of the paragraph he recommends in his DISCUSS vote, I also believe the mechanism defined by this draf

RE: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07

The main issue I have been struggeling with these authorization extensions inside TLS is that they happen at the wrong layer. Today, we see similar functionality being deployed at higher layers. I doubt that a standardized authorization mechanism inside TLS will have a lot of impact. Ciao Hanne

Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07

On 2/12/09 1:16 PM, "Hannes Tschofenig" wrote: > The main issue I have been struggeling with these authorization extensions > inside TLS is that they happen at the wrong layer. I don't know about that - I think it really depends on how the TLS session is being used, etc. I think that the more ab

Re: IETF and open source license compatibility (Was: Re: yet another comment on draft-housley-tls-authz-extns-07.txt)

Dear Jari et al.; On Feb 12, 2009, at 12:25 PM, Jari Arkko wrote: Harald, Margaret, and Simon, Harald wrote actually that's intended to be permitted by RFC 5377 section 4.2: and Margaret wrote: However, I don't think that anyone actually believes that the IETF will track down people who

RE: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07

Hi Melinda, >On 2/12/09 1:16 PM, "Hannes Tschofenig" > wrote: >> The main issue I have been struggeling with these authorization >> extensions inside TLS is that they happen at the wrong layer. > >I don't know about that - I think it really depends on how the >TLS session is being used, etc.

Re: IETF and open source license compatibility

Jari Arkko writes: > Simon, > That's not possible because the IETF policies does not permit free software compatible licensing on Internet drafts published by the IETF. > ... >> See RFC 5378: >> >>It is also important to note that additional copyright notices are >>n

Re: IETF and open source license compatibility

Harald Alvestrand writes: > Tony Finch wrote: >> On Thu, 12 Feb 2009, Jari Arkko wrote: >> >>> I agree that there are problematic case, but I believe I hope everyone >>> realizes this is only the case if the RFC in question has code. >>> Otherwise it really does not matter. Only some RFCs have

Re: IETF and open source license compatibility

Jari Arkko writes: > Harald, Margaret, and Simon, > > Harald wrote >> actually that's intended to be permitted by RFC 5377 section 4.2: > > and Margaret wrote: > >> However, I don't think that anyone actually believes that the IETF >> will track down people who copy RFC text into comments and sue

Re: IETF and open source license compatibility

Simon Josefsson wrote: Jari Arkko writes: Simon, That's not possible because the IETF policies does not permit free software compatible licensing on Internet drafts published by the IETF. ... See RFC 5378: It is also important to note that additional copy

Re: IETF and open source license compatibility

I disagree Simon. Free Software authors (for any variety of free software I know of) are free to submit I-Ds describing protocols that they define. They can not take their licensed code, with license restrictions, and put it in the RFC. The primary reason for this restriction, in my view, is

Re: IETF and open source license compatibility

"Joel M. Halpern" writes: > I disagree Simon. > > Free Software authors (for any variety of free software I know of) are > free to submit I-Ds describing protocols that they define. Sure. And some do... > They can not take their licensed code, with license restrictions, and > put it in the RFC

Re: IETF and open source license compatibility

Wes Hardaker writes: > So, I couldn't find a statement that says automatic sublicenses will be > given out for code related items. It only says that the policies for > creating those sublicenses ***will*** be guided by 5377 (which says > about the right thing: you can modify code extracts). IE,

LORAN is making a comeback..

Folks because of the problems with GPS the LORAN system and a new location based encrypted LORAN is emerging. But there is an opportunity to expand that and layer PPP or some other rudimentary stack atop the LORAN transport Anyone else interested? Todd Glassey __

RE: IETF and open source license compatibility

Some points: 1) Open Source software and 'free software' as defined by the FSF are not the same thing. Historically, open source licenses such as BSD and Apache or in the case of CERN libwww, a grant to the public domain have proved considerably more effective than GNU copyleft. The World wid

Re: IETF and open source license compatibility

Simon Josefsson wrote: Jari Arkko writes: Harald, Margaret, and Simon, Harald wrote actually that's intended to be permitted by RFC 5377 section 4.2: and Margaret wrote: However, I don't think that anyone actually believes that the IETF will track down people who copy

RE: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07

Hannes wrote: > Melinda wrote: > > > > and that there are > > some non-trivial advantages to carrying authorizations in-band. > Namely... I don't wish to speak for Melinda, but this is a view shared by many within my own community. I have a long list of applications, collected from within this c

Re: LORAN is making a comeback..

On Thu, Feb 12, 2009 at 4:04 PM, TSG wrote: > Folks because of the problems with GPS the LORAN system and a new location > based encrypted LORAN is emerging. Problems locking on to enough satellites to get a fix? Atmospheric interference? --R ___ Ietf

Re: LORAN is making a comeback..

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yo All! On Thu, 12 Feb 2009, Robinson Tryon wrote: > On Thu, Feb 12, 2009 at 4:04 PM, TSG wrote: > > Folks because of the problems with GPS the LORAN system and a new location > > based encrypted LORAN is emerging. > > Problems locking on to enough

Re: IETF and open source license compatibility

For short excerpts, one can use the text anyway and claim "fair use", but larger excerpts can be useful to quote in comments or documentation and then there is a problem. This whole line of reasoning does reminds me of stories about camels jumping through eyse in needles, numbers

Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07

> "Josh" == Josh Howlett writes: Josh> I have a long list of applications, collected from within Josh> this community, with which they would like to use SAML-based Josh> authorisation; and it seems to me that the ability for Josh> application protocols to share a common mechan

Re: LORAN is making a comeback..

Take it off line. This has nothing to do with the IETF. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf

Re: LORAN is making a comeback..

Lyndon Nerenberg wrote: Take it off line. This has nothing to do with the IETF. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Except as requirements for TICTOC. Stewart __

RE: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07

Hi Josh, >Hannes wrote: >> Melinda wrote: >> > >> > and that there are >> > some non-trivial advantages to carrying authorizations in-band. >> Namely... > >I don't wish to speak for Melinda, but this is a view shared >by many within my own community. > >I have a long list of applications, colle

TLS Standard problem

Hello, I realize that this may be past the deadline for comment, but I wanted to add my voice to those protesting the adoption of a standard for TLS authorization extensions that includes a pending patent applied for by RedPhone security. I believe it is counter to the concept of open standards to

Re: Please reject the patent-encumbered proposed standard for TLS authorization

Dear Noel, It's unfortunate, but I know of no way to tell the difference between an email address that's the main point of contact for an organization and an email address that distributes to a huge mailing list. I sent email to ietf@ietf.org, naively assuming that the Internet Engineering Ta

"TLS authorization" standard

Hello. I'm writing to you regarding the proposed standard "TLS authorization". Please stop the madness. It's bad enough that ISO lost a significant part of it's perceived independence, now we see IETF thinking about aproving a patent-encumbered standard. This kind of conduct is unthinkable w

Re: It's time for some new steps (was: [Welcome to the "Ietf-honest" mailing list])

On Mon, Feb 09, 2009 at 04:38:00PM -0800, Dave CROCKER wrote: > 1. Permanently and irrevocably ban postings from any and all addresses > that Dean controls. An organized attack warrants it. > > 2. Highten strictures on ietf list posting. I'm not entirely clear > what level the current bar i

Re: RE proposed standard draft-housley-tls-authz-extns-07

Thank you, Noel, for the followup. I would like you to realize, though, that many people will see a vast difference between approving a standard that may (or may not) be encumbered by an unforeseen patent and knowingly approving a standard with strings attached. The difference is one of the re

Comments on TLS-authz

I oppose the publication of "Transport Layer Security (TLS) Authorization Extensions" (draft-housley-tls-authz-extns) due to patent restrictions on the use of these extensions. The implementation appears to be released from any potential patent claims for implementing the protocol(s) as described i

Concern regarding Patented TLS Authorization spec

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have been made aware through my involvement in the Free Information and Free Software communities of a dangerous spec the IETF is about to push through regarding TLS. The FSF notice about the spec(s) in question is at

TLS authorization and RedPhone Security patent

I was reading some news late today when I noticed this. http://opendotdotdot.blogspot.com/2009/02/help-fight-this-patent-encumbered-ietf.html http://www.computerworlduk.com/community/blogs/index.cfm?blogid=14&entryid=1845 http://www.fsf.org/news/reoppose-tls-authz-standard Hopefully I'm not to la

TLS Authz - Encumbered Standards are Not Standards

Dear Folks: I sincerely hope that U will vote to reject this 'standard.' Any widely-used protocol that is taxed by patent encumbrance leaves the entire market at the mercy of the whims of the patent holder. When an investment is made in a technology, a strong argument can be made for breath

Re: please do not publish draft-housley-tls-authz-extns

Hi Noel, On Wed, Feb 11, 2009 at 05:39:19PM -0500, Noel Chiappa wrote: > Thank you for being part of a crowd of hundreds of people who have mailbombed > the mailboxes of thousands of IETF 'members' (since we don't have any formal > membership, just an email list). As a result, we all have such pos

Re: IETF and open source license compatibility

> On Thu, 12 Feb 2009 14:39:53 +0200, Jari Arkko > said: JA> I agree that there are problematic case, but I believe I hope everyone JA> realizes this is only the case if the RFC in question has JA> code. Otherwise it really does not matter. Only some RFCs have code. Actually, many RFCs

Re: IETF and open source license compatibility

> On Thu, 12 Feb 2009 22:03:39 +0100, Simon Josefsson > said: SJ> The IETF Trust sub-license third parties rights to code components in SJ> (new) IETF documents under the BSD license, see section 4 of: SJ> http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf Thanks! Does anyone

Re: IETF and open source license compatibility

Simon Josefsson wrote: actually that's intended to be permitted by RFC 5377 section 4.2: 4.2. Rights Granted for Quoting from IETF Contributions There is rough consensus that it is useful to permit quoting without modification of excerpts from IETF Contributions. Such excerpts may be o

Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07

and that there are some non-trivial advantages to carrying authorizations in-band. Namely... Independance between payload and security measures. Piggybagging information on lower layers is a very old concept. https was successful over shttp. I think the patent is made by trolls. The

Changes needed to Last Call boilerplate

I've heard from a number of the FSF thundering herd people to the effect of 'but the announcement says send email to ietf@ietf.org". (They're conveniently ignoring the fact that it says "the IETF community" all over the place in the Last Call, but never mind.) So clearly we need to change it to sa

Re: It's time for some new steps (was: [Welcome to the "Ietf-honest" mailing list])

And once the "moderate" switch has been thrown, what criteria will be used to decide which messages to allow and which to block? On 2/11/09, Rich Kulawiec wrote: > On Mon, Feb 09, 2009 at 04:38:00PM -0800, Dave CROCKER wrote: > > 1. Permanently and irrevocably ban postings from any and all add

Re: Changes needed to Last Call boilerplate

Actually, there is a grain of a good idea here that I'd like to extract. I wouldn't create two places to send comments and attempt to segregate who can post to which group. However, creating an ietf-comm...@ietf.org email list and asking >all< last call comments to be sent to that email list has

Re: Changes needed to Last Call boilerplate

> From: Clint Chaplin > I wouldn't create two places to send comments and attempt to segregate > who can post to which group. However, creating an ietf-comm...@ietf.org > email list and asking >all< last call comments to be sent to that That also works for me. Noel _

Re: please do not publish draft-housley-tls-authz-extns

In message <20090211233244.ga23...@localdomain>, Ward Vandewege writes: > Hi Noel, > > On Wed, Feb 11, 2009 at 05:39:19PM -0500, Noel Chiappa wrote: > > Thank you for being part of a crowd of hundreds of people who have mailbomb > ed > > the mailboxes of thousands of IETF 'members' (since we don'

Re: Changes needed to Last Call boilerplate

On 2009-02-13 13:15, Noel Chiappa wrote: > > From: Clint Chaplin > > > I wouldn't create two places to send comments and attempt to segregate > > who can post to which group. However, creating an ietf-comm...@ietf.org > > email list and asking >all< last call comments to be sent t

Re: Changes needed to Last Call boilerplate

On Fri, 13 Feb 2009, Brian E Carpenter wrote: On 2009-02-13 13:15, Noel Chiappa wrote: > From: Clint Chaplin > I wouldn't create two places to send comments and attempt to segregate > who can post to which group. However, creating an ietf-comm...@ietf.org > email list and asking

Re: Changes needed to Last Call boilerplate

David Morris wrote: Seems like a unique mailbox per lastcall would be very helpful all around. Right now, gathering and evaluating comments must be a nightmare. An alternative, would be a single LC mailbox as suggested, but require EVERY subject line to carry the last call ID, preferable in a f

Re: Changes needed to Last Call boilerplate

On Thu, 12 Feb 2009, Willie Gillespie wrote: David Morris wrote: Seems like a unique mailbox per lastcall would be very helpful all around. Right now, gathering and evaluating comments must be a nightmare. An David Morris ... Not a bad idea. In fact, it may be useful to have a unique "list

Re: Changes needed to Last Call boilerplate

> From: Brian E Carpenter > it's really important that the Subject contains the draft name. > Otherwise, sorting becomes a nightmare. > ... > The radical alternative is of course a web-based method which ensures > that comments are logged and stored per-document I think t

Re: IETF and open source license compatibility

On Thu, 12 Feb 2009 21:38:44 +0100 Simon Josefsson wrote: > The discussion started by Stephan suggesting that free software > authors publish their work as free standards in the IETF. My point > was that since the IETF disallow publishing standards under a license > that is compatible with free

Re: IETF and open source license compatibility

On 12.02.2009, Hallam-Baker, Phillip wrote: > 3) Write only campaigns decrease sympathy for the position being promoted. As someone who mainly acts in read-only mode on this list: regardless of what one thinks about free software, I think what troubles me most in the recent campaign is that it has