Subject: [weirds] I-D Action: draft-ietf-weirds-bootstrap-02.txt

From: [email-masked]
Date: Mon, 23 Jun 2014 05:43:26 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Web Extensible Internet Registration Data Service Working Group of the IETF.

        Title           : Finding the Authoritative Registration Data (RDAP) Service
        Author          : Marc Blanchet
	Filename        : draft-ietf-weirds-bootstrap-02.txt
	Pages           : 11
	Date            : 2014-06-23

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 IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-weirds-bootstrap/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-weirds-bootstrap-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-bootstrap-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 23 Jun 2014 13:59:11 +0100

Hello,
 here is a new version of the bootstrap document. This is a major rewrite based on the various concensus points during last meeting and followup, such as: JSON, using templates, IANA section rewrite, .... After some mailing list discussions and discussions with rdap-query authors, this draft hopefully covers the direction of the wg.
 One can look at the diffs, but I'm not sure it is that valuable given major rewrite.

Regards, Marc.

Début du message réexpédié :

> De: [email-masked]
> Objet: I-D Action: draft-ietf-weirds-bootstrap-02.txt
> Date: 23 juin 2014 13:43:26 UTC+1
> À: [email-masked]
> Cc: [email-masked]
> Répondre à: [email-masked]
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Tom Harrison <[email-masked]>
Date: Tue, 24 Jun 2014 10:51:15 +1000

> "services": [
> ["entry1", "entry2", "entry3"]: {
>    "template": "{proto}://registry.example.com/myrdap/{resource}",
>    "proto": [ https ],
>   },
> ["entry4"]: {
>    "template": "{proto}://example.org/{resource}",
>   },
> ],
 
This is using arrays, instead of strings, as keys. Given that
"services" is not an object, but an array, is the structure meant to
be like this:

    "services": [
        [ ["entry1", "entry2", "entry3"], 
          { "template": "{proto}://registry.example.com/myrdap/{resource}",
            "proto": [ "https" ] } ],
        [ ["entry4"], 
          { "template": "{proto}://example.org/{resource}" } ]
    ]

instead?

> For example, a domain RDAP query for a.b.example.com matches the com
> entry in one of the arrays of the registry.  Following the example
> above, the base RDAP URL for this query is
> "https://registry.example.com/myrdap/".  The {resource} specified in
> [I-D.ietf-weirds-rdap-query] is then appended to the base URL to
> complete the query.  The complete query is then
> "https://registry.example.com/myrdap/domain/a.b.example.com".  This
> example is not normative.

This limits implementations to path-based lookup, since the object
type and the query value don't have separate variables. This isn't in
keeping with draft-ietf-appsawg-uri-get-off-my-lawn-05 [2.3], since an
implementation might prefer to use query processing instead. Should
there be text in the document explaining why this is OK in this case?

-Tom

---

From: Naoki Kambe <[email-masked]>
Date: Tue, 24 Jun 2014 10:34:16 +0900 (JST)

Hello,

Here are my comments related to the JSON syntax.

From: Tom Harrison <[email-masked]>
Date: Tue, 24 Jun 2014 10:51:15 +1000

>           { "template": "{proto}://example.org/{resource}" } ]

Also I've found some errors by using JSONLint <http://jsonlint.com/>.
I've directly copied and pasted the examples from the draft.  Please
check this.

I think a JSON object should always start with '{' and end with '}'.
The examples on the draft seems to start with the string
"rdap.bootstrap".

And I'm not sure that an array-type key like the following can be
allowed to be used in JSON:

    "services": [
|   ["1.0.0.0/8", "192.0.0.0/8"]: {
       "template": "https://rir1.example.com/myrdap/{resource}",

I think some of RDAP clients might fail to parse such examples.

Regards,

Naoki Kambe

---

From: "John Levine" <[email-masked]>
Date: 24 Jun 2014 02:16:17 -0000

It's closer, but of course I have some suggestions to simplify and
improve it.

I note that the only two macros are {proto} and {resource}.  I propose
getting rid of both of them, for different reasons.

The problem with "proto" is that it doesn't do what it needs to do,
unless the only possible protos are http and https on default ports.
The "resource" as currently specified only makes sense at the end of
the template, so you might as well leave it out.

As others have noted, the tags in objects can only be strings, not
arrays, so make the list of tags and templates an array.

Change the template to remove the proto, and instead have an array of
URL prefixes.  Since the templates are now the only thing in the
object, they doesn't need to be wrapped in an object:

"domain": [
    [ ["wtf"], [
		"https://example.net/rdapwtf/",
		"http://example.net:8080/rdapwtf/",
		"ftp://[email-masked]/pub/file/rdapwtf/"
	       ]
    ],
    [ ["net", "com"], [
                "https://registry.example.com/myrdap/"
               ]
    ]
]

For ASNs, it's just cruel to store the numbers as strings.  Make them
either a single number or a two-element array for a range:

"asn": [
    [ [2045, [20116,20117]],
	[ "https://rir2.example.com/myrdap/" ]
    ],
    [ [[10000,12000], [65900,66000]],
        [  "https://example.org/",
	   "http://example.org/"
	]
    ],
    [ [[65512,65534]], 
        [ "http://example.net/rdaprir2/",
          "https://example.net/rdaprir2/"
	]
    ]
]

I understand that the point of making the key-like bit an array is to
make the bootstrap smaller for the relatively common case that a
single provider handles multiple keys, but it's not obvious to me that
the added complexity is worth it, compared to having one name-like
thing (domain name, CIDR, or ASN range) and a template, and just expand out
the duplicates.

I concur with the note that providing prefixes rather than full
templates may make the URL lawn police unhappy, but we seem to have a
clear consensus that the syntax in rdap-query meets the needs of any
plausible RDAP server.

R's,
John

---

From: Andy Newton <[email-masked]>
Date: Tue, 24 Jun 2014 14:35:46 +0000

> there be text in the document explaining why this is OK in this case?

Perhaps the draft should say the template is “https://registry.example.com/myrdap/{resource}” and that {resource} is substituted for a.b.example.com.

But I think what is being proposed does allow for query use instead of path use, and the object type is implicit in the bootstrap registry type. For domains, the DNR could submit {proto}://example.com/blahblah?domain={resource} just as easily as {proto}://example.com/blahblah/{resource}.

BTW, if we are to stick with the proto array, we should really rename it. In URI/URL speak, it is “scheme” not protocol.

-andy

---

From: Andy Newton <[email-masked]>
Date: Tue, 24 Jun 2014 14:47:36 +0000

>                "https://registry.example.com/myrdap/"

Requiring the use of default ports does seem odd. So I think an array of URLs is a better solution. However, I think it would be better as an object with two properties, “secure” and “non-secure”:

{
  “secure”: “https://example.com:4443/slslsls/{resource}”,
  “non-secure”: “https://example.com:8080/slslsl/{resource}”
}

> either a single number or a two-element array for a range:

I agree with this.

> thing (domain name, CIDR, or ASN range) and a template, and just expand out

I don’t think it is added complexity, and keeping it smaller does improve performance. For my client there is a noticeable difference between parsing the ASN registry vs the NET or domain registry because the ASN registry is much, much longer because it has lots of little allocations.

> clear consensus that the syntax in rdap-query meets the needs of any

Do we really want to keep fighting this battle? I think parsing a URL template and only substituting {resource} for the object lookup key is doable even without a full-blown URL template library.

-andy

---

From: Andy Newton <[email-masked]>
Date: Tue, 24 Jun 2014 14:51:54 +0000

On Jun 23, 2014, at 8:59 AM, Marc Blanchet <[email-masked]<mailto:[email-masked]>> wrote:

Hello,

Section 3 should probably have text stating that any unknown/unspecified JSON object properties or values should be ignored by implementers. This makes future expansion of the registry easier.

And given that, I think the “version” property should indicate the format version and not the publication version. To indicate the date of publication, it would make more sense to use “publication” or something like that.

-andy

---

From: "John Levine" <[email-masked]>
Date: 24 Jun 2014 16:11:34 -0000

>implicit in the bootstrap registry type. For domains, the DNR could submit
>{proto}://example.com/blahblah?domain={resource} just as easily as
>{proto}://example.com/blahblah/{resource}.

Except that in rdap-query, some of the resources are paths and some
are queries: 

   .../rdap/domain/example.wtf
   .../domains?name=example*

If we're forced to be fully lawn-compatible, the stuff in the
bootstrap has to be the URL of the template, and we accept a 100%
query overhead since every query has to be preceded by a template
fetch.  (The templates can often be cached, but that assumes you're
using a client with a persistent cache.)  Or else we bloat up the
bootstrap with separate patterns for every query type which would make
it an order of magnitude bigger and a nightmare to maintain.

I'm reasonably sure I heard Mark say that URL prefixes (remember when
we added /.well-known ?) are adequate to satisfy the lawn concerns,
since they avoid globally reserved URL segments.  Let's just say
they're prefixes and leave it at that.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 24 Jun 2014 16:16:47 -0000

>However, I think it would be better as an object with two properties, “secure” and “non-secure”:
>
>{

My example was intended to say try these in order until you find one
that works.  In your case, I am concerned about semantic overload.
What does this mean?

{
  "secure": "http://example.com:80/slslsls/{resource}",
  "non-secure": "https://example.com:443/slslsl/{resource}"
}

(Or to put it another way, if people want https, they presumably know how to spell it.)

>> make the bootstrap smaller ...

>I don’t think it is added complexity, and keeping it smaller does improve performance. For my client there
>is a noticeable difference between parsing the ASN registry vs the NET or domain registry because the ASN
>registry is much, much longer because it has lots of little allocations.

Egad, actual data?  If it makes a real difference, then never mind, that's fine.

R's,
John

---

From: Andy Newton <[email-masked]>
Date: Tue, 24 Jun 2014 16:27:08 +0000

> it an order of magnitude bigger and a nightmare to maintain.

Can you explain this further? Why wouldn’t the bootstrap just contain the URL templates? Why do we need a fetch of the template?

> they're prefixes and leave it at that.

My understanding is that ANY structure defined by the working group in the URL is forbidden by the lawn mowers.

-andy

---

From: Andy Newton <[email-masked]>
Date: Tue, 24 Jun 2014 16:27:08 +0000

On Jun 24, 2014, at 12:16 PM, John Levine <[email-masked]> wrote:

>> However, I think it would be better as an object with two properties, �secure� and �non-secure�:
>> 
>> {
>> �secure�: �https://example.com:4443/slslsls/{resource}�,
>> �non-secure�: �https://example.com:8080/slslsl/{resource}�
>> }
> 

Fair enough. Your way works for me too then.

-andy

---

From: "John Levine" <[email-masked]>
Date: 24 Jun 2014 17:28:26 -0000

>Can you explain this further? Why wouldn’t the bootstrap just contain the URL templates? Why do we need a

I count six lookup types and about six searches in rdap-query.  As I
understand it, if we're doing templates, that's 12 URL templates per
bootstrap entry.

>My understanding is that ANY structure defined by the working group in the URL is forbidden by the lawn mowers.

That can't be right.  They were OK with /.well-known/rdap/whatever.

R's,
John

---

From: Andrew Newton <[email-masked]>
Date: Tue, 24 Jun 2014 14:40:18 -0300

> understand it, if we're doing templates, that's 12 URL templates per

Yes, but only domain, ip address, and as lookup are applicable to bootstrapping.

> That can't be right.  They were OK with /.well-known/rdap/whatever.

Because .well-known is an acceptable vice in their particular religion.

-andy