On 03/13/2013 12:53 PM, Joe Abley wrote:
On 2013-03-13, at 13:34, Doug Barton <[email protected]> wrote:
On 03/13/2013 10:20 AM, Joe Abley wrote:
On 2013-03-13, at 13:17, Doug Barton <[email protected]>
wrote:
In order to really make this work a non-trivial number of TLD
registries (which have a variety of different rules and
policies) AND registrars would have to be on board.
No. Where there are registrars involved, you just need a
registrar that can handle your domain name to support it. The
registry-registrar interactions can remain unchanged.
Sure, if you can accomplish getting the registrars that handle your
domains on board then you've accomplished the goal for you. What
about everyone else? Or do we only care about this problem to the
extent that it affects certain TLDs?
Doug, I don't understand your concern.
You insisted earlier that for gTLDs, we would need support by all TLD
registries and all registrars.
I did not say that.
I said that's nonsense. Now I don't understand what your point is.
Perhaps because you're not reading my messages carefully? I'm not
snarking here, you seem to be adding quite a bit of your own baggage to
what I'm actually writing, and I think it's making it difficult for you
to understand my meaning.
Has anyone communicated with them about this topic? The ICANN
forums for both groups would be a good place to start.
No doubt some of them have people here. But this is not an topic
that deals with issues of registries and registrars; it's a DNS
protocol issue. Changing the context to a policy one seems
unlikely to result in additional light.
Why do you think I'm trying to turn it into a policy issue?
Honestly, I have no idea why you're trying to do that.
I'm specifically not trying to do that. If that isn't clear to you, then
you seriously don't understand what I've written at all.
But by
suggesting loudly that we need to build requirements from gTLD
registrars and registries, that's indeed what you are doing. I'm
actively opposed to that because I think it's unnecessary, and a
distraction from the work at hand.
So you're not at all concerned about the scenario where we're going to
create a really neat mechanism for handling this problem but it will
never get deployed? In spite of the ample evidence of the IETF doing
exactly that, over and over again? And, not only do you not think it's a
good idea to talk to the people who may or may not implement this thing
we create, you are actively opposed to doing so because it would be a
distraction?
I'm flabbergasted ...
You're defining "need" differently than I am. You're saying,
"We need an automated mechanism to deal with DS records." I'm
saying that unless the registries and registrars are on board
with the mechanism we create, it doesn't matter how good it is,
it isn't going to solve the real-world need.
I understand. I think you're wrong.
Ok, show me why I'm wrong. How is this mechanism going to work for
you if the registries and registrars don't implement it?
You said (earlier) we needed *all* registries and registrars to
support it. I disagreed with that (there is non-zero utility in this
scheme being implemented by just one registrar, or one registry that
doesn't follow the RRR model). I disagree that registries that follow
the RRR model need to be involved at all (the work can be done by
registrars).
And that will benefit those TLDs who use registrars, sure. What about
the ones who allow registrants to deal with the registry directly? Or
are you confirming that you're only interested in solving this for a
subset of TLDs?
Also, I don't know how realistic "near real time" is, if you
consider the problem of a parent operator having to poll
5,000,000 children for changes. "Some time today" would
satisfy the need I see.
... which is why I agreed with the others that raised the idea
of a special packet for the child to send to the parent to
signal the need to scrape.
I think that's a non-starter.
Why?
I think it'd be a support nightmare, it can't work in cases where
registries are not allowed to interact directly with registrants, and
it's rife with DDoS potential.
I think the "support nightmare" would be overcome rather quickly by
building the sending of this packet into the tools that do the work of
zone maintenance. Users with enough experience to handle maintaining
their zones by hand are also smart enough to handle sending the packet,
so I don't agree with you here. But if I'm missing something please fill
me in.
It's not at all clear that the prohibition against registrar-registry
contact would apply to this case, and even if it did there are
workarounds (such as a registry-registrar EPP channel that gets
triggered when the registry receives the packet).
The DDOS argument I have sympathy with, but that's fairly easily managed
with rate limits, and really isn't any worse than the many other DDOS
vectors that already exist.
Doug
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
