Child-to-Parent Synchronization in DNS
draft-ietf-dnsop-child-syncronization-07

[Ballot comment]
I am clearing the DISCUSS based on Wes Hardaker's proposed text to address point 3, and our discussion of points 1 and 2.  Thanks!

In 2.1.2, why SHOULD and not MUST here?

      Implementations that support parsing of presentation format
      records SHOULD be able to read and understand these TYPE
      representations as well.

In 3.2.1, what happens if the parent queries a host, and that host no longer appears in the updated NS record?  I think this is Mostly Harmless, but might be worth mentioning.  Also, in principle if the old server is left running but no longer authoritative, this whole scheme would fail if, for example, it had been the master prior to the change, were not configured to no longer serve the zone, and were no longer being updated.  This is probably worth mentioning as an operational consideration.

Points from my DISCUSS:

Point 1--

2.1.1.1 doesn't talk about SOA serial number overflow.  It's not clear to me that the security goal intended by this section is correctly addressed if the implementation assumes that the comparison operators defined in section 3.2 of RFC 1982 are used, rather than doing a simple unsigned compare.

I don't think there's a clearly correct answer here, but the issue should be documented and, ideally, a choice should be made.  To clear this DISCUSS, the document needs to say which of the two sets of comparison operators apply, and needs to explain how serial number wrap events are accounted for (or that they are not accounted for, and this is an open issue with security implications).

The easiest way to fix this would be to require a comparison for equality, but I realize that this would place an additional burden on implementations which may be impractical.

Point 2--

In 3.2.1, you don't say what to do if the name server returns an NS record listing names queries on which result in NXDOMAIN, or for which neither A nor AAAA records exist.

Point 3--

I don't think you've specifically excluded RRtypes not mentioned in section 3.2.  It's seems obvious to me based on what's stated in section 2 that the intention of the document is to only support these two RRtypes, but I think it is necessary to say so explicitly, if that is in fact what is intended.  If something else is intended, text explaining what is intended should be added.  E.g., if it's okay for cooperating child name servers to set bits not listed here, and for cooperating parent name servers to process them, you should say so.

[Ballot comment]
I am clearing the DISCUSS based on Wes George's proposed text to address point 3, and our discussion of points 1 and 2.  Thanks!

In 2.1.2, why SHOULD and not MUST here?

      Implementations that support parsing of presentation format
      records SHOULD be able to read and understand these TYPE
      representations as well.

In 3.2.1, what happens if the parent queries a host, and that host no longer appears in the updated NS record?  I think this is Mostly Harmless, but might be worth mentioning.  Also, in principle if the old server is left running but no longer authoritative, this whole scheme would fail if, for example, it had been the master prior to the change, were not configured to no longer serve the zone, and were no longer being updated.  This is probably worth mentioning as an operational consideration.

Points from my DISCUSS:

Point 1--

2.1.1.1 doesn't talk about SOA serial number overflow.  It's not clear to me that the security goal intended by this section is correctly addressed if the implementation assumes that the comparison operators defined in section 3.2 of RFC 1982 are used, rather than doing a simple unsigned compare.

I don't think there's a clearly correct answer here, but the issue should be documented and, ideally, a choice should be made.  To clear this DISCUSS, the document needs to say which of the two sets of comparison operators apply, and needs to explain how serial number wrap events are accounted for (or that they are not accounted for, and this is an open issue with security implications).

The easiest way to fix this would be to require a comparison for equality, but I realize that this would place an additional burden on implementations which may be impractical.

Point 2--

In 3.2.1, you don't say what to do if the name server returns an NS record listing names queries on which result in NXDOMAIN, or for which neither A nor AAAA records exist.

Point 3--

I don't think you've specifically excluded RRtypes not mentioned in section 3.2.  It's seems obvious to me based on what's stated in section 2 that the intention of the document is to only support these two RRtypes, but I think it is necessary to say so explicitly, if that is in fact what is intended.  If something else is intended, text explaining what is intended should be added.  E.g., if it's okay for cooperating child name servers to set bits not listed here, and for cooperating parent name servers to process them, you should say so.

[Ballot discuss]
Adding on to Ted's DISCUSS: The Security Considerations need to make clear that this mechanism MUST NOT be used to synchronize DS records between child and parent (whether this is allowed through the base protocol or some extension).  This is because the DS records are the only thing the parent has that allows it to validate all the DNSSEC signatures that it is required to verify -- if an attacker can change the DS record, then it can change any other record it wants to.

[Ballot comment]
First sentence in Sec 1 is missing an it:
"This document specifies how a child zone in the DNS ([RFC1034],
  [RFC1035]) can publish a record to indicate to a parental agent that
  can copy and process certain records from the child zone."
^ it

In Sec 2: What does unpunishable data mean in
"Errors due to unsupported Type Bit Map bits, or otherwise
  nonpunishable data, SHALL result in no change to the parent zone's
  delegation information for the Child."

In Sec 3.1:  It says " If the SOA serial numbers are equal but less than the CSYNC record's
  SOA Serial Field [RFC1982], the record MUST NOT be processed."  which seems to
contradict what is stated in Sec 2.1.1.1 "If the
  soaminimum flag is not set, parental agents MUST ignore the value in
  the SOA Serial Field.  Clients can set the field to any value if the
  soaminimum flag is unset, such as the number zero."
Perhaps I'm missing a relevant DNS clue?

[Ballot discuss]
Point 1--

2.1.1.1 doesn't talk about SOA serial number overflow.  It's not clear to me that the security goal intended by this section is correctly addressed if the implementation assumes that the comparison operators defined in section 3.2 of RFC 1982 are used, rather than doing a simple unsigned compare.

I don't think there's a clearly correct answer here, but the issue should be documented and, ideally, a choice should be made.  To clear this DISCUSS, the document needs to say which of the two sets of comparison operators apply, and needs to explain how serial number wrap events are accounted for (or that they are not accounted for, and this is an open issue with security implications).

The easiest way to fix this would be to require a comparison for equality, but I realize that this would place an additional burden on implementations which may be impractical.

Point 2--

In 3.2.1, you don't say what to do if the name server returns an NS record listing names queries on which result in NXDOMAIN, or for which neither A nor AAAA records exist.

Point 3--

I don't think you've specifically excluded RRtypes not mentioned in section 3.2.  It's seems obvious to me based on what's stated in section 2 that the intention of the document is to only support these two RRtypes, but I think it is necessary to say so explicitly, if that is in fact what is intended.  If something else is intended, text explaining what is intended should be added.  E.g., if it's okay for cooperating child name servers to set bits not listed here, and for cooperating parent name servers to process them, you should say so.

[Ballot comment]
In 2.1.2, why SHOULD and not MUST here?

      Implementations that support parsing of presentation format
      records SHOULD be able to read and understand these TYPE
      representations as well.

In 3.2.1, what happens if the parent queries a host, and that host no longer appears in the updated NS record?  I think this is Mostly Harmless, but might be worth mentioning.  Also, in principle if the old server is left running but no longer authoritative, this whole scheme would fail if, for example, it had been the master prior to the change, were not configured to no longer serve the zone, and were no longer being updated.  This is probably worth mentioning as an operational consideration.

[Ballot comment]
First sentence in Sec 1 is missing an it:
"This document specifies how a child zone in the DNS ([RFC1034],
  [RFC1035]) can publish a record to indicate to a parental agent that
  can copy and process certain records from the child zone."
^ it

In Sec 2: What does unpunishable data mean in
"Errors due to unsupported Type Bit Map bits, or otherwise
  nonpunishable data, SHALL result in no change to the parent zone's
  delegation information for the Child."

[Ballot discuss]
In the definition of the CSYNC Flags registry in the IANA Considerations, you have two conflicting statements:

ONE:
  Assignment of new flag values are subject to
  "RFC Required" specifications [RFC5226].

TWO:
  For new assignments to be made to this registry, a new RFC must be
  published via a Standards Action.

Which is it: RFC Required, or Standards Action?  They are different (the former allows for Experimental or Informational RFCs, and RFCs in the Independent or IRTF streams; the latter requires a Standards Track RFC in the IETF stream).  There's also "IETF Review", which requires an IETF stream RFC, but allows Informational or Experimental).

[Ballot comment]

- general: Couldn't a child ask for its CSYNC record to be
published in the parent? (and so on up...) I think you should
say a parent MUST NOT take a child's CSYNC in the same way
that you say to not use CSYNC for DS RRs.

- 2.1.1.2.1: Is the meaning of "blindly" sufficiently clear
that all implementers and deployers will get this right?
I'm willing to believe you if you say it is.

[Ballot comment]
[Updating for -03]

Sections 4.2, 4.3, and 4.4: The MAYs in there MAY be inappropriate. The ones about providing interfaces sure don't seem like protocol options. On the others it's hard to tell. Please review. The SHOULDs in 4.1 and 4.4 seems also suspiciously wrong.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-dnsop-child-syncronization-02.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

We have two "Notes" for the requested actions by this document.

IANA understands that, upon approval of this document, there are two actions which IANA must complete.

First, in the Resource Record (RR) TYPEs sub-registry of the Domain Name System (DNS) Parameters registry located at:

http://www.iana.org/assignments/dns-parameters/

a new Resource Record type will be registered as follows:

Type: CSYNC
Value: [ TBD-at-registration ]
Meaning: Child To Parent Synchronization
Reference: [ RFC-to-be ]

NOTE 1:
IANA understand that the author has requested a value of 61 to be used for this registration.
But, draft-ietf-dane-openpgpkey has taken value 61.  The author may edit the I-D to either
remove 61 and suggest 62, or simply put TBD.

Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.

Second, a new subregistry of the Domain Name System (DNS) Parameters registry located at:

http://www.iana.org/assignments/dns-parameters/

is to be created and called the Child Synchronization (CSYNC) Flags registry. This new subregistry is to be maintained using "RFC Required" as defined in RFC 5226.

There are initial registrations in this registry as follows:

Bit Flag Description Reference
---- ------ ------------- -----------
Bit 0 immediate Immediately process this [ RFC-to-be
CSYNC record. Section 3]
Bit 1 soaminimum Require a SOA serial [ RFC-to-be
number greater than the Section 2.1.1.1]
one specified.
Bits 2-15 are unassigned.

NOTE 2: Please edit the URL in the IANA Considerations section:

FROM:
(http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml)

TO:
(http://www.iana.org/assignments/dns-parameters)

This will ensure the URL will always work and point to the most current
version/extension.

IANA understands these to be the only actions required of IANA upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Child To Parent Synchronization in DNS) to Proposed Standard


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document:
- 'Child To Parent Synchronization in DNS'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-08-22. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document specifies how a child zone in the DNS can publish a
  record to indicate to a parental agent that it may copy and process
  certain records from the child zone.  The existence of and value
  change of the record may be monitored by a parental agent and acted
  on as appropriate.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dnsop-child-syncronization/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dnsop-child-syncronization/ballot/


No IPR declarations have been submitted directly on this I-D.

[Ballot comment]
[This document is being re-Last Called, so my DISCUSS is no longer relevant.]

Good document. A few simple comments:

Section 3:

      Require that the child zone administrator approve the operation
      through an out-of-band mechanism (such as through pushing a button
      via a web interface).  I.e., a parental agent MAY choose not to
      support the "immediate" flag.

I think you reversed this sentence. Better would be:

      Choose not to process the CSYNC record immediately, even if the
      "immediate" flag is set. That is, a parental agent might require
      the child zone administrator approve the operation through an
      out-of-band mechanism (such as through pushing a button via a web
      interface).

Sections 4.2, 4.3, and 4.4: The MAYs in there MAY be inappropriate. The ones about providing interfaces sure don't seem like protocol options. On the others it's hard to tell. Please review. The SHOULD in 4.4 seems also suspiciously wrong.

[Ballot discuss]
The writeup and the document itself say that this is going to be Standards Track, which seems appropriate. But the datatracker says that it is going for Informational, the Last Call went out as Informational, and it is being balloted as Informational. If the intention is that this is Standards Track, this needs a new Last Call and needs to be on a new telechat. (For those that might be thinking that this is meaningless process-wonkery, please note that getting the status wrong has consequences: Barry and I split up Informational documents so only one of us reviews each. Therefore, Barry did not review this document at all. I am quite sure if this is to be Standards Track, he would want to review it.)

[Ballot comment]
Good document. A few simple comments:

Section 3:

      Require that the child zone administrator approve the operation
      through an out-of-band mechanism (such as through pushing a button
      via a web interface).  I.e., a parental agent MAY choose not to
      support the "immediate" flag.

I think you reversed this sentence. Better would be:

      Choose not to process the CSYNC record immediately, even if the
      "immediate" flag is set. That is, a parental agent might require
      the child zone administrator approve the operation through an
      out-of-band mechanism (such as through pushing a button via a web
      interface).

Sections 4.2, 4.3, and 4.4: The MAYs in there MAY be inappropriate. The ones about providing interfaces sure don't seem like protocol options. On the others it's hard to tell. Please review. The SHOULD in 4.4 seems also suspiciously wrong.

[Ballot discuss]
I support the publication of this document, but I have one point that I would like to discuss.  I *think* this should be easy...

Section 2.1.1.2.1 ends with this text:

  Specifically: a parental agent must not copy data blindly; An IETF
  proposed (or higher) standard specification must exist that defines
  how the data should be processed for a given bit.

I am not sure how this gets enforced given its locality within the document.  I think it is easier to enforce by taking the text out of 2.1.1.2.1 and adding text to the IANA Considerations section stating that in order to allocate a bit out of the Child Synchronization (CSYNC) Flags registry, the RFC needs to be published via Standards Action (per RFC 5226). That would clearly control what type of document can get a bit allocated out of that registry.

[Ballot comment]
I have no objection to the publication of this document, but note a
couple of nits.

---

I'm a pedant, I know, but...
Abstract
OLD
  This document specifies how a child zone in the DNS can publish a
  record to indicate to a parental agent that it may copy and process
  certain records from the child zone.  The existence of and value
  change of the record may be monitored by a parental agent and acted
  on as appropriate.
NEW
  This document specifies how a child zone in the DNS can publish a
  record to indicate to a parental agent that the parental agent may
  copy and process certain records from the child zone.  The existence
  of the record and any change in its value may be monitored by a
  parental agent and acted on depending on local policy.
END

- "...it may..." is marginally ambiguous
- "...existence of and value of..." was sufficiently clumsy to cause
  re-reading
- "as appropriate" always rings an alarm bell with me because it
  actually says nothing :-)  (I may be wrong about "...depending on
  local policy" which would:
  - prove my point
  - allow you to substitute your own text.

The same paragraph appears in the Introduction.

---

Continuing the pedantic theme (don't I have anything better to do with
my time?)...

Section 1

  It has been traditionally challenging for child DNS operators to
  update their delegation records within the parent's set in a timely
  fashion.

"Tradition"?
Image of my grandfather on the roof of his house with violin and DNS
server.
Maybe just strike the word.

Also "child DNS operators" made me giggle unmercifully.
Maybe "operators of child DNS zones"?
In general, the inclusion of "zone" after "DNS" will help clarify.

---

2.1.1.2 and 2.1.1.2.1.

c/Section Section/Section/

acker.
IANA Actions - YES

REVISED IANA ACTIONS: This revised review is based on version 02 of
this drafted document

IANA understands that, upon approval of this document there are two
actions which IANA must complete.

ACTION 1:
IANA is requested to assign a new DNS Resource Record Type from
the "Resource Record (RR) TYPEs" sub-registry of the "Domain Name
System (DNS) Parameters" registry located at:


  http://www.iana.org/assignments/dns-parameters

The new request type is:

    TYPE    Value    Meaning                          Reference
    -----  ------  --------------------------        -----------
    CSYNC  TBA      Child To Parent Synchronization  [This document]

NOTEs:
1. IANA understands that the code-point 61 is being requested.

2. Please revise the URL in the IANA Considerations section:

FROM:
(http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml)

TO:
(http://www.iana.org/assignments/dns-parameters)

This will ensure the URL will always work and point to the most current
version/extension.

ACTION 2:
IANA is also requested to create a new sub-registry called
"Child Synchronization (CSYNC) Flags" and hosted under
the "Domain Name System (DNS) Parameters" registry located
at:

http://www.iana.org/assignments/dns-parameters

The initial assignments in this registry are:

    Bit      Flag        Description              Reference
    ----    ------      -------------            -----------
    Bit 0    immediate  Immediately process this  [This document,
                          CSYNC record.            Section 3]

    Bit 1    soaminimum  Require a SOA serial      [This document,
                          number greater than the  Section 2.1.1.1]
                          one specified.

The defined range is 16 flags.
Assignment of new flag values are subject to "RFC Required" specifications [RFC5226]."

The actions requested in this document will not be completed until the document has been approved for publication as an RFC.

Authors should review the comments and/or questions above and
report any inaccuracies and respond to any questions as soon
as possible.

Thank you,

Pearl Liang
ICANN



On Sat Jul 19 16:15:20 2014, iesg-secretary@ietf.org wrote:
> Evaluation for  can be
> found at
> http://datatracker.ietf.org/doc/draft-ietf-dnsop-child-syncronization/
>
> Last call to expire on: 2014-06-23 00:00
>
>
>        Please return the full line with your position.
>
>                      Yes  No-Objection  Discuss  Abstain
> Joel Jaeggli        [ X ]    [  ]      [  ]    [  ]
>
>
> Has enough positions to pass.
>
> DISCUSSES AND COMMENTS
> ===========
> ?
> ---- following is a DRAFT of message to be sent AFTER approval ---
> From: The IESG
> To: IETF-Announce
> Cc: RFC Editor ,
>    dnsop mailing list ,
>    dnsop chair
> Subject: Document Action: 'Child To Parent Synchronization in DNS' to
> Informational RFC (draft-ietf-dnsop-child-syncronization-01.txt)
>
> The IESG has approved the following document:
> - 'Child To Parent Synchronization in DNS'
>  (draft-ietf-dnsop-child-syncronization-01.txt) as Informational RFC
>
> 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.
>
>
>

dnsop-child-syncronization Shepherd Write up

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February
2012.

(1) This RFC is being requested as Standards Track. This is
introducing a new DNS RRTYPE related to delegation records within a
parent zone.

(2) 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.


(3)/(4) 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.

(5) N/A

(6) No concerns

(7) No IPR disclosures

(8) No IPR disclosures filed.

(9) This draft underwent several long discussions, and during last
call, several sections were re-written to answer editorial issues
raised. The group is happy.

(10) There is no discontent (10) There is no indicated discontent

(11) All nits have been addressed.

(12) N/A

(13) References identfied as either normative or informative

(14) no normative references

(15) no downward normative references issues


(16) No change in existing RFCs

(17) IANA considerations refer to the creation of an RRType, and the
request to assign a new RRType for 'CDNSKEY' type. .

(18) DNS RRType registry will need "DNS Expert Review" to assign a new
RRType.

(19) Only formal language in document was DNS RRTYPE format, which was
reviewed by the document shepherd but not yet confirmed by the “DNS
expert review” individual of the IESG.

dnsop-child-syncronization Shepherd Write up

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) This RFC is being requested as Standards Track.  This is introducing a new DNS RRTYPE related to delegation records within a parent zone.

(2)

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.


(3)/(4) 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.

(5) N/A

(6) No concerns

(7) No IPR disclosures

(8) No IPR disclosures filed.

(9) This draft underwent several long discussions, and during last call, several sections were re-written to answer editorial issues raised.  The group is happy.

(10) There is no discontent
(10) There is no indicated discontent

(11) All nits have been addressed.

(12) N/A

(13) References identfied as  either normative or informative

(14) no normative references

(15) no downward normative references issues


(16)  No change in existing RFCs

(17)  IANA considerations refer to the creation of an RRType, and the request to
assign a new RRType for 'CDNSKEY' type. .

(18) DNS RRType registry will need "DNS Expert Review" to assign a new RRType.

(19) Only formal language in document was DNS RRTYPE format, which was reviewed by the document shepherd but not yet confirmed by the “DNS expert review” individual of the IESG.

dnsop-child-syncronization Shepherd Write up

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) This RFC is being requested as Standards Track.  This is introducing a new DNS RRTYPE related to delegation records within a parent zone.

(2)

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.


(3)/(4) 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.

(5) N/A

(6) No concerns

(7) No IPR disclosures

(8) No IPR disclosures filed.

(9) This draft underwent several long discussions, and during last call, several sections were re-written to answer editorial issues raised.  The group is happy.

(10) There is no discontent
(10) There is no indicated discontent

(11) All nits have been addressed.

(12) N/A

(13) References identfied as  either normative or informative

(14) no normative references

(15) no downward normative references issues


(16)  No change in existing RFCs

(17)  IANA considerations refer to the creation of an RRType, and the request to
assign a new RRType for 'CDNSKEY' type. .

(18) DNS RRType registry will need "DNS Expert Review" to assign a new RRType.

(19) Only formal language in document was DNS RRTYPE format, which was reviewed by the document shepherd but not yet confirmed by the “DNS expert review” individual of the IESG.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-dnsop-child-syncronization-01.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA has a question about the action requested in the IANA Considerations section of this document.

The IANA Considerations section requests that:

"This document defines a set of single-bit "Flags" for use in the CSYNC record within the 16 bit Flags field. Thus, a maximum of 16 flags may be defined. The two initial flags defined by this document are:

0x00 0x01: "immediate"
0x00 0x02: "soaminimum"

Assignment of new flag values are subject to "RFC Required" specifications [RFC5226]."

IANA has several questions:

1) Is this a request for a new registry?

2) If so, where would this new registry be created? Does it belong at an existing URL (see http://www.iana.org/protocols for the index), or should IANA create a new page/URL?

3) What is the exact name of this new registry, as it should appear online?

4) Can you confirm that the range of available values is 0x00 0x03 - 0x00 0x0F, and that 0x00 0x00 does not appear in the registry?

5) The string "CSYNC" doesn't appear anywhere on the IANA website. Is this document making a registration called "CSYNC"? If so, in which registry?

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Child To Parent Synchronization in DNS) to Informational RFC


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document:
- 'Child To Parent Synchronization in DNS'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-06-23. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document specifies how a child zone in the DNS can publish a
  record to indicate to a parental agent that it may copy and process
  certain records from the child zone.  The existence of and value
  change of the record may be monitored by a parental agent and acted
  on as appropriate.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dnsop-child-syncronization/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dnsop-child-syncronization/ballot/


No IPR declarations have been submitted directly on this I-D.

dnsop-child-syncronization Shepherd Write up

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) This RFC is being requested as Standards Track.  This is introducing a new DNS RRTYPE related to delegation records within a parent zone.

(2)

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.


(3)/(4) 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.

(5) N/A

(6) No concerns

(7) No IPR disclosures

(8) No IPR disclosures filed.

(9) This draft underwent several long discussions, and during last call, several sections were re-written to answer editorial issues raised.  The group is happy.

(10) There is no discontent
(10) There is no indicated discontent

(11) All nits have been addressed.

(12) N/A

(13) References identfied as  either normative or informative

(14) no normative references

(15) no downward normative references issues


(16)  No change in existing RFCs

(17)  IANA considerations refer to the creation of an RRType, and the request to
assign a new RRType for 'CDNSKEY' type. .

(18) DNS RRType registry will need "DNS Expert Review" to assign a new RRType.

(19) Only formal language in document was DNS RRTYPE format, which was reviewed by the document shepherd but not yet confirmed by the “DNS expert review” individual of the IESG.