Subject: Draft Charter.

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 23 Jun 2003 09:58:57 +0200

Below is a draft for a charter revision. Please send in your comments, we
want to get this to the IESG shortly.

-- Olaf Kolkman, DNSEXT co-chair.

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC

DNSEXT DNS Extensions Working group
---------------------------------------------------

  Charter
  Last Modified: 20-June-2003

  Current Status: Active Working Group (being re-chartered)

  Chair(s):
      Olafur Gudmundsson <[email-masked]>
      Olaf Kolkman <[email-masked]>

  Internet Area Director(s):
      Thomas Narten <[email-masked]>
      Erik Nordmark <[email-masked]>

  Internet Area Advisor:
      Erik Nordmark <[email-masked]>

  Mailing Lists:
      General Discussion: [email-masked]
      To Subscribe:       [email-masked]
      Archive:            <http://ops.ietf.org/lists/namedroppers/>

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.

 Issues surrounding the operation of DNS, recommendations concerning
 the configuration of DNS servers, and other issues with the use of
 the protocol are out of this Working Group's charter.  These issues
 are considered in other venues, such as the DNS Operations Working
 Group.

 Broad topics include changes to the DNS protocol and advance DNS
 protocol documents along the standards track. This includes advance
 zone transfer, update, notify, security documents to Draft standard.

Specific work items are:

       o Protocol clarifications and corrections for DNSSEC, initially
         these clarifications will be done as separate RFCs which will
         later be folded into a document that we refer to as the RFC
         2535bis document standard These include plans and changes
         that simplify the operation of DNSSEC.

       o Generate new specification documents of DNSSEC (the RFC
         2535bis document set) that includes all changes to RFC2535.
         This includes the following RFCs 2931, 3007, 3008, 3090 and
         3226 and a number of Internet Drafts including DS,
         AD-is-secure, Key Signing Flag, etc. Advance this document
         set through the standard process.

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

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

         + 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??? AXFR clarify to Draft Standard.
         + RFC3??? GSS/TSIG to Draft Standard         

       o IPv6 support in DNS records and IPv6 DNS services
         + RFC1886bis to Draft Standard.

       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.

 The lifetime of the group is set by the work items above but while
 these are ongoing the working group has additional tasks:

       o Reviewing and providing recommendations about the specification,
         by other working groups, of RR types that do not require any
         special processing and that do not require any special naming
         conventions.

       o Advance relevant documents to full standard.

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.

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

  Jun 03  Submit to IESG OPT-IN as Informational (nomative to RFC2535-bis)
  Jul 03  Forward IPv6 auto-registration to IESG for Experimental
  Jul 03  Submit to IESG DHCID RR for Proposed Standard.
  Jul 03  Forward LLMNR IESG for Proposed Standard.
  Jul 03  Submit to IESG Delegation Signer for Proposed Standard.
  Aug 03  WG last call on the DNSSEC document set(RFC2535-bis).
  Aug 03  WG last call on  IESG Wildcard clarification
  Aug/Sep 03 Submit to IESG KEY algorithm documents RFC253[69] and
             RFC3110 to
  Sep/Oct 03 Forward RFC2535-bis to IESG for to IESG for Proposed
             standard.
  Q3/Q4 03   Submit to IESG Case insensitive clarification for proposed
             standard.
  Q1 04      Submit to IESG RFC2835 (TSIG)to Draft standard.
  Q1 04      Submit to IESG RFC2930 (TKEY) to Draft standard.

 After ownership of interop test has been taken the following items
 will be assigned milestones.

  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

$Id: Charter.txt,v 1.7 2003/06/20 15:17:30 olaf Exp $

--
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: "D. J. Bernstein" <[email-masked]>
Date: 23 Jun 2003 14:44:43 -0000

> 	 + 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

---

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.

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

>          + 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

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

>          standard and Discover as experimental.

Okay, nothing new but that.

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

>  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

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 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)

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

---

From: Edward Lewis <[email-masked]>
Date: Mon, 23 Jun 2003 22:00:37 -0400

It's in the milestones...

"  Q3/Q4 03   Submit to IESG Case insensitive clarification for proposed
              standard.
"

---

From: Donald Eastlake 3rd <[email-masked]>
Date: Tue, 24 Jun 2003 09:36:17 -0400 (EDT)

Ooops, sorry.
Thanks,
Donald

On Mon, 23 Jun 2003, Edward Lewis wrote:

> Date: Mon, 23 Jun 2003 22:00:37 -0400
> From: Edward Lewis <[email-masked]>
> To: Donald Eastlake 3rd <[email-masked]>
> Cc: Olaf M. Kolkman <[email-masked]>, [email-masked]
> Subject: Re: Draft Charter.
>

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 25 Jun 2003 07:04:54 +0200 (CEST)

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

It's in my plate - not the IESG as a whole.
One of the things I intend to finish before I depart in Vienna.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 25 Jun 2003 07:10:14 +0200 (CEST)

> clarify.  Whether or not consensus has been reached, we do need to 

As I understand the process the WG has submitted the document to
the IESG and it is up to the IESG to interpret the IETF last call
comments (recommending to the IESG how to proceed is the second DNSEXT 
thing I need  to finish before Vienna).
Until this has been done I think it is perfectly reasonable
for the WG to assume that the document will become a proposed
standard since it is out of the WG's hands.

   Erik