Subject: Silly TLS Auth lobbying

From: RJ Atkinson <[email-masked]>
Date: Sat, 27 Oct 2007 11:57:21 -0400

Some important things that the FSF folks seem NOT to understand,
and frankly seem to aggressively NOT want to understand, are:

- Many RFCs are *not* on the IETF standards track.

- Any "Experimental RFC" is *not* on the IETF standards track.
   So there is no "endorsement" by IETF in publishing such.

- The IETF has published real standards-track documents that
   required patented technology and were known to have
   *difficult* license terms on the publication date (think
   cryptographic algorithms and scan backwards in rfc-index.txt).

- There is no history of IETF requiring technology to be freely
   available (for either common definition of free).

I support the idea that virtually any document ought to be able
to be published as an Informational RFC or Experimental RFC.
Technology that is useful will be adopted if economically sensible,
whether in an RFC or not, whether made a formal standard or not.
By having an open specification, users can at least understand
the properties of the technology that is documented openly.

Just to be crystal clear, I do support publishing draft-housley-*
as either Informational RFC or Experimental RFC.

Yours,

Ran
[email-masked]

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

-53; Mon, 29 Oct 2007 08:45:36 -0400
To: [email-masked]
From: Ben Finney <[email-masked]>
Date: Sat, 27 Oct 2007 10:00:26 +1000
Lines: 25
Cancel-Lock: sha1:hZhZ3e1Ao8fflV4Fp6z86IsjXUU=
Subject: Re: Experimental makes sense for tls-authz

[email-masked] (Noel Chiappa) writes:

> I concur [with ignoring requests to reject
> 'draft-housley-tls-authz-extns' on grounds of patent encumbrance] -
> and I think this is the action we should take, no matter how many
> emails we see from people we've never heard from before (and
> probably never will again).

These people you speak of are users of the internet, and in many cases
software developers, expressing specific concern over a process they
see as harmful to the foundation of the internet: namely, validation
of a patent-encumbered technology by progressing it through a
standards process.

In the past it has been expressed on this list that the only
qualification for getting involved in IETF policy is exactly that,
getting involved -- in particular, on this list. Are you saying that
people who take the time to post in this forum will be ignored merely
because what they say is not what you want to hear?

-- 
 \       "Courage is resistance to fear, mastery of fear — not absence |
  `\                     of fear.  -- Mark Twain, _Pudd'n'head Wilson_ |
_o__)                                                                  |
Ben Finney

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

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 29 Oct 2007 22:29:09 +0900

>   So there is no "endorsement" by IETF in publishing such.

A lot more silly fact, these days, is that all the published RFCs
require IESG "endorsement".

That being so, I fully agree with FSF folks against publication of
silly RFCs.

> to be published as an Informational RFC or Experimental RFC.

I do agree with the idea.

And, it was the real practice in good old days when Jon was the
RFC editor.

							Masataka Ohta

---

From: <[email-masked]>
Date: Mon, 29 Oct 2007 13:41:49 -0000

> - Many RFCs are *not* on the IETF standards track.

One of the commenters mentioned that even Informational RFCs are seen,
by the uninitiated, as having the force of a standard.

>    So there is no "endorsement" by IETF in publishing such.

In fact, designating an RFC with IPR concerns to Experimental status is
a kind of "purgatory" for the RFC. It gives opponents a chance rally
implementation efforts using alternatives so that the Experimental RFC
never goes anywhere. But, if it turns out that there are no viable
alternatives or that the IPR owner is being fair and reasonable, then
the RFC can come out of Experimental status after the work has proven
itself. If the FSF and others understood that Experimental RFCs are a
form of purgatory, I think many of them would be satisfied.

> able to be published as an Informational RFC or Experimental RFC.
> Technology that is useful will be adopted if economically 
> sensible, whether in an RFC or not, whether made a formal 
> standard or not.
> By having an open specification, users can at least 
> understand the properties of the technology that is documented openly.

And people who dislike an IPR-encumbered design are free to publish an
alternative that satisfies the same needs. If they succeed in getting
their design published as an Informational or Experimental RFC, then
they have reached "IETF feature parity".

I am in favor of publishing draft-housley as Experimental

--Michael Dillon

---

From: Sam Hartman <[email-masked]>
Date: Mon, 29 Oct 2007 09:52:33 -0400

>>>>> "RJ" == RJ Atkinson <[email-masked]> writes:

    RJ> I support the idea that virtually any document ought to be
    RJ> able to be published as an Informational RFC or Experimental
    RJ> RFC.  Technology that is useful will be adopted if
    RJ> economically sensible, whether in an RFC or not, whether made
    RJ> a formal standard or not.  By having an open specification,
    RJ> users can at least understand the properties of the technology
    RJ> that is documented openly.

I agree with this general principle.

I continue to be unclear on how this principle interacts with IETF
consensus IANA actions, nor how it should interact.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 29 Oct 2007 15:56:09 +0100

Did you consider that the IANA allocation policy for the two IANA values
required by the document is "IETF Consensus"?

The standards track status of the document doesn't matter then.  What
matters is if the registration meets "IETF Consensus", and the IESG
decides this.

I think the policies around what "IETF Consensus" means could be made
more explicit, especially when it is applied to a document that itself
do not require consensus to be published.  I do think that the intention
is clear, though, to be that registration should only be done if there
is consensus in the IETF community that the IANA allocation should be
done.

/Simon

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 29 Oct 2007 09:22:27 -0700

If we create confusion by labelling everything RFC we are going to feel the ill effects caused by that confusion.
 
I know we keep comming across the problem that the RFC numbers are welded into the infrastructure and nobody seems to want STDs. But we still have a problem.
 
Perhaps a variant of Klensin's suggestion of documents describing a set of standards. If this was reduced down to the bare essentials of merely a set of references we might have documents of the form:
 
IETF-SMTP-2007
 
[boilerplate]
 
The following documents are normative components of the SMTP standard:
    RFC 2821
    RFC 2822
 
The following documents are not part of the SMTP standard but SMTP has normative references to them:
    None
 
The following documents are non normative:
    [whatever]
 
[IPR boilerplate]
 
There would be no other content. The document would be credited to IETF.

Such a document would replace the current STANDARD designation. All the documents referenced in such a document would have to be DRAFT or better on submission and would automatically become STANDARD status on the document being published.
 
This would not represent a significant change in current practice except to the extent that at present almost all protocols stick at DRAFT. 

I would anticipate there being relatively few such standards but the terms are much more likely to be used. I am not going to remember two sets of numeric designations and I don't think anyone else will either.
 
Switching from the term STD to IETF reminds people of where the documents come from. It also avoids an unfortunate choice of acronym. Semiotics do matter.

The use of a year designator would allow reference to be made to a particular version of the SMTP specification if that was appropriate. Year designators are preferred over version numbers in this case as version numbers have semantics associated with them. They also remind people when a standard has not been revised for some time. 

________________________________

From: RJ Atkinson [mailto:[email-masked]]
Sent: Sat 27/10/2007 11:57 AM
To: [email-masked]
Subject: Silly TLS Auth lobbying

Yours,

Ran
[email-masked]

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 29 Oct 2007 09:22:27 -0700

IETF-SMTP-2007
 
[boilerplate]

 
 
[IPR boilerplate]

 

Yours,

Ran
[email-masked]