Subject: [dns-dir] DNS Directorate Conf Call
From: Peter Koch <[email-masked]>
To: IETF DNS Directorate <[email-masked]>
Date: Mon, 2 Mar 2009 02:17:38 +0100
List-Id: IETF DNS directorate discussion list <dns-dir.ietf.org>

Dear DNS Directorate members,

last month we skipped the conf call and deferred to the beginning of March to
prepare for the upcoming San Francisco IETF.
With apologies for the short notice I'd now like to send this invitation for a
call on
		Monday, 2 March, 1500 UTC.

We are going to use the conf call infrastructure provided by Nominet, Roy
will add the details (number/toll free numbers) later.

Here is a preliminary agenda, additions welcome:

o agenda bashing, roll call

o open reviews

  - "Vouch By Reference"
  - Infrastructure ENUM

o review of the review process

o areas of interest for IETF 74

  - v4/v6 co-existence

o face to face meeting in San Francisco

o A.O.B.

Best regards,
   Peter

From: Roy Arends <[email-masked]>
To: IETF DNS Directorate <[email-masked]>
Date: Mon, 2 Mar 2009 09:10:18 +0100
Subject: [dns-dir] Call Information. DNS Directorate Conf Call

These are the call logistics for the conf call today at 1500 UTC

US (east)  +1 7183541169
US (west)  +1 4089616553
NL +31 202013852
UK +44 2078193600
FR +33 171230055
SE +46 858536827
CA 18667425608
FI +358 969379595
DE +49 6950070811

Conference Code:     4227104

Kind regards,

Roy Arends

Note: I'll be present to initiate the call, but since I ricked my back  
last week, I might not be able to sit it all through. I have to lay  
flat.

On Mar 2, 2009, at 2:17 AM, Peter Koch wrote:

> Dear DNS Directorate members,
>
> last month we skipped the conf call and deferred to the beginning of  
> March to
> prepare for the upcoming San Francisco IETF.
> With apologies for the short notice I'd now like to send this  
> invitation for a
> call on
> 		Monday, 2 March, 1500 UTC.
>
> We are going to use the conf call infrastructure provided by  
> Nominet, Roy
> will add the details (number/toll free numbers) later.
>
> Here is a preliminary agenda, additions welcome:
>
> o agenda bashing, roll call
>
> o open reviews
>
>  - "Vouch By Reference"
>  - Infrastructure ENUM
>
> o review of the review process
>
> o areas of interest for IETF 74
>
>  - v4/v6 co-existence
>
> o face to face meeting in San Francisco
>
> o A.O.B.
>
> Best regards,
>   Peter
> _______________________________________________
> dns-dir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-dir
>

Content-class: urn:content-classes:message
Date: Mon, 2 Mar 2009 10:27:14 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Roy Arends" <[email-masked]>, "IETF DNS Directorate" <[email-masked]>
Subject: Re: [dns-dir] Call Information. DNS Directorate Conf Call

1500 UTC is 10AM EST  I guess. Ron and me have a WG status call
scheduled at this time that will preempt us from attending the DNS-DIR
call.=20

Dan
=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Roy Arends
> Sent: Monday, March 02, 2009 10:10 AM
> To: IETF DNS Directorate
> Subject: [dns-dir] Call Information. DNS Directorate Conf Call
>=20
> These are the call logistics for the conf call today at 1500 UTC
>=20
> US (east)  +1 7183541169
> US (west)  +1 4089616553
> NL +31 202013852
> UK +44 2078193600
> FR +33 171230055
> SE +46 858536827
> CA 18667425608
> FI +358 969379595
> DE +49 6950070811
>=20
> Conference Code:     4227104
>=20
> Kind regards,
>=20
> Roy Arends
>=20
> Note: I'll be present to initiate the call, but since I=20
> ricked my back last week, I might not be able to sit it all=20
> through. I have to lay flat.
>=20
> On Mar 2, 2009, at 2:17 AM, Peter Koch wrote:
>=20
> > Dear DNS Directorate members,
> >
> > last month we skipped the conf call and deferred to the=20
> beginning of=20
> > March to prepare for the upcoming San Francisco IETF.
> > With apologies for the short notice I'd now like to send this=20
> > invitation for a call on
> > 		Monday, 2 March, 1500 UTC.
> >
> > We are going to use the conf call infrastructure provided=20
> by Nominet,=20
> > Roy will add the details (number/toll free numbers) later.
> >
> > Here is a preliminary agenda, additions welcome:
> >
> > o agenda bashing, roll call
> >
> > o open reviews
> >
> >  - "Vouch By Reference"
> >  - Infrastructure ENUM
> >
> > o review of the review process
> >
> > o areas of interest for IETF 74
> >
> >  - v4/v6 co-existence
> >
> > o face to face meeting in San Francisco
> >
> > o A.O.B.
> >
> > Best regards,
> >   Peter
> > _______________________________________________
> > dns-dir mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dns-dir
> >
>=20
> _______________________________________________
> dns-dir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-dir
>=20

From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
To: Roy Arends <[email-masked]>
Date: Mon, 2 Mar 2009 15:07:16 +0100
Cc: IETF DNS Directorate <[email-masked]>
Subject: Re: [dns-dir] Call Information. DNS Directorate Conf Call

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-141--2401446
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

I will be in a meeting with the IT Minister in Sweden and will not be  
able to participate.

    Patrik

On 2 mar 2009, at 09.10, Roy Arends wrote:

> These are the call logistics for the conf call today at 1500 UTC
>
> US (east)  +1 7183541169
> US (west)  +1 4089616553
> NL +31 202013852
> UK +44 2078193600
> FR +33 171230055
> SE +46 858536827
> CA 18667425608
> FI +358 969379595
> DE +49 6950070811
>
> Conference Code:     4227104
>
> Kind regards,
>
> Roy Arends
>
> Note: I'll be present to initiate the call, but since I ricked my  
> back last week, I might not be able to sit it all through. I have to  
> lay flat.
>
> On Mar 2, 2009, at 2:17 AM, Peter Koch wrote:
>
>> Dear DNS Directorate members,
>>
>> last month we skipped the conf call and deferred to the beginning  
>> of March to
>> prepare for the upcoming San Francisco IETF.
>> With apologies for the short notice I'd now like to send this  
>> invitation for a
>> call on
>> 		Monday, 2 March, 1500 UTC.
>>
>> We are going to use the conf call infrastructure provided by  
>> Nominet, Roy
>> will add the details (number/toll free numbers) later.
>>
>> Here is a preliminary agenda, additions welcome:
>>
>> o agenda bashing, roll call
>>
>> o open reviews
>>
>> - "Vouch By Reference"
>> - Infrastructure ENUM
>>
>> o review of the review process
>>
>> o areas of interest for IETF 74
>>
>> - v4/v6 co-existence
>>
>> o face to face meeting in San Francisco
>>
>> o A.O.B.
>>
>> Best regards,
>>  Peter
>> _______________________________________________
>> dns-dir mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dns-dir
>>
>
> _______________________________________________
> dns-dir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-dir

--Apple-Mail-141--2401446
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

--Apple-Mail-141--2401446--

From [email-masked]  Thu Mar  5 23:23:11 2009
Content-class: urn:content-classes:message
Date: Fri, 6 Mar 2009 08:23:29 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>, "MIB Doctors (E-mail)" <[email-masked]>, <[email-masked]>, "IETF DNS Directorate" <[email-masked]>
Subject: [dns-dir] FW: PRELIMINARY Agenda and Package for March 12, 2009 Telechat

Please find below the preliminary agenda of the 3/12 IESG telechat.
Please send me you comments and concerns before 3/11 COB.=20

Thanks and Regards,

Dan
=20

2. Protocol Actions
	Reviews should focus on these questions: "Is this document a
	reasonable basis on which to build the salient part of the
Internet
	infrastructure? If not, what changes would make it so?"

2.1 WG Submissions
2.1.1 New Item
  o draft-ietf-behave-turn-13.txt
    Traversal Using Relays around NAT (TURN): Relay Extensions to
Session

    Traversal Utilities for NAT (STUN) (Proposed Standard) - 1 of 9=20
    Token: Magnus Westerlund
  o draft-ietf-avt-rtp-uemclip-04.txt
    RTP payload format for mU-law EMbedded Codec for Low-delay IP
communication=20
    (UEMCLIP) speech codec (Proposed Standard) - 2 of 9=20
    Note: The document shepherd is Roni Even.=20
    Token: Cullen Jennings
  o draft-ietf-btns-connection-latching-08.txt
    IPsec Channels: Connection Latching (Proposed Standard) - 3 of 9=20
    Token: Tim Polk
  o draft-ietf-softwire-security-requirements-06.txt
    Softwire Security Analysis and Requirements (Proposed Standard) - 4
of
9=20
    Token: Mark Townsley
  o draft-ietf-netconf-tls-07.txt
    NETCONF Over Transport Layer Security (TLS) (Proposed Standard) - 5
of
9=20
    Note: Mehmet Ersue is the PROTO-shepherd=20
    Token: Dan Romascanu
  o draft-ietf-ntp-ntpv4-proto-11.txt
    Network Time Protocol Version 4 Protocol And Algorithms
Specification

    (Proposed Standard) - 6 of 9=20
    Token: Mark Townsley
  o draft-ietf-ntp-ntpv4-mib-05.txt
    Definitions of Managed Objects for Network Time Protocol Version 4
(NTPv4)=20
    (Proposed Standard) - 7 of 9=20
    Token: Mark Townsley
  o draft-ietf-lemonade-profile-bis-12.txt
    The Lemonade Profile (Proposed Standard) - 8 of 9=20
    Note: Glenn Parsons is the Document Shepherd=20
    Token: Chris Newman
  o draft-ietf-netlmm-pmipv6-heartbeat-05.txt
    Heartbeat Mechanism for Proxy Mobile IPv6 (Proposed Standard) - 9 of
9
=20
    Token: Jari Arkko

2.1.2 Returning Item
  o draft-ietf-usefor-usepro-14.txt
    Netnews Architecture and Protocols (Proposed Standard) - 1 of 1=20
    Token: Lisa Dusseault

2.2 Individual Submissions
2.2.1 New Item
  o draft-farrel-rtg-common-bnf-08.txt
    Reduced Backus-Naur Form (RBNF) A Syntax Used in Various Protocol=20
    Specifications (Proposed Standard) - 1 of 2=20
    Token: Ross Callon
  o draft-gulbrandsen-imap-response-codes-07.txt
    IMAP Response Codes (Proposed Standard) - 2 of 2=20
    Note: Alexey Melnikov is document shepherd=20
    Token: Chris Newman

2.2.2 Returning Item
NONE

3. Document Actions

3.1 WG Submissions
	Reviews should focus on these questions: "Is this document a
reasonable
	contribution to the area of Internet engineering which it
covers? If
	not, what changes would make it so?"

3.1.1 New Item
NONE
3.1.2 Returning Item
NONE

3.2 Individual Submissions Via AD
	Reviews should focus on these questions: "Is this document a
reasonable
	contribution to the area of Internet engineering which it
covers? If
	not, what changes would make it so?"

3.2.1 New Item
  o draft-jones-dime-3gpp-eps-command-codes-01.txt
    Diameter Command Code Registration for Third Generation Partnership
Project=20
    (3GPP) Evolved Packet System (EPS) (Informational) - 1 of 1=20
    Note: IETF LC ends on 3/5. A new revised I-D will be available
immediatly=20
    after the Last Call.=20
    Token: Dan Romascanu

3.2.2 Returning Item
NONE
3.3 Independent Submissions Via RFC Editor
	The IESG will use RFC 3932 responses: 1) The IESG has not
	found any conflict between this document and IETF work; 2) The
	IESG thinks that this work is related to IETF work done in WG
	<X>, but this does not prevent publishing; 3) The IESG thinks
	that publication is harmful to work in WG <X> and recommends
	not publishing at this time; 4) The IESG thinks that this
	document violates the IETF procedures for <X> and should
	therefore not be published without IETF review and IESG
	approval; 5) The IESG thinks that this document extends an
	IETF protocol in a way that requires IETF review and should
	therefore not be published without IETF review and IESG
approval.

	The document shepherd must propose one of these responses in
	the Data Tracker note and supply complete text in the IESG
	Note portion of the write-up. The Area Director ballot positions
	indicate consensus with the response proposed by the
	document shepherd.

	Other matters may be recorded in comments, and the comments will
	be passed on to the RFC Editor as community review of the
document.

3.3.1 New Item
NONE
3.3.2 Returning Item
NONE

4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
  o Locator/ID Separation Protocol (lisp) - 1 of 3
    Token: Jari Arkko
  o Session Initiation Protocol Core (sipcore) - 2 of 3
    Token: Cullen Jennings=20
  o Dispatch (dispatch) - 3 of 3
    Token: Cullen Jennings
4.1.2 Proposed for Approval
    NONE
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
    NONE
4.2.2 Proposed for Approval
  o Network File System Version 4 (nfsv4) - 1 of 3
    Token: Lars Eggert
  o Ad-Hoc Network Autoconfiguration (autoconf) - 2 of 3
    Token: Jari Arkko
  o Routing Over Low power and Lossy networks (roll) - 3 of 3
    Token: David Ward

From [email-masked]  Fri Mar  6 06:00:29 2009
Date: Fri, 06 Mar 2009 08:58:13 -0500
To: "IETF DNS Directorate" <[email-masked]>
From: Olafur Gudmundsson <[email-masked]>
Subject: Re: [dns-dir] FW: PRELIMINARY Agenda and Package for March 12, 2009 Telechat

--=====================_514119114==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 02:23 06/03/2009, Romascanu, Dan (Dan) wrote:

>   o draft-ietf-ntp-ntpv4-mib-05.txt
>     Definitions of Managed Objects for Network Time Protocol Version 4
>(NTPv4)
>     (Proposed Standard) - 7 of 9
>     Token: Mark Townsley

This one is in the DNS early warning DB, it is a false alarm due to
their variables being called srvNot........

         Olafur
PS: sorry about the bulk update of early warning documents, this was due to
perl upgrade problem on my system.

--=====================_514119114==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
<font size=3>At 02:23 06/03/2009, Romascanu, Dan (Dan) wrote:<br><br>
<br>
<blockquote type=cite class=cite cite="">&nbsp; o
draft-ietf-ntp-ntpv4-mib-05.txt<br>
&nbsp;&nbsp;&nbsp; Definitions of Managed Objects for Network Time
Protocol Version 4<br>
(NTPv4) <br>
&nbsp;&nbsp;&nbsp; (Proposed Standard) - 7 of 9 <br>
&nbsp;&nbsp;&nbsp; Token: Mark Townsley</blockquote><br>
This one is in the DNS early warning DB, it is a false alarm due to <br>
their variables being called srvNot........ <br><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Olafur<br>
PS: sorry about the bulk update of early warning documents, this was due
to <br>
perl upgrade problem on my system. <br>
</font></body>
</html>

--=====================_514119114==.ALT--

From [email-masked]  Fri Mar  6 07:41:48 2009
To: [email-masked]
From: Olafur_DNS_EARLY_WARNING <[email-masked]>
Date: Fri, 6 Mar 2009 10:42:17 -0500
Subject: [dns-dir] DNS Early Warn: draft-thomson-geopriv-res-gw-lis-discovery-00.txt

Count:       42 

GEOPRIV                                                       M. Thomson
Internet-Draft                                        Andrew Corporation
Intended status: Informational                         February 12, 2009
Expires: August 16, 2009

  Location Information Server (LIS) Discovery From Behind Residential
                                Gateways
             draft-thomson-geopriv-res-gw-lis-discovery-00

 Abstract
   The residential gateway is an ubiquitous device that has become an

   integral part of home networking equipment.  Discovering a Location
   Information Server (LIS) is a necessary part of aquiring location
   information for location-based services.  However, discovering a LIS
   when a residential gateway is present poses a configuration
   challenge, requiring a method that is able to work around the
   obstacle presented by the gateway.

   This document describes the problem of discovering a LIS in the
   presence of a residential gateway.  The current version includes two
   proposed solutions to this problem, which will be evaluated.

From [email-masked]  Fri Mar  6 07:41:49 2009
To: [email-masked]
From: Olafur_DNS_EARLY_WARNING <[email-masked]>
Date: Fri, 6 Mar 2009 10:42:18 -0500
Subject: [dns-dir] DNS Early Warn: draft-morris-dnsop-dnssec-key-timing-00.txt

Count:       59 

Internet Engineering Task Force                                S. Morris
Internet-Draft                                                   Nominet
Intended status: Informational                                  J. Ihren
Expires: August 21, 2009                                      Autonomica
                                                            J. Dickinson
                                                       February 17, 2009

                    DNSSEC Key Timing Considerations
              draft-morris-dnsop-dnssec-key-timing-00.txt

 Abstract
   RFC 4641 gives a detailed overview of the operational considerations
   involved in running a DNSSEC-secured zone, including key rollovers.
   This document expands on the previous work, and discusses timing
   considerations in greater depth.  It explicitly identifies the
   relationships between the various time parameters, and gives a
   suggested algorithm for key rollover in a DNSSEC-secured zone.

From [email-masked]  Fri Mar  6 07:54:14 2009
To: [email-masked]
From: Olafur_DNS_EARLY_WARNING <[email-masked]>
Date: Fri, 6 Mar 2009 10:42:31 -0500
Subject: [dns-dir] DNS Early Warn: draft-ietf-nfsv4-rfc1831bis-13.txt

Count:       22 

Network File System Version 4 Working Group                   R. Thurlow
Internet-Draft                                          Sun Microsystems
Intended status: Draft Standard
Obsoletes: 1831
Expires: September 5, 2009                               March 5, 2009

      RPC: Remote Procedure Call Protocol Specification Version 2
                   draft-ietf-nfsv4-rfc1831bis-13.txt

 Abstract
   This document describes the ONC (Open Network Computing) Remote
   Procedure Call (ONC RPC Version 2) protocol as it is currently
   deployed and accepted.  This document obsoletes [RFC1831].

From [email-masked]  Fri Mar  6 07:54:15 2009
To: [email-masked]
From: Olafur_DNS_EARLY_WARNING <[email-masked]>
Date: Fri, 6 Mar 2009 10:42:25 -0500
Subject: [dns-dir] DNS Early Warn: draft-vesely-vhlo-00.txt

Count:       23 

Network Working Group                                          A. Vesely
Internet-Draft                                             March 1, 2009
Intended status: Standards Track
Expires: September 2, 2009

                     Verified-Hello SMTP extension
                          draft-vesely-vhlo-00

 Abstract
   This memo defines an extension to the SMTP service whereby an SMTP
   client can know beforehand the reputation and whitelisting treatment
   for the messages that it is about to transmit.  By formalizing the

   trust that the receiving part grants to the sending one, using the
   VHLO command a sender recovers reliability at the expenses of
   flexibility.

From [email-masked]  Fri Mar  6 07:54:15 2009
To: [email-masked]
From: Olafur_DNS_EARLY_WARNING <[email-masked]>
Date: Fri, 6 Mar 2009 10:42:24 -0500
Subject: [dns-dir] DNS Early Warn: draft-winter-dynamic-discovery-00.txt

Count:       37 

RADIUS Extensions Working Group                                S. Winter
Internet-Draft                                                   RESTENA
Intended status: Experimental                                M. McCauley
Expires: August 31, 2009                                             OSC
                                                       February 27, 2009

     NAI-based Dynamic Peer Discovery for RADIUS over TLS and DTLS
                   draft-winter-dynamic-discovery-00

 Abstract
   This document specifies a means to find authoritative AAA servers for
   a given NAI realm.  It can be used in conjunction with RADIUS over
   TLS and RADIUS over DTLS.

From [email-masked]  Fri Mar  6 07:54:16 2009
To: [email-masked]
From: Olafur_DNS_EARLY_WARNING <[email-masked]>
Date: Fri, 6 Mar 2009 10:42:24 -0500
Subject: [dns-dir] DNS Early Warn: draft-wood-tae-specifying-uri-transports-04.txt

Count:       13 

Network Working Group                                            L. Wood
Internet-Draft                                             Cisco Systems
Intended status: Experimental                          February 27, 2009
Expires: August 31, 2009

   Specifying transport mechanisms for retrieval or delivery of URIs
              draft-wood-tae-specifying-uri-transports-04

 Abstract
   This document describes a simple extension of the URI format that
   allows preferred transport mechanisms, including protocols, ports and
   interfaces, to be specified as parseable additions to the scheme

   name.  This explicit configuration is beneficial for separation of
   HTTP from underlying transports, which has been increasingly
   recognised as useful when a variety of ways of transporting or
   configuring use of HTTP are available and a choice of mechanism to
   use must be indicated.

From [email-masked]  Fri Mar  6 07:54:17 2009
To: [email-masked]
From: Olafur_DNS_EARLY_WARNING <[email-masked]>
Date: Fri, 6 Mar 2009 10:42:25 -0500
Subject: [dns-dir] DNS Early Warn: draft-ietf-dnsop-rfc4641bis-00.txt

Count:      216 

DNSOP                                                         O. Kolkman
Internet-Draft                                                NLnet Labs
Obsoletes: 2541 (if approved)                                  R. Gieben
Intended status: BCP
Expires: September 3, 2009                                 March 2, 2009

                      DNSSEC Operational Practices
                     draft-ietf-dnsop-rfc4641bis-00

 Abstract
   This document describes a set of practices for operating the DNS with
   security extensions (DNSSEC).  The target audience is zone
   administrators deploying DNSSEC.

   The document discusses operational aspects of using keys and
   signatures in the DNS.  It discusses issues of key generation, key
   storage, signature generation, key rollover, and related policies.

   This document obsoletes RFC 2541, as it covers more operational
   ground and gives more up-to-date requirements with respect to key
   sizes and the new DNSSEC specification.

From [email-masked]  Fri Mar  6 07:54:18 2009
To: [email-masked]
From: Olafur_DNS_EARLY_WARNING <[email-masked]>
Date: Fri, 6 Mar 2009 10:42:27 -0500
Subject: [dns-dir] DNS Early Warn: draft-wang-alto-discovery-00.txt

Count:       36 ALTO WG                                                       G. Garcia 
Internet Draft                                           Telefonica I+D 
Intended status: Informational                                 M. Tomsu 
Expires: September 2009                        Alcatel-Lucent Bell Labs 
                                                                Y. Wang 
                                                              Microsoft 
                                                          March 3, 2009 

                         ALTO Discovery Protocols 
                     draft-wang-alto-discovery-00.txt 

 Abstract 

   The Application-Layer Traffic Optimization service aims to provide 
   applications with information to perform better-than-random initial 
   peer selection when multiple peers in the network are available to 
   provide a resource or service. This document discusses the discovery 
   protocols for the service. 

From [email-masked]  Fri Mar  6 07:54:19 2009
To: [email-masked]
From: Olafur_DNS_EARLY_WARNING <[email-masked]>
Date: Fri, 6 Mar 2009 10:42:32 -0500
Subject: [dns-dir] DNS Early Warn: draft-montenegro-mif-multihoming-00.txt

Count:       38 Network Working Group                                 G. Montenegro 
Internet Draft                                            D. Thaler 
Intended status: Informational                       Shyam Seshadri 
                                              Microsoft Corporation 
Expires: September 4, 2009                            March 4, 2009 

                     Multiple Interfaces on Windows 
                  draft-montenegro-mif-multihoming-00 

 Abstract 
   Increasingly, hosts have more than one network interface active 
   at any given point in time. Such multiplicity of interfaces 
   leads to multiple and potentially conflicting (or overlapping) 
   sets of configuration information and policies. How these are 
   arbitrated and managed influence how the host resolves DNS 
   queries, and-with respect to outgoing packets-how it selects a 
   source address and an outgoing interface.  

From [email-masked]  Fri Mar  6 07:54:20 2009
To: [email-masked]
From: Olafur_DNS_EARLY_WARNING <[email-masked]>
Date: Fri, 6 Mar 2009 10:42:28 -0500
Subject: [dns-dir] DNS Early Warn: draft-mrw-mif-current-practices-00.txt

Count:       14 

Internet Engineering Task Force                        M. Wasserman, Ed.
Internet-Draft                                     Sandstorm Enterprises
Intended status: Informational                             T. Savolainen
Expires: September 5, 2009                                         Nokia
                                                             M. Blanchet
                                                                Viagenie
                                                           March 4, 2009

             Current Practices for Multiple Interface Hosts
                   draft-mrw-mif-current-practices-00

 Abstract
   An increasing number of hosts are operating in multiple-interface
   environments, where different network interfaces are providing
   unequal levels of service or connectivity.  This document describes
   how some common operating systems cope with the related challenges.

From [email-masked]  Fri Mar  6 07:54:20 2009
To: [email-masked]
From: Olafur_DNS_EARLY_WARNING <[email-masked]>
Date: Fri, 6 Mar 2009 10:42:32 -0500
Subject: [dns-dir] DNS Early Warn: draft-frejborg-hipv4-01.txt

Count:       11 Network Working Group                                 Patrick Frejborg 
Internet Draft                                              Consultant 
Intended status: Experimental                            March 5, 2009 
Expires: September 2009 

                        Hierarchical IPv4 Framework 
                        draft-frejborg-hipv4-01.txt 

    Abstract 
   This draft describes a framework how the current IPv4 address 
   structure can be extended towards a similar hierarchical numbering 
   structure as used in the Public Switched Telephone Network and bring 
   hierarchy to the routing architecture of Internet. The framework 
   requires extensions to the existing Domain Name System architecture, 
   the existing IPv4 stack of the end systems (hosts) and to routers in 
   the Internet. The framework can be implemented incrementally to the 
   hosts, databases, routers and for some applications that transport  
   IPv4 addresses in their payload. 

From [email-masked]  Fri Mar  6 07:54:21 2009
To: [email-masked]
From: Olafur_DNS_EARLY_WARNING <[email-masked]>
Date: Fri, 6 Mar 2009 10:42:25 -0500
Subject: [dns-dir] DNS Early Warn: draft-yang-mif-req-00.txt

Count:       11 

Network Working Group                                            P. Yang
Internet-Draft                                  Hitachi (China) R&D Corp
Intended status: Standards Track                                P. Seite
Expires: August 31, 2009                                  France Telecom
                                                             C. Williams
                                                                  J. Qin
                                                                     ZTE
                                                       February 27, 2009

         Requirements on multiple Interface (MIF) of simple IP
                         draft-yang-mif-req-00

 Abstract
   This draft makes a summary on the requirements of supporting multiple
   interfaces (MIF) in hosts with simple IP.  These requirements result
   from examining scenarios for multiple interface host usages.  The
   differentiation between MIF and other related IETF works are
   interpreted as well.

From [email-masked]  Fri Mar  6 07:54:21 2009
To: [email-masked]
From: Olafur_DNS_EARLY_WARNING <[email-masked]>
Date: Fri, 6 Mar 2009 10:42:30 -0500
Subject: [dns-dir] DNS Early Warn: draft-malas-enum-trunk-sip-00.txt

Count:       28 

ENUM                                                       D. Malas, Ed.
Internet-Draft                                                 CableLabs
Intended status: Informational                              T. Creighton
Expires: September 5, 2009                                       Comcast
                                                           March 4, 2009

                        Trunk Group Use in ENUM
                     draft-malas-enum-trunk-sip-00

 Abstract
   This document concludes that incorporating trunk group parameters
   into an Electronic Number (ENUM) response for the Session Initiation

   Protocol (SIP) [RFC3261] service URI is a more effective approach
   compared to defining a new ENUM service type for a 'trunk'.  Upon
   further review of the existing ENUM trunk group draft
   [I-D.ietf-enum-trunkgroup] and practical operator experience, this
   draft recommends the use of the current trunk group contexts as
   defined in [RFC4904] as additional parameters in the E2U+SIP
   enumservice NAPTR record [RFC3403] URI.

From [email-masked]  Fri Mar  6 07:54:22 2009
To: [email-masked]
From: Olafur_DNS_EARLY_WARNING <[email-masked]>
Date: Fri, 6 Mar 2009 10:42:19 -0500
Subject: [dns-dir] DNS Early Warn: draft-savolainen-mif-dns-server-selection-00.txt

Count:      113 

Internet Engineering Task Force                            T. Savolainen
Internet-Draft                                                     Nokia
Intended status: Informational                         February 19, 2009
Expires: August 23, 2009

               DNS Server Selection on Multi-Homed Hosts
              draft-savolainen-mif-dns-server-selection-00

 Abstract
   A multi-homed host may receive DNS server configuration information
   from multiple physical and/or virtual network interfaces.  In split

   DNS scenarios not all DNS servers are able to provide the same
   information.  When the multi-homed host needs to utilize DNS, it has
   to select which of the servers to contact to.  This document
   describes problems of split DNS for multi-homed hosts and also a
   method for selecting the DNS server with help of DNS suffix
   information received dynamically for each network interface.  The
   method is useful in split DNS scenarios where private names are used
   and where correct DNS server selection is mandatory for successful
   DNS resolution.

From [email-masked]  Fri Mar  6 07:54:22 2009
To: [email-masked]
From: Olafur_DNS_EARLY_WARNING <[email-masked]>
Date: Fri, 6 Mar 2009 10:42:28 -0500
Subject: [dns-dir] DNS Early Warn: draft-xu-rangi-proxy-00.txt

Count:       24 Network Working Group                                        Xiaohu Xu 
Internet Draft                                                  Huawei 
Intended status: Informational                                Raj Jain 
Expires: September 2009                  Washington Univ. in St. Louis 
                                                         March 4, 2009 

                        A Transition Mechanism for  
       Routing Architecture for the Next Generation Internet (RANGI) 
                        draft-xu-rangi-proxy-00.txt 

 Abstract 
   The Routing Architecture for the Next Generation Internet (RANGI) is 
   a proposal for solving routing scalability, mobility, multihoming, 

   traffic engineering and other issues facing the current Internet. 
   RANGI is described in a separate document [RANGI]. This document 
   describes a transition mechanism for RANGI. With this mechanism, 
   legacy IPv4 or IPv6 hosts can communicate with RANGI hosts, and vice 
   versa. This allows RANGI to be deployed incrementally in the current 
   Internet. 

From [email-masked]  Fri Mar  6 07:54:23 2009
To: [email-masked]
From: Olafur_DNS_EARLY_WARNING <[email-masked]>
Date: Fri, 6 Mar 2009 10:42:29 -0500
Subject: [dns-dir] DNS Early Warn: draft-song-alto-server-discovery-00.txt

Count:       42 

ALTO                                                        H. Song, Ed.
Internet-Draft                                                    Huawei
Intended status: Standards Track                                 R. Even
Expires: September 3, 2009                                  Gesher Erove
                                                              V. Pascual
                                                                 Tekelec
                                                                Y. Zhang
                                                            China Mobile
                                                           March 2, 2009

  Application-Layer Traffic Optimization (ALTO): Discover ALTO Servers
                  draft-song-alto-server-discovery-00

 Abstract
   A set of mechanisms are required to discover an Application-Layer
   Traffic Optimization (ALTO) Server.  These mechanisms enable
   applications to find a reliable information source which provides
   them with information regarding the underlying network.  By providing
   this information it would be possible to greatly increase application
   performance, reduce congestion and optimize the overall traffic
   across different networks.  This document specifies the use of
   general means such as DHCP, DNS or static configuration for ALTO
   server discovery.

From [email-masked]  Fri Mar  6 07:54:24 2009
To: [email-masked]
From: Olafur_DNS_EARLY_WARNING <[email-masked]>
Date: Fri, 6 Mar 2009 10:42:30 -0500
Subject: [dns-dir] DNS Early Warn: draft-vyncke-vdv-v6ops-conf-stats-00.txt

Count:       12 

v6ops Working Group                                      G. Van de Velde
Internet-Draft                                                 E. Vyncke
Intended status: Informational                             Cisco Systems
Expires: September 5, 2009                                 March 4, 2009

             IPv6 Deployment and Statistics at a Conference
               <draft-vyncke-vdv-v6ops-conf-stats-00.txt>

 Abstract
   During the Cisco [Cisco] European networkers Conference 2009 that ran
   from 26th to 29th January in Barcelona native IPv6 was added to the
   traditional IPv4 infrastructure.  During this conference the 3500
   attendees had dual stack access to both IPv4 and IPv6 simultaneously.
   The goal of this IPv6 deployment project was to gather usage
   statistics in a situation where the end-user just wants to access
   his/her enterprise VPN or simply get onto the Internet.  The
   collected statistics are not only useful per se but this document
   presents easy ways to measure the quality of the IPv6 connectivity
   offered on such events.  In essence the users were not conducting
   IPv6 technology tests, but were just using Internet services.  The
   statistics collected give some pieces of information on the size and
   impact of IPv6 onto the normal userbase and will also derive the
   importance of IPv6 onto the infrastructiure and end-user operating
   systems and firewall technologies.  The experiment ran in
   collaboration with Google [Google] and Tata-Communications [Tata].

From [email-masked]  Fri Mar  6 07:54:24 2009
To: [email-masked]
From: Olafur_DNS_EARLY_WARNING <[email-masked]>
Date: Fri, 6 Mar 2009 10:42:18 -0500
Subject: [dns-dir] DNS Early Warn: draft-otis-auth-header-appeal-00.txt

Count:       11 

Individual                                                       D. Otis
Internet-Draft                                                   D. Rand
Intended status: Informational                         Trend Micro, NSSG
Expires: August 20, 2009                               February 16, 2009

               Authentication-Results Header Field Appeal
                    draft-otis-auth-header-appeal-00

 Abstract
   The proposed [I-D.kucherawy-sender-auth-header] defines a header
   field used to capture email verification results obtained at border

   receptions has been approved for publication.  However, serious
   deficiencies remain in its secure use and has prompted an appeal of
   the publication decision.  This new header field is to convey to Mail
   User Agents (MUA) and downstream processes the verification results
   that are intended to augment handling decisions and message
   annotations that might be made visible to recipients.  For such use,
   it is crucial to include within an "authenticated-results" header, a
   truly authenticated identity.

   The draft acknowledges that it confuses authorization with
   authentication in section 1.5.2.  This confusion has lead the draft
   to incorrectly elevate the authorization of an SMTP client into the
   authentication of an email-address domain.  Elevating the
   *authorization* of the SMTP client into the *authentication* of an
   email-address domain incorrectly assumes current email practices
   adequately restrict the use of an email-address domain based upon the
   originating IP address of the SMTP client.  In an era of carrier
   grade NATs, virtual servers, aggregated services, and other
   techniques that overload the IP address, this assumption is neither
   safe nor practical.

   Although the draft explicitly declares Sender-ID and SPF as the
   authorization of the transmitting SMTP client, it fails to offer the
   authenticated identity being trusted.  A truly authenticated identity
   is essential for reputation assessments which section 4.1 indicates
   should be made prior to results being revealed.  A reputation check
   of a truly authenticated identifier is often a necessary step needed
   to mitigate fraud and abuse.  In addition, it is unfair to attribute
   fraud or abuse to the unauthenticated identifiers.  Even so, the
   header offers no assurance that any reputation check has been made,
   nor does it ensure that an authenticated identity, the IP address of
   the SMTP client, can be determined by the MUA or downstream process.
   The goal of the appeal is to ensure adequate information is available
   when annotating email.

From [email-masked]  Fri Mar  6 11:02:51 2009
Date: Fri, 6 Mar 2009 14:03:17 -0500
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: [dns-dir] IDNA, mapping, case folding, and need for review

Dear colleagues,

A new thread has cropped up about mapping names in IDNA, and I think
it'd be very helpful if some participants in this group had a look and
offered some reactions.

I'm going to try to offer some summary first, in case you haven't been
following this; if you want to skip to the specific thing I think
needs reaction, scroll down to the ===Proposal needs review=== section
below.  

===Background===

Consider the example of the character Eszett, ß.  In IDNA2003, ß is
always mapped to ss right at the beginning of all the transformations.
If we are to remove all mappings from the protocol, this won't be
allowed.  But we now have the problem that (for example) fussball.tld
might be registered somewhere.  Currently, when a user types in
"fußball.tld", it resolves to "fussball.tld".  If all the mappings are
removed from the protocol, then "fußball.tld" will not resolve to
"fussball.tld" unless the zone operator of .tld takes some steps to
make these equivalent.  The "making these equivalent" is usually
called either "bundling" or "variants" (or both).  They usually follow
something along the lines of the JET Guidelines, RFC 3743, and for our
purposes boil down to "DNAME for everything", which isn't too bad in
the case of Eszett but is quite complicated for, say, Greek final form
sigma.  It also turns out to be problematic even for French, because
some people think Ecole and école are the same word, and others think
École and école are the same word (and not the same as Ecole).  And,
as you can see, we have just opened a can of worms around how to match
cases: since we have this new case-matching problem, we suddenly
appear to be having an explosion of DNAMEs in any IDN-offering zone.
This will make things tricky at least.

This gets worse because of mixed-script possibilities, such as (e.g.)
Latin capital A and Greek capital Alpha, which is completely
indistinguishable from Latin capital A except at the codepoint level
(that is, competent human readers can't usually tell whether they're
looking at a "Latin letter" or a "Greek letter", even though in many
fonts they can tell easily when it's lower case).

If you got this far, you might be thinking that the IDNA2008 goal of
"no mapping whatsoever" is looking a little unrealistic.  Yes.

===Proposal needs review===

In order to get around this, in the thread starting at
http://www.alvestrand.no/pipermail/idna-update/2009-March/003751.html
Erik van der Poel suggests that we "get users used" to the idea of
user lower case only in the DNS, and do some tricks to force the idea
(his actual message is at
http://www.alvestrand.no/pipermail/idna-update/2009-March/003753.html,
but the one above is some background from Klensin).  I initially
reacted that this is contrary to RFC 1034, but the more I think about
it the less convinced I am.  The idea is that IDNA applications can
downcase everything _before anything else happens_, so that we never
have upper case confusions within the protocol at least.  Similarly,
any "IDNA-aware domain name slot" -- basically, wherever an IDNA-aware
application might display a domain name -- is restricted to lower case
and always displays in lower case even if you type upper case.

This will not cause any problems for "plain" DNS names -- everything
on the wire just automatically ends up in lower case (modulo whatever
the resolver does as part of that 0x20 trickiness), and is case folded
back down by the application when it comes back.  Therefore, from the
point of view of DNS, it's just an operational convention without any
real protocol implications.

However, it _feels_ wrong to me from the DNS point of view.  Still, it
looks like this trick is a way that might allow IDNA2008 to make some
progress, and it does not, as far as I can tell, actually violate any
DNS rules.  Therefore, I'm prepared to get over my feelings and
support this idea.

If you have feedback, I'd be interested to hear it.  If you have
something to say about it on the idna-bis list, that'd be even better,
since certain freshly (re?)minted members of the IAB are making
pointed remarks about the lack of input from the DNS community.

Thanks,

A

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

From [email-masked]  Sat Mar  7 05:45:33 2009
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
To: Andrew Sullivan <[email-masked]>
Date: Sat, 7 Mar 2009 14:46:01 +0100
Cc: [email-masked]
Subject: Re: [dns-dir] IDNA, mapping, case folding, and need for review

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-2-428323529
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

On 6 mar 2009, at 20.03, Andrew Sullivan wrote:

> If you got this far, you might be thinking that the IDNA2008 goal of
> "no mapping whatsoever" is looking a little unrealistic.  Yes.

That is NOT a goal for IDNA2008. That we need mapping specifications  
have been clear from day one.

The difference though is that the mappings are not part of the spec of  
"what goes into the DNS", and we have had as a rule that we MUST have  
a clear separation between "what the user think she can use" and "what  
goes into the DNS".

There have been at least one proposal for how to do mappings  
circulated in the wg, but the author of that document has so far (the  
last three years) not created an I-D out of it.

> ===Proposal needs review===
>
> In order to get around this, in the thread starting at
> http://www.alvestrand.no/pipermail/idna-update/2009-March/003751.html
> Erik van der Poel suggests that we "get users used" to the idea of
> user lower case only in the DNS, and do some tricks to force the idea
> (his actual message is at
> http://www.alvestrand.no/pipermail/idna-update/2009-March/003753.html,
> but the one above is some background from Klensin).  I initially
> reacted that this is contrary to RFC 1034, but the more I think about
> it the less convinced I am.  The idea is that IDNA applications can
> downcase everything _before anything else happens_, so that we never
> have upper case confusions within the protocol at least.  Similarly,
> any "IDNA-aware domain name slot" -- basically, wherever an IDNA-aware
> application might display a domain name -- is restricted to lower case
> and always displays in lower case even if you type upper case.

I think the whole problem with case sensitivity and insensitivity is  
blown up out of proportions. We have file systems that have different  
case folding rules, and the world seems to have survived.

The important thing is still that we must define what goes into the  
DNS. How the applications actually handle things is something that  
will be different between applications. Just like filenames, URLs,  
telephone numbers etc.

> This will not cause any problems for "plain" DNS names -- everything
> on the wire just automatically ends up in lower case (modulo whatever
> the resolver does as part of that 0x20 trickiness), and is case folded
> back down by the application when it comes back.  Therefore, from the
> point of view of DNS, it's just an operational convention without any
> real protocol implications.

DNS should not know about it. DNS has nothing to do with what the  
application does.

> However, it _feels_ wrong to me from the DNS point of view.  Still, it
> looks like this trick is a way that might allow IDNA2008 to make some
> progress, and it does not, as far as I can tell, actually violate any
> DNS rules.  Therefore, I'm prepared to get over my feelings and
> support this idea.

I think you and I are on the same page. "The DNS" should have  
absolutely nothing to do with this. What they talk about is a  
standardized behaviour for clients.

> If you have feedback, I'd be interested to hear it.  If you have
> something to say about it on the idna-bis list, that'd be even better,
> since certain freshly (re?)minted members of the IAB are making
> pointed remarks about the lack of input from the DNS community.

Some of us wait until there are some proposals that really can fly. :-)

    Patrik

--Apple-Mail-2-428323529
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

--Apple-Mail-2-428323529--

From [email-masked]  Sat Mar  7 11:29:31 2009
To: [email-masked]
From: Olafur_DNS_EARLY_WARNING <[email-masked]>
Date: Sat, 7 Mar 2009 14:30:01 -0500
Subject: [dns-dir] DNS Early Warn: draft-martinotti-mpls-tp-interworking-01.txt

Count:       13 

Internet Engineering Task Force                            R. Martinotti
Internet-Draft                                               D. Caviglia
Intended status: Informational                                  Ericsson
Expires: September 6, 2009                                   N. Sprecher
                                                  Nokia Siemens Networks
                                                         A. D'Alessandro
                                                              A. Capello
                                                          Telecom Italia
                                                           March 5, 2009

                Interworking between MPLS-TP and IP/MPLS
                draft-martinotti-mpls-tp-interworking-01

 Abstract
   Purpose of this ID is to illustrate interworking scenarios between
   network(s) supporting MPLS-TP and network(s) supporting IP/MPLS.
   Main interworking issues and open points are highlighted.

From [email-masked]  Sun Mar  8 11:29:30 2009
To: [email-masked]
From: Olafur_DNS_EARLY_WARNING <[email-masked]>
Date: Sun, 8 Mar 2009 14:30:01 -0400
Subject: [dns-dir] DNS Early Warn: draft-bagnulo-behave-dns64-02.txt

Count:      216 

BEHAVE WG                                                     M. Bagnulo
Internet-Draft                                                      UC3M
Intended status: Standards Track                             A. Sullivan
Expires: September 8, 2009                                      Shinkuro
                                                             P. Matthews
                                                          Alcatel-Lucent
                                                          I. van Beijnum
                                                          IMDEA Networks
                                                                 M. Endo
                                           Yokogawa Electric Corporation
                                                           March 7, 2009

DNS64: DNS extensions for Network Address Translation from IPv6 Clients
                            to IPv4 Servers
                     draft-bagnulo-behave-dns64-02

 Abstract
   DNS64 is a mechanism for synthesizing AAAA records from A records.
   DNS64 is used with NAT64, an IPv6 IPv4 translator to enable client-
   server communication between an IPv6-only client and an IPv4-only
   server, without requiring any changes to either the IPv6 or the IPv4
   node, for the class of applications that work through NATs.  This
   document specifies DNS64, and provides suggestions on how it should
   be deployed in conjunction with NAT64.

From [email-masked]  Mon Mar  9 11:29:29 2009
To: [email-masked]
From: Olafur_DNS_EARLY_WARNING <[email-masked]>
Date: Mon, 9 Mar 2009 14:30:01 -0400
Subject: [dns-dir] DNS Early Warn: draft-ietf-vcarddav-carddav-06.txt

Count:       13 

Network Working Group                                           C. Daboo
Internet-Draft                                                     Apple
Intended status: Standards Track                           March 9, 2009
Expires: September 10, 2009

                  vCard Extensions to WebDAV (CardDAV)
                     draft-ietf-vcarddav-carddav-06

 Abstract
   This document defines extensions to the Web Distributed Authoring and
   Versioning (WebDAV) protocol to specify a standard way of accessing,
   managing, and sharing contact information based on the vCard format.

From [email-masked]  Mon Mar  9 11:59:25 2009
To: [email-masked]
From: Olafur_DNS_EARLY_WARNING <[email-masked]>
Date: Mon, 9 Mar 2009 14:30:02 -0400
Subject: [dns-dir] DNS Early Warn: draft-ietf-behave-nat-behavior-discovery-06.txt

Count:       14 

BEHAVE                                                    D.C. MacDonald
Internet-Draft                               CounterPath Solutions, Inc.
Intended status: Experimental                             B. B. Lowekamp
Expires: September 10, 2009                                    MYMIC LLC
                                                           March 9, 2009

                   NAT Behavior Discovery Using STUN
              draft-ietf-behave-nat-behavior-discovery-06

 Abstract
   This specification defines an experimental usage of the Simple
   Traversal Underneath Network Address Translators (NAT) (STUN)
   Protocol that discovers the presence and current behaviour of NATs
   and firewalls between the STUN client and the STUN server.

From [email-masked]  Wed Mar 11 04:27:16 2009
Content-class: urn:content-classes:message
Date: Wed, 11 Mar 2009 12:27:26 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Andrew Sullivan" <[email-masked]>
Cc: Arvel Hathcock <[email-masked]>, John Levine <[email-masked]>, Russ Housley <[email-masked]>, [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [dns-dir] Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt

I am clearing my DISCUSS. Following the discussions in DNS-DIR and in
the IESG it became clear that the issue of the TXT records is the kind
of disagreement that will not be solved by blocking this document.

Dan
=20

> -----Original Message-----
> From: Andrew Sullivan [mailto:[email-masked]]=20
> Sent: Tuesday, February 17, 2009 4:52 PM
> To: Romascanu, Dan (Dan)
> Cc: Paul Hoffman; Arvel Hathcock; Russ Housley;=20
> [email-masked]; John Levine
> Subject: Re: [dns-dir] Removing your DISCUSS on=20
> draft-hoffman-dac-vbr-05.txt
>=20
> On Mon, Feb 16, 2009 at 12:26:49PM +0100, Romascanu, Dan (Dan) wrote:
> > My question is whether there is any change in text that=20
> would improve=20
> > or better document the current status.
>=20
> I doubt it.  I'm unhappy to say that we passed, some time=20
> ago, the point where it's even possible to discuss whether=20
> TXT records are a good idea for this use-case.  I preduct any=20
> attempt even to address the topic will result in unresolvable=20
> differences of opinion.
>=20
> A
>=20
> --
> Andrew Sullivan
> [email-masked]
> Shinkuro, Inc.
>=20

From [email-masked]  Wed Mar 11 07:37:28 2009
Date: Wed, 11 Mar 2009 07:37:41 -0700
To: "Romascanu, Dan (Dan)" <[email-masked]>, "Andrew Sullivan" <[email-masked]>
From: Paul Hoffman <[email-masked]>
Cc: Arvel Hathcock <[email-masked]>, Russ Housley <[email-masked]>, [email-masked], John Levine <[email-masked]>
Subject: Re: [dns-dir] Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt

At 12:27 PM +0100 3/11/09, Romascanu, Dan (Dan) wrote:
>I am clearing my DISCUSS. Following the discussions in DNS-DIR and in
>the IESG it became clear that the issue of the TXT records is the kind
>of disagreement that will not be solved by blocking this document.

Thanks! If the DNS Directorate wants to disagree with the protocol authors about acceptable protocol style, doing so after IETF Last Call is not the best time for that. Having a technical debate about how a protocol is using the DNS is fine even in the late stages, of course, but this one seemed to be only about style, not technical problems.

On a separate note, please consider making the DNS Directorate archive publicly visible, similar to the Security Directorate archive, so that authors impacted by the directorate reviews can engage more effectively. As we said in our earlier messages, we were quite happy to talk about this, but didn't even know what was being said.

--Paul Hoffman, Director
--Domain Assurance Council

From [email-masked]  Wed Mar 11 07:46:20 2009
Date: Wed, 11 Mar 2009 10:44:12 -0400
To: Paul Hoffman <[email-masked]>, "Romascanu, Dan (Dan)" <[email-masked]>, "Andrew Sullivan" <[email-masked]>
From: Russ Housley <[email-masked]>
Cc: Arvel Hathcock <[email-masked]>, [email-masked], John Levine <[email-masked]>
Subject: Re: [dns-dir] Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt

Paul:

> >I am clearing my DISCUSS. Following the discussions in DNS-DIR and in
> >the IESG it became clear that the issue of the TXT records is the kind
> >of disagreement that will not be solved by blocking this document.
>
>Thanks! If the DNS Directorate wants to disagree with the protocol 
>authors about acceptable protocol style, doing so after IETF Last 
>Call is not the best time for that. Having a technical debate about 
>how a protocol is using the DNS is fine even in the late stages, of 
>course, but this one seemed to be only about style, not technical problems.

This is an unfair criticism.  This document is an individual 
standards-track submission.  The IETF Last Call on such a document 
can be the first time that a wide audience is aware of it.

Russ 

From [email-masked]  Wed Mar 11 08:29:08 2009
Date: Wed, 11 Mar 2009 11:29:41 -0400
From: Andrew Sullivan <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: Arvel Hathcock <[email-masked]>, Russ Housley <[email-masked]>, [email-masked], John Levine <[email-masked]>
Subject: Re: [dns-dir] Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt

On Wed, Mar 11, 2009 at 08:06:22AM -0700, Paul Hoffman wrote:

> If our protocol had a technical problem with the use of TXT records,
> we would have been happy to hear about it even in IESG review. We
> have no problem with the DNS Directorate commenting on the document;
> we even nudged one member about it well before IETF Last Call. The
> issue I bring up above is about being delayed for a stylistic
> preference, one that we could not actively engage in discussion with
> the DNS Directorate about.

To be clear, not all of us think that specifying the syntax of a
particular TXT record, or even specifying behaviour based on a TXT
record, is merely a stylistic preference.  Some of us think that this
is fundamentally broken behaviour, because it is less reliable than
using a new RRTYPE --  DNS data is typed, and avoiding problems
arising from collisions of two records at the same RNAME using the
same type for different purposes is _why_ it is typed.

I nevertheless think we have to be realistic in the face of protocols
that are sort-of-working using the TXT record.  I do find it amusing
that I now hear people moaning about the nasty side effects to DKIM of
TXT records, but the horse has left the barn, the ship has sailed, &c
&c.

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

From [email-masked]  Wed Mar 11 09:46:42 2009
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
To: Andrew Sullivan <[email-masked]>
Date: Wed, 11 Mar 2009 17:47:13 +0100
Cc: Arvel Hathcock <[email-masked]>, John Levine <[email-masked]>, Russ Housley <[email-masked]>, [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [dns-dir] Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-138-784796286
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

On 11 mar 2009, at 16.29, Andrew Sullivan wrote:

> Some of us think that this
> is fundamentally broken behaviour, because it is less reliable than
> using a new RRTYPE --  DNS data is typed, and avoiding problems
> arising from collisions of two records at the same RNAME using the
> same type for different purposes is _why_ it is typed.

And, btw, let me just point out that you can NOT guarantee that you  
can choose the RNAME of your records. Some of the records must have  
the same RNAME as other records, and if the RNAME, TYPE and CLASS is  
the same...well...there are definitely some side effects.

There will be an IAB document out shortly, at last, about this.

In short, reusing TXT is very bad.

    Patrik

--Apple-Mail-138-784796286
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

--Apple-Mail-138-784796286--

From [email-masked]  Wed Mar 11 10:01:44 2009
Date: Wed, 11 Mar 2009 13:02:17 -0400
From: Andrew Sullivan <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: Arvel Hathcock <[email-masked]>, Russ Housley <[email-masked]>, [email-masked], John Levine <[email-masked]>
Subject: Re: [dns-dir] Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt

On Wed, Mar 11, 2009 at 09:54:56AM -0700, Paul Hoffman wrote:
> 
> For the record, none of the authors of VBR have ever heard of such
> nasty side effects; if we had, we would have designed VBR
> differently. Without any indication of what those were, or even who
> spoke when you were hearing it, we can't reply.

To be clear so that people don't think I'm some sort of FUD font,
these were hallway conversations to which I replied, basically, that
the expressed worries were indeed the sort of thing DNS weenies
think are a problem, and then promptly forgot about.  I don't even
recall who it was -- I was amused, after all, not bothered.  I don't
believe the world will end if TXT records get used this way (although
the more it happens, the more I think there's a liklihood of a
problem).

A

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

From [email-masked]  Wed Mar 11 11:35:20 2009
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
To: IETF DNS Directorate <[email-masked]>
Date: Wed, 11 Mar 2009 19:35:25 +0100
Cc: Arvel Hathcock <[email-masked]>, Russ Housley <[email-masked]>, Paul Hoffman <[email-masked]>, John Levine <[email-masked]>
Subject: Re: [dns-dir] Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-144-791287773
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable

On 11 mar 2009, at 17.47, Patrik F=E4ltstr=F6m wrote:

> On 11 mar 2009, at 16.29, Andrew Sullivan wrote:
>
>> Some of us think that this
>> is fundamentally broken behaviour, because it is less reliable than
>> using a new RRTYPE --  DNS data is typed, and avoiding problems
>> arising from collisions of two records at the same RNAME using the
>> same type for different purposes is _why_ it is typed.
>
> And, btw, let me just point out that you can NOT guarantee that you =20=

> can choose the RNAME of your records. Some of the records must have =20=

> the same RNAME as other records, and if the RNAME, TYPE and CLASS is =20=

> the same...well...there are definitely some side effects.
>
> There will be an IAB document out shortly, at last, about this.
>
> In short, reusing TXT is very bad.

s/RNAME/OWNER/

Of course...

Sorrryyyyy...

    Patrik

--Apple-Mail-144-791287773
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

--Apple-Mail-144-791287773--

From [email-masked]  Wed Mar 11 12:00:23 2009
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
To: "John R. Levine" <[email-masked]>
Date: Wed, 11 Mar 2009 20:00:42 +0100
Cc: Arvel Hathcock <[email-masked]>, Russ Housley <[email-masked]>, [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [dns-dir] Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-146-792805248
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

On 11 mar 2009, at 19.37, John R. Levine wrote:

>> And, btw, let me just point out that you can NOT guarantee that you  
>> can choose the RNAME of your records. Some of the records must have  
>> the same RNAME as other records, and if the RNAME, TYPE and CLASS  
>> is the same...well...there are definitely some side effects.
>
> Well, in fairness, VBR and DKIM do use _vouch and _domainkey labels  
> which should keep out any explicit overlap with other stuff.  I  
> agree that wildcards don't play well here.

I did write the wrong thing, and intended to write OWNER and not RNAME.

As you know there are RRTYPES that by default have to have the same  
owner as other records. Just look at DNSSEC.

So it is not so easy to say "there is no overlap". If some DNSSEC  
records also used prefix and TXT records, instead of new RRTYPES, then  
it would be bad. Right?

    paf

--Apple-Mail-146-792805248
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

--Apple-Mail-146-792805248--

From [email-masked]  Wed Mar 11 08:06:55 2009
Date: Wed, 11 Mar 2009 08:06:22 -0700
To: Russ Housley <[email-masked]>, "Romascanu, Dan (Dan)" <[email-masked]>, "Andrew Sullivan" <[email-masked]>
From: Paul Hoffman <[email-masked]>
Cc: Arvel Hathcock <[email-masked]>, [email-masked], John Levine <[email-masked]>
Subject: Re: [dns-dir] Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt

At 10:44 AM -0400 3/11/09, Russ Housley wrote:
>Paul:
>
>> >I am clearing my DISCUSS. Following the discussions in DNS-DIR and in
>>>the IESG it became clear that the issue of the TXT records is the kind
>>>of disagreement that will not be solved by blocking this document.
>>
>>Thanks! If the DNS Directorate wants to disagree with the protocol authors about acceptable protocol style, doing so after IETF Last Call is not the best time for that. Having a technical debate about how a protocol is using the DNS is fine even in the late stages, of course, but this one seemed to be only about style, not technical problems.
>
>This is an unfair criticism.  This document is an individual standards-track submission.  The IETF Last Call on such a document can be the first time that a wide audience is aware of it.

If our protocol had a technical problem with the use of TXT records, we would have been happy to hear about it even in IESG review. We have no problem with the DNS Directorate commenting on the document; we even nudged one member about it well before IETF Last Call. The issue I bring up above is about being delayed for a stylistic preference, one that we could not actively engage in discussion with the DNS Directorate about.

--Paul Hoffman, Director
--Domain Assurance Council

From [email-masked]  Wed Mar 11 09:54:45 2009
Date: Wed, 11 Mar 2009 09:54:56 -0700
To: Andrew Sullivan <[email-masked]>
From: Paul Hoffman <[email-masked]>
Cc: Arvel Hathcock <[email-masked]>, Russ Housley <[email-masked]>, [email-masked], John Levine <[email-masked]>
Subject: Re: [dns-dir] Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt

At 11:29 AM -0400 3/11/09, Andrew Sullivan wrote:
>I nevertheless think we have to be realistic in the face of protocols
>that are sort-of-working using the TXT record. 

Thank you.

>I do find it amusing
>that I now hear people moaning about the nasty side effects to DKIM of
>TXT records, but the horse has left the barn, the ship has sailed, &c
>&c.

For the record, none of the authors of VBR have ever heard of such nasty side effects; if we had, we would have designed VBR differently. Without any indication of what those were, or even who spoke when you were hearing it, we can't reply.

--Paul Hoffman, Director
--Domain Assurance Council

From [email-masked]  Wed Mar 11 11:36:48 2009
Date: Wed, 11 Mar 2009 18:37:20 +0000 (GMT)
From: "John R. Levine" <[email-masked]>
To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
Cleverness: None detected
Cc: Arvel Hathcock <[email-masked]>, Russ Housley <[email-masked]>, [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [dns-dir] Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt

> And, btw, let me just point out that you can NOT guarantee that you can 
> choose the RNAME of your records. Some of the records must have the same 
> RNAME as other records, and if the RNAME, TYPE and CLASS is the 
> same...well...there are definitely some side effects.

Well, in fairness, VBR and DKIM do use _vouch and _domainkey labels which 
should keep out any explicit overlap with other stuff.  I agree that 
wildcards don't play well here.

R's,
John

From [email-masked]  Thu Mar 12 08:45:37 2009
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
To: "John R. Levine" <[email-masked]>
Date: Thu, 12 Mar 2009 16:45:41 +0100
Cc: Arvel Hathcock <[email-masked]>, Russ Housley <[email-masked]>, [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [dns-dir] Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-166-867504163
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

On 11 mar 2009, at 19.37, John R. Levine wrote:

>> And, btw, let me just point out that you can NOT guarantee that you  
>> can choose the RNAME of your records. Some of the records must have  
>> the same RNAME as other records, and if the RNAME, TYPE and CLASS  
>> is the same...well...there are definitely some side effects.
>
> Well, in fairness, VBR and DKIM do use _vouch and _domainkey labels  
> which should keep out any explicit overlap with other stuff.  I  
> agree that wildcards don't play well here.

That is just because things that reuse owner (like DNSSEC) _so_far_  
has chosen to use different RRTYPE than TXT. If DNSSEC extension just  
like DKIM reused TXT, then it would not have worked. Just as an example.

So, what you rely on when DKIM did choose to go down the path of  
reusing TXT is that there is _no_ extension to DNS fulfil both of  
these requirements at the same time:

1. Require the same OWNER as other resource records in DNS
2. Reuse TXT (just like DKIM does)

I.e. you rely on other people creating new RR Types now when DKIM and  
VBR did not.

    Patrik

--Apple-Mail-166-867504163
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

--Apple-Mail-166-867504163--

From [email-masked]  Thu Mar 12 08:50:42 2009
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
To: Paul Hoffman <[email-masked]>
Date: Thu, 12 Mar 2009 16:51:04 +0100
Cc: Russ Housley <[email-masked]>, Arvel Hathcock <[email-masked]>, John Levine <[email-masked]>, [email-masked]
Subject: Re: [dns-dir] Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-167-867826636
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

On 11 mar 2009, at 16.06, Paul Hoffman wrote:

> If our protocol had a technical problem with the use of TXT records,  
> we would have been happy to hear about it even in IESG review. We  
> have no problem with the DNS Directorate commenting on the document;  
> we even nudged one member about it well before IETF Last Call. The  
> issue I bring up above is about being delayed for a stylistic  
> preference, one that we could not actively engage in discussion with  
> the DNS Directorate about.

Reuse of TXT records is a problem that is well known, and you know it  
yourself since the DKIM discussions. And just like I brought up the  
issues in the DKIM discussions I bring it up now. You heard about it  
then, and you hear about it now.

But, just like the DKIM document(s) passed, this will probably pass as  
well, because we have no _document_ explaining why TXT is a bad  
choice. We only have DNS people telling others that "you should not  
reuse RR Types". We know from history that that is not enough.  
Obviously. As for example you and many others reuse TXT.

This is not *you* as editors of *this* document. This is a generic  
weakness of the DNS architecture in the IETF.

Because of this, I did together with Rob Austein many moons ago as IAB  
members initiate the creation of a document that talk about the  
issues, and finally last week IAB did approve the document (draft-iab- 
dns-choices-08.txt). So you will have an RFC pointing out that  
"reusing TXT records is not optimal".

And that will hopefully make discussions like these _in_the_future_  
easier.

    Patrik

--Apple-Mail-167-867826636
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

--Apple-Mail-167-867826636--

From [email-masked]  Thu Mar 12 11:03:37 2009
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
To: John Levine <[email-masked]>
Date: Thu, 12 Mar 2009 19:03:18 +0100
Cc: Paul Hoffman <[email-masked]>, Russ Housley <[email-masked]>, Arvel Hathcock <[email-masked]>, [email-masked]
Subject: Re: [dns-dir] Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-170-875760822
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

On 12 mar 2009, at 17.29, John Levine wrote:

> If you want people to take your advice, write some deployment guides  
> telling people how to add new RRs to widely used DNS server and  
> client software.  The problem is not theoretical, it's that people  
> have a not altogether unreasonable concern that if they try to use  
> new RRs, their DNS software won't work.

Part from Microsoft and other systems that use non-DNS (like LDAP) for  
some lookups and transfers of data, the problem is not today in the  
DNS systems as much as in the provisioning systems. How to handle  
unknown resource records in authoritative servers is different between  
the servers out there, but most of course require you to edit not the  
mnemonics for the RRTYPE but instead the number and data in hex (like  
in the standard config file format).

In the clients I see no problems at all as the clients have to be  
changed anyway when you bring in new features, like DKIM.

Every change to any protocol requires changes. Adding MIME to email  
took some time. Adding support for IDNA in clients will take some time  
(we have already worked on that), and of course adding support for  
DKIM in software will also take some time.

And, remember that the RFC specifying unknown resource records is from  
September 2003, RFC 3597. And already when that was written it was  
discussed in the DNS community if there *really* where any issues, and  
the conclusion was that most software out there did support it (I was  
surprised myself) *OR* it should be upgraded, like old deployment of  
Bind 4.

But, this has been discussed, and we had this discussion in the DKIM  
wg, and I will not bring it up again. You and I did not agree then,  
and I do not think we will agree now either. I accept people  
disagreeing with me. We at least agree on what we disagree on!

    Patrik

--Apple-Mail-170-875760822
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

--Apple-Mail-170-875760822--

From [email-masked]  Fri Mar 13 12:01:31 2009
Date: Fri, 13 Mar 2009 15:02:06 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: [dns-dir] Directorate and interaction with others redux

Dear colleagues,

A thing I think we need to have on our agenda for our next discussion
is the status of the DNS Directorate with respect to others --
individuals, WGs, the IETF as a whole, &c.

My previous understanding was that we were a group that simply
provided some expertise and background to ADs.  As a result, we do
not engage in formal review, or try to review every document the IETF
produces.  Rather, we provide attention to issues we think could
impinge on the DNS, and make suggestions privately.

The reason I think we need to be clearer about this is because of the
difficulty with the DISCUSS on the vouch-by-reference draft.  In the
debate over that draft, the "DNS Directorate" and the dns-dir mailing
list were both invoked more than once.  Paul Hoffman in particular has
expressed (I believe generally, as well as in rather strong terms to
me privately) frustration at being pointed to archives of a list when
he's not allowed to read such archives.  I think this situation tends
to encourage the "black helicopters" charges that occasionally rise.

I can think of three ways to resolve this:

1.  Never do that again.  If arguments have to be taken from the
dns-dir list, then the whole thread needs to be forwarded to the
person who needs to see the arguments.  More likely, the arguments in
question need to be paraphrased, and anyone engaged in such a
discussion has to be copied privately.  The obvious disadavantage to
this is that it will be confusing and will not leave a tidy record in
some list's archives.

2.  Formalise the DNS Directorate more, and add members to it so that
it becomes a "full service" directorate of the sort that the security
directorate seems to be.  I'm a little uncomfortable with this,
because I think the analogy between secdir and dns-dir is not that
strong.  Importantly, every network protocol and document probably
does have some security considerations that are relevant, even if only
indirectly.  The same is, thankfully, not true about the DNS (even if
it feels that way sometimes).  Moreover, the security directorate is
sometimes viewed by others as a frustrating roadblock on the road to
getting documents published.  I don't know we need to add more
bureaucratic hurdles to that process.

3.  Add a separate mailing list for DNS Directorate interaction with
the rest of the world.  All postings to dns-dir-pub also go to
dns-dir, so that one doesn't have to subscribe to another mailing list
(although one does have to be careful about where one posts).  The
archives for this proposed list would be open.

These ideas are obviously not exhaustive.  I just think that it'd be
nice to avoid the same problem in future while retaining the DNS
Directorate as a fairly lightweight adjuct to regular IETF processes
instead of an unofficial addition to the proesses.  And I'm keen for
us to shake any suggestion of being a DNS cabal out to thwart the
legitimate aspirations of people wanting to use the DNS.

A

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

From [email-masked]  Thu Mar 12 09:29:24 2009
Date: Thu, 12 Mar 2009 16:29:54 +0000 (GMT)
From: John Levine <[email-masked]>
To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
Cleverness: None detected
Cc: Paul Hoffman <[email-masked]>, Russ Housley <[email-masked]>, Arvel Hathcock <[email-masked]>, [email-masked]
Subject: Re: [dns-dir] Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt

> But, just like the DKIM document(s) passed, this will probably pass as well, 
> because we have no _document_ explaining why TXT is a bad choice. We only 
> have DNS people telling others that "you should not reuse RR Types".

Actually, I think we appreciate the advantages that new RRs can have over 
reusing existing types.

If you want people to take your advice, write some deployment guides 
telling people how to add new RRs to widely used DNS server and client 
software.  The problem is not theoretical, it's that people have a not 
altogether unreasonable concern that if they try to use new RRs, their DNS 
software won't work.

Regards,
John Levine, [email-masked]
The Domain Assurance Council

From [email-masked]  Sun Mar 15 04:39:13 2009
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
To: John Levine <[email-masked]>
Date: Sun, 15 Mar 2009 12:39:46 +0100
Cc: Arvel Hathcock <[email-masked]>, Russ Housley <[email-masked]>, [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [dns-dir] Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-7--1035534818
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

On 12 mar 2009, at 17.29, John Levine wrote:

> If you want people to take your advice, write some deployment guides  
> telling people how to add new RRs to widely used DNS server and  
> client software.  The problem is not theoretical, it's that people  
> have a not altogether unreasonable concern that if they try to use  
> new RRs, their DNS software won't work.

RFC 3597 explain what the format is for unknown resource records in a  
zone file. See end of section 5. Most software out there can "eat"  
such format when you load the zone from a text file. Also after  
checking support for zone transfers, as I also said earlier, I do not  
know of any software version released the last three years that do  
zone transfers that barf on unknown resource records. If they use DNS  
for the zone transfer that is. Some software use LDAP as the core  
protocol (in enterprise environments that uses Microsoft Directory for  
example, where DNS is a front end to the AD server(s)), and there of  
course there is a problem with unknown resource records.

If you have some specific software you are thinking of, let me know,  
and I will have a look at it.

The rest is a case of updating, as I said earlier, the provisioning  
software that people might use, and that is hard to help with.

    Patrik

--Apple-Mail-7--1035534818
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

--Apple-Mail-7--1035534818--

From [email-masked]  Sun Mar 15 06:35:06 2009
Date: Sun, 15 Mar 2009 13:35:40 +0000 (GMT)
From: John Levine <[email-masked]>
To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
Cleverness: None detected
Cc: Arvel Hathcock <[email-masked]>, Russ Housley <[email-masked]>, [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [dns-dir] Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt

> RFC 3597 explain what the format is for unknown resource records in a zone 
> file. See end of section 5. Most software out there can "eat" ...

People really need specific advice: e.g., for BIND, you need to update to 
at least version 8.x and then do this to publish records.  If you're using 
the server in Win 200X, be sure you're up to patch N.M and then do that. 
If you're using the client library in Ubuntu, do this to fetch records of 
type X.

I'm not saying you personally need to write this deployment guide, but I 
can tell you from experience that's the kind of thing that you need to 
keep people from saying oh, screw it, we'll use text records.  Someone who 
believes that new record types are important in practice as well as in 
theory ought to do it.

Even though DKIM uses text records, people are still writing deployment 
guides about how to create the records, what goes in them, how to manage 
them, etc.  It makes a difference.

Regards,
John Levine, [email-masked]
The Domain Assurance Council

From [email-masked]  Mon Mar 16 05:49:17 2009
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
To: John Levine <[email-masked]>
Date: Mon, 16 Mar 2009 13:49:07 +0100
Cc: Arvel Hathcock <[email-masked]>, Russ Housley <[email-masked]>, [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [dns-dir] Removing your DISCUSS on draft-hoffman-dac-vbr-05.txt

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-11--944973910
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

On 15 mar 2009, at 14.35, John Levine wrote:

>> RFC 3597 explain what the format is for unknown resource records in  
>> a zone file. See end of section 5. Most software out there can  
>> "eat" ...
>
> People really need specific advice: e.g., for BIND, you need to  
> update to at least version 8.x and then do this to publish records.   
> If you're using the server in Win 200X, be sure you're up to patch  
> N.M and then do that. If you're using the client library in Ubuntu,  
> do this to fetch records of type X.

Point taken.

Thanks for your patience John!

    Patrik

--Apple-Mail-11--944973910
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

--Apple-Mail-11--944973910--

From [email-masked]  Mon Mar 16 07:07:18 2009
Content-class: urn:content-classes:message
Date: Mon, 16 Mar 2009 15:07:54 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Andrew Sullivan" <[email-masked]>, <[email-masked]>
Subject: Re: [dns-dir] Directorate and interaction with others redux

This is a good subject for discussion in San Francisco, but maybe we
should gather some opinions on the list first.=20

I had been using the DNS-DIR input for some of my DISCUSSes and
appreciated the expertise and background. I unusually mention DNS-DIR
and the reviewers names as the source of the comments more as a matter
of fairness and recognition. When solutions are proposed to issues
originating from the DNS-DIR comments I think it's natural to get back
to the reviewer (and DNS-DIR in the majority of cases) to validate the
responses. The interaction was never so intense (in my memory I should
say) as it was with the Hoffman draft, where incidentally I took the
DISCUSS more as am Action Item in the IESG telechat.=20

My preference from the below would be 3) or something close. It could
work like this. Discussions on DNS-DIR are still being conducted as
today, but when a DISCUSS is taken the AD copies dns-dir-external rather
than dns-dir leading to further discussions to be commented on the
external list until the DISCUSS is cleared.=20

Comments? Other opinions? Other suggestions?=20

Dan
=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Andrew Sullivan
> Sent: Friday, March 13, 2009 9:02 PM
> To: [email-masked]
> Subject: [dns-dir] Directorate and interaction with others redux
>=20
> Dear colleagues,
>=20
> A thing I think we need to have on our agenda for our next=20
> discussion is the status of the DNS Directorate with respect=20
> to others -- individuals, WGs, the IETF as a whole, &c.
>=20
> My previous understanding was that we were a group that=20
> simply provided some expertise and background to ADs.  As a=20
> result, we do not engage in formal review, or try to review=20
> every document the IETF produces.  Rather, we provide=20
> attention to issues we think could impinge on the DNS, and=20
> make suggestions privately.
>=20
> The reason I think we need to be clearer about this is=20
> because of the difficulty with the DISCUSS on the=20
> vouch-by-reference draft.  In the debate over that draft, the=20
> "DNS Directorate" and the dns-dir mailing list were both=20
> invoked more than once.  Paul Hoffman in particular has=20
> expressed (I believe generally, as well as in rather strong=20
> terms to me privately) frustration at being pointed to=20
> archives of a list when he's not allowed to read such=20
> archives.  I think this situation tends to encourage the=20
> "black helicopters" charges that occasionally rise.
>=20
> I can think of three ways to resolve this:
>=20
> 1.  Never do that again.  If arguments have to be taken from=20
> the dns-dir list, then the whole thread needs to be forwarded=20
> to the person who needs to see the arguments.  More likely,=20
> the arguments in question need to be paraphrased, and anyone=20
> engaged in such a discussion has to be copied privately.  The=20
> obvious disadavantage to this is that it will be confusing=20
> and will not leave a tidy record in some list's archives.
>=20
> 2.  Formalise the DNS Directorate more, and add members to it=20
> so that it becomes a "full service" directorate of the sort=20
> that the security directorate seems to be.  I'm a little=20
> uncomfortable with this, because I think the analogy between=20
> secdir and dns-dir is not that strong.  Importantly, every=20
> network protocol and document probably does have some=20
> security considerations that are relevant, even if only=20
> indirectly.  The same is, thankfully, not true about the DNS=20
> (even if it feels that way sometimes).  Moreover, the=20
> security directorate is sometimes viewed by others as a=20
> frustrating roadblock on the road to getting documents=20
> published.  I don't know we need to add more bureaucratic=20
> hurdles to that process.
>=20
> 3.  Add a separate mailing list for DNS Directorate=20
> interaction with the rest of the world.  All postings to=20
> dns-dir-pub also go to dns-dir, so that one doesn't have to=20
> subscribe to another mailing list (although one does have to=20
> be careful about where one posts).  The archives for this=20
> proposed list would be open.
>=20
> These ideas are obviously not exhaustive.  I just think that=20
> it'd be nice to avoid the same problem in future while=20
> retaining the DNS Directorate as a fairly lightweight adjuct=20
> to regular IETF processes instead of an unofficial addition=20
> to the proesses.  And I'm keen for us to shake any suggestion=20
> of being a DNS cabal out to thwart the legitimate aspirations=20
> of people wanting to use the DNS.
>=20
> A
>=20
> --
> Andrew Sullivan
> [email-masked]
> Shinkuro, Inc.
> _______________________________________________
> dns-dir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-dir
>=20

From [email-masked]  Mon Mar 16 07:53:00 2009
Date: Mon, 16 Mar 2009 07:53:09 -0700
From: Jari Arkko <[email-masked]>
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked]
Subject: Re: [dns-dir] Directorate and interaction with others redux

I don't think this is very different from other cases where the ADs use 
someone else to help in reviews. I do that all the time, and what ends 
up happening is that I paraphrase the issue, and in many cases include 
the full reviewer comments. (It does not help to tive a reference to 
some obscure discussion that the authors can't get to.) Finally, when we 
mail the Discuss out, we have the option of adding a Cc to the reviewer.

The above description works for the single reviewer case. Most of my 
directorate reviews are from one person, but there may be situations 
where multiple people contribute or when the directorate as a whole 
needs to be involved. But I don't think situation is really different, 
again the initial mail to the author needs to be self-contained, and 
from that point onwards even the directorate list can be Cced; mail from 
people from the directorate responding to the discussion will go to the 
authors as well.

So I guess I'm saying option 1.

Jari

Andrew Sullivan wrote:
> Dear colleagues,
>
> A thing I think we need to have on our agenda for our next discussion
> is the status of the DNS Directorate with respect to others --
> individuals, WGs, the IETF as a whole, &c.
>
> My previous understanding was that we were a group that simply
> provided some expertise and background to ADs.  As a result, we do
> not engage in formal review, or try to review every document the IETF
> produces.  Rather, we provide attention to issues we think could
> impinge on the DNS, and make suggestions privately.
>
> The reason I think we need to be clearer about this is because of the
> difficulty with the DISCUSS on the vouch-by-reference draft.  In the
> debate over that draft, the "DNS Directorate" and the dns-dir mailing
> list were both invoked more than once.  Paul Hoffman in particular has
> expressed (I believe generally, as well as in rather strong terms to
> me privately) frustration at being pointed to archives of a list when
> he's not allowed to read such archives.  I think this situation tends
> to encourage the "black helicopters" charges that occasionally rise.
>
> I can think of three ways to resolve this:
>
> 1.  Never do that again.  If arguments have to be taken from the
> dns-dir list, then the whole thread needs to be forwarded to the
> person who needs to see the arguments.  More likely, the arguments in
> question need to be paraphrased, and anyone engaged in such a
> discussion has to be copied privately.  The obvious disadavantage to
> this is that it will be confusing and will not leave a tidy record in
> some list's archives.
>
> 2.  Formalise the DNS Directorate more, and add members to it so that
> it becomes a "full service" directorate of the sort that the security
> directorate seems to be.  I'm a little uncomfortable with this,
> because I think the analogy between secdir and dns-dir is not that
> strong.  Importantly, every network protocol and document probably
> does have some security considerations that are relevant, even if only
> indirectly.  The same is, thankfully, not true about the DNS (even if
> it feels that way sometimes).  Moreover, the security directorate is
> sometimes viewed by others as a frustrating roadblock on the road to
> getting documents published.  I don't know we need to add more
> bureaucratic hurdles to that process.
>
> 3.  Add a separate mailing list for DNS Directorate interaction with
> the rest of the world.  All postings to dns-dir-pub also go to
> dns-dir, so that one doesn't have to subscribe to another mailing list
> (although one does have to be careful about where one posts).  The
> archives for this proposed list would be open.
>
> These ideas are obviously not exhaustive.  I just think that it'd be
> nice to avoid the same problem in future while retaining the DNS
> Directorate as a fairly lightweight adjuct to regular IETF processes
> instead of an unofficial addition to the proesses.  And I'm keen for
> us to shake any suggestion of being a DNS cabal out to thwart the
> legitimate aspirations of people wanting to use the DNS.
>
> A
>
>   

From [email-masked]  Tue Mar 17 12:40:24 2009
Date: Tue, 17 Mar 2009 20:41:04 +0100
From: Peter Koch <[email-masked]>
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked]
Subject: Re: [dns-dir] Directorate and interaction with others redux

Andrew,

thanks for bringing this up.  The recent discussion disturbed me, as well,
and a review of assumptions is probably due.

Caveat: the DNS-DIR archives are currently publicly acessible.  This may
be a result of the secretariat having "fixed" archiving for IETF lists
a week or two ago or may have been the case for longer. To me it was a surprise.

> My previous understanding was that we were a group that simply
> provided some expertise and background to ADs.  As a result, we do
> not engage in formal review, or try to review every document the IETF
> produces.  Rather, we provide attention to issues we think could
> impinge on the DNS, and make suggestions privately.

It was at least my understanding that nobody should ever try to "speak for
the DNS directorate" unless explicitly agreed upon.  Reviews initiated here
would serve as input to AD evaluations and not per se carry more weight.

> 1.  Never do that again.  If arguments have to be taken from the
> dns-dir list, then the whole thread needs to be forwarded to the
> person who needs to see the arguments.  More likely, the arguments in

Sure. However, the genesis of a common response, if any, is probably less
important.  But this opens the question of how "we" actually arrive at
some review response.  maybe we can discuss this in San Francisco?

> 2.  Formalise the DNS Directorate more, and add members to it so that
> it becomes a "full service" directorate of the sort that the security
> directorate seems to be.  I'm a little uncomfortable with this,

... so am I, for at least an additional reason: formalization would
suggest we have some review guidelines and I'm not sure we're that far yet.

> 3.  Add a separate mailing list for DNS Directorate interaction with
> the rest of the world.  All postings to dns-dir-pub also go to
> dns-dir, so that one doesn't have to subscribe to another mailing list
> (although one does have to be careful about where one posts).  The
> archives for this proposed list would be open.

To avoid confusion, I'd slightly prefer (1) over this.

> instead of an unofficial addition to the proesses.  And I'm keen for
> us to shake any suggestion of being a DNS cabal out to thwart the
> legitimate aspirations of people wanting to use the DNS.

Whatever this cabal would have been up to, at least in recent cases it doesn't
seem to have been overly successful ...
But I agree the output should be somehow deterministic (to the extent that
different people see different things, but have a common ground and
vision w.r.t. the DNS).

-Peter

From [email-masked]  Wed Mar 18 04:24:07 2009
Content-class: urn:content-classes:message
Date: Wed, 18 Mar 2009 12:24:19 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, "MIB Doctors (E-mail)" <[email-masked]>
Subject: [dns-dir] FW: [New-work] WG Review: Locator/ID Separation Protocol (lisp)

=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of IESG Secretary
Sent: Wednesday, March 18, 2009 2:38 AM
To: [email-masked]
Subject: [New-work] WG Review: Locator/ID Separation Protocol (lisp)

A new IETF working group has been proposed in the Routing Area.  The
IESG has not made any determination as yet.  The following draft charter
was submitted, and is provided for informational purposes only.  Please
send your comments to the IESG mailing list ([email-masked]) by Tuesday,
March 24, 2009.

Locator/ID Separation Protocol (lisp)
--------------------------------------------------
Last Modified: 2009-03-12

Current status: Proposed Working Group

Chair(s):
TBD

Internet Area Director(s):
TBD

Routing Area Advisor:
TBD

Mailing Lists:
General Discussion: https://www.ietf.org/mailman/listinfo/lisp

Description of Working Group:

The IAB's October 2006 workshop on Routing and Addressing Workshop (RFC
4984) rekindled interest in scalable routing and addressing
architectures for the Internet. Among the many issues driving this
renewed interest are concerns about the scalability of the routing
system and the impending exhaustion of the IPv4 address space. Since the
IAB workshop, several proposals have emerged which attempt to address
the concerns expressed there and elsewhere. In general, these proposals
are based on the "Locator/Identifier separation".

The basic idea behind the separation that the Internet architecture
combines two functions, Routing Locators, or RLOCs (where you are
attached to the network) and Endpoint Identifiers, or EIDs (who you are)
in one number space: The IP address. Proponents of the separation
architecture postulate that splitting these functions apart will yield
several advantages, including improved scalability for the routing
system.
The separation aims to decouple location and identity, thus allowing for
efficient aggregation of the RLOC space and providing persistent
identity in the EID space.

LISP supports the separation of the Internet address space into Endpoint
Identifiers and Routing Locators following a network-based map-and-encap
scheme (RFC 1955). It employs EIDs that represent a mixture of locators
and identifiers; it could also be classified as a multi-level locator
scheme.  A number of other approaches are being looked at in parallel in
the IRTF and IETF. At this time, these proposals are at an early stage.
All proposals (including
LISP) have potentially harmful side-effects to Internet traffic carried
by the involved routers, have parts where deployment incentives may be
lacking, and are NOT RECOMMENDED for deployment beyond experimental
situations at this stage. Many of the proposals have components (such as
the EID-to-RLOC mapping system) where it is not yet known what kind of
design alternative is the best one among many.

However, despite these issues it would be valuable to write concrete
protocol specifications and develop implementations that can be used to
understand the characteristics of these designs. The LISP WG is
chartered to work on the LISP base protocol
(draft-farinacci-lisp-12.txt), the LISP+ALT mapping system
(draft-fuller-lisp-alt-05.txt), LISP Interworking
(draft-lewis-lisp-interworking-02.txt), LISP Map Server
(draft-fuller-lisp-ms-00.txt), and LISP multicast
(draft-farinacci-lisp-multicast-01.txt) for these purposes, with the
given drafts as a starting point. The working group will encourage and
support interoperable LISP implementations as well as defining
requirements for alternate mapping systems. The Working Group will also
develop security profiles for the ALT and/or other mapping systems.

It is expected that the results of specifying, implementing, and testing
LISP will be fed to the general efforts at the IETF and IRTF (e.g., the
Routing Research Group) that attempts to understand which type of a
solution is optimal. The LISP WG is NOT chartered to develop the final
or standard solution for solving the routing scalability problem. Its
specifications are Experimental and labeled with accurate disclaimers
about their limitations and not fully understood implications for
Internet traffic. In addition, as these issues are understood, the
working group will analyze and document the implications of LISP on
Internet traffic, applications, routers, and security. This analysis
will explain what role LISP can play in scalable routing. The analysis
should also look at scalability and levels of state required for
encapsulation, decapsulation, liveness, and so on
(draft-meyer-loc-id-implications).

Goals and Milestones:

Mar 2010 Submit base LISP specification to the IESG as Experimental

Mar 2010 Submit base ALT specification to the IESG as Experimental

Mar 2010 Submit the LISP Interworking specification to the IESG as
Experimental

June 2010 Submit the LISP Map Server specification to the IESG as
Experimental

June 2010 Submit Recommendations for Securing the LISP Mapping System to
the IESG as Experimental

Jul 2010 Submit LISP for Multicast Environments to the IESG as
Experimental

Dec 2010 Submit a preliminary analysis as Informational

Dec 2010 Re-charter or close.

_______________________________________________
New-work mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/new-work

From [email-masked]  Wed Mar 18 06:18:05 2009
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
To: Peter Koch <[email-masked]>
Date: Wed, 18 Mar 2009 06:50:07 +0100
Cc: [email-masked]
Subject: Re: [dns-dir] Directorate and interaction with others redux

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-81--797313670
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

I am on vacation, but in short, my view is that DNS-DIR is _not_ a  
body that make decisions. It is a discussion forum where invited  
people that know something about DNS discuss issues that have to be  
discussed. Issues are often brought up by the ADs (of various Areas)  
but possibly also by wg chairs and individual IETF participants. The  
directorate exists, just like any directorate, as a resource that is  
there to help with DNS-specific issues.

    Patrik

On 17 mar 2009, at 20.41, Peter Koch wrote:

> Andrew,
>
> thanks for bringing this up.  The recent discussion disturbed me, as  
> well,
> and a review of assumptions is probably due.
>
> Caveat: the DNS-DIR archives are currently publicly acessible.  This  
> may
> be a result of the secretariat having "fixed" archiving for IETF lists
> a week or two ago or may have been the case for longer. To me it was  
> a surprise.
>
>> My previous understanding was that we were a group that simply
>> provided some expertise and background to ADs.  As a result, we do
>> not engage in formal review, or try to review every document the IETF
>> produces.  Rather, we provide attention to issues we think could
>> impinge on the DNS, and make suggestions privately.
>
> It was at least my understanding that nobody should ever try to  
> "speak for
> the DNS directorate" unless explicitly agreed upon.  Reviews  
> initiated here
> would serve as input to AD evaluations and not per se carry more  
> weight.
>
>> 1.  Never do that again.  If arguments have to be taken from the
>> dns-dir list, then the whole thread needs to be forwarded to the
>> person who needs to see the arguments.  More likely, the arguments in
>
> Sure. However, the genesis of a common response, if any, is probably  
> less
> important.  But this opens the question of how "we" actually arrive at
> some review response.  maybe we can discuss this in San Francisco?
>
>> 2.  Formalise the DNS Directorate more, and add members to it so that
>> it becomes a "full service" directorate of the sort that the security
>> directorate seems to be.  I'm a little uncomfortable with this,
>
> ... so am I, for at least an additional reason: formalization would
> suggest we have some review guidelines and I'm not sure we're that  
> far yet.
>
>> 3.  Add a separate mailing list for DNS Directorate interaction with
>> the rest of the world.  All postings to dns-dir-pub also go to
>> dns-dir, so that one doesn't have to subscribe to another mailing  
>> list
>> (although one does have to be careful about where one posts).  The
>> archives for this proposed list would be open.
>
> To avoid confusion, I'd slightly prefer (1) over this.
>
>> instead of an unofficial addition to the proesses.  And I'm keen for
>> us to shake any suggestion of being a DNS cabal out to thwart the
>> legitimate aspirations of people wanting to use the DNS.
>
> Whatever this cabal would have been up to, at least in recent cases  
> it doesn't
> seem to have been overly successful ...
> But I agree the output should be somehow deterministic (to the  
> extent that
> different people see different things, but have a common ground and
> vision w.r.t. the DNS).
>
> -Peter
> _______________________________________________
> dns-dir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-dir

--Apple-Mail-81--797313670
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

--Apple-Mail-81--797313670--

From [email-masked]  Wed Mar 18 09:30:44 2009
Content-class: urn:content-classes:message
Date: Wed, 18 Mar 2009 17:31:07 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, "MIB Doctors (E-mail)" <[email-masked]>
Subject: [dns-dir] FW: WG Review: Dispatch (dispatch)

=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
IESG Secretary
Sent: Wednesday, March 18, 2009 4:37 PM
To: [email-masked]
Subject: WG Review: Dispatch (dispatch)=20

A new IETF working group has been proposed in the Real-time Applications
and Infrastructure Area.  The IESG has not made any determination as
yet.
The following draft charter was submitted, and is provided for
informational purposes only.  Please send your comments to the IESG
mailing list ([email-masked]) by Wednesday, March 25, 2009.

Dispatch (dispatch)
--------------------------------------------------
Last Modified: 2009-03-12

Current Status: Proposed Working Group

Group Description:=20

The Dispatch working group is chartered to consider proposals for
  new work in the RAI area and identify, or help create, an appropriate
  venue for the work. Options for handling new work include:

  - Assigning the work to an existing WG.
  - Developing a proposal for a BOF.
  - Developing a charter and establishing consensus for a new WG
    or Exploratory Group. This option will primarily be used with
    fairly mature and well-defined efforts.
  - Rejecting and deferring work.

  A major objective of the DISPATCH WG is to provide timely, clear
  dispositions of new efforts. Where there is consensus to take
  on new work, the WG will strive to quickly find a home for it.
  Reconsideration of proposals which have failed to gather consensus
  will be prioritized behind proposals for new work which have not
  yet been considered. In general, requests for reconsideration
  should only be made once a proposal has been significantly
  revised.

  The DISPATCH WG will also operate as an area wide WG where ideas can
  be discussed that do not currently have a logical venue for the work
  to be done. As part of this function, the WG will evaluate SIP Event
  Packages that were not developed inside some other area working group.

  Guiding principles will include:

  1. Providing a clear problem statement for proposed new work.

  2. Prioritizing new efforts so that RAI does not take on more work
     than it can effectively complete.

  3. Looking for commonalities among ongoing development efforts.
     Such commonalities may indicate the need to develop more
     general, reusable components.

  4. Protecting the architectural integrity of RAI protocols and
ensuring that work has general applicability.

  The WG may take on some of the previous work items from the SIPPING
working group to allow a smooth transition. If the group decides that a
particular topic needs to be addressed by a new or existing WG, this is
still followed by the usual IETF chartering process, including, for
instance, IETF-wide review of the proposed changes. Proposal for large
work efforts SHOULD lead to a BOF where the topic can be discussed in
front of the entire IETF community.

Milestones:
    TBD

From [email-masked]  Wed Mar 18 09:31:09 2009
Content-class: urn:content-classes:message
Date: Wed, 18 Mar 2009 17:31:38 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, "MIB Doctors (E-mail)" <[email-masked]>
Subject: [dns-dir] FW: WG Review: Session Initiation Protocol Core (SIPCore)

=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
IESG Secretary
Sent: Wednesday, March 18, 2009 6:29 PM
To: [email-masked]
Subject: WG Review: Session Initiation Protocol Core (SIPCore)=20

A new IETF working group has been proposed in the Real-time Applications
and Infrastructure Area.  The IESG has not made any determination as
yet.
The following draft charter was submitted, and is provided for
informational purposes only.  Please send your comments to the IESG
mailing list ([email-masked]) by Wednesday, March 25, 2009.

Session Initiation Protocol Core (SIPCore)
--------------------------------------------------
Current Status: Proposed Working Group

Last Modified: 2009-03-12

Group Description:

The Session Initiation Protocol Core (SIPCore) working group is
chartered to maintain and continue the development of the core SIP
specifications, currently defined as proposed standard RFCs 3261, 3262,
3263, 3264, and 3265.

The SIPCore working group will concentrate on specifications that update
or replace the core SIP specifications. In this context, "update" means
replacing or modifying protocol elements in the above listed RFCs in
ways that would affect most or all implementations of those RFCs alone.
Extensions to SIP that add new functionality that would not be required
of all implementations will be done outside of this WG. The process and
requirements for such extensions are documented in RFC 3427bis, "Change
Process for the Session Initiation Protocol".

Throughout its work, the group will strive to maintain the basic model
and architecture defined by SIP. In particular:

1. Services and features are provided end-to-end whenever possible.

2. Reuse of existing Internet protocols and architectures and
integrating with other Internet applications is crucial.

The primary source of change requirements will be a) interoperability
problems that stem from ambiguous or under-defined specification, and b)
requirements from other working groups in the RAI Area.

Although in general the WG will not work on extensions to SIP, it may
take on some previous work items from the SIP working group to allow for
a smooth transition. The adoption of new items requires explicit
agreement from the AD or rechartering.

Goals and Milestones:

Mar 2009 Identify requirements for test matrix to move 3261 to Draft
Standard Mar 2009 Essential corrections to RFC 3261 (1st batch) to IESG
(PS) May 2009 Delivering request-URI and parameters to UAS via proxy to
IESG (PS) May 2009 INFO package framework to IESG (PS)

From [email-masked]  Thu Mar 26 11:29:10 2009
To: [email-masked]
From: Olafur_DNS_EARLY_WARNING <[email-masked]>
Date: Thu, 26 Mar 2009 14:30:01 -0400
Subject: [dns-dir] DNS Early Warn: draft-ietf-v6ops-ipv6-cpe-router-00.txt

Count:       20 

Network Working Group                                           H. Singh
Internet-Draft                                                 W. Beebee
Intended status: BCP                                 Cisco Systems, Inc.
Expires: September 26, 2009                               March 25, 2009

                    IPv6 CPE Router Recommendations
                  draft-ietf-v6ops-ipv6-cpe-router-00

 Abstract
   This document recommends IPv6 behavior for Customer Premises
   Equipment (CPE) routers in Internet-enabled homes and small offices.
   The CPE Router may be a standalone device.  The CPE Router may also
   be embedded in a device such as a cable modem, DSL modem, cellular
   phone, etc.  This document describes the router portion of such a
   device.  The purpose behind this document is to provide minimal
   functionality for interoperability and create consistency in the
   customer experience and satisfy customer expectations for the device.
   Further, the document also provide some guidance for implementers to
   expedite availability of IPv6 CPE router products in the marketplace.
   It is expected that standards bodies other than the IETF developing
   standards for specific products in this area (e.g.  CableLabs
   eRouter, Broadband Forum, Home Gateway Initiative, etc.) may
   reference this work for basic functionality and provide value-added
   or linktype-specific customizations and enhancements which are beyond
   the scope of this document.

From [email-masked]  Fri Mar 27 09:28:43 2009
To: [email-masked]
From: Lars-Johan Liman <[email-masked]>
Date: Fri, 27 Mar 2009 09:29:31 -0700
Subject: [dns-dir] "domain name" text sanity text.

Following yesterday's brief discussion on "what to say to ppl who want
to make syntactic specification for hostnames/domainnames", this is
what I and one of the authors of draft-ietf-netmod-yang-types-02.txt
ended up with after half an hour of tossing of ideas.

Do you find it unsuitable to have such text in an RFC? If so, please
help me to improveme it!

(This is a cut-and-paste I have done myself from our mail messages, as
I don't have access to the actual file they're edititing.

  typedef domain-name {
    type string {
      pattern '([a-zA-Z0-9_](([a-zA-Z0-9\-_]){0,61}[a-zA-Z0-9])?\.)*'
           +  '[a-zA-Z0-9_](([a-zA-Z0-9\-_]){0,61}[a-zA-Z0-9])?';
      length "1..255";
    }
    description
     "The domain-name type represents a DNS domain name. The 
      name SHOULD be fully qualified whenever possible.

      The description clause of objects using the domain-name
      type MUST describe how (and when) these names are 
      resolved to IP addresses.

      Note that the resolution of a domain-name value may 
      require to query multiple DNS records (e.g., A for IPv4
      and AAAA for IPv6). The order of the resolution process
      and which DNS record takes precedence depends on the
      configuration of the resolver.

      The canonical format for domain-name values uses the US-ASCII
      encoding and case-insensitive characters are set to lowercase.

      Internet domain names are only loosely specified.  Section 3.5
      of RFC 1034 recommends a syntax (modified in section 2.1 of RFC
      1123).  The syntax described above is intended to allow for
      current practise in domain name use, and some possible future
      expansion.  It is designed to hold various types of domain
      names, including names used for A or AAAA records (host names)
      and other records, such as SRV records. Note that Internet host
      names have a stricter syntax (described in RFC 952) than the DNS
      recommendations in RFCs 1034 and 1123, and that systems that
      want to store host names in domain-name type containers are
      recommended to adhere to this stricter standard to ensure
      interoperability.";

    reference
     "RFC  952: DoD Internet Host Table Specification
      RFC 1034: Domain Names - Concepts and Facilities
      RFC 1123: Requirements for Internet Hosts -- Application 
                and Support
      RFC 3490: Internationalizing Domain Names in Applications
                (IDNA)";
  }

				Cheers,
				  /Liman

From [email-masked]  Fri Mar 27 09:35:24 2009
Date: Fri, 27 Mar 2009 12:36:16 -0400
To: [email-masked]
From: Olafur Gudmundsson <[email-masked]>
Subject: Re: [dns-dir] "domain name" text sanity text.

At 12:29 27/03/2009, Lars-Johan Liman wrote:
>Following yesterday's brief discussion on "what to say to ppl who want
>to make syntactic specification for hostnames/domainnames", this is
>what I and one of the authors of draft-ietf-netmod-yang-types-02.txt
>ended up with after half an hour of tossing of ideas.
>
>Do you find it unsuitable to have such text in an RFC? If so, please
>help me to improveme it!
>
>(This is a cut-and-paste I have done myself from our mail messages, as
>I don't have access to the actual file they're edititing.
>
>
>   typedef domain-name {
>     type string {
>       pattern '([a-zA-Z0-9_](([a-zA-Z0-9\-_]){0,61}[a-zA-Z0-9])?\.)*'
>            +  '[a-zA-Z0-9_](([a-zA-Z0-9\-_]){0,61}[a-zA-Z0-9])?';
>       length "1..255";
>     }

This expression is close but it rules out single letter labels.

         Olafur

From [email-masked]  Fri Mar 27 09:48:13 2009
To: Olafur Gudmundsson <[email-masked]>
From: Lars-Johan Liman <[email-masked]>
Date: Fri, 27 Mar 2009 09:48:47 -0700
Cc: [email-masked]
Subject: Re: [dns-dir] "domain name" text sanity text.

At 12:29 27/03/2009, Lars-Johan Liman wrote:
>> pattern '([a-zA-Z0-9_](([a-zA-Z0-9\-_]){0,61}[a-zA-Z0-9])?\.)*'
>> +  '[a-zA-Z0-9_](([a-zA-Z0-9\-_]){0,61}[a-zA-Z0-9])?';
>> length "1..255";
>> }

[email-masked]:
> This expression is close but it rules out single letter labels.

Yes, you're right. :-( It get's really ugly if you want to allow a
single char label, but not if it's a '-' or a '_'. Sigh. I'll toss
that back to the author. He seems to like regexps ... ;-)

				Cheers,
				  /Liman

From [email-masked]  Fri Mar 27 23:54:16 2009
Date: Sat, 28 Mar 2009 07:51:59 +0100
From: Peter Koch <[email-masked]>
To: Lars-Johan Liman <[email-masked]>
Sender: Peter Koch <[email-masked]>
Cc: [email-masked]
Subject: Re: [dns-dir] "domain name" text sanity text.

On Fri, Mar 27, 2009 at 09:48:47AM -0700, Lars-Johan Liman wrote:
> At 12:29 27/03/2009, Lars-Johan Liman wrote:
> >> pattern '([a-zA-Z0-9_](([a-zA-Z0-9\-_]){0,61}[a-zA-Z0-9])?\.)*'
> >> +  '[a-zA-Z0-9_](([a-zA-Z0-9\-_]){0,61}[a-zA-Z0-9])?';
> >> length "1..255";

Given that the wire format is restricted to 255 octets (well, 1123 is again
a bit ambiguous), and also given that the wire formats needs two octets more
than the presentation format, length should be 1..253 here.

> [email-masked]:
> > This expression is close but it rules out single letter labels.

It might have been intentional, but it rules out ".", too.

> Yes, you're right. :-( It get's really ugly if you want to allow a
> single char label, but not if it's a '-' or a '_'. Sigh. I'll toss
> that back to the author. He seems to like regexps ... ;-)

To my surprise, it explicitly allows the "_" character, even at the
beginning of a label.  Also, when it's called "domain-name" and then uses
hostname 'restrictions' (lest the '_'), that calls for confusion.
The reference to RFC 3490 shouldn't be necessary, by the way.

In total, this convinces me that "we" should come up with a consolidated
description of DNS hostname syntax.

-Peter

PS: The regexp seems inconsistent about the trailing dot (warning, potential
    rathole) and it does not (well, cannot) exclude IP address like names.

From [email-masked]  Mon Mar 30 01:39:16 2009
To: [email-masked]
From: Lars-Johan Liman <[email-masked]>
Date: Mon, 30 Mar 2009 10:38:53 +0200
Subject: Re: [dns-dir] "domain name" text sanity text.

[email-masked]:
> Given that the wire format is restricted to 255 octets (well, 1123
> is again a bit ambiguous), and also given that the wire formats
> needs two octets more than the presentation format, length should be
> 1..253 here.

Umm ... isn't wire format N+1 (not N+2) except for the root itself
(single ".") which is just N (where N =3D 1)?

General case:

www.cafax.se. =3D 13

3 w w w 5 c a f a x 2 s e 0 =3D 14

Root:

. =3D 1

0 =3D 1

AH! Are you referring to the presentation format _without_ the
trailing "."? If so, then we agree.

Yes, maybe we should limit it to 253.

>> [email-masked]:
>> > This expression is close but it rules out single letter labels.

> It might have been intentional, but it rules out ".", too.

Not intentional. Should definitely not rule out ".".

>> Yes, you're right. :-( It get's really ugly if you want to allow a
>> single char label, but not if it's a '-' or a '_'. Sigh. I'll toss
>> that back to the author. He seems to like regexps ... ;-)

> To my surprise, it explicitly allows the "_" character, even at the
> beginning of a label.

By design!

_kerberos._udp.cafax.se.        IN      SRV     ...     ...

It is indeed intended to be a container for domain names, and not only
for hostnames. E.g., you might want to use the same data type to carry
SRV records (VoIP, Kerberos, or other) or even just the search domain
for a resolver, neither of which is a hostname.

> Also, when it's called "domain-name" and then uses hostname
> 'restrictions' (lest the '_'),

Our intention: to use the restrictions that are recommended in 1034,
plus expansions for the 3com case, typical in-addr.arpa domains, SRV
records, and make sure IDN is allowed.

> that calls for confusion.

I'm sorry. Domain names _are_ confusing. ;-)

> The reference to RFC 3490 shouldn't be necessary, by the way.

Why not? Domain names appear sometimes displayed in a certain LOCALE
(e.g. "r=E4ksm=F6rg=E5s.se"), and since the authors want to enforce that the
name stored in their data type is expanded punycode (A-labels), I
think a reference to RFC 3490 is appropriate. I'm happy to reference
some other RFC, but I believe that _some_ reference to IDN encoding is
called for.

> In total, this convinces me that "we" should come up with a
> consolidated description of DNS hostname syntax.

> PS: The regexp seems inconsistent about the trailing dot (warning, potent=
ial
>     rathole) and it does not (well, cannot) exclude IP address like
>     names.

By intention we designed the container to be able to hold "any" type
of domain name, not only hostnames. Hostnames are a subset of domain
names, and will hence fit well in the container. The container is also
designed to a) withstand some minimal possible future relaxation of
hostnames without having to be redefined, and b) "be liberal in what
you expect". Our hope is that the "conservative in what you send" part
is accomplished by the text that follows it, explaining about hostname
restrictions.

Provocative question:

Isn't it time we denounce the old RFC 952? What good does it bring?

;-)

				Cheers,
				  /Liman

From [email-masked]  Mon Mar 30 06:46:14 2009
Date: Mon, 30 Mar 2009 09:47:02 -0400
To: [email-masked]
From: Olafur Gudmundsson <[email-masked]>
Subject: Re: [dns-dir] "domain name" text sanity text.

At 04:38 30/03/2009, Lars-Johan Liman wrote:
>[email-masked]:
> > Given that the wire format is restricted to 255 octets (well, 1123
> > is again a bit ambiguous), and also given that the wire formats
> > needs two octets more than the presentation format, length should be
> > 1..253 here.
>
>Umm ... isn't wire format N+1 (not N+2) except for the root itself
>(single ".") which is just N (where N =3D 1)?
>
>General case:
>
>www.cafax.se. =3D 13
>
>3 w w w 5 c a f a x 2 s e 0 =3D 14
>
>Root:
>
>. =3D 1
>
>0 =3D 1
>
>AH! Are you referring to the presentation format _without_ the
>trailing "."? If so, then we agree.
>
>Yes, maybe we should limit it to 253.
>
> >> [email-masked]:
> >> > This expression is close but it rules out single letter labels.
>
> > It might have been intentional, but it rules out ".", too.
>
>Not intentional. Should definitely not rule out ".".

IMHO "." does not need to be covered if we state that this
is an expression of what domain names can be allocated.
Root is a precursor to any other names in the tree.

> >> Yes, you're right. :-( It get's really ugly if you want to allow a
> >> single char label, but not if it's a '-' or a '_'. Sigh. I'll toss
> >> that back to the author. He seems to like regexps ... ;-)
>
> > To my surprise, it explicitly allows the "_" character, even at the
> > beginning of a label.
>
>By design!
>
>_kerberos._udp.cafax.se.        IN      SRV     ...     ...
>
>It is indeed intended to be a container for domain names, and not only
>for hostnames. E.g., you might want to use the same data type to carry
>SRV records (VoIP, Kerberos, or other) or even just the search domain
>for a resolver, neither of which is a hostname.
>
> > Also, when it's called "domain-name" and then uses hostname
> > 'restrictions' (lest the '_'),
>
>Our intention: to use the restrictions that are recommended in 1034,
>plus expansions for the 3com case, typical in-addr.arpa domains, SRV
>records, and make sure IDN is allowed.

666.com is a registered valid domain name and there is no
reason why it or any other "numeric label" should be restricted
at any level other than TLD.

> > that calls for confusion.
>
>I'm sorry. Domain names _are_ confusing. ;-)

New terminology idea:
         root                    root
         TLD name                trunk
         non-TLD name            branch/leaf

> > The reference to RFC 3490 shouldn't be necessary, by the way.
>
>Why not? Domain names appear sometimes displayed in a certain LOCALE
>(e.g. "r=E4ksm=F6rg=E5s.se"), and since the authors want to enforce that=
 the
>name stored in their data type is expanded punycode (A-labels), I
>think a reference to RFC 3490 is appropriate. I'm happy to reference
>some other RFC, but I believe that _some_ reference to IDN encoding is
>called for.
>
> > In total, this convinces me that "we" should come up with a
> > consolidated description of DNS hostname syntax.
>
> > PS: The regexp seems inconsistent about the=20
> trailing dot (warning, potential
> >     rathole) and it does not (well, cannot) exclude IP address like
> >     names.
>
>By intention we designed the container to be able to hold "any" type
>of domain name, not only hostnames. Hostnames are a subset of domain
>names, and will hence fit well in the container. The container is also
>designed to a) withstand some minimal possible future relaxation of
>hostnames without having to be redefined, and b) "be liberal in what
>you expect". Our hope is that the "conservative in what you send" part
>is accomplished by the text that follows it, explaining about hostname
>restrictions.
>
>Provocative question:
>
>Isn't it time we denounce the old RFC 952? What good does it bring?
>
>;-)

Please lets obsolete it, from what I can see in RFC952 there is NO
content other than the character subset that has any value!

         Olafur

From [email-masked]  Tue Mar 31 11:29:03 2009
To: [email-masked]
From: Olafur_DNS_EARLY_WARNING <[email-masked]>
Date: Tue, 31 Mar 2009 14:30:01 -0400
Subject: [dns-dir] DNS Early Warn: draft-vogt-address-translation-harmfulness-02.txt

Count:       11 

Network Working Group                                     Christian Vogt
Internet-Draft                                                  Ericsson
Expires:  September 16, 2009                              March 15, 2009

           Qualifying the Harmfulness of Address Translation
           draft-vogt-address-translation-harmfulness-02.txt

 Abstract
   Address translation is widely considered harmful because it conflicts
   with design principles highly regarded within the Internet
   engineering community.  Still, address translation has become common
   practice despite technical problems because it constitutes an easy-

   to-deploy solution to a set of common operational needs.  Since some
   of these needs will continue to exist in IP version 6, there is
   concern within the Internet engineering community about the potential
   proliferation of harmful technology from IP version 4 to IP version
   6.  This document investigates this concern.  It compares feasible
   address translator designs with respect to the harmful impact they
   may have, explains why the problems of address translation, as used
   today, are to a significant extent entailed by the shortage of global
   addresses in IP version 4, and shows how the problems can be
   mitigated in IP version 6.

From [email-masked]  Tue Mar 31 11:49:39 2009
Date: Tue, 31 Mar 2009 20:47:21 +0200
From: Peter Koch <[email-masked]>
To: DNS Directorate <[email-masked]>
Sender: Peter Koch <[email-masked]>
Subject: Re: [dns-dir] "domain name" text sanity text.

On Mon, Mar 30, 2009 at 10:38:53AM +0200, Lars-Johan Liman wrote:

> AH! Are you referring to the presentation format _without_ the
> trailing "."? If so, then we agree.

yes.

> _kerberos._udp.cafax.se.        IN      SRV     ...     ...
> 
> It is indeed intended to be a container for domain names, and not only
> for hostnames. E.g., you might want to use the same data type to carry
> SRV records (VoIP, Kerberos, or other) or even just the search domain
> for a resolver, neither of which is a hostname.

well, that would be a strong deviation from previous discussions. RFC 2181,
with all the due grain of salt, re-emphasizes that "domain names" can contain
_any_ characters. Hostnames, though, are and have alsways been restricted
by RFC952 as amended by RFC 1123.  The owners of SRV RRs have an additional
component, but I doubt that it is a goof way forward to unconditionally
add '_' to the RFC952/1123 character set and call taht "domain names".

> Our intention: to use the restrictions that are recommended in 1034,
> plus expansions for the 3com case, typical in-addr.arpa domains, SRV
> records, and make sure IDN is allowed.

There's no need to "allow" IDNs.  They have been carefully desigend to meet
the RFC952/1123 requirements.  Apart from that, IDNs are not domain names.

> > The reference to RFC 3490 shouldn't be necessary, by the way.
> 
> Why not? Domain names appear sometimes displayed in a certain LOCALE
> (e.g. "r�ksm�rg�s.se"), and since the authors want to enforce that the
> name stored in their data type is expanded punycode (A-labels), I

I didn't read that in the excerpt you provided.  Is there a full draft
available?

> By intention we designed the container to be able to hold "any" type
> of domain name, not only hostnames. Hostnames are a subset of domain
> names, and will hence fit well in the container. The container is also
> designed to a) withstand some minimal possible future relaxation of
> hostnames without having to be redefined, and b) "be liberal in what
> you expect". Our hope is that the "conservative in what you send" part
> is accomplished by the text that follows it, explaining about hostname
> restrictions.

>From what I read the "container" allows hostnames + '_', so doesn't look
very 'lioberal'.

> Provocative question:
> 
> Isn't it time we denounce the old RFC 952? What good does it bring?

Backwards compatibility for applications, maybe?

-Peter

From [email-masked]  Tue Mar 31 12:00:53 2009
Date: Tue, 31 Mar 2009 20:58:21 +0200
From: Peter Koch <[email-masked]>
To: DNS Directorate <[email-masked]>
Sender: Peter Koch <[email-masked]>
Subject: Re: [dns-dir] "domain name" text sanity text.

On Mon, Mar 30, 2009 at 09:47:02AM -0400, Olafur Gudmundsson wrote:

> >Not intentional. Should definitely not rule out ".".
> 
> IMHO "." does not need to be covered if we state that this
> is an expression of what domain names can be allocated.
> Root is a precursor to any other names in the tree.

The quoted text did not mention "allocation" but representation of
domain names, which would include ".".

> >I'm sorry. Domain names _are_ confusing. ;-)
> 
> New terminology idea:
>         root                    root
>         TLD name                trunk
>         non-TLD name            branch/leaf

Since TLD names can be leaves, why would this not add confusion? :-)

> >Isn't it time we denounce the old RFC 952? What good does it bring?
> >
> >;-)
> 
> 
> Please lets obsolete it, from what I can see in RFC952 there is NO
> content other than the character subset that has any value!

Well, "NO ... other" admits that it _has_ value, at least. And I'd add
that RFC 952 is the only place I can remember that actually defines
teh dotted decimal representation of IPv4 addresses.  Obsoleting RFC 952
doesn't sound right to me. Stability is key.

-Peter

From [email-masked]  Tue Mar 31 12:56:00 2009
Date: Tue, 31 Mar 2009 15:56:06 -0400
To: Peter Koch <[email-masked]>, DNS Directorate <[email-masked]>
From: Olafur Gudmundsson <[email-masked]>
Subject: Re: [dns-dir] "domain name" text sanity text.

At 14:58 31/03/2009, Peter Koch wrote:
>On Mon, Mar 30, 2009 at 09:47:02AM -0400, Olafur Gudmundsson wrote:
>
> > >Not intentional. Should definitely not rule out ".".
> >
> > IMHO "." does not need to be covered if we state that this
> > is an expression of what domain names can be allocated.
> > Root is a precursor to any other names in the tree.
>
>The quoted text did not mention "allocation" but representation of
>domain names, which would include ".".

text can be fixed

> > >I'm sorry. Domain names _are_ confusing. ;-)
> >
> > New terminology idea:
> >         root                    root
> >         TLD name                trunk
> >         non-TLD name            branch/leaf
>
>Since TLD names can be leaves, why would this not add confusion? :-)

suggest something better :-)

> > >Isn't it time we denounce the old RFC 952? What good does it bring?
> > >
> > >;-)
> >
> >
> > Please lets obsolete it, from what I can see in RFC952 there is NO
> > content other than the character subset that has any value!
>
>Well, "NO ... other" admits that it _has_ value, at least. And I'd add
>that RFC 952 is the only place I can remember that actually defines
>teh dotted decimal representation of IPv4 addresses.  Obsoleting RFC 952
>doesn't sound right to me. Stability is key.

Network Working Group                               K. Harrenstien (SRI)
Request for Comments: 952                                 M. Stahl (SRI)
                                                         E. Feinler (SRI)
Obsoletes:  RFC 810, 608                                    October 1985

                  DOD INTERNET HOST TABLE SPECIFICATION

How in the world do we expect anyone to even think twice to look in this
document for specification of textual "hostname" and "ip address".
If we follow 952 to the letter no DNS label can be more than 24 characters
long.
The IP address representation used the obsoleted A-E class model, thus
it is misleading.

When 90% of the contents has no value or is misleading then I think it
is time to obsolete.

         Olafur 

From [email-masked]  Tue Mar 31 13:34:26 2009
Date: Tue, 31 Mar 2009 22:32:09 +0200
From: Peter Koch <[email-masked]>
To: DNS Directorate <[email-masked]>
Sender: Peter Koch <[email-masked]>
Subject: Re: [dns-dir] "domain name" text sanity text.

On Tue, Mar 31, 2009 at 03:56:06PM -0400, Olafur Gudmundsson wrote:

> >The quoted text did not mention "allocation" but representation of
> >domain names, which would include ".".
> 
> text can be fixed

-v, please. Why "fix" the text when there's no conjunction with "allocation"
anyway?

> >Since TLD names can be leaves, why would this not add confusion? :-)
> 
> suggest something better :-)

Err, no. You suggested new terminology -- please explain what that would help.

> Network Working Group                               K. Harrenstien (SRI)
> Request for Comments: 952                                 M. Stahl (SRI)
>                                                         E. Feinler (SRI)
> Obsoletes:  RFC 810, 608                                    October 1985
> 
>                  DOD INTERNET HOST TABLE SPECIFICATION
> 
> How in the world do we expect anyone to even think twice to look in this
> document for specification of textual "hostname" and "ip address".

That's a different issue.  There are enough references to 952 in 1123 and
elsewhere.

> If we follow 952 to the letter no DNS label can be more than 24 characters
> long.

That's why we should not use 952 without the DNS relevant amendments in 1123.

> The IP address representation used the obsoleted A-E class model, thus
> it is misleading.

The textual representation is independent of the classful system.

> When 90% of the contents has no value or is misleading then I think it
> is time to obsolete.

Maybe it's time to _clarify_ or to consolidate the appropriate information
in a singfle place, yes.

-Peter