[db-wg] abuse-c: proposal

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 --