Subject: I-D ACTION:draft-ietf-dnsext-rollover-requirements-00.txt

From: [email-masked]
Date: Tue, 21 Feb 2006 15:50:02 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.

	Title		: Requirements related to DNSSEC Trust Anchor Rollover

	Author(s)	: S. Crocker, et al.
	Filename	: draft-ietf-dnsext-rollover-requirements-00.txt
	Pages		: 
	Date		: 2006-2-21
	
   Every DNS security-aware resolver must have at least one Trust
   Anchor to use as the basis for validating responses from DNS signed
   zones. For various reasons, most DNS security-aware resolvers are
   expected to have several Trust Anchors. For some operations, manual
   monitoring and updating of Trust Anchors may be feasible but many
   operations will require automated methods for updating Trust Anchors
   in their security-aware resolvers. This document identifies the
   requirements that must be met by an automated DNS Trust Anchor
   rollover solution for security-aware DNS resolvers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rollover-requirements-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dnsext-rollover-requirements-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-dnsext-rollover-requirements-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Thierry Moreau <[email-masked]>
Date: Wed, 22 Feb 2006 07:43:00 -0500

> 	Filename	: draft-ietf-dnsext-rollover-requirements-00.txt

This document essentially says that manual methods of trust anchor key 
management *are* adequate.

In my opinion, the remaining contents can only trigger unproductive 
discussions. I whish I'm wrong on this!

Regards,

-- 

- Thierry Moreau

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

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

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

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

---

From: Russ Mundy <[email-masked]>
Date: Wed, 22 Feb 2006 18:57:36 -0500

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

>management *are* adequate.

The Working Group has said that manual methods are acceptable - the real world
decision as to whether or not manual methods are used belongs to those
responsible for operation of each security-aware resolver.

>discussions. I whish I'm wrong on this!

I too hope that the I-D does not trigger unproductive discussions - that is
certainly not intent of the document.  The intent is to provide a clear set of
requirement statements that have been identified on the mail list, in dnsext
WG meetings and in email that was sent to the designated editor team (as
directed by the co-chairs).  Hopefully, we will have useful, positive
discussions that result in a set of requirements that have Working Group
consensus.

>Regards,

Russ Mundy

---

From: "Scott Rose" <[email-masked]>
Date: Thu, 23 Feb 2006 08:01:08 -0500

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Thierry Moreau
> >

I believe that manual methods may be adequate for some zones - it is
certainly not adequate for the majority, but depending on security goals, it
may be an acceptable design choice.

> discussions. I whish I'm wrong on this!

I read both requirements drafts, and I think it may be a good idea to merge
some of the ideas in both documents into a unified draft of technical
requirements.

Scott

---

From: Ben Laurie <[email-masked]>
Date: Thu, 23 Feb 2006 19:16:42 +0000

> 	Title		: Requirements related to DNSSEC Trust Anchor Rollover

Comments:

Emergency Trust Anchor Rollover:

  "Any security-aware resolver
   using those RR(s) as Trust Anchor(s) must quickly remove them from
   use by the resolver."

Surely not - what must happen is they must start using the new keys
and stop using the old ones.

Normal or Scheduled Trust Anchor Rollover:

  "Operators of security-aware resolvers using RR(s) from that zone as
   Trust Anchors need to acquire new and remove revoked Trust Anchors
   at roughly the same time as the signed zone issues or revokes
   RR(s)."

Actually the requirement is that they don't use revoked ones after
they are revoked and do use new ones. Why is this different? Because
it allows resolvers that are offline for an extended period to comply.

5.3 - is "SHALL" (as opposed to "shall") a word?

5.9 - "Information about the issuer's view of that state of Resource
   Records used as Trust Anchors" - should "that" be "the"?

also, a metacomment - some of the requirements seem to have ended up
hidden in the definitions (such as those I comment on above).

Cheers,

Ben.

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

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

---

From: Geoffrey Sisson <[email-masked]>
Date: Thu, 23 Feb 2006 19:36:09 +0000

> 5.3 - is "SHALL" (as opposed to "shall") a word?

Equivalent to "MUST" (RFC 2119).

Geoff

---

From: Russ Mundy <[email-masked]>
Date: Fri, 24 Feb 2006 16:46:26 -0500

>some of the ideas in both documents into a unified draft of technical

This I-D was finished except for final formatting when Thierry announced his
I-D.  I reviewed that I-D prior to submitting this one and do think that there
might be some things that the Working Group might want to incorporate into
this one but (as the final 'clean-up' editor) I did not incorporate any items
into this draft for several reasons - it would have further delayed getting
this draft out, items from that draft can be incorporated into subsequent
versions of this draft, the requirements in Thierry's draft seemed to be
addressing what would be needed for a full-blown pki which I think is more
than the WG wants for rollover, and there seemed to be some different usage of
terms from what is defined in rfc-4033.

At the risk of repeating, I think that it's certainly possible that there are
some things from Thierry's draft that should be incorporated into this one -
Working Group participants really need to speak up (or would that be 'mail up'
:*) their views to namedroppers.

Russ

---

From: Thierry Moreau <[email-masked]>
Date: Sat, 25 Feb 2006 12:02:22 -0500

Russ Mundy wrote:

"[...] the requirements in Thierry's draft seemed to be addressing what
would be needed for a full-blown pki which I think is more than the WG
wants for rollover [...]"

This assessment of draft-moreau-dnsext-tak-req-00.txt is unsupported,
expeditious, imprecise, and misleading. You may infer that I disagree.

The document draft-moreau-dnsext-tak-req-00.txt is an independent I-D
submission addressing the automated trust anchor key rollover
requirements for DNSSEC. The dnsext wg is chartered to work on this
automated rollover.

Regards,

-- 

- Thierry Moreau

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

---

From: Mike StJohns <[email-masked]>
Date: Sat, 25 Feb 2006 15:33:26 -0500

Hi Russ -

I'm going to have to object to the 12 month period in 5.5 as a 
requirement.  It's a nice to have, but we should consider any box 
that's been sitting on the shelf for 12 months as the equivalent of a 
freshly manufactured box for purposes of ANY configuration.

If this requirement stands, it eliminates any possibility of doing 
this in-band with the DNS protocol and will require an external 
key-management system that can handle being disconnected for 12 
months.  (And I'm not sure I know of any one).    [OK - I know I have 
to explain this.  Basically, DNS is two different protocols - a 
two-way transport protocol and a one-way data protocol.  It's 
possible to query a server if you get problematic - protocol-wise - 
answers during a query, but it's currently not possible to do 
something like ask an authoritative server for all the changes that 
were made over the last twelve months - e.g. what the database folks 
call "journaling".  To accomplish a recovery from 12 month down time 
you're going to need to be able to chain all the changes at the 
appropriate times and even, if your original trust anchor is 
compromised, I'm not sure you can trust your answer.  This would 
suggest using a set of signatures completely outside of DNSSEC - 
maybe even something based on 509 certs and messages]

Mike

---

From: Paul Vixie <[email-masked]>
Date: Sat, 25 Feb 2006 21:38:07 +0000

# "[...] the requirements in Thierry's draft seemed to be addressing what
# would be needed for a full-blown pki which I think is more than the WG
# wants for rollover [...]"
# 
# This assessment of draft-moreau-dnsext-tak-req-00.txt is unsupported,
# expeditious, imprecise, and misleading. You may infer that I disagree.

since your work on this is patented, most of us have not reviewed it.

# The document draft-moreau-dnsext-tak-req-00.txt is an independent I-D
# submission addressing the automated trust anchor key rollover
# requirements for DNSSEC. The dnsext wg is chartered to work on this
# automated rollover.

and what is the IPR status of your requirements document?

---

From: Ben Laurie <[email-masked]>
Date: Sun, 26 Feb 2006 14:42:19 +0000

Russ Mundy wrote:
> see in-line:
> 
> On 2/23/06 at 7:16 PM -0000, Ben Laurie <[email-masked]> wrote: 
> The current wording may need improved but I think that your suggested change
> infers that there _will_ (or MUST) be new keys available at the time that the

implies, surely. But in any case if there aren't new keys it isn't rollover.

> 'old' keys should no longer be used, e.g., 'old' keys have been compromised.
> While I agree that having new keys in place when old keys are removed is the
> most desireable state but I believe that there is a real possibility that a
> zone may not have new keys available so that the zone can no longer be
> operated as signed.  In that case, the security-aware resolver should stop
> using the old key as a TA and treat everything under that hierarchy as _not_
> signed.  In other words, the TA should no longer be used even though a new key
> is not available.  Do you have some wording suggestions?

I really would prefer that the definition of rollover and the
requirements were separated.

Here's what I'd suggest:

Emergency Trust Anchor Rollover

   The operator of a signed zone has issued new DNSKEY RR(s) and/or DS
   RR(s) as part of an exceptional event.

Emergency Trust Anchor Revocation

   The operator of a signed zone wishes to indicate that the current
   DNSKEY and/or DS RR(s) are no longer valid as part of an exceptional
   event.

with the requirements moved down to the requirements section.

> I agree that this definition doesn't mesh particularly well with 5.5 but I
> don't think that they conflict either in that when a system is 'returning from
> offline' there should be an effective, secure method for it the resolver to
> use only valid TAs.  Do you have some suggested words here?

Again, split the definition from the requirement, and make the requirement:

Operators of security-aware resolvers using RR(s) from that zone as
Trust Anchors need to acquire new and remove revoked Trust Anchors such
that no old key is used for long after revocation."

Cheers,

Ben.

---

From: Russ Mundy <[email-masked]>
Date: Fri, 24 Feb 2006 17:23:08 -0500

see in-line:

>5.3 - is "SHALL" (as opposed to "shall") a word?

What Geoff said "Equivalent to "MUST" (RFC 2119)."

>   Records used as Trust Anchors" - should "that" be "the"?

Right, got it, thanks.

>hidden in the definitions (such as those I comment on above).

Well there was some discussion among the editor team about things that should
be definitions and things that should be requirements.  For the most part, the
requirements section are things the editor team received as directed in the
last WG meeting (mail list, direct mail & WG meetings).  The definitions were
written to explain terms that were included in the requirements that did not
have definitions (or not enough of a definition) in rfc4033.  

It is certainly possible that some WG members believe (like Ben) that some (or
lots of) things from the definitions section should be revised & moved to the
requirements section.  If you believe this to be the case, please speak up &
provide suggested wording for the 'new' requirement.

>Ben.

Thanks a lot for your review & input,

Russ

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 27 Feb 2006 11:40:03 +0100

> requirements for DNSSEC. The dnsext wg is chartered to work on this

And we do so by keeping focus on the working group requirements  
document.

If anybody would like to see requirements changed or added then, as  
always, the suggestion is to write a "patch" to the WG requirements  
document (wording as it should appear in the document) and argue why  
you would like to have it there.

Some participants are already following that strategy.

If there is consensus for your position the modification goes in.

--Olaf

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

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 27 Feb 2006 12:19:03 +0100

Section 5.2 says:

   The solution SHOULD not have any intellectual property encumbrance
   on either the technologies used by the solution nor implementations
   of the solution. The technology used by the solution SHOULD permit
   implementers to provide complete, running implementations that have
   Berkley open source type of licensing.

I suggest modifying it to:

   The solution SHOULD not have any intellectual property encumbrance
   on either the technologies used by the solution nor implementations
   of the solution. The technology used by the solution SHOULD permit
   implementers to provide complete, running implementations that have
   Berkley open source type or GNU Generic Public License free
   software type of licensing.

The reasons is that we expect that implementations of this solution to
be released under the GPL (e.g., in glibc), and that the GPL places
certain additional restrictions on solutions, that the Berkeley
license do not places, which I feel are important to capture here.

In general, this section may be poorly phrased.  I see no problem in
picking a solution that is patented if there is a license that grant
everyone sufficient rights to use the solution without any additional
problems.  What do you think?

Thanks,
Simon

---

From: Alex Bligh <[email-masked]>
Date: Mon, 27 Feb 2006 11:35:56 +0000

> license do not places, which I feel are important to capture here.

I don't think your propose change makes sense. What the original para
seeks to do is ensure that the IPR can be released under a BSD-style
license. The very fact that it can be released under such a license
means that it can also be released under a GPL-style license (as BSD-style
licenses allow relicensing).

Your proposal suggests that we merely ensure that it can be released
under BSD *OR* GPL. This would permit IPR that was /only/ released under
GPL, which would prevent a BSD release (as GPL does not permit relicensing
under BSD).

Your point that the wording is significantly broken is, however, taken.
BSD and GPL are both /copyright/ licenses, neither of which make any
mention of patents, and neither have any patent grant or patent defence
clauses. It's thus perfectly possible to release an implementation of
a patent-encumbered algorithm under (say) the GPL, and retain a cause
of action against those using it.

On that basis I would suggest simply deleting the second sentence
(which adds nothing except confusion to the first sentence).

But in any case, isn't there an IETF standard which specifies what sort of
IPR encumbrances are and are not acceptable, in which case can't we just
use that, rather than attempting to repeat that debate in microcosm? If so,
the whole paragraph can be replaced with a reference to that, and we
can stop trying to be lawyers :-) ...

Alex

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 27 Feb 2006 12:45:17 +0100

> GPL, which would prevent a BSD release (as GPL does not permit relicensing

No, that was not my point.  I strongly believe the solution should be
possible to implement with any popular free license.  Including both
the BSD and the GPL.  If you have a better way to capture that, I'm
all for it.

> of action against those using it.

At the risk of starting an unproductive discussion, that is incorrect,
the GPLv3 draft do talk about patents.

> (which adds nothing except confusion to the first sentence).

I disagree.  Making it possible to implement this solution with either
BSD or GPL license seem required for wider adoption.

> can stop trying to be lawyers :-) ...

See RFC 3979.

Thanks,
Simon

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 27 Feb 2006 07:04:49 -0500

> use that, rather than attempting to repeat that debate in microcosm? If so,

RFC3979 is pretty clear that the IETF won't take a stand on
"acceptable or not".  But sectoin 6.5 offers three options under
which IPR claims are not incompatible with publication as RFC:

   a) under a royalty-free and otherwise reasonable and non-
   discriminatory license 

   b) under a license that contains reasonable and non-discriminatory
   terms and conditions, including a reasonable royalty or other payment

   c) without the need to obtain a license from the IPR holder

As nearly as I can tell, the point of the reference to the BSD in
this draft is to eliminate (b) from the running, and to clarify what
"reasonable and non-discriminatory" in (a) means.  My suspicion,
however, is that (c) is what we'd really like.  So perhaps something
along the following lines will get us there:

    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 standard licensing
    models of existing resolver libraries.

Does that help?

A

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

---

From: Alex Bligh <[email-masked]>
Date: Mon, 27 Feb 2006 15:00:49 +0000

>     models of existing resolver libraries.

That would indeed address my point.

Alex

---

From: Alex Bligh <[email-masked]>
Date: Mon, 27 Feb 2006 15:06:52 +0000

Simon,

>> means that it can also be released under a GPL-style license (as
>> BSD-style licenses allow relicensing).
>>
>> GPL, which would prevent a BSD release (as GPL does not permit
>> relicensing under BSD).
>

I agree with what you are seeking to do. However, your wording had
could be read to have the opposite effect...

> The technology used by the solution SHOULD permit

... because of the word "or" before GNU. A technology that ONLY allowed GPL
would thus satisfy the "SHOULD" condition, if you read the "or" to mean
"the solution shall either provide X or Y". My point was that you can
delete the GPL bit because ANYTHING that's licensed under a BSD license can
ANYWAY be relicensed under the GPL. So if it is a necessary condition that
a BSD version of the library can be released, then that alone is sufficient
to ensure a GPL version can also be released (at least in terms of
copyright grant).

> the GPLv3 draft do talk about patents.

That's WIP. GPLv2 is what's here today.

> BSD or GPL license seem required for wider adoption.

I agree completely, just that that's not what your proposed amendment
does (at least the way I read it). If you wrote "or (at the
implementers choice)" then it would not be ambiguous. But...

>> But in any case, isn't there an IETF standard which specifies what sort
>> of IPR encumbrances are and are not acceptable, in which case can't we
>> just use that, rather than attempting to repeat that debate in
>> microcosm? If so, the whole paragraph can be replaced with a reference
>> to that, and we can stop trying to be lawyers :-) ...
>
> See RFC 3979.

I think this is preferable (if we refer to (a) or (c)).

Alex

---

From: Paul Vixie <[email-masked]>
Date: Mon, 27 Feb 2006 15:08:19 +0000

# >     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 standard licensing
# >     models of existing resolver libraries.
# 
# That would indeed address my point.

if someone points at GLIBC2 and says "it's compatible with that", no.
if someone points at BIND and says "it's compatible with that", yes.

therefore i think we need stronger, more explicit wording.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 27 Feb 2006 16:20:50 +0100

> I think this is preferable (if we refer to (a) or (c)).

I agree that this is preferable.  I do believe it should be (a) _and_
(c), though.  For reference, here they are:

   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.

I don't think b) would be compatible with how several DNS resolvers
are distributed today (and thus likely to be distributed tomorrow).

a) without c) may cause delays when someone wishes to fork a free
implementation, requiring the new distributor to obtain a license.

If there are no strong argument that c) has to be permitted, I believe
a) AND c) would be the most useful requirement on a solution.

Thanks,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 27 Feb 2006 16:28:37 +0100

Paul Vixie <[email-masked]> writes:

> # No, that was not my point.  I strongly believe the solution should be
> # possible to implement with any popular free license.  Including both
> # the BSD and the GPL.  If you have a better way to capture that, I'm
> # all for it.
>
> BSD code can be forked and rerelased under GPL, but not vice versa.  So
> if you specify "BSD or GPL" you're allowing for a non-BSD-compatible
> license (which TAKREM, for example, has).  If you specify "BSD" then you
> are effectively allowing "BSD or GPL" implementations.

I disagree.  GPLv3 discusses patents.  It will be possible to create
an implementation licensed under the BSD license that is not possible
to re-license to GPLv3 because of a patent.

I do not think this WG will have a solution to the anchor problem
before GPLv3 has been released.  Since GLIBC will be available under
GPLv3, and may end up containing an implementation of this proposal
[1], I believe it is useful to make sure it is possible to implement
the solution and release the code under the GPLv3 license.

Thanks.

[1] Although it will likely be an external add-on in the beginning,
similar to how my IDN work was distributed as an add-on to GLIBC in
the beginning, but later merged into glibc proper.

---

From: Alex Bligh <[email-masked]>
Date: Mon, 27 Feb 2006 15:30:50 +0000

> a) AND c) would be the most useful requirement on a solution.

At risk of spending the whole day arguing about AND vs OR, how
can something both be "without the need to obtain a license"
AND be "under a royalty-free or otherwise non-discrimatory license". The
stronger statement (if we are concerned about minimizing licensing
conditions to implementors) would be to require (c). I can't see
how requiring "(a) AND (c)" is meaningful.

I think it either has to be "(a) or (c)", or "(c)". Only the latter
will guarantee it can be released under a BSD license, which is your
aim. (a) (which is a possibility in "(a) or (c)" would allow the
requirement of a payment of (say) 1 cent per deployed library, which
is obviously not compatible with BSD/GPL.

Therefore I think we should be going for "(c)".

Alex

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 27 Feb 2006 10:36:28 -0500

> if someone points at BIND and says "it's compatible with that", yes.

That was why I said "models" and not "a model".  But the idea is, "It
had better be compatible with all the well-known licenses for this
sort of stuff."  What about ". . .compatible with standard licensing
models of existing resolver libraries, including Berkeley- and GNU-
style software licenses."  (My own preference, FWIW, is to add
that technologies that are available under case (c) SHOULD be
preferred over other technologies, assuming each meets the other
technical requirements.  AFAIK this is in keeping with the current
BCPs, but I neither am a lawyer nor had a hand in drafting the
current BCPs.)

A

---

From: Alex Bligh <[email-masked]>
Date: Mon, 27 Feb 2006 16:13:38 +0000

> to re-license to GPLv3 because of a patent.

Even if GPLv3 contains a grant, it is STILL possible for a third party
to relicense a BSD license under GPLv3. However, the end licensee will
not benefit from the grant in GPLv3, as the original IPR holder won't
have granted it.

The same problem occurs in a much simpler scenario, which is that
the license holder grants a BSD license (which has no patent grant).

Even if you disambiguate your wording, the "letter of the law" would
still be met by an IPR holder who agrees to grant a BSD license to
the IPR (which would be ineffective to help enbd users as it didn't
contain a patent grant), and a GPLv3 license (which would be effective
to end users, but they'd be stuck with a GPLv3 license). That doesn't
do what you want, because people can't *USE* it under the BSD license
(because they don't have a patent grant).

> the solution and release the code under the GPLv3 license.

I think trying to reinvent license-discuss here is folly. We should not
talk about specific licenses. We should talk about unincumbered IPR.
IE we should define the effect we want, not cause. If we really want
to talk about software licenses, how about:

   The technology used by the solution SHOULD permit
   implementers to provide complete, running implementations under
   any OSI-approved license that the implementor chooses, without either
   the implementer or the end user requiring any additional
   license grant (patent, copyright, or other) to make use of the
   resultant code.

If you like you can add "(including BSD and GPL)" after "OSI-approved
license" but I think it's otiose.

Can I also pick another hole in this bit:

   of the solution.

I think it's quite reasonable for a subset of implementations to
be subject to IPR "encumbrances", provided you can produce another that
isn't. For instance, if someone produces an unpatented method, and
provides a closed-source implementation, this should not count against
the protocol (the more interoperability the better) PROVIDED that
it doesn't make it any harder for anyone else to provide unencumbered
implementations. We also have an "either/nor" issue.
I think we should have something like.

   The solution SHOULD not have any intellectual property encumbrance
   affecting either the technologies used by the solution, or which
   necessarily affect any implementatoin of the solution.

Just to be clear, I fully agree with what you are trying to do here,
which is to specify that whatever solution is picked should not create
problems for those trying to incorporate the library in to GPL or BSD
code, I'm just arguing about the wording; in fact I'd probably go
further and make the "SHOULD" a "MUST" given we are talking about every
resolver that's out there.

Alex

---

From: Paul Vixie <[email-masked]>
Date: Mon, 27 Feb 2006 15:00:35 +0000

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 27 Feb 2006 18:14:40 +0100

> not benefit from the grant in GPLv3, as the original IPR holder won't

See section 11 of GPLv3.  There is an automatic implied patent license
right in it, see:

http://gplv3.fsf.org/draft
http://gplv3.fsf.org/rationale#SECTION003110000000000000000

So it seems it may not be possible to re-license BSD code under the
GPLv3, if there is an applicable patent that the IPR holder is not
willing to grant a license to.

> IE we should define the effect we want, not cause.

I completely agree here.  My issue was prompted up by the current
draft discussing licenses.

> resolver that's out there.

I don't think RFC 2119 language is applicable at all here.  This is
intended to be a guiding document.

Thanks,
Simon

---

From: Paul Vixie <[email-masked]>
Date: Mon, 27 Feb 2006 22:42:05 +0000

# I agree that this is preferable.  I do believe it should be (a) _and_
# (c), though.  For reference, here they are:
# 
#    a) under a royalty-free and otherwise reasonable and non-
#    discriminatory license, or
# ...
#    c) without the need to obtain a license from the IPR holder.
# 

agreed.