Subject: WG Action: RECHARTER: DNS Extensions (dnsext)

From: The IESG <[email-masked]>
Date: Wed, 09 Feb 2005 15:39:22 -0500

The charter of the DNS Extensions (dnsext) working group in the Internet Area 
of the IETF has been updated. For additional information, please contact 
the Area Directors or the working group Chairs.

+++

DNS Extensions (dnsext)
=========================

  Current Status: Active Working Group 

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

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

  Internet Area Advisor:
      Thomas Narten <[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 DNS protocol issues,
 including the specification of message formats, message handling, and
 data formats used for DNS client-server and server-server
 communication.

 This WG is focused on advancing the zone transfer, update, notify
 and DNSSECbis documents to Draft standard.

 The WG works on solutions for DNSSEC deployment issues that may
 require protocol modifications. Two of these issues are identified
 and are worked on under the umbrella of this WG. 1] (a) method(s) to
 prevent the possibility of trivial zone enumeration and 2] a method
 for automated rollover of trust-anchors configured in validating
 resolvers.

 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 scope for this Working Group.  These issues
 are considered in other venues, such as the DNS Operations Working
 Group.

 The DNSEXT Working Group sometimes uses an additional mailing list
 for discussion of DNS Security related issues. This list is open to
 all

   Discussion: [email-masked]
   To Subscribe: [email-masked]
   Archive:  http://www.cafax.se/dnssec/ and
            ftp://ftp.cafax.se/pub/archives/dnssec.list

 The 2535bis document set was edited by a team. This team was
 chartered with making editorial changes only, with all substantiative
 changes discussed on the WG list. The archive of this editors-only
 mailing list is available at:
   
   http://www.east.isi.edu/projects/DNSSEC

Specific work items are:

       o Advance the DNSSECbis document set through the standards
         process.

       o Clarification of RFC1034/1035 relating to DNSEXT ongoing work.
         + Clarification of wildcard processing rules.

       o After the work items above have been completed the working
         group will continue on reviewing the following existing
         proposed standard and examine if there is a possibility to
         progress them on the standards track.

         + RFC1995 (IXFR)  to Draft standard.
         + RFC1996 (Notify) 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.
         + RFC2672 (DNAME) to Draft Standard, or revision.
         + RFC2845 (TSIG)to Draft standard.
         + RFC2930 (TKEY) to Draft standard.
         + RFC3007 (Secure Update) to Draft standard.
         + RFC3645 GSS/TSIG to Draft Standard         
         + RFC3??? AXFR clarify to Draft Standard.

       o Identify (a) method(s) to prevent the possibility of trivial
         zone enumeration.

       o Define a method for automated rollover of trust-anchors
         configured in validating resolvers.

       o Foster the development of Link Local Multicast Name
         Resolution (LLMNR) standard. The WG has taken up this work
         since LLMNR it is very similar to the DNS protocol.  LLMNR is
         targeted as proposed standard.

 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.

Goals and Milestones:

Done            Forward RFC2535-bis to IESG for proposed standard
Done            Forward Case Insensitive to IESG for Proposed Standard
Done            Forward LLMNR to IESG for Proposed Standard
Feb 05          Submit KEY algorithm documents RFC253[69]bis and RFC3110 to IESG for 
		proposed standard
Feb 05          Update boilerplate text on OPT-IN
Mar 05          Forward Wildcard clarification to IESG for proposed standard
Mar 05          Finalize Zone Enumeration Requirements
Apr 05          Start of process of reviewing the following RFCs 
                and to move them to Draft Standard status
May 05          Submit to IESG RFC2845 (TSIG)to Draft standard
Jun 05          RFC2672 (DNAME) to Draft Standard or revision
Jun 05          RFC2671 (EDNS0) to Draft Standard 
Jul 05          RFC1995 (IXFR) to Draft standard
Jul 05          RFC1996 (Notify) to Draft Standard
Jul 05          RFC2136 (Dynamic Update) to Draft Standard
Jul 05          RFC3007 (Secure Update) to Draft Standard
Sep 05          RFC2308 (Neg Caching) to Draft Standard
Sep 05          RFC2930 (TKEY) to Draft standard
Sep 05          RFC2181 (Clarify) to Draft Standard
Nov 05          RFC2782 (SRV RR) to Draft Standard
Nov 05          RFC1982 (Serial Number Arithmetic)
Nov 05          RFC2538 (CERT RR) to Draft Standard
Nov 05          FRC2539 (DH Key RR) to Draft Standard
Nov 05          RFC3226 (Message Size) to Draft Standard 

--
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: Fri, 11 Feb 2005 04:59:44 -0500 (EST)

>          + RFC3??? AXFR clarify to Draft Standard.

I thought AXFR clarify died a horrible and tragic death after a short and
ill-fated attempt to impose unnecessary changes made by Bind on the rest
of the DNS implmentations.

Why is this still on the list?

Possibly AXFR does need to be clarified. I think it was agreed that the
current spec was vague, but Bind groups' proposed solution was universally
rejected (by everyone except those associated with Bind, of course)

I may be willing to write a clarification for AXFR that corrects the
ambiguity in the fashion accepted by all of the non-Bind server
implementations.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Fri, 11 Feb 2005 11:41:37 +0100

> Why is this still on the list?

See the status of this ID in the ID-tracker:
  https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=5123&rfc_flag=0

To paraphrase: The AD has a number of comments and the working group will need to pick 
this ID up again. 

To be continued.

-- Olaf

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

---

From: Dean Anderson <[email-masked]>
Date: Fri, 11 Feb 2005 15:34:00 -0500 (EST)

>   https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=5123&rfc_flag=0

BTW, this is database thing is great. Kudos to the people who made the
database app happen. I'm surprised at the amount of information in it 
already. The 'clarify work is tracked back to 2002.

		--Dean

---

From: "D. J. Bernstein" <[email-masked]>
Date: 16 Feb 2005 01:53:15 -0000

A note to AXFR implementors worried about interoperability: Check out
http://cr.yp.to/djbdns/axfr-notes.html for a description of exactly how
the AXFR protocol works.

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