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

["Shatan, Gregory S." <GShatan@xxxxxxxxxxxxx>]

I think this discussion is somewhat overtaken by the emails from Chuck
and Liz.
 
Based on the emails from Chuck and Liz, it appears that we must use
quotes from the technical experts from the transcript, rather than
summaries of what they said.  Where technical experts submit written
comments, this issue is moot.  We could consider on the call whether we
want to ask our experts to prepare written comments, but my initial
reaction to my own suggestion is (a) that is an imposition and (b) we
have the transcript and should use that.  We will need to show them the
report and give them a chance to edit their comments, in any event. 

  _____  

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