[gnso-sl-wg] FW: we have further information from one of the technical experts/and it has some implications for the report

["Marilyn Cade" <marilynscade@xxxxxxxxxxx>]

Dear colleagues

 

What follows are two email responses received by Steve Bellovin[you can see
the incoming times], one of the technical experts, with his comments on the
recommendations that the group is proposing.

 

There are implications for the recommendations, and on how to incorporate
his comments. 

 

I just talked to Patrick about how to incorporate the emails into the
comments from technical experts, but the sub group needs to discuss the
implications to the draft recommendations, because Steve's clarification of
what he said on the consultation call/which we didn't quite capture
correctly implicates two of our recommendations at the top level.  He also
provided another RFC reference for us.

 

I am proposing a call today at 4:30 p.m. for anyone available from the Sub
Group to discuss the technical input and adjustments to the sub group
report. Sorry to jump in, Greg, but it sees important to try to discuss this
with the sub group via a call. Can you make a short call then? 

I also cc'd Chuck Gomes, given that this is arriving later than we had
hoped, to see if he wants to join the discussion.

 

 

Also Patrick is both emailing and calling Mark McFadden, once he locates a
telephone numbe for Mark to see if he can track him down. 

 

Bridge for the call at 4:30 pm EST.:  866 484 5340/code:  525815

 

Marilyn Cade

-----Original Message-----

From: Steven M. Bellovin [mailto:smb@xxxxxxxxxxxxxxx] 

Sent: Tuesday, May 08, 2007 10:16 PM

To: Marilyn Cade

Subject: Re: follow up/deadline tomorrow for your review of sections related
to your comments

 

Quick followup -- I confirmed that Unix standards *require* that

ddd.ddd be interpreted as described; see

http://www.opengroup.org/onlinepubs/000095399/functions/getaddrinfo.html

and

http://www.opengroup.org/onlinepubs/000095399/functions/inet_addr.html

 

To be quite explicit: any program that uses IEEE standard 1003.1 *will*

be confused by ddd.ddd.

 

==========================================================================

 

 

-----Original Message-----

From: Steven M. Bellovin [mailto:smb@xxxxxxxxxxxxxxx] 

Sent: Tuesday, May 08, 2007 9:51 PM

To: Marilyn Cade

Subject: Re: follow up/deadline tomorrow for your review of sections related
to your comments

 

I read just the portions you cited.

 

Mostly ok, but...

 

1.5:

 

This is wrong:

 

      However, due to technical concerns, we recommend that single

      character (LDH) names be reserved at the second level in any

      single letter TLD.

 

Single-letter TLDs are bad if there are single-letter second level names

anywhere, and vice-versa.  The problem is not restricted to direct

descendants.  For example, suppose that .a and .foo are TLDs.  If I'm

on host xyzzy.foo and ask for 'a', do I get a. -- the TLD? -- or a.foo?

This is the problem described in RFC 1535. (Yes, it can happen with

longer names; it was a real incident that inspired that RFC.)

 

The same concerns apply to this text:

 

       However, there may be technical concerns regarding the use of

      single letter and digit domains at the second level in a single

      letter TLD (e.g., 1.a or a.a).  Allocation of single letters at

      both the top level and second level in combination may [will??]

      cause certain older DNS software applications to incorrectly

      resolve.    

 

and

 

      If single letter TLDs are unreserved, single letters at the

      second level would need to be reserved in these domains.

 

and

 

      Single letters at the second level would need to be reserved in

      single letter TLDs until this problem has been eliminated.

 

 

1.6:

Numbers at the top and second level *will* cause problems.  Here's some

text from RFC 3493 -- not an IETF standard, but I think it is a Posix

standard, and it is present on all modern Unix systems, i.e.., it's not

just legacy software.

 

   If the nodename argument is not null, it can be a descriptive name or

   can be an address string.  If the specified address family is

   AF_INET, AF_INET6, or AF_UNSPEC, valid descriptive names include host

   names. If the specified address family is AF_INET or AF_UNSPEC,

   address strings using Internet standard dot notation as specified in 

   inet_addr() are valid.

 

This RFC doesn't define the behavior of inet_addr(), but Solaris and

Linux specify that it accepts ddd.ddd.  I think (but haven't verified)

that Posix requires that.