This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[db-wg] Proposed Change 2004.2: Removal of "referral-by:" Attribute
- Previous message (by thread): [db-wg] ANNOUNCEMENT: "auth:" Attribute is Now Searchable
- Next message (by thread): [db-wg] Delay in mailed updates to Database
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Engin Gunduz
engin at ripe.net
Mon Jun 14 17:34:52 CEST 2004
Dear Colleagues, This is a proposed change to improve the content of the RIPE Database. Please review and let us know if you have any comments. [2004.2] Removal of "referral-by:" Attribute from the MNTNER Object ------------------------------------------------------------------- Change: Remove the "referral-by:" attribute from the MNTNER objects' schema. This attribute is currently a mandatory attribute for MNTNER objects. The RIPE NCC will also remove this attribute from all existing MNTNER objects in the RIPE Whois Database. Motivation: The "referral-by:" attribute was introduced into MNTNER objects when the RIPE Whois Database was transitioning from version 2 whois software to version 3, which implements RFC2622 (RPSL) and RFC2725 (RPS Security). "referral-by:" is defined in RFC2725: ============== referral-by This attribute is required in the maintainer object. It may never be altered after the addition of the maintainer. This attribute refers to the maintainer that created this maintainer. It may be multiple if more than one signature appeared on the transaction creating the object. auth-override An auth-override attribute can be added, deleted, or changed by a transaction submitted by maintainer listed in the referral-by. An auth-override can only be added to a maintainer if that maintainer has been inactive for the prior 60 days. The auth-override attribute itself contains only the date when the attribute will go into effect which must be at least 60 days from the current date unless there is already authorization to modify the maintainer. After the date in the auth-override is reached, those identified by the maintainer in the referral-by have authorization to modify the maintainer. This attribute exists as a means to clean up should the holder of a maintainer become unresponsive and can only take effect if that maintainer does not remove the auth-override in response to the automatic notification that occurs on changes. The existing "mnt-by" attribute references the "maintainer" object type. The "mnt-by" attribute is now mandatory in all object types. A new maintainer may be added by any existing maintainer. The "referral-by" attribute is now mandatory in the "maintainer" object to keep a record of which maintainer made the addition and can never be changed. Maintainers cannot be deleted as long as they are referenced by a "referral-by" attribute elsewhere. ============== The RIPE NCC introduced the "referral-by:" attribute as a place-holder, without implementing its functionality. It was thought that the attribute would be useful in the future and make it as compatible as possible with RFC2622 and RFC2725. However, it is now clear that an attribute that is not currently used (and with no plans to use it in the near future) is confusing for the database users. It can easily be re-introduced if the need arises. Regards, Engin Gunduz RIPE NCC Software Engineering Department References: [RFC2622] Routing Policy Specification Language (RPSL) ftp://ftp.ripe.net/rfc/rfc2622.txt [RFC2725] Routing Policy System Security ftp://ftp.ripe.net/rfc/rfc2725.txt
- Previous message (by thread): [db-wg] ANNOUNCEMENT: "auth:" Attribute is Now Searchable
- Next message (by thread): [db-wg] Delay in mailed updates to Database
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]