Subject: Re: Last Call: 'DNSSEC Lookaside Validation (DLV)' to Informational RFC (draft-weiler-dnssec-dlv)

From: Bernard Aboba <[email-masked]>
Date: Fri, 27 Oct 2006 09:48:50 -0700 (PDT)

Joe Abley said:

"Apologies to all concerned if I'm rudely pointing out the elephant in the 
living room.  This is one of two separate specifications for DLV. The 
document at

  http://www.isc.org/pubs/tn/isc-tn-2006-1.txt

describes an approach called "DNSSEC Lookaside Validation (DLV)" which 
uses the same DLV resource record specified in RFC 4431. This 
specification is implemented in BIND 9, as far as I know.

I haven't compared draft-weiler-dnssec-dlv-01 with the ISC tech note 
closely, but since the text is different it seems likely that 
implementations based on one would likely differ from those based on the 
other, from different interpretations of the text if not from fundamental 
differences in approach."

Thanks for pointing this out.  As a matter of practical reality, a DNSSEC 
implementer will probably opt for compatibility with BIND 9 without 
compelling reasons to do otherwise.  Therefore, I'd suggest that one of 
the following actions needs to occur before publication of draft-weiler 
would be advisable:

a. Review by the BIND 9 maintainers to determine whether existing 
implementations are compatible with draft-weiler.  

b. If incompatibilities are found, then agreement by the BIND 9 
maintainers that they will make the changes necessary to upgrade to 
draft-weiler. 

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Geoff Huston <[email-masked]>
Date: Mon, 30 Oct 2006 05:27:55 +1100

>maintainers that they will make the changes necessary to upgrade to

or, more radically:

a.  Review by the draft-weiler author(s) to determine whether existing
implementations are compatible with draft-weiler.

b. If incompatibilities are found, then the author of draft-weiler
to make the changes necessary in the draft to match the running code.

(or have we all entered a state of blissful collective amnesia about 
that annoying
thing called "running code"?)

  Geoff

---

From: John C Klensin <[email-masked]>
Date: Sun, 29 Oct 2006 15:43:17 -0500

--On Monday, 30 October, 2006 05:27 +1100 Geoff Huston
<[email-masked]> wrote:

>...
>> I haven't compared draft-weiler-dnssec-dlv-01 with the ISC
>> tech note closely, but since the text is different it seems
>> likely that implementations based on one would likely differ
>> from those based on the other, from different interpretations
>> of the text if not from fundamental differences in approach."
>> 
>> Thanks for pointing this out.  As a matter of practical
>> reality, a DNSSEC implementer will probably opt for
>> compatibility with BIND 9 without compelling reasons to do
>> otherwise.  Therefore, I'd suggest that one of the following
>> actions needs to occur before publication of draft-weiler
>> would be advisable:
>> 
>> a. Review by the BIND 9 maintainers to determine whether
>> existing implementations are compatible with draft-weiler.
>> 
>> b. If incompatibilities are found, then agreement by the BIND
>> 9 maintainers that they will make the changes necessary to
>> upgrade to draft-weiler.
> 
> or, more radically:
> 
> (or have we all entered a state of blissful collective amnesia
> about that annoying thing called "running code"?)

Sigh.  At the risk of excessive optimism, might we assume that
the author of draft-weiler, the authors and parties responsible
for the relevant implementations, and the relevant ADs are all
adults or at least capable of simulating them for a short time?
If so, we might encourage them to review the work and
implementations (as both Geoff and Bernard have suggested) and
then sit down, with appropriate lubrication, identify
differences and the reasons for them, figure out what needs to
be adjusted, and do so.

I hope that, by this time, it should be clear to the IESG and
the other parties involved that this document should not move
forward until any differences with existing important
implementations are noted and either resolved or carefully
described and explained in the text.   I would hope that we
don't need to specify exactly how to tune things further.

   john