Re: [DNSOP] New Draft Charter

[Dean Anderson <[e-mail]>]

So root and gTLD DNS server operations supervision is off the charter?  
It used to be the first item.  This appears to affect ISOC IETF
commitments to ICANN to provide this technical role.

I'm not certain I'm against that--I just want to clarify that this isn't
an oversight.

1. Define the processes by which Domain Name System (DNS) software
      may be efficiently and correctly administered, configured, and
      operated on Internet networks. This will include root zone
      name servers, gTLD name servers, name servers for other DNS
      zones, iterative DNS resolvers, and recursive DNS resolvers.
      As part of this effort, the group will produce documents
      explaining to the general Internet community what processes
      and mechanisms should be employed for the effective management
      and operation of DNS software. 


		--Dean

On Tue, 11 Mar 2008, Peter Koch wrote:

> Dear WG,
> 
> after several attempts, here is the most recent version of the new DNSOP
> charter to be discussed in tomorrow's WG session:
> 
> -----------------------------------------------------------------------------
> 
> The DNS Operations (DNSOP) Working Group will develop and review guidelines
> for the correct,From [e-mail]  Tue Mar 11 07:41:10 2008
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 19F663A6D78;
	Tue, 11 Mar 2008 07:41:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.518
X-Spam-Level: 
X-Spam-Status: No, score=-101.518 tagged_above=-999 required=5
	tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451,
	HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id ubUsL4Gh0oVO; Tue, 11 Mar 2008 07:41:09 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id C726E3A6E0A;
	Tue, 11 Mar 2008 07:40:49 -0700 (PDT)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id EDD5D3A69C4
	for <[e-mail]>; Tue, 11 Mar 2008 07:40:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id yZA15wmq+hqE for <[e-mail]>;
	Tue, 11 Mar 2008 07:40:44 -0700 (PDT)
Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66])
	by core3.amsl.com (Postfix) with ESMTP id 2549E28C3AA
	for <[e-mail]>; Tue, 11 Mar 2008 07:40:38 -0700 (PDT)
Received: from [130.105.12.10] ([130.105.12.10]) (authenticated bits=0)
	by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id m2BEbr3b022250
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Tue, 11 Mar 2008 10:37:57 -0400
Date: Tue, 11 Mar 2008 10:37:53 -0400 (EDT)
From: Dean Anderson <[e-mail]>
X-X-Sender: [e-mail]
To: Peter Koch <[e-mail]>
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Cc: IETF DNSOP WG <[e-mail]>
Subject: Re: [DNSOP] New Draft Charter
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/dnsop>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,
	<mailto:[e-mail]?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]

So root and gTLD DNS server operations supervision is off the charter?  
It used to be the first item.  This appears to affect ISOC IETF
commitments to ICANN to provide this technical role.

I'm not certain I'm against that--I just want to clarify that this isn't
an oversight.

1. Define the processes by which Domain Name System (DNS) software
      may be efficiently and correctly administered, configured, and
      operated on Internet networks. This will include root zone
      name servers, gTLD name servers, name servers for other DNS
      zones, iterative DNS resolvers, and recursive DNS resolvers.
      As part of this effort, the group will produce documents
      explaining to the general Internet community what processes
      and mechanisms should be employed for the effective management
      and operation of DNS software. 


		--Dean

On Tue, 11 Mar 2008, Peter Koch wrote:

> Dear WG,
> 
> after several attempts, here is the most recent version of the new DNSOP
> charter to be discussed in tomorrow's WG session:
> 
> -----------------------------------------------------------------------------
> 
> The DNS Operations (DNSOP) 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 (default)
> 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) investigate and identify requirements of DNSSEC to the lower layers,
>    both transport and network
> 4) develop or review operational guidelines that address the specifics of
>    IPv4/v6 coexistence and transition
> 
> 5) review the use of existing DNS frameworks (SRV, DDDS) in other protocols,
>    especially focussing on operational consequences and scalability, most
>    importantly when these frameworks are used in other wg's protocol proposals.
> 
> 6) develop and review guidelines for resolver (stub and full) behaviour,
>    including search path and timing issues as well as query strategies.
> 
> 7) establish terminology and methodology for performance measurements
>    of servers, resolvers or the service as such.
> 
> 8) identify the requirements for a name server configuration and control
>    protocol.
> 
> To avoid overlap with the DNS Extensions working group, the DNSOP group
> will not change the on the wire behaviour of the DNS.  Terminology issues
> will, where appropriate, be addressed in coordination with DNSEXT.
> 
> -----------------------------------------------------------------------------
> 
> This version is expected to take into account the feedback given on the list
> and during the WG meetings in and after 2006 as well as recent additions
> to the set of active work items.
> 
> -Peter
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
> 
> 

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


_______________________________________________
DNSOP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsop


 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 (default)
> 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) investigate and identify requirements of DNSSEC to the lower layers,
>    both transport and network
> 4) develop or review operational guidelines that address the specifics of
>    IPv4/v6 coexistence and transition
> 
> 5) review the use of existing DNS frameworks (SRV, DDDS) in other protocols,
>    especially focussing on operational consequences and scalability, most
>    importantly when these frameworks are used in other wg's protocol proposals.
> 
> 6) develop and review guidelines for resolver (stub and full) behaviour,
>    including search path and timing issues as well as query strategies.
> 
> 7) establish terminology and methodology for performance measurements
>    of servers, resolvers or the service as such.
> 
> 8) identify the requirements for a name server configuration and control
>    protocol.
> 
> To avoid overlap with the DNS Extensions working group, the DNSOP group
> will not change the on the wire behaviour of the DNS.  Terminology issues
> will, where appropriate, be addressed in coordination with DNSEXT.
> 
> -----------------------------------------------------------------------------
> 
> This version is expected to take into account the feedback given on the list
> and during the WG meetings in and after 2006 as well as recent additions
> to the set of active work items.
> 
> -Peter
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
> 
> 

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


_______________________________________________
DNSOP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsop