It's been very quiet on the list since the frantic activity
at the end of last week. I expect day-to-day reality has
imposed itself.
I've done some further thinking, and have reviewed the contributions
last week on the db-wg list. I've tried to recognize the issues and
alternatives in this message and to make proposals as straw-men for
consensus.
I've used a bullet-point approach, as I think no-one is likely to
have time to read anything more discursive. I'll happily explain
anything that people find too terse.
Here goes ...
Attribute name
Name should be distinctive, eg: 'abuse-mailbox'; not 'e-mail'
Handle
Handle is upwardly scalable
Handle could refer to person, role, or maintainer
Value
Value is necessary; if not in primary object, then indirectly
Value in primary object is attractive at low end of scale
Value is vulnerable to RHS-hijacking, even if not in primary object!
Hint string
Trailing #-comment is easiest
RFC822 parens-comment as part of value is possible
Qualifier to attribute name would be neat, but may be difficult
to implement (eg: abuse-mailbox-{spam,security})
Proposal (1)
Advertisement (sysadmin) side
Use two attributes: one to hold value, the other to hold handle
Use attribute 'abuse-mailbox' to hold value
Use attribute name 'abuse-c' to hold indirect object handle
Allow use of 'abuse-mailbox' attribute in primary object
Encourage use of attribute in indirect object as best practice
Support all relevant indirect objects (person, role, maintainer)
in order to make it easy for sysadmins
We REALLY WANT sysadmins to ADOPT this (NAFS: no apol for shout)
Inheritance
Implemented in query tool: design and coding resource impact
Must be 'intuitive' for advertising sysadmin
Two axes: by reference to handle; by containing block
Priority: by reference first, but ...
Proposal (2)
Query side algorithm
Specifies behaviour of focused query tool
Sysadmins must take account when advertising
in order to align query result with their intent
Needs discussion:
Concept
Implementation: cost to implement, performance,
possible pruning of search tree
Given object (from inet*num, asnum, ...) and circumstances
To identify appropriate abuse contact
Find contact set for given object
Include tech-c.email value for given object if set is empty
Discard members of set unless circumstances match hint
Return survivor(s)
To find contact set
Start with empty set
Add all abuse-mailbox values found in current object
While set still empty visit abuse-c, mnt-c, tech-c ... (?)
Find contact set for visited object
Stop visiting as soon as set is no longer empty
While set still empty visit containing block
Find contact set for containing block (if any)
(Note: person, role, mntner have no containing block)
Stop visiting as soon as set is no longer empty
Return set
-- Ends --
