Subject: [dnsext] WG Review: Recharter of DNS Extensions (dnsext)

From: IESG Secretary <[email-masked]>
Date: Tue, 23 Nov 2010 09:25:39 -0800 (PST)

A modified charter has been submitted for the DNS Extensions (dnsext)
working group in the Internet Area of the IETF.  The IESG has not made any
determination as yet.  The modified charter is provided below for
informational purposes only.  Please send your comments to the IESG
mailing list ([email-masked]) by Tuesday, November 30, 2010.

DNS Extensions (dnsext)
---------------------------------------------
Status: Active Working Group
Last updated: 2010-11-09

Chairs:
  Olafur Gudmundsson <[email-masked]>
  Andrew Sullivan <[email-masked]>

Internet Area Directors:
  Ralph Droms <[email-masked]>
  Jari Arkko <[email-masked]>

Internet Area Advisor:
  Ralph Droms <[email-masked]>

Mailing Lists:
  Address:	[email-masked]
  To Subscribe:	https://www.ietf.org/mailman/listinfo/dnsext
  Archive:	http://www.ietf.org/mail-archive/web/dnsext/

Description of Working Group:

The DNS has a large installed base and repertoire of protocol
specifications. The DNSEXT working group will actively advance DNS
protocol-related RFCs on the standards track while thoroughly
reviewing further proposed extensions. The scope of the DNSEXT WG is
confined to the DNS protocol, particularly changes that affect DNS
protocols "on the wire" or the internal processing of DNS data. DNS
operations are out of scope for the WG.

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)
* Hardening DNS protocol and providing guidance to implementers
* Advancing existing DNS-related Proposed Standard RFCs to Draft/Full
  Standard
* Obsoleting DNS-related RFCs
* 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

While the DNS offers two mechanisms for aliasing DNS labels -- CNAME
and DNAME -- neither of these provides the support necessary to alias
completely one part of the DNS tree as another part.  There are claims
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 DNSEXT WG will evaluate ways to provide such aliasing, to add
metadata to zones to allow easier operation of zones when such
aliasing is needed, or both.  The WG will also provide an
informational document outlining the various strategies available,
what they might be used for, and what their limitations are.  It is
possible that the WG will conclude no aliasing or metadata support is
possible, or that none of the proposals so far made are adequate.

Before formal adoption of any work item at least 5 working group
participants must publicly state that the item is within charter and
is a worthwhile item for further study.

The DNSEXT WG will conduct the specified RFC5395 review of RR
templates as they are posted, and EDNS0 Option templates if EDNS0-bis
updates registration requirements.

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.

Goals and Milestones:

Done           AXFR Clarify to IESG
Done           DNS existing transport protocol
                    recommendations/clarifications to IESG
Dec 2010       RFC3597-bis Unknown RR advanced to IESG for PS 
Dec 2010       DNSKEY Registry fixes and allocation procedure
                    advanced to IESG
Dec 2010       EDNS0-bis update advanced to IESG
Dec 2010       TSIG/MD5 Obsoleting to IESG
Dec 2010       IXFR-only to IESG
Jan 2011       DNSSEC Errata document to IESG 
Jul 2011       WG consensus on new or revised RRTYPEs for aliasing
                    work
Jul 2011       Interoperation testing on new or revised RRTYPEs
                    (particularly with existing deployed code)
Nov 2011       Document on new RRTYPE or revised RRTYPE handling for
                    alias to IESG
Nov 2011       Document on in-zone metadata for aliases to IESG
Nov 2011       Document on uses and limitations of different alias
                    techniques to IESG

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 29 Nov 2010 10:06:46 -0800

>is a worthwhile item for further study.

The IESG should recognize that this restriction will cause the DNSEXT WG to sometimes not be able to take on some of the items for which it is being chartered, and that those items might have to be done by individual submission in such cases.

--Paul Hoffman, Director
--VPN Consortium

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 29 Nov 2010 13:54:31 -0500

> The IESG should recognize that this restriction will cause the DNSEXT WG to sometimes not be able to take on some of the items for which it is being chartered, and that those items might have to be…

In defence of this requirement (and speaking as chair but noting I
didn't discuss this message with my co-chair), I want to argue that
any draft that can't attract five reviews either really isn't
on-charter, or else it's an idea that shouldn't be standardized
because nobody has looked at it.  Most of the time our problem is the
latter.  I don't think such things should go by individual submission,
either; I think they just shouldn't be done.

A

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

---

From: Jari Arkko <[email-masked]>
Date: Mon, 29 Nov 2010 22:26:54 +0200

Agreeing with Andrew. Really, if we can't get enough interest to support 
a particular work item then its not worth doing...

I'll also note that if there's interest but the group feels that the 
topic is outside the charter, I think all of us are open to a discussion 
about extending the charter.

Jari

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 29 Nov 2010 12:39:32 -0800

At 10:26 PM +0200 11/29/10, Jari Arkko wrote:
>Agreeing with Andrew. Really, if we can't get enough interest to support a particular work item then its not worth doing...
>
>I'll also note that if there's interest but the group feels that the topic is outside the charter, I think all of us are open to a discussion about extending the charter.

I'm going to push back on this a bit. The DNSEXT WG has had times of extreme lack of interest, so "couldn't find five people in the WG who would say they would review it" is not a solid indicator of lack of value.

If a good idea has three authors on it, plus maybe two other DNS-capable people who will review it, why should that document *not* get to IETF Last Call? It is fine for the sponsoring AD for an individual submission to kill something due to lack of interest. The level of interest and review for a DNS-related idea can maybe be better judged in an IETF Last Call than in the DNSEXT WG.

--Paul Hoffman, Director
--VPN Consortium

---

From: Thomas Narten <[email-masked]>
Date: Mon, 29 Nov 2010 20:29:31 -0500

Paul Hoffman <[email-masked]> writes:

> I'm going to push back on this a bit. The DNSEXT WG has had times of
>  extreme lack of interest, so "couldn't find five people in the WG
>  who would say they would review it" is not a solid indicator of
>  lack of value.

And a twin part of "lack of interest" is that the document doesn't get
the review and improvement that it needs. WGs are wise not to take on
such documents.

> If a good idea has three authors on it, plus maybe two other
>  DNS-capable people who will review it, why should that document
>  *not* get to IETF Last Call?

If something is truly a good idea, and there is a need, the best way
to validate that is to get non-authors to do reviews and say "good
stuff".

Anything other than that places the burden on others who are often
poorly positioned to do that. E.g., the ADs or IESG.

We also know that that there are plenty of documents that no one looks
at during IETF LC, so using silence during LC as an indication of
support is also not wise.

I'm strongly in favor of a model where if a document can't get a
minimal level of support (and 5 non-authors doesn't seem that
unreasonable), it is far from clear the document is needed at all. And
the burden on finding those 5 individuals shoudl be on the authers,
not on the IETF leadership.

Better to kill documents (or more correctly "let die") at the start,
than to string them along for many month or years if there really
isn't enough interest to complete the work.

Thomas

---

From: [email-masked]
Date: Tue, 30 Nov 2010 05:37:01 +0000

> either; I think they just shouldn't be done.

	i was with you right up to the; "(no).. individual submissions either"
	i think this is a huge problem with the modern IETF - too focused on
	products that can be monitized and shipped and far less on exploring and
	documenting ideas.  I guess that the right place to develop unpopular
	ideas is in academic papers, technical reports, and trademarked works
	indead of bringing them to a once open forum.  YMMV of course.

--bill

> 
> A
> 
> -- 
> Andrew Sullivan
> [email-masked]
> Shinkuro, Inc.
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext

---

From: Jari Arkko <[email-masked]>
Date: Tue, 30 Nov 2010 14:26:40 +0200

Andrew, Bill,

Generally speaking I at least tend to use roughly the same bar for 
working group items and individual submissions via the AD. Both will be 
reviewed by the IETF, get a full IESG and directorate reviews, and may 
come with a label that shows the IETF recommends them (BCP or PS). Of 
course, there are various different types of documents and possible 
extensions. Experimental "someone's experimental extension of FOO" and 
informational ("thoughts on BAR") can be published more easily than 
standards ("the recommended way").

So I do agree with Andrew again that if some specific proposal is not 
interesting for the working group then its probably not interesting for 
the IETF as a whole either, and I probably would not sponsor it. And if 
there aren't N reviewers to look at a document, we can't really make a 
quality output anyway. Informational and Experimental have a lower bar 
in the sense that we do not have be so sure that they are the 
recommended approach for the Internet, but even they do require people 
to review the documents. However, I would like to point out we also have 
Independent submissions via the RFC Editor, which may sometimes be used 
to publish documents that the IETF does not take on.

Jari

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 30 Nov 2010 08:02:02 -0800

At 2:26 PM +0200 11/30/10, Jari Arkko wrote:
>Andrew, Bill,
>
>Generally speaking I at least tend to use roughly the same bar for working group items and individual submissions via the AD. Both will be reviewed by the IETF, get a full IESG and directorate reviews, and may come with a label that shows the IETF recommends them (BCP or PS). Of course, there are various different types of documents and possible extensions. Experimental "someone's experimental extension of FOO" and informational ("thoughts on BAR") can be published more easily than standards ("the recommended way").

Exactly. The fact that the DNSEXT WG chairs could not find five reviewers who wanted to work on an experimental or informational document should not prevent it from being published in the IETF stream if an AD wants to move it forwards.

>
>So I do agree with Andrew again that if some specific proposal is not interesting for the working group then its probably not interesting for the IETF as a whole either, and I probably would not sponsor it.

Right: "probably" is the operative word here.

> And if there aren't N reviewers to look at a document, we can't really make a quality output anyway. Informational and Experimental have a lower bar in the sense that we do not have be so sure that they are the recommended approach for the Internet, but even they do require people to review the documents.

That's the judgement call by the sponsoring AD, either before he sponsors or after the IETF Last Call. If not, and the authors still want it published as an RFC, it becomes the judgement call of the ISE. The fact that the DNSEXT WG couldn't find five reviewers should be a piece of data, not a hard stop.

> However, I would like to point out we also have Independent submissions via the RFC Editor, which may sometimes be used to publish documents that the IETF does not take on.

Of course, but it should not be considered the only method, particularly if an AD wants to see if there is enough review energy outside the often-dysfucntional DNSEXT WG.

--Paul Hoffman, Director
--VPN Consortium

---

From: [email-masked]
Date: Tue, 30 Nov 2010 17:50:48 +0000

> standards ("the recommended way").

	so, if some mis-directd soul has a non-popular idea, does 
	work, runs the experiment, and wants to document it for the
	future - then the individual submission to experimental or
	informational is ok with our AD?

> to publish documents that the IETF does not take on.

	or should we take this path?  (I'll note that the previous RFCed
	informed me that even this path has the AD/IESG/directorate review
	before being allowed publication).

--bill

---

From: Jari Arkko <[email-masked]>
Date: Tue, 30 Nov 2010 19:59:16 +0200

Bill,

> then the individual submission to experimental or
...
> 	or should we take this path?

Judgment call. You should ask Ralph or me about it. Depending on the 
case we may either tell you to take it to the RFC Editor, ask the WG to 
take it on, or be willing to sponsor a document through the IETF. A big 
factor is the interest from others to review etc.

> (I'll note that the previous RFCed

That's not right, at least not as a general rule. There are some cases 
where you are allocating IANA numbers from an IETF number space, for 
instance, where you can only publish your RFC through the IETF. But in 
general the RFC Editor submissions are independent, and do not require 
IETF review.

There is however always an IESG check even for these documents, but not 
for technical content, just to check that the IANA rules have not been 
broken and that no end run is attempted to bypass something that an IETF 
WG is working on. As this is not a technical review, we do not ask for 
directorate reviews or IETF last call feedback.

Jari

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 30 Nov 2010 18:07:04 -0500

I can think of cases where the DNSEXT group would have no interest in a
draft but other parts of the IETF would have very serious interest.

A lot of work that needs to be done does not fit neatly in the IETF areas.
In particular to do useful work on security or optimization a proposal will
very often cut across multiple layers in the stack. DKIM does, KEYASSURE
does, WebSEC does.

The point is in any case moot since WGs do not get a pocket veto on work
proposals. It might be a different issue if there was active opposition to a
proposal. But indifference does not merit that consideration.