Lutz,
On Nov 18, 2014, at 1:38 PM, Lutz Donnerhacke 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 thi
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.
* 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 li
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.
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 RI
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
P
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 18N
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 reason
On Tue, Nov 18, 2014 at 03:22:00PM +, 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 hav
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 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 m
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?
> Nick
Wilfried
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 th
On 18 Nov 2014, at 15:51, Rob Evans 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
Hi Jim,
On 18.11.2014 16:34, Jim Reid wrote:
>On 18 Nov 2014, at 14:59, Rob Evans 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
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
On 18 Nov 2014, at 14:59, Rob Evans 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 th
On 18 Nov 2014, at 14:50, Jorma Mellin 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 terr
On Tue, Nov 18, 2014 at 11:16:19AM +, 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 micr
On 18 Nov 2014, at 14:59, Rob Evans 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 co
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
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
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
>> Let's have RIPE.INT removed.
>
> +1
+1
>> Let's have RIPEN.CC removed also.
>
> +1
+∞
Cheers,
Sander
Hiya,
On Tue, Nov 18, 2014 at 11:16:19AM +, 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
-- NetM
On Tue, Nov 18, 2014 at 11:16:19AM +, 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-IAN
Niall O'Reilly wrote:
> At Tue, 18 Nov 2014 10:22:09 +,
> Jim Reid wrote:
>
>>On 17 Nov 2014, at 15:49, Romeo Zwart 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 a
At Tue, 18 Nov 2014 10:22:09 +,
Jim Reid wrote:
>
> On 17 Nov 2014, at 15:49, Romeo Zwart 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 requ
Hi Jim,
On 14/11/18 10:54 , Jim Reid wrote:
> On 18 Nov 2014, at 08:22, Romeo Zwart 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
On 17 Nov 2014, at 15:49, Romeo Zwart 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)
On 18 Nov 2014, at 08:22, Romeo Zwart 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
-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
> 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
>
Hi all,
On Mon, 17 Nov 2014, David Conrad wrote:
> Romeo,
>
> On Nov 17, 2014, at 7:49 AM, Romeo Zwart 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 undesirabl
Romeo,
On Nov 17, 2014, at 7:49 AM, Romeo Zwart 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/
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
Paul Mockapetris (pvm) == Original maintainer of .INT,
Bill Manning (wcm) == second maintainer of .INT,
ICANN == Current Maintainer of .INT.
DLV == DNS Lookaside Validation, a kludge to deal with islands of trust,
published by Sam Weiler and productized by Internet Systems (nee Software)
Co
On 14 Nov 2014, at 10:19, Tony Finch wrote:
> Peter Koch wrote:
>>
>> I'd rather not see the RIPE NCC further endorse the DLV technology and
>> service by continuing to submit key material there. DLV was meant as a
>> temporary deployment aid and might have been a good idea at its time.
>
> W
Peter Koch wrote:
>
> I'd rather not see the RIPE NCC further endorse the DLV technology and
> service by continuing to submit key material there. DLV was meant as a
> temporary deployment aid and might have been a good idea at its time.
We would like to stop using the DLV but some of our revers
the EU is not a treaty based org? I thought that the Maastricht Treaty in 1993
created the EU.
certainly RIPE existed before then (didm;t it emerge from RARE?)… which if
memory serves,
was an agreement between several organizations to work together. While that
might not have
engendered a form
On Nov 13, 2014, at 7:44 AM, Randy Bush wrote:
>> I'd rather not see the RIPE NCC further endorse the DLV technology and
>> service by continuing to submit key material there.
>
> thank you
>
>> DLV was meant as a temporary deployment aid and might have been a good
>> idea at its time.
>
> or n
i guess one could argue RIPE is an offshoot of a treaty org (the EU)
/bill
No, it is not.
Rob
On 13 Nov 2014, at 17:38, Peter Koch wrote:
> I'd rather not see the RIPE NCC further endorse the DLV technology and
> service by continuing to submit key material there.
+100
What's this? Peter and myself in agreement? Something is wrong. :-)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 11/13/14 6:54 AM, Anand Buddhdev wrote:
| Dear colleagues,
|
| Most of the zones that the RIPE NCC signs with DNSSEC have trust
| anchors in their parent zones, with the exception of these three
| zones:
|
| 151.76.62.in-addr.arpa ripe.int ripen.
once, long ago, there was a serious and aggressive move to remove .arpa
we moved everything into .int and included the rirs as organizations
responsible for the numbers.
then it was pointed out that replacing all the resolver libraries might be
problematic and DNAME had not
been invented… the
> I'd rather not see the RIPE NCC further endorse the DLV technology and
> service by continuing to submit key material there.
thank you
> DLV was meant as a temporary deployment aid and might have been a good
> idea at its time.
or not
randy
Anand, all,
On Thu, Nov 13, 2014 at 03:54:54PM +0100, Anand Buddhdev wrote:
> 151.76.62.in-addr.arpa
> ripe.int
> ripen.cc
> On Tuesday, 11 November 2014, we rolled our DNSSEC Key Signing Keys
> and added the new trust anchors for these three zones to the ISC
> DLV TAR. Because we believe manual
On 13 Nov 2014, at 14:54, Anand Buddhdev wrote:
> Signed PGP part
> Dear colleagues,
>
> Most of the zones that the RIPE NCC signs with DNSSEC have trust anchors
> in their parent zones, with the exception of these three zones:
>
> 151.76.62.in-addr.arpa
> ripe.int
> ripen.cc
>
> We have been
Hi Anand,
On 13.11.2014 16:18, Wilfried Woeber wrote:
> Well, this may be seen as a stupid question from a DNS DAU,
>
> but can you explain what ripe.int (an international treaty organisation?)
> and ripen.cc are used for?
I'd like to second Wilfried's question at least for the .int part.
Thank
Well, this may be seen as a stupid question from a DNS DAU,
but can you explain what ripe.int (an international treaty organisation?)
and ripen.cc are used for?
Thanks,
Wilfried
Anand Buddhdev wrote:
> Dear colleagues,
>
> Most of the zones that the RIPE NCC signs with DNSSEC have trust ancho
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dear colleagues,
Most of the zones that the RIPE NCC signs with DNSSEC have trust anchors
in their parent zones, with the exception of these three zones:
151.76.62.in-addr.arpa
ripe.int
ripen.cc
We have been publishing trust anchors for these three
49 matches
Mail list logo
