[address-policy-wg] 2008-05 - Anycast assignments for ENUM/TLD registries
- Previous message (by thread): [address-policy-wg] Anycast assignments for ENUM/TLD registries
- Next message (by thread): [address-policy-wg] 2008-05 New Draft Documents Published (Anycasting Assignments for TLDs and Tier 0/1 ENUM)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Wilfried Woeber, UniVie/ACOnet
Woeber at CC.UniVie.ac.at
Sun Apr 19 13:32:00 CEST 2009
Editorial - B C wrote: > On Fri, Apr 17, 2009 at 2:34 PM, Jim Reid <jim at rfc1035.com> wrote: > >>Apologies for providing a meaningful Subject: header. :-) Could we please keep the policy proposal ID in the Subject? Thanks, Wilfried. >>On Apr 15, 2009, at 14:43, Peter Koch wrote: >> >> >>>"TLD operators as defined by IANA" may be a well intended phrase, but many >>>affected registries would reject being "defined" by IANA. >> >>Peter, I feel you're being overly picky here. If an organisation doesn't >>like the wording of some policy then they are of course free to choose not >>to enjoy the benefits of that policy. Better still, they could suggest text >>that makes them feel more comfortable. :-) I think the wording Ondrej has >>proposed should provide that level of comfort. >> > > > This wording will be in the new version. > > >>I'm ultimately guilty of the insertion of "as defined by IANA". The intent >>here was to come up with a policy that would allow anycast assignments to >>real TLD registries (ie those in the IANA database) rather than for whatever >>gunk lies in so-called alternate roots and so forth. The same goes for the >>ENUM Tier-1 registries, though in this case it's ITU and not IANA that has >>the definitive database for that. Again, the intent here was to have policy >>wording that would prevent charlatans setting up bogus-e164.com (or >>whatever) and then come to NCC claiming an entitlement of 200 or so Tier-1 >>"country code" anycast assignments: ie essentially having alternate roots in >>a slightly different guise. >> >>In an earlier discussion about this draft I contributed text containing the >>URLs for the IANA and ITU databases. This was considered a Bad Idea because >>these links could change. So that's what provoked the "as defined by" >>revision in the next iteration of the document. >> >> >>>This layer 9 stuff >>>aside, I'm still uncertain whether the assignment goes to the registry >>>itself >>>or to some operator who provides name service for TLDs (or ENUM, for that >>>matter). The former makes more sense to me. >> >>I am still not certain the latest draft resolves this confusion either. >> > > > This has also been addressed in the newest version. > > > >>I strongly believe that the assignment should go to the registry and not the >>provider of registry or DNS services for that registry. Even if these are >>the same entity, their roles and their responsibilities are different. On a >>practical level, the TLD or Tier-1 administrator might want to split their >>anycast assignment between DNS providers: say discrete /24s to each of them. >>This wouldn't be easy to do (or change) if that anycast assignment was held >>by their registry operator. And suppose the registry has a serious >>disagreement its registry operator or the back-end provider changes when the >>contract goes out to tender. >> >> >>>"TLD manager/administrator as described in RFC 1591" might be more >>>acceptable. >> >>IMO the language that needs to be use here has somehow to be linked to the >>TLD managers that are known to the IANA database. RFC 1591 seems too fuzzy >>and very out of date. The excellent text Ondrej suggested -- "designated >>manager for TLD as delegated by IANA" -- works for me. I hope it will for >>everyone else. >> > > > This has also been added to the new version. > > > >>>Similar considerations apply to "ENUM operators as defined by the ITU". >> >>I don't think so. ITU implicitly define this as they have effective >>administrative control for the delegations under e164.arpa. Ondrej's come up >>with better text for that too: "ENUM administrator as assigned by the ITU". >>Can we agree to use that? >> >> >>>OK, 2nd occurence, but s/Critical DNS infrastructure/the purpose >>>justifying the >>>assignment/. >> >>Again, I think you're being unduly picky Peter. IIRC there was a rough >>consensus on the policy draft using "Critical DNS Infrastructure" as a >>definition of the DNS servers needed for the TLDs in the IANA database and >>the Tier-0/1 ENUM domains in the ITU database. If you don't like the word >>"Critical" here, let's choose something else like "Qualifying" or >>"Eligible". OTOH, this is for critical DNS infrastructure so there's no >>reason IMO for not making that explicit. >> >> > > > I have removed the "critical dns infrastructure wording" from the > document and replaced it with something a little less controversial > but meaningful. > > > I think/hope that the new draft Ondrej and I submitted today should > address everything below and satisfy points made here by everybody > (It's Friday and hence I'm feeling positive) it will be made available > shortly after the review period ends for current version (23/04) > > Brett > >
- Previous message (by thread): [address-policy-wg] Anycast assignments for ENUM/TLD registries
- Next message (by thread): [address-policy-wg] 2008-05 New Draft Documents Published (Anycasting Assignments for TLDs and Tier 0/1 ENUM)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]