Unsubscribe

[Eric Ding <[e-mail]>]

Unsubscribe

> On Jun 30, 2017, at 3:00 PM, [e-mail] wrote:
> 
> Send ietf mailing list submissions to
>    [e-mail]
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>    https://www.ietf.org/mailman/listinfo/ietf
> or, via email, send a message with subject or body 'help' to
>    [e-mail]
> 
> You can reach the person managing the list at
>    [e-mail]
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ietf digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: (Daniel Karrenberg)
>   2. Re: (Donald Eastlake)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Fri, 30 Jun 2017 18:53:27 +0200
> From: Daniel Karrenberg <[e-mail]>
> To: [e-mail]
> Subject: Re:
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset=utf-8
> 
> john,
> 
> your eloquently told story agrees with personal memory and my particular
> version of reality ;-).
> 
> I know for a fact that ISO3166 at the time contained at least two letter
> alphabetic, three letter alphabetic and numeric codes for each country
> or territory recognized by the United Nations.
> 
> I also distinctly remember a number of conversations with Jon about DNS
> "going international". Jon wisely saw that IANA needed an external
> authority to decide what was a country. After considering several such
> authorities, the United nations appeared the most widely agreed one.
>> From there it was but a short step to ISO3166. The choice for two letter
> alphabetic codes was also straightforward: there were no two letter TLDs
> at the time and that guaranteed that there would be no clashes with
> exiting TLDs. [1]
> 
> So I would argue that ASCII ccTLDs are indeed meant to be exactly two
> letters. If only to avoid clashes with future changes to ISO3166 I would
> consider it to be a Bad Idea to allocate two letter ASCII strings for
> any other purpose. This is why I have spoken up against ".EU" until the
> ISO3166 maintenance agency published it as a "reserved" code.
> 
> Conversely it would be problematic now to have three letter ASCII ccTLDs
> unless there is a clear agreement with ISO that they will never allocate
> a three letter code that already exists as a gTLD. Afaik there are no
> clashes right now, but past results are not a guarantee for the future.
> It is never a good idea to have two 'authorities' over one part of a
> name space.
> 
> dfk
> 
> [1] UK appeared at different times in at least two realities that have
> been recounted to me. ;-) But there was no clash in ISO3166 at the time.
> 
> 
> 
> 
>> On 1.01.70 1:00 ,  wrote:
>> 
>> 
>> --On Friday, June 30, 2017 07:31 +0200 Olivier MJ
>> Cr?pin-Leblond <[e-mail]> wrote:
>> 
>>> Hello all,
>>> 
>>> I am reading RFC1591 and RFC3071 and have a couple of simple
>>> questions: 1. Is a ccTLD defined as restricted to 2-letter
>>> country codes (ISO3166 alpha 2), or could that include
>>> 3-letter country codes in the ISO3166 list (ISO3166 alpha 3)?
>>> 2. RFC1591 appears to point at 2-letter, but many other parts
>>> of this RFC are obsolete - so does this RFC remain valid?
>> 
>> Olivier,
>> 
>> First, it is important to understand that RFC 1591 was never an
>> IETF document.  It was an IANA policy document, dating from a
>> time that IANA operated largely independent of the IETF (the
>> IETF could _request_ registration actions or registry creation,
>> but not _order_ them and so could others) and, while it
>> (deliberately, IIR) didn't strongly call that out, reflecting
>> policies and norms that had been in effect, although evolving
>> somewhat, long before the time it was published.
>> 
>> It may also be useful to recall that the practical authority of
>> IANA in the DNS space at that time was derived from two things.
>> The first is what is known (especially next week) on this side
>> of the pond as the "consent of the governed": just about
>> everyone understood that a central registration and allocation
>> authority was important and, with one important exception [1],
>> no one had something they believed was a better idea that they
>> were anxious to propose.  Yes, in theory the US Government could
>> have stepped in, but they didn't and their behavior was such as
>> to lead everyone to believe that they wouldn't.   The second was
>> that there was a general belief that, if the rules, especially
>> those involving principles of responsible behavior that 1591
>> invokes with the "trustee for the ... community" language, were
>> violated IANA had both the authority and the will to, e.g., make
>> changes in delegations to parties who would be more responsible.
>> 
>> There were also a number of things -- both "rules" and
>> explanations -- that didn't go into 1591, either because we
>> didn't think of them (or think they were necessary) or because
>> Jon saw them simply as things he wasn't going to allow.   The
>> now-famous "will be alphabetic" phrasing in RFC 1123 about TLD
>> labels was typical: Jon knew he simply was not going to allow
>> TLD names containing anything other than ASCII letters.
>> 
>> Whether the principles underlying 1591 are "obsolete" or not
>> depends on some complicated questions involving one's view of
>> the Internet and the role of the DNS (see
>> draft-klensin-dns-function-considerations as well as several
>> RFCs that followed 1591.  Certainly, when 1591 was written, we
>> didn't anticipate either ICANN or the rise of the domain name
>> business (and, arguably, its dominance in decision-making).
>> 
>> Now, with that background, let me try to answer your question.
>> First, the ccTLD naming model was strictly limited to allocated
>> codes in what is now called ISO 3166-1 alpha-2 [1].
>> Specifically, no use of the reserved list (not sure that existed
>> at the time either), no private-use codes, no codes allocated by
>> IANA rather than a body fully responsible to ISO TC 46, and,
>> while there are a couple of famous mistakes (history and
>> explanation on request if relevant) no allocations on
>> speculation.
>> 
>> One of those rules was, AFAKK, never formally published although
>> at least part of it was widely understood.  That was that TLD
>> labels came in categories that could be determined by length,
>> such that filters and algorithms could be based on those
>> categories.  The rule was 2-3.4+, i.e.,
>> 
>> * All two-letter labels were country codes derived from
>>    3166 alpha-2.
>> * All three letter labels were generic TLDs (not all of
>>    which were managed under IANA supervision).
>> * All labels of four characters or more were either the
>>    specific string "ARPA" (which was originally intended to
>>    be temporary and transitional) or what is now known as a
>>    "special use name", i.e., one that is not part of the
>>    global DNS or that was expected to be processed using
>>    some non-DNS mechanism.
>> 
>> ICANN staff were warned about that rule in the 1999 period but
>> decided to allow TLD applications for gTLDs with labels longer
>> than three characters and to not identify the issue to
>> applicants.   Many of the issues that are now seen as "universal
>> acceptance" problems are the result of that decision.  Whether
>> one assumed at the time, or concludes now, that it was a
>> rational, consensus, decision to favor applicant choice and
>> consequent competition in the TLD marketplace over that
>> historical rule or, even the controversies about special names,
>> a screwup and/or show of arrogance is very much in the mind of
>> the beholder.
>> 
>> Similarly, ICANN clearly broke the 1591 rules in allocating "EU"
>> as a TLD label.  It is not an ISO 3166-1 alpha-2 registered
>> country code and it violates some territorial overlap rules that
>> are intrinsic to bother 3166-1 and the assumptions underlying
>> 1591.  At a different end of the problem, IANA's rules (pointed
>> to but maybe not explicit enough) is that, if a country
>> convinced 3166/MA to change its code, there needed to be a plan
>> in place to remove the older TLD within a reasonably short
>> period before the new code would be delegated (on a "one
>> territory, one code" principle)).  IIR, there was such an
>> agreement about "SU" before "RU" was delegated, but ICANN has
>> never succeeded in getting rid of "SU", violating that principle.
>> 
>> All of this is further complicated by IDN TLDs, where new ones
>> associated with countries are not limited to two characters
>> (even in their original scripts); non-country political entities
>> are allowed (if one counts GOV. MIL, and maybe INT, they have
>> always been allowed, but those are probably a bit different(;
>> and the relationships between 3166 alpha-2 ccTLDs and their IDN
>> relatives have never really been spelled out (despite the length
>> of the ccTLD Fast Track Procedure.
>> 
>> Whether that makes 3166 partially or completely obsolete is a
>> matter of personal judgment.   Because it was an IANA document,
>> the IETF Protocol Police would never have arrested anyone for
>> violating it.  Unlike the IETF and its relationship to the
>> Protocol Police, IANA did have the ability to enforce its
>> provisions (and did).  ICANN has clearly demonstrated a
>> willingness to violate some of its provisions (explicit or
>> implied) and it appears that, both prior and subsequent to the
>> recent "IANA transition", there is no one to tell them that they
>> cannot do so.  My personal opinion that the Internet would be
>> much better off if the principles of 1591, especially the
>> requirement that registries be required to act in the best
>> interests of the global Internet community, were followed and
>> enforced (see draft-klensin-idna-rfc5891bis for the specific
>> IDNA case) are probably worth a cup of fancy coffee after a few
>> Euros (or equivalent) are thrown in.
>> 
>> best,
>>    john
>> 
>> 
>> [1] The dissenters were largely arguing for abandoning the DNS
>> in favor of X.500.  At least in public, that position was
>> justified on the basis of developing and future technology, with
>> the side effect of putting the top-level entities under the
>> control of the ISO and ITU registration processes.
>> Interestingly, with regard to your question, X.500 uses ISO
>> 3166-1 alpha-2 country codes as well.
>> 
>> [2]  I don't think there was more than one part of ISO 3166 at
>> the time Jon discovered or was pointed to the Standard and can't
>> remember if it contained the alpha-3 codes in addition to the
>> alpha-2 and numeric ones.  I do know that we never considered
>> anything other than the alpha-2 codes for ccTLD names, if only
>> because Jon wanted that system to be as deterministic as
>> possible with no possibility about arguments about what code
>> should be assigned that IANA needed to referee.    
>> 
>> 
>> 
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Fri, 30 Jun 2017 13:21:31 -0400
> From: Donald Eastlake <[e-mail]>
> To: Daniel Karrenberg <[e-mail]>
> Cc: IETF Discussion <[e-mail]>
> Subject: Re:
> Message-ID:
>    <[e-mail]>
> Content-Type: text/plain; charset="UTF-8"
> 
>> On Fri, Jun 30, 2017 at 12:53 PM, Daniel Karrenberg <[e-mail]> wrote:
>> john,
>> 
>> ...
>> 
>> Conversely it would be problematic now to have three letter ASCII ccTLDs
>> unless there is a clear agreement with ISO that they will never allocate
>> a three letter code that already exists as a gTLD. Afaik there are no
>> clashes right now, but past results are not a guarantee for the future.
> 
> COM is the three letter code for the Comoros Islands. I believe it is
> also used by a few entities as their TLD :-)
> 
>> It is never a good idea to have two 'authorities' over one part of a
>> name space.
>> 
>> dfk
> 
> Thanks,
> Donald
> 
> 
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> ietf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf
> 
> 
> ------------------------------
> 
> End of ietf Digest, Vol 109, Issue 92
> *************************************