[gnso-sl-wg] FW: we have further information from one of the technical experts/and it has some implications for the report
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.