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

The IESG <> Tue, 20 January 2015 15:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 659681B2E13; Tue, 20 Jan 2015 07:52:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Kp-l1UUD0K8K; Tue, 20 Jan 2015 07:52:27 -0800 (PST)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 0C69C1B2E27; Tue, 20 Jan 2015 07:52:07 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <>
To: IETF-Announce <>
Subject: Protocol Action: 'Child To Parent Synchronization in DNS' to Proposed Standard (draft-ietf-dnsop-child-syncronization-07.txt)
X-Test-IDTracker: no
X-IETF-IDTracker: 5.10.0.p8
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <>
Date: Tue, 20 Jan 2015 07:52:07 -0800
Archived-At: <>
Cc: dnsop mailing list <>, dnsop chair <>, RFC Editor <>
X-Mailman-Version: 2.1.15
List-Id: "IETF announcement list. No discussions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 Jan 2015 15:52:29 -0000

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

The IESG contact persons are Joel Jaeggli and Benoit Claise.

A URL of this Internet Draft is:

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

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.


Tim Wicinski is the Document Shepherd Joel Jaggeli is the Area

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.'