ietf-openpgp
[Top] [All Lists]

Re: IETF process

1997-11-06 05:49:14
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(_at_)systemics(_dot_)com>
Organization: Systemics
X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386)
To: Raph Levien <raph(_at_)acm(_dot_)org>
CC: ietf-open-pgp(_at_)imc(_dot_)org, Gene Hoffman 
<hoffmang(_at_)pgp(_dot_)com>
Subject: Re: IETF process (was How many 2.6 users?)
Sender: owner-ietf-open-pgp(_at_)imc(_dot_)org

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



<Prev in Thread] Current Thread [Next in Thread>