On Mon, 16 Jul 2012, Paul Hoffman wrote:

Subject: Re: [DNSOP] draft-wouters-dnsop-secure-update-use-cases-00

On Jul 16, 2012, at 12:40 AM, Patrik Fältström wrote:

On 13 jul 2012, at 13:57, Peter Koch wrote:

while this discussion is refreshing, the reason Paul (was) volunteered
to write this document was less the (re-)definition of the lame delegation
terminology but more to address (potential) requirements for an in-band
child parent key exchange. Let's leave the bikeshed black for the moment
and focus on the design of the bikes instead.

Because I find the registrar/registry description be non-complete, and in some 
cases wrong, let me suggest that portion of the draft is just removed, and 
instead that the draft actually talk about what it is supposed to talk about.

The goal was to describe use cases, not requirements. We can change that
if we want, but then we will have the use-cases discussion anyway on the
list. If the WG wants that, it's fine with me.

For example:

- I recommend strongly to not talk about sub-registrars

It's a very important use case unfortunately, with the second largest
reseller not supporting DNSSEC, while powering dozens of smaller
sub-registrars.

- I recommend as strongly to not talk about registrant/registry relationship

How else would you describe the relationships where parent and child do
not communicate with each other directly, but use a third party?

- The protocol to use to communicate with registrar is normally private API, 
not epp

Unless in the case of the sub-registrar.

- It varies what and how the registrars are to send data to the registry, even 
if epp is in use, so just skip trying to describe it as registries have too 
much difference in policy and ideas on how that is to be done

Etc...

Can these be folded into use cases?

Patrik's partial list of problems with the document can be summarized as:

What is the intention of this document: is it describing current operations, or 
operations that we want to see?

It is trying to describe the use-cases that any solution that tries to
automate parent-child related records with DNSSEC-based authentication
should attempt to support.

If it is the former then, yes, there is a lot of completely incorrect 
statements. If it is the latter, it will be interesting to imagine how we can 
get consensus because current operators won't want to change to this new design 
or to run two or more different operations in parallel.

I think this statement confuses "operator" with "registrar". There are
many other use cases too. It would be unfortunate if we leave the entire
RRR ecosystem out of any possible solution, because part of the
motivation for this document is to speed up adoption of DNSSEC in the
many different RRR eco-systems.

Paul
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to