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
DNSOP@ietf...
https://www.ietf.org/mailman/listinfo/dnsop