[db-wg] Proposal - Maintaining person, role and domain objects
- Previous message (by thread): [db-wg] Proposal - Maintaining person, role and domain objects
- Next message (by thread): [db-wg] "-c" flag to become default in RIPE Database server
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Joao Damas
Joao_Damas at isc.org
Mon Jun 25 11:00:20 CEST 2007
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 | > -------------------------------------------------------- >
- Previous message (by thread): [db-wg] Proposal - Maintaining person, role and domain objects
- Next message (by thread): [db-wg] "-c" flag to become default in RIPE Database server
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]