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:john-ietf(_at_)jck(_dot_)com]
Sent: Sunday, October 29, 2006 3:43 PM
To: Geoff Huston; Bernard Aboba; ietf(_at_)ietf(_dot_)org
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
<gih(_at_)apnic(_dot_)net> 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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf