Subject: [dnsop] DRAFT new charter

From: Peter Koch <[email-masked]>
Date: Tue, 21 Mar 2006 01:22:03 +0100

Dear WG,

as you might have seen on the agenda for tomorrow's meeting we'd like to
discuss the rechartering of the dnsop WG. This is a text for the general
mission statement, slightly adjusting the focus:

-----------------------------------------------------------------------------

The DNS Operations Working Group will develop and review guidelines for the
correct, efficient and secure configuration of DNS authoritative servers,
resolvers, and DNSSEC validators. Target audiences for those guidelines
are zone administrators as well as software developers who provide tools
for DNS zone administration or server/resolver/validator configuration.

The group will perform the following activities:

1) develop or review guidelines for chosing zone configuration
   parameters that affect inter-server or server-resolver communication,
   including but not limited to SOA RR parameters, TTL values, and glue
   information

2) develop or review guidelines for any DNSSEC specific operational
   parameters, such as key length or key validity periods

3) develop or review operational guidelines that address the specifics of
   IPv4/v6 coexistence and transition

4) review the use of existing DNS frameworks (SRV, DDDS) in other protocols,
   especially focussing on operational consequences and scalability

-----------------------------------------------------------------------------

The old charter can be found at <http://www.ietf.org/html.charters/dnsop-charter.html>

Please send comments to this list, during tomorrows session or on jabber
<[email-masked]> 2120-2320 UTC. We'll have to talk about
milestones.

-Peter
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Edward Lewis <[email-masked]>
Date: Tue, 21 Mar 2006 16:03:57 -0600

>    especially focussing on operational consequences and scalability

I would consider two other areas:

5) Resolver
6) Performance

5 - "Resolver": search approach, configuration, timing, treatment of 
certain kinds of messages.  "Resolver" meaning: iterating server, 
stub, cache, forward, etc.

6 - Performance: derive a recommended way to establish performance 
requirements and/or measurement of a server "constellation."  Include 
consideration of anycast clouds, etc.

The descriptions of each area are fuzzy here in an attempt to get 
some brain-storming on this.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Nothin' more exciting than going to the printer to watch the toner drain...
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Kenji Rikitake <[email-masked]>
Date: Sun, 26 Mar 2006 18:56:19 +0900

In the message <[email-masked]>
dated Tue, Mar 21, 2006 at 01:21:40AM +0100,
>    parameters, such as key length or key validity periods

Please include:
a) Requirement of DNSSEC to the lower-layer transports such as UDP or TCP,
   or even IPv4 and IPv6
b) How a) should be satisfied on the real-world Internet environment

I know I'm getting too late, but I think it's much better than saying
nothing.

// Kenji Rikitake
.

---

From: Peter Koch <[email-masked]>
Date: Mon, 27 Mar 2006 23:38:29 +0200

Ed,

> stub, cache, forward, etc.

that's covered in the general introductory text - and as discussed in Dallas
we'd need some terminology clarification to start with. I'd like to hear
more opinions on whether we should explicitly have a "high level work package"
like this:

5) {numbers likely to change}
   develop and review guidelines for resolver (stub and full) behaviour,
   including search path and timing issues as well as query strategies.

   (A document actually saying that 'recursive servers' ==
    'iterative resolvers' SHOULD issue queries with RD==0 only would fall
    into this basket, as would probably anything around RFC1535bis)

> consideration of anycast clouds, etc.

6) establish terminology and methodology for performance measurements
   of servers, resolvers or the service as such.

   ('CNNP' comes to mind)

> some brain-storming on this.

Text change suggestions are welcome. Thanks, Ed.

-Peter
.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 27 Mar 2006 17:36:11 -0500

I'd add that two or more of the drafts discussed in the meeting last 
week support 5 & 6 -

    6.1) Measurements on DNSSEC Validation Performance
	http://www3.ietf.org/proceedings/06mar/slides/dnsop-0.pdf
	[Jakob Schlyter][10 min][16:40]

    6.2) "Open Resolvers"
	[chairs or volunteer][15 min][16:50]

In addition to...

>     into this basket, as would probably anything around RFC1535bis)

Oh, terminology, better yey, DNS terminology.  ;)  Such a work item 
could be justification to keep a WG around long enough to set an 
all-time longevity ecord.  But I'd admire the effort.

This area could cover items like root-hints file management and 
distribution, etc.  Not that this is a burning issue, but, that and 
other resolver configuration topics.

>    of servers, resolvers or the service as such.

Yes, that I had in mind.  Plus the one up above by Jakob.  And others 
may be there, I'm sure.