Finding the Authoritative Registration Data (RDAP) Service
draft-ietf-weirds-bootstrap-11

[Ballot comment]
Discuss cleared in favour of Barry's Discuss which covers the same thing.

A few other comments:

Everyone should be aware though that we are creating a live database that would be queried by software, not by implementors.

Anyway, I think that is fine.

Suresh Krishnan had this comment in his Gen-ART review:

* Sections 5.2 and 5.3

-> The document uses some non-documentation addresses (AFAIK) in some of
the examples. e.g. 28.2.0.0/16 for an IPv4 prefix and 2600::/16 for an
IPv6 prefix. Is it possible to rewrite these examples using reserved
documentation addresses? Strangely enough, idnits does not seem to catch
them either.

[Ballot comment]

- p4, where does it say what time is the publication time?  Is
it when the record is created/sent to IANA or when IANA get it
or what?

- section 9, 1st para: I'm not clear what cache expiry
expectations we're setting here for IANA and dislike that that
is essentially a form of dynamic data intended to be related to
registry content that I don't believe IANA has previously been
asked to serve up. I think that's a bad plan.

- section 11 - this ought call for TLS as a MUST

[Ballot comment]
Suresh Krishnan had this comment in his Gen-ART review:

* Sections 5.2 and 5.3

-> The document uses some non-documentation addresses (AFAIK) in some of
the examples. e.g. 28.2.0.0/16 for an IPv4 prefix and 2600::/16 for an
IPv6 prefix. Is it possible to rewrite these examples using reserved
documentation addresses? Strangely enough, idnits does not seem to catch
them either.

[Ballot discuss]
Everyone should be aware though that we are creating a live database that would be queried by software, not by implementors.

Anyway, I think that is fine, but I have a question mark. This could be due to my lack of understanding of WEIRDS. But as far as I can see, the document asks IANA to create a newly formatted view based on the contents of the existing registry database. I understand how most of the data is filled in, but I do not understand how the URLs are created. For instance, for ASes the document says to generate something like this:

        [
          ["2045-2045"],
          [
            "https://rir3.example.com/myrdap/"
          ]
        ],

but if I look at the existing registry, it does not have these URLs, it has something else. E.g.,
from http://www.iana.org/assignments/as-numbers/as-numbers.xhtml:


  Number Description Whois Reference Registration Date
    0 Reserved [RFC-ietf-idr-as0-06]
    1-6 Assigned by ARIN whois.arin.net
    7 Assigned by RIPE NCC whois.ripe.net
    8-27 Assigned by ARIN whois.arin.net
    28 Assigned by RIPE NCC whois.ripe.net

and I do not see the RDAP URLs there. Only WHOIS URLs. Does filling out the RDAP URLs require IANA to contact the people who have made registrations, and ask what the proper URL is? Or am I missing something?

[Ballot comment]
I'm a little unclear as to why this document is necessary.  It seems like given the use of 30X redirects in -using-http, you could just start with an IANA root server and redirect your way down the tree.  It may appear that this bootstrap mechanism saves queries to the root, but you could achieve the same effect or better using 301 redirects with appropriate caching.

The use of JSON in this syntax is slightly disappointing.  Generally, using JSON arrays to contain items of different types is not a great idea.  It seems like the "services" entries should actually be objects, with entries indicating the semantics of the inner arrays, e.g.:

OLD: [ ["1.0.0.0/8", "192.0.0.0/8"], ["https://rir1.example.com/myrdap/"] ]
NEW: { "resources": ["1.0.0.0/8", "192.0.0.0/8"], "urls": ["https://rir1.example.com/myrdap/"] }

This should not be hard to describe in the notation of Section 10.2, and it only uses a few more bytes on the wire.

[Ballot comment]
The use of JSON in this syntax is slightly disappointing.  Generally, using JSON arrays to contain items of different types is not a great idea.  It seems like the "services" entries should actually be objects, with entries indicating the semantics of the inner arrays, e.g.:

OLD: [ ["1.0.0.0/8", "192.0.0.0/8"], ["https://rir1.example.com/myrdap/"] ]
NEW: { "resources": ["1.0.0.0/8", "192.0.0.0/8"], "urls": ["https://rir1.example.com/myrdap/"] }

This should not be hard to describe in the notation of Section 10.2, and it only uses a few more bytes on the wire.

[Ballot comment]
This draft looks fine and adds the appropriate set of security considerations for what it does, however, shouldn't there be a reference to the draft-ietf-weirds-rdap-sec draft to say where everything else should be covered?

Thanks

[Ballot discuss]
DISCUSS point 1, on the clarity of the text about matching:

-- Section 4 --
The matching is of labels from right to left... You and I know that, but will every reader understand that?  With gTLDs upon us, will it always be clear to everyone that a registry entry of "nyc" matches "coffee.nyc", but does not match "nyc.com"?  Will everyone understand that a registry entry of "example.com" matches "good.example.com", but does not match "goodexample.com"?

There's also nothing said about what happens if there are multiple matches at the same specificity.  What if there are two Entry Arrays that both contain "example.com"?  More likely, what if someone makes an error in specifying AS numbers, we get one entry for 10000-12000 and another for 12000-14000... and then we query for 12000?

It might be good to be clearer about exactly what matching is intended, and what doesn't match.  Feel free to use my examples above, if that helps.

-----

DISCUSS point 2: the scope of what we're asking IANA to do, and the question of whether it's really clear both to us and to them what it is, what it will entail, and what it will cost:

-- Section 8 --

  Clients SHOULD cache the
  registry, but use underlying protocol signalling, such as the HTTP
  Expires header field [RFC7234], to identify when it is time to
  refresh the cached registry.

Now you're putting another requirement on IANA, which I'm not sure has been part of the discussion: they have to present the registries in the right format AND manage the TTL of the queries with the Expires header.  Please, please make sure that IANA is very clear about the entire scope of what we're asking, and signs off on it.

-- Section 12 --

  IANA is expected to generate the RDAP Bootstrap
  Services Registries data from these above mentioned registries,
  according to their own registration policies.

I presume "their" refers to the registries, not to IANA, but that's ambiguous, and should be fixed.  The above-mentioned registries do not have RDAP URLs, do they?  Whence is IANA meant to get that information, in order to generate these new registries?

If IANA generates these by periodically re-processing the source registries to pick up changes, how current are the RDAP registries expected to be? Is it OK for them to be updated once a week?  Once a month?  Are we setting up any SLAs for the timeliness and reliability of these registries?

[Ballot comment]
-- Section 1 --

  This document requests IANA to make an augmented version of
  the existing registries available for the specific purpose of
  RDAP use

I presume that IANA has agreed to do that.  Where will the URIs for those augmented registries be published.  That is, how will a bootstrapping application know where to find them for the bootstrapping?

-- Section 3 --

  The JSON object for each
  registry will start with a series of members that contain metadata

"Start with" implies ordering, but members within JSON objects are explicitly unordered.  Do you actually care about the ordering, or should you just change "start with" to "contain" (and similarly change the subsequent "Following that")?

  Each item of the array contains a second-level array,
  with two elements, each of them being a third-level array.

  The first third-level array, named 'Entry array', contains all
  entries that have the same set of base RDAP URLs.  The second third-
  level array, named 'Service URL array', contains the list of base
  RDAP URLs usable for the entries found in the 'Entry array'.  There
  is no assumption of sorting except that the two arrays found in each
  second-level array MUST appear in the correct order: The entries
  array are followed by the service URL array.

This is just an editorial comment, but this description seems unnecessarily complicated, and the "no sorting, but certain things have to be in the right order" is just odd.

May I make a suggestion that gets rid of the "third-level array" awkwardness (and also corrects some wording errors)?:

NEW
  Each element of the Services array is a second-level array with
  two elements: in order, an Entry Array and a Service URL Array.

  The Entry Array contains all entries that have the same set of
  base RDAP URLs.  The Service URL Array contains the list of base
  RDAP URLs usable for the entries found in the Entry Array. Elements
  within these two arrays are not sorted in any way.
END

  Any unknown or unspecified JSON object
  properties or values should be ignored by implementers.

1. Implementers don't ignore the unrecognized things; implementations do.

2. What does it mean to ignore an unspecified thing?  It's not there to be ignored.

3. The "should be" makes people wonder whether it's supposed to be a 2119 key word, and why it's not.  I suggest just using "are" -- that's simply the way it is.

So, maybe:
  Any unrecognized JSON object properties or values are
  ignored by implementations.

-- Section 4 --

  The domain names authoritative registration data service is found by
  doing the label-wise longest match of the target domain name with the
  domain values in the arrays in the IANA Domain Name RDAP Bootstrap
  Service Registry.  The values contained in the second element of the
  array are the valid base RDAP URLs as described in
  [I-D.ietf-weirds-rdap-query].

You have names for these arrays in Section 3; why don't you use them?

NEW
  The domain names authoritative registration data service is found by
  doing the label-wise longest match of the target domain name with the
  domain values in the Entry Arrays in the IANA Domain Name RDAP
  Bootstrap Service Registry.  The values contained in the Service URL
  Array of the matching second-level array are the valid base RDAP URLs
  as described in [I-D.ietf-weirds-rdap-query].
END

And similarly for other times when you say "first element" or "second element".

I'm also thinking more and more that "longest match" should instead be "most specific match", especially for the IP address numbers.

-- Section 5.1 --
Doesn't "CIDR format" need a reference?

-- Section 7 --

  The registries may not contain the requested value or the base RDAP
  URL value may be empty.

Nothing up in Section 3 said that a Service URL Array could be empty.  If that's legal, that fact should be specified up there.

-- Section 10.2 --
In the definition of "rdap-bootstrap-registry" you should note that the "description" member is optional, probably by saying, "and an optional MEMBER description and...".

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Finding the Authoritative Registration Data (RDAP) Service) to Proposed Standard


The IESG has received a request from the Web Extensible Internet
Registration Data Service WG (weirds) to consider the following document:
- 'Finding the Authoritative Registration Data (RDAP) Service'
  as Proposed Standard

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 2014-10-27. 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


  This document specifies a method to find which Registration Data
  Access Protocol (RDAP) server is authoritative to answer queries for
  a requested scope, such as domain names, IP addresses or Autonomous
  System numbers.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-weirds-bootstrap/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-weirds-bootstrap/ballot/


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

1. Summary

The document shepherd is Michael Szucs.
Pete Resnick is the responsible Area Director.

The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from domain name and regional internet registries.  This document specifies a method to find which Registration Data Access Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses or Autonomous System numbers.

The document is requesting Proposed Standard status as per the definition of a Technical Specification in RFC2026 Section 3.1. 

2. Review and Consensus

This document was discussed at length at recent IETF meetings.  Extra consideration was paid by the working group to the IANA Considerations section.  (see below)

The document appears to have the support of the WG, and there is at least one implementation in progress.

There are no known threats of appeals for this document.

I don't believe any particular external review is needed for this document.

3. Intellectual Property

Each author has confirmed conformance with BCP 78/79.  Authors have reconfirmed there are no IPR issues following WGLC.

There are no IPR disclosures on the document.

4. Other Points

The document calls for IANA to setup four RDAP registries.

The WG spent a good deal of time working on the wording of the IANA section.  Attempts were made to clarify the specific data output requirements without providing instruction to IANA on update frequency, policy, etc., since this work has the unusual complication that the registry policies actually will mirror whatever rules ICANN puts in place for updating their name and number registries.

This draft does specify that IANA should implement the required registries in JSON format, rather than specifying only output format requirements.  This was previously corrected but has reappeared.

The document contains a normative reference to RFC 4627 which is obsoleted by RFC 7159; these do not currently appear in the downref registry.

1. Summary

The document shepherd is Michael Szucs.
Pete Resnick is the responsible Area Director.

The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from domain name and regional internet registries.  This document specifies a method to find which Registration Data Access Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses or Autonomous System numbers.

The document is requesting Proposed Standard status as per the definition of a Technical Specification in RFC2026 Section 3.1. 

2. Review and Consensus

This document was discussed at length at recent IETF meetings.  Extra consideration was paid by the working group to the IANA Considerations section.  (see below)

The document appears to have the support of the WG, and there is at least one implementation in progress.

There are no known threats of appeals for this document.

I don't believe any particular external review is needed for this document.

3. Intellectual Property

Each author has confirmed conformance with BCP 78/79.  Authors have reconfirmed there are no IPR issues following WGLC.

There are no IPR disclosures on the document.

4. Other Points

The document calls for IANA to setup four RDAP registries.

The WG spent a good deal of time working on the wording of the IANA section.  Attempts were made to clarify the specific data output requirements without providing instruction to IANA on update frequency, policy, etc., since this work has the unusual complication that the registry policies actually will mirror whatever rules ICANN puts in place for updating their name and number registries.

This draft does specify that IANA should implement the required registries in JSON format, rather than specifying only output format requirements.  This was previously corrected but has reappeared.

The document contains a normative reference to RFC 4627 which is obsoleted by RFC 7159; these do not currently appear in the downref registry.

1. Summary

The document shepherd is Michael Szucs.
Pete Resnick is the responsible Area Director.

The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from domain name and regional internet registries.  This document specifies a method to find which Registration Data Access Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses or Autonomous System numbers.

The document is requesting Proposed Standard status as per the definition of a Technical Specification in RFC2026 Section 3.1. 

2. Review and Consensus

This document was discussed at length at recent IETF meetings.  Extra consideration was paid by the working group to the IANA Considerations section.

The document appears to have the support of the WG, and there is at least one implementation in progress.

There are no known threats of appeals for this document.

I don't believe any particular external review is needed for this document.

3. Intellectual Property

Each author has confirmed conformance with BCP 78/79.  Authors have reconfirmed there are no IPR issues following WGLC.

There are no IPR disclosures on the document.

4. Other Points

The document calls for IANA to setup four RDAP registries.

The WG spent a good deal of time working on the wording of the IANA section.  Attempts were made to clarify the specific data output requirements without providing instruction to IANA on update frequency, policy, etc.

This draft does specify that IANA should implement the required registries in JSON format, rather than specifying only output format requirements.

The document contains a normative reference to RFC 4627 which is obsoleted by RFC 7159.