Subject: axfr-clarify, again

From: "D. J. Bernstein" <[email-masked]>
Date: 23 Jun 2003 14:44:43 -0000

Olaf M. Kolkman writes:
> 	 + RFC3??? AXFR clarify to Draft Standard.

Replacement charter item: ``See whether consensus can be achieved on
AXFR clarifications.'' I fully understand the desire to clarify how the
DNS protocol works---but that doesn't justify pushing a horribly flawed
document to ``Proposed Standard,'' never mind ``Draft Standard.''

At least seven people have gone on record as objecting to axfr-clarify;
see http://cr.yp.to/djbdns/axfr-clarify.html for details. The BIND
company admits that axfr-clarify does not correctly describe the
behavior of most DNS servers on the Internet.

My web page http://cr.yp.to/djbdns/axfr-notes.html contains an accurate
description of the AXFR protocol, quite different from axfr-clarify.
Along the way, it identifies nine clear errors in axfr-clarify: six
points where axfr-clarify (in violation of RFC 2119 section 6) prohibits
existing working behavior, and three points where axfr-clarify creates
new interoperability problems.

What the BIND company has given us is not, in fact, ``clarification.''
It is BIND 9 documentation fraudulently posing as clarification. It is
blatantly biased in favor of one vendor---the same vendor that produced
the document, that has generated most of the messages supporting the
document, and that previously paid one of the WG chairs (Gudmundsson) to
work on its software.

The problems with axfr-clarify, both in content and in procedure, have
been thoroughly documented. Anyone who wants to ignore IETF documents---
even the occasional high-quality ones, the ones that are important for
interoperability---simply has to point to the progress of axfr-clarify
as an IETF ``standard.'' A legitimate standards organization would never
have allowed axfr-clarify to get anywhere.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

--
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: Dean Anderson <[email-masked]>
Date: Mon, 23 Jun 2003 12:08:10 -0400 (EDT)

This document was previously shown to be a major change and an unnecessary
change at that.  There is quite obviously no consensus on the merits of
the document.

While a clarification on AXFR is order due to vague language in the
present specification, such clarification should take into account how
multiple existing implementations interpreted the vague specification,
rather than try to push through an unnecessary change made by the Bind9
developers.

		--Dean

---

From: Edward Lewis <[email-masked]>
Date: Mon, 23 Jun 2003 15:47:16 -0400

Keep in mind that a charter is a statement of scope.  Excepting the 
milestone list that is attached, the charter lists the work items 
vague enough to provide scope without preventing us from making 
decisions based on the results of lessons not yet learned.

The latter sentence refers in part to the quagmire that is AXFR 
clarify.  Whether or not consensus has been reached, we do need to 
clarify this topic.

At 9:58 +0200 6/23/03, Olaf M. Kolkman wrote:
>Below is a draft for a charter revision. Please send in your comments, we
>want to get this to the IESG shortly.
>
>Description of Working Group:
>
>  DNS was originally specified in RFC's 1034 and 1035, with subsequent
>  updates.  Within the scope of this WG are protocol issues, including
>  message formats, message handling, and data formats. New work items
>  and milestones may be added from time-to-time with the approval of
>  the Working Group and the IESG.

You need to caveat that the WG is looking at specific (class of) 
EXTENSIONS to the protocol.  I would drop the last sentence as that 
is always true.

>Specific work items are:

You need to do a wording nits pass, but I'll stick to issues only for now.

Looks like 'o' 1 and 2 are the same.

>
>        o Clarification of RFC1034/1035
>          + Clarification of wildcard processing rules.
>          + Case Insensitivity Clarification.

I'd be careful here.  There's a lot of clarification to be done if 
this is a main work item.  Clarifications should only be undertaken 
if they are in support of other extension work.  Otherwise the group 
might well consider the clarification DNS into DNS++ within scope.

>        o Advance the following existing proposed and draft standards on
>          the standard track.

I think that specifying the level of standard as being Draft Standard 
is a good scoping of the work, but keep in mind what that means. 
Draft Standard is not the end of the line for a body of work, but it 
could be the end of the line for the WG formed to achieve that level.

Perhaps the WG ought to consider it's scope to take things that have 
once hit PS and get them to DS.  I.e., no new ideas.  (Yes, I'm 
serious, sometimes new ideas belong in newer WG's.)

>        o Investigate how protocol changes, use of multicast,
>          etc. might support zeroconf environments, of the two
>          approaches considdered, the WG targets LLMNR as proposed
>          standard and Discover as experimental.

Okay, nothing new but that.

>  The lifetime of the group is set by the work items above but while
>  these are ongoing the working group has additional tasks:
>
>        o Advance relevant documents to full standard.

This I find possibly unsettling.  If DNS was well documented, etc., 
the different extension efforts (DNSSEC, LLMNR) could run off at 
independent paces with some matrix-management coordination.  But it 
isn't well documented and maybe we need a monolith.  Although leaving 
DS as a goal for the WG (above), FS possibilities are needed because 
of the RFC2026 "progress or die" section (6.2, top of page 21).

On the other hand, I'd rather see the above added if/when the time 
comes (heck, we had nothing get to DS in nearly, what, a decade) and 
we decide to re-charter.

>
>Goals and Milestones:
>
>  Where there is no milestone for a work item mentioned above, the
>  working group has not yet decided upon the priority for the item, or,
>  in some cases, whether active work will be undertaken, and no target
>  milestone has yet been set.

I would strongly encourage that every effort be made to make this 
milestone list as detailed as possible.  Milestones are easily 
changed (AD permission and mail to ietf-action).  With more detail, 
it'll encourage more maintenance of them.  (The one thing this group 
needs is more attention to detail and process.)

There should be no need for any prose in the milestone section...no excuses!

>  The milestones will be reviewed about 3 times per year, coinciding
>  with the IETF meeting.

Not a milestone, and, should be reviewed every time a milestone is 
hit/passed.  The review takes a few seconds per month and is a good 
habit to be in.

>   Jun 03  Submit to IESG OPT-IN as Informational (nomative to RFC2535-bis)

It's already June 23rd and I for one don't see that there's any 
support in the WG for doing this.  I am objecting to the milestone 
date here as we talking about the charter.  I can't see this being 
met.

(One of my pet peeves are management plans that try to have deadlines 
that are too soon for the group to react to.)

>   o RFC1995    (IXFR) to Draft standard
>   o RFC1996    (Notify) to  Draft Standard.
>   o RFC2136bis (Dynamic Update) to Draft Standard.
>   o RFC2181    (Clarify) to Draft Standard.
>   o RFC2308    (Neg Caching) to Draft Standard.
>   o RFC2535bis (DNSSEC) to Draft standard.
>   o RFC2671    (EDNS0) to Draft Standard.
>   o RFC3007    (Secure Update) to Draft standard.
>   o RFC3???    (AXFR clarify) to Draft Standard.
>   o RFC3???    (GSS/TSIG) to Draft Standard
>   o RFC3???    (Unkown RR) to Draft Standard

Off the top of my head, I'd like to add DNAME to that - if we really 
are trying to get all the PS's progressed.  Geezer - RFC 1995? 
Wasn't that published in, like, 1940?

When was the last time a DNS document achieved Draft Standard status?

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

...as graceful as a blindfolded bull in a china shop...

---

From: Brian Wellington <[email-masked]>
Date: Mon, 23 Jun 2003 14:35:52 -0700 (PDT)

On Mon, 23 Jun 2003, Olaf M. Kolkman wrote:

>        + RFC1995 (IXFR)  to Draft standard.
> 	 + RFC1996 (Norify) to Draft standard.
> 	 + RFC2136bis (Dynamic Update) to Draft Standard.
> 	 + RFC2181 (Clarify) to IESG for advancement to Draft Standard.
> 	 + RFC2308 (Neg Caching) to Draft Standard.
> 	 + RFC2671 (EDNS0) to Draft Standard.
> 	 + RFC2835 (TSIG)to Draft standard.
> 	 + RFC2930 ( TKEY) to Draft standard.
> 	 + RFC3007 (Secure Update) to Draft standard.
>          + RFC3??? GSS/TSIG to Draft Standard         

Any chance of retrieving ad-is-secure from the IESG black hole?

Brian

---

From: Donald Eastlake 3rd <[email-masked]>
Date: Mon, 23 Jun 2003 21:37:21 -0400 (EDT)

Is "Case Insensitivity" considered too minor to mention? As far as I 
know, its ready for WG last call.

Thanks,
Donald
======================================================================
 Donald E. Eastlake 3rd                       [email-masked]
 155 Beaver Street              +1-508-634-2066(h) +1-508-851-8280(w)
 Milford, MA 01757 USA                   [email-masked]

On Mon, 23 Jun 2003, Olaf M. Kolkman wrote:

> Date: Mon, 23 Jun 2003 09:58:57 +0200
> From: Olaf M. Kolkman <[email-masked]>
> To: [email-masked]
> Subject: Draft Charter.
> 
> 
> -- Olaf Kolkman, DNSEXT co-chair.
> 
> ---------------------------------| Olaf M. Kolkman
> ---------------------------------| RIPE NCC