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.
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. I imagine that could be useful to registrants, DNS hosters, registrars and registries. But also within the non-RRR model of parent-child relationship. The private/different API/EPP implementations is not helping making DNSSEC deployment easy. That's what we're trying to address.
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.
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. 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. 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. Paul _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop