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

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.

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

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]

---

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

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

---

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

On Mar 5, 2006, at 11:58 AM, Thierry Moreau wrote:

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

---

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