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

From: Internet-Drafts at ietf.org ([email-masked])
Date: Mon Aug 11 12:31:21 2003

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF.

	Title		: Cross Registry Internet Service Protocol (CRISP) Internet Resource Number Requirements
	Author(s)	: V. Listman
	Filename	: draft-ietf-crisp-internet-resource-number-req-00.txt
	Pages		: 26
	Date		: 2003-8-10
	
Internet registries expose administrative and operational data via 
varying directory services.  This document defines functional 
requirements for the directory services of Internet resource number 
registries.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-crisp-internet-resource-number-req-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-crisp-internet-resource-number-req-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-crisp-internet-resource-number-req-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
-------------- next part --------------
Skipped content of type multipart/alternative

---

From: davidb at verisignlabs.com (David Blacka)
Date: Mon Aug 18 14:21:00 2003

Ginny,

I am a little confused by part of the requirements in your draft:

  3.2.2.1 Protocol Requirement

     The protocol MUST contain the following search functions:

     1. IPv4 address search given one or more contiguous IP address
        numbers. This search SHOULD allow for both exact matching and
        nested matching.

     2. IPv6 address search given one or more contiguous IP address
        numbers. This search SHOULD allow for both exact matching and
        nested matching.

These searches seem sort of vague to me.  Maybe it is a terminology 
problem.  When doing a IP address search, what are you looking for?  
Supernets or subnets?  All supernets or all subnets?  Is an "exact match" 
the closest enclosing supernet and a "nested match" all supernets?  
Wouldn't we want the ability to search for both supernets and subnets?

Also, I would sort of think that searching for network blocks (IPv4 or 
IPv6) would be one of the most basic points of the service, so should the 
ability to search for them be a SHOULD?

-- 
David Blacka    <[email-masked]> 
Sr. Engineer    Verisign Applied Research

---

From: shane at ripe.net (Shane Kerr)
Date: Tue Aug 19 06:00:10 2003

> Wouldn't we want the ability to search for both supernets and subnets?

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

- 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

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

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

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

More details:

-x is networks where:
   (start(network) = start(search)) AND
   (end(network) = end(search))

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

-L is networks where:
   (start(network) <= start(search)) AND
   (end(network) >= end(search))

-l is all of the networks from -L, with the provisio that:
   no other network in the return set is contained by the network

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)))

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

(Note that the definition is not the best way to find the answer.)

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

> ability to search for them be a SHOULD?

Agreed.

-- 
Shane Kerr
RIPE NCC

---

From: davidb at verisignlabs.com (David Blacka)
Date: Tue Aug 19 10:08:39 2003

On Tuesday 19 August 2003 06:00 am, Shane Kerr wrote:

Excellent response, Shane.  Thanks.  My comments are in-line.

> RIPE-land, and the default for our servers, or "supernets" in your 

I called this "the closest enclosing supernet", but your description is 
quite clear.

> within that range; "-m" in RIPE-land, or "subnets" in your terminology

Ok, is "least specific" the same thing as largest, in this context?  I 
guess I'm not sure how to define this search.

>    no other network in the return set contains the network

Sorry, couldn't parse that last sentence.  "no other network in the return 
set contains the network"? which network? huh?

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

I realize that this is currently what the RIPE WHOIS servers do, but are 
there specific reasons why some of these rules exist?  For instance, if 
the "more-specific" supernet search (-l) was able to return exact matches, 
would you even need (-x)?

> > ability to search for them be a SHOULD?

This information, in some form, needs to make it into the requirements 
document as MUSTs.  Or maybe some subset of these searches are MUSTs and 
some are SHOULDs.

---

From: shane at ripe.net (Shane Kerr)
Date: Wed Aug 20 12:42:08 2003

> guess I'm not sure how to define this search.

Well, it includes the largest networks.  For instance, given this query:

193.0.0.0 - 193.0.31.255

"least-specific" is:

193.0.0.0 - 193.0.7.255
193.0.8.0 - 193.0.11.255
193.0.14.0 - 193.0.14.255
  .
  .
  .

And so on.  Note that the networks here are a /21, a /22, and a /24.

It should not find:

193.0.0.0 - 193.0.3.255

Even though this is a /22, and larger than the /24 (if you count IP's 
in the range).  Size matters, but it's not the only thing.  ;)

You could say it is the "child networks" of the network, although that 
begs the question of what a child is in this context (the definition 
below is relatively formal and complete, IMHO).

> set contains the network"? which network? huh?

Maybe a diagram:

    X                                             Y 

A  |------------------|
B          |--------------------|
C                      |-------------------------|
D    |--------|
E                  |-------|
F                                    |---------|

Given these networks, if you searched with "-m" for "X - Y", you would 
get A, B, and C.  You would not get D (contained by A), E (contained 
by B) or F (contained by C).

Or look at some code:

@results = $db->selectall_arrayref(qq"
   SELECT lo_ip, hi_ip FROM networks
   WHERE (lo_ip <= $search_lo_ip) AND
         (hi_ip >= $search_ip_ip) AND
         NOT ((lo_ip == $search_lo_ip) AND hi_ip == $search_hi_ip))
   ");

for ($i=0; $i<@results; $i++) {
     for ($j=$i+1; $j<@results; $j++) {
         if (contains($results[j], $results[i])) {
             # remove network that is contained by the other
             splice(@results, $i, 1);
         }
     }
}

sub contains {
     my ($a, $b) = @_;
     return ($a->[0] <= $b->[0]) && ($a->[1] >= $b[1]) &&
            !(($a->[0] == $b->[0]) && ($a->[1] == $b->[1]));
}

> would you even need (-x)?

It's currently used in the RIPE database to do lookups (versus 
searches).  I guess there's no real need if we have intelligent 
clients, but it could reduce bandwidth consumption if nothing else in 
the case where you know what you are looking for.

Note that if you have -l return exact matches, then you MUST have a -L 
flag.  Otherwise you can't know who the parent of a given network is, 
except by trying both of these:

-l  (lo_ip-1) - hi_ip
-l  lo_ip - (hi_ip+1)

:)

>>>IPv6) would be one of the most basic points of the service, so should 
> 
> the 
> 

We absolutely cannot live without:

-l  (one level less specific)
-m  (one level more specific)

The client can do the -x checking on its side.

You can build -L (all less specific) and -M (all more specific) with 
these, although I don't know if it makes sense.  You'll also end up 
sending the same objects in some cases if you build them from the 
others, due to overlapping networks.  -L is a lightweight query (going 
up a tree doesn't give you much data), but -M can be very, very 
heavyweight (somebody does "-M 0.0.0.0/0" every day on our server).

So perhaps:

-l => MUST
-m => MUST
-L => SHOULD
-M => MAY
-x => SHOULD

I like -x because it's efficient.

Note that you can do more funky things, like "2nd level more specific" 
and so on.  I don't know if these are useful, especially if they can 
be constructed through use of the -l/-m operators.

-- 
Shane Kerr
RIPE NCC

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Wed Aug 20 18:34:46 2003

>>> - Given a range, find only the least specific networks that are
>>> fully within that range; "-m" in RIPE-land, or "subnets" in your
>>> terminology
>> 
>> Ok, is "least specific" the same thing as largest, in this context?
>> I guess I'm not sure how to define this search.
> 

[...]

I'm going to guess that David is having some of the same problems I had
when Ed Lewis was describing the same kind of syntax, which is that
specifying the range as the query value is just strange.

I'm not entirely sure if there isn't a disconnect here. For WHOIS queries
this kind of syntax is okay since the dumb-terminal client is talking to a
front-end parser that is part of a monolithic back-end. In distributed
models, however, the client is supposed to be the front-end parser that
maps the input to a canonical value and the server's role is reduced to
handling the database lookup. In that regard, having the client pass raw
input to the server negates the benefits of the model, and feels wrong.

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

---

From: shane at ripe.net (Shane Kerr)
Date: Thu Aug 21 04:09:25 2003

> specifying the range as the query value is just strange.

I would guess you think it's strange because you're a domain person.
;)

> input to the server negates the benefits of the model, and feels wrong.

Syntax is irrelevant:

<IPv4-query begin="193.0.0.0" end="193.0.31.255"/>

<inetnum>
   <first>3238002688</first>
   <last>3238010879</last>
</inetnum>

<NETBLOCK><IP VAL="193.0.0.0"/><BITS VAL="19"/></NETBLOCK>

Whatever.   (Textual IP's are easier when debugging, of course.)  I 
only use the syntax I did because that's what we use now.

But maybe that's not what you mean.  Is the problem specifying the 
range and doing a search rather than a simple lookup?  The address 
space is not the same as the domain space.  We actually need to be 
able to have the semantics that I described in terms of looking for 
parent/child relationships and having abritrary values for searches.
-- 
Shane Kerr
RIPE NCC

---

From: davidb at verisignlabs.com (David Blacka)
Date: Thu Aug 21 08:37:30 2003

> specifying the range as the query value is just strange.

Actually, no.  I don't find using IP ranges especially strange, since I 
know that they are the basic units of identity for a network block.  In 
this thread, my main concern is that the word "search" in the address 
space is hopelessly vague.  Shane has managed to express quite precisely 
what he (or RIPE) wants in an address-space WHOIS replacement.

In this particular case, I was having trouble understanding what the search 
parameters for RIPE's "-m" search were.  Shane's explanation was great.  
If I were to try and put it in English, I might say:

  All networks enclosed by this range that are not themselves enclosed by 
other networks in the result set.

Still pretty clumsy, I admit.

> input to the server negates the benefits of the model, and feels wrong.

I expect the real disconnect is that those of us outside this space don't 
really have a handle on the use cases that a WHOIS replacement would need 
to support.

---

From: davidb at verisignlabs.com (David Blacka)
Date: Thu Aug 21 08:48:10 2003

> parent/child relationships and having abritrary values for searches.

Shane, how important is it that *all* of those searches are done with 
arbitrary ranges?  In particular, I am wondering if the "-m" query, for 
instance, could be started with a known network block (identified by 
handle, for instance) instead of an arbitrary range?  It occurs to me that 
if "-m" where queries by network block handle, implementations could 
pre-calculate the results.

A followup question might be: would it be useful for any of the IP searches 
to start with a network block identifier, in addition?

---

From: shane at ripe.net (Shane Kerr)
Date: Thu Aug 21 09:31:33 2003

> pre-calculate the results.

These don't always match.  For instance, if I want to find all of the 
allocations from 210.0.0.0/7 I would probably have to do a search for 
210.0.0.0/8 and 211.0.0.0/8 if those were the entries in the database. 
It's not *strictly* necessary, but we don't really have performance 
problems so I'd prefer not to limit the protocol unnecessarily.

> to start with a network block identifier, in addition?

That's possibly useful.  Unfortunately we don't have (unique) identifiers 
for network blocks except for the start/end IP.

-- 
Shane Kerr
RIPE NCC

---

From: timc at arin.net (Tim Christensen)
Date: Thu Aug 21 09:37:00 2003

Hi, David-

> to start with a network block identifier, in addition?

Just as likely (maybe even more) that queries would be issued with either
the start of the block or the _network_block_identifier_, when the query
issuer is clueful regarding the network block in question.

e.g. if I were the responsible maintainer for the block, I would most
likely look up the block by either its starting point or by a unique
identifier to find out what information was registered about it.

I am not clued into RIPE '-m' and can't answer to that, but there are
(historically anyway) many :43 queries today (in the ARIN region) which
are looked up via the unique network block identifier or by the network's
start point.

(disclaimer: ARIN's :43 service does not support range queries at this
time, but supports 'wildcard' queries which, while not replicating the
behavior, can be crafted to simulate it is some cases. These account for a
very small percentage of total queries. 'Why' is left to speculation of
the reader.)

ARIN's most recent incarnation of :43 service permits the queryant (new
word?) to use flags to force a return of next-level-down subnets (though
not a cascading tree) or a next-level-up supernet when the query returns 1
network.  Important to note is that this is _not_ achievable with an IP
query alone in the current code -- a network block identifier must be
used.

I am (personal opinion here) in favor of a search which by default returns
the 'most close network'.  This can be painfully difficult to define, but
Shane's is the closest I have seen and I concur, with the caveat that most
of the time, queryants (there it is again!) *seem* to want to see _only_
the most-close network most of the time; so returning the
supernets/subnets about the range (or single IP for that matter, a range
of 1) would IMO be best served with flags.

Note that the current version of the draft does not address a network
block identifier beyond a range (which does not necessarily uniquely
define a network -- a network can be subdelegated in its entirety).  So
it is not a 'MUST' according to the existing document.  This _may_ hamper
certain uses of CRISP protocol in an implementation if said implementation
were to explicitly ignore the (IMO common) desire to get 1 network
response back for 1 query in many cases.

Tim

---

From: timc at arin.net (Tim Christensen)
Date: Thu Aug 21 09:46:00 2003

Hi Shane,

> problems so I'd prefer not to limit the protocol unnecessarily.

Agreed. The database is not always aggregated; to presume that a query
ought to _ONLY_ be dealt with on an aggregated basis is undesirable.

> for network blocks except for the start/end IP.

Which is not to say that it's not desirable to be able to uniquely
identify a network block (and indeed, when two networks match, which one
is the supernet and which one is the subnet).

While the query language might not NEED (read: MUST) to permit a unique
query to that level, for me it is a desired benefit of the protocol that
it allow such definition and a way to get to it.

Tim

---

From: shane at ripe.net (Shane Kerr)
Date: Thu Aug 21 10:01:47 2003

> is the supernet and which one is the subnet).

We do not allow this.  In fact, our schema is backwords.  Our begin/end IP 
are unique, but our network names are not.  :(

Don't blame me, I didn't design the schema.  ;)

> it allow such definition and a way to get to it.

It does make sense to allow lookup by handle for any record, IMHO.

-- 
Shane Kerr
RIPE NCC

---

From: anewton at ecotroph.net (Andrew Newton)
Date: Thu Aug 21 10:05:23 2003

> is the supernet and which one is the subnet).

How do you get two network blocks with the same starting and ending 
addresses?  And how do they have a relationship other than equivalence? 
  Or is there a temporal relationship?

-andy

---

From: anewton at ecotroph.net (Andrew Newton)
Date: Thu Aug 21 10:13:20 2003

>  Or is there a temporal relationship?

Ignore this.  You answered the question.

-andy

---

From: shane at ripe.net (Shane Kerr)
Date: Thu Aug 21 10:16:51 2003

>  Or is there a temporal relationship?

Say I have received a /17 and a /19 from ARIN, disjoint.  One of my 
customers is now big enough that they can use an entire /19.  I want to 
assign the entire block to them.  Therefore I create an entry in the 
database reflecting this.  We still have:

IANA -> ARIN -> ISP -> User

And want to reflect this relationship, but the block to the ISP and the 
User are the sam, in terms of start/end address.

-- 
Shane Kerr
RIPE NCC

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Thu Aug 21 10:35:36 2003

> parent/child relationships and having abritrary values for searches.

Using the netblock syntax would be the most efficient for the holistic
system, for several reasons. Using the range syntax would be the least
efficient.

For one thing, the "back-end" of the system actually consists of multiple
back-ends, each of which manage portions of the delegated hierarchy. This
is somewhat different from the existing model of independent systems. We
aren't going to be having clients query ~RIPE when the address falls into
a certain range, but instead the idea is that the client will start with
zero knowledge and rely on the distributed back-ends to redirect them to
the appropriate server.

The two choices for this are an index of all entries or a series of
delegation referrals. We've already chosen the delegation referral model
since the super-index approach has too many problems.

Now we need to think about how the database partitions and entries are
keyed so that the delegation hierarchy can be efficiently followed. Using
ranges as key values has a lot of problematic issues. It's certainly
possible to combine multiple attributes into an entry name, but it's not
very efficient. Furthermore, all delegations are required to be netblocks
that fall on CIDR boundaries, which is a single value, and is therefore
going to be highly efficient in terms of key-based referrals.

In terms of server processing, it helps a lot if the most-common query
uses these same values. Having the client issue a query for a range of
addresses would mean that the server would have to convert either the
query value or the database contents into a form that will match against
the other form.

Meanwhile, on the client side, preparing a single value is simpler than
preparing a range (need to do a lot more validation and preparation for
ranges), and since the server and namespace would both prefer the netblock
syntax (a single value) that is what it should be producing anyway.

So cumulatively, it is overall most efficient to use netblocks as the
primary naming syntax for navigation, searches and queries.

It's still entirely possible to search by other values, but in the
distributed back-end model we've got, value-based searches necessarily
have to be restrictred to specific servers, and cannot follow the
delegation hierarchy. For example, things like network handles can still
be supported (and there's an attribute in FIRS for this), and can still be
searched for, but the client either has to know which server has that data
and start the search there, or the client has to ask an index server and
hope that the index is up to date, is accurate, etc.

---

From: timc at arin.net (Tim Christensen)
Date: Thu Aug 21 11:18:35 2003

Comments inline but I left the entire thread here since there are several 
reference points. Sorry for length.

>system, for several reasons. Using the range syntax would be the least

Most efficient, yes, I agree. Not practical, unfortunately, see below.

<snip>
>Furthermore, all delegations are required to be netblocks

Not true. All delegations are _not_ required to be netblocks that fall on 
CIDR boundaries.

As it happens, not only can direct delegations be off-bit, but 
subdelegations also can (and frequently are).

ARIN made a choice at its last database redesign to store networks in CIDR 
chunks.  But that in no way infers that networks (as a discrete, defined, 
delegated resource) are necessarily constrained to exist on a tidy bit 
boundary.

>primary naming syntax for navigation, searches and queries.

IMO this unnecessarily limits the querying ability that the protocol 
supports.  To presume that someone would want to query only on CIDR bit 
boundaries is erroneous and ignores the fact that many network delegations 
span multiple cidr-espressed blocks.

While it's true that you _could_ choose to look at this another way -- to 
consider that a multi-cidr-block delegation is really just contiguous 
cidr-represented networks, and that in and of itself means that the 
(single-CIDR-addressable block) is unique -- I see 2 problems with this 
approach:

- seems to me that most folks want to know the size&shape of the delegated 
block
- it still doesn't address full-subdelegation of the cidr block (and 
indeed, creates an even larger problem in this area)

To exemplify, assume that we have a network delegation from 10.10.254.2 to 
10.10.254.254 (this is close to a real world example in ARIN's database, 
details modified somewhat).  It requires 13 CIDR blocks to represent this 
single network resource (resource from the perspective of a single 
allocation instance).  If I were to issue a query for 10.10.254.64, or even 
for the range 10.10.254.64 -> 10.10.254.240, I would want to know that this 
range is encompassed by the delegated network 10.10.254.2->254.  Using the 
'netblock' query model above does not permit the latter query (since itself 
is a multi-cidr range), and the further discussion seemed to preclude 
identification of the network as a single database entry (again not 
reflective of reality and undesirable IMO)

Tim

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Thu Aug 21 11:29:27 2003

Answering for myself here.

> 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.

> RIPE-land, and the default for our servers, or "supernets" in your 

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.

> 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...

> within that range; "-m" in RIPE-land, or "subnets" in your terminology

I don't understand this one.

> addresses as the range; "-x" in RIPE-land

Ranges are heavily disfavored by me. Too weird.

> match, as well as the encompassing networks:

That's the default for FIRS.

>         (end(network) = end(search)))

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

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

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

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Thu Aug 21 11:50:34 2003

>> Furthermore, all delegations are required to be netblocks that fall
>> on CIDR boundaries, which is a single value, and is therefore going
>> to be highly efficient in terms of key-based referrals.
> 
> Not true. All delegations are _not_ required to be netblocks that fall
> on CIDR boundaries.

I'm perfectly aware that organizations allocate addres space, where the
space may span multiple netblocks, but the components themselves are still
required to be netblocks right?

Also, my understanding is that the component netblocks are the discrete
entries, while the address space is just administrative. For example,
routing uses netblocks not the whole space.

> subdelegations also can (and frequently are).

These are space assignments, not the netblock delegations right?

>  boundaries is erroneous and ignores the fact that many network
> delegations span multiple cidr-espressed blocks.

There is no such presumption. The effort is to find an efficient means of
representation so that the hierarchical delegatin system actually works.
We can support additional representations but those are by definition
going to be search-by-value and thus limited to target servers.

Also, don't forget that we have the ASN namespace as a separate hierarchy.
Each of the partitions and entries in that hierarchy would naturally
reference administrative groups, any of which could also provide pointers
to discontiguous network blocks as associated resources.

> While it's true that you _could_ choose to look at this another way --
> to consider that a multi-cidr-block delegation is really just
> contiguous cidr-represented networks, and that in and of itself means
> that the (single-CIDR-addressable block) is unique -- I see 2 problems
> with this approach:
> 
> - seems to me that most folks want to know the size&shape of the
> delegated block - it still doesn't address full-subdelegation of the
> cidr block (and indeed, creates an even larger problem in this area)
> 
> To exemplify, assume that we have a network delegation from 10.10.254.2
> to 10.10.254.254 (this is close to a real world example in ARIN's
> database, details modified somewhat).  It requires 13 CIDR blocks to
> represent this single network resource (resource from the perspective
> of a single allocation instance).  If I were to issue a query for
> 10.10.254.64, or even for the range 10.10.254.64 -> 10.10.254.240, I
> would want to know that this range is encompassed by the delegated
> network 10.10.254.2->254.  Using the 'netblock' query model above does
> not permit the latter query (since itself is a multi-cidr range), and
> the further discussion seemed to preclude identification of the network
> as a single database entry (again not reflective of reality and
> undesirable IMO)

The example you cited is supported in the default (with FIRS anyway). Each
parent netblock in the delegation path would be returned as it was
encountered during the chase-down to the query value.

---

From: timc at arin.net (Tim Christensen)
Date: Thu Aug 21 13:58:46 2003

Hi Eric,

At 8/21/2003 11:50 AM, Eric A. Hall wrote:
> > All delegations are _not_ required to be netblocks that fall
> > on CIDR boundaries.
>

To the extent that even a /32 is a one-node netblock, yes, I suppose.

>routing uses netblocks not the whole space.

"Just administrative" might be an oversimplification, but yes.

>These are space assignments, not the netblock delegations right?

Terminology confusion on my part. When I read "delegation" I think "space 
that has been provided from an entity holding space to another 
entity".  The unit of provision is measured in nodes, and can be measured 
in CIDR-prefix-size(s).  When I read "assignment" it has special meaning to 
me about the use of the delegation, so I am confused.

If what you are meaning is "These are named aggregates-of-netblocks 
[CIDR-expressed blocks], not the [individual] netblocks themselves", I 
would agree with that.

>encountered during the chase-down to the query value.

Could you amplify your response further? Let me provide context.

In the example above of the range 10.10.254.2 to 10.10.254.254, the proper 
way to describe this 'network' in CIDR is:

10.10.254.2/31   +
10.10.254.4/30   +
10.10.254.8/29   +
10.10.254.16/28  +
10.10.254.32/27  +
10.10.254.64/26  +
10.10.254.128/26 +
10.10.254.192/27 +
10.10.254.224/28 +
10.10.254.240/29 +
10.10.254.248/30 +
10.10.254.252/31 +
10.10.254.254/32

Now, if I search for the range 10.10.254.64 -> 10.10.254.240, I am only 
hitting nodes in cidr-sections 6,7,8,9, and 10 in my list of 13....

My assertion is that the protocol should be defined such that it returns 
the network 10.10.254.2->254, because that was the closest aggregated 
network delegation.
It should _not_ only return the cidr blocks represented by cidr-sections 6 
thru 10 above, because that is an incomplete expression of the delegation 
that was delegated by the upstream.

Similarly, if I used a single-term query such as 10.10.254.64, it would 
still return the network 10.10.254.2->254, because that node is encompassed 
in that delegated network, and to return only 10.10.254.64/26 
mischaracterizes the delegation.

In the context above, what would FIRS return?  More to the point, what 
should the CRISP protocol call for $CRISP_IMPLEMENTATION demand?  I believe 
it's more 'correct' to return the entire 'delegation', not just its closest 
CIDR sub-component.

Moving on, how would I have queried the first search above in the following 

>> > <NETBLOCK><IP VAL="193.0.0.0"/><BITS VAL="19"/></NETBLOCK>

The first 2 are intuitive but the last, I struggle with.  Would it be
<netblock><IP VAL="10.10.254.64"/><BITS VAL="26"/><IP 
VAL="10.10.254.128"/><BITS VAL="26"/>...<IP VAL="10.10.254.240"/><BITS 
VAL="32"/></netblock>?

Ew, that's cumbersome. And requires the queryant to have 
better-than-average clue about how to express networks in CIDR notation.

Expressing a range as a range (and not in CIDR notation) is far preferable, 
IMO.

Tim

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Thu Aug 21 23:29:47 2003

> [CIDR-expressed blocks], not the [individual] netblocks themselves", I 

Yeah, that's what I mean.

>>> To exemplify, assume that we have a network delegation from 
>>> 10.10.254.2 to 10.10.254.254 (this is close to a real world example
>>>  in ARIN's database, details modified somewhat).  It requires 13 
>>> CIDR blocks to represent this single network resource (resource 
>>> from the perspective of a single allocation instance).  If I were 
>>> to issue a query for 10.10.254.64, or even for the range 
>>> 10.10.254.64 -> 10.10.254.240, I would want to know that this range
>>>  is encompassed by the delegated network 10.10.254.2->254.  Using 
>>> the 'netblock' query model above does not permit the latter query 
>>> (since itself is a multi-cidr range), and the further discussion 
>>> seemed to preclude identification of the network as a single 
>>> database entry (again not reflective of reality and undesirable 
>>> IMO)
>> 
>> The example you cited is supported in the default (with FIRS anyway).
>>  Each parent netblock in the delegation path would be returned as it 
>> was encountered during the chase-down to the query value.
> 
> In the example above of the range 10.10.254.2 to 10.10.254.254, the 
> proper way to describe this 'network' in CIDR is:
> 
> 10.10.254.2/31   + 10.10.254.4/30   + 10.10.254.8/29   + 
> 10.10.254.16/28  + 10.10.254.32/27  + 10.10.254.64/26  + 
> 10.10.254.128/26 + 10.10.254.192/27 + 10.10.254.224/28 + 
> 10.10.254.240/29 + 10.10.254.248/30 + 10.10.254.252/31 + 
> 10.10.254.254/32
> 
> My assertion is that the protocol should be defined such that it 
> returns the network 10.10.254.2->254, because that was the closest 
> aggregated network delegation. It should _not_ only return the cidr 
> blocks represented by cidr-sections 6 thru 10 above, because that is an
>  incomplete expression of the delegation that was delegated by the 
> upstream.
> 
>  still return the network 10.10.254.2->254, because that node is 
> encompassed in that delegated network, and to return only 
> 10.10.254.64/26 mischaracterizes the delegation.

Okay I see what you're seeing, and this is different than what I thought
you were saying earlier.

> In the context above, what would FIRS return?

The inetIpvNetworkMatch query doesn't match against entries that exceed a
netblock so if you gave it 10.10.254.64 it would find the 10.10.254.64/26
entry and none of the siblings. It would find any parent netblocks that
had been created (eg 10.10.254.0/24), but since your example uses an
administrative grouping and not a netblock delegation, the matching entry
is the only one that would be returned in a fully-distributed query.

Note that the sibling entries could be returned as attribute values which
identified the other netblocks. You could also do a targetted search
against the server for the administratively grouped data. But in the
default distributed query (where the client has zero knowledge apart from
an input address), the associated entries wouldn't be located in the
distributed system using the "normal" query syntax.

As a demonstration of this, I've added the entries to goose.ehsco.com.
Point a whois client to that and issue a query for 10.10.254.64/26 (or any
address within that specific netblock), and you'll get back that entry
alone, but the data contains pointers to all of the siblings, which you
can requery for through the same interface. You can point an LDAP client
to that same server and issue a query with the searchbase of
cn=inetResources,dc=ntrg,dc=com and with the assertion value of
(&(objectclass=inetIpv4Network)(inetPrivateIdentifier=TC-NET-00)) to find
all of the netblocks associated with "TC-NET-00" private identifier.

Although it would be possible to automate such a query, it's important to
point out again that identifiers like "TC-NET-00" don't have any hierarchy
in their naming, so they cannot be used as seed values for searches
against distributed partititions. Unless the RIRs want to setup a branch
of governance to allocate identifiers (which you hopefully don't want),
that won't ever work.

> More to the point, what should the CRISP protocol call for
> $CRISP_IMPLEMENTATION demand?  I believe it's more 'correct' to return
> the entire 'delegation', not just its closest CIDR sub-component.

Return all 13 detailed entries or just a pointer to the siblings? If the
latter then that's working now. It could probably stand to be cleaned up
some -- there need to be explicit sibling, parent and child attributes to
fully present what's registered, rather than relying on a generic
"associated" attribute -- but the latter part more or less works now.

> Moving on, how would I have queried the first search above in the 
> following [strawman] query models (from earlier in the thread):
> 
>>>> <inetnum> <first>3238002688</first> <last>3238010879</last> 
>>>> </inetnum>
>>>> 

In FIRS, it's just a single unit of "10.10.254.64/26".

> better-than-average clue about how to express networks in CIDR 

Don't get UI stuff confused with this. It's possible to represent a
netblock by any number of mechanisms. The firs.pl demonstration client
(the one listening on goose:43) will take an address without a prefix and
take an educated guess at the appropriate network, for example. It also
handles the various hex/octal notations.

Its not hard to imagine another client having two fields:

  start: [___.___.___.___]

    end: [___.___.___.___]

and then try to figure out what the user wants.

The format of the vallue in the protocol message is what's important, not
the data-entry format.

> Expressing a range as a range (and not in CIDR notation) is far 
> preferable, IMO.

That format also assumes that the queryant knows what the full
administrative assignment looks like.