Registration Data Access Protocol (RDAP) Object Tagging
draft-ietf-regext-rdap-object-tag-05

[Ballot comment]
This is a fine document, but I have one possible issue that I would like to quickly discuss before recommending approval of this document:

Looking at the example in Section 3:

  {
    "version": "1.0",
    "publication": "YYYY-MM-DDTHH:MM:SSZ",
    "description": "RDAP service provider bootstrap values",
    "services": [
      [
        ["YYYY"],

Values like YYYY are not distinguishable from TLD values registered in .
All numeric values (ASNs or ranges of ASNs), as well as IPv4/IPv6 addresses are syntactically distinguishable from TLDs, but values registered in this document are not.
Is this a problem? My concern is about fetching JSON from  and misinterpreting it as valid data from the registry established in this document or vice versa.

        [
          "https://example.com/rdap/"
        ]
      ],
      [
        ["ZZ54"],
        [
          "http://rdap.example.org/"
        ]
      ],
      [
        ["1754"],
        [
          "https://example.net/rdap/",
          "http://example.net/rdap/"
        ]
      ]
    ]
    }

[Ballot comment]
I'm also a little surprised to see this as a BCP. It seems to define at least a bit of protocol as part of the "practice".

§3.1: Does the FCFS registration policy allow a potential for squatting or other malicious behavior?

[Ballot comment]
I'm not sure why anyone would do this, but I'll ask anyway: is there no concern about someone maliciously registering an identifier against an existing RDAP URL, given that the registry is specified to be FCFS? Let's say I have a grudge against MyLocalRIR and I go register "fubar" as the service provider name together with an existing mylocalrir.org RDAP URL. This maybe has little practical effect but surely MyLocalRIR would not be too happy with it.

[Ballot comment]
Thank you for writing this - it solves a useful purpose, and is clear and easy to read.

I had 2 comments / questions - please also see Tim Chown'sOpsDir review for a useful nit.

Section  2.  Object Naming Practice
The entire 'HYPHEN-MINUS' selection makes me slightly twitchy - the argument that it was chosen because it is commonly already used as a separator feels like it cuts both ways - the fact that 'Handles can themselves contain HYPHEN-MINUS characters' already seems to argue that a different separator should have been chosen to minimize the chance of collisions / people getting this wrong.  I get that the document says "the service provider identifier is found following the last HYPHEN-MINUS character in the tagged identifier", and would feel more comfortable if some of the examples contained more than one hyphen to make this clearer.

Section 7. Security Considerations
'The transport used to access the IANA registries can be more secure by using TLS [RFC5246], which IANA supports.'
I'm confused by this sentence in the Security Considerations section - more secure than what, not using TLS? Why isn't this something like "The transport used to access the IANA registries SHOULD (or MUST) be over TLS"?

[Ballot comment]
Thank you for writing this - it solves a useful purpose, and is clear and easy to read.

I had 2 comments / questions.

Section  2.  Object Naming Practice
The entire 'HYPHEN-MINUS' selection makes me slightly twitchy - the argument that it was chosen because it is commonly already used as a separator feels like it cuts both ways - the fact that 'Handles can themselves contain HYPHEN-MINUS characters' already seems to argue that a different separator should have been chosen to minimize the chance of collisions / people getting this wrong.  I get that the document says "the service provider identifier is found following the last HYPHEN-MINUS character in the tagged identifier", and would feel more comfortable if some of the examples contained more than one hyphen to make this clearer.

Section 7. Security Considerations
'The transport used to access the IANA registries can be more secure by using TLS [RFC5246], which IANA supports.'
I'm confused by this sentence in the Security Considerations section - more secure than what, not using TLS? Why isn't this something like "The transport used to access the IANA registries SHOULD (or MUST) be over TLS"?

[Ballot discuss]
This is a fine document, but I have one possible issue that I would like to quickly discuss before recommending approval of this document:

Looking at the example in Section 3:

  {
    "version": "1.0",
    "publication": "YYYY-MM-DDTHH:MM:SSZ",
    "description": "RDAP service provider bootstrap values",
    "services": [
      [
        ["YYYY"],

Values like YYYY are not distinguishable from TLD values registered in .
All numeric values (ASNs or ranges of ASNs), as well as IPv4/IPv6 addresses are syntactically distinguishable from TLDs, but values registered in this document are not.
Is this a problem? My concern is about fetching JSON from  and misinterpreting it as valid data from the registry established in this document or vice versa.

        [
          "https://example.com/rdap/"
        ]
      ],
      [
        ["ZZ54"],
        [
          "http://rdap.example.org/"
        ]
      ],
      [
        ["1754"],
        [
          "https://example.net/rdap/",
          "http://example.net/rdap/"
        ]
      ]
    ]
    }

[Ballot 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.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-regext-rdap-object-tag-03. If any part of this review is inaccurate, please let us know.

The IANA Services Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete.

First, a new registry is to be created called the RDAP Bootstrap Services Registry. We understand that the new registry is to be managed via First Come, First Served as defined in RFC 8126.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

IANA Question --> Section 3 of the current draft provides an example of the JSON output of the regsitry. However, there appear to be no initial values for the registry and the current draft appears to make no registrations. Is this correct?

IANA Question --> Could Section 3 or Section 5.1 be updated with a description of the physical appearance of the registry? It would be useful to understand the link between the registrations and the JSON output.

Second, in the RDAP Extensions located at:

https://www.iana.org/assignments/rdap-extensions/

a single, new registration is to be made as follows:

Extension identifier: rdap_objectTag
Registry operator: Any
Published specification: [ RFC-to-be ]
Contact: IESG
Intended usage: This extension describes a best practice for structuring entity identifiers to enable query bootstrapping.

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-06-19):

From: The IESG
To: IETF-Announce
CC: adam@nostrum.com, jgould@verisign.com, regext-chairs@ietf.org, James Gould , draft-ietf-regext-rdap-object-tag@ietf.org, regext@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Registration Data Access Protocol (RDAP) Object Tagging) to Best Current Practice


The IESG has received a request from the Registration Protocols Extensions WG
(regext) to consider the following document: - 'Registration Data Access
Protocol (RDAP) Object Tagging'
  as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-06-19. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  The Registration Data Access Protocol (RDAP) includes a method that
  can be used to identify the authoritative server for processing
  domain name, IP address, and autonomous system number queries.  The
  method does not describe how to identify the authoritative server for
  processing other RDAP query types, such as entity queries.  This
  limitation exists because the identifiers associated with these query
  types are typically unstructured.  This document updates RFC 7484 by
  describing an operational practice that can be used to add structure
  to RDAP identifiers that makes it possible to identify the
  authoritative server for additional RDAP queries.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-object-tag/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-object-tag/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc7484: Finding the Authoritative Registration Data (RDAP) Service (Proposed Standard - IETF stream)

Technical Summary

This document updates RFC 7484 by describing an operational practice
that can be used to add structure to RDAP identifiers that makes it
possible to identify the authoritative server for additional RDAP queries.

Working Group Summary

draft-ietf-regext-rdap-object-tag is on best current practice track. 
The document defines an entity identifier structure in RFC 7484 to
support identifying the authoritative server for additional RDAP queries.

Document Quality

This document has been discussed on the mailing lists of the regext
working group.  The authors have addressed all comments and
changes have been incorporated in the document. 

Verisign Labs and OpenRDAP have working implementations of this specification.


Personnel

Document shepherd is James Gould, jgould@verisign.com
Area Director is Adam Roach, adam@nostrum.com

Shepherd Comments

As document shepherd I have verified that all the JSON examples. The “…” convention
used in the examples was removed to perform the verification.  The rdapConformance structure
example JSON snippet verified by adding the leading “{“ and the trailing “}” characters. 

The author has confirmed following BCP78 and BCP79 in the document header.
No IPR disclosures have been submitted for this document.

The IANA considerations follow the defined format for the submission of the
RDAP Service Providers Registry and the RDAP Extensions Registry. 

All normative and informative references have been verified.

After carefully reviewing the mailings lists of the regext working
group I have found no objections to this document. From IETF meetings I recall
broad consensus that this document is ready for publication.

As document shepherd I believe this document is ready for publication.