From razvano at ripe.net Mon Jun 4 12:21:03 2007 From: razvano at ripe.net (Razvan Oprea) Date: Mon, 04 Jun 2007 12:21:03 +0200 Subject: [ncc-services-wg] LIR Portal ticketing system outage on 6 June Message-ID: <4663E78F.5090906@ripe.net> Dear Colleagues, The RIPE NCC will perform planned maintenance work on Wednesday, 6 June 2007 between 17:00 and 19:00 (UTC). During this period the RIPE NCC ticketing system will not be working, meaning that any changes in the status of open tickets will not be reflected in the LIR Portal. Any pending mails will be processed after the maintenance work has been completed. We apologise for any inconvenience that this may cause. If you have any questions about this, please send an e-mail to . Regards, Razvan Oprea Senior Systems Engineer RIPE NCC From razvano at ripe.net Mon Jun 4 12:21:03 2007 From: razvano at ripe.net (Razvan Oprea) Date: Mon, 04 Jun 2007 12:21:03 +0200 Subject: [ncc-services-wg] [ncc-announce] LIR Portal ticketing system outage on 6 June Message-ID: <4663E78F.5090906@ripe.net> Dear Colleagues, The RIPE NCC will perform planned maintenance work on Wednesday, 6 June 2007 between 17:00 and 19:00 (UTC). During this period the RIPE NCC ticketing system will not be working, meaning that any changes in the status of open tickets will not be reflected in the LIR Portal. Any pending mails will be processed after the maintenance work has been completed. We apologise for any inconvenience that this may cause. If you have any questions about this, please send an e-mail to . Regards, Razvan Oprea Senior Systems Engineer RIPE NCC From razvano at ripe.net Wed Jun 6 14:49:52 2007 From: razvano at ripe.net (Razvan Oprea) Date: Wed, 06 Jun 2007 14:49:52 +0200 Subject: [ncc-services-wg] Reminder: LIR Portal ticketing system outage on 6 June Message-ID: <4666AD70.3050603@ripe.net> Dear Colleagues, This is a reminder for the maintenance work being carried out tonight. The RIPE NCC will perform planned maintenance work on Wednesday, 6 June 2007 between 17:00 and 19:00 (UTC). During this period the RIPE NCC ticketing system will not be working, meaning that any changes in the status of open tickets will not be reflected in the LIR Portal. Any pending mails will be processed after the maintenance work has been completed. We apologise for any inconvenience that this may cause. If you have any questions about this, please send an e-mail to . Regards, Razvan Oprea Senior Systems Engineer RIPE NCC From razvano at ripe.net Wed Jun 6 14:49:52 2007 From: razvano at ripe.net (Razvan Oprea) Date: Wed, 06 Jun 2007 14:49:52 +0200 Subject: [ncc-services-wg] [ncc-announce] Reminder: LIR Portal ticketing system outage on 6 June Message-ID: <4666AD70.3050603@ripe.net> Dear Colleagues, This is a reminder for the maintenance work being carried out tonight. The RIPE NCC will perform planned maintenance work on Wednesday, 6 June 2007 between 17:00 and 19:00 (UTC). During this period the RIPE NCC ticketing system will not be working, meaning that any changes in the status of open tickets will not be reflected in the LIR Portal. Any pending mails will be processed after the maintenance work has been completed. We apologise for any inconvenience that this may cause. If you have any questions about this, please send an e-mail to . Regards, Razvan Oprea Senior Systems Engineer RIPE NCC From webmaster at ripe.net Thu Jun 7 11:22:58 2007 From: webmaster at ripe.net (RIPE NCC Document Announcement Service) Date: Thu, 07 Jun 2007 11:22:58 +0200 Subject: [ncc-services-wg] New RIPE Document available: RIPE-411 Message-ID: <20070607092258.1902A2F583@herring.ripe.net> A new RIPE Document is available from the RIPE Document store. Ref: ripe-411 Title: IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region Author: RIPE NCC Date: June 2007 Format: PDF=82,541 Obsoletes: ripe-405 This document describes the RIPE community?s current IPv4 address allocation and assignment policies. They were developed through a bottom-up, consensus driven, open policy development process in the RIPE Address Policy Working Group (AP WG). The RIPE Network Coordination Centre (RIPE NCC) facilitates and supports this process. These policies apply to the RIPE NCC and the Local Internet Registries (LIRs) within the RIPE NCC service region. You can find this document at: http://www.ripe.net/docs/ripe-411.html Regards RIPE NCC Webmaster From razvano at ripe.net Thu Jun 7 13:38:41 2007 From: razvano at ripe.net (Razvan Oprea) Date: Thu, 07 Jun 2007 13:38:41 +0200 Subject: [ncc-services-wg] LIR Portal ticketing system outage on June 12 Message-ID: <4667EE41.3040902@ripe.net> Dear Colleagues, The RIPE NCC will perform planned maintenance work on Tuesday, June 12, 2007 between 17:00 and 19:00 (UTC). Please note that this is a different maintenance task than the one successfully completed on June 6. During this period the RIPE NCC ticketing system will not be working, meaning that any changes in the status of open tickets will not be reflected in the LIR Portal. Any pending mails will be processed after the maintenance work has been completed. We apologise for any inconvenience that this may cause. If you have any questions about this, please send an e-mail to . Regards, Razvan Oprea Senior Systems Engineer RIPE NCC From markguz at ripe.net Mon Jun 18 14:54:53 2007 From: markguz at ripe.net (Mark Guz) Date: Mon, 18 Jun 2007 14:54:53 +0200 Subject: [ncc-services-wg] RIPE NCC Network Maintenance Wednesday 20 June 17:00 to 19:00 UTC/GMT Message-ID: <4676809D.8050105@ripe.net> [apologies for duplicates] Dear Colleagues, On Wednesday 20/06/2007, between 17:00 and 19:00 (UTC), the RIPE NCC will carry out planned maintenance work on our network infrastructure. This may result in brief interruptions to RIPE NCC services during the posted maintenance window. We apologise for any inconvenience that this may cause. This work is due to planned resilience testing of our network. If you have any questions about this, please send an e-mail to: ops at ripe.net . Regards Mark Guz Senior Engineer RIPE NCC From denis at ripe.net Thu Jun 21 14:41:41 2007 From: denis at ripe.net (Denis Walker) Date: Thu, 21 Jun 2007 14:41:41 +0200 Subject: [ncc-services-wg] Proposal - Maintaining person, role and domain objects Message-ID: <467A7205.7030504@ripe.net> [Apologies for duplicate mails] Dear Colleagues, As a result of discussions during the Database Working Group session at RIPE 54, the RIPE NCC has nine proposals and implementation plans to present to the community. Although most of them are now in the final stages of preparation, we will send them out one at a time over the next few weeks for consideration by the community. The first one concerns maintaining all objects in the RIPE Database, which followed from a recommendation from the Data Protection Task Force (DP TF) (see below). We have already had some preliminary discussions about this with the DP TF. They provided the RIPE NCC with some very useful feedback, which is incorporated in this proposal. Regards Denis Walker RIPE NCC Maintaining person, role and domain objects ------------------------------------------- * Introduction * Proposal * Illustrations of how the checks work - New startup - Closing down - Modifying existing data * Implementation - Stage 1 - Stage 2 - Stage 3 * Statistics Introduction ------------ It was agreed at RIPE 54 that the "mnt-by:" attribute would be made mandatory on all objects. Currently, for person, role and domain objects, "mnt-by:" is optional. Making "mnt-by:" mandatory on person objects raises two clear issues: 1. It creates a chicken and egg situation between person and mntner objects. 2. Many person objects are not changed for years, so any change to syntax may take a long time to be reflected in the database. Many un-maintained person objects could therefore remain so for many years. Proposal -------- Making "mnt-by:" mandatory on role and domain objects does not cause any technical difficulties. To address all the issues relating to the person objects, we suggest a slightly different approach. 1. Make "mnt-by:" mandatory in person objects. 2. Provide a mechanism in dbupdate to handle the startup case where a new person and mntner objects are required. 3. Provide a mechanism in dbupdate to handle the closing down situation where the last person and mntner objects are to be deleted. 4. Extend the referential integrity checks so that a person object cannot be referenced unless it is maintained, except in a mntner object. 5. Extend the referential integrity checks so that a mntner object cannot be referenced unless the person objects it references are maintained. This does not include the cyclic case of a person and mntner object referencing each other. The referencing checks sound complicated in words, but are actually quite simple. The illustrations below explain how it works in practice. This approach has a number of advantages: 1. It accommodates the chicken and egg situation. 2. We already do referential integrity checks. Whenever there is a reference to a person object, the database software checks if the person object exists. We only have to extend this check to see if the person object is also maintained. 3. Whenever there is a reference to a mntner object, the database software checks if the mntner object exists. We only have to extend this check to see if the person objects referenced by the mntner are maintained. 4. Each time any other object (say an inetnum or aut-num) is modified, the referenced person objects need to be maintained. If not, the update will fail. This will not prevent anyone from working. If they are going to modify an inetnum object, they must be authorised to do so. They can apply the same mntner to any un-maintained person objects. This encourages users to maintain the existing person objects. A CGI script may be provided to make this process simple and quick if it is considered to be helpful. 5. No un-maintained person object can be linked to the white pages to avoid deletion. (The white pages will be explained in a later proposal.) Illustrations of how the checks work ------------------------------------ New startup Send an update message to dbupdate to create a person object and a mntner object. These must be the first two objects in an update message, in any order. The references to each other must also be in place. The database software will accommodate this. person: Den is address: RIPE Network Coordination Centre (NCC) address: Singel 258 address: 1016 AB Amsterdam address: The Netherlands phone: +31 20 535 4444 nic-hdl: DW-RIPE mnt-by: aardvark-mnt notify: denis at ripe.net changed: denis at ripe.net 20040318 source: RIPE mntner: AARDVARK-MNT descr: Mntner for denis' objects. admin-c: DW-RIPE tech-c: DW-RIPE upd-to: denis at ripe.net auth: X509-1 notify: denis at ripe.net mnt-by: AARDVARK-MNT referral-by: RIPE-DBM-MNT changed: denis at ripe.net 20040225 source: RIPE The update software will recognise that the first person/mntner object references a non-existent mntner/person object. It will check that this referenced object is next in the update message. If it is, the "mnt- by:" attribute will be removed from the person object. The person and mntner objects will be created, and then the person object will be modified to add back the "mnt-by:" attribute. The objects are now fully configured and can be used. The person object can be referenced by any other object where a nic-hdl is referenced. It can also be linked to the white pages. The mntner can be used to protect any data in the database. If the non-existent referenced object is not next in the update message then an error message will be generated and the update will fail. This is the current behaviour. Closing down The same situation occurs when closing down and deleting all the data. It is possible to delete all data except for the last person and mntner objects in the normal way. To delete these last two, send them together in an update message, both marked with the "delete:" pseudo attribute. Only these two objects should be in the update message. The update software will recognise that the first person/mntner object to delete is referenced in a mntner/person object. It will check that this referencing object is next in the update message and also marked for deletion. If so the person object will be modified first to remove the "mnt-by:" attribute. The mntner object will then be deleted, followed by the person object. Modifying existing data Suppose some data is to be modified and there is a reference to an un- maintained person object. Suppose you already have this data in the database: inetnum: 193.0.0.0 - 193.0.7.255 netname: RIPE-NCC descr: RIPE Network Coordination Centre descr: Amsterdam, Netherlands remarks: Used for RIPE NCC infrastructure. country: NL admin-c: DW-RIPE tech-c: DW-RIPE status: ASSIGNED PI mnt-by: AARDVARK-MNT mnt-lower: AARDVARK-MNT changed: bit-bucket at ripe.net 20060221 source: RIPE person: Den is address: RIPE Network Coordination Centre (NCC) address: Singel 258 address: 1016 AB Amsterdam address: The Netherlands phone: +31 20 535 4444 nic-hdl: DW-RIPE notify: denis at ripe.net changed: denis at ripe.net 20040318 source: RIPE mntner: AARDVARK-MNT descr: Mntner for denis' objects. admin-c: DW-RIPE tech-c: DW-RIPE upd-to: denis at ripe.net auth: X509-1 notify: denis at ripe.net mnt-by: AARDVARK-MNT referral-by: RIPE-DBM-MNT changed: denis at ripe.net 20040225 source: RIPE The inetnum and mntner objects both reference a person object that is not maintained. This situation can continue for the foreseeable future with no problem. The situation becomes problematic when some data needs to be changed. An attempt to modify the inetnum object will fail. This is because it references a person object that is not maintained. It also references a mntner object which references un-maintained person objects. (This will only happen in stage three of the implementation) These person objects will have to be maintained before the inetnum object can be modified. A CGI script will be provided to allow this to be done quickly and easily. When all referenced person objects are maintained, the original update can be resubmitted and will proceed. Implementation As with the CRYPT-PW deprecation this will have a staged rollout. Stage 1 * No new person, role or domain objects can be created without a "mnt-by:" attribute. * Any un-maintained person, role or domain object cannot be modified without adding a "mnt-by:" attribute. * Any update where objects reference an un-maintained person object, either directly or through a mntner with such references, will generate a warning message in the acknowledgement. In this stage the acknowledgement message may include these warnings: ***WARNING: Un-maintained person object referenced [DW-RIPE] ***WARNING: Un-maintained person object referenced [DW-RIPE] in mntner [AARDVARK-MNT] Stage 2 * Any update where objects reference an un-maintained person object, either directly or through a mntner with such references, will generate a warning message in the acknowledgement. * Any NEW reference to an un-maintained person object or to a mntner which has such references will generate an error message in the acknowledgement and the update will fail. In this stage the acknowledgement message may include these warnings and errors: ***WARNING: Un-maintained person object referenced [DW-RIPE] ***WARNING: Un-maintained person object referenced [DW-RIPE] in mntner [AARDVARK-MNT] ***ERROR: New reference to un-maintained person object [DW-RIPE] ***ERROR: New reference to un-maintained person object [DW-RIPE] in mntner [AARDVARK-MNT] Stage 3 * Any update where objects reference an un-maintained person object, either directly or through a mntner with such references, will generate an error message in the acknowledgement and the update will fail. In this stage the acknowledgement message may include these errors: ***ERROR: Un-maintained person object referenced [DW-RIPE] ***ERROR: Un-maintained person object referenced [DW-RIPE] in mntner [AARDVARK-MNT] Statistics ---------- While not a very statistically valid survey, we looked at a few days just after the RIPE meeting to see how many new person objects were created with and without mntner objects. We also queried the new objects some time after creation to allow for a "mnt-by:" to be added later. We also noted how many unique person objects were referenced in any objects in update messages with and without mntner objects. AUTO- references were ignored in both creations and updates, and multiple instances of the same person object being referenced many times were counted as one. -------------------------------------------------------- | Date |Created |Created |Referenced |Referenced | | |with |without |with |without | |--------------------------------------------------------| | 20070515 | 156 | 89 | 925 | 726 | | 20070516 | 111 | 67 | 1022 | 486 | | 20070517 | 85 | 48 | 476 | 185 | | 20070518 | 82 | 18 | 679 | 445 | -------------------------------------------------------- From denis at ripe.net Thu Jun 21 17:04:52 2007 From: denis at ripe.net (Denis Walker) Date: Thu, 21 Jun 2007 17:04:52 +0200 Subject: [ncc-services-wg] Re: [db-wg] Proposal - Maintaining person, role and domain objects In-Reply-To: <467A86AC.2030504@ja.net> References: <467A7205.7030504@ripe.net> <467A86AC.2030504@ja.net> Message-ID: <467A9394.2040107@ripe.net> Hi Rodney These are very good questions. You are correct that there is a lot of legacy data that just sits there and may not be modified for years. Some of this will not be caught by any of these stages for a long time. The simple answer to your question 1 is that the RIPE NCC cannot decide on the time frame. That will have to come from the community. What we would like now is a consensus to move to stage 1. That will be a big step forward and require all new objects and any objects which are modified to be maintained. To go to stage 2 and 3 will have an impact on working practices. These involve maintaining referenced objects. So you may be prevented from making a change to an inetnum object because it references un-maintained person objects. In theory you should at least have a business relationship with these people. Otherwise why are they referenced from your data. But they may not be located physically in your office. So you will have to contact them and ask them to maintain their person object before you can modify the inetnum object. Or you just create a mntner, put it on the unreferenced person object and send the password to the person concerned. But these issues need time for people to think about and decide how they are going to handle the change. We can discuss this separately, on the mailing list or at RIPE 55, produce more statistics and then make a decision on a time frame to move to stages 2 and 3. For now lets focus on moving to stage 1. regards Denis RIPE NCC Rodney Tillotson wrote: > The proposal from Denis for moving towards assigning a mntner for all > person, role and domain objects seems to me very clear, and entirely > practicable to implement. Two questions: > > > 1. How will RIPE NCC decide when to move to the next stage? > > 2. I think it is logically possible for objects in a stagnant part of > the database to escape stages 1, 2 and 3 because they are rarely or > never involved in update traffic. > Have we any idea how large a collection of such objects will remain, > and might there be a stage 4 during which action is taken on them? > > > I suspect both questions depend on some more statistics. Some of them > will only become available as the transition goes on, and I do not > know how to design them anyway. > > Rodney Tillotson, JANET-CERT > +44 1235 822 255. > > > >> Stage 1 > >> > >> * No new person, role or domain objects can be created without a > >> "mnt-by:" attribute. > >> * Any un-maintained person, role or domain object cannot be > >> modified without adding a "mnt-by:" attribute. > >> * Any update where objects reference an un-maintained person > >> object, either directly or through a mntner with such > >> references, will generate a warning message in the > >> acknowledgement. > > >> Stage 2 > >> > >> * Any update where objects reference an un-maintained person > >> object, either directly or through a mntner with such > >> references, will generate a warning message in the > >> acknowledgement. > >> * Any NEW reference to an un-maintained person object or to a > >> mntner which has such references will generate an error message > >> in the acknowledgement and the update will fail. > > >> Stage 3 > >> > >> * Any update where objects reference an un-maintained person > >> object, either directly or through a mntner with such > >> references, will generate an error message in the > >> acknowledgement and the update will fail. > From rodney.tillotson at ja.net Thu Jun 21 16:09:48 2007 From: rodney.tillotson at ja.net (Rodney Tillotson) Date: Thu, 21 Jun 2007 15:09:48 +0100 Subject: [ncc-services-wg] Re: [db-wg] Proposal - Maintaining person, role and domain objects In-Reply-To: <467A7205.7030504@ripe.net> References: <467A7205.7030504@ripe.net> Message-ID: <467A86AC.2030504@ja.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The proposal from Denis for moving towards assigning a mntner for all person, role and domain objects seems to me very clear, and entirely practicable to implement. Two questions: 1. How will RIPE NCC decide when to move to the next stage? 2. I think it is logically possible for objects in a stagnant part of the database to escape stages 1, 2 and 3 because they are rarely or never involved in update traffic. Have we any idea how large a collection of such objects will remain, and might there be a stage 4 during which action is taken on them? I suspect both questions depend on some more statistics. Some of them will only become available as the transition goes on, and I do not know how to design them anyway. Rodney Tillotson, JANET-CERT +44 1235 822 255. > Stage 1 > > * No new person, role or domain objects can be created without a > "mnt-by:" attribute. > * Any un-maintained person, role or domain object cannot be > modified without adding a "mnt-by:" attribute. > * Any update where objects reference an un-maintained person > object, either directly or through a mntner with such > references, will generate a warning message in the > acknowledgement. > Stage 2 > > * Any update where objects reference an un-maintained person > object, either directly or through a mntner with such > references, will generate a warning message in the > acknowledgement. > * Any NEW reference to an un-maintained person object or to a > mntner which has such references will generate an error message > in the acknowledgement and the update will fail. > Stage 3 > > * Any update where objects reference an un-maintained person > object, either directly or through a mntner with such > references, will generate an error message in the > acknowledgement and the update will fail. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGeoZczHL8ns8C6+kRAr7pAKDT+FtlcGYvJsBXAJVuluLjJvROMACfThuW IEIgZFvjpzU6IRK5RlubDBs= =83pz -----END PGP SIGNATURE----- From Joao_Damas at isc.org Mon Jun 25 11:00:20 2007 From: Joao_Damas at isc.org (Joao Damas) Date: Mon, 25 Jun 2007 11:00:20 +0200 Subject: [ncc-services-wg] Re: [db-wg] Proposal - Maintaining person, role and domain objects In-Reply-To: <467A7205.7030504@ripe.net> References: <467A7205.7030504@ripe.net> Message-ID: <2C87FF7B-BA39-4D2D-B534-722115EF3B9B@isc.org> Stage 1 makes a lot of sense to me as it has little consequences to older data while it makes sure new information going into the DB has a better chance of being kept as originally posted by the object creator. The other stages do need a bit more discussion as they may in fact affect a lot of legacy data and have the potential to add a burden to LIR operations. I am in favour of those extra steps, just think that there is a need to repeat the warnings and announcements before and insist on people making an impact analysis on their operations. Joao Damas On 21 Jun 2007, at 14:41, Denis Walker wrote: > [Apologies for duplicate mails] > > Dear Colleagues, > > As a result of discussions during the Database Working Group > session at > RIPE 54, the RIPE NCC has nine proposals and implementation plans to > present to the community. Although most of them are now in the final > stages of preparation, we will send them out one at a time over the > next > few weeks for consideration by the community. > > The first one concerns maintaining all objects in the RIPE > Database, which > followed from a recommendation from the Data Protection Task Force > (DP TF) > (see below). We have already had some preliminary discussions about > this > with the DP TF. They provided the RIPE NCC with some very useful > feedback, > which is incorporated in this proposal. > > Regards > Denis Walker > RIPE NCC > > > > Maintaining person, role and domain objects > ------------------------------------------- > > * Introduction > * Proposal > * Illustrations of how the checks work > - New startup > - Closing down > - Modifying existing data > * Implementation > - Stage 1 > - Stage 2 > - Stage 3 > * Statistics > > > Introduction > ------------ > It was agreed at RIPE 54 that the "mnt-by:" attribute would be made > mandatory on all objects. Currently, for person, role and domain > objects, "mnt-by:" is optional. Making "mnt-by:" mandatory on person > objects raises two clear issues: > > 1. It creates a chicken and egg situation between person and mntner > objects. > 2. Many person objects are not changed for years, so any change to > syntax may take a long time to be reflected in the database. Many > un-maintained person objects could therefore remain so for many > years. > > Proposal > -------- > Making "mnt-by:" mandatory on role and domain objects does not cause > any technical difficulties. > > To address all the issues relating to the person objects, we suggest a > slightly different approach. > > 1. Make "mnt-by:" mandatory in person objects. > 2. Provide a mechanism in dbupdate to handle the startup case > where a > new person and mntner objects are required. > 3. Provide a mechanism in dbupdate to handle the closing down > situation where the last person and mntner objects are to be > deleted. > 4. Extend the referential integrity checks so that a person object > cannot be referenced unless it is maintained, except in a mntner > object. > 5. Extend the referential integrity checks so that a mntner object > cannot be referenced unless the person objects it references are > maintained. This does not include the cyclic case of a person and > mntner object referencing each other. > > The referencing checks sound complicated in words, but are actually > quite simple. The illustrations below explain how it works in > practice. > > This approach has a number of advantages: > > 1. It accommodates the chicken and egg situation. > 2. We already do referential integrity checks. Whenever there is a > reference to a person object, the database software checks if the > person object exists. We only have to extend this check to see if > the person object is also maintained. > 3. Whenever there is a reference to a mntner object, the database > software checks if the mntner object exists. We only have to > extend > this check to see if the person objects referenced by the mntner > are maintained. > 4. Each time any other object (say an inetnum or aut-num) is > modified, the referenced person objects need to be maintained. If > not, the update will fail. This will not prevent anyone from > working. > If they are going to modify an inetnum object, they must be > authorised > to do so. They can apply the same mntner to any un-maintained > person > objects. This encourages users to maintain the existing person > objects. A CGI script may be provided to make this process > simple and > quick if it is considered to be helpful. > 5. No un-maintained person object can be linked to the white > pages to > avoid deletion. (The white pages will be explained in a later > proposal.) > > > Illustrations of how the checks work > ------------------------------------ > > New startup > Send an update message to dbupdate to create a person object and a > mntner object. These must be the first two objects in an update > message, in any order. The references to each other must also be in > place. The database software will accommodate this. > > person: Den is > address: RIPE Network Coordination Centre (NCC) > address: Singel 258 > address: 1016 AB Amsterdam > address: The Netherlands > phone: +31 20 535 4444 > nic-hdl: DW-RIPE > mnt-by: aardvark-mnt > notify: denis at ripe.net > changed: denis at ripe.net 20040318 > source: RIPE > > mntner: AARDVARK-MNT > descr: Mntner for denis' objects. > admin-c: DW-RIPE > tech-c: DW-RIPE > upd-to: denis at ripe.net > auth: X509-1 > notify: denis at ripe.net > mnt-by: AARDVARK-MNT > referral-by: RIPE-DBM-MNT > changed: denis at ripe.net 20040225 > source: RIPE > > The update software will recognise that the first person/mntner object > references a non-existent mntner/person object. It will check that > this > referenced object is next in the update message. If it is, the "mnt- > by:" attribute will be removed from the person object. The person and > mntner objects will be created, and then the person object will be > modified to add back the "mnt-by:" attribute. > > The objects are now fully configured and can be used. The person > object > can be referenced by any other object where a nic-hdl is > referenced. It > can also be linked to the white pages. The mntner can be used to > protect any data in the database. > > If the non-existent referenced object is not next in the update > message > then an error message will be generated and the update will fail. This > is the current behaviour. > > > Closing down > The same situation occurs when closing down and deleting all the data. > It is possible to delete all data except for the last person and > mntner > objects in the normal way. To delete these last two, send them > together > in an update message, both marked with the "delete:" pseudo attribute. > Only these two objects should be in the update message. > > The update software will recognise that the first person/mntner object > to delete is referenced in a mntner/person object. It will check that > this referencing object is next in the update message and also marked > for deletion. If so the person object will be modified first to remove > the "mnt-by:" attribute. The mntner object will then be deleted, > followed by the person object. > > > Modifying existing data > Suppose some data is to be modified and there is a reference to an un- > maintained person object. > > Suppose you already have this data in the database: > > inetnum: 193.0.0.0 - 193.0.7.255 > netname: RIPE-NCC > descr: RIPE Network Coordination Centre > descr: Amsterdam, Netherlands > remarks: Used for RIPE NCC infrastructure. > country: NL > admin-c: DW-RIPE > tech-c: DW-RIPE > status: ASSIGNED PI > mnt-by: AARDVARK-MNT > mnt-lower: AARDVARK-MNT > changed: bit-bucket at ripe.net 20060221 > source: RIPE > > person: Den is > address: RIPE Network Coordination Centre (NCC) > address: Singel 258 > address: 1016 AB Amsterdam > address: The Netherlands > phone: +31 20 535 4444 > nic-hdl: DW-RIPE > notify: denis at ripe.net > changed: denis at ripe.net 20040318 > source: RIPE > > mntner: AARDVARK-MNT > descr: Mntner for denis' objects. > admin-c: DW-RIPE > tech-c: DW-RIPE > upd-to: denis at ripe.net > auth: X509-1 > notify: denis at ripe.net > mnt-by: AARDVARK-MNT > referral-by: RIPE-DBM-MNT > changed: denis at ripe.net 20040225 > source: RIPE > > The inetnum and mntner objects both reference a person object that is > not maintained. This situation can continue for the foreseeable future > with no problem. The situation becomes problematic when some data > needs > to be changed. > > An attempt to modify the inetnum object will fail. This is because it > references a person object that is not maintained. It also > references a > mntner object which references un-maintained person objects. (This > will > only happen in stage three of the implementation) > > These person objects will have to be maintained before the inetnum > object can be modified. A CGI script will be provided to allow this to > be done quickly and easily. > > When all referenced person objects are maintained, the original update > can be resubmitted and will proceed. > > > Implementation > As with the CRYPT-PW deprecation this will have a staged rollout. > > Stage 1 > > * No new person, role or domain objects can be created without a > "mnt-by:" attribute. > * Any un-maintained person, role or domain object cannot be modified > without adding a "mnt-by:" attribute. > * Any update where objects reference an un-maintained person object, > either directly or through a mntner with such references, will > generate a warning message in the acknowledgement. > > In this stage the acknowledgement message may include these warnings: > > ***WARNING: Un-maintained person object referenced [DW-RIPE] > ***WARNING: Un-maintained person object referenced [DW-RIPE] in > mntner [AARDVARK-MNT] > > Stage 2 > > * Any update where objects reference an un-maintained person object, > either directly or through a mntner with such references, will > generate a warning message in the acknowledgement. > * Any NEW reference to an un-maintained person object or to a mntner > which has such references will generate an error message in the > acknowledgement and the update will fail. > > In this stage the acknowledgement message may include these warnings > and errors: > > ***WARNING: Un-maintained person object referenced [DW-RIPE] > ***WARNING: Un-maintained person object referenced [DW-RIPE] in > mntner [AARDVARK-MNT] > ***ERROR: New reference to un-maintained person object [DW-RIPE] > ***ERROR: New reference to un-maintained person object [DW-RIPE] in > mntner [AARDVARK-MNT] > > Stage 3 > > * Any update where objects reference an un-maintained person object, > either directly or through a mntner with such references, will > generate an error message in the acknowledgement and the update > will fail. > > In this stage the acknowledgement message may include these errors: > > ***ERROR: Un-maintained person object referenced [DW-RIPE] > ***ERROR: Un-maintained person object referenced [DW-RIPE] in mntner > [AARDVARK-MNT] > > > Statistics > ---------- > While not a very statistically valid survey, we looked at a few days > just after the RIPE meeting to see how many new person objects were > created with and without mntner objects. We also queried the new > objects some time after creation to allow for a "mnt-by:" to be added > later. We also noted how many unique person objects were referenced in > any objects in update messages with and without mntner objects. AUTO- > references were ignored in both creations and updates, and multiple > instances of the same person object being referenced many times were > counted as one. > > -------------------------------------------------------- > | Date |Created |Created |Referenced |Referenced | > | |with |without |with |without | > |--------------------------------------------------------| > | 20070515 | 156 | 89 | 925 | 726 | > | 20070516 | 111 | 67 | 1022 | 486 | > | 20070517 | 85 | 48 | 476 | 185 | > | 20070518 | 82 | 18 | 679 | 445 | > -------------------------------------------------------- > From denis_on_vacation at yahoo.co.uk Tue Jun 26 09:23:34 2007 From: denis_on_vacation at yahoo.co.uk (Denis W) Date: Tue, 26 Jun 2007 08:23:34 +0100 (BST) Subject: [ncc-services-wg] Re: db-wg digest, Vol 1 #520 - 1 msg In-Reply-To: <20070625100003.10716.74177.Mailman@postboy.ripe.net> Message-ID: <20070626072334.52942.qmail@web27211.mail.ukl.yahoo.com> Hi Joao I agree. So lets focus first on a consensus for stage 1. Then we can start work on that while we continue discussions on the other stages and the impacts they will have on work flow of LIRs. regards Denis RIPE NCC Cc: Database WG , ncc-services-wg From: Joao Damas Subject: Re: [db-wg] Proposal - Maintaining person, role and domain objects Date: Mon, 25 Jun 2007 11:00:20 +0200 To: Denis Walker Stage 1 makes a lot of sense to me as it has little consequences to older data while it makes sure new information going into the DB has a better chance of being kept as originally posted by the object creator. The other stages do need a bit more discussion as they may in fact affect a lot of legacy data and have the potential to add a burden to LIR operations. I am in favour of those extra steps, just think that there is a need to repeat the warnings and announcements before and insist on people making an impact analysis on their operations. Joao Damas On 21 Jun 2007, at 14:41, Denis Walker wrote: > [Apologies for duplicate mails] > > Dear Colleagues, > > As a result of discussions during the Database Working Group > session at > RIPE 54, the RIPE NCC has nine proposals and implementation plans to > present to the community. Although most of them are now in the final > stages of preparation, we will send them out one at a time over the > next > few weeks for consideration by the community. > > The first one concerns maintaining all objects in the RIPE > Database, which > followed from a recommendation from the Data Protection Task Force > (DP TF) > (see below). We have already had some preliminary discussions about > this > with the DP TF. They provided the RIPE NCC with some very useful > feedback, > which is incorporated in this proposal. > > Regards > Denis Walker > RIPE NCC > > > > Maintaining person, role and domain objects > ------------------------------------------- > > > Implementation > As with the CRYPT-PW deprecation this will have a staged rollout. > > Stage 1 > > * No new person, role or domain objects can be created without a > "mnt-by:" attribute. > * Any un-maintained person, role or domain object cannot be modified > without adding a "mnt-by:" attribute. > * Any update where objects reference an un-maintained person object, > either directly or through a mntner with such references, will > generate a warning message in the acknowledgement. > > In this stage the acknowledgement message may include these warnings: > > ***WARNING: Un-maintained person object referenced [DW-RIPE] > ***WARNING: Un-maintained person object referenced [DW-RIPE] in > mntner [AARDVARK-MNT] > > Stage 2 > > * Any update where objects reference an un-maintained person object, > either directly or through a mntner with such references, will > generate a warning message in the acknowledgement. > * Any NEW reference to an un-maintained person object or to a mntner > which has such references will generate an error message in the > acknowledgement and the update will fail. > > In this stage the acknowledgement message may include these warnings > and errors: > > ***WARNING: Un-maintained person object referenced [DW-RIPE] > ***WARNING: Un-maintained person object referenced [DW-RIPE] in > mntner [AARDVARK-MNT] > ***ERROR: New reference to un-maintained person object [DW-RIPE] > ***ERROR: New reference to un-maintained person object [DW-RIPE] in > mntner [AARDVARK-MNT] > > Stage 3 > > * Any update where objects reference an un-maintained person object, > either directly or through a mntner with such references, will > generate an error message in the acknowledgement and the update > will fail. > > In this stage the acknowledgement message may include these errors: > > ***ERROR: Un-maintained person object referenced [DW-RIPE] > ***ERROR: Un-maintained person object referenced [DW-RIPE] in mntner > [AARDVARK-MNT] > > > Statistics > ---------- > While not a very statistically valid survey, we looked at a few days > just after the RIPE meeting to see how many new person objects were > created with and without mntner objects. We also queried the new > objects some time after creation to allow for a "mnt-by:" to be added > later. We also noted how many unique person objects were referenced in > any objects in update messages with and without mntner objects. AUTO- > references were ignored in both creations and updates, and multiple > instances of the same person object being referenced many times were > counted as one. > > -------------------------------------------------------- > | Date |Created |Created |Referenced |Referenced | > | |with |without |with |without | > |--------------------------------------------------------| > | 20070515 | 156 | 89 | 925 | 726 | > | 20070516 | 111 | 67 | 1022 | 486 | > | 20070517 | 85 | 48 | 476 | 185 | > | 20070518 | 82 | 18 | 679 | 445 | > -------------------------------------------------------- > End of db-wg Digest --------------------------------- New Yahoo! Mail is the ultimate force in competitive emailing. Find out more at the Yahoo! Mail Championships. Plus: play games and win prizes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eromijn at ripe.net Thu Jun 28 14:05:19 2007 From: eromijn at ripe.net (Erik Romijn) Date: Thu, 28 Jun 2007 14:05:19 +0200 Subject: [ncc-services-wg] RIS maintenance announcement: 4 July 2007 Message-ID: [Apologies for duplicates] Dear Colleagues, On Wednesday, 4 July 2007, we will conduct planned maintenance on the Routing Information Service (RIS). This will involve a memory test on our collector connected to LINX (rrc01). Between 17:00 and 19:00 (UTC), we will reboot the collector to run an offline memory test. During this test, the collector will not collect data and the looking glass for this collector will not be available. We thank you for your patience and apologise for any inconvenience this may cause. If you have any questions about this work, please send an e-mail to . Regards, Erik Romijn Information Services RIPE NCC From agoston at ripe.net Fri Jun 29 12:34:09 2007 From: agoston at ripe.net (Agoston Horvath) Date: Fri, 29 Jun 2007 12:34:09 +0200 Subject: [ncc-services-wg] RIPE DB not accessible over IPv6 Message-ID: <4684E021.6060505@ripe.net> Dear Colleagues, >From 11:12 on 29 June 2007, the RIPE Database is not able to respond to queries over IPv6. All other services (updates, queries over IPv4) are unaffected. This problem is due to a firewall-related issue in our Juniper routers. We apologise for any inconvenience. If you have any questions or concerns about this, please contact us at: Regards, Agoston Horvath Database Group RIPE NCC