[regext] AD Review: draft-ietf-regext-rdap-object-tag

Adam Roach <adam@nostrum.com> Mon, 04 June 2018 23:46 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B477A130E14 for <regext@ietfa.amsl.com>; Mon, 4 Jun 2018 16:46:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level:
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no
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 hGkaJqqCsbdA for <regext@ietfa.amsl.com>; Mon, 4 Jun 2018 16:46:05 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B409D130E11 for <regext@ietf.org>; Mon, 4 Jun 2018 16:46:05 -0700 (PDT)
Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w54NWG1f079139 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 4 Jun 2018 18:32:17 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local
To: "regext@ietf.org" <regext@ietf.org>, draft-ietf-regext-rdap-object-tag@tools.ietf.org
From: Adam Roach <adam@nostrum.com>
Message-ID: <7426e645-9de3-20ed-f4c4-7e1f46703233@nostrum.com>
Date: Mon, 4 Jun 2018 18:32:11 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/VYbscA450lhXYxriVUXuyHHKe3g>
Subject: [regext] AD Review: draft-ietf-regext-rdap-object-tag
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
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: Mon, 04 Jun 2018 23:46:07 -0000

I've reviewed the document draft-ietf-regext-rdap-object-tag in 
preparation for
placing it into IETF last call. The mechanism and document generally 
look good
and useful; however, I have some concerns about its URL synthesis.

The mechanical synthesis of URLs as described in this document 
contravenes the
requirements of BCP 190, section 2.3. Ordinarily, I would consider this a
showstopper and ask the working group to adjust handling to match BCP 190
requirements (e.g., using RFC 6570 URI Templates). Because this 
specification
simply builds upon RFC 7484 techniques for performing URI synthesis, 
however,
forcing such a change would result in an incongruity that I understand might
cause deployment issues.

Nonetheless, I request that the working group consider whether the use of
something like RFC 6570 would be appropriate for the mechanism described 
this
document. Please also understand that other area directors may note and 
object
to this type of URL synthesis during IESG processing. Chairs: please let me
know when you believe working group consideration of this issue is complete.

---------------------------------------------------------------------------

I also have one question about an example in section 2:

 >  For example, if the base RDAP URL
 >  "https://example.com/rdap/" is associated with service provider
 >  "YYYY" in an IANA registry, an RDAP client will parse a tagged entity
 >  identifier "XXXX-YYYY" into distinct handle ("XXXX") and service
 >  provider ("YYYY") identifiers.  The service provider identifier
 >  "YYYY" is used to query an IANA registry to retrieve the base RDAP
 >  URL "https://example.com/rdap/".  The base RDAP URL is concatenated
 >  to the entity handle to create a complete RDAP query path segment of
 >  "https://example.com/rdap/entity/XXXX-YYYY".

I read the text as calling for implementors to concatenate "XXXX-YYYY" 
to the
end of the IANA-registered base URL ("https://example.com/rdap/"), 
resulting in
"https://example.com/rdap/XXXX-YYYY". The example instead shows
"https://example.com/rdap/entity/XXXX-YYY". Is the inclusion of "entity/" in
this example an error?


Thanks for the work everyone has done on this document.

/a