RE: Silly TLS Auth lobbying
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Silly TLS Auth lobbying

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 numeriFrom ietf-bounces at ietf.org Mon Oct 29 12:28:50 2007
Return-path: <ietf-bounces at ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1ImXOL-0005HI-Qr; Mon, 29 Oct 2007 12:23:05 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1ImXOJ-0005Er-HA
	for ietf at ietf.org; Mon, 29 Oct 2007 12:23:03 -0400
Received: from colibri.verisign.com ([65.205.251.74])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImXOE-0007q9-Ee
	for ietf at ietf.org; Mon, 29 Oct 2007 12:22:59 -0400
Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com
	[65.205.251.33])
	by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id l9TGIpjh017319;
	Mon, 29 Oct 2007 09:18:52 -0700
Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by
	MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft
	SMTPSVC(6.0.3790.3959); Mon, 29 Oct 2007 16:22:28 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Mon, 29 Oct 2007 09:22:27 -0700
Message-ID: <2788466ED3E31C418E9ACC5C31661557084F1F at mou1wnexmb09.vcorp.ad.vrsn.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Silly TLS Auth lobbying
Thread-Index: AcgaLHs8ITLSJVbpQMOMmJi9DMf/9QAGMfJ+
References: <6130F950-2671-4612-9334-BB5723458DCB at extremenetworks.com>
From: "Hallam-Baker, Phillip" <pbaker at verisign.com>
To: "RJ Atkinson" <rja at extremenetworks.com>, <ietf at ietf.org>
X-OriginalArrivalTime: 29 Oct 2007 16:22:28.0237 (UTC)
	FILETIME=[E5E9E3D0:01C81A47]
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32
Cc:
Subject: RE: Silly TLS Auth lobbying
X-BeenThere: ietf at ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="==============16695427=="
Errors-To: ietf-bounces at ietf.org

This is a multi-part message in MIME format.
Title: Silly TLS Auth lobbying
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:rja at extremenetworks.com]
Sent: Sat 27/10/2007 11:57 AM
To: ietf at ietf.org
Subject: Silly TLS Auth lobbying


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 eco 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:rja at extremenetworks.com]
Sent: Sat 27/10/2007 11:57 AM
To: ietf at ietf.org
Subject: Silly TLS Auth lobbying


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
rja at extremenetworks.com


_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.