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

["Gomes, Chuck" <cgomes@xxxxxxxxxxxx>]

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.