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

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

Thanks Marilyn.  I will leave it to the subgroup to continue their work
without my interference, but I do want to make one comment.  It is
important to realize that we really do not have until 10 May to continue
working.  On 10 May the full WG will have to approve final
recommendations so several days of lead time should be allowed before
then.  I would suggest that subgroup reports should be completed
including final recommendations not later than 8 May at the latest, but
I am open to discussion on this.  The key factor is the ability for the
full WG to take final action on 10 May.
 
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: owner-gnso-rn-wg@xxxxxxxxx
[mailto:owner-gnso-rn-wg@xxxxxxxxx] On Behalf Of Marilyn Cade
        Sent: Tuesday, April 24, 2007 3: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 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