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

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

If we are including expert testimony, it is critical that we quote their
testimony rather than report an interpretation of what they said.  If
for some reason that it is not possible to quote their exact testimony,
then we must make sure that we accurately represent what they said.
 
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-sl-wg@xxxxxxxxx
[mailto:owner-gnso-sl-wg@xxxxxxxxx] On Behalf Of Marilyn Cade
        Sent: Sunday, April 29, 2007 9:06 PM
        To: mxr@xxxxxxxxxxxxx; gnso-sl-wg@xxxxxxxxx
        Subject: 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
        
        

        THANKS, Mike,for your initial suggested edits. Undersand you are
busy at INTA.  I think some of your other INTA counterparts are working
around being available, though, for some of the meetings of the WG. Iis
there a way to get you available at least for the WG call? I thought
that was after INTA... which ends Wednesday, right?

         

        .....a couple of thoughts on your comments:  

        ITEM 30 came from the technical experts. I don't think we can
'edit'out their comments. but I may be misunderstanding what you are
suggesting as an 'edit'. 

         

        32. not sure what 'deemed insubstantial' means. can you clarify
what you were suggesting there? Isn't it simply: 'resolve technical
questions"? that seems a simple and accurate statement. but I may have
not understood what you wanted to convey with 'deemed insubstantial',
and it may be an important addition, so wanted to understand your
thoughts on that. 

        I see that you suggested deletion of the comment about problems
at top/second level. 

         

        I can't support that. 

         

        As the transcript shows, and as various notes from participants
will note,  both technical experts referenced that as a conflict. I was
thinking that the sub group could better formulate the necessary
technical test, as I tried to reference in 46/etc. 

        The technical trial would validate any problems, and whether
single letters at top level can coexist at second level, or if
resistrictions are needed. but it seems that really, that can  be a
proposal from the sub group/and then the issue is getting full WG
support, and then getting Council support. and if the recommendation is
that single leltters at top level have to have restrictions at second
level, taht seems a fairly straight forward recommendation, once the
technical trial on single letters at teh top level is undertaken by an
independent entity/credible entity. 

         

        It seems that in any case, a technical test is needed. 

        That seemed to be supported by the two technical experts.

         

        I'll look at your suggested edits to my initial summary further.
thanks for taking the time to offer comments.  

        regards, Marilyn Cade

        
        
         

                
________________________________

                From: "Mike Rodenbaugh" <mxr@xxxxxxxxxxxxx>
                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
                Date: Sun, 29 Apr 2007 16:21:44 -0700
                
                

                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