RE: [gnso-sl-wg] FW: [gnso-rn-wg] Initial draft summary of the conference call with technical experts on ASCII letters and numbers - prepared for the SubGroup

[Alistair DIXON <Alistair.Dixon@xxxxxxxxxxxxxxxxxxxxxxx>]

I had one additional comment in relation to Marilyn's number 22: I asked Steve 
Bellovin the question whether if there were numbers at the top level and 
letters below that, would that cause a problem, and his answer was no but he 
would have to think about it.  He also raised the issue of enforcement.  See 
page 24 of the 23 April transcript.  I think Steve's answer does raise the 
question of whether we should follow up to see whether he had any further 
thoughts on that point, though I think this is in the category of  very high 
hanging fruit.

Alistair


-----Original Message-----
From: owner-gnso-sl-wg@xxxxxxxxx on behalf of Mike Rodenbaugh
Sent: Mon 4/30/2007 11:21 AM
To: gnso-sl-wg@xxxxxxxxx
Subject: [gnso-sl-wg] FW: [gnso-rn-wg] Initial draft summary of the conference 
call with technical experts on ASCII letters and numbers - prepared for the 
SubGroup
 
I made a few suggested edits in boldface ALLCAPS below.  Sorry that I
cannot make either the subgroup or WG calls this week due to the INTA
conference, but glad to continue discussion via email in the meanwhile.


 

Thanks.

 

Mike Rodenbaugh

Sr. Legal Director

Yahoo! Inc.

 

NOTICE:  This communication is confidential and may be protected by
attorney-client and/or work product privilege.  If you are not the
intended recipient, please notify me by reply, and delete this
communication and any attachments.

  _____  

From: owner-gnso-rn-wg@xxxxxxxxx [mailto:owner-gnso-rn-wg@xxxxxxxxx] On
Behalf Of Marilyn Cade
Sent: Tuesday, April 24, 2007 12:28 PM
To: gnso-rn-wg@xxxxxxxxx
Cc: 'Marilyn Cade'
Subject: [gnso-rn-wg] Initial draft summary of the conference call with
technical experts on ASCII letters and numbers - prepared for the
SubGroup

 

Dear colleague: the draft below is a report on a call held with
technical experts, and preliminary and draft recommendations for the
work on single letters and numbers at top and second level. It is very
draft, and will be discussed by the sub group today. Please consider it
very preliminary. Paragraphs are numbered for ease in discussion. 

 

 Best regards, Marilyn Cade 

 

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

 

 

Recommendations regarding single and two letters and single and two
numbers at top and second level:

 

1.      On April 23, 2007, a call with two technical experts was held by
sub group on single and two letters/numbers. Participants on the call
were : 
2.      Insert list of participants. 

 

 

 

3.      The technical experts who joined the call were Steve Bellovin
[insert link  to C.V.] and Mark McFadden {link to C.V.}to discuss ASCII
characters, excluding symbols. 

 

4.      In its report to GNSO Council, the RN WG made several
recommendations about the sub categories of  single and two characters
at top and second level; and numbers at top level and second level, as
well as two letters at top level/second level. [see report to GNSO
Council : link:    ] Symbols are not being further discussed by the
extended RN WG, since the recommendation to continue to reserve symbols
has been accepted by the GNSO Council. 

 

5.      To further the work examining letters and numbers as described
above, several questions were prepared and d discussed with the two
technical experts on Monday's call.  A transcript and MP3 recording will
be available for full documentation of the Conference call consultation
and discussion. 

 

6.      In general, the questions discussed with the technical experts
addressed the following:

 

7.      Are there technical issues at both top level and second level?
Is there an interaction 
8.      between the two, so that names can't be allocated at top level
if also allocated at second level - e.g. numbers in various sequences?
Is there a technical concern if there is 'a.a'; or 'a.x' or '1.0' or
'11.0', etc.
        
        Are there other considerations:  Are there interactions that are
not apparent that present challenges due to legacy  application or
BIND/.or other software, such as the problems encountered by the more
than 3 letter new gTLDs, such as travel, .museum; info.

 

9.      Are there other known or suspected concerns about single
characters, whether numbers,
        letters, or symbols at top level? 

 

10.     If there are unknowns, and that MAY JUSTIFY [is justifying]
continuing a reservation, are there ways to identify what research or
additional work is needed to change the reservation status? Should a
further study, similar to the IDN study be undertaken in a specific
area, such as single letters at the top level? Are there suggestions for
how to do that research?  [DELETE:  A separately retained expert
consultant?  Who would make the decision: GNSO or Board: To whom would
the outcome be presented: SSAC, Board, other?] 

 

11.     When issues or technical concerns/questions are identified, how
and to what extent are the consequences manageable? How can that be
determined? By whom? 

 

12.     [DELETE (not discussed):  Is there a rationale that suggests
that names should be released and allocated, unless there is a well
documented technical issue?  Is there a rational that suggests that
identification of a concern by several highly trusted technical
resources should be sufficient to continue reserved status, without a
'documented' explanation of the basis for that concern?  In that case,
can there later be a process to then unreserve these names, and allocate
        them? What process would need to  be followed to determine that
the 'concern' has been alleviated in order to do such?] 
13.     
        [DELETE (not discussed):  Is allocation a key concern to the
community regarding some names, not just technical interactions, e.g.
since there are only 27 ASCII letters, or certain numbers that have
higher 'identity', such as "one", or 1, or ten, or 100, etc. are there
other prevailing concerns about misuse of names that need to be
understood and addressed if these are allocated at the top level?] 
        
        Specific questions about numbers?  Do numbers have challenges at
top level, or at second level? Can a pair of single letter and single
number, such as .3M, be allocated? Are there other issues about numbers
at the top level, and restrictions when numbers are registered at all
levels, e.g.11.000.22.10, where .10 is the top level; 22 is the second
level, and 000 is the third level, is there an issue of the allocation
mechanism mirrored the IP addressing scheme for IPv4 ?   Are there
different questions for categories for what should be
        reserved fro not mirroring IPv6?

 

14.     Discussion with experts. Both Bellovin and McFadden, [hereafter
experts], discussed the questions with the participants on the call. The
summary just identifies the general agreements and identifies where
there is a unique perspective or request for further consideration by
any member of the Sub Group.  It was acknowledged that there are also
policy and political aspects related to the decisions, and the technical
experts were not addressing those [DELETE: , but acknowledged their
importance.] 

 

15.     One of the experts suggested that the TF/WG divide their
considerations into 'groups', such as: 

        *       What the Name space allows
        *       What the resolvers can do
        *       What happens at the application layer

 

16.     It was noted that one could make a decision on rules for the
name space, but would still run into problems in applications. The
members of the group also discussed whether the TF/WG needs to be
concerned about 'old' versions of BIND, old applications, etc. 

 

17.     Information is available on the published surveys of versions of
BIND; there were security holes in older versions of BIND. A recent
panel at NANOG included a distribution graph of versions of BIND.
Suggested that the TF could review this information. Overall, Much of
problem not in BIND, but [potentially] in application layer. That is
harder to identify and document.  Important to 'test' before assuming
that there are no problems, as a general "rule". Test would have to
address 'scale' issues.

 

18.     RFC 1535 proposes some issues; as does 862 or 865 [verify with
Bellovin on the numbers of the RFCs. Important to review these again as
a WG and address whether the issues are addressed in the technical
consultation undertaken, or if further work is needed on any of the sub
categories, based on the RFCs. 

 

19.     [DELETE (not discussed):  For the most part, the members of the
group recognized these concerns and their implications. One or two
members are eager to try to move ahead in allocation of some of the
categories of strings at the top level, as long as the failures are not
widescale.  See Recommendations for possible approach.]  

 

20.     Draft Recommendations: 

 

21.     The group agreed that there was no need to further discuss two
letters at the top level with the technical experts, since any questions
are policy and political, not technical.

 

22.     Single Numbers at the top level:  the use of single numbers at
the top level creates ambiguity [with IP addresses], and can cause
application errors. One of the experts believed that there was a high
probability of such errors. This is caused by the inter relationship to
IP addresses. Some newer code [newer versions of UNIX] will interpret
'helpfully' if certain numbers, such as '00' are omitted, inserting them
into a string of numbers. Such code is still around. 

 

23.     Already have numbers at the second level, e.g. 163.net. An
earlier ICANN staff report documented that many ccTLDs and several gTLDs
have numbers of varying length at the second level.   Cannot have all
digits at both levels due to ambiguity that will result. 

 

24.     Recommendation: 

 

25.     Maintain reservation of single numbers at the top level. 
26.     Continue to allow allocation of numbers at the second level,
including single numbers. 

 

        *       Need to verify that single numbers at the second level
are in use today, widely, and are not encountering application problems.


 

 

27.     Single Letters at the Top Level:
28.     Single letters do not presently exist at the top level, and
ICANN rejected an application in the initial 'round'.

 

29.     It is not clear that single letters as TLD create a security
problem, but [potentially may] have stability issues.  Problems [may]
exist, especially in the least developed world's installed
infrastructure, which are not able to resolve single letter TLDs. 

 

30.     [DELETE:  Reachability" expected to be a serious issue.]  Some
versions of BIND/associated resolvers will return NX domain' for queries
against single letter TLDs.  [DELETE (unless/until verified by an
expert):  Noted that when TLDs did not resolve, as in early days of more
than three letter TLDS, there were extensive burdens on ISPs and others
operationally to try to address.  If a proposal were seriously made to
allow single letters at the top level, both testing and extensive
education would be needed to educate the underlying  infrastructure
service providers, including ISPs, code developers, etc, as well as
reaching into the developing countries to seek to develop financial base
to enhance their infrastructure. [need to verify this with Mark and
Steve].] 

 

31.     Recommendation:
32.     Reserve single letters at the top level [until technical issues
resolved or deemed insubstantial]. See further recommendation below
regarding possible research and testing. 

 

33.     Single letters at the second level: 

 

34.     Single letters are presently allocated in many ccTLDs, and about
five are allocated in the .com and .net space. Although we know that it
works, RFC 1535 notes conflicts when you get conflicts in names between
different levels and resolvers append something on in order to 'help'
the user. Example, type in a single word in the search bar, and many
browsers append the extension '.com'.  [DELETE:  Problems exist when you
have single letters at both top and second level; thus single
letter.single letter has potential for confusion.] 

 

35.     Recommendation: 

 

36.     Release single letters at second level, with defined allocation
method(s) described. [defined allocation methods??]

 

 

37.     Combinations of numbers and letters at the top level and at the
second level: 

 

38.     Do not see a technical problem, although there may  be a need to
ensure the order of the appearance of the digit. Note:   3M exists at
the second level, as does V6. 

 

39.     Recommendation: 
40.     Combinations of single letter + a single digit should be
allowable at the top level and the second level. Reverify the order with
technical experts. 

 

41.     Question: does  order of number/letter or letter/number matter.
See RFC >> that says a domain name must begin with... 

 

42.     Issue of '-' in conjunction with a number or a letter, such as
'1-, or a-, or -'

 

43.     Okay to use between words, or names. Can have 'letter -;
digit-'. 
44.     May be problems as initial character, keeping in mind RFC __
that says that a domain name must begin with letter or number [to be
quoted here]

 

45.     Recommendation: Allow letter-, or digit-, as long as there is no
problem with interactions regarding digit-.

 

46.     Possible Potential for Further Work on Single letters at the top
level: 

 

47.     [DELETE:  To be further explored: although the depth of support
for further work is not  yet determined:]  Examine whether there is
support or need for  further work on single letters at the top level as
TLD string. There is not clear support for this recommendation; the
scope and scale of needed work is unclear and would need to be completed
in a further work effort. It is not yet clear whether the study can be
fully defined by the end of the May 10 deadline, or whether the RN-WG
might suggest this as a further down the road imitative, once the nearer
term recommendations are finalized and approved and under
implementation.  Once it is scoped, it is possible that a 3 month - 6
month period [or less] could identify the range of considerations that
exist in the use of single letters at the top level. 

 

48.     There is not intent to hold up any of the other recommendations
in order to address this question.

 

 

49.     Consider whether there is support for a form of the study that
was organized/supported and funded by ICANN related to IDNs regarding
the use of single letters as a TLD. 

 

50.     To do this, the TF would have to develop a clear set of problem
statement/questions that ask the technical community for clear and
explicit advice related to the existence of single letters at the top
level, assuming that there are single letters at the second level in
existence. 

 

Prepared in draft by 

Marilyn Cade

April 24, 2007