[regext] Benjamin Kaduk's No Objection on draft-ietf-regext-rdap-object-tag-04: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Fri, 27 July 2018 17:51 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: regext@ietf.org
Delivered-To: regext@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D3085131032; Fri, 27 Jul 2018 10:51:36 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk <kaduk@mit.edu>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-regext-rdap-object-tag@ietf.org, James Gould <jgould@verisign.com>, regext-chairs@ietf.org, jgould@verisign.com, regext@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.83.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153271389685.32575.14236059863408474169.idtracker@ietfa.amsl.com>
Date: Fri, 27 Jul 2018 10:51:36 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/mYCr4M9sGddJLORknhLRJKLzR0E>
Subject: [regext] Benjamin Kaduk's No Objection on draft-ietf-regext-rdap-object-tag-04: (with COMMENT)
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.27
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Jul 2018 17:51:37 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-regext-rdap-object-tag-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-object-tag/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I was a little surprised to see that this document targets BCP status, not
Proposed Standard.  Was there much discussion of this question in the WG?

Section 2

   Service provider tags are concatenated to the end of RDAP query
   object identifiers to unambiguously identify the authoritative server

It seems like it is the combination of concatenation of the service
provider tag, and the use of the rdap_objectTag_level_0 rdapConformance
attribute that provides the unambiguous property; I would like to see this
caveat made more clear here.

Also, per https://www.iab.org/2016/11/07/iab-statement-on-ipv6/, please
consider using IPv6 addresses in the examples.

Section 5.1

Are all provided URLs supposed to be functionally different?  If not, how
do we tell which ones do what?

Section 7

Perhaps note that it is using IANA as a well-known central trusted
authority in order to provide the property of allowing users to get RDAP
data from an authoritative source?

   [...] The method has the same security
   properties as the RDAP protocols themselves.  The transport used to
   access the IANA registries can be more secure by using TLS [RFC5246],
   which IANA supports.

Well, I don't know that "the same as" is quite right, especially given the
following sentence.  The composed chain of "talk to iana, talk to referred
RDAP server" depends both on the security of the connection to the RDAP
server and that of the connection to IANA; it seems prudent to note that if
TLS is used for the RDAP connection, TLS should also be used when talking
to IANA, or even that TLS should always be used when talking to IANA.