On 16 jul 2012, at 16:25, Paul Wouters wrote: > 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.
The problem is that there are large disagreements in the TLD business whether something like subregistrar really should be (let me use computer terminology here) a first order object or not. Specifically because there are disagreements whether special restrictions should be put on resellers, or if "only" the requirements on registrars should be automatically transferred to the reseller. Plus of course whether resellers are allowed at all -- and that dives into the issues where there are discussions on how you define whether two organisations have "too close relationship", i.e. "are the same organisation". And people against the term reseller very strongly is against it because any such text might risk removing responsibilities on the registrar, and because of that the ability for registries to blame resellers (because resellers live under not only agreement with the registrar, but also separate agreement with the registry or some accreditation agency). Etc. This is a can of worms. >>> - 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? If you do, then you must describe the relationship given the different kind of agreements that exists. In most cases there are agreements between the registry and the registrant that the registrant must live up to. But how that is implemented, when the registrant is agreeing to the rules, and how the registry is to ensure the registrant is living up to the rules is very very different between different registries. In some cases the rules are technical, in others not. In some you also have a relationship between the DNS hosting provider and the registry. >>> - The protocol to use to communicate with registrar is normally private >>> API, not epp > > Unless in the case of the sub-registrar. My experience is that majority of communication with the registrar is not epp. Regardless of whether we talk about registrants, sub-registrars or dns hosting providers that communicate with the 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? If you write lots of lots of text that describe the different cases. :-P And remember that registries do change their policies and rules every third to fourth year, that changes things. >> 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. I still think you should just concentrate on discussing what you actually want to do. If we concentrate on that part I am happy to help commenting on how those ideas fit (or not) into the world I see (as a registrar mainly in the ccTLD world). For example, do you think DS is to be passed to the registry or DNSKEY? Even *that* discussion have stalled in the epp discussions because registries want to (for possibly correct reasons) have a freedom to build their own business models. But if you manage to write only that "simple" thing in a document that we can give registries and registrars, getting that implemented will not be easy. >> 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. Patrik _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
