misleading use of the connect: field in inetnum: object
Dear all, (and sorry for a possibly too wide distribution). We had some instances recently, where operations people were prompted by users to sort out connectivity problems to a given network that couldn't be reached. The most obvious thing to do is to look into the RIPE-DB, of course. The network(s) were registered, but further investigation revealed that the network(s) did not yet have full connectivity to the Internet. However the information in the connect: field of the network object contained strings like RIPE, NSF or EASI, but no indication about the more local situation. For the end-user, and most probably for a lot of operations people as well, it is definitely not obvious that the connect field is more or less just a (sometimes very misleading!) comment. Thus I propose to discuss and agree on a (RIPE) recommendation along the following lines, at least for registering new networks in the database: - The Local-IR registers the network with a (local/regional) network or service-provider string, but without using any misleading flags in the connect: field like RIPE, NSF, EASI... If -for whatever reason- commonly used strings are used, then the remarks: field should give a very clear indication about expected connection date(s) and service restrictions (like dial-up networks, e-mail only links...). - When the network is connected to a service provider to configure routing, (Reverse-)DNS, or services like e-mail, etc. the network should be tagged with a useful service-provider string. This "state" could and probably should be skipped for situations where full connectivity could be expected within a few days. Examples: ACONET or SURFNET for national academic networks, EUNET-DE for a EUnet connection, XLINK and the like Note: I'm not proposing to use the LOCAL tag, because this means that no connectivity to the outside world is wanted or intended at all! - Only after the point in time where there is really full connectivity, the usual strings like RIPE, NSF, etc. should be added to the connect: field, out-dated comments removed, DNS and AS-Number information added, and the like. In addition to that I propose to list the connect: strings in a kind of intuitive "local to global" sequence. Examples: "ACONET RIPE NSF" or "ARNES EMPB RIPE NSF" or "EUNET-XX RIPE" Thus we would end up with really useful information in the connect field, and maybe also with more complete database objects, because information is available for the second or last update phase that usually cannot be submitted when registering the network. Could I have your opinions and comments please? An example for a network in Western-Nowhere, that is connected to a regional net that gets connectivity throug ACOnet and EBONE would be: Phase-1 connect: WNWNET !while setting up the net !or eg. e-mail only conn Phase-2 connect: WNWNET ACONET RIPE !after adding... bdrygw-l: ACONET Phase-3 connect: WNWNET ACONET RIPE NSF !after registering NSF-conn. Wilfried. ------------------------------------------------------------------------------- Wilfried Woeber : Wilfried.Woeber@CC.UniVie.ac.at (Internet) Computer Center - ACOnet : Z00WWR01@AWIUNI11.BITNET (EARN) Vienna University : 29133::WOEBER (SPAN/HEPnet) Universitaetsstrasse 7 : Tel: +43 1 436111 355 A-1010 Vienna, Austria, Europe : Fax: +43 1 436111 170 NIC: WW144 -------------------------------------------------------------------------------
Hi, in response to Wilfried Woeber's message on misleading "connect" field tags, I can tell you a little about the practices I personally try to adhere to when first assigning a network and later when connectivity is applied for. When the network is assigned, I always submit the registration request with "connect: LOCAL". Later, when (and if) I apply for wider connectivity for the network, I (at the same time) send in another update, stating the applied-for connectivity (as a matter of fact, I have started using the RIPE "inetnum" form as the application itself, simply CC:'ing my next higher authority in the chain to gain whatever connectivity is desired). The use of "LOCAL" could be discussed -- in my case I interpret it as "local to a single AS", which may not be the original intent of the flag, but there's no UNINETT flag defined, so... As for tagging with service provider, I never use the "bdrygw-l" flag, I stick to the "aut-sys" flag instead (I thought the "bdrygw-l" flag was deprecated by now, and we'll soon have to tag with aut-sys anyway). At what moment the network receives the "aut-sys" flag varies -- sometimes from the beginning, sometimes later. I beleive this is sensible practice, no? I'm not sure if these (or similar) practices have been documented, but if not, I agree, it should probably be stated somewhere. (But then again, keeping the database in sync with reality is really the duty of the people submitting information to the database, which should go without saying...) - Havard
Wilfried and others, the real problem with the "connect" attribute is that it still is the badly defined kludge it has been from the start. I can say so because I invented it. Today we have a well defined and agreed way of specifying the information you want: It is called ripe-81 by the document fans and "The Routing Registry" by afficionados. In my opinion we should put our efforts in getting the RR populated rather than trying to specify how to use an un-specifyable kludge. The original plan was to keep connect alive with the only legal value of LOCAL. Maybe we shouldn't even do this. An item for discussion at the RIPE meeting! Daniel
participants (3)
-
Daniel Karrenberg -
Havard Eidnes -
Wilfried Woeber, UniVie/ACOnet