[dns-wg] {Use of} the INT TLD {by the NCC and others} [Re: RIPE NCC DNSSEC trust anchors]

Peter,

On Nov 13, 2014, at 10:50 AM, Peter Koch <pk at DENIC.DE> wrote:
> On Thu, Nov 13, 2014 at 10:28:32AM -1000, David Conrad wrote:
> 
>> On Nov 13, 2014, at 8:05 AM, Doug Barton <dougb at dougbarton.us> wrote:
>>> The NCC should simply release ripe.int, as the historical reasons for
>>> it no longer apply. (FWIW, same goes for apnic.int. None of the other
>>> RIRs have similar domains.)
>> 
>> +1
> 
> this might be the exact wrong point in time.  

Or, given the IANA Functions transition, the exact right point in time if people want to avoid a pointless political food fight.

> The NCC likely does not fulfill
> the eligibility criterie laid out in <http://www.iana.org/domains/int/policy/>,
> but obviously the registrations in INT benefit from a genaral protection
> of confidence.  

What's a "general protection of confidence"?

> Also, the 'policy' document linked above does not provide
> for a revocation mechanism.

If an entity does not meet the documented policy criteria, then it should not be in the zone. However, IANA does not unilaterally remove zones. Traditionally, the entity simply says "please remove my entry".  Are you recommending RIPE knowingly and intentionally violate a documented policy?

> So, there is a registrant in INT interested in having key material published.
> What does it take to get INT signed?

Currently, .INT is part of the IANA Functions contract. My understanding (which is NOT authoritative) is that efforts are underway to get .INT signed, but that it requires approval by NTIA.

> What is the governing body?

As mentioned, management of .INT is part of the IANA Functions contract, specifically section C.2.9.4 of http://www.ntia.doc.gov/files/ntia/publications/sf_26_pg_1-2-final_award_and_sacs.pdf.

> The 'policy'
> document bases itself on RFC 1591 but also says "The IANA no longer _grants_
> .int domain names [...]".

Um, yeah.  1591 also says "Second level names in INT are registered by the PVM at ISI.EDU." Good luck with that. I personally find the cherry picking of RFC 1591 quite fascinating. The Internet has changed a bit since 1994 and it has never been clear to me that relying on that document in contravention to existing evolved policies makes a lot of sense.

> While this particular issue is out of scope, the
> text may be read as if "the IANA" was acting with its own authority rather
> than being a registry operator bound by some policy set by the competent body.

It may be read that way, but doing so would simply be wrong.  My understanding is that the policy used for .INT registrations was created by Mike St. Johns when he was at DARPA. The fact that there are historical anomalies (e.g., tpc.int, ripe.int, apnic.int, ymca.int, etc), are, in my personal view, things that should be cleaned up, not things that should be used to stir up the political muck.

> So, again: who is to be convinced to make INT signed?

Until the IANA Functions transition, NTIA.  After the transition: that's an interesting question.

Can we just ask for RIPE.INT to be dropped from the .INT zone?  Does RIPE actually use it for anything other than a redirect to RIPE.NET?

Regards,
-drc
(ICANN CTO, but speaking only for myself. Really.)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.ripe.net/ripe/mail/archives/dns-wg/attachments/20141113/8577be87/attachment.sig>