[Ietf-not43] I-D ACTION:draft-ietf-crisp-internet-resource-number-req-00.txt

[Eric A. Hall]

Answering for myself here.

on 8/19/2003 5:00 AM Shane Kerr wrote:

> For us (RIPE NCC), nested matching means:
> 
> - Given a range, find all the networks that contain that range; "-L" 
> in RIPE-land, or "all supernets" in your terminology

That's the default with FIRS' address-specific matching filter. Each
parent netblock is returned as they are encountered, until either an exact
match for the query value is found. If no exact match was found, the user
still gets to see all of the parent netblocks.

Issue a whois query to goose.ehsco.com with the value of 192.168.11.1 to
see this. There is no entry for the queried /32 address but the delegation
parents are returned.

> - Given a range, find only the most specific network that contains 
> that range (could be multiple networks, but usually single); "-l" in 
> RIPE-land, and the default for our servers, or "supernets" in your 
> terminology

There are two ways to do this with the FIRS approach. First way would be
to have the client filter the output, so that only the matching entry was
displayed, and all of the parent entries were discarded.

Less workable but still functional would be to have the client use an
equality match, but this would require the client to have prior knowledge
about which server was authoritative for the netblock in question.

> - Given a range, find all the networks that are fully within that 
> range; "-M" in RIPE-land, or "all subnets" in your terminology

This is kind of supported with the default matching filter, although its
possible to do more than this by defining another filter.

Right now, entries are encouraged to contain attribute values that itemize
the "related" netblocks, and the user could chase down any of those in
particular by issuing new queries for any of those entries. You can see
this in the output to 192.168.0.0/16 in the demonstration server, which
lists 192.168.11.0/24 and 192.168.12.0/24 as associated networks. The
client could issue new queries for either of these.

It would also be possible to define a separate filter that didn't stop at
the matching entry, although there are some fairly hard questions that
need to be answered first, given the distributed model. In a monolithis
model, you can do this because all of the data is contained within your
server, but its pretty nasty when the subordinate entries all refer to
other systems. I mean, if there are ~20 subordinate delegations, each of
which have referrals that point to different subordinate management bodies
and servers, should all of them be queried? How far down does this fan-out
need to go? I mean, should every /32 in every delegated subnet be pursued
with new queries? We're not in mono-ville anymore...

> - Given a range, find only the least specific networks that are fully 
> within that range; "-m" in RIPE-land, or "subnets" in your terminology

I don't understand this one.

> Exact matching means:
> 
> - Given a range, find the network that begins and ends on the same IP 
> addresses as the range; "-x" in RIPE-land

Ranges are heavily disfavored by me. Too weird.

> For us, a "less-specific" search can return a network that is an exact 
> match, as well as the encompassing networks:

That's the default for FIRS.

> However, a "more-specific" search must not be an exact match:
> 
> -M is networks where:
>    (start(network) >= start(search)) AND
>    (end(network) <= end(search)) AND
>    NOT ((start(network) = start(search)) AND
>         (end(network) = end(search)))

So all subordinate entries, but not the matching entry. Again, this
introduces all kinds of weirdness in a distributed system.

> -m is all of the networks from -M, with the provisio that:
>    no other network in the return set contains the network

> Any replacement for WHOIS would have to have at *least* this much 
> expressiveness.

I don't think expression is the problem so much as making sure that the
queries are reasonably efficient for the distributed environment.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/