[dbwg] Notification Process

[william at elan.net]

These POC should not be displayed in whois, public really has no interest in 
knowing who are NT, NA, NR contacts. I think we should have "hidden" flag 
setup for all POCs and had default values set for different POCs, for 
example Abuse POC should be public default, while these 3 can be private 
(unless somebody wants to make it public!), I'd like to see Administrative POC
private default as well.

Regarding actual POCs, 3 may very well be an overkill. I'd like to ask 
first if this was to be used by humans for notifiactions of failure or for 
autmated software? In either case I don't think there is much interest in 
this being full POC, rather only email is really what is important, so why 
not just create special contact with 3 email fields for NT, NA, NR?

On Thu, 6 Mar 2003, ginny listman wrote:

> 
> NOTIFICATION PROCESS
> ====================
> To provide a measure of accountability, ARIN would like to implement the
> use of notification under two different methods.
> 
> FOR ASN, NET, & ORG
> ===================
> ARIN will create three new POC types as follows:
> 
>     - Notify (NT): When a submitted template is processed whether
>       successfully or not, the email address of any applicable Notify
>       POCs, where on the Org or its resources, will be cc'ed on the
>       confirmation or returned mail.
>     - Notify Accept (NA): When a submitted template is processed
>       successfully that modifies or removes an org or one its resources,
>       the email addresses of any applicable Notify-Accept POCs, whether on
>       the Org or its resources, will be cc'ed on the confirmation.
>     - Notify Reject (NR): When a submitted template is reject due to
>       failed authorization or errors in the template, the email address of
>       any applicable  Notify-Reject POCs, whether on the Org or its
>       resources, will be cc'ed on the returned mail.
> 
> ------------------------------------------------------------------------
> If ARIN proceeds with this, the following issues need to be resolved.
> 
> 1. For those of you who would implement this, is 3 new POCs overkill?
>    Would a single Notify POC suffice? Or two {Notify-Accept, Notify-
>    Reject} work better?
> 2. How should the POCs be displayed in WHOIS?
>    A. Never show them. (Con: Maintainability issues)
>    B. Always show both resource and org notify contacts (Con: Verbose
>       output, not really needed for troubleshooting)
>    C. On resource queries, only show resource-notify contacts, for org
>       queries only show org-notify contacts. (Con: Still somewhat verbose)
>    D. Display only POC's handle and email address (Con: New display type,
>       whereas parsers are already used to manipulating contact info)
> 
> ----------------------------------------------------------------------
> 
> FOR POC ONLY
> ============
> If the mailbox is deleted/modified for an existing POC, the deleted/
> modified mailbox is cc'ed.
>