Re: [DNSOP] Protocol Action: 'Child To Parent Synchronization in DNS' to Proposed Standard (draft-ietf-dnsop-child-syncronization-07.txt)

Tim Wicinski <tjw.ietf@gmail.com> Tue, 20 January 2015 16:29 UTC

references: <20150120155207.5561.14509.idtracker@ietfa.amsl.com>
To: dnsop mailing list <dnsop@ietf.org>
From: Tim Wicinski <tjw.ietf@gmail.com>
message-id: <54BE8276.3060104@gmail.com>
Date: Tue, 20 Jan 2015 11:29:42 -0500
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:37.0) Gecko/20100101 Thunderbird/37.0a2
mime-version: 1.0
in-reply-to: <20150120155207.5561.14509.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/QoPl6CT5fHo1Y0vhXHYfcYu-ZCI>
Cc: joel jaeggli <joelja@bogus.com>
Subject: Re: [DNSOP] Protocol Action: 'Child To Parent Synchronization in DNS' to Proposed Standard (draft-ietf-dnsop-child-syncronization-07.txt)
Precedence: list

I wanted to thank all the folks who offered comments, edits, and text 
for this document.

Big thanks to Joel for patiently wading through the review process and 
Wes for the last-minute iterations.

tim

On 1/20/15 10:52 AM, The IESG wrote:
> The IESG has approved the following document:
> - 'Child To Parent Synchronization in DNS'
>    (draft-ietf-dnsop-child-syncronization-07.txt) as Proposed Standard
>
> This document is the product of the Domain Name System Operations Working
> Group.
>
> The IESG contact persons are Joel Jaeggli and Benoit Claise.
>
> A URL of this Internet Draft is:
> http://datatracker.ietf.org/doc/draft-ietf-dnsop-child-syncronization/
>
>
>
>
>
> Technical Summary
>
> This document specifies how a child zone in DNS can publish records
> indicating to the parent zone to process and act on these records. It
> does this by introducing a new Resource Record Type named CSYNC
>
> Working Group Summary
>
> Initially the WG attempting to combine this work with the
> draft-ietf-dnsop-delegation-trust-maintainance document. However, it
> became clearer they were two different approaches, and the request was
> dropped.
>
>
> Document Quality
>
> Currently there are no implementations for the handling of this
> RRType. It was implied that some of the public domain software
> packages will deploy this, but have not so far.
>
> We believe the reviews have been thorough and substantial.
>
> Personnel
>
> Tim Wicinski is the Document Shepherd Joel Jaggeli is the Area
> Director
>
> The document Shepherd feels that this draft underwent a strong
> technical and editorial review, and there is no concern about the
> breath of reviews.
>
>
> RFC Editor Note
>
> One final editorial nit from Barry Leiba
>
> section 6 iana considerations
> ...
> Change the words to say "Standards Action", which is the term in 5226 that apllies.  Saying RFC Required, even with the explanation, invites both IANA and other readers to misunderstand.
>
> So you could say, instead, 'Assignment of new flag values are subject to "Standards Action" specifications [RFC5226], publishing the definition of the new value in a standards track RFC.'
> ...
>

[DNSOP] Protocol Action: 'Child To Parent Synchro… The IESG
Re: [DNSOP] Protocol Action: 'Child To Parent Syn… Tim Wicinski
Re: [DNSOP] Protocol Action: 'Child To Parent Syn… Wes Hardaker