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

["Marilyn Cade" <marilynscade@xxxxxxxxxxx>]

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 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?  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.     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.     
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, 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
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.     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, 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 do have stability issues.  Problems exist, especially in the
least developed world's installed infrastructure, which are not able to
resolve single letter TLDs. 

 

30.     Reachability" expected to be a serious issue.  Some versions of
BIND/associated resolvers will return NX domain' for queries against single
letter TLDs.  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. 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'.  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. 

 

 

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.     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