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/db-wg@ripe.net/
[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 ]