misleading use of the connect: field in inetnum: object

 Havard Eidnes <Havard.Eidnes at runit.sintef.no> writes:
  * >   > So now I've got another concern: populating the RR helps the
  * >   > "afficionados", but probably doesn't help the (end-)user in finding
  * >   > out what he/she can expect. I'd assume people are still thinking in
  * >   > terms of NORDUnet, NSF, RIPE and not in terms of ASxxx and ASyyy.
  * > 
  * > Of course you can look up what ASxxx and ASyyy are in the very same
  * > database.  And find NORDUnet, ACOnet etc.  Maybe we should include that
  * > info in the recursive lookup information?  It can only be one AS per net
  * > so it will not be too bad. 
  * 
  * But that will not give you the same functionality, and at an increase in
  * both "processing load" and "information load" for the user.  I agree that
  * the "connect" field is a kludge not usable for any automated use, but I
  * *do* find it useful as simply a commentary field indicating the intended
  * connectivity.  And as long as the NSFnet autonomous system is not in the
  * European routing registry (it isn't, right?), you will not be able to
  * represent the effect of "connect: NSF" with the routing registry.
  * 
  * If we were to use the method Daniel hints at to obtain the same (or
  * corresponding) information, you would have to trace the use of an
  * autonomous system number in all the "as-out" and "as-in" fields for the
  * autonomous systems between "here" and "there" to see if there is any
  * intended connectivity.  And since you have to have two-way traffic to
  * communicate, you'd have to trace back again (possibly looking at default
  * routes...)  I therefore conclude that calculating the equivalent of the
  * "connect" field dynamically on every "whois" lookup for a given network
  * will probably be too expensive (besides, "there" is not well-defined in
  * such a query...:-).
  * 
  * I also concur with Wilfried that people still think in terms of NORDUnet,
  * NSFnet, RIPE (?), EBONE, the GIX etc., and personally I see nothing wrong
  * with that.  So my personal opinion on the matter at hand is not to delete
  * the "connect" field altogether (or maim it to be essentialy useless by only
  * allowing LOCAL as a legal value (did I mis-quote that?)), but rather
  * redefine it to be "intended region-wise connectivity".  This could be done
  * by possibly dropping the RIPE and NORDU attributes (RIPE has no routers and
  * NORDU is more or less equivalent to EBONE these days, connectivity-wise,
  * and besides NORDUnet isn't a large enough region in these matters, IMHO)
  * and instead add EBONE, GIX (and possibly CIX?), and keep EU (?), NSF and of
  * course LOCAL.  Please note that this is expression of intent, but it should
  * of course be kept reasonably in sync with reality, eg. by following the
  * routine I do :-) as described in my previous message.
  * 
Well finally you find a comment in here form me ;-). Whilst I agree "to a
point" I do not see this really helps as much as you say. First, there is a
granularity issue of where you stop with "so-called" regions. Connectivity
(intended or otherwise) cannot be defind by anything else other than
routing interaction. Adding "name tags" to nets (which are not guarded) is
*not* an indication of connectivity (intended or otherwise). To the NSF
issue you can of course check (whether you are allowed rather than connected
with "-a" flag or whois -h prdb.merit.edu "net".

  * Also: please note that I fully support the work behind RIPE-81, the PRIDE
  * project and the population of the routing registry database.  However, the
  * "connect" field is hardly a substitute for any of that work (or vice versa)
  * .
  * 
Well - no it isn't but it is a "proof/result versus intention" issue. PRIDE will
give you the ability to extrapolate as you said above. In time to be truly
functional the routing registry (as with all registries) must have more
coverage than just the RIPE RR whether it be by comman exchange of RIPE-81
style objects or an agreed transfer syntax.

As an alternative. Why not just document the "intended connectivity" as
remarks and update accordingly.
  * 
  * Hope you don't get sick of my nagging :-),
  * 
Never and it's not nagging. I just remember from before how "undefined"
these connect: TAGS were and how difficult it is to use/decide on them
but perhaps I'm not seeing it straight either ?

  * - Havard

--Tony