Re: [DNSOP] Adam Roach's No Objection on draft-ietf-dnsop-attrleaf-fix-04: (with COMMENT)

Dave Crocker <dhc@dcrocker.net> Wed, 10 October 2018 13:51 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 82DB0130EFB; Wed, 10 Oct 2018 06:51:18 -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 HRuTlC5uGIA1; Wed, 10 Oct 2018 06:51:16 -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 7F028130ED8; Wed, 10 Oct 2018 06:51:16 -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 w9ADpbor009220 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 10 Oct 2018 06:51:38 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1539179500; bh=1xV/KwX+f52JHDiBrw+NjNlSoZ4wU1W+yqcUa4qBnK0=; h=From:Subject:To:Cc:References:Date:In-Reply-To:From; b=BarWrNOMvkAuBaRmtE0LIi+uSmNlGqXnxrhfj96pidC9noGExFOSl8xGiDrYMcb4s M6UWi/gZsjruGA3R/fvsf5RVvBJuIaluOtR+s4b0oo+QK3eKZ1LINtpcpFoXO7h7ic 4fEaJSeuaie/aYx7DfZX9sde6e+z8iSy9UexsKSg=
From: Dave Crocker <dhc@dcrocker.net>
To: Adam Roach <adam@nostrum.com>, The IESG <iesg@ietf.org>
Cc: benno@NLnetLabs.nl, dnsop@ietf.org, dnsop-chairs@ietf.org, draft-ietf-dnsop-attrleaf-fix@ietf.org
References: <153905658979.18363.9468480045775152891.idtracker@ietfa.amsl.com>
Message-ID: <7e5ae04b-e285-e0e8-0c8e-44a6cbeeca25@dcrocker.net>
Date: Wed, 10 Oct 2018 09:51:20 -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: <153905658979.18363.9468480045775152891.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/n93i8fbDhi9IBCW3NkjrAwWDvTY>
Subject: Re: [DNSOP] Adam Roach's No Objection on draft-ietf-dnsop-attrleaf-fix-04: (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 13:51:19 -0000

Responding to your additional comments...


On 10/8/2018 11:43 PM, Adam Roach wrote:
> Echoing comments from my review of draft-ietf-dnsop-attrleaf: I believe this
> document needs to also include RFC 6763 and RFC 4386; and that it should not
> include RFC 6733. Please see that review for details.


RFC 6733 (Diameter):

      Section 5.2 #3 cites SRV usage with underscore details.  So it 
should remain in -fix, to trigger review of this text if/when the spec 
is revised.

      However the entry in the base table, citing it, should be removed, 
because the RFC 6733 _tls text is an example and not a spec.


RFC 6763:

      Wow.  Whole new RR category for the table, for PTR usage (in the 
base spec, as well as -fix.)

      If I am reading 6763 correctly, in terms of 'global' underscored 
use and distinguishing its 'hypotheticals' from actual usage, it only 
reserves _tcp and _udp.  (For example, its use of _ipp is second-level 
and therefore not global.)


RFC 4386:

      SRV usage.  So, yeah, it's in -fix.



> §§2.1 and 2.2:
> 
>>   An effort has been made to locate existing drafts that
>>   do this, register the global underscored names, and list them in this
>>   document.
> 
> I think this text ("list them in this document") is left over from before this
> document was split from draft-ietf-dnsop-attrleaf.

oops.  However I think it useful to highlight the possibility of names' 
having been missed in the initialization of the registry -- and your 
review here has nicely demonstrated the issue... -- so rather than drop 
that sentence, I've modified it to:

      An effort has been made to locate existing drafts that do this,
      register the global underscored names, and list them in the initial
      set of names added to the registry.


> §2.3:
> 
> This ties back to my discuss on draft-ietf-dnsop-attrleaf, and needs to be
> changed in a way that is consistent with however that issue is resolved. The
> current list of entries added by draft-ietf-dnsop-attrleaf strongly implies that
> the contents of https://www.iana.org/assignments/enum-services were
> automatically imported into the namespace created by the Underscore Global
> Registry by the simple existence of RFC 7553. If that's the case, it seems that
> the following text in this document...
> 
>>   For any document that specifies the use of a "URI" RRset
> 
> ...doesn't capture the real process here. As RFC 7553 will continue to exist
> into the future, it seems that the trigger is addition of new Enumservice
> entries, rather than the explicit specification of a new URI RRset.

Given the choice of de-coupling maintenance of the tables, there is no 
goal to make an entry into the underscore table for each new name in 
enumservice.  Rather there is a need to make an entry in the underscore 
table for every URI use of a new underscore entry.


d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net