March 1999 - db-wg - mailman.ripe.net

<auto-dbm@ripe.net> is slow this afternoon.
by RIPE Database Administration 17 May '18

17 May '18

Dear Colleagues, Because of a very high level of use this afternoon, the response time of <auto-dbm(a)ripe.net> is longer than normal. I have made contact with those who are responsible and I expect the situation to improve as the machine works through the queue. Please be patient. Obviously we at the RIPE NCC Database Group are continuously working to make the performance of the database as good as possible. However, we cannot make improvements in zero time. We thank you for your co-operation up to now and we ask for your continued co-operation so that everyone receives the best possible service. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

2 2

Re: Modifications to the inet6num in the RIPE Database
by Wilfried Woeber, UniVie/ACOnet 18 Mar '99

18 Mar '99

Guy, Engin, thanks a lot for the explanation! Guy said: >Finally, you can only have one of these constructs per address. This is >common sense really since, if you have 3ffe::aaaa::bbbb, you cannot tell >how many zeroes are replaced with the first pair of colons and how many >by the second. There is no convention (AFAIK) for which block would be >written out in full. Personally, since I am lazy, I choose to write out >the fewer number of zeroes (remembering that I only need one zero per >block of 4 hex digits). > >So, some examples of IPv6 addresses are... > >3ffe:1100:0:c00::/52 >= Note the :0: because there is a :: later in the address Engin added: >The algorithm we use translates "5:0:0:78:0:0:0:0" >into "5:0:0:78::" but not "5::78:0:0:0:0". Of course, >both are legal, but we choose to double-colonize the >last group of zeros, and all prefixes are normalized >according to this and then put into the registry. which already gives us two compatible but different ways to deal with that, and >But I don't know what 6bone registry does. interesting, indeed. Taking this one step further, and looking back at what we did with IPv4, where it would be feasible to say 131.130/16, implying 131.130.0.0/16, I wonder if it wouldn't again be worthwhile to restrict the use of these shorthand notations in the Address Registry? Is there a danger for braking something by _not_ allowing the "::" construct in the registry at all, or - in particular - not _in the middle_ of a prefix? Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 --------------------------------------------------------------------------

6 6

Re: Modifications to the inet6num in the RIPE Database
by Wilfried Woeber, UniVie/ACOnet 16 Mar '99

16 Mar '99

Hi David, Joao, et.al. <disclaimer> My question is going to prove complete ignorance when it comes to IPv6 address formats. So please bear with me :-) </disclaimer> => The two suggested changes are: => => - - addition of a "status" attribute with the following possible values: => TLA, NLA and SLA. => Syntax checks will be done so that: => TLA is only allowed if the prefix length is 3<x<=16 => NLA is only allowed if the prefix length is 16<x<=48 => SLA is only allowed if the prefix length is 48<x<=64 = =This is fine although, I am not entirely convinced that we really need =it. It's a bit redundant information. By definition something is a =TLA/NLA/SLA so you can just look at the 'inet6num:' field and you =already know what it is. Can't you just generate this field =automatically ?!? For the IPv4 case we do have a well-established format for external representation of addresses and prefixes, i.e. full dotted quad with /prefix-length. In the 6bone registry there's IPv6 prefixes with a "structured" external representation, like "3FFE::/16" or "5FBC:1000::/32". So my questioon is: is there an agreed algorithm to insert punctuation at the "appropriate" positions, and does the proposal/criticism for the semantic checks do have an influence on this formatting? Thanks, Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 --------------------------------------------------------------------------

4 3

Modifications to the inet6num in the RIPE Database
by Joao Luis Silva Damas 15 Mar '99

15 Mar '99

Dear all, A week has passed and no comments against the proposed modifications to the IPv6 object have been put forward. Therefore we take it that everyone is happy with it and will procede with the implementation. We expect this to be available in about two weeks. The original message is repeated below for your reference. Regards, Joao Damas DB Group RIPE NCC ------- Begin Original Message From: Joao Luis Silva Damas <joao(a)ripe.net> Date: Thu, 04 Mar 1999 10:20:17 +0100 To: lir-wg(a)ripe.net, db-wg(a)ripe.net Subject: Modifications to the inet6num in the RIPE Database Dear all, below are the proposed modifications to the inet6num object in the RIPE Database as discussed during the past RIPE Meeting. These are mainly to bring the IPv6 object up to the IPv4 object's functionality. The two suggested changes are: - - addition of a "status" attribute with the following possible values: TLA, NLA and SLA. Syntax checks will be done so that: TLA is only allowed if the prefix length is 3<x<=16 NLA is only allowed if the prefix length is 16<x<=48 SLA is only allowed if the prefix length is 48<x<=64 - - addition of "mnt-lower" capabilities, as in the IPv4 object. We would like to open a comment period of 1 week from today to gather input and proceed with implementation if there is consensus. Regards, Joao Damas DB Group RIPE NCC ------- End Original Message

2 1

Annoing lists.:(
by Irmantas Gudelis 15 Mar '99

15 Mar '99

[ Moderator note: changed local-ir(a)ripe.net -> db-wg(a)ripe.net ] Is it good that everybody is using addreses from ripe database for sennding such a stuipid and annoing messages? The problem is that it is happening more frequently. Maybe anybody has solved the problem how to filter messages like that ..? ---------- Forwarded message ---------- Return-Path: <JCh7649460(a)aol.com> Delivered-To: irmis(a)isi.kvm.lt Received: (qmail 11358 invoked from network); 5 Mar 1999 15:09:08 -0000 Received: from lex.balt.net (root(a)195.14.162.1) by isi.kvm.lt with SMTP; 5 Mar 1999 15:09:08 -0000 Received: from imo13.mx.aol.com (imo13.mx.aol.com [198.81.17.3]) by lex.balt.net (8.9.1a/8.9.0) with ESMTP id QAA01908 for <registry(a)balt.net>; Fri, 5 Mar 1999 16:00:27 -0100 From: JCh7649460(a)aol.com Received: from JCh7649460(a)aol.com by imo13.mx.aol.com (IMOv19.3) id aTOYa22613; Fri, 5 Mar 1999 09:15:15 -0500 (EST) Message-ID: <3afff544.36dfe6f3(a)aol.com> Date: Fri, 5 Mar 1999 09:15:15 EST Mime-Version: 1.0 Subject: Profit From The Internet Growth-Explosion 800 607-6006 Ex 2492 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 3.0 for Windows 95 sub 76 This is a 1 time mailing Fire the Boss and break the Alarm Clock! I did! after eleven years, I left a $140,000 a year income for this opportunity I can truly say it was one of the best decisions of my life!!! Never commute again! make $2000-$5000 per week from home with a turn key marketing system! To find out how our system works call the 800#. You can start out in your spare time, work part time or work up to full time if you want to! It's your business! Call 1-800 607-6006 ex 2492# then press 1 no selling! stay home with the family! Proven track record of success! 1 800-607-6006 ex 2492# call now! Profit From The Internet Growth-Explosion 800 607-6006 Ex 2492 Thank You

2 2

Re: Modifications to the inet6num in the RIPE Database
by Simon Leinen 15 Mar '99

15 Mar '99

Joao, sorry for the late comment, but I have a small issue with the following: > Syntax checks will be done so that: > TLA is only allowed if the prefix length is 3<x<=16 > NLA is only allowed if the prefix length is 16<x<=48 I think the separation between TLA and NLA space is not that clear. There are eight reserved bits between the TLA field and the NLA field (see section 2.5.7 of RFC 2373 and section 3.1 of RFC 2374). By introducing the checks as you proposed, you seem to have decided that those should be part of the NLA field. I don't think this is warranted. Section 3.2 of RFC 2374 makes it clear that some of the reserved bits might also be used to extend the TLA field in the future. You should permit either both TLAs and NLAs, or neither of them for prefix lengths between 16 and 24. I suggest rejecting such prefixes for the moment, and keep in mind that the reserved bits may be added to the TLA and/or NLA over time. If I missed some change in the intended structure of IPv6 unicast addresses, please apologize. Regards, -- Simon Leinen simon(a)switch.ch SWITCH http://www.switch.ch/ Who is General Failure & why's he reading my disk?

2 1

Modifications to the inet6num in the RIPE Database
by Joao Luis Silva Damas 04 Mar '99

04 Mar '99

Dear all, below are the proposed modifications to the inet6num object in the RIPE Database as discussed during the past RIPE Meeting. These are mainly to bring the IPv6 object up to the IPv4 object's functionality. The two suggested changes are: - addition of a "status" attribute with the following possible values: TLA, NLA and SLA. Syntax checks will be done so that: TLA is only allowed if the prefix length is 3<x<=16 NLA is only allowed if the prefix length is 16<x<=48 SLA is only allowed if the prefix length is 48<x<=64 - addition of "mnt-lower" capabilities, as in the IPv4 object. We would like to open a comment period of 1 week from today to gather input and proceed with implementation if there is consensus. Regards, Joao Damas DB Group RIPE NCC

1 0

[Fwd: FAILED:]
by Nader S Kawar 03 Mar '99

03 Mar '99

Hello, I am trying to update our aut-num object in the database but it fails giving me the below error message. Can anyone pls tell me what needs to be done. thanks. Regards, Nader Kawar Global One Jordan ------------------------------ RIPE Database Management wrote: > > Part of your update FAILED > > > From: Nader S Kawar <nader(a)go.com.jo> > > Subject: > > Date: Thu, 25 Feb 1999 14:28:14 +0200 (GMT) > > Msg-Id: <199902251228.OAA05619(a)go.com.jo> > > For help see <http://www.ripe.net/db/> or > include 'help' in the subject line of your message > > Objects without errors have been processed. > > Update FAILED: [aut-num] AS8376 > > aut-num: AS8376 > descr: GO-JOR Autonomous System > descr: Global One Communications (Jordan) Ltd > descr: Amman > as-in: from AS4004 10 accept ANY > as-in: from AS4005 10 accept ANY > as-in: from AS6453 10 accept ANY > as-in: from AS8697 10 accept ANY > as-out: to AS4004 announce AS8376 > as-out: to AS4005 announce AS8376 > as-out: to AS6453 announce AS8376 > as-out: to AS8697 announce AS8376 > default: AS4004 10 > admin-c: SK161-RIPE > tech-c: NK68-RIPE > mnt-by: GO-JOR > changed: nader(a)go.com.jo 19990225 > source: RIPE > *ERROR*: authorisation failed, request forwarded to maintainer

2 1

Adding nic handles to contact objects without one
by Joao Luis Silva Damas 02 Mar '99

02 Mar '99

Dear all, during the last RIPE meeting, in Amsterdam, the database working group discussed a proposal to automatically add NIC Handles to all person and role objects in the RIPE Database that don't yet have one (new objects can't be created without nic handles anymore). This proposal was supported by the working group and it was agreed that it should be circulated to the mailing lists to give people not attending a chance to provide input. This does not affect how other objects reference these person or role objects. This is only intended to bring old objects into conformance with the current object definitions and does not mean that data provided by the user will be modified. Only the nic handle attribute will be given a value when the object lacks one. No other attributes will be touched. Objects which already have nic handles will not be touched. The nic handle is a tag conveying no information about the user or role described in the object. It is an identifier for the object. This addition would make data more uniform and could be a benefit for everyone. For more information on nic handles, please read RIPE 157 and RIPE 189 available at http://www.ripe.net/docs Best regards, Joao Damas Database Group RIPE NCC

4 5