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