On 2009-12-02, at 14:12, Phillip Hallam-Baker wrote:
The alternative would be to not use .local at all and insist on that
approach as a means of avoiding ICANNs perceived perogatives. I think
that would be a bad idea as the spec would not serve its intended
purpose.
Given the existing deployed base of this protocol, and the desire expressed by
many to document what has been deployed, I don't think that insisting that
current practice change is a useful approach.
I read on another list recently the observation that ICANN's draft applicant
guidebook already reserves LOCAL as a name that can't be registered as a new
gTLD.
http://www.icann.org/en/topics/new-gtlds/draft-evaluation-procedures-clean-04oct09-en.pdf
See the table on page 2-6.
I have no involvement with the new gTLD programme at all, but it seems possible
that concern over a clash between a "local" delegation from the root zone and
the use of "local" by Apple and others is largely semantic.
No doubt semantic concern can still be valid; however, I think the distinction
between real lurking operational danger and theoretical possibility for
conflict in the distant future is worth making.
Joe
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf