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?
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.
I gather that your main point is that making this Proposed would be better?
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
