ICANN Email Archives: [gnso-sl-wg]

ICANN ICANN Email List Archives

[gnso-sl-wg]

<<< Chronological Index >>> <<< Thread Index >>>

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

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
From: "Marilyn Cade" <marilynscade@xxxxxxxxxxx>
Date: Sun, 29 Apr 2007 21:06:02 -0400

<html><div style='background-color:'><P>THANKS, Mike,for your initial suggested edits. 
Undersand you are busy at INTA.&nbsp;&nbsp;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?</P>
<P>&nbsp;</P>
<P>.....a couple of thoughts on your comments:&nbsp; </P>
<P>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'. </P>
<P>&nbsp;</P>
<P>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. </P>
<P>I see that you suggested&nbsp;deletion of&nbsp;the comment about problems at 
top/second level. </P>
<P>&nbsp;</P>
<P>I can't support that. </P>
<P>&nbsp;</P>
<P>As the transcript shows, and as various notes from participants will note,&nbsp; 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.&nbsp;</P>
<P>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&nbsp; 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. </P>
<P>&nbsp;</P>
<P>It seems that in any case, a technical test is needed. </P>
<P>That seemed to be supported by the two technical experts.</P>
<P>&nbsp;</P>
<P>I'll look at your suggested edits to my initial summary further. thanks for taking the 
time to offer comments.&nbsp; </P>
<P>regards, Marilyn Cade</P>
<P><BR><BR>&nbsp;</P>
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #a0c6e5 2px solid; MARGIN-RIGHT: 
0px"><FONT style="FONT-SIZE: 11px; FONT-FAMILY: tahoma,sans-serif">
<HR color=#a0c6e5 SIZE=1>
From: <I>"Mike Rodenbaugh" &lt;mxr@xxxxxxxxxxxxx&gt;</I><BR>To: <I>&lt;gnso-sl-wg@xxxxxxxxx&gt;</I><BR>Subject: 
<I>[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><BR>Date: <I>Sun, 29 Apr 2007 16:21:44 -0700</I><BR><BR>
<META content="Microsoft SafeHTML" name=Generator>
<STYLE>
.shape
{;}
</STYLE>

<STYLE>
</STYLE>

<STYLE>
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;font-family:'Times New 
Roman';}
a:link, span.MsoHyperlink
{color:blue;text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:purple;text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{margin-right:0in;margin-left:0in;font-size:12.0pt;font-family:'Times New 
Roman';}
span.EmailStyle17
{font-family:Arial;color:navy;}
span.EmailStyle18
{font-family:Arial;color:navy;}
span.EmailStyle19
{font-family:Arial;color:navy;}
@page Section1
{size:8.5in 11.0in;margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
{page:Section1;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}

</STYLE>

<DIV class=Section1> 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.   <DIV> 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.</DIV> <DIV> <DIV class=MsoNormal style="TEXT-ALIGN: center" align=center> <HR align=center width="100%" SIZE=2> </DIV> 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</DIV>   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:   <OL style="MARGIN-TOP: 0in" type=1> <LI class=MsoNormal>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 : </LI> <LI class=MsoNormal>Insert list of participants. </LI></OL>       <OL style="MARGIN-TOP: 0in" type=1 start=3> <LI class=MsoNormal>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. </LI></OL>   <OL style="MARGIN-TOP: 0in" type=1 start=4> <LI class=MsoNormal>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. </LI></OL>   <OL style="MARGIN-TOP: 0in" type=1 start=5> <LI class=MsoNormal>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. </LI></OL>   <OL style="MARGIN-TOP: 0in" type=1 start=6> <LI class=MsoNormal>In general, the questions discussed with the technical experts addressed the following:</LI></OL>   <OL style="MARGIN-TOP: 0in" type=1 start=7> <LI class=MsoNormal>Are there technical issues at both top level and second level?  Is there an interaction </LI> <LI class=MsoNormal>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.</LI></OL>   <OL style="MARGIN-TOP: 0in" type=1 start=9> <LI class=MsoNormal>Are there other known or suspected concerns about single characters, whether numbers, letters, or symbols at top level? </LI></OL>   <OL style="MARGIN-TOP: 0in" type=1 start=10> <LI class=MsoNormal>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?] </LI></OL>   <OL style="MARGIN-TOP: 0in" type=1 start=11> <LI class=MsoNormal>When issues or technical concerns/questions are identified, how and to what extent are the consequences manageable? How can that be determined? By whom? </LI></OL>   <OL style="MARGIN-TOP: 0in" type=1 start=12> <LI class=MsoNormal>[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?] </LI> <LI class=MsoNormal style="MARGIN-BOTTOM: 12pt"> [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?</LI></OL>   <OL style="MARGIN-TOP: 0in" type=1 start=14> <LI class=MsoNormal>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.] </LI></OL>   <OL style="MARGIN-TOP: 0in" type=1 start=15> <LI class=MsoNormal>One of the experts suggested that the TF/WG divide their considerations into ?groups?, such as: </LI> <UL style="MARGIN-TOP: 0in" type=disc> <LI class=MsoNormal>What the Name space allows</LI> <LI class=MsoNormal>What the resolvers can do</LI> <LI class=MsoNormal>What happens at the application layer</LI></UL></OL>   <OL style="MARGIN-TOP: 0in" type=1 start=16> <LI class=MsoNormal>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. </LI></OL>   <OL style="MARGIN-TOP: 0in" type=1 start=17> <LI class=MsoNormal>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.</LI></OL>   <OL style="MARGIN-TOP: 0in" type=1 start=18> <LI class=MsoNormal>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. </LI></OL>   <OL style="MARGIN-TOP: 0in" type=1 start=19> <LI class=MsoNormal>[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.]  </LI></OL>   <OL style="MARGIN-TOP: 0in" type=1 start=20> <LI class=MsoNormal>Draft Recommendations: </LI></OL>   <OL style="MARGIN-TOP: 0in" type=1 start=21> <LI class=MsoNormal>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.</LI></OL>   <OL style="MARGIN-TOP: 0in" type=1 start=22> <LI class=MsoNormal>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. </LI></OL>   <OL style="MARGIN-TOP: 0in" type=1 start=23> <LI class=MsoNormal>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. </LI></OL>   <OL style="MARGIN-TOP: 0in" type=1 start=24> <LI class=MsoNormal>Recommendation: </LI></OL>   <OL style="MARGIN-TOP: 0in" type=1 start=25> <LI class=MsoNormal>Maintain reservation of single numbers at the top level. </LI> <LI class=MsoNormal>Continue to allow allocation of numbers at the second level, including single numbers. </LI></OL>   <OL style="MARGIN-TOP: 0in" type=1 start=26> <UL style="MARGIN-TOP: 0in" type=disc> <LI class=MsoNormal>Need to verify that single numbers at the second level are in use today, widely, and are not encountering application problems. </LI></UL></OL>     <OL style="MARGIN-TOP: 0in" type=1 start=27> <LI class=MsoNormal style="MARGIN-BOTTOM: 12pt">Single Letters at the Top Level:</LI> <LI class=MsoNormal>Single letters do not presently exist at the top level, and ICANN rejected an application in the initial ?round?.</LI></OL>   <OL style="MARGIN-TOP: 0in" type=1 start=29> <LI class=MsoNormal>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. </LI></OL>   <OL style="MARGIN-TOP: 0in" type=1 start=30> <LI class=MsoNormal>[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].] </LI></OL>   <OL style="MARGIN-TOP: 0in" type=1 start=31> <LI class=MsoNormal>Recommendation:</LI> <LI class=MsoNormal>Reserve single letters at the top level [until technical issues resolved or deemed insubstantial]. See further recommendation below regarding possible research and testing. </LI></OL>   <OL style="MARGIN-TOP: 0in" type=1 start=33> <LI class=MsoNormal>Single letters at the second level: </LI></OL>   <OL style="MARGIN-TOP: 0in" type=1 start=34> <LI class=MsoNormal>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.] </LI></OL>   <OL style="MARGIN-TOP: 0in" type=1 start=35> <LI class=MsoNormal>Recommendation: </LI></OL>   <OL style="MARGIN-TOP: 0in" type=1 start=36> <LI class=MsoNormal>Release single letters at second level, with defined allocation method(s) described. [defined allocation methods??]</LI></OL>     <OL style="MARGIN-TOP: 0in" type=1 start=37> <LI class=MsoNormal>Combinations of numbers and letters at the top level and at the second level: </LI></OL>   <OL style="MARGIN-TOP: 0in" type=1 start=38> <LI class=MsoNormal>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. </LI></OL>   <OL style="MARGIN-TOP: 0in" type=1 start=39> <LI class=MsoNormal>Recommendation: </LI> <LI class=MsoNormal>Combinations of single letter + a single digit should be allowable at the top level and the second level. Reverify the order with technical experts. </LI></OL>   <OL style="MARGIN-TOP: 0in" type=1 start=41> <LI class=MsoNormal>Question: does  order of number/letter or letter/number matter. See RFC >> that says a domain name must begin with? </LI></OL>   <OL style="MARGIN-TOP: 0in" type=1 start=42> <LI class=MsoNormal>Issue of ?-? in conjunction with a number or a letter, such as ?1-, or a-, or ??</LI></OL>   <OL style="MARGIN-TOP: 0in" type=1 start=43> <LI class=MsoNormal>Okay to use between words, or names. Can have ?letter -; digit-?. </LI> <LI class=MsoNormal>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]</LI></OL>   <OL style="MARGIN-TOP: 0in" type=1 start=45> <LI class=MsoNormal>Recommendation: Allow letter-, or digit-, as long as there is no problem with interactions regarding digit-.</LI></OL>   <OL style="MARGIN-TOP: 0in" type=1 start=46> <LI class=MsoNormal>Possible Potential for Further Work on Single letters at the top level: </LI></OL>   <OL style="MARGIN-TOP: 0in" type=1 start=47> <LI class=MsoNormal>[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. </LI></OL>   <OL style="MARGIN-TOP: 0in" type=1 start=48> <LI class=MsoNormal>There is not intent to hold up any of the other recommendations in order to address this question.</LI></OL>     <OL style="MARGIN-TOP: 0in" type=1 start=49> <LI class=MsoNormal>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. </LI></OL>   <OL style="MARGIN-TOP: 0in" type=1 start=50> <LI class=MsoNormal>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. </LI></OL>   Prepared in draft by Marilyn Cade April 24, 2007  </DIV> </BLOCKQUOTE></div></html>

Follow-Ups:
- 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
  - From: Gomes, Chuck

References:
- [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
  - From: Mike Rodenbaugh

<<< Chronological Index >>> <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy