[acm-tf] some thoughts on issues raised today

Hello everybody,

are there any other thought, concerns, suggestions about the idea of
Denis we should discuss?

If not I would like to take the next steps and think about how we get
these things into a policy formated text.

Thanks,

Tobias


Am 15.06.11 21:49, schrieb Denis Walker:
> Dear Colleagues,
> 
> I was thinking about a couple of points made during the discussion today
> while on the train home (yes I know I should get a life but I just had
> to write it down). In particular the points about (not) introducing a
> new NIC hdl suffix (-abuse) and the need to create multiple ROLE objects
> with duplicated data for small organisations. An idea came to mind that
> addresses both these issues, fits even better within our current data
> model and is extensible.
> 
> Suppose we introduce a new attribute to the ROLE object:
> role-type:      [mandatory]  [multiple]     []
> 
> and allow this initially to take one of three values:
> 
> STANDARD    All the current ROLE objects would fit with this type
> ABUSE       For ROLE objects holding abuse contact data
> IRT         For ROLE objects holding IRT contact data
> 
> We then add two new contact attributes "abuse-c:" and "irt-c:"
> (replacing "mnt-irt:"). These can only reference ABUSE and IRT ROLE
> object types respectively. All role based contact information is now
> held in the one object type, ROLE. All references to contact details are
> from the same type of attribute, "xxx-c:". There is no need for a new
> NIC hdl suffix. Existing ROLE objects with their current NIC hdls can be
> used for any of these roles. There is no need for a separate IRT object
> referenced by a maintainer like attribute. The ROLE object with
> "role-type: IRT" and referenced by an "irt-c:" replaces it.
> 
> The syntax for the ROLE object then becomes a superset of all the
> attributes needed for each of these roles. All these attributes can be
> defined as OPTIONAL by syntax. Their use in each type can be defined by
> business rules as one of:
> 
> REQUIRED    - must have
> ALLOWED     - can have
> NOT ALLOWED - can't have
> 
> Suppose we have the following superset of optional attributes for all
> role types:
> 
> abuse-mailbox:
> e-mail:
> phone:
> irc:
> url:
> im:
> signature:
> encryption:
> irt-nfy:
> 
> One example set of business rules could be:
> 
> STANDARD ROLE
> 
> REQUIRED
>  e-mail:
> ALLOWED
>  phone:
> NOT ALLOWED
>  abuse-mailbox:
>  irc:
>  url:
>  im:
>  signature:
>  encryption:
>  irt-nfy:
> 
> ABUSE ROLE
> 
> REQUIRED
>  abuse-mailbox:
> ALLOWED
>  phone:
>  e-mail:
>  irc:
>  url:
>  im:
> NOT ALLOWED
>  signature:
>  encryption:
>  irt-nfy:
> 
> IRT ROLE
> 
> REQUIRED
>  e-mail:
>  signature:
>  encryption:
> ALLOWED
>  phone:
>  irt-nfy:
> NOT ALLOWED
>  abuse-mailbox:
>  irc:
>  url:
>  im:
> 
> Filtering and access control limits (ACL) could also apply differently
> to the different role types. For STANDARD and IRT ROLE objects query
> filtering (negated with the -B flag) could apply to all attributes
> containing an email address (as it does now). ACL will apply to the
> number of these role types a user queries. For the ABUSE ROLE objects
> filtering should only apply to database management attributes like
> "notify:" and "changed:". The operational specific attributes like
> "abuse-mailbox:" and "e-mail:" will not be filtered. Also no ACL will
> apply to queries for these role types.
> 
> By allowing "role-type:" to be a multiple attribute, one ROLE object can
> take on more than one role. But with the caveat that the least
> restrictive rules for a role type will apply. So for a small company
> with only one set of people who do everything, one ROLE object can be
> defined as both STANDARD and ABUSE. The business rules will be a
> composite of these two role types. No ACL will apply to queries for this
> ROLE object as it is an ABUSE role type, even though it is also a
> STANDARD role type. It becomes a user choice between convenience and
> control.
> 
> To summarise, one object type can be used to define any type of contact
> role. We currently have a need for three types. Any new type can be
> added in the future by defining a new type value. Business rules can
> define the arrangement of attributes per type from a superset of
> attributes, including any new ones added later. All contacts should be
> referenced by attributes of the format "xxx-c:" and again business rules
> can restrict the type of role these attributes can reference.
> 
> I hope this provides some helpful thoughts on these two issues and also
> takes another step in the direction of simplifying the data model.
> 
> cheers
> denis
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 267 bytes
Desc: OpenPGP digital signature
URL: <https://www.ripe.net/ripe/mail/archives/acm-tf/attachments/20110629/7c7a6556/attachment.sig>