Adding nic handles to contact objects without one (72 chars/line)
Thou shall not send vi docs directly on a mail! At people's request here goes the mail again with sorter lines. Regards, Joao ------- Include message ------ Dear all, During the month of February the RIPE NCC, at the RIPE Database working group's request after the RIPE 32 meeting in Amsterdam, put out a proposal to add automatically generated nic handles to existing person objects that do not currently have one. Some other unrelated issues have caused me to not follow this up appropriately. I am sorry for that. In order to resume (and hopefully swiftly conclude) this issue, I will use the rest of this message to summarize the state of discussions. I would like to ask for a 10 day discussion period after which I will summarize the conclusion to the list and have the Database group take whatever action is agreed to. Summary: The initial proposal called just for the addition of an automatically generated nic handle to person and role objects which currently do not have one. This would be done using the same automatic procedure used by the Database software when a user request an AUTO nic handle. That is, the database takes up to 4 initials from the name, looks for the highest exisiting number of a nic handle in the sequence of nic handles with the same initials, generates a new number and adds the suffix "-RIPE". Input received discussed if we should use the opportunity and try to modify some database objects that reference person and role objects by name instead of nic handle as is required now in the RIPE Database. These are two separate issues. The first one could be approved without the second one. The first one alone brings old objects up to date to current specifications, simplifies the prorammers life and enables further steps to increase the DB's consistency. In my personal opinion it is a Good Thing. The main advantage of the second part is that: - References by nic handle are less ambiguous than references by name since the DB ensures that there are no duplicate nic handles whereas there is no reason why two persons can't have the same name. (Note: currently there are around 30 duplicate nic handles in the RIPE DB due to legacy objects from the past and bugs in past releases of the software. This problem is being addressed in the context of the RIPE DB consistency project. There will be an extensive report on the progress of this project in the coming RIPE meeting in Vienna). Doing this doesn't solve all the problems, naturally, and may have some problems as itemized below: - If the reference by name is to a name for which more than one object exists then there is an ambiguity that can't be handled automatically. The solution to this requires intervention by the referencing object's owner. This will be handled by the DB consistency project. - If there is no object with the referenced name then the referencing object is at least partially orphaned. This issue will also be addressed by the DB consistency project and may eventually need further policy decisions in the future, to be discussed by the community. - There is a chance that a person/role object with a refenced name exists and is unique but is not the one that created the referencing object. Eg. if I created an inetnum object in 1991 but then deleted my person object and then my twin ghost registered in the DB and created some new objects: should the original inetnum object (still in the database) be linked to my twin ghost (who probably doesn't know anything about it)? If this issue is seen as a heavy one then no name references can be modified to references by NIC handle automatically, unless an exhaustive search of the DB update logs is performed (and even then, there is no guaranteed result). I think this summarizes the state of affairs. Please give your input as soon as possible so that a conclusion can be reached. If possible, address the original and the extension proposal separately. Thanks, Joao Damas RIPE DB Group Manager RIPE NCC
Joao Luis Silva Damas writes:
- If there is no object with the referenced name then the referencing object is at least partially orphaned. This issue will also be addressed by the DB consistency project and may eventually need further policy decisions in the future, to be discussed by the community.
Since I was thinking about the orphaned object problem for quite some time and just forgot to bring up the topic in January I might just jump in here. I'd propose a machine generated ``orphan'' timestamp on each person object. This would allow to kick out all orphaned objects after a certain grace period (maybe 6 month), which probably will get rid of quite a number of person objects no longer needed. A machine generated ``orphan'' timestamp is different from a machine generated change timestamp in that the change timestamp only gets updated whenever the object itself is changed whereas the ``orphan'' timestamp get set whenever the link counter is reduced to 0, i.e. the object becomes orphaned. This would greatly enhance DB house cleaning, since very few people seem to remove or even to worry about their orphaned objects. The grace period of 6 month (just as a suggestion) gives plenty of time to introduce a new person object an then have the national NIC delegate a domain and create the referencing domain object. I can think of several ways to implement an ``orphan'' timestamp--it doesn't nessecarily need to be a real _timestamp_, it might be a count down timer of some sort, which would even allow reducing its size. -- Ulf Kieber email: kieber@ga-telecom.net Network Engineer voice: +49-69-299896-21 Global Access Telecommunications, Inc. fax : +49-69-299896-66 internet solutions for business www : www.ga-telecom.net
On Fri, 16 Apr 1999, Ulf Kieber wrote: kieber> I'd propose a machine generated ``orphan'' timestamp on each person kieber> object. This would allow to kick out all orphaned objects after a kieber> certain grace period (maybe 6 month), which probably will get rid of kieber> quite a number of person objects no longer needed. kieber> I can think of several ways to implement an ``orphan'' timestamp--it kieber> doesn't nessecarily need to be a real _timestamp_, it might be a count kieber> down timer of some sort, which would even allow reducing its size. The following is a generic solution, and could be applied by the database when an object is found to be 'orphaned'. -- Bruce Campbell <bruce.campbell@apnic.net> +61-7-3367-0490 Systems Administrator (#2) Regional Internet Registry Asia Pacific Network Information Centre For the Asia Pacific Region Proposal: The addition of an 'expire:' field which sets out a time when the database will send a reminder notice to the listed contacts/notify requesting continuing confirmation of the object's existence, and indirectly checking the validity of the contacts supplied. I see the primary use of this as being for objects (inetnums/as/domains) describing assignments by LIRs to their customers, setting a time when a contract between the two expires (or two weeks after, the exact usage/timing of the field would be left up to the member). Specifics: expire: action date [frequency] (optional, multiple) Multiple occurences of this field may be present. -- 'Action' is one of: 'notify': Send a message to the address in the notify field, and also to the admin-c address(es) advising of the existence of the object and a copy thereof. Primary use of this would be to advise of the objects existence with a view to making sure that the details are still correct, and only makes sense if the optional frequency subfield is also set. 'delete': Send a message to the address in the notify field, and also to the admin-c address(es) advising of the impending deletion of the object (in 14 days, this being a global database setting in ripedb.conf) unless further information is forthcoming, and a copy of the object. Primary use of this would be to ensure the validity of database information in the event of a short-term, but possibly ongoing assignment. For security reasons, if the object is protected by a maintainer, the 'do not delete this object' response should be authorised as set out by the maintainer. The same applies to sending messages out if (for example) pgp encrpytion of messages is enabled. -- 'Date' is an standard date string in the same format of the 'changed:' attribute which outlines the base date from which the above recurring times are calculated, or the date on which once-only action occurs. This would be reset by the database if required. (Note: maybe add another 'changed' attribute implying when the expire attribute was first set on that object, providing a bit of history on when the object (or the contract it possibly represents) was created?) -- 'Frequency' is an optional field containing either the string 'once' (meaning that the action happens once only, this is the default if 'frequency' is not specified) or a recurring time interval (signified by '+'), expressed in days, months or years, eg: '+30d': The action occurs every 30 days. '+1m': The action occurs every month (on the same date). '+1y': The action occurs every year (on the same date). More complicated expressions could be added (eg, 3rdMonday for the 3rd Monday of each month), although this might be seen as making this functionality of the database a large calender routine. -- A 'grace' period of warning before an object is deleted can be enacted by using multiple 'expire:' fields, one being an 'expire: notify' with a date one month before the following 'expire: delete' field. It would be expected that the database would (in the notify message), outline any other expire events, such as a recurring notify, or an immenient delete action. --
participants (3)
-
Bruce Campbell -
Joao Luis Silva Damas -
kieber＠ga-telecom.net