Registration Data Access Protocol (RDAP) Object Tagging
RFC 8521

Note: This ballot was opened for revision 04 and is now closed.

(Adam Roach) Yes

(Ignas Bagdonas) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

Comment (2018-08-01 for -04)
No email
send info
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?

Alissa Cooper No Objection

Comment (2018-07-31 for -04)
No email
send info
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 RDAP URL. This maybe has little practical effect but surely MyLocalRIR would not be too happy with it.

(Spencer Dawkins) No Objection

Benjamin Kaduk No Objection

Comment (2018-07-27 for -04)
No email
send info
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, 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.

(Suresh Krishnan) No Objection

Warren Kumari No Objection

Comment (2018-07-30 for -04)
No email
send info
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"?

(Mirja Kühlewind) No Objection

(Terry Manderson) No Objection

(Alexey Melnikov) (was Discuss) No Objection

Comment (2018-08-02 for -04)
No email
send info
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": [

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.