Subject: Consensus Call for draft-housley-tls-authz

From: Tim Polk <[email-masked]>
Date: Fri, 6 Mar 2009 14:26:09 -0500

Folks,

After some time reflecting on the hundreds of messages submitted to  
the IETF discussion list, I have come to several conclusions about  
progressing draft-housley-tls-authz.  I will summarize the conclusions  
up front, then provide the rationale for those decisions in the  
remainder of this message.

1.     Last Call demonstrates that the community does not support  
progression of this document on the standards track, but sufficient  
support exists for publication as an Experimental RFC.

2.     The community would like the TLS working group to develop a  
standards track mechanism for TLS authorization, and strongly prefers  
an unencumbered solution.

3.     Publication of draft-housley-tls-authz should be timed to  
ensure that it does not unduly interfere with acceptance and adoption  
of a standards track solution.

As stated in the Last Call announcement, I had intended to request  
IESG evaluation for publication on the standards track.   It is clear  
that the community does not support publication of this document on  
the standards track.  However, the Last Call comments show rough  
consensus for publication as an Experimental RFC.

If one simply counts the messages sent to the IETF discussion list,  
the conclusion would be that the document should not be published.   
However, I did not weight all comments equally.  In particular, I  
discounted the large volume of messages from the Free Software  
Foundation.  To be clear, these messages were not ignored – they  
represent a viewpoint shared by a significant number of IETF  
participants, and the IETF has a clear preference for unencumbered  
solutions.
However, many of the messages from the FSF campaign stated that it is  
the IETF’s mission to develop unencumbered standards to satisfy the  
FSF.  That is not for the FSF to decide, and is not consistent with  
the IETF’s traditional stance on IPR.  For example:

> We depend on organizations like the Internet Engineering Task Force  
> (IETF) and the Internet Engineering Steering Group (IESG) to  
> evaluate new proposals for standards and make sure that they are not  
> encumbered by patents or any other sort of restriction that would  
> prevent free software users and programmers from participating in  
> the world they define.
>

This position does not align with IETF IPR policy.  It is therefore  
inappropriate to impose the FSF’s requirements on this or any other  
IETF specification.

It is very clear that the community would prefer a standards track  
publication generated through the TLS working group process, assuming  
sufficient interest exists to support the work.  If the TLS working  
group chooses to take on this work, this specification should not be  
published until the standards track solution is published.  This  
ensures that publication of draft-housley-tls-authz does not unduly  
interfere with acceptance and adoption of a standards track solution.

If publication of draft-housley-tls-authz is approved by the IESG but  
delayed in deference to working group activities, I intend to request  
early IANA assignment.   This will permit experimental use of this  
publication while the standards track publication is under development.

Thanks,

Tim Polk

---

From: Kurt Zeilenga <[email-masked]>
Date: Fri, 6 Mar 2009 11:34:19 -0800

On Mar 6, 2009, at 11:26 AM, Tim Polk wrote:

> progressing draft-housley-tls-authz.  I will summarize the  
> conclusions up front, then provide the rationale for those decisions  
> in the remainder of this message.
>
> standards track mechanism for TLS authorization, and strongly  
> prefers an unencumbered solution.

You don't explicitly state so, but are you concluding that consensus  
is that draft-housley-tls-authz is an encumbered solution.

I don't have an opinion here either way as I simply haven't done the  
patent research, nor do I plan to form one.  Nor do I intend to form  
any opinion in this area if and when the IETF produces some other  
solution in this space.

> If publication of draft-housley-tls-authz is approved by the IESG  
> but delayed in deference to working group activities, I intend to  
> request early IANA assignment.   This will permit experimental use  
> of this publication while the standards track publication is under  
> development.

I think if the IESG chooses not to publish draft-housley-tls-authz  
now, the authors should immediately take it RFC Editor for publication  
and the IESG should not object to its timely publication.   In this  
case, the authors should not be asked to wait on a WG effort as they  
have done well, I think, to try to publish this through the IETF.  It  
would be disingenuous for us to now delay independent publication of  
this I-D via the RFC Editor.

Regards, Kurt

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 06 Mar 2009 13:55:58 -0800

At Fri, 6 Mar 2009 14:26:09 -0500,
Tim Polk wrote:
> standards track mechanism for TLS authorization,

I'm not trying to be difficult, but I don't think this is
actually clear, as it's not the question the LC asked.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 06 Mar 2009 13:59:59 -0800

At Fri, 6 Mar 2009 11:34:19 -0800,
> this I-D via the RFC Editor.

This avenue is specifically precluded by RFC 5246: draft-housley-tls-authz
contains new ExtensionType code points, and they can only be
assigned by IETF Consensus:

   -  TLS ExtensionType Registry: Future values are allocated via IETF
      Consensus [RFC2434].  IANA has updated this registry to include
      the signature_algorithms extension and its corresponding value
      (see Section 7.4.1.4).

Obviously, the authors can publish a document without code point
assignments, but it's hard to see what the value of that is.

-Ekr

---

From: Kurt Zeilenga <[email-masked]>
Date: Fri, 6 Mar 2009 13:59:04 -0800

> assignments, but it's hard to see what the value of that is.

The IETF can hold a consensus call on the assignment of code points  
(certainly this question has not been answered by any previous call).   
I would hope folks would place a lessor hurdle upon assignment of code  
points then they do for IETF RFC publication.

-- Kurt

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 06 Mar 2009 14:24:44 -0800

At Fri, 6 Mar 2009 13:59:04 -0800,
> points then they do for IETF RFC publication.

That's not what "IETF Consensus" means in the context of
RFC 2434:

      IETF Consensus - New values are assigned through the IETF
           consensus process. Specifically, new assignments are made via
           RFCs approved by the IESG. Typically, the IESG will seek
           input on prospective assignments from appropriate persons
           (e.g., a relevant Working Group if one exists).

-Ekr

---

From: Kurt Zeilenga <[email-masked]>
Date: Fri, 6 Mar 2009 14:08:04 -0800

>           (e.g., a relevant Working Group if one exists).

Okay, so we're being overly anal here.   Like we can control the world  
of protocol extensions.

-- Kurt

---

From: John C Klensin <[email-masked]>
Date: Fri, 06 Mar 2009 17:38:32 -0500

--On Friday, March 06, 2009 14:08 -0800 Kurt Zeilenga
<[email-masked]> wrote:

>...
> Okay, so we're being overly anal here.   Like we can control
> the world of protocol extensions.

Kurt,

While I agree (and strongly so), there is lots of precedent for
the IESG rejecting parameter registrations because of distaste
for a particular extension, presumably in the hope that "no
registered value" will imply "the unpopular extension idea goes
away".  From a process standpoint, there is no difference
between "we won't let you have a value because there are
identified serious technical flaws and risks with the extension"
and "the IESG finds you and/or your proposal unattractive and
cannot determine that there is community consensus to the
contrary, so you don't get the value".

Of course, if the requester is at all determined, denying the
value assignment rarely works.  Instead, it leads to squatting
on parameter values which, in any sort of limited space, is a
sure path to interoperability problems with applications that
use the values differently and may have registered them.   And
that is probably just a long way of saying "like we can
control...".

      john

---

From: "Lawrence Rosen" <[email-masked]>
Date: Fri, 6 Mar 2009 14:58:10 -0800

> consensus for publication as an Experimental RFC.

I do not understand why an "Experimental RFC" is different in principle from
a "standards track RFC" when it comes to patents, since even experimental
use of patented technology is an infringement. However,...

As a compromise and as an IETF experiment for this one TLS proposal, I
suggest that we try to apply the procedure described in the W3C Patent
Policy, section 7, "Exception Handling", as adapted to conform to the IETF
mode of operation. 
[See http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Exception] 

Specifically that would mean:

1. IETF forms a PAG (or IETF WG equivalent) of volunteers to analyze the
patent disclosure and the proposed technology, and to determine what
licenses are necessary and available for full implementation anywhere in the
world.

2. The PAG recommends whether, and on what licensing terms, to secure
necessary technology for the proposed RFC.

3. Meanwhile, the WG continues its work.

Nothing would preclude later decisions, in accordance with normal IETF
consensus procedures, to adopt or not adopt a patent-encumbered standard.
[See in particular section 7.5 of the W3C Patent Policy.]

/Larry Rosen

Lawrence Rosen
Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com)
3001 King Ranch Road, Ukiah, CA 95482
707-485-1242 * cell: 707-478-8932 * fax: 707-485-1243
Skype: LawrenceRosen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Tim Polk
> Sent: Friday, March 06, 2009 11:26 AM
> To: [email-masked]
> Subject: Consensus Call for draft-housley-tls-authz
> 
> Folks,
> 
> Foundation.  To be clear, these messages were not ignored - they
> the IETF's mission to develop unencumbered standards to satisfy the
> the IETF's traditional stance on IPR.  For example:
> 
> inappropriate to impose the FSF's requirements on this or any other
> IETF specification.
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Sam Hartman <[email-masked]>
Date: Fri, 06 Mar 2009 18:01:23 -0500

>>>>> "Kurt" == Kurt Zeilenga <[email-masked]> writes:

    >>>
    >> That's not what "IETF Consensus" means in the context of RFC
    >> 2434:
    >> 
    >> RFCs approved by the IESG. Typically, the IESG will seek input
    >> on prospective assignments from appropriate persons (e.g., a
    >> relevant Working Group if one exists).

    Kurt> Okay, so we're being overly anal here.  Like we can control
    Kurt> the world of protocol extensions.

For the record, I would support an effort to relax TLS's IANA
registration policies.  I will not be the primary person behind such
an effort: my ocean boiling energy is limited.

---

From: Kurt Zeilenga <[email-masked]>
Date: Fri, 6 Mar 2009 15:14:27 -0800

Since Eric pointed out process issues with the independent publication  
approach...

While I concur with:
     the Last Call comments show rough consensus for publication as an  
Experimental RFC.

I do not feel it appropriate to further delay the publication of this  
I-D as an Experimental RFC.

I urge the IESG to approve this document as an Experimental RFC on the  
IETF stream.

-- Kurt

---

From: John C Klensin <[email-masked]>
Date: Fri, 06 Mar 2009 18:20:57 -0500

--On Friday, March 06, 2009 14:58 -0800 Lawrence Rosen
<[email-masked]> wrote:

>...
> I do not understand why an "Experimental RFC" is different in
> principle from a "standards track RFC" when it comes to
> patents, since even experimental use of patented technology is
> an infringement. However,...

Larry, just to try to answer the implied question...

Remember that the RFC series contains many documents that are
not standards, some of which have not significantly passed
through the IETF and some of which few people would actual
consider implementing -- not because of patent restrictions, but
because of what they are.  To try to suggest that nothing should
be published in the series that has any encumbrances would be a
huge step, possibly justified on the basis of a philosophical
war on patents, but hard to justify on any other basis -- after
all, reading about an encumbered technology for purposes of
education, etc., is not an infringement, as others (and I think
you) have explained on this list more than once.

So the answer to your question is that Experimental RFCs are
different from Standards Track ones because, among other things,
there is no implicit IETF recommendation of implementation and
deployment of the technology and because part of the purpose of
publication is educational.   In addition, while I take your
point that experimental use is infringing (my recollection is
that there are some fine points there if the use is strictly to
learn about the invention, but you are the expert), no one sane
would try to deploy a product strictly on the basis of an
Experimental Protocol publication (with or without patent
involvement).  I would also imagine that, all other things being
equal, some people's risk assessment would be different for
small-scale experimental uses than for larger-scale product
development and deployment.

    john

---

From: Kurt Zeilenga <[email-masked]>
Date: Fri, 6 Mar 2009 16:07:29 -0800

On Mar 6, 2009, at 2:58 PM, Lawrence Rosen wrote:

> principle from

I note that advancement on the standard track can hinge on  
implementors ability to obtain suitable licenses of essential rights.

> [See http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Exception 

Exception to what?  That is, which IETF policy do you think precludes  
the IETF from publication this I-D as supported by (apparent) consensus?

-- Kurt

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 07 Mar 2009 01:41:33 +0100

> support exists for publication as an Experimental RFC.

How can that support be demonstrated?  I don't see how we can say
anything about support for experimental unless the community is asked to
answer that question.  That question has been asked in an earlier last
call:

http://article.gmane.org/gmane.ietf.announce/21152

Presumably, no support for publishing on experimental could be
demonstrated at that time.

Btw, the patent disclaimer #833 is still not available from the IETF web
site.  The community can no longer evaluate the complete patent license
history around the document.  I believe this violates BCP79:

      Copies of IPR disclosures made to the IETF Secretariat and any
      assurances of licenses to be made available, or the result of an
      attempt made to obtain a general license or permission for the use
      of such proprietary rights by implementers or users of this
      specification can be obtained from the IETF on-line IPR repository
      at http://www.ietf.org/ipr.

By removing earlier disclaimers, I believe the IETF has moved into the
territory of making decision about the validity of patent related
claims.

/Simon

---

From: [email-masked]
Date: Sat, 07 Mar 2009 17:29:24 -0800 (PST)

> away".

There are indeed lots of precedents for this. And speaking as someone who, as
media types reviewer, has had had to clean up the mess as best I could when we
were overly restrictive with one of these things, there is also precedent that
doing this can be a REALLY bad idea.

> From a process standpoint, there is no difference

Exactly so.

> use the values differently and may have registered them.

And in the case of a large space, the registry ends up being incomplete,
thereby diminishing its value. If the unregistered value ends up getting
deployed, the lack of registry information, including but not limited to
security considerations, can lead to operational problems.

And depending on the shape of the parameter space there can still be collisions
leading to interop problems.

> And that is probably just a long way of saying "like we can
> control...".

But in believing we can we can things even worse.

				Ned

---

From: Christian Huitema <[email-masked]>
Date: Sat, 7 Mar 2009 19:38:53 -0800

> There are indeed lots of precedents for this. And speaking as someone
> who, as media types reviewer, has had had to clean up the mess as best I could
> when we were overly restrictive with one of these things, there is also
> precedent that doing this can be a REALLY bad idea.

I agree with Ned. The main purpose of the registry should be to document what is out there, not to act as a gatekeeper. Even when a protocol is not a full standard, having a public documentation is useful. Documentation enables filtering, monitoring, even debugging.

By the way, other institutions have found ways to decouple number collision avoidance and registration. IETF protocols use short fields for parameter identifiers, small number spaces that effectively mandate registration in order to avoid collisions. This is an engineering decision that trades administrative hassles for shorter messages. It is not the only choice. Other design have used Object Identifiers (SNMP, ASN.1), or Universal Resource Locators (most W3C protocols). OID and URL requires some amount of registration, to obtain a node in the hierarchy, but allow for decentralized allocation of identifiers in these hierarchies. If you don't want to use a hierarchy, you can also use GUID, essentially a 128 bit random number. Open extensibility with OID, URL or GUID is, in my opinion, a better design than relying on registries for number allocations.

-- Christian Huitema

---

From: David Conrad <[email-masked]>
Date: Sat, 7 Mar 2009 17:49:54 -1000

Hi,

On Mar 7, 2009, at 5:38 PM, Christian Huitema wrote:
> I agree with Ned. The main purpose of the registry should be to  
> document what is out there, not to act as a gatekeeper. Even when a  
> protocol is not a full standard, having a public documentation is  
> useful. Documentation enables filtering, monitoring, even debugging.

This is not how IANA staff have been directed to maintain the IETF  
registries.

Regards,
-drc

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Sat, 7 Mar 2009 23:07:33 -0500

On Sat, 7 Mar 2009 17:49:54 -1000
David Conrad <[email-masked]> wrote:

> > document what is out there, not to act as a gatekeeper. Even when
> > a protocol is not a full standard, having a public documentation
> > is useful. Documentation enables filtering, monitoring, even
> > debugging.
> 

That is not how IANA staff has been directed to maintain *some* IETF
registries.  Typically, the RFC that creates a registry specifies the
conditions for it.  It may be "IETF consensus", or a whole host of
other options; see RFC 5226 for more details.  The issue here is
two-fold: what are the specified conditions for this particular
registry, and was the decision of the TLS WG correct when it specified
them?

Christian's note suggests other code point design strategies that don't
run into the "limited number of small integers" problem.  Very true --
and those strategies are explicitly recognized by 5226.  There may be a
problem here, but it's not the general IANA problem, it's the specific
decision made once upon a time.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

---

From: John C Klensin <[email-masked]>
Date: Sat, 07 Mar 2009 23:53:47 -0500

--On Saturday, March 07, 2009 12:31 -0500 Richard M Stallman
<[email-masked]> wrote:

>     So the answer to your question is that Experimental RFCs
> are     different from Standards Track ones because, among
> other things,     there is no implicit IETF recommendation of
> implementation and     deployment of the technology and
> because part of the purpose of     publication is educational.
 
> If a proposed standard is not freely implementable, in general
> it should not be accorded any status beyond a mere "proposal".

But an experimental RFC is not a Proposed Standard, a proposed
standard, a document that is in the process of being considered
for standardization, or any other sort of standard or
prestandard.

    john

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 08 Mar 2009 16:41:59 +0100

> publication while the standards track publication is under development.
In other words: Tim does NOT want to try to block the codepoint 
registration, even if the document's publication as an RFC is delayed.

I kind of agree with Ned's point about trying to regulate the world of 
what we don't like by refusing to list things with IANA that we know 
exist (that is, it's stupid), but this isn't what Tim (and, hopefully, 
the IESG) is trying to do in this case.

                            Harald

---

From: Kurt Zeilenga <[email-masked]>
Date: Sun, 8 Mar 2009 09:45:23 -0700

On Mar 8, 2009, at 8:41 AM, Harald Alvestrand wrote:

> but this isn't what Tim (and, hopefully, the IESG) is trying to do  
> in this case.

I advocate publication of this document NOW as Experimental.  Tim  
apparently is suggesting delaying the document for some yet-to-be- 
chartered, yet-to-started WG effort.  I oppose this delay.

It's my view is that implementors have sufficient technical and IPR  
information to determine whether or not to implement this  
specification.  Further discussions of the specific IPR issues  
surrounding this I-D is, IMO, a waste of time.  In the end, each  
implementor needs to make an independent judgement as whether to  
implement this (or any other specification) as they are libel from  
their own infringement of any valid IPR claims (and/or at risk of  
litigation for any valid-or-not IPR claims).

-- Kurt

---

From: Richard M Stallman <[email-masked]>
Date: Sat, 07 Mar 2009 12:31:57 -0500

publication is educational.

If a proposed standard is not freely implementable, in general it
should not be accorded any status beyond a mere "proposal".

I do see one possible exception.  It is ok for the proposal to start
moving along the path towards becoming a standard if it can't possibly
reach that point before the patents expire.

---

From: Richard M Stallman <[email-masked]>
Date: Sun, 08 Mar 2009 18:12:13 -0400

There are people who propose this as a standard; in factual terms,
that makes it a proposed standard.  Whether or not the fact of
publication as an experimental RFC would make it one, it is one
already.

If publication as an experimental RFC entails any sort of approval,
such approval is what a patented proposed software standard should not
get.

---

From: SM <[email-masked]>
Date: Mon, 09 Mar 2009 11:07:10 -0700

>publication as an experimental RFC would make it one, it is one

In IETF terms:

   "Internet specifications go through stages of development, testing,
    and acceptance.  Within the Internet Standards Process, these stages
    are formally labeled "maturity levels"."

   "The entry-level maturity for the standards track is "Proposed
    Standard".  A specific action by the IESG is required to move a
    specification onto the standards track at the "Proposed Standard"
    level."

As the draft was not approved by the IESG as a "Proposed Standard", 
the fact is that most people in the IETF community would not consider 
it as a proposed standard.

   "The "Experimental" designation typically denotes a specification that
    is part of some research or development effort.  Such a specification
    is published for the general information of the Internet technical
    community and as an archival record of the work, subject only to
    editorial considerations and to verification that there has been
    adequate coordination with the standards process."

Publication as an "Experimental" RFC does make a document a 
standard.  The "Status of This Memo" which is prominently displayed 
on the first page of the RFC mentions that:

   "This memo defines an Experimental Protocol for the Internet
    community.  It does not specify an Internet standard of any kind."

Regards,
-sm

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 9 Mar 2009 14:14:28 -0400

On Mon, 09 Mar 2009 11:07:10 -0700
SM <[email-masked]> wrote:

>    "The "Experimental" designation typically denotes a specification
> that is part of some research or development effort.  Such a
> specification is published for the general information of the
> Internet technical community and as an archival record of the work,
> subject only to editorial considerations and to verification that
> there has been adequate coordination with the standards process."
> 

Put another way, an Experimental RFC is no more an IETF standard than a
conference or journal publication.  Someone has done something that is
perceived to be of enough interest to the community to publish as an
RFC, but it is manifestly *not* an IETF standard of any kind.

---

From: SM <[email-masked]>
Date: Mon, 09 Mar 2009 11:35:46 -0700

>RFC, but it is manifestly *not* an IETF standard of any kind.

You said it better than me.

There was a mistake in my previous message. A "not" was omitted.  The 
correct sentence is:

   "Publication as an "Experimental" RFC does not make a document a standard."

Regards,
-sm

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 9 Mar 2009 14:20:45 -0700

1) Patents happen, get over it.
 
Under the current patent system a company that does not apply for patents risks finding that a patent troll has applied for their idea. This is perjury, it should be prosecuted. But it is not. And fighting that type of lawsuit has cost comapnies involved in IETF $5 million or more to have a completely ridiculous claim thrown out.
 
So nobody should be appologizing for applying for patents. It is simply a necessary concern for any major company.

2) Very few patents are so essential that they are worth more than interoperability.
 
In the communications world the value lies in the ability to connect. There are very few technologies that are so compelling that the value of the enhancement to communication that they bring is greater than the cost of a smaller communications network. The only example I can think of in the history of the Internet is public key cryptography and the original Diffie Hellman/RSA patents. 

3) It follows that the only allowable patents are on non-essential aspects
 
If someone wants to use a proprietary encryption cipher with SMTP, let them. And make sure that the standard specifies how to do so in order that unencumbered implementations can take advantage of the feature when it becomes available.

4) In rare instances a standard can turn a worthless patent into a valuable one.
 
But only if the exercise of the patent is made essential to the communications role. As in the audio and video codecs that became essential due to being required for DVD.
 
Sometimes groups try to spring a patent by surprise. That is irritating. But it happens much less now that patent applications are no longer secret in the US.
 
There is definitely a problem with IETF rules in this area. In my view the IPR regime is a part of the requirements for the spec. 

5) Blanket rules give purported patent claims too much power
 
Most US patents are completely worthless as far as enforcement goes. The main use of patents is to persuade Venture Capital to part with funds and some small time trolls extort license fees.
 
But if the IETF were to adopt a hard rule that said that it would adopt no standard with a proprietary claim then people will quickly start claiming a proprietary interest in technologies that they don't want to happen for whatever reason.
 
There is no practical means for the IETF to adjuicate on such claims. Its easy enough to propose forming a board, but who would sit on it? Who would have the legal and technical skills and want to accept the liability?
 
The IPR working group turned into a farce because the two principal sides that showed up were (1) the companies with big patent portfolios that they would rather not have to think about, still less search for potential claims and (2) professional expert witnesses in patent cases.

Ob. Disclosure: Yes, I do offer consulting and expert witness services in IPR disputes. This started as a dodge I learned from Alan Shiffman, once you announce you are offering services as an expert witness in an area, you are less likely to be dragged into somebody else's patent dispute as has happend from time to time, or at least if you do get dragged in you at least get paid.

________________________________

From: [email-masked] on behalf of Richard M Stallman
Sent: Sun 3/8/2009 6:12 PM
To: John C Klensin
Cc: [email-masked]; [email-masked]
Subject: Re: Consensus Call for draft-housley-tls-authz

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 9 Mar 2009 14:30:41 -0700

Steve,
 
Endorsment of a standard implies two (separable) assertions:
 
1) Do 'X'.
2) If you are going to do 'X', then do it by doing 'Y'

An experimental specification on the other hand contains the assertions
 
1) It might be desirable to do 'X'
2) It might be possible to do 'X' by doing 'Y'

So an experimental RFC does go part way towards a standard. But where it falls short is precisely the area where issues such as IPR come in. In particular the question of whether the need for 'X' justifies the IPR encumbrance.
 
If the market, of its own accord suddenly goes off and starts implementing Y, it becomes pretty clear that there is a need.
 
But offhand, I can really think of no example other than public key crypto where this was the case.

From: [email-masked] on behalf of Steven M. Bellovin
Sent: Mon 3/9/2009 2:14 PM
To: SM
Cc: [email-masked]; [email-masked]
Subject: Re: Consensus Call for draft-housley-tls-authz

---

From: Stephan Wenger <[email-masked]>
Date: Mon, 09 Mar 2009 15:35:31 -0700

> RFC, but it is manifestly *not* an IETF standard of any kind.

The IETF might view it this way.  Large parts of the (standardization) world
does not.  One example in my field of work is FLUTE, and the surrounding
infrastructure of frameworks and FEC codes.  To the best of my recollection,
these specifications were originally issued as Experimental RFCs, for
reasons of congestion control worries.  (They are also heavily encumbered,
but that was not really an issue according to my recollection.)  The
Experimental status did not stop 3GPP and other SDOs to normatively
reference them, and treat them just like any other IETF RFC.  Note that 3GPP
could NOT do that with a journal publication...  I could name more examples,
both when it comes to referencing SDOs and referenced RFC types (including
normative references to at least Historic, Obsolete, Informational).

Stephan

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 9 Mar 2009 18:40:51 -0400

On Mon, 09 Mar 2009 15:35:31 -0700
Stephan Wenger <[email-masked]> wrote:

> The IETF might view it this way.  Large parts of the
> (standardization) world does not.  One example in my field of work is
> FLUTE, and the surrounding infrastructure of frameworks and FEC
> codes.  To the best of my recollection, these specifications were
> originally issued as Experimental RFCs, for reasons of congestion
> control worries.  (They are also heavily encumbered, but that was not
> really an issue according to my recollection.)  The Experimental
> status did not stop 3GPP and other SDOs to normatively reference
> them, and treat them just like any other IETF RFC.  Note that 3GPP
> could NOT do that with a journal publication...  I could name more
> examples, both when it comes to referencing SDOs and referenced RFC
> types (including normative references to at least Historic, Obsolete,
> Informational).

This is, I think, the second- or third-most-common topic on the IETF
list: should we rename the document series to prevent that...  (#1 is
non-ASCII formats for RFCs; #2 -- by volume of postings, rather than
frequency of discussion -- might be IPR.)

Other than giving up the RFC label for Experimental documents, it's
hard to see what the IETF can do.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 9 Mar 2009 21:38:05 -0700

When British Leyland shut down the assembly line for the Triumph TR7 they found a note that said, 'Your proposal to prime and paint the TR7 bodyshells before moving them a hundred miles in open rail cars to the assembly plant has been made before. If only stopping rust was so simple'.
 
The fact that a proposal has been made before and ignored does not diminish its value.
 
How frequently does a sensible proposal have to be made to receive a susbstantive response?

From: [email-masked] on behalf of Steven M. Bellovin
Sent: Mon 3/9/2009 6:40 PM
To: Stephan Wenger
Cc: SM; [email-masked]; [email-masked]
Subject: Re: Consensus Call for draft-housley-tls-authz

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 10 Mar 2009 06:40:09 -0700

Please note that I didn¹t make a proposal.  I can live quite well with a
misalignment of IETF terminology and reality as perceived outside the IETF.
So can the industry, I think.  What I was commenting on is that it does not
make sense to me to re-iterate the mantra of ³Experimental RFCs not being
standards², when there is ample evidence that a large percentage of the
outside world views this differently.
It seems to take only the intervention one of the (security / congestion
control / anti-patent / ...) communities of the IETF to move a document
intended for standard¹s track to the, arguably, second-class RFC status
known as ³Experimental².  Again, that¹s not a problem for me, for the reason
stated above.  
Stephan

On 3/9/09 9:38 PM, "Hallam-Baker, Phillip" <[email-masked]> wrote:

> When British Leyland shut down the assembly line for the Triumph TR7 they
> found a note that said, 'Your proposal to prime and paint the TR7 bodyshells
> before moving them a hundred miles in open rail cars to the assembly plant has
> been made before. If only stopping rust was so simple'.
>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 10 Mar 2009 07:09:12 -0700

I am the last person to propose making changes to IETF procedures to suit RMS better.
 
The reason to make changes is to increase influence.
 
Experimental evidence (take any recent election you choose) strongly suggests that the human logical reasoning system has the Post hoc ergo propter hoc facilicy wired in. Basically the brain is a big, mushy association engine. If two events happen together frequently enough, an expectation is formed that one will lead to another. Contrawise, the causal relationship is weakened each time a contrary example is seen.
 
At the moment the procedures ensure that there is almost no visible correlation between the success of a protocol and progress in IETF process.

From: Stephan Wenger [mailto:[email-masked]]
Sent: Tue 3/10/2009 9:40 AM
To: Hallam-Baker, Phillip; Steven M. Bellovin
Cc: SM; [email-masked]; [email-masked]
Subject: Re: Consensus Call for draft-housley-tls-authz

Please note that I didn't make a proposal.  I can live quite well with a misalignment of IETF terminology and reality as perceived outside the IETF.  So can the industry, I think.  What I was commenting on is that it does not make sense to me to re-iterate the mantra of "Experimental RFCs not being standards", when there is ample evidence that a large percentage of the outside world views this differently.
It seems to take only the intervention one of the (security / congestion control / anti-patent / ...) communities of the IETF to move a document intended for standard's track to the, arguably, second-class RFC status known as "Experimental".  Again, that's not a problem for me, for the reason stated above.  
Stephan

---

From: Richard M Stallman <[email-masked]>
Date: Tue, 10 Mar 2009 05:11:03 -0400

It depends whether one interprets the term according to IETF procedures
or according to everyday understanding of English.

How high is the threshold, in practice, for getting something
published as an experimental RFC?  If one can easily get just about
anything published that way on request, that means it requires very
little approval.  In that case I agree that it implies little also.

But if it is necessary to convince someone that XYZ merits publication
as an experimental RFC, that IS a kind of approval.

I don't know which of these two is the case.

---

From: "Lawrence Rosen" <[email-masked]>
Date: Tue, 10 Mar 2009 10:22:51 -0700

Stephan Wenger wrote:

Please note that I didn't make a proposal.  I can live quite well with a
misalignment of IETF terminology and reality as perceived outside the IETF.
So can the industry, I think.  What I was commenting on is that it does not
make sense to me to re-iterate the mantra of "Experimental RFCs not being
standards", when there is ample evidence that a large percentage of the
outside world views this differently.
It seems to take only the intervention one of the (security / congestion
control / anti-patent / ...) communities of the IETF to move a document
intended for standard's track to the, arguably, second-class RFC status
known as "Experimental".  Again, that's not a problem for me, for the reason
stated above.  

Hi Stephan,

The "misalignment of IETF terminology and reality" continues to bother me. I
hope you don't expect the FOSS part of our software industry to live with
that misalignment just because big companies can afford to evaluate patent
risks in private.

Since we are talking about a specific patent disclosure here and not some
abstract terminology, then *experimental* status for draft-housley-tls-authz
makes not one tiny bit of legal difference. Patents deal with *use* and
don't care about the purpose. IETF contributors can write about TLS all we
want, and maybe even draft software to implement that proposed RFC, but the
moment we execute code on a computer we would potentially infringe.
Experiment or for actual commercial purposes, it would still be an
infringement. We could be liable potentially for years' worth of damages. We
could yet be faced with an injunction that would make our standardization
and implementation efforts utterly useless. 

Isn't that the "reality"? If we use different terminology to identify this
IETF RFC, how does that change anything?

Not that we have any good reason to believe that the disclosed patent claims
will be issued for real; this is merely a patent application, and we're all
still speculating randomly about future risks. 

Best regards,

/Larry

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 10 Mar 2009 10:31:03 -0700

At 10:22 AM -0700 3/10/09, Lawrence Rosen wrote:
>If we use different terminology to identify this IETF RFC, how does that change anything?

Because you earlier complained about IETF standards having known patent issues. Now we are talking about experimental protocols that are not standards.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 10 Mar 2009 14:34:37 -0400

On Tue, 10 Mar 2009 14:21:00 -0400
Richard M Stallman <[email-masked]> wrote:

> Steve Bellovin wrote:
> 
>     Other than giving up the RFC label for Experimental documents,
> it's hard to see what the IETF can do.
> 
> Another thing the IETF could do is stop publishing this sort of
> document.  Anyone that might ask the IETF to publish one can easily
> publish it on Internet himself.
> 
> In the cases where an experimental RFC is useful, how is it more
> useful for the Internet than publication of the same information in
> some other way?  Long ago, before search engines, perhaps interested
> people would not have found it elsewhere, but that isn't true now.
> 
For the same reason that people publish in conferences and journals --
experimental RFCs are peer-reviewed and accessible via a stable
mechanism.

Of course, the notion of peer review, especially for for-profit
journals, has also been challenged, and for the same reasons you cite.

---

From: SM <[email-masked]>
Date: Tue, 10 Mar 2009 12:04:13 -0700

>or according to everyday understanding of English.

I agree.  That is why I specified IETF community in my reply.

>little approval.  In that case I agree that it implies little also.

RFCs are published by the RFC Editor.  To keep things easy, I'll say 
that there are IETF Submissions and Independent Submissions.  IETF 
Submissions go through the IETF Process.

Anyone can write an Internet-Draft and submit it to the RFC Editor as 
Independent Submission.  The Internet-Draft can be published as an 
RFC as long as there is no conflict with the IETF Process.  The RFC 
Editor will select someone competent in the subject of the document 
to review it.  Although it may be somewhat overlooked, having 
Independent Submissions provides people outside the IETF community 
with a means to publish their ideas and disseminate them at no cost.

"Experimental" RFCs can be IETF Submissions or Independent 
Submissions.  I'll leave it for someone else to comment on the 
threshold for publishing an Independent Submission as 
"Experimental".  For IETF Submissions, the threshold depends on the 
quality (and not quantity) of comments the Internet-Draft receives 
from the IETF community.  The document also goes through an IESG evaluation.

Every Internet-Draft that is submitted to the RFC Editor does not end 
up as a RFC.  For example, in January 2009, 26 Internet-Drafts were 
submitted and 11 were published as RFCs.  By having a high threshold, 
the RFC Editor would set a barrier of entry that affects individuals 
the most.  An author can get a document published as an RFC if the 
subject of the document fits within the RFC Series and it is in 
reasonable editorial shape and technically sound.  A request for 
publication as "Experimental" may get rejected if the publication is 
deemed "harmful".  I'll say that the threshold is not that high.

>as an experimental RFC, that IS a kind of approval.

Yes, you will have to convince someone that your proposal merits 
publication as an "Experimental" RFC.  If it wasn't for that, the RFC 
Series would be turned into an index of the Web.

>publish it on Internet himself.

Such a measure affects individuals more as they may not have the 
clout or the means to disseminate their publications.

>people would not have found it elsewhere, but that isn't true now.

The RFC Series predates the IETF.  It is a repository of technical 
information and, hopefully, it will still be around when I am no 
longer around.  I don't know how search engines will be years from 
now but there is one thing I know.  As long as the tradition is 
preserved, the Internet community will have a mechanism to publish 
technical information.

Regards,
-sm

---

From: "Lawrence Rosen" <[email-masked]>
Date: Tue, 10 Mar 2009 12:28:21 -0700

Paul Hoffman replied: 
> Because you earlier complained about IETF standards having known patent
> issues. Now we are talking about experimental protocols that are not
> standards.

And I am saying that it doesn't make a bit of difference legally. If you
infringe for experimental reasons, that is still infringement.

I don't think we should publish under the IETF imprimatur if there are
*unresolved* known patent issues about which ignorant and cautious people
continue to speculate blindly. Why should any of us waste time and money on
IETF and commercial and FOSS "experiments" if they may cost us too much
money downstream? 

Its authors are free to publish draft-housley-tls-authz already. Google is
free to index that document already. Why do you insist upon granting it an
IETF RFC status without first deciding if the disclosed patent claims are
likely bogus?

/Larry

> From: Paul Hoffman [mailto:[email-masked]]
> Sent: Tuesday, March 10, 2009 10:31 AM
> To: [email-masked]; [email-masked]
> Subject: RE: Consensus Call for draft-housley-tls-authz
> 
> Because you earlier complained about IETF standards having known patent
> issues. Now we are talking about experimental protocols that are not
> standards.
> 
> --Paul Hoffman, Director
> --VPN Consortium

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 10 Mar 2009 13:23:59 -0700

Institute the policy as you suggest and you have just given the patent
trolls the power to place an indefinite hold on any IETF proposal.

So instead of extorting payment for exercise of the claims they hold the
standard hostage.

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Lawrence Rosen
> Sent: Tuesday, March 10, 2009 3:28 PM
> To: 'Paul Hoffman'; [email-masked]
> > >If we use different terminology to identify this IETF RFC, 
> how does 
> > >that
> > change anything?
> 
> Paul Hoffman replied: 
> > Because you earlier complained about IETF standards having known 
> > patent issues. Now we are talking about experimental protocols that 
> > are not standards.
> 
> And I am saying that it doesn't make a bit of difference 
> legally. If you infringe for experimental reasons, that is 
> still infringement.
> 
> *unresolved* known patent issues about which ignorant and 
> cautious people continue to speculate blindly. Why should any 
> of us waste time and money on IETF and commercial and FOSS 
> "experiments" if they may cost us too much money downstream? 
> 
> Its authors are free to publish draft-housley-tls-authz 
> already. Google is free to index that document already. Why 
> do you insist upon granting it an IETF RFC status without 
> first deciding if the disclosed patent claims are likely bogus?
> 
> /Larry
> 
> 
> > >If we use different terminology to identify this IETF RFC, 
> how does 
> > >that
> > change anything?
> > 
> > Because you earlier complained about IETF standards having known 
> > patent issues. Now we are talking about experimental protocols that 
> > are not standards.
> > 
> > --Paul Hoffman, Director
> > --VPN Consortium
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Mar 2009 09:32:27 +1300

Larry,

On 2009-03-11 08:28, Lawrence Rosen wrote:
...
> IETF and commercial and FOSS "experiments" if they may cost us too much

Then we can just fold up our tents and slip away now. I'm sure you've
looked at more patents than I have, but in my experience there is always
uncertainty in someone's mind whether a particular patent does or doesn't
read on a particular specification. In fact the uncertainty will be whether
a specific claim in the patent reads on a specific part of the spec, and
whether there is in fact prior art on that specific point. I'd say that
in practice, there are *always* unresolved issues, and the judgment call
is whether they are serious enough to hold up publication.

Not to mention, of course, the permanent uncertainty about whether
there are any submarine patents waiting offshore, owned by someone who
is carefully not participating.

So, while we can certainly discuss ways to make things better, I believe
we can never make them perfect.

    Brian

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 10 Mar 2009 13:36:08 -0700

>infringe for experimental reasons, that is still infringement.

And no one has said any different. Please stay on topic. We are not talking about standards, we are talking about un-standard protocols or, in this case, extensions.

>continue to speculate blindly.

Fine. You don't have to be part of "we". There are plenty of different "we" that embrace different patent policies. Or are you trying to convert us from one religion to another?

>Why should any of us waste time and money on

You probably shouldn't. By all means, stop implementing draft-housley-tls-authz if you feel that way. Ditto for any other non-standard protocol that has ever been published.

>IETF RFC status without first deciding if the disclosed patent claims are

Because there may be people who will want to implement the protocol in an interoperable fashion. 'Twas ever thus.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Lawrence Rosen" <[email-masked]>
Date: Tue, 10 Mar 2009 16:08:23 -0700

> trolls the power to place an indefinite hold on any IETF proposal.

I have never suggested placing any kind of hold on any IETF proposal.
Propose all you want. Publish the proposal. Try to convince people that it
is a good proposal. Establish a WG to design away....

An IPR Disclosure has been filed in accordance with standard IETF procedure.

What I've suggested is due diligence to determine the implications of that
disclosure. Only THEN is publication as an IETF RFC justified. Experimental
or not, industry standard or not, an IETF RFC encourages companies to
implement and use the technology, and that may be patent infringement.

Or it may be a bogus IPR disclosure that intelligent people could decide to
ignore.

I am certainly not giving patent trolls any more power than they deserve. In
fact, I hope to dispose of this particular TLS patent troll once we get a
small group of patent attorneys to analyze the IPR disclosure like
professionals do it. 

Just like W3C does it. They don't give patent trolls power either.

/Larry

> From: Hallam-Baker, Phillip [mailto:[email-masked]]
> Sent: Tuesday, March 10, 2009 1:24 PM
> To: [email-masked]; Paul Hoffman; [email-masked]

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 10 Mar 2009 16:26:35 -0700

When you say IETF RFC, do you also include RFC-Editor track informational RFCs?

EHL

On 3/10/09 3:08 PM, "Lawrence Rosen" <[email-masked]> wrote:

/Larry

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 10 Mar 2009 16:46:44 -0700

> When you say IETF RFC, do you also include RFC-Editor track

There's no consensus requirement for an informational document, In point
of fact even the coordination clause in 2026 4.2.3 is not an obstacle to
publication...

> ------------------------------------------------------------------------
>

---

From: [email-masked]
Date: Tue, 10 Mar 2009 16:07:51 -0700 (PDT)

> reference them, and treat them just like any other IETF RFC.

OK, let's try a little thought experiment. Suppose 3GPP or some other SDO
really wants to build on some work slated for publication as an experimental or
informational RFC, but for whatever reason that publication was blocked.

Do you seriously think this would stop them? Of course it wouldn't! They'll
simply get the rights from the author(s) - who in all liklihood will be happy
to grant them - and arrange to publish the specification themselves and cut the
IETF out of the process entirely.

If you want a specific example of where this has happened, consider P-IMAP.
Publication of this as an RFC was blocked in the IETF due to the LEMONADE WG
doing work in the area, but that didn't stop another SDO from taking it and
publishing it as their own standard.

> Note that 3GPP could NOT do that with a journal publication...

Sure they could. They can either get permission to republish the journal
article or, if that's not possible, they can simply write their own independent
specification of the protocol or whatever.

Face it: The existence of an expermental RFC to reference is at most a small
convenience for other SDOs hell-bent on standardizing something the IETF is
reluctant or unwilling to put on the standards track. The lack of that
expermental RFC isn't going to stop them if they really want that standard.

In fact I can give anecdotes where the publication of a document as
experimental with an IESG warning acted as a deterrent to adoption. Before SPF
came out as an experimental specification we received a fair number of requests
for support. After it came out and people were able to make an informed
decision, we saw both fewer requests as well as a couple of people reevaluating
their earlier requests in light of the added information that was now
available.

> I could name more examples,

And I can name other examples where RFC publication was blocked but
standardization occurred elsewhere nevertheless.

We really need to get over ourselves here. We may like to think we're the
gatekeepers against standardization of bad stuff, but we're not. There are
simply too many SDOs churning out specifciations these days.

In fact it is precisely because we've tried to set ourselves up in many cases
as the final arbiters of what's "good for the net", resorting on occasion to
sleazy process tricks to try and stall or prevent publication of stuff that
offends the delicate olfactory apparatus of someone currently in power, that we
find ourselves increasingly routed around as a blockage to what's perceived as
forward progress.

				Ned

---

From: Theodore Tso <[email-masked]>
Date: Tue, 10 Mar 2009 20:59:36 -0400

> small group of patent attorneys to analyze the IPR disclosure like

There is a huge amount of cost and risk in having companies
pariticipating in these sorts of "is this patent valid" discussions.
The liability exposure alone, not to mention concerns about the
potential trebling of damages, might be enough to stop many companies
from declining from participating.  If no one volunteers to show up,
what should happen?  Does the IETF not publish the standard?  Such a
mandatory proposal might also be a sufficient denial-of-service attack
on the organization.

What if some people show up, but they don't represent all sides of the
debate?  Or several hundred crazied FSF'ers show up demanding to be
part of the process?  You keep citing W3C, but what worked well for
them, which involved things like such patent discussions happening
completely secretly and restricted to W3C members only might not work
so well in the IETF context.  In addition, while the W3C standards
might be important enough from a business perspective to justify
having companies send their highly paid patent attorneys to attend
formal meetings might not work so well for standards which are highly
important to the Internet, but which don't represent enough profit
potential to justify the heavyweight W3C approach.  Finally, I'll note
that in the entire history of the W3C, they've only had 3 such
private/secret patent examination teams.  The IETF has a rather higher
number of IPR disclosures in a year, and it's not at all clear the W3C
approach is sufficiently scalable.

						- Ted

---

From: "Lawrence Rosen" <[email-masked]>
Date: Tue, 10 Mar 2009 18:46:59 -0700

Ted Tso wrote:
> The IETF has a rather higher

The vast majority of IETF IPR disclosures are in the form of completely
acceptable non-asserts that satisfy the needs of both proprietary and FOSS
implementers. They pose no problems whatsoever.

Only occasionally does someone submit a disclosure as misleading and
confusing as the one relating to TLS. That is one that needs intelligent
analysis.

I can count on one hand the number of IETF RFCs that FSF and the FOSS
community have objected to in recent years on patent grounds. (How many FSF
campaigns do you remember?) That's certainly scalable. 

/Larry

> From: Theodore Tso [mailto:[email-masked]]
> Sent: Tuesday, March 10, 2009 6:00 PM
> To: Lawrence Rosen
> Cc: [email-masked]

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 10 Mar 2009 19:54:06 -0600

On 3/10/09 7:46 PM, Lawrence Rosen wrote:

> confusing as the one relating to TLS.

TLS itself (RFCs 2246, 4346, 5246) is not affected by the disclosure at
hand. The impact is limited to a particular extension to TLS (and even
then, it seems, only to certain applications of that extension). Please
let us be clear about what is in and out of scope.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 11 Mar 2009 10:27:41 +0100

SM wrote:
> A request for publication as 
> "Experimental" may get rejected if the publication is deemed "harmful".

Does that include legal threats?

---

From: SM <[email-masked]>
Date: Wed, 11 Mar 2009 06:45:07 -0700

>Does that include legal threats?

No.  "Harmful" here should be viewed as "harmful to the work of a 
Working Group" or if the document proposes to use "free" bits for a 
purpose which is contrary to the meaning the standard defines.

Regards,
-sm

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 11 Mar 2009 07:32:35 -0700

At Wed, 11 Mar 2009 02:00:31 -0400 (EDT),
Dean Anderson wrote:
> 
> On Fri, 6 Mar 2009, Lawrence Rosen wrote:
> Historical Note: They tried the experimental route before.  But
> Experimental RFC's aren't sufficient for an IANA code point.

Actually, in this case, an Experimental RFC is sufficient to assign
a code point. The requirement is 2434 IETF Consensus.

-Ekr

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 11 Mar 2009 07:20:34 -0700

On Mar 11, 2009, at 6:45 AM, SM wrote:

> "Harmful" here should be viewed as "harmful to the work of a Working  
> Group"

I think we need to look more at "harmful to the Internet".

I note that the IETF has a long established practice of allowing  
publication of "alternative solutions".  I fully support this practice.

-- Kurt

---

From: [email-masked]
Date: Wed, 11 Mar 2009 11:01:43 -0700 (PDT)

> In other words, "If we don't do it, someone else will."

Not even close. First, you're again totally missing the essential point here:
That an experimental or informational RFC is NOT a standard. So there is no
equivalency between our "doing" an experimental RFC and someone else "doing" a
standard.

Second, AFAIK nobody has even intimated that other standards groups are
planning to standardize this particular proposal.

Third, nobody has said that our publishing something about this - never mind
what - will, as you imply, have any effect on what other SDOs do. In fact my
main point is that our publication practices are unlikely to have any impact at
all.

And finally, to the extent publication as an experimental RFC would have an
effect, it is that it provides a means for people to experiment with the
technology and determine for themselves whether or not it is useful. And that
includes evaluation of IPR issues. There is in fact "running code" that, far
from always leading to increased adoption of a given proposal, publication in
the form of an experimental RFC may in fact expose the problematic nature of a
proposal and lead to its rejection by the community in a fashion which, has the
document never been published, would not have happened.

				Ned

---

From: Richard M Stallman <[email-masked]>
Date: Tue, 10 Mar 2009 14:21:00 -0400

Steve Bellovin wrote:

---

From: Richard M Stallman <[email-masked]>
Date: Tue, 10 Mar 2009 14:21:09 -0400

Under the current patent system a company that does not apply for     patents risks finding that a patent troll has applied for their idea. 
Publishing the idea should have the same effect as patenting it: to make
future applications invalid.

In practice, given the fallibility of the US PTO, neither a
publication nor an existing patent guarantees it will not issue a new
patent.

This is precisely why everyone should oppose the patented standards at
every step of the way.

    There is no practical means for the IETF to adjuicate on such claims. 
The W3C has a means that seems to work in practice.

---

From: Richard M Stallman <[email-masked]>
Date: Tue, 10 Mar 2009 14:21:11 -0400

The IPR working group turned into a farce

It had a strike against it the moment it was formed, from the term
"IPR".  Describing the remit of an activity as "IPR" directs it down
a path that leads to confusion.

So I would not propose to change the "IPR" working group, but rather
to split off the issue of patents and adopt a patent policy similar to
that of the W3C.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 11 Mar 2009 19:44:56 +0100

Hello Richard,

On 3/10/09 7:21 PM, Richard M Stallman wrote:
>      Under the current patent system a company that does not apply for =
>      patents risks finding that a patent troll has applied for their idea. =
>

Let me pose you a scenario and ask for your advice:

   1. Vendor A develops technology and works to see adopted an
      associated standard, publishing as you suggest above.
   2. Vendor B then develops an important extension to that work and
      patents it.  Vendor B extorts an expensive license arrangement
      from Vendor A.

What is Vendor A to do to protect itself from such an attack?  One 
approach is Vendor A patenting the technology and cross-licensing at 
reasonable terms (like don't sue us and we won't sue you).  What would 
you suggest instead?

Eliot

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 12 Mar 2009 04:57:10 -0700

And this is inevitable as you cannot control use of technology by controlling a registry.

IANA is a consensual illusion. It only has the power to assign names as long as the community agrees that it performs that role. Patent encumberances must not be used to deny IANA code points. If that happens the IPR holders will simply chose their own code points and use them. There is no legal impediment.

This has actually happened in the EUI48 space. Originally a MAC address could only be assigned for network hardware. So the storage people created their own registry with an offset which was subsequently grandfathered.

We are not going to break IANA in order in the service of anybodies ideologies.

-----Original Message-----
From: [email-masked] on behalf of Eric Rescorla
Sent: Wed 3/11/2009 10:32 AM
To: Dean Anderson
Cc: [email-masked]; [email-masked]; Richard Stallman
Subject: Re: [Ietf-honest] Consensus Call for draft-housley-tls-authz

-Ekr

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 12 Mar 2009 11:01:49 -0400

> The W3C has a means that seems to work in practice.

As several people have already pointed out, the analogy with the W3C
is an imperfect one, because whereas anyone can just show up on an
IETF mailing list and thereby be "part of a WG", W3C WGs have members
in a formal sense.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Scott Brim <[email-masked]>
Date: Thu, 12 Mar 2009 11:11:40 -0400

> IETF mailing list and thereby be "part of a WG", W3C WGs have members

modulo the Note Well

---

From: [email-masked]
Date: Thu, 12 Mar 2009 13:51:14 -0700 (PDT)

> You are the one who compared them, when you said this:

I did no such thing. You're taking what I said completely out of context and
once again failing to understand the difference between standards and other
documents the IETF publishes.

The matter at hand wasn't the publication of any sort of standard in the IETF,
but rather the notion that the IETF publishing an experimental, entirely
nonstandard document would act as an impetus for someone else standardizing
that technology. My point was, and is, that if someone else wants to
standardize something, they will, irrespective of what we do.

You then turned asserted this is tantamount to saying "if we don't do it,
someone else will". But what we're doing isn't publishing a standard, so  the
two "dos" are not equivalent and cannot be compared.

> If you think the comparison is misguided, then you should object to
> your own point too.

it's a totally different point.

> Then why did you hypothesize it would happen?

I didn't. The discussion has moved past this specific document and moved on to
a discussion of experimental RFCs in general.

> It is quite peculiar that you disagree on so many points with te
> message you posted on Tuesday.  Are there two different people posting
> from your account?

With all due respect, the inconsistency you perceive is because you seem unable
or unwilling to come to terms with the essential properties of the IETF
process, which like it or not has always included the publication of things 
other than standards and even includes the publication of "this is a bad idea,
don't do this" documents.

				Ned

---

From: Eliot Lear <[email-masked]>
Date: Thu, 12 Mar 2009 22:25:15 +0100

Thanks for your response, Richard.  On this point:
> I have nothing against obtaining patents to be used only defensively.
> If company A wants to do this, I presume it will start by give
> everyone a royalty-free license to use the original standard.
>    

I am aware of at least one particular company who largely only patents 
defensively, and I wonder if that is in fact the general state of the 
interactions with the IETF.  Have people have found that in the past 
there was a problem making use of even an informational or experimental 
RFC because of patent restrictions?

Eliot

---

From: "Mohsen BANAN" <[email-masked]>
Date: Wed, 11 Mar 2009 12:39:09 -0700

>>>>> On Mon, 9 Mar 2009 14:20:45 -0700, "Hallam-Baker, Phillip" <[email-masked]> said:

  Phillip> 1) Patents happen, get over it.

The problem is not that patents happen. The
problem is IETF's position when patents happen.

Clearly stated in 
  
  http://www.fsf.org/news/reoppose-tls-authz-standard

is that granted rights are inadequate.

  "... RedPhone has given a license to anyone who
  implements the protocol, but they still threaten
  to sue anyone that uses it. ..."

While this may be fine in your world of big
proprietary business, it is a severe problem 
for FOSS.
 
  Phillip> 2) Very few patents are so essential that they are worth more than
  Phillip> interoperability.
 
The bar is not that of being "so essential".

  Phillip> 3) It follows that the only allowable patents are on non-essential aspects
 
When a protocol is contaminated with patents it no
longer serves the real purpose of a standard
destined protocol.

That of creating a level playing field for
interaction of all participants.

About 10 years ago, I brought all of this up in
the context of patent contaminated WAP protocols
in: 

                The WAP Trap
An Expose of the Wireless Application Protocol
http://www.freeprotocols.org/PLPC/100014

Some of that same patent related logic applies in
this case.

Mohsen BANAN -- http://mohsen.banan.1.byname.net

---

From: Mohsen BANAN <[email-masked]>
Date: Wed, 11 Mar 2009 14:35:36 -0700

>>>>> On Tue, 10 Mar 2009 12:04:13 -0700, SM <[email-masked]> said:
  SM> At 11:21 10-03-2009, Richard M Stallman wrote:

  RMS> In the cases where an experimental RFC is useful, how is it more
  RMS> useful for the Internet than publication of the same information in
  RMS> some other way?  Long ago, before search engines, perhaps interested
  RMS> people would not have found it elsewhere, but that isn't true now.

  SM> The RFC Series predates the IETF.  It is a repository of technical
  SM> information and, hopefully, it will still be around when I am no
  SM> longer around.  I don't know how search engines will be years from now
  SM> but there is one thing I know.  As long as the tradition is preserved,
  SM> the Internet community will have a mechanism to publish technical
  SM> information.

Note here that the following are independent of
one another:

  - Publication (RFC or other wise)
  - Patent contamination
  - Standards designation

My remarks here are limited to Publication.  I'll
follow up with a separate note on what the
solution is for the process as a whole.

RFC publication in fact is more complex than SM describes.

With RFC publication there is a 
   real part 
and there is an 
   imaginary part.

The imaginary part is what is the process as
advertised (in RFC-2026). That access to RFC
publication is fair and reasonable and that the
RFC series are a source for the Internet technical
community at large.

The real part is that IETF is now fully dominated
by interests of proprietary big business.  In
practice the role of the RFC Editor for documents
coming from outside of the IETF/IESG/IAB has been
reduced to that of a glorified clerk of the IESG.
Much of the Internet technical community has
chosen to be outside of the IETF. And RFC
publication is now mostly an IETF work group game.

Plenty of concrete examples for both the real and
the imaginary.

In my case:
  http://mohsen.banan.1.byname.net/PLPC/120026
  http://www.esro.org/documents/baseProtocols.html
  http://www.emsd.org/communicationRecord/rfc2524Publication/maillist.html

In  D. J. Bernstein's case:
  http://cr.yp.to/proto/rfced.html

And all of those were in the cases of patent free
protocols.

Now in this particular case of a patent
contaminated protocol extension why would non-RFC
publication be adequate?

...Mohsen

---

From: Mohsen BANAN <[email-masked]>
Date: Thu, 12 Mar 2009 17:56:13 -0700

>>>>> On Wed, 11 Mar 2009 14:35:36 -0700, Mohsen BANAN <[email-masked]> said:

  Mohsen> Now in this particular case of a patent
  Mohsen> contaminated protocol extension why would non-RFC
  Mohsen> publication be adequate?

I omitted the important "not" in that sentence.

I meant:

Now in this particular case of a patent
contaminated protocol extension why would not
non-RFC publication be adequate?

I am asking as to why it should be published as an
RFC (any status) when we know to begin with that it
is a patent contaminated specification.

Addressing the RFC Editor:

Has there ever been a case before where a known
patent contaminated specifiaction been published 
as an independent submission?

What are the RFC Editor's values/policies with respect to 
publication of known patent contaminated specifiactions?

What are the minimum rights demanded from the patent holder in such a case?

--
Mohsen BANAN                   http://mohsen.banan.1.byname.net
Neda Communications, Inc       http://www.neda.com

---

From: Richard M Stallman <[email-masked]>
Date: Thu, 12 Mar 2009 16:08:41 -0400

If experimental RFCs are peer-reviewed, that means they require a kimd
of approval.  Others have expplained how this approval has an effect
on the public.  I'm saying that the IETF should not give this
approval to patent-restricted practices.

Based on what you've said, the IETF could stop publishing experimental
RFCs and say "Submit it to a journal instead," and there would be
little loss.

---

From: Richard M Stallman <[email-masked]>
Date: Thu, 12 Mar 2009 16:08:55 -0400

If that is true, an experimental RFC constitutes a very important kind of  
approval.

---

From: Richard M Stallman <[email-masked]>
Date: Thu, 12 Mar 2009 16:10:04 -0400

---

From: Richard M Stallman <[email-masked]>
Date: Thu, 12 Mar 2009 16:10:05 -0400

We can also imagine a troll trap condition of the form "provided you
don't participate in any other patent license covering the use of the
standard which is offered to the general public and requires payment
to any specified party."  I would not object to conditions of that
sort.  IANAL so I don't know whether such conditions are considered
lawful in any country.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 13 Mar 2009 18:44:52 +0100

> RFCs and say "Submit it to a journal instead," and there would be

In general, journals don't publish protocol specifications.

And from where I'm sitting, publication as experimental is not so much  
an approval by the IESG as a lack of approval to publish as standards  
track. I'm sure that is lost on most people, though.

I don't think the world needs more experimental RFC that only serve to  
legitimize a patent encumbered protocol, but not all experimental RFCs  
fall into that class.

---

From: "Lawrence Rosen" <[email-masked]>
Date: Fri, 13 Mar 2009 10:51:06 -0700

> Does that include legal threats?

Of course! Wouldn't you consider that prudent under some circumstances? Or
are some at IETF actually trying to set implementers up for legal action by
refusing to evaluate *disclosed* threats?

/Larry

> Alessandro Vesely
> Sent: Wednesday, March 11, 2009 2:28 AM
> To: SM

---

From: grenville armitage <[email-masked]>
Date: Sat, 14 Mar 2009 11:12:25 +1100

Lawrence Rosen wrote:
	[..]
> Or are some at IETF actually trying to set implementers up for legal action by

Helping hapless implementers evaluate patent threats
sounds like a job for the Internet Legal Task Force.

I believe they're two doors down, on the right...

cheers,
gja

---

From: "Doug Ewell" <[email-masked]>
Date: Fri, 13 Mar 2009 19:30:11 -0600

> sort.  IANAL so I don't know whether such conditions are considered 

This is completely different from the hundred or so "campaign" e-mails 
sent to this list which said that all software patents are evil and all 
software standards must be 100% patent-free.

--
Doug Ewell  *  Thornton, Colorado, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

---

From: "Tadayuki Abraham HATTORI" <[email-masked]>
Date: Sat, 14 Mar 2009 13:33:59 +0900

I wonder that movement of FSF and the related subjects of
patent threats might be a kind of economical hypnotism.

Theorem or formulas of hypnotism might be used.....mightn't it?

// In an essay "Meeeeeeee" in  "Surely, you are joking Mr.Feynman",
// he said that "I've learned how to be under hypnotism."

Kindly regards,

Abraham TaddyHatty
taddyhatty at acm dot org

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 15 Mar 2009 15:37:46 +0100

Apparently, publishing a message as "experimental" is an invitation by 
the IETF to experiment with a new protocol. What sense does that bear, 
if accepting IETF invitations is likely to result in legal troubles?

> I believe they're two doors down, on the right...

http://www.isoc.org/isoc/general/trustees/mtg07.shtml
26 - 27 June 1995, Honolulu, Hawaii, USA
[...]
6.18 Legal and Regulatory Initiatives

The Executive Director briefed the Board on the developments relating 
to the proposed Internet Legal Task Force (ILTF), a proposed body 
whose objective was described as the investigation of various legal 
issues regarding the Internet and its social impact. The sense of the 
Board was to invite those interested in such an agenda to participate 
within the IETF framework and ISOC conference structure, but the Board 
did not wish to endorse the formation of an ILTF as a part of the ISOC 
organizational structure.

---

From: John Levine <[email-masked]>
Date: 15 Mar 2009 15:32:08 -0000

>Apparently, publishing a message as "experimental" is an invitation
>by the IETF to experiment with a new protocol. What sense does that
>bear, if accepting IETF invitations is likely to result in legal
>troubles?

In North America, at least, experimentation per se doesn't infringe
patents.

See http://en.wikipedia.org/wiki/Research_exemption

Can we stop playing Junior Lawyer now, please?

R's,
John

---

From: "Tadayuki Abraham HATTORI" <[email-masked]>
Date: Mon, 16 Mar 2009 00:55:21 +0900

As you might know, generally, legal mind tend to focus on "past" not on 
"future".
So, law or legal mind can't be used for calculation of states of future.
Law can be described as formulas, I think.

For managing the future, theorem or formulas should be used,
just as academic arts such as social science or artificial intelligence, 
sh'dn't it?

// NANCHATTE-HAKASE/Local Pseudo Doctors will easily chages
// their minds according to the future of RFC or atmosphere of IETF.

In good faith,

Abraham TaddyHatty

>
>
> Apparently, publishing a message as "experimental" is an invitation by the 
> IETF to experiment with a new protocol. What sense does that bear, if 
> accepting IETF invitations is likely to result in legal troubles?
>
>>> Or are some at IETF actually trying to set implementers up for legal 
>>> action by refusing to evaluate *disclosed* threats?
>>
>> Helping hapless implementers evaluate patent threats sounds like a job 
>> for the Internet Legal Task Force.
>>
> The Executive Director briefed the Board on the developments relating to 
> the proposed Internet Legal Task Force (ILTF), a proposed body whose 
> objective was described as the investigation of various legal issues 
> regarding the Internet and its social impact. The sense of the Board was 
> to invite those interested in such an agenda to participate within the 
> IETF framework and ISOC conference structure, but the Board did not wish 
> to endorse the formation of an ILTF as a part of the ISOC organizational 
> structure.

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 15 Mar 2009 19:14:14 +0100

> See http://en.wikipedia.org/wiki/Research_exemption

However, it is difficult to exactly trace a boundary between normal 
exploitation of a patent and a strictly controlled experiment. For 
example, I don't think that all the mail hubs currently using SPF 
would be considered mere experiments, but SPF is still experimental.

Of course, if publishing as experimental explicitly included licenses, 
that idea might work.

> Can we stop playing Junior Lawyer now, please?

That's what I'd hope. This habit of requiring two lawyers and a judge 
for every pair of citizens is really annoying. It is the main reason 
for seeking unencumbered environments, IMHO. Software is complicated 
enough already.

---

From: "Lawrence Rosen" <[email-masked]>
Date: Sun, 15 Mar 2009 12:32:11 -0700

> > See http://en.wikipedia.org/wiki/Research_exemption

Once again, I wish non-lawyers would ask question before interpreting the
patent law. The experimentation exception referred to in that wikipedia
article [§271(e)(1) or "Hatch-Waxman" exemption] is largely relevant to
pharmaceuticals in process of tests and experiments for regulatory approval.
It has nothing whatsoever to do with software that doesn't get approved by
anyone. 

Is that what IETF's "April Fools RFCs" are about? Perhaps drugs will improve
Internet performance. It is worth an experiment....

Alessandro Vesely wrote:
> This habit of requiring two lawyers and a judge

Fortunately for all of us, there aren't quite that many lawyers. So practice
your complicated engineering and let us lawyers do our job. 

/Larry

> Sent: Sunday, March 15, 2009 11:14 AM
> To: John Levine
> Cc: [email-masked]

---

From: "Tadayuki Abraham HATTORI" <[email-masked]>
Date: Mon, 16 Mar 2009 09:07:25 +0900

Considering the history of the world, traditional law or classic legal mind
can't help managing future. They had been created for hereditary 
civilization
based upon papers, pen and ink. It may just pull back legs of evolution
of new civilization.

It can be helped by scientific mind, formulas and technology.
I recommend to create formulas or theorem of international law rather than
asking traditional and local lawyers.
Why don't you go to do so?
That's possible.

Abraham TaddyHatty

---

From: "Tadayuki Abraham HATTORI" <[email-masked]>
Date: Mon, 16 Mar 2009 20:16:28 +0900

> Theorem or formulas of hypnotism might be used.....mightn't it?

 For me, many local IT companies looks like as slaves of the hypnotism, 
congregation of local pseudo doctors, hysteria of IT trend, I think.
 What's more, local pseudo IT doctors easily changes their 
own thoughts according to atmosphere of discussion of IETF, 
or  any other international academic/engineering society, I think.

International democratic discussion about network protocols for 
political processes such as democracy could promote new 
fundamental conceptal computing,  I believe in.

Let's consider new conceptual brain-like computer and the network,
and new international political process automation standards as sets 
of communication protocols.

Sincerely,
 
Be careful of evil rumor and whispering,

Abraham TaddyHatty

>>> action by

---

From: Yaakov Stein <[email-masked]>
Date: Thu, 19 Mar 2009 10:37:03 +0200

> It has nothing whatsoever to do with software that doesn't get approved by

This is one application, however in Madey vs. Duke the appeals court 
for the Federal Circuit allowed an experimentation defense for purposes of
"amusement, to satisfy idle curiosity, or for strictly philosophical inquiry"
as long as this experimentation is not 
"in furtherance of the alleged infringer’s legitimate business".

Internationally, Article 30 or TRIPS allows member states
to provide experimentation exceptions unrelated to regulatory issues.

The experimentation defense is also known in common law,
and was upheld in Whittemore v. Cutter in the early 1800s.

Y(J)S