Hi Tim
On 17/12/2015 12:01, Tim Bruijnzeels wrote:
Hi all,
To clarify, we do not create duplicates or overrides.
On 16 Dec 2015, at 16:54, denis <ripede...@yahoo.co.uk> wrote:
Hi Tim
On 16/12/2015 15:58, Tim Bruijnzeels wrote:
Hi,
To expedite the creation of abuse contacts we've just
deployed an enhancement to the RIPE Database web
interface.
Whenever you create a new organisation object or you edit
an existing one that does not have an abuse contact set, we
will display a warning and offer a simple abuse-c creation
workflow.
An "abuse-c:" attribute is only required in an ORGANISATION
object if it is referenced by a resource object. So the
wording in this revised web interface may be a bit confusing
to users. It would be better if you do a check on the
specified ORGANISATION object and only display this warning
if this object should have an "abuse-c:" reference.
From what I understood, warning is not an error and doesn't
prevent the creation of the ORGANISATION object.
If you submit the object in the web interface with an empty value
for the abuse-c, it will give you the following error: "Please
provide an Abuse-c or remove the attribute if you would like to
do it later"
So you can explicitly remove the attribute if you want, but we
try to guide people into adding the abuse-c because it's a good
idea to have it in general (even if it's not strictly required),
Sorry but this is just wrong. The whole design of "abuse-c:"
attribute was to use hierarchical inheritance in resource objects.
You only put it where it is needed and it is inherited by any more
specific objects. It should NOT be duplicated where it is not
required. That leads to redundant information being stored in the
database. This copy can be forgotten about when the authoritative
version referenced from a less specific object is changed and leave
invalid data in the database which will override the valid data for
some resources.
We are talking here about adding "abuse-c:" to organisation objects,
not resource objects.
All inet(6)num and aut-num objects allocated or assigned through the
RIPE NCC have an "org:" reference. The referenced organisation must
have an "abuse-c:" attribute by policy 2011-06.
If an LIR creates more specific inet(6)num objects, the default
behaviour is that the "org:" object are blank, and is the abuse-c
'inherited' from the covering object's "org:". But they can
optionally refer to another organisation object. In that case it is
also appropriate to have an explicit "abuse-c" on that organisation.
In rare cases it may be that two different organisations should use
the same abuse contact - this can easily be achieved by referring to
the same role object from both organisation objects' "abuse-c:".
In short the duplication that you refer to is not introduced.
You said it yourself below you cannot know why a user is creating an
ORGANISATION object. It is quite possible an LIR sub allocates part of
an allocation to another company but intends to handle all abuse
complaints themselves for their allocation. If you now create an
ORGANISATION object for the company holding the sub allocation you tell
them they should add an "abuse-c:". Now you are assuming they know they
should use the same ROLE object of the LIR and should not change that
reference. It is quite likely they will follow your instructions and let
you create a new ROLE object for them with their email address.
It is far better to encourage users to understand what they are doing
and why. If your instructions suggested adding an "abuse-c:" IF
required, or even told them to check if they need one, then someone
needs to find out if they require it. But to tell them it is missing
means they will just follow instructions and add one.
and we often find
that organisation objects are created for sponsored PI or ASN
resources without this, and this adds unnecessary overhead to
request handling because then we will need to ask for this then.
If you know this is why you are creating this ORGANISATION object
then it is reasonable to add an "abuse-c:" at this point. But the
wording on your new web form should be clear and suggest adding an
"abuse-c:" only IF it is needed.
We are not creating the object. The user is.
That is why your instructions should be clear.
Moreover, during object creation procedure it is unknown what
for the ORGANISATION object is created.
You should not be creating objects in the database if you don't
know what their immediate use is for. If you do not currently
handle any abuse complaints then you should not include an
"abuse-c:" attribute in a newly created ORGANISATION object. This
is confusing and redundant information and may override the valid
contact data.
Again, we are not creating objects. The user is. We cannot know the
users full intent at the time they create an organisation object. The
duplication you refer to does not exist. And having a dedicated
contact method for abuse related matters is best practice. The trash
icon and error message in case the value is left blank is indication
enough that this is strictly speaking optional.
The "You" did not mean 'you' :) I meant whoever is creating the object.
They should know why they are creating it. But since the RIPE NCC
doesn't know at this point why they are creating an ORGANISATION object
you should not be 'encouraging' them to add an "abuse-c:" at this point.
If they do add one of their own and later this is referenced by a sub
allocation then you may have overridden the LIRs abuse contact details.
My point is simple. People should know what they are doing. An
"abuse-c:" attribute should be added where and when needed. Telling
people to add it regardless, with the possibility of the wrong data
being used if the blindly follow your instructions, is not useful.
cheers
denis
Cheers Tim
cheers denis
Indeed, we don't know this at creation time.
Regards,
Tim
All the best, Piotr
-- gucio -> Piotr Strzyżewski E-mail:
piotr.strzyzew...@polsl.pl
