appolgies for setting this aside for a month. IETF intervened, I don't plan to advance this until the question is addressed in any event. On 7/8/16 1:32 PM, Robert Sparks wrote: > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Document: draft-ietf-dnsop-maintain-ds-03 > Reviewer: Robert Sparks > Review Date: 8 Jul 2016 > IETF LC End Date: 11 Jul 2016 > IESG Telechat date: Not yet scheduled for a telechat > > Summary: Ready, but with nits and perhaps a process problem > > Potential process problem: > > This document intends to move RFC7344 from Informational to PS in place > (without republishing RFC7344. The intent to do so is buried at the end > of the document (the abstract doesn't mention it). The Last Call for the > document does not make it clear that _this_ document is elevating > RFC7344. > (It at least mentions it, which is good, but the writeup about the > elevation > can be read to say "we're considering this elevation somewhere else, > keep it > in mind while evaluating this document"). I don't recall the shift in status be controversial within the working group, so perhaps I view it a logical step having developed experience with the work as being worthwhile. That said I think there is a point to be made here between advancing a standards track document and having a standards track document address previously unspecified uses in an informational document, Perhaps a third state is that the standards track document is introducing an entirely new facility (trust anchor setup) and dragging 7334 along with it. I'm not sure the location of section 6.1 particularly matters wrt the question of what to do, it's readily apparent in the front matter as a section heading. possibly the thing to do is hold separate last call for the standards action I don't see this document as proposing any edits to 7334 that would make revising it a necessity. > > There is no hint from the subject line that this is a call to bring > RFC7344 > onto the standards track. Unless there is some other communication effort > that I've missed on a quick search, I think it is very likely that most > of the IETF community outside the dnsop working group missed this intent. > I strongly encourge a last call focusing _specifically_ on moving RFC7344 > to the standards track without republication. that seems like the right think to do. > > My personal feedback on elevating RFC7344 without republishing is that > it's > not the right thing to do. At the very least "Category: Informational" > appears in the document itself, and that will not change. If the IESG > decides to proceed with this as currently formulated, count me in the > deep rough. > > Nits: > > In 1.2, "that decision SHOULD be fully under the child domain's > control"... > Why is that a 2119 SHOULD? I think this is commentary on that it would be > a bad idea for someone else to unilaterally decide to turn of DNSSEC for > a child domain? Why not just say that (it would be even better to expand > on _why_ it's a bad idea. If you really think this is the right way to > say > what you mean, and you keep 2119, please talk about when it would be > ok to > not follow that SHOULD. > > In 1.3, consider pointing to Appendix A of RFC7344 to better define RRR. > > In the Security Considerations, you have "Users SHOULD" and "all options > SHOULD be considered". These are not meaningul uses of 2119 - please use > prose to say what you really mean. If you want to keep them, please talk > about when it would be ok to not follow the SHOULD. I think you're trying > to say "Completing the rollover via an unsigned state is dangerous and > should > only be used as a last resort" or something similarly strong. > > Consider pointing back to the 5 scenarios you spell out in section 1.2 > in the > security considerations section. The asserted existance of operational > and > aoftware limitations that necessitate turning off DNSSEC to facilitate > a change > of operator is certainly a major security consideration. > > Consider doing more to the DNS Security Algorithms Number registry than > the current instructions indicate. Simply adding a reference to this > document > to the row for number 0 does not convey that this "reserved" number is > actually > being _used_ in a protocol, and that when it is it's an algorithm > number that > is not a number for an algorithm. I don't know how to say that > cleanly, but > the registry should say more than simply "reserved" if this document > is approved. > > Typo-nit: s/digiest/digest/ > >