On Sun, Oct 30, 2016 at 11:49 PM, Matthew Pounsett <m...@conundrum.com> wrote:
> Hi all. > > I've submitted an update for the below draft which I'd like the working > group to eventually consider for adoption. If there's time in the agenda, > I'd like to ask the chairs for some time to discuss this in Seoul. > > As with the previous version, I'm looking for some specific feedback on a > few things. > > 1) I believe this draft represents operational experience that could be > added to RFC6781. While it doesn't (intentionally) change anything in > 6781, I think the additional operator change procedure justifies the > "updates" meta-data in the draft. With the increase in gTLDs and the > expected future increase in gTLD transfers I think it's important to put > this information in front of operators searching for advice, which makes > having it appear as a link from the 6781 meta-data important. I'd like to > get the group's feeling on that. > > 2) RFC 6781 does not explicitly describe the timings of each step in the > operator change procedure, leaving that as an exercise for the reader to > obtain by reading earlier sections of the RFC. The -01 version of this > draft followed that style for a couple of reasons: first, so as not to > unnecessarily duplicate any information; second, to avoid unintentionally > introducing any ambiguity or update to the information in 6781. I've been > of two minds on that, however. I felt that the aim of this draft–to > provide advice to inexperienced operators–was not well served by leaving a > prose description of the procedure out. With the recent publication of > errata for § 4.1.2, my opinion has tipped slightly the other way, and so > I've added text to describe the steps and their timings. > > 3) I don't believe this draft raises any *new* security considerations, so > I've done my best to incorporate by reference the security considerations > from 6781. I'd like to know your thoughts on this as well. > > > ---------- Forwarded message ---------- > From: <internet-dra...@ietf.org> > Date: 30 October 2016 at 23:29 > Subject: New Version Notification for draft-pounsett-transferring- > automated-dnssec-zones-02.txt > To: Matthew Pounsett <m...@conundrum.com> > > > > A new version of I-D, draft-pounsett-transferring-au > tomated-dnssec-zones-02.txt > has been successfully submitted by Matthew Pounsett and posted to the > IETF repository. > > Name: draft-pounsett-transferring-automated-dnssec-zones > Revision: 02 > Title: Change of Operator Procedures for Automatically Published > DNSSEC Zones > Document date: 2016-10-31 > Group: Individual Submission > Pages: 7 > URL: https://www.ietf.org/internet- > drafts/draft-pounsett-transferring-automated-dnssec-zones-02.txt > Status: https://datatracker.ietf.org/ > doc/draft-pounsett-transferring-automated-dnssec-zones/ > Htmlized: https://tools.ietf.org/html/d > raft-pounsett-transferring-automated-dnssec-zones-02 > Diff: https://www.ietf.org/rfcdiff? > url2=draft-pounsett-transferring-automated-dnssec-zones-02 > > Abstract: > Section 4.3.5.1 of [RFC6781] "DNSSEC Operational Practices, version > 2" describes a procedure for transitioning a DNSSEC signed zone from > one (cooperative) operator to another. The procedure works well in > many situations, but makes the assumption that it is feasible for the > two operators to simultaneously publish slightly different versions > of the zone being transferred. In some cases, such as with TLD > registries, operational considerations require both operators to > publish identical versions of the zone for the duration of the > transition. This document describes a modified transition procedure > which can be used in these cases. > 2.4. The Procedure Second paragraph under "Signing Migration", "ganinig" -> "gaining" In "Post Migration" "severs" is correct, but it looks so much like a common misspelling of "server" that I would replace it with "stops" or "breaks". -- Bob Harold
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
