Like Scott, I think I understand Rick's note, and like Scott, something in my understanding needs checking.
> > The only entity that can define what is and is not allowed in domain names > > (not host names) is ICANN and although they have doen it before, it > > doesn't happen often. True for those operators that delegate this policy to ICANN. This includes gTLD (unrestricted and restricted), the .AU ccTLD operator. At the moment, I'm personally not aware of any other TLD operator that has delegated this policy to ICANN. > > If you want to continue down this path I suggest you submit a proposal to > > the DNSO and that it is not a path we wish to take in this wg. Assuming that the scope of the policy sought includes the set of operators and their domains for which ICANN, and thus its DNSO, are the delegated policy formation bodies. It is worth reminding ourselves from time to time, that some IANA root TLD operators (other than Verisign) have operational practices that differ from the current ICANN gTLD contract. ... > > The responsibility and expertise to define domain and host name formats lies > with the IETF. Assuming the ICANN MOU, s/IETF/PSO/, and of course we all hope that in this context, the ITU, W3C, and ETSI are non-contributory. Again, ICANN itself is binding as the policy making body only where there is consent, currently limited to com/net/org/info/biz/pro/museum/coop/aero, and AU, again AFAIK. > ... The DNSO is responsible for determining the policy aspects > of how those identifiers are used. This implies that the IETF should strive > to develop policy-neutral engineering solutions. Which leads me back to zone-scope, which existed in version 4 of the Seng/ Wenzel draft as [35], and as [30] in versions 5, and 6 of that draft. It is a policy to require zone-scope mechanism(s) not exist in the IETF work- product, and that policy promotes some local policy, possibly .com's to global scope. It is a policy to require zone-scope mechanism(s) do exist in the IETF work- product, and that policy is neutral w.r.t. policies and scope. Even when some "law of least astonishment" is cited as an excuse to pursue a single-scope mechanism, in my mind, within the framework of rfc2826, and the MOU, the "customer" is not ICANN uniquely, but ICANN and the TLD and root zone operators, and they don't agree on policy. > Is the issue of mixed TC and SC an engineering issue, or a policy issue? I > haven't seen much on this thread to suggest that an engineering issue > exists. If registrar or registry guidelines are being described as the way > to resolve the issue, Rick is probably right about this not being an IETF > issue, but a DNSO issue. Here I differ with my learned colleges. I know we are dealing with a problem of mechanism, and if it were a DNSO issue, there is little reason to conclude that the gTLD and ccTLD registries would, absent controlling policy, construe identical, or even consistent guidelines. I appreciate the opportunity to have observed ICANN process first-hand at all three of its meetings this year, and to have observed CDNC and JET process as well. It has been educational. Eric
