Re: Experimental makes sense for tls-authz

[Stjepan Gros <sgros at zemris.fer.hr>]

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

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

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

Note that this is the only one, and very simple, scenario to reach the
goal ofFrom ietf-bounces at ietf.org Sat Oct 27 04:48:38 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 1Ilgy8-0004N1-Cg; Sat, 27 Oct 2007 04:24:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ilgy5-0004G4-5F
	for ietf at ietf.org; Sat, 27 Oct 2007 04:24:29 -0400
Received: from iluvatar.zemris.fer.hr ([161.53.65.13])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ilgxy-0005y1-QI
	for ietf at ietf.org; Sat, 27 Oct 2007 04:24:29 -0400
Received: from localhost (unknown [127.0.0.1])
	by iluvatar.zemris.fer.hr (Postfix) with ESMTP id 9AA67174024;
	Sat, 27 Oct 2007 08:19:53 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at zemris.fer.hr
Received: from iluvatar.zemris.fer.hr ([127.0.0.1])
	by localhost (iluvatar.zemris.fer.hr [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id VW0PoQwh-367; Sat, 27 Oct 2007 10:19:45 +0200 (CEST)
Received: from [193.198.86.161] (vipnet161-86.mobile.carnet.hr
	[193.198.86.161]) (using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by iluvatar.zemris.fer.hr (Postfix) with ESMTP id BA91D174027;
	Sat, 27 Oct 2007 10:19:40 +0200 (CEST)
From: Stjepan Gros <sgros at zemris.fer.hr>
To: Randy Presuhn <randy_presuhn at mindspring.com>
In-Reply-To: <003e01c817fa$b09cfb80$6801a8c0 at oemcomputer>
References: <003e01c817fa$b09cfb80$6801a8c0 at oemcomputer>
Content-Type: text/plain
Organization: FER - ZEMRIS
Date: Sat, 27 Oct 2007 10:21:49 +0200
Message-Id: <1193473309.3143.20.camel at localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.10.3 (2.10.3-4.fc7) 
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: ietf at ietf.org
Subject: Re: Experimental makes sense for tls-authz
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>
Errors-To: ietf-bounces at ietf.org

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

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

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

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

Stjepan

> Randy
> 
> 
> _______________________________________________
> 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