On 30 Apr 2015, at 16:40, George Michaelson wrote: > economy and economycode is a useful concept sometimes. it avoids the CN/TW > issue. and encompasses HK. > > state or territory can be useful. covers some of the intermediate things. > eg much of the CIS is a 'transitional state' according to the UN. > > iso-3166 encompasses non-state entities, AP is reserved for the african > fisheries forum. > > EU is delegated. its not the same as INT. > > BTW, at some stage, its possible the economies will usurp the 3 letter > codes and assert a right to have them in the DNS...
Also note that there are ccTLDs allocated for codes that are not registered in ISO3166 (UK, EU etc). Suggested new text: ccTLD -- A TLD that is allocated to distinct economies. Historically, these were two-letter TLDs, and were allocated to economies using the two letter code for the economy taken from the ISO 3166-1 alpha-2 standard [ISO3166] although exceptions exists. In recent years, there have been allocations of TLDs that conform to IDNA2008 ([RFC5890], [RFC5891], [RFC5892], [RFC5893], and [RFC5894]); these are still treated as ccTLDs for policy purposes. Patrik > On Thu, Apr 30, 2015 at 4:35 PM, Andrew Sullivan <a...@anvilwalrusden.com> > wrote: > >> On Wed, Apr 29, 2015 at 07:28:21PM +0000, Edward Lewis wrote: >>> #ccTLD -- A TLD that is allocated to a country. Historically, these >>> #were two-letter TLDs, and were allocated to countries using the two- >>> #letter code from the ISO 3166-1 alpha-2 standard [ISO3166]. In >>> #recent years, there have been allocations of TLDs that conform to >>> #IDNA2008 ([RFC5890], [RFC5891], [RFC5892], [RFC5893], and [RFC5894]); >>> #these are still treated as ccTLDs for policy purposes. >>> >>> "Country" is a loaded term. I don't have a better suggestion in mind but >>> there are many instances where a ccTLD is a territory, etc. I don't mean >>> to open a rathole, just point this out. >> >> If we changed this to say, "A TLD that is allocated using the UN >> country list using the the two-letter code from the ISO 3166-1 alpha-2 >> standard [ISO3166]," would that address your concern? >> >>> Might as well also list sTLD for sponsored. Technically there is no >>> difference, it's all in the way the registry has been instituted. >> >> ICANN's own policies don't actually seem to enforce the sTLD/gTLD >> distinction, and nobody ever mentions sTLDs, so I'd as soon leave it >> out. >> >>> I never thought NODATA meant NOERROR, just simply an empty answer >> section. >> >> NODATA comes with a NOERROR header, or it's not a NODATA response. >> >>> # 6. Zones >>> >>> #Parent -- The domain in which the Child is registered. (Quoted from >>> #[RFC7344], section 1.1) Earlier, "parent name server" was defined in >>> #[RFC0882] as "the name server that has authority over the place in >>> #the domain name space that will hold the new domain". >>> >>> Speaking from personal experience, I'd use "delegated" and not >> registered. >>> In my world, there is a distinction in what is "registered" and what is >>> "delegated." I don't mean to derail this into a registry vs. DNS >>> operations discussion, just saying that the term "registered" means >>> something different in a field (registration of domain names and internet >>> numbers) very close to DNS. >> >> We want to cleave to the quoted documents, but do you wnat us to add >> discussion about the distinction between "registration" and >> "delegation"? There's in fact a distinction also with "allocation", >> but I'm not sure it belongs here. >> >>> #Delegation -- The process by which a separate zone is created in the >>> #name space beneath the apex of a given domain. Delegation happens >>> #when an NS RRset is added in the parent zone for the child origin, >>> #and a corresponding zone apex is created at the child origin. >>> #Delegation inherently happens at a zone cut. >>> >>> I agreed up until "and a corresponding..." Once the parent creates the >>> zone cut, the delegation is made. The distinction is that in the world >> of >>> operations, the child's servers may be unavailable (down or cut off the >>> net). The delegation is still there, no one can confirm the >>> "corresponding" stuff mentioned here. >> >> Hmm, this is an interesting point. >> >>> Vice versa, once the parent removes >>> the NS set, the delegation is removed regardless of what the child >>> "thinks." >> >> Well, effectively maybe not. If a resolver "sticks" on the child, >> then the delegation won't move regardless. >> >>> #Referrals -- ... Historically, many >>> #authoritative servers answered with a referral to the root zone when >>> #queried for a name for which they were not authoritative, but this >>> #practice has declined. >>> >>> Not declined - seen as a vulnerability and removed from code. >> >> That's one kind of decline, isn't it? >> >> A >> >> -- >> Andrew Sullivan >> a...@anvilwalrusden.com >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
