ietf
[Top] [All Lists]

Re: IPR at IETF 54

2002-05-31 11:11:40
On Thu, May 30, 2002 at 11:13:24PM -0500, Dave Crocker wrote:
To underscore the point that Marshall has been making:

The IETF has a strong preference to use unencumbered technologies.  When 
there is a choice between encumbered and unencumbered, the working group 
includes encumbrance into the range of factors it treats as important for 
evaluating alternatives.

There are some unknowns about licensing.  Some holders of IPR are helpful 
to resolving that easily and quickly.  Others are more reticent.  That 
become a component of the evaluation about the IPR factor.

And so on.

Generally this thread seems to be seeking determinacy for a matter that can 
only be made deterministic by a) ignoring IPR encumbrance, or b) rejecting 
all IPR encumbrances.  The first is not compatible with IETF culture.  The 
latter is not practical in some cases.

So, what exactly do folks think is a practical kind of change to the 
current IETF policies?

I think the problem is that while there is (very) rough consensus
IETF-wide that there is a strong cultural bias against patent
encumberances (*), this bias is not adequately documented in writing.
This is exacerbated by the fact that some IETF working groups,
particularly those where a greater number of the participants do not
have as much IETF experience and acculturation.  This is happening
more and more as we start doing more cross-collaborations with other
standards bodies, and when technologies which previously had been used
on top of other media are "ported" to IP, and people who had been used
to working in other standards bodies find them selves working within
the IETF.  

(*) Unless there is a ***very*** reason why you can't do without the
patent --- RSA signatures/encryption being classic example, but even
there, RSA DSI's licensing policies were probably far more effective
that the U.S. government's export control regime at preventing the
deployment of secure protocols in the Internet).

Many of these newcomers to the IETF very dutifully read the relevant
RFC's (2026, et. al.), and then are surprised either (a) they get
strong push back from the IESG, or (b) their decisions get attacked at
IETF plenery sessions, the IETF mailing list, or in other venues.
They are get surprised, and there is some fairness to their argument
that this bias against non-RF patents isn't written down anywhere and
isn't formally part of our policies.

Granted, we can't document every tiny detail of cultural biases within
the IETF in our policy documents, but I think this one is important
enough that we need to say something.  Once we do decide that we need
to say something, then the next question is exactly where do we draw
the line, and that's where all of the discussion and long missives to
the IETF mailing list are coming from.  

Although it's pretty clear we won't be able to give working groups an
algorithmic flowchart about when a non-RF patent is acceptable, I do
believe that we can give some general guidelines, and then require
that the working group chair work with the area director when this
sort of issue raises its ugly head.  This won't solve the "stealth
patent" problem, where the patent problems only reveal themselves very
late in the process, or even after document is published as an RFC,
but it does handle a large number of other cases.

                                                - Ted



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