Re: [DNSOP] Alissa Cooper's No Objection on draft-ietf-dnsop-attrleaf-13: (with COMMENT)

[Alissa Cooper <[e-mail]>]

Hi Dave,

> On Oct 10, 2018, at 12:49 PM, Dave Crocker <[e-mail]> 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 <[e-mail]>
>> To: [e-mail]
>> 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 <[e-mail]>
>> To: Francesca Palombini <[e-mail]>, [e-mail]
>> ...
>> 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&#345;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