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

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

--On 07 March 2006 18:49 +0000 Paul Vixie <[email-masked]> wrote:

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

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

Alex

--
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: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 8 Mar 2006 10:04:20 +0100

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

Paul's text as the property that it does not mention the specific  
licenses; that does remove one the topics we are ratholing on (I do  
not think this working group should try to figure out what is the  
better license BSD, GPL2 or GPL3).

Paul's premisses is that we had consented on the "mandatory-to- 
implement" part of the key-rollover. The exact RFC2119 form (MUST,  
SHOULD or MAY NOT implement) of that requirement is open to  
discussion but I think we do consent to the spirit of the "mandatory- 
to-implement" part; "mandatory-to-implement" should be in between  
quotes indeed.

So in order to try and reach convergence --- which is incredibly  
difficult --- Are there more takers for this position?

Remember that we are looking for rough consensus; please put some  
water with your wine for the sake of progress.

Is this a text you can consent with:

>
> 5.2 No Intellectual Property Encumbrance
>
>     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.
>

--Olaf

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

---

From: Edward Lewis <[email-masked]>
Date: Wed, 8 Mar 2006 05:04:45 -0500

I've been told that my opinions don't count for much because I 
haven't read everything under the sun pertaining to this issue. 
(Sorry, I can't afford to become an expert on copyright law this 
week.)  So, for what it's worth, I will just react to this.

>Is this a text you can consent with:

Short answer is no.

>>  Because trust anchor rollover is considered "mandatory-to-implement",
>>  section 8 of [RFC3979] requires that the technology solution chosen must

The first paragraph is okay.

>>  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,

The second paragraph I strongly (but arguing from weakness) object to.

I am sure that there is a more reliable definition of "royalty-free" 
than what a bunch of DNS engineers can come up with on this mailing 
list.  As much as we don't like middle-boxes implementing subsets of 
the DNS protocol (such as fire-walls that don't parse EDNS0 
correctly), we shouldn't try to hack at legal and economic concepts 
in the same manner.

E.g., http://en.wikipedia.org/wiki/Royalty_free. 'Course, that's in 
the context of photographic images.

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

I would say that our goal is give interoperability every chance to 
succeed by deriving a solution that anyone is free to implement 
without having to succumb to the whims of any person or entity not 
under the auspices of the IETF.

I'm being obstinate because this is a topic best handled by legal and 
economic people, not network engineers.  As engineers, we understand 
interoperabilty, we aren't fluent in "right to implement..." kind of 
concepts, or what "pay any fee" means to the limits of the law.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Nothin' more exciting than going to the printer to watch the toner drain...

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Mar 2006 09:11:51 -0700

> difficult --- Are there more takers for this position?

I'm perfectly happy with Paul's section instead of yours; I'm also perfectly 
happy with yours.

I don't think either one is "unprofessional."   The point is not to exclude 
"Thierry's proposal."   The point is to say what kind of IPR restrictions the 
working group is willing to accept on any protocol specification for a piece 
of technology that is be needed in some form or other in order for the whole 
protocol suite to be useful to users of the Internet: the people whom we 
ultimately serve when we do work for the IETF.

---

From: Russ Mundy <[email-masked]>
Date: Wed, 8 Mar 2006 12:50:18 -0500

On 3/8/06 at 5:04 AM -0500, Edward Lewis <[email-masked]> wrote: 

--------- snip ------------------

Editor hat ON

My impression was that the requirement in section 5.6 _removed_ automated key
rollover from being a "mandatory-to-implement".  

I think that those speaking for the NOT mandatory-to-implement position were
present in the Vancouver WG meeting but I have not seen any statements to that
effect on the list.

We may need to have statements either way on the 'mandatory-to-implement'
requirement.

Should this be Issue 2??

Russ

---

From: Paul Vixie <[email-masked]>
Date: Wed, 08 Mar 2006 18:39:09 +0000

# My impression was that the requirement in section 5.6 _removed_ automated key
# rollover from being a "mandatory-to-implement".  

that would be good news in and of itself, since we (isc) could start pushing
for wider deployment, even though it would require DLV and completely miss the
NSEC3 wave.

# I think that those speaking for the NOT mandatory-to-implement position were
# present in the Vancouver WG meeting but I have not seen any statements to
# that effect on the list.
# 
# We may need to have statements either way on the 'mandatory-to-implement'
# requirement.
# 
# Should this be Issue 2??

i think so, yes.  if trust anchor management is not mandatory to implement,
then DNSSEC-bis is ready for wide scale deployment, and this whole debate, as
well as the NSEC3 technology wave, are way less relevant than we've all been
treating them.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 9 Mar 2006 09:57:36 +0100

On Mar 8, 2006, at 6:50 PM, Russ Mundy wrote:
(...)

Note that I wrote:

> discussion but I think we do consent to the spirit of the  
> "mandatory-to-implement" part; "mandatory-to-implement" should be  
> in between quotes indeed.

The spirit of the "mandatory-to-implement" is that automatic  
keyrollover is a key component of successful deployment of DNSSECbis.  
There is broad, better than rough, consensus in this WG that  
automatic key rollover is a missing and necessary addition to DNSSECbis.

That means that if we develop such protocol it must be widely  
available and for operational successful deployment operators of  
validating devices will have to deploy this (otherwise their life  
becomes a mess).

I read 5.6 to say that if we have developed a mechanism than people  
should be able to either ignore the technology or use manual means to  
perform the rollover. As a metaphor: I can have a robot swap the keys  
or do it myself.

We can no start to quibble if "mandatory to implement" has to be  
defined in the same manner as "royalty free" is defined for this  
particular text. I prefer we rather not do this.

--Olaf

---

From: Paul Vixie <[email-masked]>
Date: Thu, 09 Mar 2006 14:56:43 +0000

we are apparently out of "issue 1" mode, and having a free exchange of ideas,
therefore i will re-enter the discussion.

# I read 5.6 to say that if we have developed a mechanism than people  should
# be able to either ignore the technology or use manual means to  perform the
# rollover. As a metaphor: I can have a robot swap the keys  or do it myself.
# 
# We can no[w] start to quibble if "mandatory to implement" has to be defined
# in the same manner as "royalty free" is defined for this particular text.  I
# prefer we rather not do this.

i don't think "mandatory-to-implement" requires further definition, but i do
think that 5.6 is ambiguous on this point if you can interpret as you
describe.  in particular, if an implementation can fail to include the
automation nec'y for this feature, but make it possible for human hands to
manually insert new keys, then the automation is optional, and therefore not
mandatory to implement.  this also opens the possibility of an "early adopter"
class of implementations who, lacking this automation, rely on human hands to
roll keys, where we know from the history of root hints that this won't occur.

if what we want to say is that IETF standard automation is required, but it
can either follow the specification whose requirements we are now defining or
some later specification, then that would make this first specification
mandatory-to-implement (since it will be, for a time at least, the only IETF
standard automation), but in the future if there are ever multiple IETF
standards for automation in this area, no single one will be mandatory to
implement.  i consider that a rather muddy puddle.

in my view the right thing to do is either declare DNSSEC-bis "done", which
means automated key rollover isn't mandatory, and wide scale implementation
ought to occur immediately; or we ought to declare DNSSEC-bis "undeployable
in its current form" and then itemize the missing features (likely this means
automated key rollover and NSEC3) and get back to work on those.  i do not
care which path is chosen, but i do believe that the choice has to be one or
the other.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 13 Mar 2006 15:44:49 +0100

Paul,

<hats off>

I think DNSSEC bis is not ready without a mechanism that allows for  
automatic key rollover. For the client device there is an operational  
need to configure keys once, turn the device on and let the device  
automagically reconfigure its trust anchors. I do not think there is  
a dispute about this.

We would like to have one single protocol that our clients need to  
understand for that purpose. Such protocol will set operational  
requirements on the DNS service provider; there will have to be bits  
set, RRsets published, RRsets pulled and specific signatures  
generated. Those operational procedures, the rollover mechanism as I  
will call it, will be mandatory to implement at the server side by  
anybody who is in the business of operating a zone that is intended  
to be a "public" entry point in the chain of trust. The exact set of  
zones which are in that business is not known to me but the root is  
definitely a member. So the "rollover mechanism" will be mandatory  
for the root.

If there is no single rollover protocol there might be multiple  
rollover mechanisms required at the root. That would be bad. So we do  
need one protocol with one set of "rollover mechanism" instructions  
for the zone owners.

The client must be able to implement the protocol in software (the  
protocol must be implementable); but may choose not to do so. Still  
for a successful rollover the operator of such client should follow  
the steps described in the protocol or reconfigure the trust-anchors  
from scratch.

Essentially we should have one set of rules to play this game which  
can be fully automated.

Another way of phrasing is:

This would be the "mandatory to implement" mechanism for everybody  
who would want to perform automatic rollover of DNSKEYs. Section 5.6  
just says that you may choose not to perform automatic rollovers.

If you take a car you MUST wear seatbelts, you MAY still choose to  
walk, it just won't get you very far.

--Olaf

---

From: Paul Vixie <[email-masked]>
Date: Mon, 13 Mar 2006 15:03:21 +0000

# Another way of phrasing is:
# 
# This would be the "mandatory to implement" mechanism for everybody who would
# want to perform automatic rollover of DNSKEYs. Section 5.6 just says that
# you may choose not to perform automatic rollovers.

so it's mandatory-to-implement for the root zone and for any other zone ``that
is intended to be a "public" entry point in the chain of trust,'' but it isn't
mandatory-to-implement for requestors, who must be considered to comply with
the DNSSEC protocol even if they don't automate this particular functional.

let me register my disagreement with this position by quoting my own words:

	this ... opens the possibility of an "early adopter" class of
	implementations who, lacking this automation, rely on human hands to
	roll keys, where we know from the history of root hints that this
	won't occur.

another way of phrasing it is, if automation of this function is optional,
then i predict market failure of virtually every implementation which lacks
it, and if these implementations have critical mass, then i predict market
failure of the DNSSEC protocol itself.

however, i must also note that for the purposes of RFC 3979, the fact that
some zone operators (including the root zone) must implement this means it
is "mandatory-to-implement".  so for the purpose of answering issue 1, your
vision of one-sided mandatoryness (while dangerous) supports my proposed
text for 5.2 in the "ISSUE 1" thread.