Subject: [dnsext] Reminder: draft charter was posted for discussion

From: Andrew Sullivan <[email-masked]>
Date: Mon, 5 Jul 2010 14:06:41 -0400

Dear colleagues,

This is a reminder that we posted some time ago a new draft charter
for the WG.  We've had very little feedback on it.  Two of the
responses asked for us to move the timelines; I have resisted those
calls, but I wonder whether others think more aggressive timelines to
be reasonable.

I attach it again here for your convenience.  I have not yet made the
editorial changes suggested by one eagle-eyed reviewer (off list).

This topic will take a considerable chunk of the time we have
scheduled in Maastricht.  The charter represents our commitments to
the rest of the IETF.

If you have opinions on it, it would be nice to hear them.  We expect
to discuss this in Maastricht and then send it along to our AD,
barring any changes.

Best, 

Andrew

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 5 Jul 2010 12:18:06 -0700

>calls, but I wonder whether others think more aggressive timelines to

More aggressive timelines are possible for the aliasing work, given that if no consensus is possible, the work could just be killed. They are not possible for things that are supposed to be done.

Current:
June 2010       RFC3597-bis Unknown RR advanced to IESG for PS
July 2010       DNSKEY Registry fixes and allocation procedure advanced to IESG
July 2010       DNSSEC Errata document to IESG
Sept 2010       EDNS0-bis update advanced to IESG
Dec  2010       TSIG/MD5 Obsoleting to IESG
Dec  2010       IXFR-only to IESG
July 2011       WG consensus on new or revised RRTYPEs for DNS tree aliasing
                         work
July 2011       Interoperation testing on new or revised RRTYPEs for
                DNS tree aliasing (particularly with existing deployed code)
Nov  2011       Document on new RRTYPE or revised RRTYPE handling for
                         DNS tree aliasing to IESG
Nov  2011       Document on in-zone metadata for DNS tree aliasing to IESG
Nov  2011       Document on uses and limitations of different DNS tree
                         aliasing techniques to IESG

Proposed:
Aug  2010       RFC3597-bis Unknown RR advanced to IESG for PS
Aug  2010       DNSKEY Registry fixes and allocation procedure advanced to IESG
Aug  2010       DNSSEC Errata document to IESG
Sept 2010       EDNS0-bis update advanced to IESG
Sept 2010       IXFR-only to IESG
Jan  2011       WG consensus on new or revised RRTYPEs for DNS tree aliasing
                         work
Feb  2011       Interoperation testing on new or revised RRTYPEs for
                DNS tree aliasing (particularly with existing deployed code)
May  2011       Document on new RRTYPE or revised RRTYPE handling for
                         DNS tree aliasing to IESG
May  2011       Document on in-zone metadata for DNS tree aliasing to IESG
May  2011       Document on uses and limitations of different DNS tree
                         aliasing techniques to IESG

Notes on the proposed changes:
- We need a small amount of time to push the first three items over the line
- "TSIG/MD5 Obsoleting" seems to have no interest; let's drop it
- We should know within four months if there can even be agreement on aliasing; taking more time than that is unlikely to get us more agreement.
- Once (if) there is agreement on aliasing, the three documents should fall out quickly, other than agreement on how they affect DNSSEC

--Paul Hoffman, Director
--VPN Consortium

---

From: Lawrence Conroy <[email-masked]>
Date: Tue, 6 Jul 2010 01:07:05 +0100

Hi esteemed co-chair, folks,
  Speaking from an ENUM perspective, I trust that the EDNS0-bis draft
can hit the IESG in this timeframe (i.e. a month's time from now).

We were going to put in a specific requirement into ENUM for EDNS0
support, but withdrew this as a general dnsext document was coming.

I for one would be happy to avoid having to add an ENUM-specific doc.

As a datum, we have NAPTR-reading client programs that use EDNS0 by
default and have not heard of widespread problems -- lord knows some
of the .tel domains have large RRsets, and that is also true for some
of the ENUM domains I've seen. It sure is time to make this mandatory.

all the best,
  Lawrence

On 5 Jul 2010, at 19:06, Andrew Sullivan wrote:
> <draft-2010-05-28.txt>

---

From: Niall O'Reilly <[email-masked]>
Date: Wed, 07 Jul 2010 09:18:38 +0100

On 05/07/10 19:06, Andrew Sullivan wrote:
> for the WG.  We've had very little feedback on it.

	FWIW, here is a little more ...

> Two of the

	Actual delivery of results is more significant than the
	targets expressed in the timelines.  Given the necessary
	enthusiasm, early delivery of results can be achieved
	whether or not the timelines are adjusted.   Without such
	enthusiasm, tweaking the programme isn't going to accelerate
	progress.  I'm for leaving them as they are.

> to discuss this in Maastricht and then send it along to our AD,

	The two paragraphs which follow the bullet-point "Mechanisms
	to alias DNS trees or parts thereof" seem to me to be more
	detailed than is appropriate in a charter.  None of the other
	items in the list is complemented by motivational material.
	Including some for this one gives an imbalanced "look".

	€0,02
	/Niall

---

From: Alex Bligh <[email-masked]>
Date: Wed, 07 Jul 2010 11:53:06 +0100

> for the WG.  We've had very little feedback on it.

+1 for new charter

-- 
Alex Bligh

---

From: Suzanne Woolf <[email-masked]>
Date: Wed, 7 Jul 2010 11:17:03 +0000

Chairs, colleagues,

I'm in general support of the new charter (with all due sympathy to
those who hoped we'd be able to leave the WG peacefully asleep).

> 	progress.  I'm for leaving them as they are.

+1 on this too. For all the historic and management reasons already
brought up in the discussion previously, setting conservative
timelines and then beating them is preferable to setting aggressive
ones and failing to meet them. I'm especially concerned about the
effect it will have if we don't include the "Guess this is more
complex than we thought" factor, because (as previously noted, more
than once) tinkering with old, widely deployed protocols probably
can't be done without subtle (and time-consuming) complications.

Suzanne

---

From: Alex Bligh <[email-masked]>
Date: Wed, 07 Jul 2010 12:27:43 +0100

> 	progress.  I'm for leaving them as they are.

+1. Experience suggests we do not always meet even timelines which
we initially consider not ambitious.

-- 
Alex Bligh

---

From: Paul Vixie <[email-masked]>
Date: Thu, 08 Jul 2010 01:54:36 +0000

> Date: Mon, 5 Jul 2010 14:06:41 -0400
> From: Andrew Sullivan <[email-masked]>
> 
> for the WG.  We've had very little feedback on it.  ...
> 
> I attach it again here for your convenience.  ...
> 
> If you have opinions on it, it would be nice to hear them.  ...

with the understanding that there's a range of possible views as to the
desireability of continued evolution in a mature deployed protocol, here
are mine.  i apologize to our WGC's for the lateness of this reply.

+---
| DRAFT charter for DNSEXT, 2010-05-28.  SUBJECT TO CHANGE
...
| The WG will consider work in the following areas:
| 
| * DNSSEC and TSIG/TKEY algorithm maintenance
| * Mechanisms that complement, or are alternatives to, TSIG and SIG(0)

since TSIG and SIG(0) are both last-mile (recursive to stub) protocols,
perhaps this bullet item would be clearer if it was amended to say:

* Last mile (recursive to stub) mechanisms that complement, or are
  alternatives to, TSIG and SIG(0); specifically including stub DNSSEC
  validation and protocol extensions to support same.

| * Hardening DNS protocol and providing guidance to implementers

the word "hardening" is at best unclear in this context.  perhaps this can
be reworded as follows:

* Improving defensibility and resiliency of DNS protocol agents by analyzing
  possible buffer overrun/underrun conditions and offering implementation
  guideance on test coverage for same.

| * Improving DNS zone synchronization mechanisms 

i think this is too specific, and should be reworded as follows:

* Improving DNS zone and DNS server configuration synchronization mechanisms 

...
| Goals and Milestones:
...
+---

i have no other comments.

---

From: "George Barwood" <[email-masked]>
Date: Thu, 8 Jul 2010 06:19:51 +0100

----- Original Message ----- 
From: "Paul Vixie" <[email-masked]>
To: <[email-masked]>

>  guideance on test coverage for same.

My understanding of "hardening" is that it refers to measures to mitigate or prevent
the various denial of service / privacy attacks that may be possible with the current DNS transport,
especially those which may have been aggravated by the introduction of DNSSEC and EDNS.

That doesn't mean that every such proposal should be adopted, just that such proposals
are within the scope of the WG.

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 08 Jul 2010 14:23:43 +0200

Andrew,

I have read the new charter and I am fine with it atm.

Ondrej

-- 
  Ondřej Surý
  vedoucí výzkumu/R&D manager
  -------------------------------------------
  CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
  Americka 23, 120 00 Praha 2, Czech Republic
  mailto:[email-masked]    http://nic.cz/
  tel:+420.222745110       fax:+420.222745112
  -------------------------------------------

---

From: "Yao Jiankang" <[email-masked]>
Date: Thu, 8 Jul 2010 21:18:29 +0800

I am fine with it too.

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 08 Jul 2010 17:52:05 +0200

Paul,

>    validation and protocol extensions to support same.

We use TSIG to authenticate AXFR - hence I am unsure if limiting to 
"Last mile" isn't too specific.

>    guideance on test coverage for same.

I think you have changed meaning of the "Hardening DNS protocol" to 
"Hardening DNS implementations".  Both is fine, but different.  Anyway 
I'm fine with word "Hardening".

> * Improving DNS zone and DNS server configuration synchronization mechanisms

I'm unsure if DNS server configurations doesn't fall in dnsop area.

-- 
  Ondřej Surý
  vedoucí výzkumu/Head of R&D department

---

From: Joe Abley <[email-masked]>
Date: Fri, 9 Jul 2010 17:13:33 -0400

> to discuss this in Maastricht and then send it along to our AD,

The proposed new charter looks sane to me. Here are some trivial, non-substantitve edits. With or without them, I support this revised charter.

Joe

--- draft-2010-05-28-orig.txt	2010-07-09 17:09:51.000000000 -0400
+++ draft-2010-05-28.txt	2010-07-09 17:12:21.000000000 -0400
@@ -21,7 +21,7 @@
 * Maintaining a Wiki containing a guide to DNS protocol RFCs
 * Improving DNS zone synchronization mechanisms 
 * Examining transport protocols, possibly adding new ones.
-* Mechanisms to alias DNS trees or parts thereof
+* Exploring mechanisms to alias DNS trees or parts thereof
 
 While the DNS offers two mechanisms for aliasing DNS labels -- CNAME
 and DNAME -- neither of these provides the support necessary to alias
@@ -29,7 +29,7 @@
 that the restriction has proven to be too great in practice,
 particularly with burgeoning deployment of IDNA and the need to
 provide domain name variants.  The issue is made more complex by
-DNSSEC
+the deployment of DNSSEC.
 
 The DNSEXT WG will evaluate ways to provide such aliasing, to add
 metadata to zones to allow easier operation of zones when such
@@ -49,7 +49,7 @@
 
 The WG will review DNS protocol related work which may originate
 elsewhere in the IETF, including AD-sponsored submissions or drafts
-in other working group.
+in other working groups.
 
 Goals and Milestones: