[appologies for cross-posting this] Hi all, Maybe I missed out on something, but accoording to various templates in the ripe-databese, the org-attribute is optional. Apparently the hostmaster mailrobot things otherwise and refuses requests with an error because of the org-attribute not being present. I just ran into it on a ASN request, but I recall having problems before with this. Can anybody tell me who is right, the database template or the robot ? In fact, the database reference (http://www.ripe.net/ripe/docs/databaseref-manual.html#1.2.3) doesn't list it all. Grtx, MarcoH
Marco, MarcoH wrote:
Maybe I missed out on something, but accoording to various templates in the ripe-databese, the org-attribute is optional. Apparently the hostmaster mailrobot things otherwise and refuses requests with an error because of the org-attribute not being present. I just ran into it on a ASN request, but I recall having problems before with this.
Can anybody tell me who is right, the database template or the robot ? In fact, the database reference (http://www.ripe.net/ripe/docs/databaseref-manual.html#1.2.3) doesn't list it all.
There are two different sets of rules here. The first is for the database: in the case of AUT-NUM objects, the "org:" attribute is optional. This allows AUT-NUM objects that have been assigned before the ORGANISATION class was added to exist, without references to dummy or incorrect objects. We can make "org:" mandatory in AUT-NUM objects. We have made other attributes mandatory in the past, without updating existing objects. This means that old AUT-NUM objects would not be fixed, but any modified objects must have an "org:". Our experience is that this discourages people from updating these objects, so some of them become less accurate, because people do not bother to fix them. The second set of rules is for the resource request process: in the case of ASN requests, we need to know which organisation will be using the ASN. This information is published in the resulting AUT-NUM object, so from this point of view it is a required attribute. Essentially, the database syntax can see seen as a sub-set of the business requirements for assigning an ASN. -- Shane Kerr RIPE NCC
On Wed, Jul 13, 2005 at 06:11:28PM +0200, Shane Kerr wrote:
There are two different sets of rules here.
The first is for the database: in the case of AUT-NUM objects, the "org:" attribute is optional. This allows AUT-NUM objects that have been assigned before the ORGANISATION class was added to exist, without references to dummy or incorrect objects.
We can make "org:" mandatory in AUT-NUM objects. We have made other attributes mandatory in the past, without updating existing objects. This means that old AUT-NUM objects would not be fixed, but any modified objects must have an "org:". Our experience is that this discourages people from updating these objects, so some of them become less accurate, because people do not bother to fix them.
The second set of rules is for the resource request process: in the case of ASN requests, we need to know which organisation will be using the ASN. This information is published in the resulting AUT-NUM object, so from this point of view it is a required attribute.
Essentially, the database syntax can see seen as a sub-set of the business requirements for assigning an ASN.
From a database point of view, I understand it's better to keep it
Hmm, at least your story confirms the one I got from hostmaster later today :) optional because of all the legacy objects. But for people who don't read any manual, it's very confusing and annoying. Is there a way or is it an idea to at least change the template returned with -t to mandatory or as I'm probably not the first one hitting this, to have the hostmaster bot send a more descriptive error ? Grtx, MarcoH
participants (2)
-
MarcoH -
Shane Kerr