Skip to main content

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

Yes

(Adam Roach)

No Objection

(Deborah Brungard)
(Ignas Bagdonas)
(Mirja Kühlewind)
(Spencer Dawkins)
(Suresh Krishnan)
(Terry Manderson)

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

Warren Kumari
No Objection
Comment (2018-07-30 for -04) Unknown
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"?
Adam Roach Former IESG member
Yes
Yes (for -04) Unknown

                            
Alexey Melnikov Former IESG member
(was Discuss) No Objection
No Objection (2018-08-02 for -04) Unknown
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 <https://www.iana.org/assignments/rdap-dns/rdap-dns.xhtml>.
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  <https://www.iana.org/assignments/rdap-dns/rdap-dns.xhtml> 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/"
         ]
       ]
     ]
    }
Alissa Cooper Former IESG member
No Objection
No Objection (2018-07-31 for -04) Unknown
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.
Ben Campbell Former IESG member
No Objection
No Objection (2018-08-01 for -04) Unknown
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?
Benjamin Kaduk Former IESG member
No Objection
No Objection (2018-07-27 for -04) Unknown
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.
Deborah Brungard Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Ignas Bagdonas Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Suresh Krishnan Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Terry Manderson Former IESG member
No Objection
No Objection (for -04) Unknown