Subject: Section 5.2 (IPR encumberance) in TAK rollover requirement draft

From: Thierry Moreau <[email-masked]>
Date: Sun, 05 Mar 2006 11:58:26 -0500

Dear all:

This message discusses the implications of a no-IPR  encumberment
requirement for trust anchor key rollover in DNSSEC, being
considered by ietf dnsext wg in section 5.2 in
draft-ietf-dnsext-rollover-requirements-00.txt.

First of all, here is a relevant citation from an ietf wg process
perspective, from RFC 3668 section 8:
      "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."

In other words, there exists an *opportunity* for an IETF wg to
evaluate alternate technologies in the presence of IPR claims.
The current wording of section 5.2 in
draft-ietf-dnsext-rollover-requirements-00.txt is an a-priori
option abandonment formulation.

In rational terms, a person or organization having an option
would not renounce of it or abandon it earlier than the option
exercise time. In saying e.g. "... in applying the discretion
granted by RFC3668 section 8, as the case may be, the evaluation
process should assign heavy ponderation to IPR hindrance ..." the
wg governance would have kept its options open and, at the same
time, give a clear indication for its future solution assessment.
A working group is a political entity to which a single-actor
rationale behavior model does not always apply.

Why did the editors of
draft-ietf-dnsext-rollover-requirements-00.txt jumped into the a-
priori option abandonment formulation in the drafting of section
5.2? I suggest the following answer: the editors (or someone who
influenced them) saw that an IPR-encumbered solution was
technologically superior to another one that they preferred, so
an a-priori abandonment strategy would fit their own purpose. If
the IPR-encumbered technology is inferior or even equal to the
free and preferred alternative, the a-priori option abandonment
would have no appeal to the proposer.

Then why nobody in the community yet objected to the a-priori
option abandonment (once proposed)? Suppose DNSSEC has a greater
than negligible value for some participants. A rational behavior
would be to optimize its implementation, given the engineering
constraints. If such participant has no bias for a trust anchor
key solution, he/she would normally argue against an a-priori
option abandonment.

In the present case, trust anchor key configuration is the very
first thing to do when a DNSSEC-aware resolver is installed. The
need for rollover comes from the need to preserve security over
time (i.e. maintaining the end-to-end cryptographic assurance
about data retrieved from the DNS). It is thus somehow linked to
the DNSSEC implementation optimization in the previous paragraph.

So there are two possible conclusions: a) some active
participants are biased towards a free alternative that they are
satisfied with, and/or b) no remaining active participants see
value in DNSSEC to the point where its implementation
optimization is worth some efforts.

Having reviewed the DNSSEC deployment issues, I think DNSSEC is
almost worthless. So the dnsext active participants would be
justified to let the requirement draft proceed with the a-priori
option abandonment formulation of section 5.2. A separate message
is posted about "DNSSEC is almost worthless!"

Does anybody knows why DNSSEC deployment would be significantly
valuable but keeping open an option (to study an IPR-encumbered
implementation alternative) should be banned?

Regards,

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [email-masked]

--
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: Ted Lemon <[email-masked]>
Date: Sun, 5 Mar 2006 11:50:58 -0700

Thierry, I can tell you from my perspective as a person who has no emotional 
involvement whatsoever in the choice between rollover models (other than that 
I'd like for a choice to be made) that the fact that your draft is encumbered 
with a patent makes it extremely unattractive to me.

I know the people who do DNSSEC.   I've known them for a long time.   They are 
good folks.   They've been working on this thankless task for over a decade.   
They've had various smart people and various idiots stand in their way, and 
they've dealt with these afflictions with a dignity that I admire.   At one 
point one of the (corporate) proponents of DNSSEC held a conference that I 
attended to look into doing DNSSEC and DHCP together; they didn't charge me a 
penny for my participation, which did cost them money.   They were even nice 
to me when I got paranoid about whether the restaurant we were going to would 
have vegetarian food and made a small scene about it.   And I happen to know 
that this is not the only such conference that has occurred - it's just the 
only one I've been to, because I personally don't have that much to do with 
DNSSEC.

So it's not appropriate for you to frame the discussion of the patent on your 
technique for key rollover in terms of value.   Real money has been spent by 
the proponents of DNSSEC to make it happen, and real sweat equity as well.   
And frankly the main thing that's prevented DNSSEC from being deployed is 
people trying to figure out how they can make money from it.   Generally 
speaking, the answer has been "exclude most domain names, because the owners 
of those domains can't afford to pay what we want to charge."

The point of promoting the standard is to get everyone to use it, not to 
create a small fenced-in world where a few people who can pay use it.   It's 
not to make a gigabuck taxing access to the technology.   It's to get the 
technology out there, to make peoples safer from hack attacks, even if they 
don't know they're safer.

The fear that I have, and that perhaps others in this working group share, is 
that you want a tax on every DNS lookup.   I've seen many people ask, "what 
is your intention with respect to this patent?   How do you intend to license 
it?"  You haven't said anything about this that I can recall seeing - please 
correct me if I am wrong.

I can attribute this to one of two explanations: either you actually expect to 
get some tax on DNS lookups, and don't want to mention this until you have 
captured the market by getting your draft turned into an RFC, or we as a 
group have stepped on some cultural norm we weren't aware of, and offended 
you so extremely that you can't even bring yourself to make explicit that you 
feel offended in this way.   I can see how this could have happened, 
particularly if you are more accustomed to other standards bodies, where 
patents are part of the cultural norm, and small royalties are as well.   But 
that's not the cultural norm of the IETF.   We aren't culturally okay with 
monetizing mainstream protocols, whatever it says in the IPR RFCs (which, by 
the way, are studiously neutral on this topic).

Whichever explanation of your motivation is true, if you persist in not 
talking about your motivation, I think what's going to happen is that the 
working group is going to assume the worst, and your draft is never going to 
be seriously considered.   This may or may not be fair to you - since I can't 
read your mind, I don't know.   You do have a knob you can turn: tell us what 
you want.   If it turns out that we're not willing to give it to you, the 
outcome is going to be no worse than what happens if you say nothing.

---

From: Paul Vixie <[email-masked]>
Date: Sun, 05 Mar 2006 19:08:00 +0000

# Why did the editors of
# draft-ietf-dnsext-rollover-requirements-00.txt jumped into the a-
# priori option abandonment formulation in the drafting of section
# 5.2? I suggest the following answer: the editors (or someone who
# influenced them) saw that an IPR-encumbered solution was
# technologically superior to another one that they preferred, so
# an a-priori abandonment strategy would fit their own purpose.

as an influencer, i should speak up as to my motives.  i don't know whether
TAKREM is good enough, better, worse, or inadequate compared to other
solutions in the space.  i do know that it smells like a "patent binary
arithmetic" or "copyright the happy birthday song" approach, where there is no
actual new idea, just a new presentation of straightforward ideas already
present in the field.  if my instinct is right, then TAKREM's IPR claims could
be trivially overcome by anyone implementing commercial technology in this
field, but it will cost money.  in that sense, TAKREM smells like an extortion
attempt -- "it's cheaper to license it than fight".  lastly, TAKREM's IPR
claims smell bad because they are so broad that almost any solution to trust
anchor rollover could be accused of infringing on the TAKREM IPR.

taken together, TAKREM is the most wholly unprofessional money-grab i've seen
since the beginning of the blackberry/R.I.M. affair or the SCO-vs-IBM battle,
and my strongest personal reaction to it is "don't even want to dignify it
with a reply."

however, my personal reaction won't matter to ISC (publisher of BIND).  what
matters to ISC is that we have to be able to publish reference implementations
of the DNS protocol under a BSD-style copyright.  TAKREM would require that
we switch to a GPL-style copyright, which we will not do.  therefore if TAKREM
were to be standardized, then it would not be implemented in ISC BIND, and i'm
pretty sure it would be harder to deploy technology in this niche without ISC.
(perhaps this overstates ISC's importance, but some large BIND Forum members
have indicated solidarity for this position.)

so, i havn't reviewed TAKREM because it protected IPR can have no part of the
future of the DNS protocol.  not because i'm somehow afraid that it's better,
but because it self-disqualifies without reference to its quality/usability.

# If the IPR-encumbered technology is inferior or even equal to the free and
# preferred alternative, the a-priori option abandonment would have no appeal
# to the proposer.

that's so nonsequitur that i don't even know how to parse it.  if you want to
be taken seriously as a protocol engineer, then stop trying to monetize the
standardization process.

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Sun, 5 Mar 2006 13:41:50 -0700

Hoping to direct the conversation to its most salient points ...

> what
> of the DNS protocol under a BSD-style copyright.  

What's the source of this requirement on ISC?

> TAKREM would require that
> we switch to a GPL-style copyright, which we will not do. 

I think someone from Verisign said the same thing a few months ago.
Why won't ISC adopt GPL?

Hilarie

---

From: Paul Vixie <[email-masked]>
Date: Mon, 06 Mar 2006 02:30:51 +0000

# Hoping to direct the conversation to its most salient points ...

imho, this isn't one (a salient point).

# > what matters to ISC is that we have to be able to publish reference
# > implementations of the DNS protocol under a BSD-style copyright.
# 
# What's the source of this requirement on ISC?

in 1994 rick adams (then president of uunet) handed me a check to found isc
and he said "none of that gnu public virus crap, got it?"  i got it.  every
dollar/yen/yuan/mark/franc/euro/ruble/etc we've taken in since that time
(including yours, hilarie, while at DoD) was with the understanding that all
funded work would be released under a BSD-style license.  that's what the
board believed when they signed on, it's what our occasional grant funding
angels believe, it's what much of our staff believes, it's what several large
BIND Forum members believe, and of course it's what i believe, and is part
of the "why paul vixie is at ISC at all" equation.  but none of that matters.

# > TAKREM would require that we switch to a GPL-style copyright, which we
# > will not do.
# 
# I think someone from Verisign said the same thing a few months ago.
# Why won't ISC adopt GPL?

because it's far too restrictive.  before we continue, and before anyone
else jumps in, please realize three things: (1) you probably have not read
both licenses and you really should, and (2) this is religion and politics
and economics, not technology, and (3) this topic is about ISC not DNS, and
only ISC's relevance to DNS is on-topic here -- not ISC's licensing religion.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 06 Mar 2006 04:14:38 +0000

# >  (including yours, hilarie, while at DoD) 
# 
# Goodness, Paul, that was US taxpayer money!

the US taxpayers weren't who i would've felt like i'd disappointed if i'd
screwed up, though.  (i suspect that most folks on namedroppers don't know
that without you and russ mundy, BIND9 would have been designed without any
kind of DNSSEC or even the latent capability for adding it in later, which
is my real reason for mentioning it here.)

---

From: "Hilarie Orman" <[email-masked]>
Date: Sun, 5 Mar 2006 20:15:39 -0700

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

>  i got it.  every
>  (including yours, hilarie, while at DoD) 

Goodness, Paul, that was US taxpayer money!

Hilarie

---

From: Alex Bligh <[email-masked]>
Date: Mon, 06 Mar 2006 10:06:44 +0000

--On 06 March 2006 02:30 +0000 Paul Vixie <[email-masked]> wrote:

> and economics, not technology, and (3) this topic is about ISC not DNS,
> and only ISC's relevance to DNS is on-topic here -- not ISC's licensing
> religion.

Actually, it's about a rather wider issue than that. It's about whether
or not ANY author of a resolver library (not just ISC) should have the
ability to publish it under a license of his/her choice without then
being in hoc to a patent holder. Sure ISC is a (very) significant such
author, but it is not guaranteed to be the only one in perpetuity. So
even if ISC /did/ support a GPL carveout on patents, I would be
arguing strongly against it. DNS is fundamentally about interoperability.
Resolver libraries tend to live pretty low down the system stack, and
need to link (directly or indirectly) to everything. Ensuring we have
sensible licensing here is vital. Patent encumbered technologies (albeit
with GPL carveouts) are not sufficient.

Alex

---

From: Ben Laurie <[email-masked]>
Date: Mon, 06 Mar 2006 09:04:29 +0000

> What's the source of this requirement on ISC?

Just so its clear that it isn't only ISC that feels this way, all the
free software I've put any significant effort into is BSD-licensed, and
that's by design. Indeed, The Apache Software Foundation, which I helped
found, is also BSD-only (though it now uses its own licence which
includes language about patents). The reason for this is that I (and the
ASF) want to write software that people can use. The GPL prevents use in
environments where other software that will be combined cannot be made
free, either through religion or licensing agreements or something else.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: Thierry Moreau <[email-masked]>
Date: Mon, 06 Mar 2006 07:56:01 -0500

Paul Vixie wrote, in part:

> [W]hat
> we switch to a GPL-style copyright, which we will not do.  [T]herefore if TAKREM

It is clear that the ISC's ability to *publish* a reference
implementation of the DNS protocol using BSD-style licensing is a
well-established practice in the DNS field, to the benefit of the
Internet, and without direct rewards for the ISC financial contributors.
As a requirement in the requirement draft, this would be phrased like
"In the presence of IPR, attention should be paid to the ability to
publish reference implementations of the DNS protocol as such 
publication represents an important mechanism of ietf protocol 
standardization activities."

Keeping in mind that

   1)turning a reference implementation into "proprietary fork", and

   2)deploying it, e.g. by service organizations that are financed by
DNS name registration fees

goes beyond mere reference implementation publication, the above
requirement might be accommodated by well-delineated licensing terms
(i.e. allowing free publication but requiring additional license for
proprietary fork and/or fee-based deployment). Actually, the separation
of TAKREM specifications in two drafts and some software structure in
the source code posted on the CONNOTECH web site are meant to ease such
licensing practice.

Regards,

-- 

- Thierry Moreau

Tel.: (514)385-5691
Fax:  (514)385-5900

---

From: Thierry Moreau <[email-masked]>
Date: Mon, 06 Mar 2006 09:49:52 -0500

In a long post, Ted Lemon wrote:
>
> [... intro and vegetarian restaurant ...]
> 
> technique for key rollover in terms of value.
> 

The value in DNSSEC that I refer is from no deployment to some
deployment, and *not* from no specifications/working-code to some
specifications/working-code. The latter is where most of the money has 
been spent so far, in the collaborative mode that you describe.

> [...]

There is a cost structure associated with the DNSSEC deployment. The
benefits are accrued to the resolver side, and the bulk of the costs are
incurred on the nameserver side.

> [...]

See http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01694.html
and http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01804.html

Some details might need to be updated, but the main ideas remain.

>
> [... about "the cultural norm of the IETF" ...]
> 

I take good note of this.

> We aren't culturally okay with 
> monetizing mainstream protocols.
> 

However, DNS name registration and nameserver operations is an industry
which is even studied by OECD economists. There is thus a mismatch
between the cultural norm of the IETF and deployment contingencies.

 > [...]

I don't know to which extent your post relates to 
draft-ietf-dnsext-rollover-requirements-00.txt, but anyway thanks for it.

Regards,

-- 

- Thierry Moreau

Tel.: (514)385-5691
Fax:  (514)385-5900

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 6 Mar 2006 10:42:10 -0500

> with GPL carveouts) are not sufficient.

I think the above highlights something that I believe is correct in
the requirements draft: the IPR restrictions, if any, are not
incidental to the technology that is to be picked in this case, but
are instead central.  As RFC 3979 says, "In all matters of
Intellectual Property Rights, the intent is to benefit the Internet
community and the public at large, while respecting the legitimate
rights of others."  There simply isn't a way to benefit the Internet
community and the public at large by adopting any sort of potential
encumbrance in a technology totally fundamental to the operation of
the Net, because there's a significant portion of the Internet
community that relies on BSD software.  

A

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

---

From: Paul Vixie <[email-masked]>
Date: Mon, 06 Mar 2006 18:34:16 +0000

# > ... only ISC's relevance to DNS is on-topic here -- not ISC's licensing
# > religion.
# 
# Actually, it's about a rather wider issue than that. It's about whether
# or not ANY author of a resolver library (not just ISC) should have the
# ability to publish it under a license of his/her choice without then
# being in hoc to a patent holder. Sure ISC is a (very) significant such
# author, but it is not guaranteed to be the only one in perpetuity.

ISC is already not the only author/publisher of free-ish resolver libraries.

# So even if ISC /did/ support a GPL carveout on patents, I would be arguing
# strongly against it. DNS is fundamentally about interoperability.  Resolver
# libraries tend to live pretty low down the system stack, and need to link
# (directly or indirectly) to everything. Ensuring we have sensible licensing
# here is vital. Patent encumbered technologies (albeit with GPL carveouts)
# are not sufficient.

note that a patent would probably not proscribe ISC from publishing code that
implemented an claimed algorithm.  it would proscribe folks from using it in
commerce, either by selling products that implemented the claimed algorithm,
or by operating a revenue-generating service that implemented the claimed
algorithm.  coming after ISC would make no sense since there's no revenue
stream associated with our publication of BSD-licensed software.

interestingly, ISC makes no assurances that our software is IPR-free, but we
do make a best effort to ensure such.  (no _assurance_ is possible, due to
possible submarine patents.)  knowing in advance that a given algorithm is
encumbered would prevent us from implementing/publishing code using such.

that having been said, you are right that the real issue is in monetization
itself, not in where it occurs.  i strongly believe that any encumbered
technology should either be available with a royalty-free license to all
internet users, service providers, and technology vendors; or it should not
be made an internet standard.  this was my position on the use of RSA, and
RSADSI kindly created a "dnssafe" package with a license permitting unlimited
royalty-free use for DNSSEC, which we then used in BIND8 where we needed RSA.
(thanks are due from all of us to steve crocker for brokering that deal, btw.)

this whole thread is a distraction.  the author of TAKREM isn't going to
grant a world wide perpetual royalty-free license for all uses commercial or
otherwise for his claimed IPR -- indeed, that would be against the purpose he
has stated for even claiming the IPR in the first place.  this means we have
to press on with technology approaches we believe to be unencumbered.  in the
end, we will have some kind of trust key rollover mechanism, and the TAKREM
author can do a SCO or R.I.M. style attack against anyone who successfully
monetizes the result (that is, claiming that ALL possible ways to solve this
problem are covered under the TAKREM patent) and we'll all deal with the mess
at that time.

for now, let's focus on solutions, not licensing religion?

---

From: Paul Vixie <[email-masked]>
Date: Mon, 06 Mar 2006 18:43:38 +0000

# ... There simply isn't a way to benefit the Internet community and the
# public at large by adopting any sort of potential encumbrance in a
# technology totally fundamental to the operation of the Net, because there's
# a significant portion of the Internet community that relies on BSD software.

i agree with your conclusion, but not with your reasoning.  what the internet
community relies on is unencumbered technology.  one expects that if somebody
were to come forward with a patent that they believed covered TCP or IP, and
tried to get everyone in the world to pay a millicent per packet, that we'd
very quickly see the rapid development and deployment of some non-encumbered
alternatives.  (and in the course of developing such alternatives, we would
disqualify any proposal that had known encumberances, unless the IPR-holder
were to grant a permanent, world wide, royalty free license for all uses 
either commercial or not.)

so it's not really a question about BSD vs GPL at all.  it's a question of
encumberances.  internet technology standards must be unencumbered to the
best of our ability.  by disclosing his encumberances, the TAKREM author has
disqualified himself, or at least his work, from further consideration.

now can we talk about possible approaches?  i still like my modified version
of the ihren/kolkman proposal, but i've been waiting for the requirements doc
to be done, and now there's mud in THAT water as well.  (don't'cha sometimes
wish that something like MODA existed to fund this kind of protocol scutwork?)

---

From: [email-masked]
Date: Mon, 6 Mar 2006 21:12:57 +0000

On Mon, Mar 06, 2006 at 04:31:13PM -0500, Thierry Moreau wrote:
> Paul Vixie wrote:
> >[T]he TAKREM
> >problem are covered under the TAKREM patent) [...].
> >
> 
> This is completely ridiculous! Please record my disagreement.
> 
> 
> -- 
> 
> - Thierry Moreau
> 

	i'm going to have to agree w/ Thierry here.  Now if Paul
	said "[T]he TAKREM *patent holder* can do..." then i'd have
	to jump w/ Paul.  It just silly to think that the author
	would always remain the patent holder.  So regardless of 
	the authors benign intentions, the mere existance of such 
	encumbrence gives one pause.  (consider the estate of Heddy
	Lamar)

--bill

---

From: Thierry Moreau <[email-masked]>
Date: Mon, 06 Mar 2006 16:31:13 -0500

-- 

- Thierry Moreau

Tel.: (514)385-5691
Fax:  (514)385-5900

---

From: Matt Larson <[email-masked]>
Date: Mon, 6 Mar 2006 18:20:08 -0500

On Mar 6, 2006, at 9:49 AM, Thierry Moreau wrote:
>> We aren't culturally okay with monetizing mainstream protocols.
>

Translation: "People are making money here and I want some, too."

I'm in agreement with Paul that this whole thread is a distraction.   
I continue to remain happily ignorant of the details of TAKEM because  
the author--both by what he has said and done and by what he has not  
said and not done--has made it clear that there will not be  
acceptable license terms that will result in this technology being  
unencumbered.  Thus it is best ignored and set aside.

We should redouble our efforts to improve the rollover requirements  
draft, pick a solution and move on.  We should also resist temptation  
and ignore self-serving distractions.  We don't have the time or  
energy to do otherwise.

Matt

---

From: Paul Vixie <[email-masked]>
Date: Tue, 07 Mar 2006 01:16:09 +0000

# > [...]  [T]he TAKREM author can do a SCO or R.I.M. style attack against
# > anyone who successfully monetizes the result (that is, claiming that ALL
# > possible ways to solve this problem are covered under the TAKREM patent)
# > [...].
# 
# This is completely ridiculous! Please record my disagreement.

so noted, for whatever that's worth.

perhaps you can help, out of the spirit of professionalism, to steer this
WG toward solutions that do not infringe?  i'm thinking that you could send
out a patent number, page, and paragraph number any time you think a proposal
here would ultimately lead the eventual holder of your IPR to come knocking?

---

From: Thierry Moreau <[email-masked]>
Date: Mon, 06 Mar 2006 21:07:51 -0500

Ted Lemon wrote:
> 
> I don't pay extra to use SSH.   I don't pay extra to use SSL.   I don't pay 
> extra to use PGP.   I don't pay extra to use IPSEC.   So why do you think 
> it's okay that I should pay extra to use DNSSEC?
> 

Short answer: infrastrusture-based ubiquitous key management.

I.e. with SSH, PGP, and IPSEC the key management burden rests on you. As
an unauthenticated client in SSL, the remote server paid for the
security certificate that you "rely" upon.

> 
> And I think, I hope, that the 
> working group as a whole does not want the outcome of the long process of 
> inventing DNSSEC to be that only those who can pay extra for it get to enjoy 
> the benefits of all this work.
> 

If I understand this, there would be an analogy between DNSSEC and
smallpox vaccine which was so beneficial to the world that it deserved
(government-funded) no-fee distribution. Indeed it worked: smallpox has
been eradicated from the planet.

Regards,

-- 

- Thierry Moreau

Tel.: (514)385-5691
Fax:  (514)385-5900

---

From: Thierry Moreau <[email-masked]>
Date: Mon, 06 Mar 2006 21:47:45 -0500

Paul Vixie wrote:

> WG toward solutions that do not infringe?

So I'm a SCO-raider on one post, then a messianic professional WG 
steersman on the next!

> i'm thinking that you could send

More seriously, in good faith, I abide by the disclosure rules in RFC3979.

The documents for which an IPR disclosure has been made in relation to 
TAKREM are
   1) draft-moreau-dnsext-takrem-dns
   2) draft-moreau-pkix-takrem

That's it.

-- 

- Thierry Moreau

Tel.: (514)385-5691
Fax:  (514)385-5900

---

From: Paul Vixie <[email-masked]>
Date: Tue, 07 Mar 2006 05:02:30 +0000

> > WG toward solutions that do not infringe?

# So I'm a SCO-raider on one post, then a messianic professional WG steersman
# on the next!

i wasn't trying to be funny.  if, as i hope and expect, it turns out that
encumbered technologies are considered self-disqualified for this, then you
have lost your bid to standardize a moneyfunnel from the world to your door.
in that case, you could choose to...

1. keep fighting about it (if anyone will further engage you, it won't be me).

2. grant a worldwide perpetual royalty free license for all DNS uses of TAKREM
   whether commercial or otherwise, and try to monetize it in some other way
   like writing a book, consulting, or going on Oprah.

3. hope that no viable alternative is found and the WG decides to look at
   TAKREM in spite of its encumberances.

4. something bizarre.

because of who i am and what i've done and where i've been, i like #4 best, and
so i'm suggesting, in all seriousness, that you help the WG -- in the best
spirit of professionalism -- to reach the goal of avoiding your encumberances.

---

From: Thierry Moreau <[email-masked]>
Date: Mon, 06 Mar 2006 21:07:51 -0500

Regards,

-- 

- Thierry Moreau

Tel.: (514)385-5691
Fax:  (514)385-5900

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 06 Mar 2006 22:49:37 -0800

>>>>> On Mon, 06 Mar 2006 21:07:51 -0500, Thierry Moreau <[email-masked]> said:

Thierry> If I understand this, there would be an analogy between
Thierry> DNSSEC and smallpox vaccine which was so beneficial to the
Thierry> world that it deserved (government-funded) no-fee
Thierry> distribution. Indeed it worked: smallpox has been eradicated
Thierry> from the planet.

If you want to achieve maximum DNSSEC deployment, yes you must be
willing to offer a solution to not just the rich but to everyone.
Doing anything else would not be providing a full solution.  If we
believe that trust management is a problem and if we want to achieve
the widest deployment of a trust management solution then we need to
use an unencumbered solution.  The only other alternative is to offer
a solution to a smaller number of people.

When it comes to deploying security protocols, we should always strive
to create solutions that achieve the best deployment spread possible
for all potential users.  We should never strive to create solutions
that are only usable by the rich, the intelligent, the powerful or the
elite.

-- 
Wes Hardaker
Sparta, Inc.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 7 Mar 2006 09:48:06 +0100

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.

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

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

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.

--Olaf

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

---

From: Damien Miller <[email-masked]>
Date: Tue, 7 Mar 2006 20:24:47 +1100 (EST)

>   be compatible with the BSD open source license

(delurking)

I would suggest that this is necessary, but not sufficient; the
license should also allow unencumbered commercial exploitation of the
technology otherwise the main benefit of the BSD licence (conducive to
reference implementations that may be freely incorporated into free and
proprietary products) are lost.

-d

---

From: Edward Lewis <[email-masked]>
Date: Tue, 7 Mar 2006 04:32:32 -0500

At 9:48 +0100 3/7/06, Olaf M. Kolkman wrote:

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

I think I'd favor this.  Only because this is a DNS document and IPR 
is something I don't understand and I find quite boring.

Still, I would not accept an encumbered technology in a IETF 
standard.  Perhaps there is an IPR WG document that explains this and 
we should reference that.

I have no qualms about paying for encumbered technology.  (I have yet 
to fly in an airplane that was built without encumbered technology.) 
But it has no place in an IETF standard because the goal is 
interoperability.

As far as the TAKRAM proposal, I ignore it on principle that it is 
encumbered and will therefore be unlikely a solid base for an 
interoperable standard.  It doesn't matter to me whether I will have 
to pay for something, it bothers me that "the other side" may not be 
able to pay for the improvement.

It's like this, an example from DNSSEC.  If I design a cryptographic 
algorithm that is far superior to RSA/SHA1, code it up, and sign my 
zones only with my algorithm, resolvers only equipped with RSA/SHA1 
will see my zone as unsigned.  Instead of enhancing my security with 
super cryptography, I cripple my security by not using the common 
algorithm.

For interoperability, commonality is more important that 
optimization.  Any possible benefit of TAKRAM is erased by the threat 
of it not being available to any *any* implementation of DNS.  The 
argument against encumbered technology is not about money, return on 
contribution (politer word than investment), market control, etc. 
It's about interoperability.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

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

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 7 Mar 2006 10:54:20 +0100

> (delurking)

Welcome :-)

> proprietary products) are lost.

I thought that was covered by "should be compatible with BSD  
license" (but that is just me trying to find wording on which we can  
consent)

If you know better wording do send a patch to the text please; If  
current text is not perfect but you can consent than please indicate  
that. Otherwise we are keep running in circles by making statements  
and not getting to a text we can all agree on.

I will try to back off now :-)

--Olaf

---

From: Damien Miller <[email-masked]>
Date: Tue, 7 Mar 2006 21:03:56 +1100 (EST)

On Tue, 7 Mar 2006, Olaf M. Kolkman wrote:

> I thought that was covered by "should be compatible with BSD license" (but
> that is just me trying to find wording on which we can consent)

I have seen licenses (on software, not patents though) where payment
provisions are activated when the source is not made available, so 
while these are technically compatible with the BSD license, they
somewhat scuttle its spirit of non-discrimination. This is what I
was trying to avoid, but reading the text of RFC3979 section 6.5
option (a), it isn't an issue anyway.

So, please ignore my rant :)

-d

---

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 7 Mar 2006 02:55:35 -0800 (PST)

>   be compatible with the BSD open source license

Would having license compatible with BSD open source license also
automatically cover those that want to release software under GPL?

The reason I ask is that we had a problem on another WG (MARID) where 
offered license was compatible with most of BSD-style licenses, but was 
not compatible with GPL. That did not go very well with large portion
of those interested and ultimately WG failed in big part because of this
issue. So my preference would be to see your line modified to read

"(a), the license SHOULD be compatible with the BSD and GPL
       open source licenses"

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: [email-masked]
Date: Tue, 7 Mar 2006 11:10:49 +0000

ed is wise in the ways of protoocol development.  C: is the most prudent
 course.  otherwise, if there is a need to refer to IPR at all, i'd take 
 A: - since that is the path of least resistance.

--bill

---

From: Edward Lewis <[email-masked]>
Date: Tue, 7 Mar 2006 06:13:03 -0500

I'd prefer...

5.2 Conformance with IETF standards

    The solution MUST be covered by one of options
    (a) or (c) of section 6.5 of [RFC3979].

No specific mention of IPR (ick), but compatibility with IETF 
standards for, umm, standards.

I.e., it's not that I want BSD licences, I don't want any (other) licenses.

If you try to argue with me over the beauty of the BSD license my 
eyes will glaze over, I'll stick my fingers in my ears, hum the 
national anthem of Elbonia and dream of the man page for ld(1). ;) 
I.e., I don't care about license discussions. I want interoperability.

At 9:48 +0100 3/7/06, Olaf M. Kolkman wrote:
>On the basis of previous discussion on the list I think we can go 
>for a consensus call on the text below:
>
>state your own arguments once and trust others to be able to read. 
>If you need clarification of arguments please ask.
>
>Please remain courteous and civil. Please respect the motivations 
>for peoples opinions.
>
>--Olaf
>
>
>
>
>content-type: application/pgp-signature; x-mac-type=70674453;
>	name=PGP.sig
>content-description: This is a digitally signed message part
>content-disposition: inline; filename=PGP.sig
>content-transfer-encoding: 7bit
>
>Attachment converted: Macintosh HD:PGP 146.sig (pgDS/    ) (001AFBAB)

---

From: Edward Lewis <[email-masked]>
Date: Tue, 7 Mar 2006 06:16:39 -0500

Great - I'm called "wise" minutes after threatening to glaze my eyes 
over, stick my fingers in my ears, hum a tune and dream of a man 
page. ;)

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 07 Mar 2006 13:27:48 +0100

>    The solution SHOULD not have any intellectual

I suggest SHOULD NOT here.

>    used by the solution nor implementations

The word "intellectual property" seems odd.  IP include copyrights,
and most likely the technology that will be proposed for this problem
will be copyrighted.

If this text is kept at all, I suggest modifying "intellectual
property" into "patent", if that is what you really are referring to.

>    be compatible with the BSD open source license

Again, I believe that this should be changed to include more licenses,
such as the GPL.  If the text is kept at all, of course.  BSD code is
not necessarily possible to use under the GPL.  For completeness,
mentioning Microsoft EULA may be useful too, the DNS resolver in
Windows is widely used today.

I believe we should require (a) _and_ (c).  Obtaining a license may be
difficult enough to prohibit some usages, and I don't see why
including that option would improve the technology.

> a: That they consent with section 5.2 as above.

With my modifications, yes.

> argumentation and "patch"

See the two changes above.

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

The term IPR often confuse things, please say patents if that is the
problem.  In theory, I'd prefer if we solved this without any IPR
concerns at all, and stuck to the technology issues, but I don't think
it is practical to expect that to work in the field.  So I think we'll
need to include something to this effect, to make sure everyone can
implement it without problems.

Note that I'm not implying that TAKREM's license is too problematic to
consider.  If the "GPL" was changed into "GPL, LGPL or BSD", it might
very well be a candidate for the final solution.  Even if TAKREM is
patented.

Thanks,
Simon

---

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

> license" (but that is just me trying to find wording on which we can  

Would this do:

   If the technology is covered by option (a), the license SHOULD NOT
   be more restrictive than the BSD open source license

or this

   If the technology is covered by option (a), the license SHOULD
   permit implementation and distribution under the terms of the BSD
   open source license

?

I am aware that both of these are stronger than the original text, so
I can see why they'd be objectionable to some.

A

---

From: Ted Lemon <[email-masked]>
Date: Mon, 6 Mar 2006 14:53:48 -0700

> This is completely ridiculous! Please record my disagreement.

I don't think that you intend anything that you think is unreasonable, but 
that's immaterial, because your model for how DNSSEC should be deployed is 
not what I want.   Your model as stated in one of the two emails to which you 
referred me is that some people will pay extra for DNSSEC, and everyone else 
will not have it.   And you'd like a cut of the transactions where people do 
pay for it.

I don't care about you getting a cut of the proceeds.   But what I do care 
about is that in order for you to get what you want, the business model for 
DNSSEC has to be a two-tier model where I have to pay extra to get security.

There is a difference between designing a protocol that *forces* a two-tier 
model, and designing a protocol that *allows* a two-tier model.   In the 
former case, if the two-tier model fails, the protocol fails.   In the latter 
case, if the two-tier model fails, we're okay - a lot of us didn't want the 
two-tier model anyway.

By structuring things the way you intend to, you force anyone who charges to 
register a domain name, even if they charge the same price for secure versus 
not secure, to pay you a fee.   So your proposal creates an economic 
incentive for exactly the opposite of what I hope to see as the outcome of 
the process of standardizing DNSSEC.

So even though it's not technically a protocol issue, designing into the 
protocol a requirement like the one you've stated is completely unacceptable 
to me.

I realize that this sucks for you.   You've created something, which you at 
least think is cool enough that you felt it was worthy of patent protection.   
And nobody even wants to talk about the thing you created - they just want to 
talk about the patent issue.   And people are even making somewhat unkind 
accusations.

But the working group can't be concerned with what sucks or doesn't suck for 
you.   This isn't a negotiation over terms.   This is a discussion about what 
the working group wants as an outcome.   And I think, I hope, that the 
working group as a whole does not want the outcome of the long process of 
inventing DNSSEC to be that only those who can pay extra for it get to enjoy 
the benefits of all this work.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 6 Mar 2006 20:42:10 -0700

> been eradicated from the planet.

Your analogy is flawed: you haven't invented the only cure for the key 
rollover problem, and there is no need for the governments of the world to 
buy you out.   If you'd care to dispute that point by claiming that you have 
in fact invented and patented all possible key rollover solutions, then 
perhaps we are at your mercy.   But you have made no such assertion, so at 
least for now it is fair for us to assume that we are not.

---

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

> not careful I propose some process that sets a timeline to this  

Thank you!

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

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

I'm for choice c.

Thomas

---

From: Rob Austein <[email-masked]>
Date: Tue, 07 Mar 2006 09:31:23 -0500

> a: That they consent with section 5.2 as above.

Yes.

---

From: Thierry Moreau <[email-masked]>
Date: Tue, 07 Mar 2006 11:30:04 -0500

Olaf M. Kolkman wrote:
> a: [...]
> b: [...

I vote for c. I.e. not closing a-priori an option the wg may use later.

Regards,

-- 

- Thierry Moreau

Tel.: (514)385-5691
Fax:  (514)385-5900

---

From: Ted Lemon <[email-masked]>
Date: Tue, 7 Mar 2006 11:04:26 -0700

>     be compatible with the BSD open source license

For those who haven't read it, the section referenced in RFC3979 in fact 
already covers both the BSD license and the GPL - it specifies a 
royalty-free, reasonable and non-discriminatory license.   So I don't think 
there's any need to mention either license here.   Having said that, I think 
that the text is fine, and I agree to it as written (but would not object to 
removing the last sentence of the second paragraph).

---

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:

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

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

---

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

---

From: Robert Story <[email-masked]>
Date: Tue, 7 Mar 2006 10:15:24 -0500

On Tue, 7 Mar 2006 09:48:06 +0100 Olaf wrote:
OMK> I'd like to ask participants to state on-list
OMK> 
OMK> a: That they consent with section 5.2 as above.

Yes.

-- 
Robert Story
SPARTA

---

From: Thierry Moreau <[email-masked]>
Date: Wed, 08 Mar 2006 12:53:55 -0500

Olaf M. Kolkman wrote:

> 
> 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.
> 
> 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 I read correctly some ot the other opinions, the clause 5.2 should 
state a *principle* by which the wg will address IPR issues, for a 
broader scope than just trust anchor key automated rollover, and asking 
more determinism in the IPR status of ietf specifications than that what 
has been anticipated by the authors of RFC3979.

In order to support the opposite view that each IPR situation should be 
considered on its own merit, background, etc. I submit the following 
factual argument:

https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=624

see also

http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.html&r=1&f=G&l=50&s1=%2220020152382%22.PGNR.&OS=DN/20020152382&RS=DN/20020152382

You may call this the "DS RR patent pending issue".

I have absolutely no association, neither directly nor indirectly, with 
this United States Patent Application 20020152382, its inventor(s), 
owner(s), assignee(s), or agent(s). It is unfortunate that my name pops 
up in the title of this ietf IPR detail page: there seems to be a hidden 
reputation cost in good faith behavior suggested by RFC3979 (Please 
carry any discussion on this sentence in the appropriate IPR wg forum, 
i.e. [email-masked]).

Regards,

-- 

- Thierry Moreau

Tel.: (514)385-5691
Fax:  (514)385-5900

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 08 Mar 2006 10:31:39 -0800

>>>>> On Tue, 7 Mar 2006 06:16:39 -0500, Edward Lewis <[email-masked]> said:

Edward> Great - I'm called "wise" minutes after threatening to glaze my eyes 
Edward> over, stick my fingers in my ears, hum a tune and dream of a man 
Edward> page. ;)

What's the problem?  Your actions sound wise to me.

-- 
Wes Hardaker
Sparta, Inc.

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 08 Mar 2006 10:35:15 -0800

>>>>> On Tue, 7 Mar 2006 09:48:06 +0100, "Olaf M. Kolkman" <[email-masked]> said:

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

Olaf> a: That they consent with section 5.2 as above.

Olaf> b: They would like to see section 5.2 as above modified. Then send  
Olaf> argumentation and "patch"

(a or b) but not c.  There have been many b's floated by, many of
which I agree with.

-- 
Wes Hardaker
Sparta, Inc.

---

From: Suresh Krishnaswamy <[email-masked]>
Date: Wed, 8 Mar 2006 17:03:24 -0500

I vote in favor of

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

However, I _would_ like to see the scope of '5.3 General  
Applicability' expanded to say something along the lines of "the  
technology must be globally implementable and usable without bias. "

Suresh

---

From: Suresh Krishnaswamy <[email-masked]>
Date: Wed, 8 Mar 2006 17:20:43 -0500

Once we do get down to comparing different proposals against the set  
of requirements its quite possible that we may find each approach  
lacking in some respect. I don't think the intent of the requirements  
document was to impose an "a-priori option abandonment formulation"  
of any one approach. From what I understand, its a collection of  
requirements that the working group *itself* has proposed at some  
point or the other.

Its really up to the working group to decide the order in which these  
requirements are important in order to identify the "preferred"  
solution.

Suresh

---

From: Mike StJohns <[email-masked]>
Date: Wed, 08 Mar 2006 18:40:55 -0500

With respect to DS - this patent (or application)  is invalid on its 
face.  The original DS draft was dated May 2001 - 18 months prior to 
the date of the patent application.

At 12:53 PM 3/8/2006, Thierry Moreau wrote:

>In order to support the opposite view that each IPR situation should 
>be considered on its own merit, background, etc. I submit the 
>following factual argument:
>
>I have absolutely no association, neither directly nor indirectly, 
>with this United States Patent Application 20020152382, its 
>inventor(s), owner(s), assignee(s), or agent(s). It is unfortunate 
>that my name pops up in the title of this ietf IPR detail page: 
>there seems to be a hidden reputation cost in good faith behavior 
>suggested by RFC3979 (Please carry any discussion on this sentence 
>in the appropriate IPR wg forum, i.e. [email-masked]).

As I understand this - you're the one who filed the disclosure - it 
was your "Personal Belief" that referenced this application.  So your 
association or lack thereof is a non-issue.  Fortunately, so is your 
IPR disclosure.

And for that matter, so is your "factual" argument.

---

From: Thierry Moreau <[email-masked]>
Date: Wed, 08 Mar 2006 20:51:16 -0500

Mike StJohns wrote:

> face.  The original DS draft was dated May 2001 - 18 months prior to the 
> date of the patent application.
> 

Thanks for pointing this relevant prior art fact. I expected this to be 
the case but I didn't know the details. When I submitted this to the 
IETF IPR disclosure mechanism, I expected that such relevant fact would 
be quickly brought up by experts, then appropriately forwarded to the 
inventor/agent/patent office so that the claim is appropriately dropped 
before, or rejected during, patent examination. This didn't occur, as 
far as I can tell. Will it occur? I don't know. Is it a patent office 
duty to become self-aware of dnsext public forum back in May 2001 in 
relation to this X.509 patent? I don't think so. If nothing happens, 
will such a generic claim be approved by the USPTO (United States Patent 
and Trademark Office) on the basis of leaner X.509 prior art? (Perhaps 
the DNSSEC prior art will assist X.509 technology unencumberance here.) 
If approved by the USPTO, the annoyance of having this patent voided 
after issuance is certainly greater than the annoyance of acting now for 
the claim to be withdrawn or rejected in the first place.

This has been presented now in this forum as an example of IPR issues 
which are best handled on a case by case basis, on specific result 
oriented approaches applicable to each of the circumstances. A blanket 
statement about an idealistic view of the end-result would not have 
helped this "DS RR patent pending issue".

-- 

- Thierry Moreau

Tel.: (514)385-5691
Fax:  (514)385-5900

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 8 Mar 2006 23:40:56 -0800

> > face.  The original DS draft was dated May 2001 - 18 months prior to
the
> far as I can tell.

It is also the inventors' duty to signal to the patent office any prior
art that they know about.

-- Christian Huitema