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

Dave Crocker <dhc@dcrocker.net> Wed, 10 October 2018 16:49 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0104130F8A; Wed, 10 Oct 2018 09:49:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.491
X-Spam-Level:
X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=dcrocker.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1b26Z4tqT4g; Wed, 10 Oct 2018 09:49:28 -0700 (PDT)
Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D0E1130F88; Wed, 10 Oct 2018 09:49:28 -0700 (PDT)
Received: from [172.16.20.49] ([64.80.128.22]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w9AGnjqn022406 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 10 Oct 2018 09:49:46 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1539190187; bh=2slnH3t+QiZO+Zul+aCp3aurgWPaH3raI9rF/CWQgjc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=eOdOvUXO0aB4yAyaTXuT7z5ZvpVpuvxFKJf+znFWf0Te4yV70dTFyMLpdEPOZ9oxP 2yMJJyWrPdkPdLvfCsd/YW63Ck67B2xGHP7VCwXjRHpMU3sX13AyYxg8hhBecj6EFq aJV17SU8JpuExPM1C9BbbD1NJYhPNzDT0Mb60G8g=
To: Alissa Cooper <alissa@cooperw.in>, The IESG <iesg@ietf.org>
Cc: draft-ietf-dnsop-attrleaf@ietf.org, Tim Wicinski <tjw.ietf@gmail.com>, Benno Overeinder <benno@NLnetLabs.nl>, dnsop-chairs@ietf.org, dnsop@ietf.org
References: <153918020224.5848.13121328738608688797.idtracker@ietfa.amsl.com>
From: Dave Crocker <dhc@dcrocker.net>
Message-ID: <ce783a4c-e215-d564-e83c-578aa510b625@dcrocker.net>
Date: Wed, 10 Oct 2018 12:49:28 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <153918020224.5848.13121328738608688797.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/57lZfcogR_N_AlcxLj2FO5u0O_4>
Subject: Re: [DNSOP] Alissa Cooper's No Objection on draft-ietf-dnsop-attrleaf-13: (with COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Oct 2018 16:49:31 -0000

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:

> -------- 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 <dcrocker@bbiw.net>
> To: draft-ietf-dnsop-attrleaf-fix@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 <dcrocker@gmail.com>
> To: Francesca Palombini <francesca.palombini@ericsson.com>, gen-art@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