Hi Dave, > On Oct 10, 2018, at 12:49 PM, Dave Crocker <d...@dcrocker.net> wrote: > > On 10/10/2018 10:03 AM, Alissa Cooper wrote: >> I agree with Alexey. It seems like the expert is being asked to do the review >> that IANA would typically do itself. > > Point taken. However, there was wg discussion about the choice and it landed > on this. > > I'll await either wg or iesg direction for specific text changes to the draft > on this. > > >> Please address the Gen-ART review nits. > > Did that some time ago, though I believe I did not receive a followup > response:
The response below was about attrleaf-fix, not attrleaf. The Gen-ART review for attrleaf is at https://mailarchive.ietf.org/arch/msg/dnsop/dq-cwawY1UqoGJWFUxQPuWv0oPc. Thanks, Alissa > >> -------- Forwarded Message -------- >> Subject: Fwd: Re: Genart last call review of draft-ietf-dnsop-attrleaf-fix-04 >> Date: Wed, 26 Sep 2018 13:29:07 -0700 >> From: Dave Crocker <dcroc...@bbiw.net> >> To: draft-ietf-dnsop-attrleaf-...@ietf.org >> G'day. >> Just for completeness... >> Absent direction to the contrary, I'm making no changes concerning the >> following items (with the ones that have produced changes elided): >> (BTW, I can't find documentation that explains the sub-addressing scheme for >> sending to folk associated with an internet-draft, and I don't remember the >> details of the various choices. So I dropped the .all in case it meant the >> entire wg. /d) >> -------- Forwarded Message -------- >> Subject: Re: Genart last call review of draft-ietf-dnsop-attrleaf-fix-04 >> Date: Mon, 24 Sep 2018 06:16:13 -0700 >> From: Dave Crocker <dcroc...@gmail.com> >> To: Francesca Palombini <francesca.palomb...@ericsson.com>, gen-...@ietf.org >> ... >> On 9/24/2018 3:00 AM, Francesca Palombini wrote: >>> The use of underscored node names is specific to each RRTYPE that is >>> being scoped. >>> As an non-expert in the area, I would have appreciate a ref to a document >>> introducing RRTYPE. >> The term is basic to DNS, with RFC 1035 cited in the first sentence of the >> Introduction: >> "Original uses of an underscore character as a domain node name >> [RFC1035] prefix, which creates a space for constrained >> interpretation of resource records, were specified without the >> benefit of an [IANA-reg] registry." >> Once such a citation has been included, is a document expected to repeat the >> citation for every term used from it? The implication is that someone >> reading this sort of document is not expected to have basic DNS familiarity? >> However this did cause me to look for the first use of "RRTYPE" and I >> discovered that RFC 1035 has "RR TYPE" but not "RRTYPE". I'm not sure where >> first use without the space started. >>> This section provides a generic approach for changes to existing >>> specifications that define straightforward use of underscored node >>> names, when scoping the use of a "TXT" RRset. >>> Same for "TXT" RRset. >> Same response. >>> An effort has been made to locate existing drafts that >>> do this, register the global underscored names, and list them in this >>> document. >>> Since the effort has been done, I would have appreciated the full list here. >> This is the 'fix' document, not the registry definition document. The >> latter is cited in the first paragraph of this document's Introduction: >> "A registry has been now defined, and that document >> discusses the background for underscored domain name use >> [Attrleaf]." >> That's where the list is provided. >>> An >>> effort has been made to locate existing drafts that do this, register >>> the global underscored names, and list them in this document. >>> Same as previous comment. >> Same response. >>> An effort has been made to locate >>> existing drafts that do this and register the associated 'protocol' >>> names. >>> Same as previous. >> Same response. >> ... >>> + Those registered by IANA in the "Service Name and Transport >>> Protocol Port Number Registry [RFC6335]" >>> Move the end quote after Registry. >> ok. Good catch. >> /// 9/26: As I posted to the wg, these actually appear to be a bug in the >> xml2rfc processing tool at the IETF site. I've made changes to the document >> to work around it. /d >>> John Levine, Bob Harold, Joel Jaeggli, Ondřej Sury and Paul >>> In Acknowledgements, one name is not encoded correctly. >> I believe this as a bug in the xml2rfc generator used by the tools site, for >> text format, since the correct text is produced by an xml to html generator. >> /// 9/26: This also appears to be a tool bug. /d >>>> From running the idnits tool (https://tools.ietf.org/tools/idnits/), >>>> several >>> comments, warnings and one error were raised, which I snipped and pasted >>> below >>> as a summary: >> What's most interesting here is that the document passed IDNits during >> submission! (Apparently nits only works on txt documents and I only >> submitted an xml version; I'd guess the submission process does not general >> a txt version on the fly, for nits to inspect...) >>> -- The draft header indicates that this document updates RFC****, but the >>> abstract doesn't seem to mention this, which it should. (see >>> https://www.ietf.org/id-info/checklist) --> I see that the abstract >>> generally >>> mentions "the existing specifications that use underscore naming", but I >>> think to make this correct, it should explicitely list them as well. >> That actually makes no sense to me, since that would be fully redundant with >> the Updates header field that is already provided. >> ... >>> == Unused Reference: several documents are included in the list of >>> references, but no explicit reference was found in the text --> if my >>> editorial comments are taken, they should fix this one. >> This actually poses an interesting challenge. The references are used in >> the Updates header field, but apparently IDNits does not look there. >>> ** Downref: Normative reference to an Informational RFC: RFC 7553 >> That document is a specification. This document modifies it. No matter >> it's standards track status, it is a normative reference to this document. >> ... >> d/ > > > > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
