Managing DS Records from the Parent via CDS/CDNSKEY
draft-ietf-dnsop-maintain-ds-06

I agree with Kathleen that this is useful document. I also agree with her DISCUSS.

I wish you could mandate use of S/MIME or OpenPGP for confirmation emails suggested in the document, but this might be too much to ask for.

Will be following the resolutions of others' DISCUSSes.

One more place where normative language seems inappropriate:

"Turning off DNSSEC reduces the security of the domain and thus should
   only be done carefully, and that decision SHOULD be fully under the
   child domain's control."

I agree with Jari's and Terry's respective discusses. I will watch for the outcome of those discussions.

Some other minor comments (I've skipped some that other people have already commented on, but I'm sure there's still overlap):

- 1.2: It seems like scenarios 1 and 3 are restatements of the same thing. That is, cannot/does-not-want-to seems to count as an operational limitation.

-4, 3rd paragraph: "If a validator sees a DNSKEY or DS record with
   this algorithm value, it MUST treat it as unknown."
I suspect that, in the context of "Right now", this is talking about the current state of affairs, rather than defining a new requirement. Thus the 2119 MUST is probably not appropriate. 

-- 4th paragraph: I think this MUST is also not appropriate. It's part of the definition of algorithm "0", and not a procedural requirement.

Editorial Comments:

-1.3, first paragaph: "When this document uses the word CDS it implies that the same applies
   to CDNSKEY and vice verse."
I don't understand this sentence.

-2, first paragraph:
s/influence/performe

-2, operation 2: Please expand KSK on first use

-2, 5th paragraph: It’s sort of confusing to talk about options labeled with ordinal numbers in a different order than their labels.

-3, first paragraph: First Sentence: I'm not sure what "... enable... for the future." means.  Does that mean “for the foreseeable future”, or perhaps “indefinitely enable”?

-- 2nd sentence is hard to parse. I suggest the following:
OLD
  Thus during the period from the time the child publishes
   the CDS until the corresponding DS is published at the parent is the
   period that DNS answers for the child could be forged.
NEW
  DNS answers could be forged during the period between when the child
  publishes the CDS until the parent publishes the corresponding DS.

-4, third paragraph: "Right now, ..."
That language will quickly become dated. I suggest "At the time of this writing, ..."

Thanks for the added text.

One technical comment:
How does the client know that the parent supports the DNSSEC Delete Algorithm and it actually can turn of DNSSEC after a while? What how long is a while? Would it be possible to define a reply message from the parent to the client to confirm that the deletion was understood?

One more or less editorial comment:
I agree with Spencer that the use of normative language in the security section is odd. All used SHOULDs should be lower case. But I would also recommend to rephrase to give clear guidance, e.g.

OLD:
"A parent zone might also consider sending an email to its
   contact addresses to give the child zone a warning that security will
   be enabled after a certain amount of wait time - thus allowing a
   child administrator to cancel the request."

NEW:
"A parent zone may send an email to its
   contact addresses to give the child zone a warning that security will
   be enabled after a defind amount of wait time - thus allowing a
   child administrator to cancel the request."

OR:
"A parent zone MAY send an email to its
   contact addresses to give the child zone a warning that security will
   be enabled after a defined amount of wait time - thus allowing a
   child administrator to cancel the request."

I understand why most of the 2119 language appears in this draft, but the SHOULDs in this text

   Users SHOULD keep in mind that re-establishing trust in delegation
   can be hard and takes a long time.  Before deciding to complete the
   rollover via an unsigned state, all options SHOULD be considered.
   
don't look like 2119 SHOULDs to me. 

I also note that there's a SHOULD in section 1.2, but 2119 terminology isn't introduced until section 1.4 (easy enough to fix, by moving section 1.4 up, but).

Agree with Jari, Terry and would like to see the 7344 situation resolved.

Thank you for addressing my concerns. Clearing my DISCUSS.