Hi Dave, > On Oct 10, 2018, at 2:32 PM, Dave Crocker <d...@dcrocker.net> wrote: > > On 10/10/2018 10:52 AM, Alissa Cooper wrote: >> I think this document needs to state explicitly which updates apply to which >> existing RFCs. That is, I would expect to see in sections 2.1, 2.2, and 2.3 >> the list of which documents are updated by each section. I realize this can >> be >> intuited, but typically for avoidance of doubt authors specify precisely >> which >> updates apply to which documents. This will also clear up the unused >> references >> that idnits is pointing out. > > What is the downside of using the existing text, as compared against the > effort (and delay -- quite possibly infinite) caused by requiring development > of the considerable detail that you are calling for?
I think the downsides are (1) people reading the documents updated by this document are confused about which parts of the update apply, and (2) it sets a precedent that one RFC can update another without being specific about what is being updated. I’m not asking for considerable detail, I’m asking for each of 2.1, 2.2, and 2.3 to specify which documents out of the list in the Updates header they update. > > My question is not about the difference in cleanliness but about serious, > practical risk. > > >> I would also like to understand why this is going for BCP. There is >> effectively no shepherd write-up for this draft (it's just a copy of the >> write-up for draft-ietf-dnsop-attrleaf and talks about this document as the >> "companion" document) so there is no explanation there. One effect of this >> being BCP is that it adds a huge number of documents to the downref registry. >> It's not clear to me that the upside of that is bigger than the downside. > > I've no comment about status choice. > > Concerning the shepherd writeup, I'm not understanding what problem(s) it is > causing. Typically the shepherd write-up explains why a particular document status was chosen. Since this document doesn’t have a write-up, it doesn’t have that explanation. > > I gather that your main point is that making this Proposed would be better? I think so. Thanks, Alissa > > >> Sections 2.1, 2.2, 2.3: I don't understand why the paragraphs "If a public >> specification that defines ... MUST be entered into this registry, if it is >> not >> already registered" are needed, since the same normative requirement is >> generically stated in draft-ietf-dnsop-attrleaf. > > Good point. I've changed those 3 bits of text to a commentary form: > > <t>Note that a public specification, which defines use of an RRset and > calls for the use of an underscore-prefixed domain name, its global > underscored name -- the one closest to the root -- is required to be entered > into this registry, if it is not already registered. <xref > target="Attrleaf"></xref>.</t> > > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
