On 16 jul 2012, at 22:07, Paul Wouters wrote: > On Mon, 16 Jul 2012, Patrik Fältström wrote: > >> This is a can of worms. > > I understand, though this document is trying to be a technical one, not > a legal one. If the examples in the RRR model can be made more generic > or "fixed", I think that would help us determine what has a use and what > has no use, getting implemented.
Fair. A good goal. I hope you can manage to describe something. Because I agree it would be useful. I am just myself a bit tired over all the different "technical" explanations I have heard from registries and registrars lately... :-P >> 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. > > One of the possible outcomes of this document would be a way where the > DNS hoster and the registry can talk via a DNSSEC-authenticated method. Please stay away from that discussion (i.e. whether the registry should have direct communication with the dns provider). That is *directly* impacting the business models of among other things registrars. And the discussion will be everything BUT technical. So, if you want a technical discussion, have one. But, as you say yourself, you MUST stay away from business models and legal stuff. > I imagine that could be useful to registrants, DNS hosters, registrars > and registries. Depends on what "that" is of course :-) > But also within the non-RRR model of parent-child > relationship. The private/different API/EPP implementations is not > helping making DNSSEC deployment easy. The private API is absolutely helping as epp is not suitable for the transactions you want. How many epp implementations have you written, or rather, how many state machines for epp have you worked on for what number of TLDs that implement what you want to do? The transactions are dead simple if you have for example a JSON based "thing", but a pain in the back if you try to do it in epp. Specifically in cases where one or more of the registrant, dns hosting provider and registrar changes while you still want to have the domain operational. > That's what we're trying to address. Understood. >> And remember that registries do change their policies and rules every third >> to fourth year, that changes things. > > If we have technology in place that can accomodate most, then over time, > hopefully that will change. Just like going from a non-EPP to an EPP > solution has slowly but surely gained more traction, and eased > deployment for registrars. Well, one can question how easy it has become. Yes, it is easier for registrars to either be bound to one non-gTLD or as an accredited ICANN registrar address most gTLD registries. But to support more than one of these (more than one non-gTLD or a non-gTLD and gTLDs), it is a royal pain. We can discuss over a beer whether it is easier than what it would have been without epp. And, note, I *was* the responsible Area Director when epp was created! So I am blaming no one else than myself for rather wanting a solution people could agree on than something that lead to interoperability. Today, I claim people over-use the 'e' in epp. ANYTHING that can reverse that I am thankful to. And that is why I say "please just start agreeing on whether you want DS or DNSKEY" passed to the registrar. That would clean up so many things that you can not imagine. >> 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? > > That is something that would come up when discussing the use cases > document. If we know all the answers to these questions, we would not > need a use cases document. Well, I think the problem is that people know the *possible* answers, but they can not agree on what to pick. > What I think (though the idea is that this becomes a WG document and I'm > just the editor) is that a likely solution would be for the child to > store something in its zone, that the parent can read and validate. This might very well create a race condition between the DNS provisioning path and the epp path. But this is exactly what we could have a look at. And "ignore" (note the quotes) the background information where I think most issues are tied to the business models. > It > seems reasonable to suggest people would want to be able to pre-publish > DS records without yet revealing the public DNSKEY, so in my personal > (no hats) opininion, I would say that the DS option should be there. I > also think the DNSKEY option should be there to accomodate those parents > that have to generate the DS themselves for whatever (technical or not) > reason. Personally, I think many issues I bring up is because different registries have a mix of: - Extremely restrictive implementations of DNSSEC in their epp - Extreme interest in policing what is done in child zones If registries just had (as I see between the lines you suggest) a combination, or multitude, of approaches, then a few different things would be resolved: 1. There would be easier for registrars to find _one_ mechanism or algorithm or state machine that works on more than one TLD 2. There would be easier to implement a multitude of use cases with the same registry Patrik _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
