Subject: [weirds] Comments on draft-ietf-weirds-bootstrap

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 15 Sep 2014 10:57:49 -0700

Hi,

I've reviewed this draft.  It's definitely on the right track and close to
being ready, but there are a few things that need to be reviewed
(especially Section 11) plus several editorial suggestions below.

1) In Section 1:

- add a space before "(RDAP)"
- s/request IANA/requests of IANA/
- s/extract/extracts/
- s/do a match/does a match/

2) In Section 3:

- s/version id identified/version identifier represented/
- s/defaults values/default values/
- s/Then the "services" element is/There exists a "services" element, which
is/

3) Also in Section 3, I would not be surprised if we were asked for ABNF
describing this.  I had to do this for RFC7071 as well, so you might find
Section 6.2 helpful.

4) Also in Section 3, rather than requiring that all base URLs end in "/",
couldn't the client just add one if it's missing in the bootstrap object?
I'm wondering why that MUST is needed.

5) Also in Section 3, the SHOULD about ordering suggests to me that we
ought to at least explain why the ordering is important.  Does that mean
clients are to try them in the order given, and we say SHOULD because HTTPS
is preferred?  Under what conditions might one legitimately deviate from
the SHOULD?  Would it not be better to simply have clients prefer secure
protocols over insecure ones, in which case ordering doesn't matter?  What
about the idea of using URLs randomly to spread load in the same way the
DNS returns randomized answers?

6) Also in Section 3, why do we MUST things into lowercase in the
registry?  Isn't it easier to require resolvers to treat them that way
(which DNS resolvers already do)?

7) In Section 4, isn't the matching not only longest and right-justified,
and ending at a label boundary?  That is, for a successful match, the
character right before the matching substring needs to be a dot as well, or
maybe even start-of-string.

8) Also in Section 4, I would say something about how b.example.com, if
present, would supersede the values found in example.com, when looking up
a.b.example.com.

9) Also in Section 4, suggest dropping "This example is not normative."
Same Sections 5.1, 5.2, and 5.3.  (Are examples ever normative?)

10) In Section 5, I'm a little puzzled by the use of "longest match".  I
think it's right, but we might want to add parenthetically that we're
actually looking to match the largest number of network bits.  Otherwise,
I'm a little fuzzy on what "longest" might mean because IP addresses are
all the same size (within the same family).

11) In Section 8, suggest the following changes:

- s/such as HTTP Expires/such as the HTTP Expires/
- delete "to be RDAP queried"
- s/no more current/no longer current/
- s/a RDAP aggregator/an RDAP aggregator/
- delete "This specification does not assume while not prohibiting how";
what's left is fine
- s/garantee/guarantee/
- s/rdap/RDAP/
- s/garanteed/guaranteed/

12) In Section 9, suggest deleting "for" from the beginning of each bullet.

13) In Section 10:

- s/helps making sure/helps to ensure/
- s/from authoritative source/from an authoritative source/
- s/The method itself/The method/

14) Section 11 still needs some work, as we discussed offline.  One of the
main things I believe it needs is to have each of the registries described
in its own subsection; in particular, each needs to have a name and
description given to the rows that would be needed to produce the JSON that
RDAP needs.  For example:

11.1.  IPv4 Address Space RDAP Registry

IANA is requested to create the IPv4 Address Space RDAP Registry.

Entries in this registry contain at least the following fields:

o A CIDR [reference to definition of CIDR] specification for the network
block being registered
o One or more URLs that provide RDAP service regarding this registration.
HTTPS URIs are to appear first in the list.  (Or if order doesn't really
matter to IANA, don't say that.)

[then copy the text about registry population that you already have]

[then copy the text about exporting it in JSON]

15) Also in Section 11, delete "such as XML" (two instances).

16) In Section 12, capitalize "WEIRDS".

-MSK

---

From: Tom Harrison <[email-masked]>
Date: Wed, 17 Sep 2014 08:51:42 +1000

> I'm wondering why that MUST is needed.

Speaking for myself, the previous text here was:

    Base RDAP URLs are likely to have a trailing "/" character because
    they are aggregated to the various segments defined in
    [I-D.ietf-weirds-rdap-query].

Without any other instruction, the obvious thing for a client to do in
the absence of the trailing "/" is append that "/", given the way in
which the segments are defined in rdap-query.  However, there is
nothing prohibiting a server operator from having a bootstrap base URL
like "https://registry.example.com/myrdap-", and resource paths like
"https://registry.example.com/myrdap-domain/example.com".  I was
interested to avoid any confusion on this point, hence the suggestion
for MUST.  If this were replaced with text that required the appending
of the "/" for bootstrap URLs that do not have it, that would work as
well.

> all the same size (within the same family).

Additionally, I think it would be worth clarifying what to do when
looking up a network range that is larger than any single range in the
registry, or that is split equally between multiple ranges in the
registry.  Treating these cases in the same way as "non-existent
entries" as per section 7 is probably the simplest approach.

-Tom

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 24 Sep 2014 13:30:52 -0400

> of the "/" for bootstrap URLs that do not have it, that would work as

So unless someone else speak, the text for this will remain as it is.

>> actually looking to match the largest number of network bits.

longest match is a very very well known concept within people using IP addresses. It is a basic concept of routing.  Moreover, there is some text about this in the draft already. So I'm not sure what you would like to see.

>>  Otherwise,

that is not the point at all. The prefix always come with a mask, which is the delimitation.  Again, there is text explaining what that means. Can you suggest alternative text?

> registry,

let me make sure I understand your point with an example based on my understanding of your text: a query is for 1.0.0.0/3  and that there is no 1.0.0.0/3 in the registry, but there is 2.0.0.0/3 and 1.0.0.0/4. Is this the use case you are trying to describe?

Marc.

> or that is split equally between multiple ranges in the
> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 24 Sep 2014 11:50:06 -0700

> So unless someone else speak, the text for this will remain as it is.

Tom makes a good point, so I'm satisfied.

> longest match is a very very well known concept within people using IP
> addresses. It is a basic concept of routing.  Moreover, there is some text
> about this in the draft already. So I'm not sure what you would like to see.
>

Someone who knows about domain names but not IP addresses might not know
what "longest match" means in that context.  I get that it's a term of art,
but that sometimes means it will leave some readers in the dark.

If I'm the only one worried about this, then just leave it.

> let me make sure I understand your point with an example based on my
> understanding of your text: a query is for 1.0.0.0/3  and that there is
> no 1.0.0.0/3 in the registry, but there is 2.0.0.0/3 and 1.0.0.0/4. Is
> this the use case you are trying to describe?
>

Assuming I understand Tom's point: If I ask for 128.0.0.0/1, do I get back
all v4 records where the most significant bit is set?

-MSK

---

From: Tom Harrison <[email-masked]>
Date: Wed, 24 Sep 2014 21:09:08 +0000

>> looking up a network range that is larger than any single range in
>> the registry,
>
> let me make sure I understand your point with an example based on
> my understanding of your text: a query is for 1.0.0.0/3  and that
> there is no 1.0.0.0/3 in the registry, but there is 2.0.0.0/3 and
> 1.0.0.0/4. Is this the use case you are trying to describe?

Yes, that's right.  It's not to do with the networks that a potential
RDAP server might return in response to a query, but merely with the 
selection of the RDAP server based on the bootstrap.

-Tom

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 24 Sep 2014 19:06:54 -0400

> selection of the RDAP server based on the bootstrap.

of course.

So in the example above, it is obvious (to me at least) that the client would parse the registry and find no match, therefore the registry does not have any rdap server for the prefix. Do you agree?  If yes, then I'm not sure what needs to be said in the draft.

Marc.

---

From: Tom Harrison <[email-masked]>
Date: Wed, 24 Sep 2014 23:58:16 +0000

>> Yes, that's right.  It's not to do with the networks that a 
>> potential RDAP server might return in response to a query, but
>> merely with the selection of the RDAP server based on the
>> bootstrap.
> 
> of course.
> 
> So in the example above, it is obvious (to me at least) that the 
> client would parse the registry and find no match, therefore the 
> registry does not have any rdap server for the prefix. Do you agree?
> If yes, then I'm not sure what needs to be said in the draft.

I agree, but I still think it's worth clarifying, given the explicit
routing analogy.  Finding references to "longest match" in the context
of routing is easy, but those are all about finding the longest match
for a single address, rather than a network, as far as I can tell.  
Additionally, section 5 has "the authoritative registration data
service is found by doing a longest match of the target *address*",
and "[t]he longest match is done the same way as for routing".  I 
think a reasonable implementor might, in the absence of a covering 
prefix, think it open e.g. to resolve to a server based on the first
address in the target network, or by using some other address or 
subnet from the target network.  In that sort of situation, they
really should be returning an error to the client.

-Tom

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 24 Sep 2014 20:01:48 -0400

> really should be returning an error to the client.

ok. I guess I'm too involved in routing and network operations. Would you mind providing some text suggestions?

Marc.

---

From: Tom Harrison <[email-masked]>
Date: Thu, 25 Sep 2014 01:32:29 +0000

> ok. I guess I'm too involved in routing and network operations. 
> Would you mind providing some text suggestions?

After the first paragraph in section 5 (the first and second 
paragraphs below are straight from the original text):

   For IP address space, the authoritative registration data service is
   found by doing a longest match of the target address with the values
   of the arrays in the corresponding Address Space RDAP Bootstrap
   registry.  The longest match is done the same way as for routing: the
   addresses are converted in binary form and then the binary strings
   are compared to find the longest match.  

   If the target is a network, rather than a single address, then the
   longest match is based on the network prefix components only.  If
   there is no single entry in the registry that covers the whole
   target network, clients SHOULD NOT default to resolving the query 
   by using a single address from, or a subnet of, the target network.

   The values contained in the second element of the array are the 
   base RDAP URLs as described in [I-D.ietf-weirds-rdap-query].  The
   longest match method enables covering prefixes of a larger address
   space pointing to one base RDAP URL while more specific prefixes
   within the covering prefix being served by another base RDAP URL.

-Tom

---

From: "John Levine" <[email-masked]>
Date: 25 Sep 2014 02:06:01 -0000

>> of routing is easy, ...

It's also a standard idea in text processing, regular expressions, and
the various automata that process them.

In this context, I'm having trouble imagining the mindset of someone who
would interpret "longest match" as anything other than, you know, the longest
match.

R's,
John

---

From: Andrew Newton <[email-masked]>
Date: Thu, 25 Sep 2014 09:42:39 -0400

>    within the covering prefix being served by another base RDAP URL.

Or in other words, where a NO MATCH in the other registries is not
easily subverted by adding bits because nothing there would be
reasonably meaningful, guessing at an IP address in a range to find a
match when there is no clear longest match is simply not acceptable. I
agree with this, though as an implementer it never once crossed my
mind to do something like that.

This text doesn't change anything, it just guards against a corner
case. So I think it should be added.

-andy