<<<
Chronological Index
>>> <<<
Thread Index
>>>
RE: [gnso-sl-wg] FW: we have further information from one of the technical experts/and it has some implications for the report
- To: "Marilyn Cade" <marilynscade@xxxxxxxxxxx>, <gnso-sl-wg@xxxxxxxxx>, "Patrick Jones" <patrick.jones@xxxxxxxxx>, "Gomes, Chuck" <cgomes@xxxxxxxxxxxx>
- Subject: RE: [gnso-sl-wg] FW: we have further information from one of the technical experts/and it has some implications for the report
- From: "Shatan, Gregory S." <GShatan@xxxxxxxxxxxxx>
- Date: Wed, 9 May 2007 14:03:42 -0400
I am available. Thank you for coordinating this, Marilyn.
_____
From: owner-gnso-sl-wg@xxxxxxxxx [mailto:owner-gnso-sl-wg@xxxxxxxxx] On
Behalf Of Marilyn Cade
Sent: Wednesday, May 09, 2007 1:50 PM
To: gnso-sl-wg@xxxxxxxxx; 'Patrick Jones'; 'Gomes, Chuck'
Subject: [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_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.
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|