On 17 Nov 2014, at 15:49, Romeo Zwart <romeo.zw...@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.
