Subject: Re: ISSUE 1: IPR was Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft

From: Thomas Narten <[email-masked]>
Date: Tue, 07 Mar 2006 09:23:35 -0500

"Olaf M. Kolkman" <[email-masked]> writes:

> Since this is one of the issues that can drag on forever if we are  
> not careful I propose some process that sets a timeline to this  
> discussion.

Thank you!

> On the basis of previous discussion on the list I think we can go for  
> a consensus call on the text below:

> 5.2 No Intellectual Property Encumbrance

>     The solution SHOULD not have any intellectual
>     property encumbrance on either the technologies
>     used by the solution nor implementations
>     of the solution.

>     The solution MUST be covered by one of options
>     (a) or (c) of section 6.5 of [RFC3979].  If the
>     technology is covered by option (a), the license SHOULD
>     be compatible with the BSD open source license

IMO, Section 5.2 is completely misguided. Here, we have the classic
case of a "requirements document" trying to pick (or exclude) a
particular solution, in advance of actually working on a solution. But
the approach being used is a hammer (e.g., "no IPR is acceptable"),
when at the end of the day, we'd be better off doing an evaluation of
the specific case at hand, and making a decision based on the
available information.

I believe I understand what the above section is attempting to
achieve. And I support that general goal.

But, the WG would be a lot better off taking each IPR claim as it
stands. Look at the technology, look at the IPR issues, and then
simply decide (on a case-by-case basis), does the WG want to adopt the
technology, or does it want to (try to) route around it and use
something different? The only way to answer this question (as
engineers -- where one weighs the pros and cons) is to evaluate two
proposals, one with the IPR, and one that is believed to route around
it. If the latter is an adequate technical solution, the WG should
just go for it. If not, it needs to reevaluate its options.

> I'd like to ask participants to state on-list

> c: They would like to see any mention of IPR dropped from the  
> requirements.

I'm for choice c.

Thomas

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Paul Vixie <[email-masked]>
Date: Tue, 07 Mar 2006 18:49:20 +0000

i've had the benefit of reading several other replies to olaf's request, and
as olaf requested, this will be my last word on this topic until the current
issue (ISSUE 1) has been decided.

i think that the entire document (RFC3979) deserves careful review by those
weighing in on this point, not just section 6.5.  in section 4.1, constraints
are placed on the IESG as to whether a document can be progressed from one
standards state to the next, and a presumption is made as to the reasonableness
and discriminatoryness of licensing terms that i think are very significant to
the points that ed lewis and ted lemon have made here today.

                        If the two unrelated implementations of the
   specification that are required to advance from Proposed Standard to
   Draft Standard have been produced by different organizations or
   individuals, or if the "significant implementation and successful
   operational experience" required to advance from Draft Standard to
   Standard has been achieved, the IESG will presume that the terms are
   reasonable and to some degree non-discriminatory.  (See RFC 2026,
   Section 4.1.3.) Note that this also applies to the case where
   multiple implementers have concluded that no licensing is required.
   This presumption may be challenged at any time, including during the
   Last-Call period by sending email to the IESG.

fundamentally, RFC3979 is about "what the IESG will do" and not about what a
WG will do.  if the WG believes that significant implementation and successful
operational experience is unlikely to result from a technology choice then we
are entirely within our rights to disqualify that choice on that basis without
evaluating it for quality at all.  in section 6.5, we see:

   Since IPR disclosures will be used by IETF working groups during
   their evaluation of alternative technical solutions, it is helpful if
   an IPR disclosure includes information about licensing of the IPR in
   case Implementing Technologies require a license.  Specifically, it
   is helpful to indicate whether, upon approval by the IESG for
   publication as RFCs of the relevant IETF specification(s), all
   persons will be able to obtain the right to implement, use,
   distribute and exercise other rights with respect to an Implementing
   Technology a) under a royalty-free and otherwise reasonable and non-
   discriminatory license, or b) under a license that contains
   reasonable and non-discriminatory terms and conditions, including a
   reasonable royalty or other payment, or c) without the need to obtain
   a license from the IPR holder.

(a) (b) and (c) are meant to be fully inclusive, as though no fourth choice
is even a theoretical possibility.  since (b) is highly subjective -- no
doubt many licensors will disagree with many potential licensees as to the
precise meaning of "reasonable and non-discriminatory" -- i think that these
three choices are not fully inclusive.  (that'll teach me not to skip POISED
meetings, i suppose.)  section 6.5 continues, in toto:

   The inclusion of licensing information in IPR disclosures is not
   mandatory but it is encouraged so that the working groups will have
   as much information as they can during their deliberations.  If the
   inclusion of licensing information in an IPR disclosure would
   significantly delay its submission it is quite reasonable to submit a
   disclosure without licensing information and then submit a new
   disclosure when the licensing information becomes available.

i don't believe that anyone here is claiming that any trust anchor IPR holder
has failed to comply with either the letter or the spirit of RFC3979.  what
we appear to be doing, instead, is talking about issues unrelated to RFC3979,
specifically whether encumbered technology is likely to achieve significant
and successful deployment.  there appears to be consensus on that point ("no")
but i recognize that the WG chairs are responsible for determining consensus,
so i won't harp further on that (not today anyway.)  in section 8, we see:

   In general, IETF working groups prefer technologies with no known IPR
   claims or, for technologies with claims against them, an offer of
   royalty-free licensing.  But IETF working groups have the discretion
   to adopt technology with a commitment of fair and non-discriminatory
   terms, or even with no licensing commitment, if they feel that this
   technology is superior enough to alternatives with fewer IPR claims
   or free licensing to outweigh the potential cost of the licenses.

i'm torn between saying that the above text is wrong-headed, vs. saying that
a WG also has the discretion to disqualify encumbered technology outright if
they believe that wide deployment will not occur without a world wide royalty
free perpetual license (as was given by RSA for their "dnssafe" a decade ago.)

but if we assume that the above text ought to guide us, then we're being told
to use our discretion.  that seems to argue that we solicit several
alternatives so that we can decide which one is superior and then, if the
one we think is superior happens to be encumbered, we can subsequently decide
whether it is "superior enough".  this, in turn, would seem to argue against
any kind of IPR restriction in the requirements document under discussion here.

but wait -- there's more!

   Over the last few years the IETF has adopted stricter requirements
   for some security technologies.  It has become common to have a
   mandatory-to-implement security technology in IETF technology
   specifications.  This is to ensure that there will be at least one
   common security technology present in all implementations of such a
   specification that can be used in all cases.  This does not limit the
   specification from including other security technologies, the use of
   which could be negotiated between implementations.  An IETF consensus
   has developed that no mandatory-to-implement security technology can
   be specified in an IETF specification unless it has no known IPR
   claims against it or a royalty-free license is available to
   implementers of the specification unless there is a very good reason
   to do so.  This limitation does not extend to other security
   technologies in the same specification if they are not listed as
   mandatory-to-implement.

if we believe that trust anchor management is mandatory-to-implement, then
the WG has no choice at all except to disqualify encumbered technology.  i'm
pretty sure that this WG has already "consensed" on this point, and that "we"
believe that deploying DNSSEC-bis without some way to roll over trust anchors
(especially the root trust anchor) would be a mistake.  that makes trust
anchor management a mandatory-to-implement technology for DNSSEC-bis, and if
we are to be guided by the above text, we have no reason to even evaluate any
encumbered technology in the absence of a world wide royalty-free perpetual
license.  (section 8 continues but i don't see it as relevant to this thread.)

RFC3979 does not define "royalty-free" or "implementors of the specification".
this leaves open a possible challenge where, for example, DNSSEC technology
vendors (whether proprietary/commercial, or F/OSS; whether GPL or BSD style)
are allowed to ship (for free or for a fee) software without paying royalties,
but the consumers of this technology would have to pay royalties based perhaps
on the revenue they can generate using said technology.  so, RFC3979 is weak
even where it applies to us at all, but i think we can make something of it.

with that preamble, here's olaf's question:

> a: That they consent with section 5.2 as above.
> 
> b: They would like to see section 5.2 as above modified. Then send
> argumentation and "patch"
> 
> c: They would like to see any mention of IPR dropped from the requirements.
> 
> Please respond by mail, try not to go into battle over arguments, state your
> own arguments once and trust others to be able to read.  If you need
> clarification of arguments please ask.
> 
> We'll assess the outcome of the discussion slightly before or during the
> face2face meeting in Dallas.
> 
> Please remain courteous and civil. Please respect the motivations for
> peoples opinions.

and here's my answer.  count me as (b).  argumentation as above.  patch is:

    Because trust anchor rollover is considered "mandatory-to-implement",
    section 8 of [RFC3979] requires that the technology solution chosen must
    be unencumbered or must be available under royalty-free terms.

    For this purpose, "royalty-free" is defined as follows: world wide,
    perpetual right to use, without fee, in commerce or otherwise, where "use"
    includes descriptions of algorithms, distribution and/or use of hardware
    implementations, distribution and/or use of software systems in source
    and/or binary form, in all DNS or DNSSEC applications including registry,
    registrar, domain name service including authority, recursion, caching,
    forwarding, stub resolver, or similar.

    In summary, no implementor, distributor, or operator of the technology
    chosen for trust anchor management shall be expected or required to pay
    any fee to any IPR holder for the right to implement, distribute, or
    operate a system which includes the chosen mandatory-to-implement
    solution.

i might not be in dallas.  i do however "trust others to be able to read."

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 7 Mar 2006 15:02:40 -0500

On Tue, Mar 07, 2006 at 06:49:20PM +0000, Paul Vixie wrote:
> alternatives so that we can decide which one is superior and then,
> if the one we think is superior happens to be encumbered, we can
> subsequently decide whether it is "superior enough".  this, in
> turn, would seem to argue against any kind of IPR restriction in
> the requirements document under discussion here.

I disagree a little with the above; but similar reasoning was the
basis on which I posted, recently, that any restriction that
prevented BSD distribution was automatically disqualified
essentially, and not just accidentally.

It is a requirements document that is under discussion, and not a
specification.  So, the draft outlines what are the necessary (and
maybe sufficient) conditions for a key rollover mechanism.  Such a
document cannot consider merely the technical issues related to the
mechanism.  It must, by nature, take into consideration whether a
scheme is implementable, given the Internet with which we find
ourselves.  (By way of comparison, I think everyone would agree that
there are items that could be better handled if one of the acceptable
criteria were, "All the resolvers in the world are replaced in 6
months."  But that's not the environment we're designing things for, I
take it.)

If I am right, one of the requirements is that whatever we adopt has
to be acceptable to the community of developers who actually provide
most of this infrastructure.  I don't see that as an add-on
requirement, to be thought about after the technology is decided
upon, any more than, "It doesn't entail a resolver flag day," is
something we think about after we evaluate all the possible
technology.  And since this isn't a protocol we're discussing, yet,
RFC 3979 is only relevant in terms of what targets we're picking.

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
                                        +1 416 646 3304 x4110

---

From: Alex Bligh <[email-masked]>
Date: Tue, 07 Mar 2006 21:02:44 +0000

> and here's my answer.  count me as (b).  argumentation as above.  patch

I think Paul has it right. So count me as (b) with his patch too.

Alex

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 08 Mar 2006 10:00:35 +0100

> just go for it. If not, it needs to reevaluate its options.

This is very convincing, and have made me change my opinion.  I now
support c) and believe that we should review patent entanglement on a
case-by-case basis.

It seems the arguments for a) and b) are now more slanted towards
making sure Thierry's proposal is disqualified without review, and I
believe that is unprofessional.

If text related to this is adopted, I'd prefer if my proposed changes
were applied, though.

Thanks,
Simon

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 8 Mar 2006 07:05:16 -0500

This is my response to the request for a consensus call on the

>    be compatible with the BSD open source license

I am persuaded by the argument that, there being remarkably few
lawyers among us, we should not get into the business of defining
what royalty-free, or non-discriminatory, or other such words mean. 
But I remain convinced that it is a good idea to make explicit that
option (b) of RFC 3979, section 6.5 is not a viable option in this
case.  So I would prefer (as others have suggested) that the last
sentence of paragraph two be removed, but that the text otherwise
stays as above.  We can then leave it open to consensus what might
qualify as "otherwise reasonable and non-discriminatory license".

A

-- 
Andrew Sullivan  | [email-masked]
A certain description of men are for getting out of debt, yet are
against all taxes for raising money to pay it off.
		--Alexander Hamilton