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&#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

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to