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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 30 Oct 2006 08:38:09 -0800

I disagree.

The ISC document makes it very clear that it is an implementation description, not a normative specification and that it is copyright ISC and not the IETF. Any casual resemblence the document might have to an RFC or draft is illusory. 

If someone was stating 'I have read the drafts and I have identified the following issue that will lead to incompatibility' the issue might be worth IESG time. 

When the statement is "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" it should go straight to the bit bucket. People complain about 'I haven't read the draft but...' comments in IETF meetings. At least there there is the excuse that there is a limited time to raise an issue that might just have occurred to you. On a mailing list there is really no excuse for not taking the time to do the comparison.

The acknowledgements sections both cite the authors of the other document. I see no reason to assume that the groups have not been in communication. They state that this is the case.

Since an individual submission is not a standard it would appear to be allowable for the documents to be inconsistent even if they were both submitted for publication as an RFC.

Too many people are relying on the IESG to do too much. The Internet is rather more robust than people imagine. 

If someone wants to stop a draft they MUST be required to provide an objective, testable explanation of the objection. 

Networking specs describing changes to a twenty year old infrastructure designed as experimaental are always going to be complex and there will always be the possibility of unanswered questions.

There might be a problem here, but it is rather more important for the IESG to protect their time by insisting that objectors put at least as much time into consider the issue as they are expected to. 

> -----Original Message-----
> From: John C Klensin [mailto:[email-masked]] 
> Sent: Sunday, October 29, 2006 3:43 PM
> To: Geoff Huston; Bernard Aboba; [email-masked]
> Subject: Re: Last Call: 'DNSSEC Lookaside Validation (DLV)' 
> to Informational RFC (draft-weiler-dnssec-dlv)
> 
> 
> 
> --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:
> > 
> > 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"?)
> 
> 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
> 
> 
> 
> 
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 

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

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 30 Oct 2006 18:26:13 +0100

On 30Oct 2006, at 5:38 PM, Hallam-Baker, Phillip wrote:

> If someone was stating 'I have read the drafts and I have  
> identified the following issue that will lead to incompatibility'  
> the issue might be worth IESG time.
>
> When the statement is "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" it should go straight to the bit bucket.  
> People complain about 'I haven't read the draft but...' comments in  
> IETF meetings. At least there there is the excuse that there is a  
> limited time to raise an issue that might just have occurred to  
> you. On a mailing list there is really no excuse for not taking the  
> time to do the comparison.
>

Phillip,

I think there is an excuse for not taking the time to do the  
comparison. To be able to understand the interoperability problems  
you either have to read the code (*) or set up a test-lab. Both are  
non-trivial time consuming exercises and even though this work is  
part of my day job, preemptive scheduling because of an IETF last  
call, just does not work.

I read the document and flagged the issue of possible  
interoperability problems, so did others (if only to make sure that  
the IESG is aware of these potential problems). This should be a  
queue for the document editor to step in and explain if there are  
issues and, if so, which. That could be a very trivial explanation.

And even if the technical specs are OK, there is still the issue of  
the IANA considerations.

--Olaf

(*) You wrote:
> Since an individual submission is not a standard it would appear to  
> be allowable for the documents to be inconsistent even if they were  
> both submitted for publication as an RFC.

Personally I am not so much worried about the difference in  
documents, I am worried about the difference between draft-weiler and  
the implementation (_the_ implementation as I am not aware  
implementations other than in BIND) hence I wrote 'code' above.

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

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 30 Oct 2006 18:36:02 +0100

I wrote:
>  This should be a queue for the document editor to step in and  
> explain if there are issues and, if so, which.

or maybe better phased:
This should be a queue for the document editor (or anybody else) to  
step in and explain if there are issues they are aware off, and if  
so, which.

--Olaf

---

From: Joe Abley <[email-masked]>
Date: Mon, 30 Oct 2006 16:06:42 -0500

> likely differ from those" it should go straight to the bit bucket.

OK. The two documents have a common heritage (as the respective  
acknowledgements sections indicate) but it's not clear from either  
document whether they describe precisely the same thing as the other.  
I have read both documents and have noted the lack of text in either  
of them which would clarify this issue.

If they describe the same thing, then hooray, but let them say so  
rather than requiring people to infer things from their titles.

Joe

---

From: Mark Andrews <[email-masked]>
Date: Tue, 31 Oct 2006 08:42:52 +1100

> rather than requiring people to infer things from their titles.

	The documents are essentially the same.  In particular the
	policy to resolve the handling of multiple dlv namespaces
	which overlap is the same.  This was not so in earlier
	versions.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: John C Klensin <[email-masked]>
Date: Mon, 30 Oct 2006 17:38:22 -0500

Mark, Sam,

It seems to me that a reference from the draft to the code
description or to Bind 9 more generally, with a note to the
effect that Bind 9 is believed to contain an implementation of
what is being described in the document, could head off a great
deal of confusion... including all of the confusion we have seen
in the last week or so.

    john

---

From: Mark Andrews <[email-masked]>
Date: Tue, 31 Oct 2006 09:46:36 +1100

> deal of confusion... including all of the confusion we have seen

	BIND 9 currently implements only a single DLV tree for ".".
	The policy refects the intended state once lookups in
	multiple DLV trees are supported.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 30 Oct 2006 18:10:13 -0500

>deal of confusion... including all of the confusion we have seen

The DNS WGs[1] have worked hard to stress that BIND is not DNS.  BIND 
is not the reference implementation of the DNS protocol.  With that 
in mind I think it is wrong to have a statement in the document 
declaring that "the *definition* is compliant with BIND 9."

>--On Tuesday, 31 October, 2006 08:42 +1100 Mark Andrews wrote:

I'm glad to hear this.  (I say that because I haven't had time to 
read the documents and code in question.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Secrets of Success #107: Why arrive at 7am for the good parking space?
Come in at 11am while the early birds drive out to lunch.

---

From: John C Klensin <[email-masked]>
Date: Mon, 30 Oct 2006 18:45:23 -0500

--On Monday, 30 October, 2006 18:10 -0500 Edward Lewis
<[email-masked]> wrote:

>> what is being described in the document, could head off a
>> great deal of confusion... including all of the confusion we
>> have seen in the last week or so.
> 
> The DNS WGs[1] have worked hard to stress that BIND is not
> DNS.  BIND is not the reference implementation of the DNS
> protocol.  With that in mind I think it is wrong to have a
> statement in the document declaring that "the *definition* is
> compliant with BIND 9."

That isn't what I said, and I certainly agree with the
principle.  I was suggesting a note that indicated that the Bind
9 implementation was believed, by some, to be compliant with the
definition (or compliant as far as it goes, or whatever).   That
is all: no definitional compliance with Bind 9 (or anything
else), not an IETF assertion that the Bind 9 implementation is,
in fact, conformant, etc.

On the other hand, unless the DNS WGs want to standardize this,
it doesn't seem to me that the above matters a lot.  Sam could
be describing an interesting approach that is similar to the
implementation, or the implementation could be similar to Sam's
approach, or any number of other situations could apply.  I
believe that, for an _informational_ document, it would be
useful for Sam to make some comment about a known
implementation.   That comment could be "that implementation is
believed to be consistent with this spec and, if it isn't, it is
wrong and should be fixed" or "the author of this spec has had a
discussion with the authors of Bind 9, they are not
intentionally inconsistent, and, if they turn out to be, the
code will be fixed" or anything in between.  

Coming back to Phil's comment, I don't believe that the IESG
should be trying to guarantee anything.  However, when the IESG,
or some AD, takes it upon itself to sponsor a non-WG
informational document, rather than sending the author off to
make an independent submission to the RFC Editor, it seems to me
that the IESG takes on the same responsibility to not request
publication of documents that raise unnecessary questions or
cause unnecessary confusion that the RFC Editor does for
documents submitted directly.  And, if the existence of an
implementation is known, some sort of brief discussion of known
differences (if any) between the specification and the
implementation, and maybe even some comments about why the
specification is preferable, would seem to me to be very much in
order.  I hope that no one will read that comment as suggesting
that the IESG do any special work -- all that is needed is to
say "we Last Called this, it appears that some of the community
has asked for some clarification on this point and no one has
objected, so why don't you supply that before publication".

     john

---

From: Edward Lewis <[email-masked]>
Date: Tue, 31 Oct 2006 08:42:47 -0500

>in fact, conformant, etc.

I don't think I would even do that.  I don't think it is commonplace
to single out any one implementation in a specification for
compliance.  That would be an endorsement.  We don't even publicize
the names of implementations in interoperability reports.

>code will be fixed" or anything in between.

It seems to me that the IETF ought not to approve a document that
describes something that contradicts reality.  Defining an alternate
approach, sure, but not when there is a contradiction.  By contradiction
I mean, for example, using the same name for the processes.

Fortunately that is apparently not happening here.

I'm raising this because I can't think of a time when or place when it
would be appropriate to have such a statement.  If there is ever a
specification that has a significant implementation in disagreement
then we don't have a consensus (to approve the document).