Ondřej Surý wrote on 03/05/2024 12:23:
I would argue that any sane person would not leave the DNS change to
the last moment and migrate the nameservers months before. I mean
right away.
oh for sure, but there's a wide variety of reasons which would cause
migration not to happen by the due date,
Paul de Weerd wrote on 02/05/2024 16:49:
We are proposing to retire the secondary DNS service by the end of
2024 and we're asking for your input and feedback on this proposal.
Please share any feedback on the DNS Working Group mailing list by 16
May 2024.
definitely a good move to retire this.
Randy Bush wrote on 15/11/2021 21:29:
you can't fool me, hilliard. i saw the black helicopter at the ietf
near dublin.
You didn't see any black helicopters! The men in black suits said they
weren't there.
Nick
To unsubscribe from this mailing list, get a password reminder, or change your
David Huberman wrote on 15/11/2021 21:31:
I guess I'm not grokking why you think this kind of regulation would
have no legal basis when regulators are proposing something very
similar in eIDAS article 45 (all web browsers must accept CAs which
we the regulators approve) and in NIS2 for root serve
David Huberman wrote on 15/11/2021 21:12:
In addition the browser vendors, wouldn't regulators be able to
define a class of orgs that are ISPs, then make a rule: ISPs must not
do DNS resolution for your customers. Instead, you must forward to
our resolver or you must announce our resolver's IP ad
Jim Reid wrote on 12/11/2021 12:23:
I’m not sure it is. Even so, I think the “welcome to the list” email
-- which I’m sure everyone keeps forever -- includes info on how to
subscribe/unsuscribe, change preferences, etc. IMO that should take
care of GDPR concerns.
Now that I'm sitting firmly in
Jim Reid wrote on 12/11/2021 11:15:
There is*nothing* anyone here can do about your list
subscription/unsubscription.
from a practical point of view, it would help if emails to
dns-wg@ripe.net included a footer on how to unsubscribe. This is
arguably also required under gdpr.
Nick
Hank Nussbacher wrote on 08/11/2021 05:12:
Does anyone have further insight into the European initiative known as
DNS4EU?
seems to be a dns resolver service.
https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52021JC0014&rid=3
Not sure what value this will bring to humanity.
Ni
Måns Nilsson wrote on 12/06/2019 22:42:
I suggest that we perform the absolute minimum of policy footwork to
endorse this procedure as is. Because I feel we have a strong if not
absolute consensus for carrying on as usual from those who spoke up here.
we don't really need this because it's not
Gert Doering wrote on 11/06/2019 21:50:
On Tue, Jun 11, 2019 at 08:40:05PM +0200, Jonas Frey wrote:
The time window might be small, but serving wrong answers was not
acceptable for us.
ok, but in the automated world of today this small window is likely to
be _really_ small.
Only if everythin
Carlos M. Martinez wrote:
> It talks about rate limiting, which seems to me is a bit hard to do in a
> stateless way :-D
Queue / buffer management does not need to be stateful. Most
implementations are stateless, except for flow based queues, which is
not what's demonstrated here.
Nick
I, also, salute our new dns-wg overlord and master!
Oh wait, there's some due process we need to go through first.
Nick
On 12/11/2015 17:53, Shane Kerr wrote:
> I would be very happy if David Knight were to act as co-chair for this
> working group.
>
> Jim Reid schreef op 12 november 2015 17:4
On 30/06/2015 13:50, Michele Neylon - Blacknight wrote:
> The .int - only a very small set of organisations could register one, so
> there’s absolutely no reason to keep it if it’s not being used.
>
> The hyphenated domains - is there any “risk” in dropping them? I
> sincerely doubt it
>
> As for
On 05/05/2015 14:28, Jim Reid wrote:
> Colleagues, here is what I hope could be a co-chair selection process
> that the WG can adopt. It's been tweaked to take account of recent
> feedback and should now be free of ambiguities.
in the case where two chairs are due to resign in the same year, the
p
Hi Romeo,
thanks for the comprehensive replies, both here and on the blog.
On 12/03/2015 09:29, Romeo Zwart wrote:
> There are two drivers for that. We receive many requests from
> prospective new K-root hosts. We have considered how to respond to this
> demand from the community. This made us pr
On 11/01/2015 19:51, Jim Reid wrote:
> "every calendar year" is even simpler and fewer words than that Nick. :-)
depends what you're looking for. If it's the simplest and fewest words,
then you will probably want:
[2] A co-chair will serve a term of N years.
The main thing is that the wording s
On 11/01/2015 15:31, Jim Reid wrote:
> Though I'd prefer "once a year" to "every second RIPE meeting" in case
> the number of RIPE meetings per year changes or one of them gets
> cancelled say because the Kras catches fire. And while the selection
> process may well be aligned with a RIPE meeting,
On 06/01/2015 12:41, Niall O'Reilly wrote:
> [2] A co-chair will serve a term of N years, where N is the number
> of co-chairs. Terms will be staggered so that one term expires every
> year.
This is also semantically non-deterministic in the case where the number of
co-chairs changes.
>From
On 07/01/2015 16:20, Robert Story wrote:
> I agree. It seems silly to limit the term of someone willing to serve and
> who has wg support.
This approach favours the creation of an incumbency, which most people
agree is not good governance.
> If, however, the consensus is in favor of term limits,
Jim,
On 05/01/2015 17:33, Jim Reid wrote:
> One sticking point appears to be the "A co-chair cannot serve more than
> 2 consecutive terms." provision in [2]. Someone commented at the mike
> at RIPE69 that this was a good thing. One of your co-chairs says the
> opposite. Everyone else has not com
On 25/11/2014 18:46, Jim Reid wrote:
> But why should this be a problem?
I'm not saying it'll ever be a problem for DNS-WG in the future, just that
it's been a problem for other WGs in the past. Those who don't learn their
history are condemned to repeat it.
Nick
On 25/11/2014 18:15, Peter Koch wrote:
> On Tue, Nov 25, 2014 at 12:09:25PM +, Jim Reid wrote:
>
>> [2] A co-chair will serve a term of N years, where N is the number
>> of co-chairs. Terms will be staggered so that one term expires every
>> year. A co-chair cannot serve more than 2 consecutiv
On 25/11/2014 14:42, Jim Reid wrote:
> Nick, thanks for your comments.
>
> I'm both surprised and disappointed. Surprised because the mood of the
> room/WG appears to be the proposed text is "good enough". Nobody has
> advocated making radical surgery to it despite the proposed text being
> in cir
On 25/11/2014 12:09, Jim Reid wrote:
> In case anyone cares, here's that proposed text again.
Jim, the proposal is non-deterministic. There's no discriminator in place
to decide who gets to stand down if N changes and two chairs need to stand
down at the same time, or if somehow the chair terms b
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/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
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
27 matches
Mail list logo
