[gnso-sl-wg] RE: we have further information from one of the technical experts/and it has some implications for the report
I will leave it to the subgroup to work this and will not plan on participating on the call unless you think that my presence is needed. I personally believe that you will be able to handle this without my assistance but am willing to help if you desire. I do request though that you use the clean version of the report that I sent to Patrick, Greg and Alistair earlier today. Enter any edits you make in that clean version using the tracking function (tracking should already be activated); when you are finished, send the new version to the full WG list for review in preparation for tomorrow's meeting. This will make it easy for everyone on the WG to easily see the latest changes made. Also, change the file name to differentiate it from the clean version. Finally, so that the full WG has as much lead time as possible before our meeting on Thursday, please send the new version to the list today, even if it is late today. If there are members of your group who are unable to respond today, they will have a chance to participate tomorrow after the new version is sent to the full list. If you have any questions, please let me know. Chuck Gomes "This message is intended for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. Any unauthorized use, distribution, or disclosure is strictly prohibited. If you have received this message in error, please notify sender immediately and destroy/delete the original transmission." ________________________________ From: Marilyn Cade [mailto:marilynscade@xxxxxxxxxxx] Sent: Wednesday, May 09, 2007 1:50 PM To: gnso-sl-wg@xxxxxxxxx; 'Patrick Jones'; Gomes, Chuck Subject: 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_addrhtml 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.