We've submitted a new version of the Third-Party Operator draft for review. There's one outstanding issue–brought up at the Prague meeting–regarding conflict resolution of data received via multiple update mechanisms (e.g. EPP and CDS) which the authors are in disagreement about. We're submitting -04 with the updates we do agree on in order to prevent the draft from expiring, but my personal hope is that we'll have an update including the remaining issue within the next couple of weeks.
---------- Forwarded message ---------- From: <internet-dra...@ietf.org> Date: 12 September 2017 at 18:23 Subject: New Version Notification for draft-ietf-regext-dnsoperator-to-rrr-protocol-04.txt To: Jacques Latour <jacques.lat...@cira.ca>, Paul Wouters <p...@nohats.ca>, Matthew Pounsett <m...@conundrum.com>, Olafur Gudmundsson < olafur+i...@cloudflare.com> A new version of I-D, draft-ietf-regext-dnsoperator-to-rrr-protocol-04.txt has been successfully submitted by Matthew Pounsett and posted to the IETF repository. Name: draft-ietf-regext-dnsoperator-to-rrr-protocol Revision: 04 Title: Third Party DNS operator to Registrars/Registries Protocol Document date: 2017-09-12 Group: regext Pages: 15 URL: https://www.ietf.org/internet-drafts/draft-ietf-regext- dnsoperator-to-rrr-protocol-04.txt Status: https://datatracker.ietf.org/doc/draft-ietf-regext- dnsoperator-to-rrr-protocol/ Htmlized: https://tools.ietf.org/html/draft-ietf-regext-dnsoperator- to-rrr-protocol-04 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-regext- dnsoperator-to-rrr-protocol-04 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-regext- dnsoperator-to-rrr-protocol-04 Abstract: There are several problems that arise in the standard Registrant/Registrar/Registry model when the operator of a zone is neither the Registrant nor the Registrar for the delegation. Historically the issues have been minor, and limited to difficulty guiding the Registrant through the initial changes to the NS records for the delegation. As this is usually a one time activity when the operator first takes charge of the zone it has not been treated as a serious issue. When the domain uses DNSSEC it necessary to make regular (sometimes annual) changes to the delegation, updating DS record(s) in order to track KSK rollover. Under the current model this is prone to delays and errors, as the Registrant must participate in updates to DS records. This document describes a simple protocol that allows a third party DNS operator to: establish the initial chain of trust (bootstrap DNSSEC) for a delegation; update DS records for a delegation; and, remove DS records from a secure delegation. The DNS operator may do these things in a trusted manner, without involving the Registrant for each operation. This same protocol can be used by Registrants to maintain their own domains if they wish. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
