i could , since i managed .INT after pvm and before it was given to ICANN
/bill
PO Box 12317
Marina del Rey, CA 90295
310.322.8102
On 13November2014Thursday, at 14:32, Doug Barton wrote:
> On 11/13/14 2:22 PM, Barbara Roseman wrote:
>> ICANN inherited a number of INT registrations when it assum
> On Nov 13, 2014, at 2:32 PM, Doug Barton wrote:
>
> On 11/13/14 2:22 PM, Barbara Roseman wrote:
>> ICANN inherited a number of INT registrations when it assumed management of
>> the zone. Since 2005, at least, and probably since 1998, only treaty-based
>> organizations who meet the other cri
On 11/13/14 2:22 PM, Barbara Roseman wrote:
ICANN inherited a number of INT registrations when it assumed management of the
zone. Since 2005, at least, and probably since 1998, only treaty-based
organizations who meet the other criteria have been given registrations, to the
best of my knowledg
On 11/13/14 2:07 PM, Nick Hilliard wrote:
On 13/11/2014 21:21, David Conrad wrote:
Can we just ask for RIPE.INT to be dropped from the .INT zone?
there isn't enough bikeshed in the universe to handle a suggestion like this.
Nick,
But that's just the point, it doesn't have to be a bikeshed.
ICANN inherited a number of INT registrations when it assumed management of the
zone. Since 2005, at least, and probably since 1998, only treaty-based
organizations who meet the other criteria have been given registrations, to the
best of my knowledge. I believe that ICANN uses an outside exper
On 13/11/2014 21:21, David Conrad wrote:
> Can we just ask for RIPE.INT to be dropped from the .INT zone?
there isn't enough bikeshed in the universe to handle a suggestion like this.
Nick
Hi Peter,
> So, there is a registrant in INT interested in having key material published.
> What does it take to get INT sigend?
It is our desire to sign .INT and we are working on making it happen. It is the
only zone we manage that isn’t signed and we are keen to reach 100%. There is
probably
Peter,
On Nov 13, 2014, at 10:50 AM, Peter Koch wrote:
> On Thu, Nov 13, 2014 at 10:28:32AM -1000, David Conrad wrote:
>
>> On Nov 13, 2014, at 8:05 AM, Doug Barton wrote:
>>> The NCC should simply release ripe.int, as the historical reasons for
>>> it no longer apply. (FWIW, same goes for apni
On 13 Nov 2014, at 20:50, Peter Koch wrote:
> So, again: who is to be convinced to make INT signed?
Runs away screaming...
The politics around .int and its oversight are... well... interesting. It might
be inadvisable to dive into that while the IANA arrangements are in flux.
On Thu, Nov 13, 2014 at 10:28:32AM -1000, David Conrad wrote:
> On Nov 13, 2014, at 8:05 AM, Doug Barton 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.)
>
>
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
22 matches
Mail list logo
