On Jul 16, 2012, at 1:07 PM, 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.
It would be better if it was really a "use cases" 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. Fully disagree. Trying to say which of the use cases for the R between the zone operator and the registry "has use" and "has no use" belongs in ICANN, not the IETF. It is not an operations issue. >> 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. Err, how could that be the outcome of a use cases document? Or are you envisioning this as also being a protocol document? (FWIW, I would love to have such a protocol, but I think it's a bad idea to do it as a "use case".) > 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. So this is now a list of current practices that are not working? >> 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. That's a business argument. >> 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. That all seems fine. What does it have to do with describing the practices today? --Paul Hoffman _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
