Subject: Experimental makes sense for tls-authz

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 26 Oct 2007 11:04:44 -0700

Hi -

The existence of IPR claims potentially relevant to the implementation
of a specification has never been sufficient grounds to block the
publication of that specification as an RFC.  Given the unfortunate
history of this work, publication of draft-housley-tls-authz-extns
as experimental seems to be the most sensible path out of this mess.

If the IPR terms are indeed so onerous as to preclude widespread
implementation, as seems to be the concern of some, then it will
simply gather dust with other "experiments" that didn't work out,
and the open source community need not worry.  If, on the other
hand, this technology is so superior to anything the open source
community can offer as an alternative, then Darwin will go to work.

None of the recent argumentation has been technical. None of the
recent argumentation has provided a convincing procedural reason
to block publication of draft-housley-tls-authz-extns.  Let's just
hand it over to the RFC editor and be done with it.

Randy

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Powers Chuck-RXCP20" <[email-masked]>
Date: Fri, 26 Oct 2007 14:18:21 -0400

> Randy Presuhn wrote:
> 
> Hi -
> 
> The existence of IPR claims potentially relevant to the 
> implementation of a specification has never been sufficient 
> grounds to block the publication of that specification as an 
> RFC.  Given the unfortunate history of this work, publication 
> of draft-housley-tls-authz-extns as experimental seems to be 
> the most sensible path out of this mess.
> 
> If the IPR terms are indeed so onerous as to preclude 
> widespread implementation, as seems to be the concern of 
> some, then it will simply gather dust with other 
> "experiments" that didn't work out, and the open source 
> community need not worry.  If, on the other hand, this 
> technology is so superior to anything the open source 
> None of the recent argumentation has been technical. None of 
> the recent argumentation has provided a convincing procedural 
> reason to block publication of draft-housley-tls-authz-extns. 
>  Let's just hand it over to the RFC editor and be done with it.
> 
> Randy

+1

If there is a technical reason for opposing the publication of this as
an Experimental RFC, please make that argument. Otherwise, lFrom [email-masked] Fri Oct 26 14:22:30 2007
Content-class: urn:content-classes:message
Date: Fri, 26 Oct 2007 14:18:21 -0400
From: "Powers Chuck-RXCP20" <[email-masked]>
To: <[email-masked]>
Subject: RE: Experimental makes sense for tls-authz

> Randy Presuhn wrote:
> 
> Hi -
> 
> The existence of IPR claims potentially relevant to the 
> implementation of a specification has never been sufficient 
> grounds to block the publication of that specification as an 
> RFC.  Given the unfortunate history of this work, publication 
> of draft-housley-tls-authz-extns as experimental seems to be 
> the most sensible path out of this mess.
> 
> If the IPR terms are indeed so onerous as to preclude 
> widespread implementation, as seems to be the concern of 
> some, then it will simply gather dust with other 
> "experiments" that didn't work out, and the open source 
> community need not worry.  If, on the other hand, this 
> technology is so superior to anything the open source 
> None of the recent argumentation has been technical. None of 
> the recent argumentation has provided a convincing procedural 
> reason to block publication of draft-housley-tls-authz-extns. 
>  Let's just hand it over to the RFC editor and be done with it.
> 
> Randy

+1

If there is a technical reason for opposing the publication of this as
an Experimental RFC, please make that argument. Otherwise, let the
Experimental RFC track do what it was designed to do, and determine what
interest (if any) there is in this technology in the industry.

regards,

Chuck

---

From: Melinda Shore <[email-masked]>
Date: Fri, 26 Oct 2007 14:16:41 -0400

On 10/26/07 2:04 PM, "Randy Presuhn" <[email-masked]> wrote:
> Given the unfortunate

Hear, hear.

Melinda

et the

regards,

Chuck

---

From: Melinda Shore <[email-masked]>
Date: Fri, 26 Oct 2007 14:16:41 -0400

Hear, hear.

Melinda

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 26 Oct 2007 15:16:07 -0400

Given the current email activity on this issue, I want to echo Randy's support.
We have published encumbered experimental and informational documents 
on many occasions.  I can see no reason not to do so in this 
case.  Given that it appears that experimental publication is 
sufficient for the registration needs that go with this document, I 
strongly support publication.

Yours,
Joel M. Halpern

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 27 Oct 2007 08:32:11 +1300

> as experimental seems to be the most sensible path out of this mess.

I agree. The DOS attack on this list seems to be from people
who haven't read RFC 2026 and use meaningless phrases like
"experimental standard." In fact, publishing this as an experiment
to see if it gets implemented and deployed despite the IPR issue
seems like *exactly* the right thing to do.

     Brian

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 26 Oct 2007 16:00:04 -0400

> seems like *exactly* the right thing to do.

Just make sure you aren't running an experiment on the results of ignoring the 
IETF rules not having signficant consuequences.

Scott K

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 26 Oct 2007 13:27:07 -0700

Perhaps the experiement is to see if the purported IPR is enforceable.

________________________________

From: Scott Kitterman [mailto:[email-masked]]
Sent: Fri 26/10/2007 4:00 PM
To: [email-masked]
Subject: Re: Experimental makes sense for tls-authz

Scott K

---

From: Ned Freed <[email-masked]>
Date: Fri, 26 Oct 2007 13:34:19 -0700 (PDT)

+1

				Ned

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 26 Oct 2007 23:57:11 +0200

Brian E Carpenter wrote:

> The DOS attack on this list seems to be from people who haven't
> read RFC 2026 and use meaningless phrases like "experimental
> standard."

What was it, 30 messages collected by Megatron over eight days ?
FYI 36 <http://tools.ietf.org/html/rfc4949#page-101> offers a
definition for "denial of service".

Of course some messages about a "standard on experimental track"
or similar kind of miss the point.  As a "campaign" it reminded
me of the weird "yes, we will deploy sender-id" parade in MARID.

Other messages were perfectly on topic, apparently from concerned
folks.  I agree with the drift in the rest of your message, but
of course I won't say anything about the specific I-D in an IETF
Last Call, for starters I didn't read it.  

OTOH I also agree with the drift of pages like <http://ffii.org>,
that includes a case where "attack" would be putting it mildly.

 Frank

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 26 Oct 2007 18:52:22 -0700

You are reminded of MARID?

That was the last time RMS had one of these write in campaigns. That then led to a counter-write-in campaigns.

Lets all write Congress while we are at it. 

> -----Original Message-----
> From: Frank Ellermann [mailto:[email-masked]] 
> Sent: Friday, October 26, 2007 5:57 PM
> To: [email-masked]
> Subject: DOS (was: Experimental makes sense for tls-authz)
> 
> Brian E Carpenter wrote:
> 
> > The DOS attack on this list seems to be from people who 
> haven't read 
> > RFC 2026 and use meaningless phrases like "experimental standard."
> 
> or similar kind of miss the point.  As a "campaign" it 
> reminded me of the weird "yes, we will deploy sender-id" 
> parade in MARID.
> 
> Other messages were perfectly on topic, apparently from 
> concerned folks.  I agree with the drift in the rest of your 
> message, but of course I won't say anything about the 
> specific I-D in an IETF Last Call, for starters I didn't read it.  
> 
> OTOH I also agree with the drift of pages like 
> <http://ffii.org>, that includes a case where "attack" would 
> be putting it mildly.
> 
>  Frank
> 
>

---

From: Ben Finney <[email-masked]>
Date: Sat, 27 Oct 2007 15:07:15 +1000

"Joel M. Halpern" <[email-masked]> writes:

> We have published encumbered experimental and informational
> documents on many occasions.  I can see no reason not to do so in
> this case.

The reasons are the same as they have always been. Making a mistake in
the past is no reason to continue making that same mistake.

Software idea patents place control over *every* independent
implementation of an idea in the hands of *one* entity, who then gets
to dictate whatever terms they like. This is unjust, and is a
practical hindrance on every software developer since it adds to the
minefield of ideas that they must avoid using when designing their
code.

Even developers who are not intending to use ideas encumbered by a
particular patent can independently arrive at some specific method
described in that patent, and inadvertantly violate the patent
rules. In such cases the violation will not be discovered for some
unknown amount of time. The burden on software developers thus mounts
with every patent on a software idea.

To allow a technology, encumbered by any known patent holder's
monopoly, as a proposed standard (even experimental or informational
or any other status) is to give legitimacy to this system that
directly harms development of all software, and especially harms the
goal of interoperability that is part of the purpose of a standards
process.

Please explicitly reject technologies from any part of the standards
process that are encumbered by software idea patents. I encourage the
IETF to start by rejecting 'draft-housley-tls-authz-extns'.

-- 
 \               "Holy bouncing boiler-plated fits, Batman!"  -- Robin |
  `\                                                                   |
_o__)                                                                  |
Ben Finney

---

From: Stjepan Gros <[email-masked]>
Date: Sat, 27 Oct 2007 10:21:49 +0200

> hand it over to the RFC editor and be done with it.

Personally, I'm against publishing anything in any kind of RFC that has
unresolved IPR issues.

As for experimental RFC. I think it's not hard to force majority into
it's use, especially if it's a good idea and solves a real problem. If,
e.g. some large web server/browser vendor decides that it's easier to
pay for this patent that to reinvent it, and then implements it, then
the others must follow, and in general, we have interoperability
problems. The most problematic in this case is Open Source, and the fact
is that Open Source can not be ignored, if nothing else, because
Internet was built on such software.

Note that this is the only one, and very simple, scenario to reach the
goal of having Experimental RFC ad hoc standard. And in my opinion, not
so unrealistic. Furthermore, shouldn't be the burden of development of
alternative, non IPR problematic technologies, IETF's task?

Stjepan

---

From: "David Harrington" <[email-masked]>
Date: Sat, 27 Oct 2007 02:28:31 -0700

> From: Joel M. Halpern [mailto:[email-masked]] 
> Sent: Friday, October 26, 2007 12:16 PM
> To: [email-masked]
> Subject: Experimental makes sense for tls-authz
> 
documents 
+1

David Harrington
[email-masked]
[email-masked]

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 27 Oct 2007 15:45:56 +0200

> You are reminded of MARID?

Yes.  And also of the http://noooxml.org/ petition where I violated
my own "never sign any online petition if you don't get a backlink"
rule.    

> That was the last time RMS had one of these write in campaigns.
> That then led to a counter-write-in campaigns.

The "shuffle those deck chairs" thread _here_ wasn't what I had in
mind, it was quite interesting.  The parade of folks stating that
they would deploy sender-id, after not contributing any technical
article, wasn't here, it was on the MARID list in reply to a poll.

Even that was no DOS, identifying hundreds of hit and run posters
on a WG list simple.  Maybe a mad approximation of a DOS.

 Frank
-- 
See also <http://en.wikipedia.org/wiki/MARID> and the corresponding
Plan B: <http://article.gmane.org/gmane.mail.spam.spf.discuss:9928>

---

From: Ben Finney <[email-masked]>
Date: Sat, 27 Oct 2007 09:53:51 +1000

Please explicitly reject technologies from any part of the standards
process that are encumbered by software idea patents. I encourage you
to start with the rejection of 'draft-housley-tls-authz-extns'.