Transition Draft Comments

Marten,

  I didn't copy the list on my message because I thought most of my
comments were superficial.  But your answers weren't superficial, so
I've added the list.

---------------------------------------------------------------------------
> From marten at ripe.net Wed Sep 14 15:53:07 1994
> To: "Dale S. Johnson" <dsj at merit.edu>
> Cc: Tony.Bates at ripe.net, daniel at ripe.net
> Subject: Re: Transition Draft Comments 
> From: Marten Terpstra <Marten.Terpstra at ripe.net>
> 
> 
>  *  More notes, this time on your excellent "Transition" draft:
> 
> Hi Dale, we appreciate your comments and suggestions. I am halfway
> through your previous comments, but let me start with this one.
> 
>  * p 10:  Automatically generating the aggregate representation of a block
>  * assumes that the user will use the aggregation you come up with.  This
>  * is more important than it might otherwise be because you state elsewhere
>  * that nothing should be routed without the exact route being registered
>  * in a route object.  If there are folks that are still announcing classfully,
>  * this will misrepresent their situation.
>  * 
>  * [Then again, maybe this is good "encouragement", and a better precdent
>  * that generating the classful route objects for them??  But maybe you
>  * need more transition planning then about getting the auto-generated
>  * aggregates into sync with what is really going on in the routing
>  * tables]
> 
> The reason why we do this is to bootstrap the amount of routes into
> the database. Perhaps we should be a bit more clear to say that after
> generation, they should check whether the routes generated are
> actually the routes they announce. I think we should indeed put some
> text in there.
> 
>  * Smaller Stuff:
>  * 
>  * p2:  Don't you want to declare an error where an aggregate prefix is 
>  * inconsistent with its length (rather than quietly truncating some
>  * bits?)
> 
> Not sure. We definately do for updates. I find it a bit harsh for
> queries. Proper documentation should take care of the "quiet
> truncation" I think. Perhaps a warning message that the message was
> truncated? I am not sure.
> 
>  * p4:  Getting back something other than what you requested by a whois query
>  * is probably usually ok, but you may want to support an "exact matches only,
>  * please" flag on whois.
> 
> You are right. This was also suggested by some people in the meeting
> yesterday. I will have to see in the code how easy/difficult this is
> to do. I think it should not be too hard.
> 
>  * Last sentence of p4;  also section 5.4:  The text about updating tools to
>  * use the new database seems to leave out one of the most important audiences:
>  * the masses of folks who are not writing tools but who have picked up old
>  * copies of tools and are just running them.
> 
> Very true. We should make a note of this in the document. We will make
> sure all our "ftp-able" tools will be up to "standard".
> 
>  * p4:  "Changes to tools that make use of the database server have to be
>  * made before that time."  ADD:  "All users of current versions of these
>  * tools need to replace their copies of the current tools with the new ones".
>  * You could have a similar section (5.5?) on page 16:  One set of tasks
>  * for people who are writing tools (e.g. adjusting to the new formats);
>  * another set of tasks for people who just use those tools.  Perhaps a task
>  * for someone of *identifying* the people who are using old versions.
>  * 
>  * On that idea:  If you move to a dbserver approach (can we offer you one?),
>  * how about "version" command that would automatically be issued by all
>  * tools to the server.  When the next incompatible round of tool changes
>  * comes up, the server could be set to tell the clients to print a message
>  * saying "This tool is obsolete because of XYZ change:  obtain a new copy
>  * of the tool from ftp..."
> 
> Yep. This was our idea as well. First implementation we would do is
> very basic; an option to ask the server what options it supports. That
> can be worked out to something what you describe. Dbserver is another
> thing I will have to look at.... The current database server also
> understand versions and types of clients, but is currently only used
> for logging purposes.
> 
>  * p 6:  Guarded Attributes:  see my overlong message about Communities.
>  * Guarded Attributes are *not* replaced by the new authentication.
> 
> Yes they are. I'll explain in more detail tomorrow morning when I
> reply to the other mail you sent. It was also clear from the meeting
> that esp that bit needs some different wording and better explanation.
> 
>  * 5.1.3: After B2:  "Change;  Guardian file mechanism is no longer needed
>  * and disabled".  I believe this is not true:  see my COMMunity memo.
> 
> Again, I will clear this up tomorrow.
> 
>  * ... "Align any locally stored objects with the split objects".  Dale does
>  * not know what "locally stored objects" means.  My ignorance?
> 
> "locally stored objects" are basically the files or databases or
> whatever people have on their own machine and use to update the RIPE
> database. Many people have a database server running for their own
> data, and use that data to update the RIPE data. We just want to make
> sure whenever we change something, they should do the same with the
> information they keep locally.

Ah, "copies of RIPE information that may be stored on local machines".

>  * 5.2 Local Registries  - Again, Dale doesn't know what "Local Registries"
>  * are.  Are these the "Mini-RIPEs?"  Will others be confused?
> 
> ;-) We should change this to Local Internet Registries. This should be
> a familiar term for all involved.

I'm afraid I'm still blinking.  The text under the title says "This is
the group who maintains 'inetnum' objects.  They will see the consequences
of the 'inetnum'/'route' split and will be able to use the new authorisation
scheme."  It sounds like this is "All NSPs who submit objects to the
RIPE database", though the phrase "Local Registries" (or even "Local
Internet Registries") sounds to me like they have to be running some kind
of software locally and probably making some kind of server access 
available.  

I suspect this may be something that is so common a usage at the RIPE
meeting that everyone knows what it means, but as someone who has never been
to one of those meetings it sounds like distributed places running
server software.

> 
>  * p15:
>  * 
>  * 5.2.2 "Now possible to store multiple "inetnum" objects covering the
>  * same address space at different levels".  Add: "though this should
>  * be extremely rare.  See the RIPE-81++ Section 5:  The Route
>  * Object."
> 
> No it is not rare. Better yet, it'll be very common. Probably not so
> much for routes, but definately for "inetnum:" objects. They contain
> *only* allocation information by then. As the section on "querying the
> database" says, we will insert into the database 193/8, 194/8, and
> 193.1/16, 193.2/16 etc to show the IP address delegation/assignment
> chain. All assigned 193 and 194 nets will appear at least 3 times in
> the database in different "inetnum:" objects. Again, this line says
> "inetnum" not "route".

Ah, I was thinking too much about the Route objects, and missed the fact
that it clearly says "inetnum".  

> 
>  * Question:  is it true that this ONLY happens in the case of Proxy
>  * Aggregation?  If so, that might be worth saying.  (Yes, I know, this
>  * was Merit's issue...)
> 
> For routes you can basically have multiple route entries as well.
> Routes originated from different AS's, more specific routes of a
> bigger aggregate being used (which can be very valid), routes that are
> in the registry but carry a "withdrawn" attribute, you name it. For
> routes it will be less likely, but not at all in rare or exceptional
> cases. 

Ah, you are right that there could be one active instance of a Route,
and one "withdrawn" registration for that route for every NSP that the
customer had jilted.  I hadn't thought of that.

I wonder if we have a fundamental nomenclature problem, though, about
what a route is?  I'm used to thinking of a route as the combination of
the dotted-quad and the mask, so that "193.0.0.0/8" and "193.0.0.0/24"
are different routes.  Under this definition, you would still only have
one active registration of a route at one time, except for the very
unusual case of two different providers doing the same proxy aggregation
simulatneously in different parts of the world (e.g. 193/8 being created
on export to North America, and simultaneously being created by someone
else on export to the Middle East).

This isn't important for this section of the text (which, as you point
out, is about Inetnums).

> 
>  * random thought:  If a Community guardian file specifies a Route (prefix/
>  * length) that is registered more than once, I guess that all instances of
>  * that Route are marked with the community name?
> 
> Again, as I will explain in more detail tomorrow (I'll first try and
> fix the text in the actual document up a bit to make it clearer) there
> will never be guardian files anymore with the new stuff. Maintainer
> and notification will handle it all. In the RIPE meeting, people could
> live with the fact that communities will not be as strictly guarded as
> they were, but will merely be "notified". Current community guardians
> thought this was good enough. And, with the introduction of netlists
> in policy expressions, you will need much less communities than
> before.

Ouch!  You aren't going to want to see my netlists embedded within policy
expressions if they are 40,000 nets long.  But I'll look forward to your
elaborations about communities.  Thanks for the extensive reply!  :-)

> 
>  * Nice paper;  nice design.
> 
> Thank you!
> 
> -Marten
> 

--Dale



-------- Logged at  Thu Sep 15 12:31:29 MET DST 1994  ---------