Subject: Re: [DNSOP] draft new charter

From: Edward Lewis <[email-masked]>
Date: Fri, 4 Apr 2014 10:23:41 -0400

On Apr 3, 2014, at 17:39, Suzanne Woolf <[email-masked]> wrote:

> 6. Publish documents that attempt to better define the overlapping
>   area among the public DNS root, DNS-like names as used in local or restricted
>   naming scopes, and the 'special names' registry that IETF
>   manages, and how they will interact moving forward.  Work in a
>   liaison capacity to ICANN to assist in this.

I’m going to cherry-pick on this one as it is already causing comments.

The generic need is:

Derive a means by which the DNS name space can accommodate limited-scope names, and publish documents describing the solution.

I realize that this topic has come up in the context of having both the IETF and ICANN independently decide what is delegated in the root zone operated by IANA.  I propose to recast the problem as defining the concept of “scoping” names - to take this squarely into where the IETF expertise is - engineering the protocol.  And by “propose” I mean just that, perhaps “scoping” isn’t the word to use.

I’m not saying “scoping” is a sure fire winner.  In fact, I bet there’s a disaster in that based on past experience and based on the tools we have.
- Locally scoped (“site-local”) IPv6 addresses are, err, were dead-on-arrival (RFC 3879 killed them and 4007 commented, 3513 had proposed them).
- The DNS lacks “autonomous system numbers” which can help a router know when not forward an advertisement for prefixes representing so-called “RFC 1918” space.
- And the DNS protocol doesn’t have the notion of a “link” - for link-local.

But, as for charter language, there is a need to come up with a way to manage the scope of names.  For instance, I want to have my LAN users go to printer01.corp and treat that as a domain name fully in application software yet never once see a query for printer01.corp leave my organization’s virtual LAN (which might be a few sites around the globe).  I am not saying it is easy or fits in the model of the DNS, but there is a user constituency that has stated “a requirement” for it.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 7 Apr 2014 12:40:53 -0400

This charter seems to fly in the fase of the traditional IETF charter style, wherein a WG was deemed to have a set end point.  “Develop guidelines”, “publish documents” and “serve as a clearinghouse” are terms that engender more activity but don’t indicate progress.  (A long time ago, in a government job, I was taught terms that guaranteed one would never fail a performance review - like “participate in” and so on.  The terms here fall into the same category.)

Comment on …

… item 1.

Don’t attempt to list the functional roles name servers name servers fill.  Most roles have never had formal definitions and in the industry “roles” have been used confusingly.  E.g., many practitioners think “root servers” are the servers for a TLD or are the (authoritative) servers of any zone.  While terminology can be refined and new definitions given, the confusion today means that the role labels don’t fit in the charter.

To be more specific, what problems exist in the current state of DNS operations?  (I believe there are quite a few.)  The specific issues the WG is willing to look into should be enumerated.  (A blanket charter is a bad idea - a restrictive charter can always be updated, a blanket allows for “make-work” items.)

… item 2.

DNSSEC is a clumsy protocol extension.  Empirical evidence suggests that it is - (without a quantitative study, I’ll go out on a limb and say) most DNSSEC validation failures stem from operator or operations related errors than forged messages.  What can be done is come up with a way to counter the “lack of a child knowing about the parent” in the assembling of the signed chain of trust.  I.e., sending the key material from child to parent.  Other needed improvement is to develop practices for debugging (SERVFAIL means what?), monitoring, and measurement.   E.g., The RFC for DS hash algorithm 2 has a trigger in it for when algorithm 2 is well deployed - but there’s no means to discover that. (http://iepg.org/2012-03-ietf83/IETF83IEPGLewis.pdf, slide 23)

See also “Crypto Alg Undertanding.”

And another topic here - clear and understandable guidance on the parameters of DNSSEC - key lengths, durations, etc.

… item 3

Again - something specific is needed.  I am a loss here for suggestions.  Hasn’t DNS been ready for IPv6 for a very long time?

… item 4 and item 5

This is kind of like saying that one of my duties is “show up for work.”  Isn’t #4 just saying the WG should act as WG?  “Protocol maintenance” might just mean adding DNSSEC key algorithm numbers or it might mean a new zone transfer protocol.  The latter is something I wouldn’t think this group is wanting to take on.

(I had written that for 4, but then I saw 5 gave me the same impression.  In the sense I do see 4 and 5 are different, if I have the same reaction, they are two general to be “good” charter items unless the goal is to have a never ending WG.)

… item 6

Already commented on that.

On Apr 3, 2014, at 17:39, Suzanne Woolf <[email-masked]> wrote:

> Colleagues,
> 
> Here is draft text for the new charter we've been talking about for DNSOP.
...

---

From: joel jaeggli <[email-masked]>
Date: Mon, 07 Apr 2014 09:55:44 -0700

On 4/7/14, 9:40 AM, Edward Lewis wrote:
> This charter seems to fly in the fase of the traditional IETF charter
> style, wherein a WG was deemed to have a set end point.

that's not entirely uncommon in ops charters. for better or worse
operations (of dns, ipv6, multicast, global routing etc)  doesn't just
end when a working group as cleared it current milestones.

---

From: S Moonesamy <[email-masked]>
Date: Tue, 08 Apr 2014 02:54:17 -0700

Hi Ed,
At 09:40 07-04-2014, Edward Lewis wrote:
>This charter seems to fly in the fase of the 
>traditional IETF charter style, wherein a WG was 
>deemed to have a set end point.  “Develop 
>guidelines”, “publish documents” and “serve as a 
>clearinghouse” are terms that engender more 
>activity but don’t indicate progress.  (A long 
>time ago, in a government job, I was taught 
>terms that guaranteed one would never fail a 
>performance review - like “participate in” and 
>so on.  The terms here fall into the same category.)

:-)

>… item 4 and item 5
>
>This is kind of like saying that one of my 
>duties is “show up for work.”  Isn’t #4 just 
>saying the WG should act as WG?  “Protocol 
>maintenance” might just mean adding DNSSEC key 
>algorithm numbers or it might mean a new zone 
>transfer protocol.  The latter is something I 
>wouldn’t think this group is wanting to take on.
>
>(I had written that for 4, but then I saw 5 gave 
>me the same impression.  In the sense I do see 4 
>and 5 are different, if I have the same 
>reaction, they are two general to be “good” 
>charter items unless the goal is to have a never ending WG.)

Item 4 ("extensions or protocol maintenance") 
allows the working group to improve DNS.  I am 
not sure whether that covers DNSSEC.  It is like have a mini-DNSng. :-)

Regards,
S. Moonesamy