- db-wg - mailman.ripe.net

Re: NCC#2003092385 [db-wg] uodate failure
by RIPE Database Administration 08 Sep '03

08 Sep '03

Dear Randy, I've sent the answer in the morning, strangely it didn't reach you. Please find it below. If you have any more questions, please contact <ripe-dbm(a)ripe.net>. Regards, Katie Petrusha ____________________________ RIPE Database Administration. From: RIPE Database Administration <ripe-dbm(a)ripe.net> To: Randy Bush <randy(a)psg.com> FCC: cur Subject: Re: NCC#2003091799 FAILED: as3130 Reply-To: ripe-dbm(a)ripe.net Date: Mon, 08 Sep 2003 10:43:51 +0200 Dear Randy, At the moment person/role object with nic-handle RB366 doesn't exist in the RIPEDatabase, therefore you can't reference it from any other object. However RB366-ARIN exists and seems to be yours, maybe you meant to use that one? If you have any more questions, please contact <ripe-dbm(a)ripe.net>. Regards, Katie Petrusha ____________________________ RIPE Database Administration. Original message follows: ------------------------ no answer from ripe-dbm(a)ripe.net, so figured to ask here. what did i do wrongly? (original was pgp wrapped) To: randy(a)psg.com Subject: FAILED: as3130 Date: Fri, 5 Sep 2003 23:08:42 +0200 (MEST) > From: Randy Bush <randy(a)psg.com> > Subject: as3130 > Date: Fri, 5 Sep 2003 14:08:25 -0700 > Reply-To: randy(a)psg.com > Message-ID: <E19vNog-0004bn-CN(a)ran.psg.com> SUMMARY OF UPDATE: Number of objects found: 1 Number of objects processed successfully: 0 Create: 0 Modify: 0 Delete: 0 No Operation: 0 Number of objects processed with errors: 1 Create: 0 Modify: 1 Delete: 0 Syntax Errors: 0 DETAILED EXPLANATION: ***Warning: Invalid keyword(s) found: as3130 ***Warning: All keywords were ignored ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The following object(s) were found to have ERRORS: --- Modify FAILED: [aut-num] AS3130 ***Info: Authorisation passed ***Info: Syntax check passed aut-num: AS3130 as-name: RGNET-3130 descr: RGnet/PSGnet admin-c: RB366 tech-c: RB366 import: from AS1239 accept ANY import: from AS2914 accept ANY import: from AS3927 accept AS3927 import: from AS3970 accept AS3970 import: from AS4128 accept AS4128 import: from AS101 accept AS-PNW-GIGAPOP import: from AS11726 accept AS-ACUMEN import: from AS12111 accept AS-OEN import: from AS16713 accept AS-NOANET-PEERING import: from AS2044 accept AS2044 import: from AS3491 accept AS-CAIS import: from AS4513 accept AS-GLOBIX import: from AS4565 accept AS-EPOCH import: from AS6456 accept AS6456 import: from AS7610 accept AS-SINGAREN import: from AS8075 accept AS8075 export: to AS1239 announce AS-RGNET export: to AS2914 announce AS-RGNET export: to AS3927 announce ANY export: to AS3970 announce ANY export: to AS4128 announce ANY export: to AS101 announce AS-RGNET export: to AS11726 announce AS-RGNET export: to AS12111 announce AS-RGNET export: to AS16713 announce AS-RGNET export: to AS2044 announce AS-RGNET export: to AS3491 announce AS-RGNET export: to AS4513 announce AS-RGNET export: to AS4565 announce AS-RGNET export: to AS6456 announce AS-RGNET export: to AS7610 announce AS-RGNET export: to AS8075 announce AS-RGNET notify: rw(a)rg.net mnt-by: MAINT-RGNET changed: randy(a)psg.com 20030905 source: RIPE ***Error: Unknown object referenced ***Info: Authorisation for [aut-num] AS3130 using mnt-by: authenticated by: MAINT-RGNET ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For assistance or clarification please contact: RIPE Database Administration <ripe-dbm(a)ripe.net>

6 7

Suggestion for more user-friendly auto-dbm behaviour
by Niall O'Reilly 08 Sep '03

08 Sep '03

After a long period of not dealing with the RIPE database, I'm getting around to some overdue housekeeping. I've been surprised at how unfriendly the interface is. The following suggestions arise from this experience. First suggestion ... > ***Warning: Invalid keyword(s) found: Update > ***Warning: All keywords were ignored It could be more clearly put, that this refers only to the 'Subject' line. Why not replace the text, "All keywords were ignored" with "Entire subject line was ignored". Second suggestion ... > ***Error: Required attribute "netname" is missing > ***Error: Required attribute "country" is missing > ***Error: Required attribute "status" is missing > ***Error: Required attribute "mnt-by" is missing I didn't wish to modify any of these just now. Why not proceed as follows: 1. Load (partial) object from transaction. 2. Retrieve matching object (if any) from database. 3. Perform go/no-go tests (authorization, validity ...) 4. Merge transaction with what was retrieved (may be null). 5. Perform any completeness/self-consistency tests. 6. Commit update unless errors were found. 7. Notify parties involved. That should be worth at least EUR 0.02! I'll send on the invoice. 8-) Niall O'Reilly

1 0

summary of organisation object discussions
by Engin Gunduz 08 Sep '03

08 Sep '03

Dear Colleagues, [apologies for duplicate messages, and for having misspelled ncc-services-wg(a)ripe.net in the previous posting] I'd like to summarise the discussions took place in the last two weeks in the working group mailing lists after the publication of the organisation object proposal ( http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00159.html ) and after the presentation in the DB-WG session last week in RIPE 46 Meeting ( http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-db-organisat… ). 1. "org:" attribute mandatory or optional in aut-num objects? The proposal mentioned above specified "org:" attribute in aut-num objects to be mandatory. However, often LIRs request an ASN for their customers and the RIPE NCC does not have enough information for them to fill in an organisation object completely. Rather than putting invalid information on the whois database, the RIPE NCC thinks it is better to make "org:" attribute optional in aut-nums. 2. "org:" attribute multi- or single-valued? The proposal specified "org:" attribute single-valued in all objects. During the discussions in the DB WG, commentors from the audience stated that in some cases a person object works for more than one companies, thus one might want to put multiple "org:" attributes in his/her person object. Similar reasoning could apply to other object types as well. However, the "org:" object specifies the holder of an Internet resource in inetnum, inet6num and aut-num objects, thus it must be single-valued in these objects. For the rest of the objects, we propose to modify the rule so it can be multi-valued. 3. addition of "mnt-ref:" attribute. The proposal suggested the use of "mnt-by:" attribute for both authorisation of modification of the organisation object and the authorisation of adding a reference to the organisation object from other objects. This has a shortcoming when the organisation object is protected by an entity other than the organisation itself (for example, an LIR, whose organisation object is protected by the RIPE NCC). We would propose to introduce mandatory "mnt-ref:" attribute to control the references to the organisation object, while "mnt-by:" protects the organisation object itself, as usual. 4. "org:" attribute in the organisation object itself. The proposal suggested the use of "org:" attribute in non-organisation objects. I think it could be used in organisation objects as well, to indicate business relations like being a dependent company to another one. 5. "business-id:" attribute. It was suggested to add an attribute to specify the national organisation number or VAT number or a similar ID of the organisation. While we see the point in this, we feel it needs some more discussion. It can be added to the organisation object after its introduction. 6. changing the meaning of '-r' flag. The proposal suggested that, when a query returns an object with an "org:" attribute, the organisation objects mentioned in this attribute be appended to the query results. This behaviour can be changed by using '-r' flag in the query. This idea was based on the fact that the "org:" attribute is at least as relevant to the resource as the "admin-c:", "tech-c:" and "zone-c:" attributes as contact information. Thus, if we return person/role objects mentioned in the query results, we should also return the organisation objects. Basically, the proposed behaviour maintains the consistency. During the discussions it was proposed to change the default behaviour of whois server, and change the meaning of '-r' flag, so that - the server does not 'expand' "admin-c:", "tech-c:" and "zone-c:" attributes, nor "org:" attribute by default, - and it expands them only when '-r' flag is used. This can separately be discussed, however, I think this is out of the scope of organisation object. I hope I did not miss any other issues. If these points are OK, we will prepare another proposal for organisation object and publish it. Best regards, -- Engin Gunduz RIPE NCC Database Group

1 0

summary of organisation object discussions
by Engin Gunduz 08 Sep '03

08 Sep '03

Dear Colleagues, I'd like to summarise the discussions took place in the last two weeks in the working group mailing lists after the publication of the organisation object proposal ( http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00159.html ) and after the presentation in the DB-WG session last week in RIPE 46 Meeting ( http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-db-organisat… ). 1. "org:" attribute mandatory or optional in aut-num objects? The proposal mentioned above specified "org:" attribute in aut-num objects to be mandatory. However, often LIRs request an ASN for their customers and the RIPE NCC does not have enough information for them to fill in an organisation object completely. Rather than putting invalid information on the whois database, the RIPE NCC thinks it is better to make "org:" attribute optional in aut-nums. 2. "org:" attribute multi- or single-valued? The proposal specified "org:" attribute single-valued in all objects. During the discussions in the DB WG, commentors from the audience stated that in some cases a person object works for more than one companies, thus one might want to put multiple "org:" attributes in his/her person object. Similar reasoning could apply to other object types as well. However, the "org:" object specifies the holder of an Internet resource in inetnum, inet6num and aut-num objects, thus it must be single-valued in these objects. For the rest of the objects, we propose to modify the rule so it can be multi-valued. 3. addition of "mnt-ref:" attribute. The proposal suggested the use of "mnt-by:" attribute for both authorisation of modification of the organisation object and the authorisation of adding a reference to the organisation object from other objects. This has a shortcoming when the organisation object is protected by an entity other than the organisation itself (for example, an LIR, whose organisation object is protected by the RIPE NCC). We would propose to introduce mandatory "mnt-ref:" attribute to control the references to the organisation object, while "mnt-by:" protects the organisation object itself, as usual. 4. "org:" attribute in the organisation object itself. The proposal suggested the use of "org:" attribute in non-organisation objects. I think it could be used in organisation objects as well, to indicate business relations like being a dependent company to another one. 5. "business-id:" attribute. It was suggested to add an attribute to specify the national organisation number or VAT number or a similar ID of the organisation. While we see the point in this, we feel it needs some more discussion. It can be added to the organisation object after its introduction. 6. changing the meaning of '-r' flag. The proposal suggested that, when a query returns an object with an "org:" attribute, the organisation objects mentioned in this attribute be appended to the query results. This behaviour can be changed by using '-r' flag in the query. This idea was based on the fact that the "org:" attribute is at least as relevant to the resource as the "admin-c:", "tech-c:" and "zone-c:" attributes as contact information. Thus, if we return person/role objects mentioned in the query results, we should also return the organisation objects. Basically, the proposed behaviour maintains the consistency. During the discussions it was proposed to change the default behaviour of whois server, and change the meaning of '-r' flag, so that - the server does not 'expand' "admin-c:", "tech-c:" and "zone-c:" attributes, nor "org:" attribute by default, - and it expands them only when '-r' flag is used. This can separately be discussed, however, I think this is out of the scope of organisation object. I hope I did not miss any other issues. If these points are OK, we will prepare another proposal for organisation object and publish it. Best regards, -- Engin Gunduz RIPE NCC Database Group

1 0

uodate failure
by Randy Bush 08 Sep '03

08 Sep '03

no answer from ripe-dbm(a)ripe.net, so figured to ask here. what did i do wrongly? (original was pgp wrapped) To: randy(a)psg.com Subject: FAILED: as3130 Date: Fri, 5 Sep 2003 23:08:42 +0200 (MEST) > From: Randy Bush <randy(a)psg.com> > Subject: as3130 > Date: Fri, 5 Sep 2003 14:08:25 -0700 > Reply-To: randy(a)psg.com > Message-ID: <E19vNog-0004bn-CN(a)ran.psg.com> SUMMARY OF UPDATE: Number of objects found: 1 Number of objects processed successfully: 0 Create: 0 Modify: 0 Delete: 0 No Operation: 0 Number of objects processed with errors: 1 Create: 0 Modify: 1 Delete: 0 Syntax Errors: 0 DETAILED EXPLANATION: ***Warning: Invalid keyword(s) found: as3130 ***Warning: All keywords were ignored ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The following object(s) were found to have ERRORS: --- Modify FAILED: [aut-num] AS3130 ***Info: Authorisation passed ***Info: Syntax check passed aut-num: AS3130 as-name: RGNET-3130 descr: RGnet/PSGnet admin-c: RB366 tech-c: RB366 import: from AS1239 accept ANY import: from AS2914 accept ANY import: from AS3927 accept AS3927 import: from AS3970 accept AS3970 import: from AS4128 accept AS4128 import: from AS101 accept AS-PNW-GIGAPOP import: from AS11726 accept AS-ACUMEN import: from AS12111 accept AS-OEN import: from AS16713 accept AS-NOANET-PEERING import: from AS2044 accept AS2044 import: from AS3491 accept AS-CAIS import: from AS4513 accept AS-GLOBIX import: from AS4565 accept AS-EPOCH import: from AS6456 accept AS6456 import: from AS7610 accept AS-SINGAREN import: from AS8075 accept AS8075 export: to AS1239 announce AS-RGNET export: to AS2914 announce AS-RGNET export: to AS3927 announce ANY export: to AS3970 announce ANY export: to AS4128 announce ANY export: to AS101 announce AS-RGNET export: to AS11726 announce AS-RGNET export: to AS12111 announce AS-RGNET export: to AS16713 announce AS-RGNET export: to AS2044 announce AS-RGNET export: to AS3491 announce AS-RGNET export: to AS4513 announce AS-RGNET export: to AS4565 announce AS-RGNET export: to AS6456 announce AS-RGNET export: to AS7610 announce AS-RGNET export: to AS8075 announce AS-RGNET notify: rw(a)rg.net mnt-by: MAINT-RGNET changed: randy(a)psg.com 20030905 source: RIPE ***Error: Unknown object referenced ***Info: Authorisation for [aut-num] AS3130 using mnt-by: authenticated by: MAINT-RGNET ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For assistance or clarification please contact: RIPE Database Administration <ripe-dbm(a)ripe.net>

1 0

Re: [db-wg] The New "organisation object" Proposal
by Denis Walker 04 Sep '03

04 Sep '03

Hi Ulrich, Notifications is becoming a complex issue in itself now. In the case you mentioned below, the notify: in the mntner is only used if the mntner object itself is modified. There is a close relationship now between the mnt-nfy: and the proposed ref-nfy:, but they are not the same thing. If you successfully modify a person object by adding a mntner into a mnt-by: then the mnt-nfy: would be notified about a successful modification and also the ref-nfy: will be notified because the mntner has been referenced. However, consider the case where an inetnum object is modified by adding a mntner into a mnt-lower:. In this case the ref-nfy: will be notified because the mntner has been referenced. But the mnt-nfy: of the referenced mntner will NOT be notified in this case. The mnt-nfy: of the mntner in the inetnum's mnt-by: will also be notified of a successful modification, but this may not be the same mntner as the one referenced in the mnt-lower:. I think we will need to write a small document explaining all the notification rules. We need to think carefully about who is notified and when and we wrote the code to apply these rules. So I think it will be very confusing to a new user of the database. cheers denis Ulrich Kiermayr <ulrich.kiermayr(a)univie.ac.at> writes: * Hi Denis, * * > [snip] * > * > It may be a bit of an overkill to add mnt-ref: to the mntner: as in * > most cases people would probably make it refer to itself, although it * > would be consistent. Another option to prevent un-authorised use * > (malicious or accidental) of a mntner is to require the mntner's own * > authorisation to be provided whenever it is added to an object. * * I agree, that it looks like an overkill, but I'd prefer to see a * consistent behaviour among all the objects. [I cold also imagine cases, * where they might as well differ]. On the other hand i could also imagine * a fallback-scheme like in the mnt-lower: if no mnt-ref, them use the * mntner itself or so.... * * One thing i have not checked: Is a ref-nfy in a mntner redundant * informaiton (e.g already coverd by notify there)? * * lG uk * -- * Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien * Network/Security Universitaetsstrasse 7, 1010 Wien, Austria * * eMail: ulrich.kiermayr(a)univie.ac.at Tel: (+43 1) 4277 / 14104 * Fax: (+43 1) 4277 / 9140 *

1 0

Re: [db-wg] The New "organisation object" Proposal
by Denis Walker 04 Sep '03

04 Sep '03

Ulrich Kiermayr <ulrich.kiermayr(a)univie.ac.at> writes: * Hi Engin, * * >>so the idea would be to seperate the reference authorisation from the * >>object-maintainer. Like in the irt-object one could introduce an 'auth:' * >>attribute to check the tagging. * > * > * > OK, that makes sense too. * > * > How about introducing "mnt-ref:" attribute for this purpose? That is, * > "mnt-by:" will protect/control the organisation object itself. * > And, "mnt-ref:" will control the references to this organisation * > object. Thus, an LIR org object might be: * > * > organisation: ORG-AA11-RIPE * > [...] * > org-type: LIR * > mnt-by: RIPE-NCC-HM-MNT * > mnt-ref: LIR-MNT * > mnt-ref: RIPE-NCC-HM-MNT * * This makes a lot of sense as well. * * > To maintain consistency, perhaps we could do the same in irt * > objects: Change the "auth:" attr into "mnt-ref:" and have mntner * > names in it (rather than auth methods directly). Also, "irt-nfy:" * > might be changed into "ref-nfy:", again for consistency. But perhaps * > this is out of scope... * * Hmm, if we waht to change the behaviour for consistency, we should do it * now, when the irt is not to widely used. * * If we agree on this more generic solution, we could extend this behavior * to other Objects that can be referenced as well. * e.g. for mntner: itself. this would be a way tho prevent anyone from * putting my mntner ont oan object. (This would solve the issue discussed * in the context of the IRT Object - where the mntner of the object should * be a proof of authenticity as well) * [snip] It may be a bit of an overkill to add mnt-ref: to the mntner: as in most cases people would probably make it refer to itself, although it would be consistent. Another option to prevent un-authorised use (malicious or accidental) of a mntner is to require the mntner's own authorisation to be provided whenever it is added to an object. cheers denis

2 1

RE: [db-wg] another attribute for organisation object
by Wilfried Woeber, UniVie/ACOnet 03 Sep '03

03 Sep '03

Hi Engin, all! [ apologies for potentially replying out of synch, I haven't read to the end of my mail yet... ] 2 comments: . format: unless we add an (issuing) country indication, the string in itself might not mean anything . verification / use: who is supoosed to do what with this piece of information? And, depending on what we want to do with this info, is it "help-yourself", or is the NCC expected to do any sort of verification? If the latter, what would the cost vs. benefit of doing so be? Wilfried. ______________________________________________________________________ >From the feedback we've got, it looks like we want another attribute in the organisation object, in which users can put an "organisation number" or an "organisation-id". This can be a VAT number, or a number assigned by a certain Chamber of Commerce, or any kind of other ID. We would propose calling it "business-id:". We have thought of "org-id:" but the org-ID is the string we will have in "organisation:" attribute, so calling another attribute "org-id:" would be confusing. "national-id:" would have been another idea, but some IDs might not be a national one, like an ID assigned uniquely in the EU. So the proposal is to add business-id: [optional] [multiple] as a new attribute. It is optional, as an organisation might not have such an ID. It is multiple, because an organisation might have multiple such IDs. Thanks and best regards, -- Engin Gunduz RIPE NCC Database Group --------------------------------------------------------------------------------

2 1

draft agenda (V2) for DB-WG meeting, RIPE 46, Amsterdam, NL
by Wilfried Woeber, UniVie/ACOnet 02 Sep '03

02 Sep '03

Dear all, this is V2 of the proposed agenda for the DB-WG sessions. I have received a request to deal with the org: object proposal in slot #1. After checking with the RIPE NCC, I propose to accommodate that request, and thus to reorder the sequence to make F.+G. go first, and then to continue with E., most probably moving it to slot#2 on Thursday. Regarding the following paragraph: > NOTE: I have seen some discussion about the ERX, so I'm trying to offer > the opportunity for the community affected to give short (if > possible ;-) presentations about - experience, - expectation, - > suggestiosn for improvement, after an intro provided by the RIPE > NCC (from their point of view). If you intend to do that, pls. let > me know before the start of the session! I have not seen any input or indication of interest to contribute :-( Wilfried. ______________________________________________________________________ Proposed Agenda for the Database Working Group Meeting 2. Draft approx. A#1. Administrative stuff (WW, chair) 10 min . scribe: N.N. B#1. Action Items 15 min C#1. WG mandate and charter, part I (WW, chair) 10 min . splitting the load between DB, Services, and? D#1. DB operational update (RIPE NCC, Shane K.) 20 min F#1. The "status:" attribute (RIPE NCC, N.N.) 15 min G#1. The org: Object proposal revised (RIPE NCC, Engin G.) 15 min ------- end of slot#1 ------- E#2. ERX status 30 min . status as from the point of view of the NCC 5 min . short reports about experience 20 min . proposals for improvements? 5 min H#2. Revised PKI proposal (RIPE NCC, Shane K.) 30 min I#2. change of behavior/default of DB-SW (RIPE NCC, Shane K.) 10 min . if "mnt-lower: is absent: .. makedefault more consistent .. lean towards a more secure behavior J#2. WG mandate and charter, part II (WW, chair) 10 min . review of alignement with other WGs . summary . editorial finalisation Y#2. Input from other WGs . Z#2. AOB: . tent.: review of DB Architecture and Assumptions . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 2-SEP-2003 15:06:11 UTC _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Only one thing in life is certain: init is Process #1"

1 0

Draft minutes for DB-WG
by Nigel Titley 01 Sep '03

01 Sep '03

Folks, Here are the draft minutes for the DB WG meeting at Barcelona. Apologies for the delay in posting. Nigel -- Nigel Titley <nigel(a)packetexchange.net> PacketExchange Ltd

1 0