Section 5.2 (IPR encumberance) in TAK rollover requirement draft
Thierry Moreau
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: thierry...@connotech.com
--
to unsubscribe send a message to namedroppe...@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
Ted Lemon
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.
Paul Vixie
# 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.
The Purple Streak, Hilarie Orman
> 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?
> 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
Paul Vixie
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.
Paul Vixie
#
# 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.)
Hilarie Orman
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
> dollar/yen/yuan/mark/franc/euro/ruble/etc we've taken in since that time
> (including yours, hilarie, while at DoD)
Goodness, Paul, that was US taxpayer money!
Hilarie
Ben Laurie
> Hoping to direct the conversation to its most salient points ...
>
>> matters to ISC is that we have to be able to publish reference implementations
>> of the DNS protocol under a BSD-style copyright.
>
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
Alex Bligh
--On 06 March 2006 02:30 +0000 Paul Vixie <pa...@vix.com> wrote:
> 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.
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
Thierry Moreau
Paul Vixie wrote, in part:
> [W]hat
> 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. [T]herefore 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.)
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: thierry...@connotech.com
--
Thierry Moreau
In a long post, Ted Lemon wrote:
>
> [... intro and vegetarian restaurant ...]
>
> So it's not appropriate for you to frame the discussion of the patent on your
> 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.
> [...]
> 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."
>
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.
>
> [...]
>
> 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.
>
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.
Paul Vixie
# > 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?
Paul Vixie
# 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?)
Andrew Sullivan
> 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.
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
<and...@ca.afilias.info> M2P 2A8
+1 416 646 3304 x4110
Thierry Moreau
Paul Vixie wrote:
> [...]
> [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.
--
- 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: thierry...@connotech.com
bman...@vacation.karoshi.com
>
>
> Paul Vixie wrote:
>
> >[...]
> >[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.
>
>
> --
>
> - 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
Matt Larson
>> 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.
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
Paul Vixie
# > 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?
Thierry Moreau
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
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: thierry...@connotech.com
Thierry Moreau
Paul Vixie wrote:
> # > [...] [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?
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
> 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?
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.
Paul Vixie
> > 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?
# 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.
Olaf M. Kolkman
--Apple-Mail-37-205329752
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
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/
--Apple-Mail-37-205329752
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: This message is locally signed.
iD8DBQFEDUjHtN/ca3YJIocRAjy1AKC5QD4gU5mvrWnNHob/TwmMkPOcXACgg4gY
a1km1NXfrt+ECQmyRVxDb/k=
=Ve8M
-----END PGP SIGNATURE-----
--Apple-Mail-37-205329752--
Edward Lewis
>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...
Olaf M. Kolkman
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>
> (delurking)
>
Welcome :-)
> 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.
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
-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/
--Apple-Mail-41-209303033
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: This message is locally signed.
iD8DBQFEDVhMtN/ca3YJIocRAmg8AKD6CXAVdkqTJvS2oUbTo2APXDSTcgCgwCrB
k9F/sVg700eaB1WUkmZY+to=
=vScM
-----END PGP SIGNATURE-----
--Apple-Mail-41-209303033--
william(at)elan.net
On Tue, 7 Mar 2006, Olaf M. Kolkman wrote:
> 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
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
wil...@elan.net
bman...@vacation.karoshi.com
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
On Tue, Mar 07, 2006 at 09:48:06AM +0100, 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.
>
> 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/
>
>
>
--
Edward Lewis
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.
>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)
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
Nothin' more exciting than going to the printer to watch the toner drain...
--
Edward Lewis
over, stick my fingers in my ears, hum a tune and dream of a man
page. ;)
At 11:10 +0000 3/7/06, bman...@vacation.karoshi.com wrote:
> 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
>
Simon Josefsson
> 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
I suggest SHOULD NOT here.
> property encumbrance on either the technologies
> used by the solution nor implementations
> of the solution.
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.
> 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
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.
> I'd like to ask participants to state on-list
>
>
> a: That they consent with section 5.2 as above.
With my modifications, yes.
> b: They would like to see section 5.2 as above modified. Then send
> argumentation and "patch"
See the two changes above.
> c: They would like to see any mention of IPR dropped from the
> requirements.
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
Thomas Narten
> Since this is one of the issues that can drag on forever if we are
> not careful I propose some process that sets a timeline to this
> discussion.
Thank you!
> On the basis of previous discussion on the list I think we can go for
> a consensus call on the text below:
> 5.2 No Intellectual Property Encumbrance
> The solution SHOULD not have any intellectual
> property encumbrance on either the technologies
> used by the solution nor implementations
> of the solution.
> The solution MUST be covered by one of options
> (a) or (c) of section 6.5 of [RFC3979]. If the
> technology is covered by option (a), the license SHOULD
> be compatible with the BSD open source license
IMO, Section 5.2 is completely misguided. Here, we have the classic
case of a "requirements document" trying to pick (or exclude) a
particular solution, in advance of actually working on a solution. But
the approach being used is a hammer (e.g., "no IPR is acceptable"),
when at the end of the day, we'd be better off doing an evaluation of
the specific case at hand, and making a decision based on the
available information.
I believe I understand what the above section is attempting to
achieve. And I support that general goal.
But, the WG would be a lot better off taking each IPR claim as it
stands. Look at the technology, look at the IPR issues, and then
simply decide (on a case-by-case basis), does the WG want to adopt the
technology, or does it want to (try to) route around it and use
something different? The only way to answer this question (as
engineers -- where one weighs the pros and cons) is to evaluate two
proposals, one with the IPR, and one that is believed to route around
it. If the latter is an adequate technical solution, the WG should
just go for it. If not, it needs to reevaluate its options.
> I'd like to ask participants to state on-list
> c: They would like to see any mention of IPR dropped from the
> requirements.
I'm for choice c.
Thomas
Rob Austein
>
> 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
>
>
Yes.
Ted Lemon
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. ]
On Monday 06 March 2006 14:31, Thierry Moreau wrote:
> 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.
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?
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.
Ted Lemon
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. ]
On Monday 06 March 2006 19:07, Thierry Moreau wrote:
> 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.
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.
Thierry Moreau
Olaf M. Kolkman wrote:
>
> I'd like to ask participants to state on-list
>
>
> a: [...]
>
> b: [...
>
> c: They would like to see any mention of IPR dropped from the
> requirements.
>
I vote for c. I.e. not closing a-priori an option the wg may use later.
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: thierry...@connotech.com
Ted Lemon
> 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
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).
Paul Vixie
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:
> 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.
and here's my answer. count me as (b). argumentation as above. patch is:
5.2 No Intellectual Property Encumbrance
Because trust anchor rollover is considered "mandatory-to-implement",
section 8 of [RFC3979] requires that the technology solution chosen must
be unencumbered or must be available under royalty-free terms.
For this purpose, "royalty-free" is defined as follows: world wide,
perpetual right to use, without fee, in commerce or otherwise, where "use"
includes descriptions of algorithms, distribution and/or use of hardware
implementations, distribution and/or use of software systems in source
and/or binary form, in all DNS or DNSSEC applications including registry,
registrar, domain name service including authority, recursion, caching,
forwarding, stub resolver, or similar.
In summary, no implementor, distributor, or operator of the technology
chosen for trust anchor management shall be expected or required to pay
any fee to any IPR holder for the right to implement, distribute, or
operate a system which includes the chosen mandatory-to-implement
solution.
i might not be in dallas. i do however "trust others to be able to read."
Alex Bligh
--On 07 March 2006 18:49 +0000 Paul Vixie <pa...@vix.com> wrote:
> and here's my answer. count me as (b). argumentation as above. patch
> is:
I think Paul has it right. So count me as (b) with his patch too.
Alex
Alex Bligh
Alex Bligh
Wes Hardaker
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.
Damien Miller
> 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
(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
Damien Miller
> 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 :)
Olaf M. Kolkman
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>
>> and here's my answer. count me as (b). argumentation as above.
>> patch
>> is:
>
> I think Paul has it right. So count me as (b) with his patch too.
Paul's text as the property that it does not mention the specific
licenses; that does remove one the topics we are ratholing on (I do
not think this working group should try to figure out what is the
better license BSD, GPL2 or GPL3).
Paul's premisses is that we had consented on the "mandatory-to-
implement" part of the key-rollover. The exact RFC2119 form (MUST,
SHOULD or MAY NOT implement) of that requirement is open to
discussion but I think we do consent to the spirit of the "mandatory-
to-implement" part; "mandatory-to-implement" should be in between
quotes indeed.
So in order to try and reach convergence --- which is incredibly
difficult --- Are there more takers for this position?
Remember that we are looking for rough consensus; please put some
water with your wine for the sake of progress.
Is this a text you can consent with:
--Olaf
-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/
--Apple-Mail-62-292703674
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: This message is locally signed.
iD8DBQFEDp4UtN/ca3YJIocRAmRrAKCZKGVA67b4H7m5/uGHPN/sdgRA+ACfQ/UA
K5SYc+/oXyQL6R/JrGZMNMM=
=338O
-----END PGP SIGNATURE-----
--Apple-Mail-62-292703674--
Simon Josefsson
> 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.
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
Edward Lewis
haven't read everything under the sun pertaining to this issue.
(Sorry, I can't afford to become an expert on copyright law this
week.) So, for what it's worth, I will just react to this.
At 10:04 +0100 3/8/06, Olaf M. Kolkman wrote:
>Is this a text you can consent with:
Short answer is no.
>> 5.2 No Intellectual Property Encumbrance
>>
>> Because trust anchor rollover is considered "mandatory-to-implement",
>> section 8 of [RFC3979] requires that the technology solution chosen must
>> be unencumbered or must be available under royalty-free terms.
The first paragraph is okay.
>> For this purpose, "royalty-free" is defined as follows: world wide,
>> perpetual right to use, without fee, in commerce or otherwise, where "use"
>> includes descriptions of algorithms, distribution and/or use of hardware
>> implementations, distribution and/or use of software systems in source
>> and/or binary form, in all DNS or DNSSEC applications including registry,
>> registrar, domain name service including authority, recursion, caching,
>> forwarding, stub resolver, or similar.
The second paragraph I strongly (but arguing from weakness) object to.
I am sure that there is a more reliable definition of "royalty-free"
than what a bunch of DNS engineers can come up with on this mailing
list. As much as we don't like middle-boxes implementing subsets of
the DNS protocol (such as fire-walls that don't parse EDNS0
correctly), we shouldn't try to hack at legal and economic concepts
in the same manner.
E.g., http://en.wikipedia.org/wiki/Royalty_free. 'Course, that's in
the context of photographic images.
>> In summary, no implementor, distributor, or operator of the technology
>> chosen for trust anchor management shall be expected or required to pay
>> any fee to any IPR holder for the right to implement, distribute, or
>> operate a system which includes the chosen mandatory-to-implement
>> solution.
I would say that our goal is give interoperability every chance to
succeed by deriving a solution that anyone is free to implement
without having to succumb to the whims of any person or entity not
under the auspices of the IETF.
I'm being obstinate because this is a topic best handled by legal and
economic people, not network engineers. As engineers, we understand
interoperabilty, we aren't fluent in "right to implement..." kind of
concepts, or what "pay any fee" means to the limits of the law.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
Nothin' more exciting than going to the printer to watch the toner drain...
--
Ted Lemon
> So in order to try and reach convergence --- which is incredibly
> difficult --- Are there more takers for this position?
I'm perfectly happy with Paul's section instead of yours; I'm also perfectly
happy with yours.
I don't think either one is "unprofessional." The point is not to exclude
"Thierry's proposal." The point is to say what kind of IPR restrictions the
working group is willing to accept on any protocol specification for a piece
of technology that is be needed in some form or other in order for the whole
protocol suite to be useful to users of the Internet: the people whom we
ultimately serve when we do work for the IETF.
Thierry Moreau
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.
>
> Please remain courteous and civil. Please respect the motivations for
> peoples opinions.
>
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
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. ipr...@ietf.org).
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: thierry...@connotech.com
Paul Vixie
# rollover from being a "mandatory-to-implement".
that would be good news in and of itself, since we (isc) could start pushing
for wider deployment, even though it would require DLV and completely miss the
NSEC3 wave.
# I think that those speaking for the NOT mandatory-to-implement position were
# present in the Vancouver WG meeting but I have not seen any statements to
# that effect on the list.
#
# We may need to have statements either way on the 'mandatory-to-implement'
# requirement.
#
# Should this be Issue 2??
i think so, yes. if trust anchor management is not mandatory to implement,
then DNSSEC-bis is ready for wide scale deployment, and this whole debate, as
well as the NSEC3 technology wave, are way less relevant than we've all been
treating them.
Andrew Sullivan
> 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)
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
<and...@ca.afilias.info> M2P 2A8
+1 416 646 3304 x4110
Andrew Sullivan
> 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.
Andrew Sullivan
proposed text:
> 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 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 | a...@crankycanuck.ca
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
Suresh Krishnaswamy
> c: They would like to see any mention of IPR dropped from the
> requirements.
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
Suresh Krishnaswamy
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
>
> 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: thierry...@connotech.com
>
>
>
Robert Story
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. ]
--Sig_4UWp3Z6h3BPwV=+xqPiwJOi
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
On Tue, 7 Mar 2006 09:48:06 +0100 Olaf wrote:
OMK> I'd like to ask participants to state on-list
OMK>=20
OMK> a: That they consent with section 5.2 as above.
Yes.
--=20
Robert Story
SPARTA
--Sig_4UWp3Z6h3BPwV=+xqPiwJOi
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)
iD8DBQFEDaOR7/fVLLY1mngRArSDAKCNDn8o7lpUn8zNKnXI5epdcPco3wCdG375
5b0gWtBpBAv6xP8Opi2Hw0Q=
=jU8i
-----END PGP SIGNATURE-----
--Sig_4UWp3Z6h3BPwV=+xqPiwJOi--
Russ Mundy
-------------- snip --------------
>
>>> 5.2 No Intellectual Property Encumbrance
>>>
>>> Because trust anchor rollover is considered "mandatory-to-implement",
>>> section 8 of [RFC3979] requires that the technology solution chosen mu=
st
>>> be unencumbered or must be available under royalty-free terms.
>
>The first paragraph is okay.
>
--------- snip ------------------
Editor hat ON
My impression was that the requirement in section 5.6 _removed_ automated k=
ey
rollover from being a "mandatory-to-implement". =20
I think that those speaking for the NOT mandatory-to-implement position wer=
e
present in the Vancouver WG meeting but I have not seen any statements to t=
hat
effect on the list.
We may need to have statements either way on the 'mandatory-to-implement'
requirement.
Should this be Issue 2??
Russ
Wes Hardaker
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.
--
Wes Hardaker
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.
Mike StJohns
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:
>
>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. ipr...@ietf.org).
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.
Thierry Moreau
Mike StJohns wrote:
> 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.
>
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
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: thierry...@connotech.com
Christian Huitema
> Mike StJohns wrote:
>=20
> > 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.
> >
> 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.
It is also the inventors' duty to signal to the patent office any prior
art that they know about.
-- Christian Huitema
Olaf M. Kolkman
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
On Mar 8, 2006, at 6:50 PM, Russ Mundy wrote:
(...)
>
> My impression was that the requirement in section 5.6 _removed_
> automated key
> rollover from being a "mandatory-to-implement".
>
Note that I wrote:
> Paul's premisses is that we had consented on the "mandatory-to-
> implement" part of the key-rollover. The exact RFC2119 form (MUST,
> SHOULD or MAY NOT implement) of that requirement is open to
> discussion but I think we do consent to the spirit of the
> "mandatory-to-implement" part; "mandatory-to-implement" should be
> in between quotes indeed.
The spirit of the "mandatory-to-implement" is that automatic
keyrollover is a key component of successful deployment of DNSSECbis.
There is broad, better than rough, consensus in this WG that
automatic key rollover is a missing and necessary addition to DNSSECbis.
That means that if we develop such protocol it must be widely
available and for operational successful deployment operators of
validating devices will have to deploy this (otherwise their life
becomes a mess).
I read 5.6 to say that if we have developed a mechanism than people
should be able to either ignore the technology or use manual means to
perform the rollover. As a metaphor: I can have a robot swap the keys
or do it myself.
We can no start to quibble if "mandatory to implement" has to be
defined in the same manner as "royalty free" is defined for this
particular text. I prefer we rather not do this.
--Olaf
-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/
--Apple-Mail-83-378699574
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: This message is locally signed.
iD8DBQFED+4FtN/ca3YJIocRAoFVAJ9P221oQ7/YSFWEQXtvchjcTaZulACg/WD1
R7EUEbL8kKl+kxzMu8U8K3w=
=vbjg
-----END PGP SIGNATURE-----
--Apple-Mail-83-378699574--
Paul Vixie
therefore i will re-enter the discussion.
# I read 5.6 to say that if we have developed a mechanism than people should
# be able to either ignore the technology or use manual means to perform the
# rollover. As a metaphor: I can have a robot swap the keys or do it myself.
#
# We can no[w] start to quibble if "mandatory to implement" has to be defined
# in the same manner as "royalty free" is defined for this particular text. I
# prefer we rather not do this.
i don't think "mandatory-to-implement" requires further definition, but i do
think that 5.6 is ambiguous on this point if you can interpret as you
describe. in particular, if an implementation can fail to include the
automation nec'y for this feature, but make it possible for human hands to
manually insert new keys, then the automation is optional, and therefore not
mandatory to implement. this also opens the possibility of an "early adopter"
class of implementations who, lacking this automation, rely on human hands to
roll keys, where we know from the history of root hints that this won't occur.
if what we want to say is that IETF standard automation is required, but it
can either follow the specification whose requirements we are now defining or
some later specification, then that would make this first specification
mandatory-to-implement (since it will be, for a time at least, the only IETF
standard automation), but in the future if there are ever multiple IETF
standards for automation in this area, no single one will be mandatory to
implement. i consider that a rather muddy puddle.
in my view the right thing to do is either declare DNSSEC-bis "done", which
means automated key rollover isn't mandatory, and wide scale implementation
ought to occur immediately; or we ought to declare DNSSEC-bis "undeployable
in its current form" and then itemize the missing features (likely this means
automated key rollover and NSEC3) and get back to work on those. i do not
care which path is chosen, but i do believe that the choice has to be one or
the other.
Olaf M. Kolkman
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Paul,
<hats off>
I think DNSSEC bis is not ready without a mechanism that allows for
automatic key rollover. For the client device there is an operational
need to configure keys once, turn the device on and let the device
automagically reconfigure its trust anchors. I do not think there is
a dispute about this.
We would like to have one single protocol that our clients need to
understand for that purpose. Such protocol will set operational
requirements on the DNS service provider; there will have to be bits
set, RRsets published, RRsets pulled and specific signatures
generated. Those operational procedures, the rollover mechanism as I
will call it, will be mandatory to implement at the server side by
anybody who is in the business of operating a zone that is intended
to be a "public" entry point in the chain of trust. The exact set of
zones which are in that business is not known to me but the root is
definitely a member. So the "rollover mechanism" will be mandatory
for the root.
If there is no single rollover protocol there might be multiple
rollover mechanisms required at the root. That would be bad. So we do
need one protocol with one set of "rollover mechanism" instructions
for the zone owners.
The client must be able to implement the protocol in software (the
protocol must be implementable); but may choose not to do so. Still
for a successful rollover the operator of such client should follow
the steps described in the protocol or reconfigure the trust-anchors
from scratch.
Essentially we should have one set of rules to play this game which
can be fully automated.
Another way of phrasing is:
This would be the "mandatory to implement" mechanism for everybody
who would want to perform automatic rollover of DNSKEYs. Section 5.6
just says that you may choose not to perform automatic rollovers.
If you take a car you MUST wear seatbelts, you MAY still choose to
walk, it just won't get you very far.
--Olaf
-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/
--Apple-Mail-129-745132593
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: This message is locally signed.
iD8DBQFEFYVmtN/ca3YJIocRAuS5AKDSTjyNi8ZHF68SkIimrYCXJ71BhQCeKo3g
RlNLE189nvtrBVzmspDVzsA=
=hSOh
-----END PGP SIGNATURE-----
--Apple-Mail-129-745132593--
Paul Vixie
#
# This would be the "mandatory to implement" mechanism for everybody who would
# want to perform automatic rollover of DNSKEYs. Section 5.6 just says that
# you may choose not to perform automatic rollovers.
so it's mandatory-to-implement for the root zone and for any other zone ``that
is intended to be a "public" entry point in the chain of trust,'' but it isn't
mandatory-to-implement for requestors, who must be considered to comply with
the DNSSEC protocol even if they don't automate this particular functional.
let me register my disagreement with this position by quoting my own words:
this ... opens the possibility of an "early adopter" class of
implementations who, lacking this automation, rely on human hands to
roll keys, where we know from the history of root hints that this
won't occur.
another way of phrasing it is, if automation of this function is optional,
then i predict market failure of virtually every implementation which lacks
it, and if these implementations have critical mass, then i predict market
failure of the DNSSEC protocol itself.
however, i must also note that for the purposes of RFC 3979, the fact that
some zone operators (including the root zone) must implement this means it
is "mandatory-to-implement". so for the purpose of answering issue 1, your
vision of one-sided mandatoryness (while dangerous) supports my proposed
text for 5.2 in the "ISSUE 1" thread.