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

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

[email-masked] wrote:
> 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
> 	

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: 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: 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: Paul Vixie <[email-masked]>
Date: Mon, 27 Feb 2006 15:00:35 +0000

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

---

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

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