Re: [dns-wg] RIPE NCC DNSSEC trust anchors
Dear Collegues, Our message from last Thursday (see https://www.ripe.net/ripe/mail/archives/dns-wg/2014-November/002981.html) has stirred a significant amount of discussion. Trying to summarize the responses on the mailing list, I came to the below list of topics: /1 Why does any zone under 62.in-addr.arpa have to be in the DLV? Since 62/8 is under RIPE NCC control, it can be properly signed. /2 Why does RIPE NCC still submit key material to the DLV? RIPE NCC should no longer endorse out-of-band mechanisms for key publication. /3 Discussion around the current use of ripe.int. /4 Discussion around the current use of ripen.cc. I will try to answer each of these point separately. 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. 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. 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. 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. Kind regards, Romeo Zwart RIPE NCC
Romeo, On Nov 17, 2014, at 7:49 AM, Romeo Zwart <romeo.zwart@ripe.net> wrote:
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.
Yay!
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.
Since .INT is currently not signed and RIPE is not using RIPE.INT, signing RIPE.INT would seem to be a bit ... silly (particularly in the light of #2). Since RIPE is not using RIPE.INT and that registration is out of (current) policy with respect to registrants in that domain, is there any reason why RIPE-NCC doesn't simply request RIPE.INT to be removed from the INT zone? Regards, -drc
Hi all, On Mon, 17 Nov 2014, David Conrad wrote:
Romeo,
On Nov 17, 2014, at 7:49 AM, Romeo Zwart <romeo.zwart@ripe.net> wrote:
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.
Yay!
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.
Since .INT is currently not signed and RIPE is not using RIPE.INT, signing RIPE.INT would seem to be a bit ... silly (particularly in the light of #2).
Since RIPE is not using RIPE.INT and that registration is out of (current) policy with respect to registrants in that domain, is there any reason why RIPE-NCC doesn't simply request RIPE.INT to be removed from the INT zone?
Is there any available statistics on how many HTTP clients that reaches ripe.int and then fetches ripe.net instead?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi David, On 14/11/17 17:56 , David Conrad wrote:
Romeo,
On Nov 17, 2014, at 7:49 AM, Romeo Zwart <romeo.zwart@ripe.net> wrote:
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.
Yay!
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.
Since .INT is currently not signed and RIPE is not using RIPE.INT, signing RIPE.INT would seem to be a bit ... silly (particularly in the light of #2).
There was an explicit suggestion on the list about using ripe.int as a 'lever' to get .int signed, hence my comment.
Since RIPE is not using RIPE.INT and that registration is out of (current) policy with respect to registrants in that domain, is there any reason why RIPE-NCC doesn't simply request RIPE.INT to be removed from the INT zone?
There will be a separate followup on this specific topic. Kind regards, Romeo
Regards, -drc
-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlRrAaoACgkQGRL9suBV+erySgCeNcN71fH2JxJyflo+e+9o1Aj8 MHMAnRD5ieR/XPXe1NqHW2A2+/rpowYx =usf1 -----END PGP SIGNATURE-----
On 18 Nov 2014, at 08:22, Romeo Zwart <romeo.zwart@ripe.net> wrote:
There was an explicit suggestion on the list about using ripe.int as a 'lever' to get .int signed, hence my comment.
I think you are mistaken Romeo. Peter asked some meta issues on policy and procedural matters around the signing of .int: ie who is the governing body for the TLD and needs to be done to get them to sign it. He did not ask for the TLD to be signed. AFAICT nobody on the list has explicitly asked to get .int signed. Anyways, this is somewhat off-point. Although it would be good to know the answer to those questions, it belongs in another thread. Could we please return to the matter at hand: [1] What DNS/web/whatever traffic goes to ripen.cc? If it's low, can this be killed? When? [2] When was the utility of its DLV entry last assessed? What's the exit strategy for that? How often does its DLV name get validated and by whom/what? [3] What DNS/web/whatever traffic goes to ripe.int? If it's low, can this be killed? When? [4] When was the utility of its DLV entry last assessed? What's the exit strategy for that? How often does its DLV name get validated and by whom/what? [5] What's the NCC's overall exit strategy for DLV? FWIW I have still not seen any valid reason or meaningful daya explaining why the NCC still uses DLV.
Hi Jim, On 14/11/18 10:54 , Jim Reid wrote:
On 18 Nov 2014, at 08:22, Romeo Zwart <romeo.zwart@ripe.net> wrote:
There was an explicit suggestion on the list about using ripe.int as a 'lever' to get .int signed, hence my comment.
I think you are mistaken Romeo. Peter asked some meta issues on policy and procedural matters around the signing of .int: ie who is the governing body for the TLD and needs to be done to get them to sign it. He did not ask for the TLD to be signed. AFAICT nobody on the list has explicitly asked to get .int signed.
My wording was inaccurate. There indeed were questions on the list about procedure to have .int signed and that is what I intended to say.
Anyways, this is somewhat off-point. Although it would be good to know the answer to those questions, it belongs in another thread.
We are in violent agreement here.
Could we please return to the matter at hand:
I noticed that, meanwhile, you have read my other post. So, for the below questions, please see my previous post, where I tried to answer these points. As I tried to indicate, and you also pointed out yourself, there are some points here on which the WG should find consensus. We are happy to proceed when there is a clear working group direction. Kind regards, Romeo
[1] What DNS/web/whatever traffic goes to ripen.cc? If it's low, can this be killed? When?
[2] When was the utility of its DLV entry last assessed? What's the exit strategy for that? How often does its DLV name get validated and by whom/what?
[3] What DNS/web/whatever traffic goes to ripe.int? If it's low, can this be killed? When?
[4] When was the utility of its DLV entry last assessed? What's the exit strategy for that? How often does its DLV name get validated and by whom/what?
[5] What's the NCC's overall exit strategy for DLV?
FWIW I have still not seen any valid reason or meaningful daya explaining why the NCC still uses DLV.
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.
At Tue, 18 Nov 2014 10:22:09 +0000, Jim Reid wrote:
On 17 Nov 2014, at 15:49, Romeo Zwart <romeo.zwart@ripe.net> wrote:
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.
I'm reading that as a call from one of the co-chairs for (more) voices from the WG, so here's mine. Let's have RIPE.INT removed.
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.
Let's have RIPEN.CC removed also.
The NCC needs to have a procedure to review its DLV entries -- report to the WG once a year?
Let's have this made part of the reporting routine.
-- and an exit strategy for the cruft^W names and keys it has there.
Let's have this too! ATB Niall
Niall O'Reilly wrote:
At Tue, 18 Nov 2014 10:22:09 +0000, Jim Reid wrote:
On 17 Nov 2014, at 15:49, Romeo Zwart <romeo.zwart@ripe.net> wrote:
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.
I'm reading that as a call from one of the co-chairs for (more) voices from the WG, so here's mine.
Let's have RIPE.INT removed.
I do share this pov. The NCC is not a result of an international treaty and the RIPE Community is even less so :-)
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.
Let's have RIPEN.CC removed also.
Same here, and as soon as possible. Imho it is also an issue of corporate identity, but that's off topic here.
The NCC needs to have a procedure to review its DLV entries -- report to the WG once a year?
Let's have this made part of the reporting routine.
-- and an exit strategy for the cruft^W names and keys it has there.
Let's have this too!
I don't have an opinion on this one, as I am mostly DNSsec illiterate :-/ Wilfried
ATB Niall
On Tue, Nov 18, 2014 at 11:16:19AM +0000, Niall O'Reilly wrote: I use the simplest option. ;-)
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.
I'm reading that as a call from one of the co-chairs for (more) voices from the WG, so here's mine.
Let's have RIPE.INT removed.
+1
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.
Let's have RIPEN.CC removed also.
+1 Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Hi,
Let's have RIPEN.CC removed also.
+1
+∞
Isn't this really, as Romeo puts it, "an operational decision" for the RIPE NCC? If they want to sit on a domain that bears a resemblance to the company identity, I'll leave that up to them... Cheers, Rob
On 18 Nov 2014, at 14:59, Rob Evans <rhe@nosc.ja.net> wrote:
Isn't this really, as Romeo puts it, "an operational decision" for the RIPE NCC?
Er no. It's a decision for the community which domain names it needs or wants to use to identify itself. After all the NCC should respond to the needs of the RIPE community and the NCC membership. It's an operational matter for the NCC how to register those domain names, which registrar(s) to use, provision the names, choose the name servers, etc, etc. YMMV. Nobody here knew about ripe.int until recently and it doesn't seem to be used. Since it does not appear to have community support -- for some definition of both community and support -- the case for retaining the domain is poor at best.
On Tue, Nov 18, 2014 at 03:22:00PM +0000, Jim Reid wrote: Jim
Nobody here knew about ripe.int until recently and it doesn't seem to be used.
Years ago I gave a lecture about DNS system. Part of it, was showing some examples of domains from non-ccTLDs. ripe.int was the only one example I have had in my mind at this time. ;-) Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
well some people knew about it. however when int was repurposed and went to ICANN, the rir delegations should have all been removed since the reason for existence was moot. that it has remained this long suggests a lack of care /bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 18November2014Tuesday, at 9:37, Piotr Strzyzewski <Piotr.Strzyzewski@polsl.pl> wrote:
On Tue, Nov 18, 2014 at 03:22:00PM +0000, Jim Reid wrote:
Jim
Nobody here knew about ripe.int until recently and it doesn't seem to be used.
Years ago I gave a lecture about DNS system. Part of it, was showing some examples of domains from non-ccTLDs. ripe.int was the only one example I have had in my mind at this time. ;-)
Piotr
-- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
On 18 Nov 2014, at 14:59, Rob Evans <rhe@nosc.ja.net> wrote:
If they want to sit on a domain that bears a resemblance to the company identity, I'll leave that up to them...
That way lies madness: ripe.$TLD-of-the-week. IMO one domain name is enough. If someone can make a convincing case to use more than that or why ripe.whatever can achieve something not possible with ripe.net, please speak up.
Hi Jim,
If they want to sit on a domain that bears a resemblance to the company identity, I'll leave that up to them...
That way lies madness: ripe.$TLD-of-the-week.
I don't disagree, but my thoughts are along the lines of what Peter said. I certainly don't want the RIPE community to be associated with the ripen.cc domain, but if the RIPE NCC wants to use it (or at least reserve it), we might think it's a mistake, but it's the company's mistake to make unless we get into a level of micro-management that I think we, as a community, delegate to the Board. As you say, YMMV, E&OE, prices of domains can go down as well as up. Cheers, Rob
On 18 Nov 2014, at 15:51, Rob Evans <rhe@nosc.ja.net> wrote:
I certainly don't want the RIPE community to be associated with theripen.cc domain, but if the RIPE NCC wants to use it (or at least reserve it), we might think it's a mistake, but it's the company's mistake to make unless we get into a level of micro-management that I think we, as a community, delegate to the Board.
I'm sort of in agreement with that Rob. Experiments and trying new stuff with other name spaces are fine, provided there's a clear understanding of what's going on and why. There also needs to be a clear exit or migration strategy. Cruft can't be allowed to just stagnate indefinitely or accumulate even more cruft along the way. There should be clear milestones around future go/no go decisions. There should be some reporting about all of the above, either to the DNS or NCC Services WG - whatever of the two is most appropriate. None of that has been done for ripe.int, ripen.cc and their injection into DLV. Well OK, nothing apart from the accummulation of cruft. My key question the has yet to be answered remains "why is the NCC putting keying material into ripe.int into DLV when the domain does not appear to be used and the case for continued DLV registration is vague to non-existent?". I would like some hard data about that. That said, I think it is reasonable for the community to decide "ripe.foo is no longer used or needed. Please let it die.".
On 18/11/2014 16:27, Jim Reid wrote:
That said, I think it is reasonable for the community to decide "ripe.foo is no longer used or needed. Please let it die.".
just as reasonable as if the ripe ncc management team (or board) were to decide that as this is purely an operational matter, that the decision would be theirs entirely. It's not helpful for the ripe community to micromanage the ncc. The entire thread about whether or not to delete ripe.int falls firmly into the category of micromanagement. Please can we let them get on with their jobs without interfering? Nick
Hi Jim, On 18.11.2014 16:34, Jim Reid wrote:
On 18 Nov 2014, at 14:59, Rob Evans <rhe@nosc.ja.net> wrote:
If they want to sit on a domain that bears a resemblance to the company identity, I'll leave that up to them...
That way lies madness: ripe.$TLD-of-the-week.
IMO one domain name is enough. If someone can make a convincing case to use more than that or why ripe.whatever can achieve something not possible with ripe.net, please speak up.
I know at least one TLD that serves a completely orthogonal purpose to any "regular" TLD - and I am sure you know this one too. :-) I'd be almost immediately convinced if the NCC decided to register under this particular TLD - for the services that come with it. Cheers, -C.
On Tue, Nov 18, 2014 at 05:17:03PM +0100, Carsten Schiefner wrote:
On 18.11.2014 16:34, Jim Reid wrote:
On 18 Nov 2014, at 14:59, Rob Evans <rhe@nosc.ja.net> wrote:
If they want to sit on a domain that bears a resemblance to the company identity, I'll leave that up to them...
That way lies madness: ripe.$TLD-of-the-week.
IMO one domain name is enough. If someone can make a convincing case to use more than that or why ripe.whatever can achieve something not possible with ripe.net, please speak up.
I know at least one TLD that serves a completely orthogonal purpose to any "regular" TLD - and I am sure you know this one too. :-)
I'd be almost immediately convinced if the NCC decided to register under this particular TLD - for the services that come with it.
I have always believed that this was a kind of an experiment with short links which was introduced during and then abandoned after the RIPE61 at ROME: http://www.ripe.net/ripe/mail/archives/ncc-announce/2010-October/000406.html https://twitter.com/RIPE_NCC/status/28388254627 Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Hiya, On Tue, Nov 18, 2014 at 11:16:19AM +0000, Niall O'Reilly wrote:
Let's have RIPE.INT removed.
+1
Let's have RIPEN.CC removed also.
+1 (I think I voiced my confusion about the existance of ripen.cc some years ago already, so my position is known :-) ) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On 18/11/2014 11:16, Niall O'Reilly wrote:
Let's have RIPE.INT removed.
tbh, I see no reason to remove ripe.int. If ICANN has concerns about the delegation, then they should raise them formally with the RIPE NCC. If the "registration is out of (current) policy with respect to registrants in that domain", it's unclear why this is a RIPE NCC problem. The domain has been around since 2001 so if there's been a problem, why has it taken 13 years for people to get worked up about it? Please leave it alone. Nick
My 0.2c I remember the day when ripe.net -domain was unreachable because of failure to renew it. The hassle was pretty big, as it took a long time to convince the domain registry (at U.S) to understand that "yes, we really need this at european territory”. This was the primary reason to register .int as well. I have no clue have the situation changed about this but if not why to get rid of the backup? Jorma On 18 Nov 2014, at 16:38, Nick Hilliard <nick@foobar.org> wrote:
On 18/11/2014 11:16, Niall O'Reilly wrote:
Let's have RIPE.INT removed.
tbh, I see no reason to remove ripe.int.
If ICANN has concerns about the delegation, then they should raise them formally with the RIPE NCC.
If the "registration is out of (current) policy with respect to registrants in that domain", it's unclear why this is a RIPE NCC problem. The domain has been around since 2001 so if there's been a problem, why has it taken 13 years for people to get worked up about it?
Please leave it alone.
Nick
On 18 Nov 2014, at 14:50, Jorma Mellin <jorma@jmellin.net> wrote:
I remember the day when ripe.net -domain was unreachable because of failure to renew it. The hassle was pretty big, as it took a long time to convince the domain registry (at U.S) to understand that "yes, we really need this at european territory”.
This must have happened a *long* time ago and I am sure the NCC now has robust procedures in place to ensure domain names get renewed in good time. Though it might be worth asking about that.
This was the primary reason to register .int as well.
The origins of ripe.int are unclear and it would be good to know why it was done.
I have no clue have the situation changed about this but if not why to get rid of the backup?
It's not a backup: gromit% dig ripe.int mx ... ;; ANSWER SECTION: ripe.int. 21600 IN MX 250 kaka.ripe.net. ripe.int. 21600 IN MX 200 koko.ripe.net. gromit% dig www.ripe.int ... ;; ANSWER SECTION: www.ripe.int. 21600 IN CNAME www.ripe.net. FWIW I have never seen a URL or email address containing has ripe.int.
Nick, On Nov 18, 2014, at 6:38 AM, Nick Hilliard <nick@foobar.org> wrote:
On 18/11/2014 11:16, Niall O'Reilly wrote:
Let's have RIPE.INT removed. tbh, I see no reason to remove ripe.int.
I see no reason to keep it.
If ICANN has concerns about the delegation, then they should raise them formally with the RIPE NCC.
AFAIK, ICANN doesn't care.
If the "registration is out of (current) policy with respect to registrants in that domain", it's unclear why this is a RIPE NCC problem.
Because the current registry (which I'm guessing will probably change with the transition of the stewardship of the IANA functions contract) won't do anything to it unless the current registrant asks.
The domain has been around since 2001 so if there's been a problem, why has it taken 13 years for people to get worked up about it?
No one is worked up and there isn't a problem per se, it is just pointless cruft left over from an earlier Internet. With the transition of the stewardship of the IANA functions contract, people are trying to figure out what to do with the .int registry. Given ICANN isn't supposed to be running a registry, it is likely the "owner" of the .int registry will change. Since RIPE does not really use the domain and is not a treaty organization, awkward political questions may be raised. Unless one enjoys pointless political discussions, I'm unclear what value there is in keeping the domain.
Please leave it alone.
What purpose does it serve? Regards, -drc (ICANN CTO, but speaking for myself only. Really.)
Wilfried Woeber writes:
Nick Hilliard wrote:
On 18/11/2014 11:16, Niall O'Reilly wrote: > >> Let's have RIPE.INT removed. > > > tbh, I see no reason to remove ripe.int. [...] > Please leave it alone.
In order to achieve or conserve - what?
Energy. jaap PS. The last time I looked, all contracts with (g)TLD registries has various names reserved, among them, RIPE. So, default RIPE.$TLD is reserved. I guess that is to stop delegations like ripe.org.
Thanks, Jaap! Jaap Akkerhuis wrote: [...]
PS. The last time I looked, all contracts with (g)TLD registries has various names reserved, among them, RIPE. So, default RIPE.$TLD is reserved. I guess that is to stop delegations like ripe.org.
Fair enough. So we'll pay for some 1000 or more RIPE.$new-gTLD reservations pretty soon now? Reality check, folks. -WW
Wilfried Woeber writes:
Thanks, Jaap!
Jaap Akkerhuis wrote:
[...]
PS. The last time I looked, all contracts with (g)TLD registries has various names reserved, among them, RIPE. So, default RIPE.$TLD is reserved. I guess that is to stop delegations like ripe.org.
Fair enough. So we'll pay for some 1000 or more RIPE.$new-gTLD reservations pretty soon now?
Nope. I think the idea to have this "verboten to delegate list" is that obe doesn't has to do defensive registratins. So the ICANN contracts protects RIPE for "abuse of ripe's domain label". jaap
On 11/18/14 6:38 AM, Nick Hilliard wrote:
On 18/11/2014 11:16, Niall O'Reilly wrote:
Let's have RIPE.INT removed.
tbh, I see no reason to remove ripe.int.
You don't find the fact that it's been out of scope for INT for over a decade to be compelling? We removed ip6.int for similar reasons, and that actually had a purpose at one point in the past.
If ICANN has concerns about the delegation, then they should raise them formally with the RIPE NCC.
It's been raised informally a non-zero number of times in the past. Why do you think that creating a kerfuffle over something simple is the right way to go? There seems to be a fairly large consensus that the domain should be removed, and Jim has asked some intelligent operational questions about its use that IMO should be answered. Doug
* Nick Hilliard wrote:
On 18/11/2014 11:16, Niall O'Reilly wrote:
Let's have RIPE.INT removed.
tbh, I see no reason to remove ripe.int.
If ICANN has concerns about the delegation, then they should raise them formally with the RIPE NCC.
I second that. And for the DLV issue, I'd like to see any zone, which can't be validated straight from the root (following the DS chain), ahandles in the following way: 1) put the validation info in a DLV (i.e. ISC). 2) push as hard as possible to get the missing zones signed. 3) remove the DLV as soon as the DS chain is complete. And forget about ripen.cc. If you think, this is a geeky idea, apply for the community TLDs .NCC as well as .RIPE.
On 11/18/14 1:38 PM, Lutz Donnerhacke wrote:
* Nick Hilliard wrote:
On 18/11/2014 11:16, Niall O'Reilly wrote:
Let's have RIPE.INT removed.
tbh, I see no reason to remove ripe.int.
If ICANN has concerns about the delegation, then they should raise them formally with the RIPE NCC.
I second that.
Why? What value does a formal request from ICANN have over the RIPE community simply doing the right thing with an old domain that no longer has relevance? Doug
Lutz, On Nov 18, 2014, at 1:38 PM, Lutz Donnerhacke <lutz@iks-jena.de> wrote:
If ICANN has concerns about the delegation, then they should raise them formally with the RIPE NCC. I second that.
As mentioned previously, AFAIK, ICANN doesn't have any concerns with ripe.int -- I doubt anyone who isn't on this mailing list from ICANN is even aware it exists. The question is about what happens in the future since .INT registry services is officially (rightly or wrongly) a service provided via the IANA Functions contract, it is likely ICANN won't be providing .INT registry services in the future (since ICANN's section II.2 of own bylaws state: "ICANN shall not act as a Domain Name System Registry [...]" so I'll be surprised if .INT is continued after the stewardship of the IANA functions contract is transitioned), and RIPE is not a treaty organization. This isn't a question for ICANN: it's a question for RIPE (or, if you prefer, RIPE-NCC) and whoever will be running .INT after the transition. I'm just suggesting that if RIPE (or, if you prefer, RIPE-NCC) see no significant value in RIPE.INT, to simply ask it be dropped prior to (I'm perhaps overly cynically guessing here) political silliness associated with the .INT zone. Regards, -drc (ICANN CTO, but speaking only for myself. Really.)
On Tue, Nov 18, 2014 at 11:16:19AM +0000, Niall O'Reilly wrote:
I'm reading that as a call from one of the co-chairs for (more) voices from the WG, so here's mine.
Let's have RIPE.INT removed.
this isn't f*cebook. As a co-chair of this wg I doubt it is reasonable for the WG to micro manage the NCC in what domain names and which TLD(s) it uses. It is also not clear to me why the DNS WG would be formally competent w.r.t. the subject matter.
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.
Let's have RIPEN.CC removed also.
Again, I doubt that a voting is helpful here. No matter what, even if the NCC gave up on the use of "ripen.cc", releasing the domain name is probably a bad idea. Also, simply removing those domains without a signed parent doesn't ultimately help solving the DLV issue. Why can't a zone be signed (for reasons of symmetry or streamlined processes) without the TA being published? -Peter
participants (18)
-
Carsten Schiefner -
David Conrad -
Doug Barton -
Gert Doering -
Jaap Akkerhuis -
Jim Reid -
Jorma Mellin -
Lutz Donnerhacke -
manning bill -
Niall O'Reilly -
Nick Hilliard -
Patrik Wallstrom -
Peter Koch -
Piotr Strzyzewski -
Rob Evans -
Romeo Zwart -
Sander Steffann -
Wilfried Woeber