On 17 Nov 2014, at 15:49, Romeo Zwart <romeo.zwart@ripe.net> wrote:
1/ While the RIPE NCC controls 62/8, the delegations under it are not necessarily under our control. Specifically the /24 mentioned in the original post is part of 62.76/16, which is delegated to the Russian Institute for Public Networks (RIPN). RIPN does not sign its zones, therefore we have been using an out of band mechanism.
Surely sticking this in DLV should be a decision for the holder of that /24 and not the NCC? Though it seems 62.76.151/24 supports an anycast instance of K. Hmmm... If that's the case, it opens even more questions.
2/ The RIPE NCC has been publishing this key material out of band for historical reasons. If there is a consensus in the WG that this is no longer needed, or even undesirable, we are happy to phase out the use of the DLV.
Glad to hear that. Though the WG has still to decide about this.
3/ RIPE NCC has been assigned ripe.int in the early 2000's. We are currently not using ripe.int, other than by redirecting to ripe.net. If the community advises the RIPE NCC to request IANA to sign .int, we can spend some effort on this, but we'd like to follow up on this separately.
I am not sure a request IANA to sign .int is worth doing any time soon. Signing .int will almost certainly be blocked by layer 9+ issues until long after the dust has settled on the NTIA-IANA transition. Besides, the few voices on this thread that have mentioned ripe.int appear to be asking for it to be removed, not for it to be signed in a signed TLD. I think the WG needs to reach consensus on what should be done here.
4/ Ripen.cc is a historical artifact. RIPE NCC is not currently using it and we are not planning any future use. Releasing the domain is an operational decision that we may take in the future.
Just kill it! IMO the domain should get removed from DLV as soon as it is prudent to do so: which probably means immediately. ripen.cc can die on its renewal date. Though these too should be consensus decisions for the WG. The NCC needs to have a procedure to review its DLV entries -- report to the WG once a year? -- and an exit strategy for the cruft^W names and keys it has there. It seems silly to be co-ordinating a key rollover for DLV material that probably isn't getting used for domain names that aren't getting used.