[On 15 Nov, @ 15:48, Edward wrote in "RE: [dnsop] comments on draft. ..."] > >do one or the other. It adds some complexity. Is the benefit worth it or > >not? > > That's a question I wanted to raise. > > If the DNSKEY is the basis of the transaction, then the registry can > "do more" - it can display the keys in whois, it can generate the > hash under "controlled" circumstances. >
<SNIP> > The second issue is whether the protocol ought to even support a > choice. In my opinion, the DS option is required. If the protocol > does not allow the DNSKEY option, we are cutting out a design choice. > But is that a bad thing? > > Is there a hard requirement that the epp-secdns retain the DNSKEY > option? (I don't consider "maintaining the choice" or "pushing the > decision up a level" as hard requirements.) I don't think there is a hard requirement either way (DS/DNSKEY). The only thing I know is that when I designed the SECREG registry I used DNSKEY as a base for communication. That was done because I could query for the DNSKEY records in the child zone. As a parent I could then create the DS records and put them in the zone. (To put the whole implementation in a tiny nutshell) So I went for DNSKEY and Ed goes for DS. Two people, two different choices. I think we should let the implementers decide this and not the draft writers, grtz Miek . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
