[db-wg] summary of organisation object discussions

Dear Colleagues,

I'd like to summarise the discussions took place in the last 
two weeks in the working group mailing lists after the 
publication of the organisation object proposal
( http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00159.html )
and after the presentation in the DB-WG session last week
in RIPE 46 Meeting ( http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-db-organisation_object.pdf ).


1. "org:" attribute mandatory or optional in aut-num objects?
   The proposal mentioned above specified "org:" attribute in
   aut-num objects to be mandatory. However, often LIRs request
   an ASN for their customers and the RIPE NCC does not have
   enough information for them to fill in an organisation object
   completely. Rather than putting invalid information on the
   whois database, the RIPE NCC thinks it is better to make "org:"
   attribute optional in aut-nums.

2. "org:" attribute multi- or single-valued?
   The proposal specified "org:" attribute single-valued in all
   objects. During the discussions in the DB WG, commentors from
   the audience stated that in some cases a person object works for
   more than one companies, thus one might want to put multiple
   "org:" attributes in his/her person object. Similar reasoning could apply
   to other object types as well. However, the "org:" object specifies
   the holder of an Internet resource in inetnum, inet6num and aut-num
   objects, thus it must be single-valued in these objects. For the
   rest of the objects, we propose to modify the rule so it can be multi-valued.

3. addition of "mnt-ref:" attribute.
   The proposal suggested the use of "mnt-by:" attribute for both
   authorisation of modification of the organisation object and
   the authorisation of adding a reference to the organisation object
   from other objects. This has a shortcoming when the organisation
   object is protected by an entity other than the organisation
   itself (for example, an LIR, whose organisation object is protected
   by the RIPE NCC). We would propose to introduce mandatory "mnt-ref:"
   attribute to control the references to the organisation object, while
   "mnt-by:" protects the organisation object itself, as usual.

4. "org:" attribute in the organisation object itself.
   The proposal suggested the use of "org:" attribute in non-organisation
   objects. I think it could be used in organisation objects as well,
   to indicate business relations like being a dependent company to
   another one. 
   
5. "business-id:" attribute.
   It was suggested to add an attribute to specify the national organisation
   number or VAT number or a similar ID of the organisation. While we see
   the point in this, we feel it needs some more discussion. It can be
   added to the organisation object after its introduction.

6. changing the meaning of '-r' flag.
   The proposal suggested that, when a query returns an object with an
   "org:" attribute, the organisation objects mentioned in this attribute
   be appended to the query results. This behaviour can be changed by
   using '-r' flag in the query.
   This idea was based on the fact that the "org:" attribute is at least
   as relevant to the resource as the "admin-c:", "tech-c:" and "zone-c:"
   attributes as contact information. Thus, if we return person/role
   objects mentioned in the query results, we should also return the organisation
   objects. Basically, the proposed behaviour maintains the consistency.
   During the discussions it was proposed to change the default behaviour
   of whois server, and change the meaning of '-r' flag, so that
     - the server does not 'expand' "admin-c:", "tech-c:" and "zone-c:"
       attributes, nor "org:" attribute by default,
     - and it expands them only when '-r' flag is used.
   This can separately be discussed, however, I think this is out of
   the scope of organisation object. 

I hope I did not miss any other issues.

If these points are OK, we will prepare another proposal for organisation
object and publish it.

Best regards,
-- 
Engin Gunduz
RIPE NCC Database Group