2 questions

[ginny listman]

It seems like the opinion is that the ARIN members want flexibility.  You
want any number of POC, of any type of POCs.  You also want both
commercial and fax phone numbers, with the flexibility to have more than
zero, one or many.

We will incorporate this flexibility into the new schema.  One additional
closely related question, and I know the answer before I ask: do you want
the flexibility to have multiple mailboxes associated with a POC?

Ginny

On Thu, 21 Dec 2000, Catherine Murphy wrote:

> 
> caveat: further details pending...
> 
> greg> May I recommended that we create a Parent name :  e.g.:  AT&T Canada
> greg> Corp.  with the proper Headquarter Name:  address:  etc...  Under
> greg> the parent name we create Divisions ( e.g.:  Internet or ISP, IP
> greg> Data Services, IP Telephony Services etc... )with their appropriate
> greg> POC's. 
> 
> Without trying to muddy the waters too much, we are already looking at a
> structure that allows for a "parent" type organization with "child" 
> divisions. In this type of structure, each "child" organization/division
> would be required to provide a minimum of an administrative, billing and
> technical POC. The parent is also required to provide a membership POC. 
> These can all be the same as far as we are concerned, but they map to the
> various types of communication that ARIN might have with an organization. 
> 
> david> We have not defined administrative POC, have we? 
> david> Are you using that term in exchange with "NOC"?
> 
> Administrative POC = "The buck stops here" authority for questions with
> regards to ARIN-to-Organization communication. This is not the same thing
> as a NOC contact. 
> 
> In addition to the POCs required at the organizational level, any resource
> (network or AS) received from ARIN may _optionally_ have POCs specified.
> 
> There are really two questions: 
> 
> (a) what type of POCs are desired?
>     and 
> (b) how many of each type are desired?
> 
> Is the answer to (a) open-ended? A tech POC is a given; an abuse POC seems
> like a good idea. In the past, it has been suggested that we create a
> "reassign" POC type that only permits the POC to perform reassignments,
> but allows no other changes to the record. Are there other _types_ of POCs
> that we know about now that we should anticipate and implement up front?
> 
> If we implement multiple _types_ of POCs, is there still a need for
> multiple POCs of a single type? For instance, 
> 
>     Netname: CONFUSION-REIGNS
>     Netblock: 10.44.0.0 - 10.44.7.255
> 
>     Tech: Name/Role (Handle) Email
>           Phone
> 
>     Tech: Name/Role (Handle) Email
>           Phone
> 
>     Abuse: Name/Role (Handle) Email
>            Phone
> 
> As David mentions, allowing multiple POCs of a single type would conform
> to concepts in RPSL. Is this the consensus of the group? 
> 
> Cathy
> 
> ---------------------------------------------
> Catherine M. Murphy <cathym at arin.net>
> Senior Software Engineer
> American Registry for Internet Numbers (ARIN)
> +1 703 227 9875
> 
> 
> 
> 
> 
> 
> 
>