- db-wg - mailman.ripe.net

Re: [db-wg] Re: "changed:" attribute
by Denis Walker 08 Sep '03

08 Sep '03

Steve Atkins <steve(a)blighty.com> writes: * On Mon, Sep 08, 2003 at 03:21:20PM +0100, Rodney Tillotson wrote: * > 2. * > > Secondly, the query users do not really know what "changed:" attribute * > > means. ... most users and automated tools pick anything that resembles * > > an email address in the whois query result and send them abuse * > > complaints. * > * > The question here is about external presentation; who sees "changed:", * > what they are looking for when they see it, what they think it means * > and what they do with it. * > * > * > The anti-spam WG is preparing a broad proposal, but one early thought * > is to provide different database views for the different classes of * > user. Casual users looking for contact information in the default * > output are an important class, probably not the most well-informed or * > patient, and it may be worth suppressing "changed:" in the view they * > get. This applies whatever decisions we make about the internal * > behaviour or the way LIRs will use the attribute. * * That seems like a good idea. Many casual users of the RIPE database do * not query it directly, rather through a small number of web-based * gateways. Would it be worth asking the owners of those gateways * to filter out the changed field now, to see what effect that has? But then someone will realise the changed lines are missing and think we are hiding something. So they will write a tool to show them and give them even more significance. cheers denis * * Cheers, * Steve *

2 1

The New "organisation object" Proposal
by DB-News 08 Sep '03

08 Sep '03

Dear Colleagues, [apologies for duplicate messages] Following discussions at the RIPE NCC about a new Whois Database object, the organisation object, we have modified the previous proposal that you can find at: http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00013.html The main changes from the previous proposal are: - a "country:" attribute is added. - "org-type:" and "org-name:" attributes are added, and "organisation:" attribute is now a NIC handle, which will be automatically assigned during the creation of the object. The motivation for this is explained in Section 3 of the proposal. - Hierarchical names can be removed, mainly for simplicity. - Differing query results on the whois server introduced in section 5. According to this, the relevant organisation objects are appended to the query results (because the organisation that holds the resource is at least as important as the person/role objects mentioned in the resource object). Please let us know your comments and concerns about the new proposal attached to this mail. Thanks for your time and best regards, -- Engin Gunduz RIPE NCC Database Group An organisation object in the RIPE Database -------------------------------------------- 1. Motivation ------------------- Currently the RIPE Database stores two main types of contact information: person and role objects. The person and role objects provide a way to contact people responsible for operations or usage of the resources represented in the RIPE Database (IP blocks, autonomous systems, and domain names). However, none of these provide an easy way of mapping resources to a particular organisation. A user must first find an object containing contact information for that organisation. Then, assuming all of the organisation's objects refer to this contact information, the user must perform an inverse query to obtain a list of objects referencing the specified person or role. This indirect process can be somewhat obscure and therefore a request for a more direct way of attaching an object to an organisation is seen as a useful addition to the RIPE Database. This document is a proposal for an organisation object in the RIPE Database and the necessary database functionality. 2. The organisation object ----------------------- The organisation object provides information identifying an organisation such as a company, charity or university, that is a holder of a network resource whose data is stored in the RIPE Database. The organisation object is identified by a unique ID specified in the "organisation:" attribute which is the primary key. An organisation object can be referenced from other types of objects using an "org:" attribute. All objects associated with a particular organisation can be retrieved by performing an "inverse query" for the organisation's ID (handle) used in the "org:" attribute of database objects. Following is a template for the proposed organisation object and an example. All attributes except the "ref-nfy:", "organisation:", "org-name:" and "org-type:" have their usual meanings. organisation: [mandatory] [single] [primary/look-up key] org-name: [mandatory] [single] [look-up key] org-type: [mandatory] [single] [ ] descr: [mandatory] [multiple] [ ] remarks: [optional] [multiple] [ ] address: [mandatory] [multiple] [ ] country: [mandatory] [single] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [look-up key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] ref-nfy: [optional] [multiple] [inverse key] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] 3. New attributes ---------------------- "organisation:" Specifies the ID of an organisation object. An organisation ID is made up of 'ORG-' prefix, followed by 2 to 4 letters, digits, a dash and is followed by the database source (in the RIPE Whois Database this is 'RIPE'). For example: ORG-RT34-RIPE Note that all parts are mandatory, thus ORG-RT-RIPE would be an invalid ID as it is missing the numeric part. Organisation object IDs are auto-generated similar to the way person/role "nic-hdl:" attributes are auto-generated. The user has to specify the ID of an organisation object as ORG-AUTO-<digit> during creation of the object, then it will be assigned an appropriate ID. The organisation ID is assigned using the "org-name:" attribute of the object. The user can specify the letter combination he/she prefers. For example if the user wants TTR as the letter combination, in the organisation ID, then ORG-AUTO-1TTR should be put into "organisation:" attribute during the creation of the object. The organisation ID cannot be reused. If an organisation ID was used in the past by an organisation object and then deleted, this ID cannot be used in new organisation objects. The auto-generation of organisation IDs and preventing reuse of them simplifies the external references. Note that when an organisation changes name, the "org-name:" can be modified accordingly. There is no need to change the organisation ID. "org-name:" Specifies the name of the organisation that this organisation object represents in the whois database. This is an ASCII-only text attribute. The restriction is because this attribute is a look-up key and the whois protocol does not allow specifying character sets in queries. The user can put the name of the organisation in non-ASCII character sets in the "descr:" attribute if required. "org-type:" Specifies the type of the organisation. The possible values are 'IANA' for Internet Assigned Numbers Authority, 'RIR' for Regional Internet Registries, 'NIR' for National Internet Registries, 'LIR' for Local Internet Registries, and 'NON-REGISTRY' for all other organisations. "ref-nfy:" Specifies the e-mail address to be notified when a reference to the organisation object is added or removed. An e-mail address as defined in RFC 2822. [This functionality is used in the "irt-nfy:". The name of this attribute is more neutral allowing reuse in other object types.] "country:" Specifies the two-letter ISO3166 country code of the country where this organisation resides. "address:" Specifies the address of the organisation. This is a free-text attribute. "org:" May be included in any other object type. It points to an existing organisation object representing the entity that holds the resource. The value of this attribute is the ID of the organisation object. It is mandatory in the aut-num objects, and inetnum and inet6num objects with "ALLOCATED-BY-IANA", "ALLOCATED-BY-RIR", "ALLOCATED-BY-RIR NON-PORTABLE", "ALLOCATED-BY-RIR PORTABLE" and "ALLOCATED-BY-RIR UNSPECIFIED" values. It is optional in all other objects, and it is single valued in all objects. 4. Authorisation checks ---------------------------------- When modifying an organisation object the update must pass authorisation checks specified by one of the mntners listed in the "mnt-by:" attributes of the organisation object. When adding an "org:" attribute to an object, the update of the object should pass the following authorisation checks: - from one of the maintainers of the organisation object - from one of the maintainers of the object being updated 5. Query changes ---------------- If a whois query returns an object with an "org:" attribute, the organisation object mentioned in this attribute is also appended to the query results. This behaviour can be disabled by using the '-r' flag in the query. 6. Examples ------------ A basic organisation object: organisation: ORG-RSIS54-RIPE org-name: Random Street Internet Services org-type: LIR descr: An example organisation address: Random St. city: Amsterdam country: NL phone: +31 123 4567 fax-no: +31 123 4568 e-mail: contact(a)example-org.net admin-c: EXAM1-RIPE tech-c: EXAM2-RIPE notify: ripe-mailbox(a)example-org.net ref-nfy: ripe-mailbox(a)example-org.net mnt-by: EXAMPLE-MNT changed: someguy(a)example-org.net 20030121 source: RIPE A network that references an organisation object: inetnum: 192.168.86.0 - 192.168.86.255 netname: EXAMPLE-NET-86 descr: Sample network org: ORG-RSIS54-RIPE country: NL admin-c: JE1-RIPE tech-c: JE2-RIPE status: ALLOCATED-BY-RIR PORTABLE mnt-by: EXAMPLE-MNT mnt-lower: EXAMPLE-MNT changed: someguy(a)example-org.net 20030122 source: RIPE A query for this inetnum object: % whois 192.168.86.251 inetnum: 192.168.86.0 - 192.168.86.255 netname: EXAMPLE-NET-86 descr: Sample network org: ORG-RSIS54-RIPE country: NL admin-c: JE1-RIPE tech-c: JE2-RIPE [...] source: RIPE organisation: ORG-RSIS54-RIPE org-name: Random Street Internet Services org-type: LIR descr: An example organisation address: Random St. address: The Netherlands phone: +31 123 4567 fax-no: +31 123 4568 e-mail: contact(a)example-org.net admin-c: EXAM1-RIPE tech-c: EXAM2-RIPE [...] source: RIPE person: John Example nic-hdl: JE1-RIPE [...] source: RIPE person: John Example Jr nic-hdl: JE2-RIPE [...] source: RIPE

17 35

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

Re: [ncc-services-wg] Re: [db-wg] The New "organisation object" Proposal
by azucena.hernandezperez＠telefonica.es 29 Aug '03

29 Aug '03

I support the view of Hans Petter regarding the additional identification of each organisation by a number making it a separate object in the database. I am in favor using the VAT number for organisations in EU countries and soon in the Eastern Europe Accessing countries and any other national registration number for those organisations established in non-EU countries. Azucena Hans Petter Holen <hpholen(a)tiscali.no> Enviado por: ncc-services-wg-admin(a)ripe.net 29/08/03 19:17 Para: Engin Gunduz <engin(a)ripe.net> cc: Hans Petter Holen <hpholen(a)tiscali.no>, DB-News <db-news(a)ripe.net>, <db-wg(a)ripe.net>, <ncc-services-wg(a)ripe.net> Asunto: [ncc-services-wg] Re: [db-wg] The New "organisation object" Proposal Clasificación: Uso Interno > I think that this is something too specific to have its own attribute. > "remarks:" attribute can be used for this I guess, just like it can > be used to point users to web pages etc. I dont agree: the point about the attribute would be to uniquely identify the organisation within a country. I am quite shure all countries within the EU has this concept of org-number/vat number or public registry number. The good thing is that it stays unique and lives trough name changes. Hans Petter ___________________________________________________________________________ Este mensaje se dirige exclusivamente a su destinatario y puede contener información privilegiada o confidencial. Si no es vd. el destinatario indicado, queda notificado de que la utilización, divulgación y/o copia sin autorización está prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. This message is intended exclusively for its addressee and may contain information that is CONFIDENTIAL and protected by professional privilege. If you are not the intended recipient you are hereby notified that any dissemination, copy or disclosure of this communication is strictly prohibited by law. If this message has been received in error, please immediately notify us via e-mail and delete it. ___________________________________________________________________________

3 2

another attribute for organisation object
by Engin Gunduz 29 Aug '03

29 Aug '03

Dear colleagues, >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

1 0

upd: draft agenda (v1*A*), for DB-WG meeting, RIPE 46, Amsterdam, NL
by Wilfried Woeber, UniVie/ACOnet 22 Aug '03

22 Aug '03

[ sorry, forgot to include one item: new I., I. became J. ] [ -WW ] Dear WG list members, dear "Meeting Role" @ the NCC, dear WG-Chairs! Attached please find the 1st draft: Proposed Agenda for the DB-WG Meeting at RIPE 46 in Amsterdam, NL. As usual, if you have any comments, corrections or additions please get back to me directly and asap. As we do have 2 slots this time - which are _not_ adjacent (on different days!) Verion 2 will try to sort the items into the bins for day 1 (Wed., 14:00 - 15:30) and day 2 (Thursday 9:00 - 10:30) 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! Looking forward to see many of you in Amsterdam, Wilfried. ______________________________________________________________________ Proposed Agenda for the Database Working Group Meeting 1. Draft approx. A. Administrative stuff (WW, chair) 10 min . scribe: N.N. B. Action Items 15 min C. WG mandate and charter, part I (WW, chair) 10 min . splitting the load between DB, Services, and? D. DB operational update (RIPE NCC, Shane K.) 20 min E. 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 F. The "status:" attribute (RIPE NCC, N.N.) 15 min G. The org: Object proposal revised (RIPE NCC, Engin G.) 15 min H. Revised PKI proposal (RIPE NCC, Shane K.) 30 min I. 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. WG mandate and charter, part II (WW, chair) 10 min . review of alignement with other WGs . summary . editorial finalisation Y. Input from other WGs . Z. AOB: . tent.: review of DB Architecture and Assumptions . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 22-AUG-2003 10:40:44 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 agenda (v1), for DB-WG meeting, RIPE 46, Amsterdam, NL
by Wilfried Woeber, UniVie/ACOnet 22 Aug '03

22 Aug '03

Dear WG list members, dear "Meeting Role" @ the NCC, dear WG-Chairs! Attached please find the 1st draft: Proposed Agenda for the DB-WG Meeting at RIPE 46 in Amsterdam, NL. As usual, if you have any comments, corrections or additions please get back to me directly and asap. As we do have 2 slots this time - which are _not_ adjacent (on different days!) Verion 2 will try to sort the items into the bins for day 1 (Wed., 14:00 - 15:30) and day 2 (Thursday 9:00 - 10:30) 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! Looking forward to see many of you in Amsterdam, Wilfried. ______________________________________________________________________ Proposed Agenda for the Database Working Group Meeting 1. Draft approx. A. Administrative stuff (WW, chair) 10 min . scribe: N.N. B. Action Items 15 min C. WG mandate and charter, part I (WW, chair) 10 min . splitting the load between DB, Services, and? D. DB operational update (RIPE NCC, Shane K.) 20 min E. 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 F. The "status:" attribute (RIPE NCC, N.N.) 15 min G. The org: Object proposal revised (RIPE NCC, Engin G.) 15 min H. Revised PKI proposal (RIPE NCC, Shane K.) 30 min I. WG mandate and charter, part II (WW, chair) 10 min . review of alignement with other WGs . summary . editorial finalisation Y. Input from other WGs . Z. AOB: . tent.: review of DB Architecture and Assumptions . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 22-AUG-2003 10:40:44 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

call for agenda items, DB-WG meeting, RIPE 46 @ AMS, NL
by Wilfried Woeber, UniVie/ACOnet 21 Aug '03

21 Aug '03

"Somewhat" urgent: Call for agenda items! >Date: Tue, 12 Aug 2003 12:01:21 +0200 > >Dear WG Chair, > >We are less than three weeks away from the RIPE Meeting. To make sure >that we have all Working Group Agendas published and printed on time, I >kindly ask you to send us your agenda. > >The deadline is Wednesday 20 August. Although the deadline has passed already (and I am wading through and sorting and trashing a mail backlog of 5K+), we need an agenda for the WG meeting. I am going to include the "usual stuff" from my end, plus an item for discussion on WG mandate. And I have (during my absence for vacation - which I dearly needed ;-) received a couple of requests already which will make it into the 1st draft. Everything alse has to come from the community, so submit your input and ideas, please!! Thanks, see you in AMS, Wilfried.

1 0

Fwd: [db-wg] X.509 authentication in the RIPE Database, take II
by Joao Luis Silva Damas 20 Aug '03

20 Aug '03

On Friday, August 15, 2003, at 04:23 PM, Shane Kerr wrote: > Joao, > > Joao Luis Silva Damas wrote: >> adding a new strong authentication method to the Database, is in my >> own personal opinion, a good thing(tm), particularly if the same >> credential can be used for other interactions with the RIPE NCC, make >> user's life easier. >> I wonder however about a few questions: >> - will this auth method be available only to RIPE NCC members? Is it >> not seen as a valuable general addition for non-member users of the >> IRR part of the RIPE DB? > > Initially it will only be available for RIPE NCC members. Another interesting change in the model? When you say initially, does this mean it will be extended or not? Shall on read the current proposal as implicitly stating this? > There are three ways we could extend the service to non-LIRs: > > 1. Accept certificates from certain "well-known" CAs, for example > Thawte, Verisign, etc. > > 2. Issue certificates from a RIPE NCC CA established for this purpose, > and accept them. > > 3. Accept all certificates, including self-signed certificates. > > #1 is relatively easy - the main overhead would be maintaining the > Certificate Revokation Lists from the CAs. Deciding which CAs to > support may also be tricky. #2 is also relatively easy, since we > already have the technology. #3 is more difficult, and would require > a slight change of the design, and administration issues (see below). For DB authentication purposes, why do you need to verify the certificate? As with the PGP model[1], the only assumption one needs to make is that the message issuer is the holder of the private part of the certificate. If the RIPE DB is going to start making assertions about the real identity of the message sender, rather than just authorise or refuse updates, this seems to be a change in the model that warrants discussion in the working group. Is this so, or am I misinterpreting your description of the mechanism? > >> - Why the choice of not publishing the pulic part of the certificated >> in the DB? The choice to have a key-cert for the PGP method was not >> to do with issues of web of trust but rather for purposes of helping >> the users with their data maintenance. As a matter of fact the >> recommendation regarding the use of PGP in the RIPE DB, as described >> in the RFC and the minutes of the DBSEC TF, was to use a PGP key for >> this purpose that was not used elsewhere. > > When you receive a PGP-signed message, you need the public key of the > signer to verify the signature. The program that updates the Database > needs this information, and it is stored in the key-cert objects(*). > > With S/MIME, the certificate is sent with the message, and this > certificate is signed by the CA. Since the database is configured to > know how to verify certificates issued by specific CAs, we can verify > the signature. No key-cert is necessary. > > But if we decide to allow any certficate, including self-signed, then > we need some way to allow users to store this information in the > database, for example key-cert objects. Unfortunately, this may cause > problems, because (for instance) someone could create a key-cert > object for a CA run by another organisation with bogus data, > preventing users from using certificates *actually* issued by that CA. > > We could possibly require these sort of key-cert objects be reviewed > by some method, for example RIPE DBM. However, if the RIPE NCC has no > relationship with the CA, we have no real way to know the validity of > any one request. Why do you need to verify the certificate. Also, part of the idea of having a key-cert object was to allow users to check, not the DB, and to maintain DB self-consistency. Are these no longer desired features? Joao [1] RFC 2726

3 2

Re: [address-policy-wg] IP Addressing policy on personal contact info (kf)
by Shane Kerr 20 Aug '03

20 Aug '03

Pascale Julienne, Pascal Julienne wrote: > In France there is such a thing as unlisted phone numbers which > remain private and unknown. Further, the RIPE DB is becoming the > best spam list in the world. So yes, responsability lays with LIR, > yes let's clean the DB, yes respect privacy. I think there are two sides to this issue. One is what the RIPE NCC can and has done to increase the privacy of people who have contact information in the Database. We have been trying to increase the privacy protections in the Database over time: - person/role objects removed from public FTP site - DB automatically rate limits access to person/role objects - mntner/irt objects removed from public FTP site - .DE person object deletion - automatic cleanup of unreferenced person/role objects The Allocation Editor on the LIR Portal should allow LIRs to keep their contact data up-to-date. We have talked with the Dutch Data Protection Authority about the Database as well, to make sure that we don't run afoul of the EU privacy directives. There has been some discussion at the last RIPE meeting about how the Database both aids and hinders spammers. Suggestions such as checking validity of contact information, as well as possibly putting fake entries in the Database and tracking spam they receive were mentioned. The second issue is deciding on what contact data *should* be in the Database. This is the job of the address-policy-wg, and perhaps the db-wg. A related issue is how the data should be accessed, which is also something that can be decided by the same groups. Katri Forsberg did a service by raising the issue. As a final issue, I am curious why you say the RIPE Database is becoming the best spam list in the world! I think that it probably generates a lot of spam for LIRs, because they have their contact information on many objects in the Database. I don't know any way to avoid this if the Database is public. I hope that for the end users who's information is in the Database for only a small number of addresses that they do not get much spam originating from the publication in the Database. The RIPE NCC is certainly interested in mechanisms that we can set up to prevent such use, as it is explicitly *not* allowed by the license that we provide for the Database. -- Shane Kerr RIPE NCC

5 4

X.509 authentication in the RIPE Database, take II
by Shane Kerr 18 Aug '03

18 Aug '03

All, [Apologies for duplicate e-mails] Attached please find a proposal for X.509 authentication in the RIPE Database. From the Database point of view (that is, syntax and semantics), it is the same as the one sent 3 July 2003. The difference is that it contains only the specific details of the change, in a straightforward fashion. I hope that we have addressed questions about the use of X.509 that arose in earlier discussions. -- Shane Kerr RIPE NCC Addition of X.509 authentication to the Database Proposal: To add an X509 authentication type to the "auth:" attribute. Attributes with this type will use the Distinguished Name (DN) of the certificate to identify it. Motivation: X.509 allows a single authentication method to work for both e-mail and the web. LIRs can receive an X.509 certificate through the LIR Portal, and should be able to use this to update records they control in the Database. X.509 is "strong", like PGP, although a different trust model is used. Details: The "auth:" attribute of the mntner class will have a new authentication scheme, X509. The DN, as defined in RFC 2253, will be used to identify the specific certificate used. Note that there is no key-cert object for the X509 scheme. Instead, the certificate must be signed by a trusted authority. The trusted authority will be the RIPE NCC Certificate Authority (CA) that is currently only available to LIRs. It is possible to configure additional CAs in future, should this become desirable. For instance, existing commercial CAs could be allowed, or the RIPE NCC could create a CA to issue certificates to non-LIRs for this purpose only. Below is an example of a maintainer with X.509 authentication: mntner: EXAMPLE-MNT descr: Sample maintainer for example. admin-c: SWK1-RIPE tech-c: RD132-RIPE tech-c: HOHO-RIPE upd-to: ripe-dbm(a)ripe.net mnt-nfy: ripe-dbm(a)ripe.net auth: X509 C=NL, O=RIPE NCC, OU=Members, CN=zz.example.user1 auth: X509 C=NL, O=RIPE NCC, OU=Members, CN=zz.example.user2 notify: ripe-dbm(a)ripe.net mnt-by: EXAMPLE-MNT referral-by: RIPE-DBM-MNT changed: ripe-dbm(a)ripe.net 20030813 source: RIPE Usage: E-mail updates for objects maintained by a maintainer with X509 authentication must be sent in S/MIME format and signed (not encrypted) using the private key associated with the issued certificate. Synchronous updates for objects maintained by a maintainer with X509 authentication must use an SSL connection using the private key from the issued certificate on the client side. Web updates for objects maintained by a maintainer with X509 authentication can use a browser with the certificate loaded. The web updates screens will allow users to specify that they want to identify themselves using the client-side private key, over an SSL connection.

3 3

Draft: "status:" re-evaluation
by Shane Kerr 15 Aug '03

15 Aug '03

All, We recently proposed changes to the "status:" attribute values in the RIPE Database: http://www.ripe.net/ripe/draft-documents/status-attributes.html We have received input from APNIC on the subject. They proposed a simpler layout, and we think their suggestion makes sense. However, we would like to go forward with a slightly modified version that incorporates the "organisation" object we are working on. In the meantime, we do not want to delay the implementation of the Sub-Allocation policy. For that reason we'd like to have an interim status attribute value for that. Proposal: Add "SUB-ALLOCATED PA" to the allowed "status:" values. "SUB-ALLOCATED PA" inetnum object may have an "ALLOCATED PA" or an "LIR-PARTITIONED PA" less specific inetnum object. A range of IP's can only have a single "SUB-ALLOCATED PA" in it. That is, you cannot sub-allocate twice. -- Shane Kerr RIPE NCC

6 9

RIPE Whois Server version 3.2.0
by DB-News 14 Aug '03

14 Aug '03

Dear Colleagues, [ Apologies for multiple messages. ] The RIPE NCC is pleased to announce the release of version 3.2.0 of the RIPE Whois server. This software is compliant with both RPSL (RFC-2622) and RPS-Security (RFC-2725). This release adds several user-visible improvements: - dbupdate has been rewritten almost from scratch - the server now limits the number of concurrent connections per IP - transaction support is added on MySQL side - query parsing is revised Detailed release notes can be found at the following URL: ftp://ftp.ripe.net/ripe/dbase/software/RELEASE-NOTES-3.2.0 You can download this release by anonymous FTP from the following URL: ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-3.2.0.tar.gz If you have any questions, please don't hesitate to contact <ripe-dbm(a)ripe.net>. Best regards, Engin Gunduz RIPE NCC Database Group

5 6

Announcement Routing Registry Training Course
by RIPE NCC Training 13 Aug '03

13 Aug '03

------- Apologies for the previous mail as there was an error in mentioned dates. Please find the correct dates in this mail. **** Dear Colleagues, [apologies for duplicate postings] As a service to its members the RIPE NCC offers the "Routing Registry Training Course". The main objective of the "Routing Registry Training Course" is to familiarise the LIRs with the features of the Routing Registry, while introducing the relevant tools and services of the RIPE NCC. The course also offers practical exercises. OVERVIEW OF TOPICS COVERED IN THE COURSE: - Routing Registry as a part of the RIPE Whois Database and the Internet Routing Registry (IRR) - Specifying routing policies using (RPSL) Routing Policy Specification Language and the RtConfig tool - IRRToolSet - Routing Information Service (RIS) - Routing Registry Consistency Check Project Please note that this is an advanced course. It will: - NOT teach the basics of routing - NOT teach the basics of RIPE Database operations, - NOT describe how to receive Internet resources from the RIPE NCC - NOT describe how to operate a Local Internet Registry (LIR) The target audience of the course are technical staff of LIRs: e.g. network operators, engineers etc. This course is not intended for administrative or management staff (e.g. Hostmasters) . It is assumed that all attendees will be familiar with Border Gateway Protocol routing and with the RIPE Database (i.e. creating/modifying objects). This course is based on interactive exercises in a local network set-up. Please bring your laptops equipped with the following: - A working Ethernet card, - Three meters of Ethernet cable, - A secure connection client, - A web browser. Please be prepared to share your laptop (or at least allow another attendee to "look over your shoulder") if necessary. The Routing Registry Training Course is conducted in the English language and is free of charge, since it is covered by the membership fee. More information about the Routing Registry Training Course can be found at: http://www.ripe.net/training/rr/ REGISTRATION: You can register for a Routing Registry Training Course at the following URL: http://www.ripe.net/cgi-bin/trainingform.pl.cgi Or by completing the registration form at the end of this e-mail and replying to <training(a)ripe.net> . In order to register for a Routing Registry Training Course you must be an employee of an LIR and either: - be an LIR contact - be confirmed by an LIR contact LIR contacts are those employees of an LIR who are registered with RIPE NCC as authoritative contact persons. It is expected that most of those interested in the Routing Registry Training Course will not be an authoritative contact person for their LIR, and therefore will be, refused by the course registration "robot". In order to be admitted to the course, a confirmation e-mail must be sent to <training(a)ripe.net>. Please approach the LIR contacts from your organisation personally, since the identity of LIR contacts is confidential, and the RIPE NCC is unable to divulge contact persons for any given LIR. Kind Regards, The RIPE NCC Training Team ************************************************************************* COURSE DATES AND VENUES ======================== Date: Friday 29 Augustus 2003 Time: 0900 - 1700 Location: Helsinki, Finland AND: Date: Monday 8 September 2003 Time: 0930 - 1700 Location: Amsterdam, The Netherlands AND: Date: Tuesday 21 October 2003 Time: 0900 - 1700 Location: Geneva, Switzerland AND: Date: Friday 14 November 2003 Time: 0900 - 1700 Location: Paris, France AND: Date: Friday 28 November 2003 Time: 0900 - 1700 Location: Moscow, Russia AND: Date: Friday 12 December 2003 Time: 0900 - 1700 Location: Lisbon, Portugal ************************************************************************* REGISTRATION FORM ================= %START PART 1 - Registration 1) Your name Enter First name, Last name in full e.g. John Doe Mary-Beth Walton # NAME [ ] 2) Your Registry ID (format: country-code.<name of registry>) # REG [ ] 3) Your e-mail address # EMAIL [ ] 4) Your NIC handle (optional) # NICHANDLE [ ] 5) The course you plan to attend (date and location) # COURSE [ ] %END

1 0

mnt-routes attribute in aut-num objects
by Frank Bohnsack 07 Aug '03

07 Aug '03

Dear Colleagues, how exactly is this meaning of MNT-ROUTES in AUT-NUM objects in case of routes object creation/modification ? RFC2725 is not realy detailed here. Means the existance of an MNT-ROUTES attribute in an AUT-NUM object that ONLY this/these referenced maintainer(s) will be able to authorized route creation/modification and the referenced MNT-BY maintainer(s) will not be used? Or should not the MNT-BY maintainer(s) checked if all MNT-ROUTES maintainer(s) authorisation fails? The current RIPE software checks MNT-ROUTES maintainers only. Thanks Frank > > From: "Frank Bohnsack" <Frank.Bohnsack(a)deu.mci.com> > > Subject: LONGACK > > Date: Mon, 4 Aug 2003 23:42:06 +0200 > > Reply-To: Frank.Bohnsack(a)deu.mci.com > > Message-ID: <FAEKJBKGENGFILMMECELOEHICAAA.Frank.Bohnsack(a)deu.mci.com> > > ... > > DETAILED EXPLANATION: > > > ***Warning: Invalid keyword(s) found: LONGACK > ***Warning: All keywords were ignored > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > The following object(s) were found to have ERRORS: > > > --- > Create FAILED: [route] 139.8.32.0/24AS702 > ***Error: Authorisation failed > ***Info: Syntax check passed > > route: 139.8.32.0/24 > descr: DE PI route > origin: AS702 > member-of: AS702:RS-DE, > AS702:RS-DE-PI, > AS702:RS-DE-PULLUP > mnt-by: WCOM-EMEA-RICE-MNT > changed: rice(a)lists.mci.com 20030804 > source: RIPE > > ***Info: Authorisation for parent [route] 139.8.0.0/16AS702 > using mnt-by: > authenticated by: WCOM-EMEA-RICE-MNT > > ***Info: Authorisation for origin [aut-num] AS702 > using mnt-routes: > not authenticated by: UUNETDK-MNT, AS1270-MNT, AS1849-MNT, > AS1890-MNT, IWAY-NOC, AS702-MNT, SE-UUNET-MNT, UUNETDE-I > > ***Info: Authorisation for [route] 139.8.32.0/24AS702 > using mnt-by: > authenticated by: WCOM-EMEA-RICE-MNT > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > For assistance or clarification please contact: > RIPE Database Administration <ripe-dbm(a)ripe.net> > > > >

2 1

Announcement on parent notifications
by Denis Walker 05 Aug '03

05 Aug '03

Colleagues, Notification on more-specific object creation authorisation ----------------------------------------------------------- The latest dbupdate binary to be put into production has implemented the change regarding parent notifications that was proposed to the Database Working Group in March 2003. This will cause some users to receive additional notifications. A summary of the change is outlined below. When the creation of an object requires authorisation by a less-specific object, normal notification rules apply to the mntner(s) in the less-specific object. In other words, "upd-to:" is notified of failure, and "mnt-nfy:" is notified of success. Where there are multiple maintainers, only one is needed to successfully authorise the creation, but all the maintainers in the list will be notified. For example: inetnum: 192.168.0.0 - 192.168.255.255 . . . mnt-by: EXAMPLE-MNT mnt-lower: ANOTHER-MNT mnt-lower: YET-ANOTHER-MNT If the successful creation of the more specific inetnum: inetnum: 192.168.201.0 - 192.168.201.255 . . . mnt-by: SOME-MNT Is authorised by YET-ANOTHER-MNT in the less specific inetnum, notifications will be sent to the "mnt-nfy:" listed in both ANOTHER-MNT and YET-ANOTHER-MNT in addition to the "mnt-nfy:" listed in SOME-MNT. In the case of route creation, the parent may be a route or an inetnum, and it may also be an exact match. Also notifications will also be sent to the mntner(s) listed in the origin aut-num of the route object being created. The original proposal can be found here: http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00034.html Regards Denis Walker Database Engineer RIPE NCC

1 0