Antoin, Isn't the Zone Maintainer (DNS operator) really just a delegate of the registrant and not a separate role? The registrants should be in control of their domain name and responsible for managing the keys.
However, many (but certainly not all) may delegate or outsource the function of operating the DNS server to an external party, and maybe also signing. It is probably just a matter of how you look at the relations. I think introducing the DNS operator as a separate entity complicates matters in many cases. Can you give an example where the DNS operations can not fall within the registrants responsibility? If there are circumstances that require this role to be defined, it is also perfectly fine to add that as a subcomponent of the registrant while still being in full compliance with the framework. -- Fredrik On 2010-10-13, at 22:47, Antoin Verschuren wrote: > Op donderdag 30-09-2010 om 16:39 uur [tijdzone +0100], schreef Stephen > Morris: >> >> The working group adopted the draft last year but since then there has been >> little discussion of it on the list. With DNSSEC at last looking as if it >> is really starting to take off, this is a timely document. Please have a >> look at it and give feedback. > > We have used the draft dps framework to write down our DPS when we > introduced DNSSEC for .nl. > We are currently rewriting our DPS to include DS/DNSKEY submission into > our zone, and we encountered a missing comunity in the outline in > section 5. In our DPS, we are defining a dns-operator as an entity that > needs to be defined seperately from an administrative > registry/registrar/registrant definition as sugested in the outline. I > would strongly suggest to include a technical dns-operator definition in > the outline, so that section 3 of the outline will be: > 1.3. Community and Applicability > 1.3.1. Registry > 1.3.2. Registrar > 1.3.3. Registrant > 1.3.4. Zone maintainer > 1.3.5. Relying Party > 1.3.6. Auditor > 1.3.7. Applicability > We're still in discussion if we need to separate zone operator (only running > the DNS server infrastructure) and zone maintainer (who is able to change the > zone's content), or that we can come up with a definition that clearly > defines the entity that is controlling the access to the zone, and can insert > RR's and reload the zone when necessary for DNSSEC maintenance. > My personal opinion is that we need to define an entity that can > add/remove/change DNSKEY RR's and can push the button to resign the zone, and > when he does, can communicate that to the parent zone through registrar, > registrant, registry or any combination of those. > > > > -- > Antoin Verschuren > > Technical Policy Advisor SIDN > Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands > > P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 > mailto:antoin.verschu...@sidn.nl xmpp:ant...@jabber.sidn.nl > http://www.sidn.nl/ > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
