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... 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
