From Daniel.Karrenberg at ripe.net Wed Sep 1 10:54:31 1993 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 01 Sep 1993 10:54:31 +0200 Subject: Authorisation and Notification of Changes Message-ID: <9309010854.AA23540@ncc.ripe.net> Folks, here is my long promised writeup on the "notify" and "maintainer" attributes. I hope it is clear enough. It will be discussed at the next RIPE meeting. Hopefully no substantive changes will be necessary. Suggestions on how to improve clarity are always welcome of course. Daniel Authorisation and Notification of Changes in the RIPE Database Daniel Karrenberg RIPE NCC ABSTRACT Two new attributes for all objects in the RIPE database are proposed in order to implement a generalised method for authorising changes and to notify interested parties of any changes made to a specific object. In addition the authorisation method provides a convenient way for distributed maintenance of the database. The Notify Attribute Each RIPE database object will have an optional attribute called notify. The value of the notify attribute is one valid RFC822 e-mail address. There can be multiple notify attributes. Whenever the object concerned is changed in the database a notification message will be sent to each e-mail addresses appearing in a notify attribute. This makes it straightforward to keep track of changes to specific objects and prevent changes from going unnoticed. Multiple notify attributes make it possible to notify a number of interested parties. This could be used to alert all contact persons for an object or the local contact per- sons as well as the relevant service provider. Although it may be tempting to put many notify attributes on database objects in order to notify everyone even remotely interested, this is not recommended. A very few key addresses should be sufficient. Prior to entering any mail address here, the explicit or implicit consent of the person responsible for that particular mailbox needs to be obtained. - 2 - The Maintainer Attribute Each RIPE database object will have an optional attribute called maintainer. The value of the maintainer attribute is a registered maintainer name. There can only be one main- tainer attribute per object. Whenever a change to the object concerned is attempted in a copy of the database the maintainer attribute of the current database object is examined. If there is no maintainer attribute or the maintainer name is authorised to make changes in the copy of the database the update proceeds causing the necessary notifications as per the notify attribute. If the maintainer name has no authorisation to change the local copy of the database, the update request is forwarded to the maintainer for processing. No notifications are per- formed in this case. The following data needs to be maintained locally about each maintainer: Maintainer name Authority none change whole database change only own objects Forwarding Info mail/RFC822-address other/address Authorisation none mail/RFC-822-address other/key Application 1: Regional Registries In order to align the InterNIC and RIPE databases it has been agreed that European objects will be maintained in Europe. The RIPE NCC will provide the data for these objects to the InterNIC for inclusion in their database without further processing. The RIPE NCC will refer all updates for non-European objects to the InternNIC and the InterNIC will refer all updates for European objects to the RIPE NCC for processing. This can be achieved by creating two maintainer names: - 3 - INTERNIC and RIPE-NCC and tagging all European objects with RIPE-NCC and vice versa. The tags can be phased in slowly, avoiding a flag day with the associated massive consistency problems. Over time all objects in the RIPE database would be thus tagged. Updates from third parties for objects with the maintainer attribute added can now be referred correctly. Updates from the other registry for objects it maintains can be accepted without further checking. Example 2: Local Registries Some European local registries keep their own copies of the database containing the objects within their area. This leads to consistency problems as updates can be sent both to the RIPE NCC and to the local registry. Referrals are per- formed by ad hoc methods. Frequently only one of the data- bases is updated and alignment needs to be done manually. By registering maintainer names for the local registries and tagging the appropriate objects this can be automated and made more reliable. The NCC would forward update requests for locally maintained objects to the local registry unless they come from that local registry itself. Example 3: Guarded Objects Some objects such as the autonomous-system object (see ripe-81) need to be protected against changes by anyone but a designated guardian since changes to these objects have a direct operational impact. By registering appropriate maintainer names for the guardi- ans and tagging the objects to be protected this functional- ity can be provided in a canonical way. Any change by third parties to such an object will not only be prevented but cause automatic notification of the guardian through the forwarding mechanism. From Piet.Beertema at EU.net Wed Sep 1 11:39:55 1993 From: Piet.Beertema at EU.net (Piet.Beertema at EU.net) Date: Wed, 01 Sep 1993 11:39:55 +0200 Subject: Authorisation and Notification of Changes In-Reply-To: Your message of Wed, 01 Sep 1993 10:54:31 +0200 . <9309010854.AA23540@ncc.ripe.net> Message-ID: <9309010939.AA20407@mcsun.EU.net> Example 2: Local Registries Some European local registries keep their own copies of the database containing the objects within their area. Reality is slightly different from "keeping own copies of the database": European local registries maintain their own database of registrations within their area. Selected fields of this database are sent on an ad-hoc or regular basis to RIPE to be included in the RIPE whois database. The selected fields may be subject to further processing before being sent to RIPE. Piet From woeber at cc.univie.ac.at Wed Sep 1 12:25:31 1993 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 01 Sep 1993 12:25:31 +0200 Subject: doc update for the (new) RIPE DB-Software Message-ID: <00971E4B.8C90F640.1813@cc.univie.ac.at> Dear DB-interested folks, according to action 15.11 on me from the 15th RIPE meeting, and as the beta test phase for the new DB-Software is making good progress, we have to agree on the structure, contents and production of new or updated documentation as well. Thus I ask all of you to contribute to this discussion on the DB-WG list. A copy of this is also sent to the Local-IR list FYI, however I propose to have the real discussion going on on th DB-WG list. Amongst other things, I think we should agree on - what is the intended audience for the doc? - what is a good structure? - who should contribute and how/when do we produce the paper(s) Regards, Wilfried. ------------------------------------------------------------------------------- Wilfried Woeber : Wilfried.Woeber at CC.UniVie.ac.at (Internet) Computer Center - ACOnet : Z00WWR01 at 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 ------------------------------------------------------------------------------- From graca at uminho.pt Wed Sep 1 15:23:35 1993 From: graca at uminho.pt (graca at uminho.pt) Date: Wed, 01 Sep 93 14:23:35 +0100 Subject: doc update for the (new) RIPE DB-Software In-Reply-To: Your message of "Wed, 01 Sep 93 12:25:31 +0200." <00971E4B.8C90F640.1813@cc.univie.ac.at> Message-ID: <9309011218.AA24165@ncc.ripe.net> Dear all, Here are some thoughts about what Wilfred wrote: > Amongst other things, I think we should agree on > > - what is the intended audience for the doc? I think that there are two different groups: . general public, who uses the whois service to consult the DB, and . local registries and all entities that have local copies of the RIPE DB, and use the software supplied by RIPE (or a different version of it). > - what is a good structure? About the contents: . to the general public: what can the service provide to commum users? which are the new objects available? This would be an updated version of the already existent leaflet about the whois service supported by the RIPE. . to the second group: a detailed document decribing all the objects available and theirs sintaxe. a document describing how the new software is supposed to work and a brief description of each existent module. how to install the new software. which are the new facilities and/or characteristics available. > - who should contribute and how/when do we produce the paper(s) Who should produce it: . no dought that the most important person is the person or persons who wrote it, they are the ones who know all these things. . the beta sites that are testing the software can give an important input. . everybody who uses the software can help accomplishig this task. If I can help with something, please let me know. I think that this documentation is needed and can help a lot. Regards, Graca. ---------------------------------------------------------------- Maria da Graca Carvalho graca at uminho.pt Rede da Comunidade Cientifica Nacional graca at rccn.net RCCN/FCCN Tel: +351 53 604475 Portugal Fax: +351 53 612954 ---------------------------------------------------------------- From woeber at cc.univie.ac.at Fri Sep 3 19:54:23 1993 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 03 Sep 1993 19:54:23 +0200 Subject: misleading use of the connect: field in inetnum: object Message-ID: <0097201C.9649C860.2195@cc.univie.ac.at> 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 at CC.UniVie.ac.at (Internet) Computer Center - ACOnet : Z00WWR01 at 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 ------------------------------------------------------------------------------- From Havard.Eidnes at runit.sintef.no Mon Sep 6 18:27:12 1993 From: Havard.Eidnes at runit.sintef.no (Havard Eidnes) Date: Mon, 06 Sep 1993 18:27:12 +0200 Subject: misleading use of the connect: field in inetnum: object In-Reply-To: Your message of "Fri, 03 Sep 1993 19:54:23 +0200." <0097201C.9649C860.2195@cc.univie.ac.at> Message-ID: <9309061627.AA13394@spurv.runit.sintef.no> 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 From Marten.Terpstra at ripe.net Tue Sep 7 17:50:20 1993 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Tue, 07 Sep 1993 17:50:20 +0200 Subject: ** URGENT ** New database software at the NCC Message-ID: <9309071550.AA09450@ncc.ripe.net> Dear people, You have all probably heard that new RIPE database software has been written at the NCC. We are convinced that this software should be used as soon as possible at the NCC, because the current update procedure has had several changes made already to keep it running with the current size of both the database and the amount of updates we receive. Therefore, we have planned to start using the new software at the NCC this Friday September 10th, at 10 AM. The new software has some consequences for whois users and people that send in updates. These consequences have been listed below. Please read the document below carefully. If you have any questions or major objections, please contact me, Daniel or Tony. Cheers, Marten PS All updates sent to the new mail alias before Friday 10 AM will either bounce, or update some test database. These updates will NOT be incorporated in the real RIPE database. ----- Introduction The software for the RIPE database has recently been completely rewritten, and the new implementation will have some effects on the behaviour of the database software as compared to the software currently in use at the NCC. This document describes the impact the new RIPE database software will have on usage of the database and on updates to it. USER IMPACT With the new database software, there will be some changes in the bahaviour of the database whois server. These include: New -s flag The indexed database will still contain information from various sources. As before normally only the RIPE information will be shown. The flag for requesting information from all sources remains the same (-a), and a new flag will be introduced to specify one or more specific source (-s source). The RIPE whois client available from the RIPE document store has been modified to accept this flag. Recursive Lookups Limited to Source of Reference The "-a" flag, or asking for information from multiple sources will show a slightly different behaviour. The old software used to perform recursive lookups on ALL the selected sources. This means that a contact person referenced by a NIC entry would be looked ap and listed from ALL other sources. The new software will ONLY perform recursive lookups in the source where the reference was found. Consequence is that one does not get a mix and match of referenced information from various sources. All references are ONLY looked up in the source where they are referenced. This was done to limit output volume and user confusion. Strict Enforcement of Object Definitions The current database file has objects in it that do not conform to the official object definitions. The new whois server will only output the legal fields for such an object. So, it may be that a network object contains a zone-c attribute in the database file, but the whois server will never show this attribute, because it is not in the network object definition. An overview of the defined attributes per object can be found at the end of this document. UPDATE IMPACT There are a number of changes that will affect people sending in updates for the RIPE database. Real Time Updates The new database software works with on-the-fly updates. This means that accepted and acknowledged database updates will be visible immediately in the whois server running at the NCC. These changes will not be visible immediately in the FTPable database file maintained via the RIPE Document Store. Once a day -or night rather- an automatic "cleanup" procedure will run which generates the FTPable file and adds all the guarded attributes as specified in the guardian files maintained at the NCC. This means that the database available for anonymous FTP does not necessarily have the same information as the running database. Guarded attributes will not be changed using the normal update procedure, they will be added once a day, and remain unchanged until the next cleanup time. New Update Procedure A new mailbox will be installed for direct access to the new database software without RIPE NCC staff intervention. This means fast response times, but since the updates are not looked at by the staff, updates containing errors will be bounced just as fast. The new mailbox will be . The old mailboxes will remain, and the NCC staff will look at mails directed to one of these mailboxes and forward updates to the new update procedure, after some very basic checking. The NCC will NOT correct all syntax errors in updates sent to one of these mailboxes, but it might correct some obvious errors. As before all updates and acknowledgements will be logged at the NCC. This means that errors and "strange" updates can be tracked quite easily. Stronger Syntax Checking The syntax checking in the new software has been improved and strengthened. As with the old software, database objects that cause errors will be bounced, and NOT be incorporated in the database. Warning messages are usually used to indicate corrections that have been made to the object sent in. Objects with warnings WILL be incorporated in the database, with the changes made as indicated in the warning messages. In general error and warning messages are descriptive and will give some indication where an error or warning was generated. The new syntax checking has the following rules: Database objects that miss mandatory attributes will generate an error, and will be bounced. An overview of the defined attributes per object can be found at the end of this document. Objects that have attributes that are not defined in the object, will generate an error and will be bounced. Objects that have syntax errors in the values of the various attributes will generate an error, and will be bounced. Objects that have a date in the changed field that is prior to the date in the current database entry will generate an error and will be bounced. Guarded attributes in updates will be ignored other than generating a warning if the values do not match the current value in the database. Currently only the boundary gateway and routing privilege in the network object are guarded attributes. The aut-sys attribute in the network object will be turned into a guarded attribute as soon as possible. Deletions have been made more easy to perform. To delete an object, it is sufficient to send in that object plus a delete: attribute that describes why this object has to be removed from the database. Objects that need to be deleted, will NOT be checked for syntax, but must exactly match the object currently in the database, otherwise an error will be generated, and the object will not be removed from the database. The order of the different attributes in the updates is NO LONGER relevant for the match. The order of different lines in the same attribute is. The new syntax rules have been determined from the original object definitions. It may well be that some syntax rules have been made too strict, or are simply wrong. Please do not hesitate to contact us in these cases. The syntax is not fixed forever. Attribute definition per object as used by the new database software. inetnum object Mandatory: inetnum netname descr country admin-c tech-c connect changed source Optional: aut-sys (will be guarded asap) gateway (obsolete) nsf-in nsf-out (obsolete ?) routpr-l (guarded) bdrygw-l (guarded) remarks rev-srv person object Mandatory: person address phone changed source Optional: e-mail fax-no nic-hdl remarks domain object Mandatory: domain descr admin-c tech-c zone-c changed source Optional: dom-net nserver sub-dom remarks aut-num object Mandatory: aut-num descr admin-c tech-c changed source Optional: guardian as-in as-out default remarks bdry-gw and rout-pr will be obsolete in the near future. From Daniel.Karrenberg at ripe.net Tue Sep 7 18:58:31 1993 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 07 Sep 1993 18:58:31 +0200 Subject: misleading use of the connect: field in inetnum: object In-Reply-To: Your message of Fri, 03 Sep 1993 19:54:23 MET. <0097201C.9649C860.2195@cc.univie.ac.at> Message-ID: <9309071658.AA10516@ncc.ripe.net> 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 From woeber at cc.univie.ac.at Tue Sep 7 19:20:40 1993 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 07 Sep 1993 19:20:40 +0200 Subject: misleading use of the connect: field in inetnum: object Message-ID: <0097233C.8A7F0860.2574@cc.univie.ac.at> Hi Daniel, >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. I had one and only one basic concern: when we put info into the DB, this info should HELP and not CONFUSE. I agree with you that "connect:" is maybe far from optimal. >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. 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. And the basic issue remains - you can just as well put some string into the "as-*:" fields and still have only EARN-E-Mail connectivity... >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! Definitely! And thanks for spending some minutes on it. Cheers, Wilfried. From Daniel.Karrenberg at ripe.net Tue Sep 7 22:06:19 1993 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 07 Sep 1993 22:06:19 +0200 Subject: misleading use of the connect: field in inetnum: object In-Reply-To: Your message of Tue, 07 Sep 1993 19:20:40 MET. <0097233C.8A7F0860.2574@cc.univie.ac.at> Message-ID: <9309072006.AA10865@ncc.ripe.net> > "Wilfried Woeber, UniVie/ACOnet" writes: > I had one and only one basic concern: when we put info into the DB, > this info should HELP and not CONFUSE. Fully agree. That is hard to do with the current connect field. > 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, RIP > E > 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. In the future we will provide tools (PRIDE project) which can actually answer the question "Is there supposed to be connectivity from here to there?" which is the question you are concerned about. The crucial point for these tools to be able to work is a well populated routing registry. That is why I would like to spend efforts on this rather than on fixing old kludges. In the long run (and even in the short run) this will be much more useful. > And the basic issue remains - you can > just as well put some string into the "as-*:" fields and still have only > EARN-E-Mail connectivity... No you can't because that is a guarded field and maintained by the service provider represented by that AS. It is not maintained by the people maintaining the network entry. If they have no service provider they will have no information there. VERY different from connect. > Definitely! > And thanks for spending some minutes on it. My pleasure and my job! Daniel From Havard.Eidnes at runit.sintef.no Tue Sep 7 23:13:52 1993 From: Havard.Eidnes at runit.sintef.no (Havard Eidnes) Date: Tue, 07 Sep 1993 23:13:52 +0200 Subject: misleading use of the connect: field in inetnum: object In-Reply-To: Your message of "Tue, 07 Sep 1993 22:06:19 +0200." <9309072006.AA10865@ncc.ripe.net> Message-ID: <9309072113.AA02751@spurv.runit.sintef.no> > > 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. 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). Hope you don't get sick of my nagging :-), - Havard From Marten.Terpstra at ripe.net Wed Sep 8 11:28:09 1993 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Wed, 08 Sep 1993 11:28:09 +0200 Subject: ** URGENT ** New database software at the NCC In-Reply-To: Your message of Wed, 08 Sep 1993 08:58:51 -0000. <"relay1.pip.306:08.08.93.08.58.54"@pipex.net> Message-ID: <9309080928.AA12375@ncc.ripe.net> Tim.Goodwin at pipex.net writes * Marten, * * > A new mailbox will be installed for direct access to the new database * > software without RIPE NCC staff intervention. This means fast response * > times, but since the updates are not looked at by the staff, updates * > containing errors will be bounced just as fast. The new mailbox will be * > . The old mailboxes will remain, and the NCC staff * > will look at mails directed to one of these mailboxes and forward * > updates to the new update procedure, after some very basic checking. * > ... * * Should new assignments from class C blocks continue to go to * "assign", with just updates to existing objects to "auto-dbm"? Or can * everything go to "auto-dbm"? Actually this is a good question ;-) We sort of have not made arrangements for this. I have some idea how to implement the difference between ripe-dbm and assign in the new database software, and I have to see how fast I can get that in (not too difficult I would say). Until further notice (I hope I can get this done before Friday) please send new assignments still to assign, and use auto-dbm or ripe-dbm for all others. Just some explanation, the messages sent to assign are first checked to see if they are already in the database, and currently bounced back to the NCC if they are. I think what I will do is create something like auto-assign, which has the same "on-the-fly" features as auto-dbm, but will only ADD new objects, and bounce all objects that are already present. This would mean that also contact people that are already present will not be updated when sent to auto-assign. The idea behind the difference between assign and ripe-dbm is to avoid some typos (especially in the beginning there were loads of 192/193 typos, and I am sure we will get some more 193/194 typos) and to cater for forwarding new entries directly to the InterNIC in the exchange format. The last has not been done yet. -Marten From alex at kiae.su Wed Sep 8 11:20:09 1993 From: alex at kiae.su (alex at kiae.su) Date: Wed, 8 Sep 93 13:20:09 +0400 Subject: misleading use of the connect: field in inetnum: object References: <9309072006.AA10865@ncc.ripe.net> Message-ID: Sorry, but why don't use DNS to propogate RIPE data-base information (such as AS - NET - CUSTOMER information), for example by using some pseudo-domain? We are speaking about internal information system (domains, networks -> customer, rights) system because we are starting of working with additional services and many different servers have to know status of every user throuth it's domain name or network number. Rudnev Aleksey, postmaster at kiae.su, Relcom. > > 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, RIP > > E > > 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. > > In the future we will provide tools (PRIDE project) which can actually > answer the question "Is there supposed to be connectivity from here to > there?" which is the question you are concerned about. > > The crucial point for these tools to be able to work is a well populated > routing registry. That is why I would like to spend efforts on this > rather than on fixing old kludges. In the long run (and even in the > short run) this will be much more useful. > > > And the basic issue remains - you can > > just as well put some string into the "as-*:" fields and still have only > > EARN-E-Mail connectivity... > > No you can't because that is a guarded field and maintained by the > service provider represented by that AS. It is not maintained by the > people maintaining the network entry. If they have no service provider > they will have no information there. VERY different from connect. > > > Definitely! > > And thanks for spending some minutes on it. > > My pleasure and my job! > > Daniel > From woeber at cc.univie.ac.at Wed Sep 8 12:29:37 1993 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 08 Sep 1993 12:29:37 +0200 Subject: ** URGENT ** New database software at the NCC Message-ID: <009723CC.482FC5E0.2648@cc.univie.ac.at> Marten, >Just some explanation, the messages sent to assign are first checked to see >if they are already in the database, and currently bounced back to the NCC if >they are. I think what I will do is create something like auto-assign, which >has the same "on-the-fly" features as auto-dbm, but will only ADD new >objects, and bounce all objects that are already present. This would mean >that also contact people that are already present will not be updated when >sent to auto-assign. ...does this mean that we are no longer able to submit *updates* for person objects along with a new network object from the 193,194 address range? If this is the case, then I think we should generally go for a system where *all* objects *with the exception of objects for newly assigned networks* should go to the ripe-dbm mailbox. Wilfried. From Tony.Bates at ripe.net Wed Sep 8 21:23:11 1993 From: Tony.Bates at ripe.net (Tony Bates) Date: Wed, 08 Sep 1993 21:23:11 +0200 Subject: misleading use of the connect: field in inetnum: object In-Reply-To: Your message of Tue, 07 Sep 1993 23:13:52 MET. <9309072113.AA02751@spurv.runit.sintef.no> Message-ID: <9309081923.AA13950@ncc.ripe.net> Havard Eidnes 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 From Marten.Terpstra at ripe.net Thu Sep 9 14:51:50 1993 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Thu, 09 Sep 1993 14:51:50 +0200 Subject: assign versus dbm in the new software Message-ID: <9309091251.AA16039@ncc.ripe.net> People, I have put the difference between assign and dbm in the new automatic aliases as well. We now have: auto-dbm - similar to ripe-dbm, but automatic auto-assign - similar to assign, ie network objects that are already present wil be bounced, persons can be updated though. This to allow for tech-c and admin-c that need to be updated with these network numbers to simply go through. deletes are accepted either way, but preferably though auto-dbm. The software also supports the LONGACK string in the subject line of the mail which indicates that you wish verbose output, ie at least a one line status per object. Objects with warnings or errors will always be returned. It seems we are almost ready for the cutover tomorrow. Be prepared for fast and different looking acknowledgements ;-) -Marten PS It may happen that tomorrow some of the additional features of a database update (such as the split version for anonymous ftp, the WAIS index, and the cisco access-lists) might be a bit later. We have to track all the stuff we currently have installed that has to do with the database, and transform them. Almost the full staff will be in on the weekend (RIPE preparation) to look after things in case it breaks (no of course it doesn;t) From Daniel.Karrenberg at ripe.net Mon Sep 13 12:20:05 1993 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 13 Sep 1993 12:20:05 +0200 Subject: No subject Message-ID: <9309131020.AA23677@ncc.ripe.net> Dear all, The closed local-IR workshop on Wednesday 15th September will take place in room Z009 (round the corner from the main auditorium), starting at 10.00 am. The proposed agenda is as follows: A G E N D A Local-IR Workshop September 15th, 10am. 1. Procedures at the RIPE NCC The NCC will describe how registry actions are being done at the RIPE NCC. 3. Procedrues at Local Registries Local Registries will describe how they do things. 2. Criteria for allocations: rfc1466 Short review of RFC1466. 3. Review and discussion of past "interesting" cases (ncc) 4. Review and discussion of past "interesting" cases (Local-ir's) See you there Daniel From Daniel.Karrenberg at ripe.net Mon Sep 13 15:43:46 1993 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 13 Sep 1993 15:43:46 +0200 Subject: Draft Agenda local-ir WG Message-ID: <9309131343.AA24292@ncc.ripe.net> Draft Agenda for the local IR WG During RIPE Meeting Thursday September 16th 1993 0. Reports for Information - short reports of significant events at local IRs - short reports of significant events at the NCC - short report from local IR workshop the previous day 1. Proxy Network Entries in RIPE Database Some service providers have expressed the wish to act as proxy for some of their clients when registering in the RIPE database in order to protect their clients privacy. Under the present policy this is not possible. A proxy policy could be established. Is this a goo idea? Proposed points: - only on explicit request from client - only if proxy has 24x7 NOC - proxy must reveal client's identity to Internet Registries - proxy must reveal identity on request of other network operator in case of ongoing problems OR take immediate measures to stop traffic 2. Autonomous Systems Database Template Has been circulated. Should be accepted as this. 3. Should we maintain a list of local IRs and publish it? Speaks for itself 4. Input for new NCC activity plan. What do you really want? and pay for it! 5. AoB Daniel From mnorris at dalkey.hea.ie Tue Sep 14 15:18:42 1993 From: mnorris at dalkey.hea.ie (Mike Norris) Date: Tue, 14 Sep 1993 14:18:42 +0100 Subject: Tomorrow's BOF Message-ID: <9309141318.AA26219@dalkey.hea.ie> Daniel et al I can't get out of here today so I'll be a bit late at tomorrow's IR bof; should be there in time for the concluding coffee, though ;-) I don't have any war stories as such, just a few things that occur to me: 1. Most clients are beginning to learn about subnetting and are using single Class C addresses for multiple link IP addresses. 2. Some clients complained that they had not been allocated enough addresses. Such clients are always those who have done nothing about getting themselves connected, despite the advice and encouragement we have offered them. Our answer to them is that when they really need more addresses to connect hosts to the Internet, they should ask their local registry. They can't complain. 3. The service provided by the RIPE NCC as the European IP registry is an excellent one. The secondary nameservice for the reverse zones in 193.1.0.0 was a great idea and well implemented. Cheers. Mike From rv at deins.Informatik.Uni-Dortmund.DE Wed Sep 15 19:40:41 1993 From: rv at deins.Informatik.Uni-Dortmund.DE (Ruediger Volk) Date: Wed, 15 Sep 1993 19:40:41 +0200 Subject: action item RIPE 15.3 Message-ID: <26981.748114841@deins.Informatik.Uni-Dortmund.DE> Hi, this is the wording as promised (for input to the local IR session) in the RIPE plenary today. Please find below proposed text, followed by some more remarks. (BTW the other day I got a request to expand the allocation for a certain federal German bureaucrazy and told them on the phone "first document current use" - and they asked for a written request/explanation why they should send that information...) Wording for action item RIPE 15.3 (the intension was: make applicants aware that their use of assigned adress space may be inspected, in particular when requesting additional allocations) When additional network numbers are needed by an organization the application sould include information on the utilization of address space already held by the same organization. This information needs to include the numbers of actually used/unused IP network numbers, and the numbers of actually used adresses, and installed subnets; more structural information may be apropriate to substantiate the new request. This data for previously assigned network numbers provides essential input for global monitoring of utilization of IP address space and feedback to registry operation. ----------- This text could be inserted into the explanation of the IP application template, and used in messages reporting allocations to applicants. When introducing the notion of "assigning additional address space" into the application document set it might be useful to also add hints that explain: The goal of the evaluation is to - ensure proper use is made of the available address space (i.e. high utiliziation) - have single contiguous blocks of addresses assigned if possible and apropriate (so routing information can be aggregated) For this a good estimate of real network requirements is needed and planning not just for the immediate needs or a specific parts of a network is encouraged. One further comment: When future policies should foresee auditing the use of assigned numbers for the purpose of reclaiming unused or underutilized space, the wording could/should be adjusted to mention eventual calls for usage reports. Cheers, Ruediger Ruediger Volk Universitaet Dortmund, Informatik IRB DE-NIC D-44221 Dortmund, Germany E-Mail: rv at Informatik.Uni-Dortmund.DE Phone: +49 231 755 4760 Fax: +49 231 755 2386 From Daniel.Karrenberg at ripe.net Tue Sep 21 13:21:41 1993 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 21 Sep 1993 13:21:41 +0200 Subject: Local-IR Draft Minutes Message-ID: <9309211121.AA09694@ncc.ripe.net> Thanks to Martijn we have prepared the draft minutes of the WG meeting last week. Please read and comment. The final minutes will be produced next monday. Daniel ------ Minutes of the Meeting of the local-ir working group at the 16th RIPE meeting. Date: September 16th 1993 Location: NIKHEF Amsterdam Chairman: Daniel Karrenberg Minutes: Anne Lord, Daniel Karrenberg, Martijn Roos Lindgreen The proposed agenda (see below) was accepted after extra points were added: - - discuss documentation that is needed - - discuss the procedure to set up new top level domains 0. Reports for information: The DE-NIC will be shut down and moved to another place at the 15th of December. It will be funded by all the DE service providers. A workshop was held on wednesday morning. As it was a closed meeting no minutes were taken. The workshop was considered useful and will be held in conjunction with a RIPE meeting on a yearly basis. A more extensive reporting was asked for, but was considered inappropriate because of the informal nature of the workshop. 1. Proxy network entries: Many participants felt that the network proxy entries should be avoided. After intensive discussion it was decided that a draft policy for this will be worked out by Duncan Rogerson and Daniel Karrenberg. Input from those service providers who are in favor of the proxy entries is necessary. 2. Autonomous Systems Database Template The AS Database template was formally accepted. 3. Should we maintain a list of local IRs and publish it? After intensive discussion it was decided that a list of Internet Registries will be maintained and published by the RIPE NCC. This list will be sorted by country and contain all local provider- and non-provider registries. A draft of the list will be circulated on the local-ir list by the NCC. 4. Input for the Activity Plan It was suggested to add the following activity: Maintain and regularly publish the list of local Internet registries Another suggestion is to strengthen the local registry liaison with tutorials and workshops. 5. AoB It was felt that more documentation is needed. The following volunteers were appointed to edit the documents: FAQ on CIDR and subnetting: GARR/NIS Why return unused IP address space and be a good network citizen: Daniel Karrenberg The problem of finding registrars for new toplevel domains was raised; there was consensus that the RIPE NCC shall offer to serve as temporary registrar for toplevel domains in our region, until about a dozen subdomains have been registered. Agenda for the local IR WG During RIPE Meeting Thursday September 16th 1993 0. Reports for Information - short reports of significant events at local IRs - short reports of significant events at the NCC - short report from local IR workshop the previous day 1. Proxy Network Entries in RIPE Database Some service providers have expressed the wish to act as proxy for some of their clients when registering in the RIPE database in order to protect their clients privacy. Under the present policy this is not possible. A proxy policy could be established. Is this a goo idea? Proposed points: - only on explicit request from client - only if proxy has 24x7 NOC - proxy must reveal client's identity to Internet Registries - proxy must reveal identity on request of other network operator in case of ongoing problems OR take immediate measures to stop traffic 2. Autonomous Systems Database Template Has been circulated. Should be accepted as this. 3. Should we maintain a list of local IRs and publish it? Speaks for itself 4. Input for new NCC activity plan. What do you really want? and pay for it! 5. AoB From Daniel.Karrenberg at ripe.net Thu Sep 23 11:09:54 1993 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 23 Sep 1993 11:09:54 +0200 Subject: RIPE NCC Temporary Registrar Message-ID: <9309230909.AA15453@ncc.ripe.net> Dear Jon (and others), during last week's RIPE meeting the question of start up toplevel domains has been discussed in the local registry working group. The concern (spawned by the situation in Lebanon) is that when first starting it is difficult to find a registrar acceptable to the community within the country and this could delay things very much. The RIPE NCC was asked and accepted to offer a temporary TLD registry service for start up TLDs in and around Europe as necessary. The procedure would be to wait for about a dozen registrations and then have the registered organisations agree on a local registrar. I hereby offer this service whenever you may think it is appropriate. Please note that we still feel that having a local registrar accepted by the local community is much preferrable to an external registrar. This offer is intended only to speed up the creation and population of new TLDs where necessary and appropriate. Regards Daniel From postel at ISI.EDU Thu Sep 23 19:52:25 1993 From: postel at ISI.EDU (Jon Postel) Date: Thu, 23 Sep 1993 10:52:25 -0700 Subject: RIPE NCC Temporary Registrar Message-ID: <199309231752.AA28273@zephyr.isi.edu> Daniel: Hi. An interesting idea that may get us out a a few difucult situations, but i'd really like to keep this to a very few cases, and much prefer to use local registrar whenever possible. --jon. From Daniel.Karrenberg at ripe.net Fri Sep 24 13:18:26 1993 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 24 Sep 1993 13:18:26 +0200 Subject: action item RIPE 15.3 In-Reply-To: Your message of Wed, 15 Sep 1993 19:40:41 MET. <26981.748114841@deins.Informatik.Uni-Dortmund.DE> Message-ID: <9309241118.AA19580@ncc.ripe.net> > Ruediger Volk writes: > Hi, > > this is the wording as promised (for input to the local IR session) Thanks you Ruediger. We will incorporate it in the next version of the request form which is due out next week. Daniel From Daniel.Karrenberg at ripe.net Fri Sep 24 14:55:42 1993 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 24 Sep 1993 14:55:42 +0200 Subject: Guarded Objects are now better protected Message-ID: <9309241255.AA19855@ncc.ripe.net> Dear colleagues, A recent accident has caused us to protect the guarded objects in the database a little better before the maintainer attribute is fully implemented. Guarded objects can from now on only be updated thru the manual procedure which involves plausibility checking by NCC staff. The manual procedure uses the old mailbox ripe-dbm at ripe.net. Any updates for guarded objects sent to the auto-dbm at ripe.net mailbox will be refused with the error message: *ERROR*: guarded objects cannot be updated via automatic procedure If you get such an error, re-send the update to ripe-dbm. Once the maintainer attribute is implemented authorisation will be handled automatically. Daniel PS: We hope to have the update procedure for guarded *attributes* deployed next week. From Marten.Terpstra at ripe.net Mon Sep 27 11:57:54 1993 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Mon, 27 Sep 1993 11:57:54 +0100 Subject: Beta RIPE database software Message-ID: <9309271057.AA24970@ncc.ripe.net> folks, I have made a beta database distribution for you all, with the emphasis on BETA. I just packed all the sources and stuff together, documentation and manual pages have not been updated to include all the changes we made over the last weeks, so this is "as is". A "real" distribution will follow whenever I am back in November, or Daniel may make one before that. You can find it on: ncc.ripe.net:/dbase-beta/dbase-beta.tar.Z NOTE this is NOT on ftp.ripe.net. The directory dbase-beta is NOT readable, but the dist can be fetched anyway. Have fun, -Marten From Daniel.Karrenberg at ripe.net Mon Sep 27 12:08:49 1993 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 27 Sep 1993 12:08:49 +0100 Subject: Beta RIPE database software In-Reply-To: Your message of Mon, 27 Sep 1993 11:57:54 MET. <9309271057.AA24970@ncc.ripe.net> Message-ID: <9309271108.AA25285@ncc.ripe.net> Questions and comments on the database beta please to . From Daniel.Karrenberg at ripe.net Tue Sep 28 17:45:12 1993 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 28 Sep 1993 17:45:12 +0100 Subject: Database beta: Bug in enkeys.pl Message-ID: <9309281645.AA29191@ncc.ripe.net> Gabor Kiss found a bug in enkeys.pl. His fix is included below. It has been incorporated in the beta release. Future announcements like this will only be made to the list . Be sure to get on this list if you use the beta release. Daniel *** /tmp/T0a09361 Tue Sep 28 17:40:00 1993 --- enkeys.pl Tue Sep 28 17:17:28 1993 *************** *** 1,9 **** # enkeys - extract keys from entry # # $RCSfile: enkeys.pl,v $ ! # $Revision: 0.13 $ ! # $Author: marten $ ! # $Date: 1993/08/19 14:53:37 $ # require "misc.pl"; --- 1,9 ---- # enkeys - extract keys from entry # # $RCSfile: enkeys.pl,v $ ! # $Revision: 0.14 $ ! # $Author: dfk $ ! # $Date: 1993/09/28 16:16:57 $ # require "misc.pl"; *************** *** 39,45 **** $i = $#result; while ($i >= 0) { $result[$i] =~ tr/A-Z/a-z/; ! $result[$i] =~ tr/a-z0-9-,\.'\///cd; if (length($result[$i])<2) { splice(@result, "$i", 1); } --- 39,45 ---- $i = $#result; while ($i >= 0) { $result[$i] =~ tr/A-Z/a-z/; ! $result[$i] =~ tr/a-z0-9\-,\.'\///cd; if (length($result[$i])<2) { splice(@result, "$i", 1); }