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

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/

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?

Thanks for clarifying the registration policy.

Thanks for addressing my DISCUSS point.

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

Overall, nicely written document.  Thanks!

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

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.