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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
