<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [gnso-rn-wg] Initial draft summary of the conference call with technical experts on ASCII letters and numbers - prepared for the SubGroup
- To: GNSO RN WG <gnso-rn-wg@xxxxxxxxx>
- Subject: Re: [gnso-rn-wg] Initial draft summary of the conference call with technical experts on ASCII letters and numbers - prepared for the SubGroup
- From: Liz Williams <liz.williams@xxxxxxxxx>
- Date: Wed, 25 Apr 2007 10:19:30 +0200
Hello everyone
Thanks so much for getting on with this important element of the
Reserved Names Group.
I am not sure who is responsible for writing up the group's findings
but please ensure you use the Report Template which Chuck is going to
distribute later today. It is very important that I receive
information in similar formats so that it can easily be integrated
into the main body of the new TLDs Final Report.
Please also separate out recommendations that relate to the treatment
of names for existing registries. Whilst some of this has relevance
in terms of the technical discussion and historical precedent, I
would prefer to see that area of work submitted as a separate set of
results as the recommendations don't necessarily relate to the
introduction of new top level domains. Again, please use the Report
Template.
Please note that Chuck is right about the time limits -- I would
suggest that all work be completed by 8 May for integration into a
final report on 10 May. I anticipate releasing an updated version of
the new TLDs Final Report shortly after that -- there are
placeholders in the Report which will need to be filled prior to the
Report being distributed to the Committee.
Liz
.....................................................
Liz Williams
Senior Policy Counselor
ICANN - Brussels
+32 2 234 7874 tel
+32 2 234 7848 fax
+32 497 07 4243 mob
On 24 Apr 2007, at 22:38, Gomes, Chuck wrote:
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:
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 :
Insert list of participants.
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.
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.
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.
In general, the questions discussed with the technical experts
addressed the following:
Are there technical issues at both top level and second level? Is
there an interaction
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.
Are there other known or suspected concerns about single
characters, whether numbers,
letters, or symbols at top level?
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?
When issues or technical concerns/questions are identified, how and
to what extent are the consequences manageable? How can that be
determined? By whom?
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?
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?
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.
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
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.
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.
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.
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.
Draft Recommendations:
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.
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.
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.
Recommendation:
Maintain reservation of single numbers at the top level.
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.
Single Letters at the Top Level:
Single letters do not presently exist at the top level, and ICANN
rejected an application in the initial ‘round’.
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.
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].
Recommendation:
Reserve single letters at the top level. See further recommendation
below regarding possible research and testing.
Single letters at the second level:
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.
Recommendation:
Release single letters at second level, with defined allocation
method(s) described.
Combinations of numbers and letters at the top level and at the
second level:
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.
Recommendation:
Combinations of single letter + a single digit should be allowable
at the top level and the second level. Reverify the order with
technical experts.
Question: does order of number/letter or letter/number matter. See
RFC >> that says a domain name must begin with…
Issue of ‘-‘ in conjunction with a number or a letter, such as ‘1-,
or a-, or –‘
Okay to use between words, or names. Can have ‘letter -; digit-‘.
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]
Recommendation: Allow letter-, or digit-, as long as there is no
problem with interactions regarding digit-.
Possible Potential for Further Work on Single letters at the top
level:
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.
There is not intent to hold up any of the other recommendations in
order to address this question.
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.
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
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|