[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IETF process
If you look at what has been happening in the IETF lately you'd see that
TLS, IPSec, and PKIX have all run into this issue.
Analyzing the document rather than studying the context is not necessarily
the way to look at things when dealing with the IETF standards process.
>Date: Wed, 05 Nov 1997 23:58:12 +0000
>From: Ian Grigg <iang@xxxxxxxxxxxxx>
>Organization: Systemics
>X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386)
>To: Raph Levien <raph@xxxxxxx>
>CC: ietf-open-pgp@xxxxxxx, Gene Hoffman <hoffmang@xxxxxxx>
>Subject: Re: IETF process (was How many 2.6 users?)
>Sender: owner-ietf-open-pgp@xxxxxxx
>
>Raph Levien wrote:
>> I believe that the most relevant document explaining IETF process is RFC
>> 2026. Quoting section 10.3.2(c), which is relevant for standards track
>> documents:
>>
>> (C) Where the IESG knows of rights, or claimed rights under (A), the
>> IETF Executive Director shall attempt to obtain from the claimant
>> of such rights, a written assurance that upon approval by the IESG
>> of the relevant Internet standards track specification(s), any
>> party will be able to obtain the right to implement, use and
>> distribute the technology or works when implementing, using or
>> distributing technology based upon the specific specification(s)
>> under openly specified, reasonable, non-discriminatory terms.
>> The Working Group proposing the use of the technology with respect
>> to which the proprietary rights are claimed may assist the IETF
>> Executive Director in this effort. The results of this procedure
>> shall not affect advancement of a specification along the
>> standards track, except that the IESG may defer approval where a
>> delay may facilitate the obtaining of such assurances. The
>> results will, however, be recorded by the IETF Executive Director,
>> and made available. The IESG may also direct that a summary of
>> the results be included in any RFC published containing the
>> specification.
>>
>> So the existence of patented technology (such as RSA or IDEA) would
>> seem to be not necessarily a problem, as long as the patent is licensed
>> under appropriately "open" terms.
>
>Wow. Let's look at this. IDEA first.
>
>IDEA is licensed by Ascom and their licensing page is at [1]. Their
>schedule is at [2] and includes more prices than you can poke a stick
>at. What is more interesting is that you can purchase the license over
>the Internet at [3] (although you are forced to read the license to get
>there). It's especially open in the hackers sense that you do not have
>to use their source.
>
>I would therefore conclude that IDEA is: available to any party,
>distributable, purchasable under open, "reasonable" and
>non-discriminatory terms. Reasonable is of course a value judgement.
>
>As an administrative burden, the IETF ExecDirector should get a letter
>that confirms this. My reading of the site and Ascom's reputation do
>not indicate an issue here.
>
>> Whether RSA meets this standard is open
>> to question - certainly they have been accused by their detractors of
>> non-openness in their licensing process.
>
>OK, now RSA.
>
>I agree that RSADSI have a bad reputation on this issue. I had a look
>at their web site and it is appallingly closed. Note however that the
>above comment does not say that an assurance of openness is necessary:
>
> "The results of this procedure
> shall not affect advancement of a specification along the
> standards track, except that the IESG may defer approval where a
> delay may facilitate the obtaining of such assurances. The
> results will, however, be recorded by the IETF Executive Director,
> and made available. The IESG may also direct that a summary of
> the results be included in any RFC published containing the
> specification."
>
>"shall not affect advancement" is quite specific, which leaves open the
>question as to why the IESG supposedly rejected the S/MIME and SSL V3
>standards. Perhaps they were simply deferred instead, as this deferral
>might be a bargaining chip in the hands of IETF.
>
>Can you comment in the S/MIME case as to why the above was considered to
>be a rejection?
>
>I would think that having the RSA algorithm listed in the standard,
>along with an IESG comment that said that this algorithm may not be
>available under open, non-discriminatory and reasonable guidelines to
>all parties would be quite a useful bargaining point.
>
>We could go even further. You could say that the RSA algorithm is to be
>used, except where algorithm is not available under open,
>non-discriminatory and reasonable guidelines. If we need a definition
>of this, I would suggest
>
> * prices not in excess of other comparables (is ElGamal comparable?
>:-),
> * purchasable over the web with no possibility of a human
> being interposing some "conditions."
> * no restrictions on code use (i.e., roll-your-own is ok, as is use
> somebody else's)
>
>All of which seems obvious of course, based on the snippet above. Are
>there any counter-views?
>
>
>
>> Hope this helps.
>
>It's excellent, thanks. Clears the FUD right out.
>
>
>
>[1] http://www.ascom.ch/Web/systec/policy/main.html
>[2] http://www.ascom.ch/Web/systec/policy/normal/exhibit3.html
>[3] http://www.ascom.ch/Web/systec/policy/normal/orderform.html
>
>--
>iang systemics.com
>
>FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com
>
>