Subject: [weirds] WGLC review for draft-ietf-weirds-bootstrap

From: Tom Harrison <[email-masked]>
Date: Tue, 9 Sep 2014 10:30:55 +1000

The document looks good, just a couple of minor issues.

It was previously suggested
(http://www.ietf.org/mail-archive/web/weirds/current/msg03908.html)
that the "rdap_bootstrap" keys be removed from the bootstrap files.  I
agree with this suggestion, but if there is a reason for the key to be
retained, its name should be changed to "rdapBootstrap", to avoid any
confusion with regard to the use of underscores for extensions as per
section 3.2 of json-response.

For domain bootstrap (section 4), I think it needs to be clearer that
the matching is on a per-label basis.  Changing "doing the longest
match" to "doing the label-wise longest match" and striking "This is a
string search ... in the arrays" could work.

-Tom

---

From: Naoki Kambe <[email-masked]>
Date: Tue, 09 Sep 2014 16:31:01 +0900 (JST)

Hello,

I have some minor comments on draft-ietf-weirds-bootstrap for WGLC.

---
In the Bootstrap examles:
   {
     "rdap_bootstrap": {
       "version": "1.0",
       "publication": "YYYY-MM-DDTHH:MM:SSZ",
       "description": "RDAP Bootstrap file for example registries.",

       "services": [

+ The "publication" value should be an actual date like
  "2014-09-09T10:23:57Z".

+ A blank line between either "publication" or "description" and
  "services" should be removed because it has no special meaning.

---
In Section 3,

    The syntax of "publication" value conforms to the Internet date/time
    format [RFC3339].

In addition to that, the "publication" value must be updated every
time the corresponding registration data are updated by IANA.

---
Also in Section 3,

   All Domain Names labels used as keys or base RDAP URLs in the
   registries defined in this document MUST be only represented in
   lowercase.

In addition to that, All Domain Names must be unique (must not be
duplicate) in one Bootstrap.

---
In Section 4,

   The domain names authoritative registration data service is found by
   doing the longest match of the target domain name with the domain
   values in the arrays in the IANA Domain Name RDAP Bootstrap Registry.

As Tom-san previously pointed out, "the longest match" is a bit
unclear for me too. For example, if the registry has the following
Bootstrap:
    ...
    [
      [ "example.com" ],
      [ "https://example.com/foo/" ],
    ], [
      [ "b.example.com" ],
      [ "https://example.com/bar/" ]
    ]
    ...

in case of an RDAP query for "ab.example.com", which must be the
longest match, "example.com" or "b.example.com" ?

So for avoiding such confusion, I'd like to propose that it should
explicitly have a "."  prefix in each name as the following:
    ...
    [
      [ ".example.com" ],
      [ "https://example.com/foo/" ],
    ], [
      [ ".b.example.com" ],
      [ "https://example.com/bar/" ]
    ]
    ...

---
In Section 11,

   The HTTP Content-Type returned to clients accessing the JSON output
   of the registries MUST be "application/json" as defined in [RFC7159].

In addition to that, the registry must produce HTTP headers including
"Access-Control-Allow-Origin: *" for being widely accessed.

---
Regards,

Naoki Kambe

---

From: Andy Newton <[email-masked]>
Date: Tue, 9 Sep 2014 13:25:55 +0000

I started coding up use of the bootstrap JSON as described in this draft, and ran across something that makes generalization of parsing code more difficult than it should be.

For domains, IPv4, and IPv6 bootstraps the entry array is simply an array of strings. But for AS numbers, the array can contain a number, an array of two numbers, or a combination thereof (and the given example doesn’t show that last one). It would be simpler if it was simply an array of strings like the other bootstraps, where a single AS number is given as a number in a string and a range of AS numbers is given as a string in the form of “start-end” (e.g. “64512-65534”). This would make writing one routine for parsing all the bootstraps much easier.

The ABNF for the string would be *DIGIT 0*1(“-“ *DIGIT)

-andy

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 9 Sep 2014 09:51:00 -0400

Le 2014-09-09 à 09:25, Andy Newton <[email-masked]> a écrit :

> I started coding up use of the bootstrap JSON as described in this draft,

good!

> and ran across something that makes generalization of parsing code more difficult than it should be.
> 

I agree with that. In fact, it was strings a few revisions ago and someone (John if I remember well) was arguing about to have AS numbers as numbers. Others?

Marc.

> 
> -andy
> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds

---

From: Andy Newton <[email-masked]>
Date: Tue, 9 Sep 2014 14:05:49 +0000

> I agree with that. In fact, it was strings a few revisions ago and someone (John if I remember well) was arguing about to have AS numbers as numbers. Others?

Yeah, I remember that. And I may have even agreed with him at the time. But coding these things up tends to find the rough spots.

-andy

---

From: "John Levine" <[email-masked]>
Date: 9 Sep 2014 18:26:56 -0000

In article <[email-masked]> you write:
>I started coding up use of the bootstrap JSON as described in this draft, and ran across something that makes
>generalization of parsing code more difficult than it should be.
>
>For domains, IPv4, and IPv6 bootstraps the entry array is simply an array of strings. But for AS numbers, the array can
>contain a number, an array of two numbers, or a combination thereof (and the given example doesn’t show that last one).
>It would be simpler if it was simply an array of strings like the other bootstraps, where a single AS number is given
>as a number in a string and a range of AS numbers is given as a string in the form of “start-end” (e.g. “64512-65534”).
>This would make writing one routine for parsing all the bootstraps much easier.

How about always a pair of numbers?  If it's a single ASN, the numbers are the same.

R's,
John

---

From: Andy Newton <[email-masked]>
Date: Tue, 9 Sep 2014 19:19:54 +0000

On Sep 9, 2014, at 2:26 PM, John Levine <[email-masked]<mailto:[email-masked]>> wrote:

Even simpler.

-andy