From ginny at arin.net Thu Dec 21 09:03:12 2000 From: ginny at arin.net (ginny listman) Date: Thu, 21 Dec 2000 09:03:12 -0500 (EST) Subject: Is anyone out there Message-ID: I see that there hasn't been any activity on this mailing list since June. Hopefully, that's about to change. My name is Ginny Listman, and since December 4, I am the Director of Engineering at ARIN. Since I've been with ARIN, I have written a document to outline some of the changes that will take place with our database, over the next year or so. It has been released internally, and after incorporating all internal comments, I will release it to this list. I'm shooting for the beginning of next week. From Greg.Sanche at attcanada.com Thu Dec 21 09:23:20 2000 From: Greg.Sanche at attcanada.com (Sanche, Greg) Date: Thu, 21 Dec 2000 07:23:20 -0700 Subject: Is anyone out there Message-ID: Yes, How are you today. Greg Sanche AT&T Canada Senior Manager, Advanced Enterprise & Technology 5160 Orbitor Drive Mississauga, Ontario L6W 5H2 Tel: 905 361-6142 Fax: 905 361-6001 E-mail: gsanche at attcanada.com Greg.Sanche at attcanada.com -----Original Message----- From: ginny listman [mailto:ginny at arin.net] Sent: Thursday, December 21, 2000 9:03 AM To: dbwg at arin.net Subject: Is anyone out there I see that there hasn't been any activity on this mailing list since June. Hopefully, that's about to change. My name is Ginny Listman, and since December 4, I am the Director of Engineering at ARIN. Since I've been with ARIN, I have written a document to outline some of the changes that will take place with our database, over the next year or so. It has been released internally, and after incorporating all internal comments, I will release it to this list. I'm shooting for the beginning of next week. From djeffrey at inflow.com Thu Dec 21 09:45:26 2000 From: djeffrey at inflow.com (Dan Jeffrey) Date: Thu, 21 Dec 2000 07:45:26 -0700 Subject: Is anyone out there Message-ID: <33367934AB40D41190D10008C7C9CE00DA96E6@columbus.admin.corp.inflow.com> We are here at Inflow, Inc. Denver Colorado Dan Jeffrey Corporate Operations Senior IP Engineer Inflow, Inc. djeffrey at inflow.com Work # 303-942-2958 Cell # 303-601-3669 "Learn - Do - Teach" -----Original Message----- From: ginny listman [mailto:ginny at arin.net] Sent: Thursday, December 21, 2000 7:03 AM To: dbwg at arin.net Subject: Is anyone out there I see that there hasn't been any activity on this mailing list since June. Hopefully, that's about to change. My name is Ginny Listman, and since December 4, I am the Director of Engineering at ARIN. Since I've been with ARIN, I have written a document to outline some of the changes that will take place with our database, over the next year or so. It has been released internally, and after incorporating all internal comments, I will release it to this list. I'm shooting for the beginning of next week. From ginny at arin.net Thu Dec 21 13:54:15 2000 From: ginny at arin.net (ginny listman) Date: Thu, 21 Dec 2000 13:54:15 -0500 (EST) Subject: 2 questions Message-ID: We've been discussing some of the requirements as we proceed, and two questions that really should be address to the members are the following: 1. Right now a POC can have any number of phones and/or mailboxes. Is this necessary? Can we delete all but one commercial phone, and all but one primary mailbox? Do we need to keep fax number? 2. Right now both ASes and Networks have handles and names. Ideally, the handle should be NET- or ASN- name. We would like to do some clean-up so that all resources would be the same. Get rid of an ASNBLK- or NETBLK-, as well as NETBLK-NET- and the like. Does anyone have a problem with ARIN possible changing your AS or Net handle/name? Cathy Murphy will be running a report to see how many people this will actually affect. BTW, I'm getting closer to releasing that document... Ginny From huberman at gblx.net Thu Dec 21 14:02:24 2000 From: huberman at gblx.net (David R Huberman) Date: Thu, 21 Dec 2000 12:02:24 -0700 (MST) Subject: 2 questions In-Reply-To: Message-ID: > 1. Right now a POC can have any number of phones and/or mailboxes. Is > this necessary? Can we delete all but one commercial phone, and all but > one primary mailbox? Do we need to keep fax number? * The fax number doesn't seem particularly relevant in most cases, no. * If you want to only allow one commercial phone number and one e-mail box, how about enhancing the database to allow multiple POC listings on objects, ala RPSL? That allows providers, for example, to list vanilla role accounts and list key techincal personal for, say, AS registrations. > 2. Right now both ASes and Networks have handles and names. Ideally, the > handle should be NET- or ASN- name. We would like to do some clean-up so > that all resources would be the same. Get rid of an ASNBLK- or NETBLK-, > as well as NETBLK-NET- and the like. Does anyone have a problem with ARIN > possible changing your AS or Net handle/name? Cathy Murphy will be > running a report to see how many people this will actually affect. * Are you talking about parent blocks only, or all registration objects? I certainly like the idea of streamlining the database objects of netname/handle for parent IP address objects and for AS registrations, but changing any portion of downstream assignments has the potential of creating havoc with many providers' SWIP scripts. Please clarify /david From dploher at level3.net Thu Dec 21 14:06:40 2000 From: dploher at level3.net (Darren Loher) Date: Thu, 21 Dec 2000 12:06:40 -0700 Subject: 2 questions In-Reply-To: ; from huberman@gblx.net on Thu, Dec 21, 2000 at 12:02:24PM -0700 References: Message-ID: <20001221120639.B1311@mail1.idc1.oss.level3.com> I too would like the support for multiple POC's. Particularly one for Abuse and one for Security. -Darren Loher Level 3 Communications Global Data Architecture On Thu, Dec 21, 2000 at 12:02:24PM -0700, David R Huberman wrote: > > > 1. Right now a POC can have any number of phones and/or mailboxes. Is > > this necessary? Can we delete all but one commercial phone, and all but > > one primary mailbox? Do we need to keep fax number? > > * The fax number doesn't seem particularly relevant in most cases, no. > > * If you want to only allow one commercial phone number and one e-mail > box, how about enhancing the database to allow multiple POC listings > on objects, ala RPSL? That allows providers, for example, to list > vanilla role accounts and list key techincal personal for, say, AS > registrations. > > > 2. Right now both ASes and Networks have handles and names. Ideally, the > > handle should be NET- or ASN- name. We would like to do some clean-up so > > that all resources would be the same. Get rid of an ASNBLK- or NETBLK-, > > as well as NETBLK-NET- and the like. Does anyone have a problem with ARIN > > possible changing your AS or Net handle/name? Cathy Murphy will be > > running a report to see how many people this will actually affect. > > * Are you talking about parent blocks only, or all registration objects? > I certainly like the idea of streamlining the database objects of > netname/handle for parent IP address objects and for AS registrations, > but changing any portion of downstream assignments has the potential > of creating havoc with many providers' SWIP scripts. Please clarify > > /david -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From Greg.Sanche at attcanada.com Thu Dec 21 14:35:23 2000 From: Greg.Sanche at attcanada.com (Sanche, Greg) Date: Thu, 21 Dec 2000 12:35:23 -0700 Subject: 2 questions Message-ID: I also agree and support the use of multiple POC's, as mentioned below and include a Billing POC. The Abuse and NOC e-mail addresses and phone numbers should be public knownledge and the Administrator and billing contact info should be protected from the general public. Greg Sanche AT&T Canada Corp. Tel: 905 361-6142 Fax: 905 361-6001 E-Mail : gsanche at attcanada.com Greg.Sanche at attcanada.com -----Original Message----- From: Darren Loher [mailto:dploher at level3.net] Sent: Thursday, December 21, 2000 2:07 PM To: David R Huberman Cc: ginny listman; dbwg at arin.net Subject: Re: 2 questions I too would like the support for multiple POC's. Particularly one for Abuse and one for Security. -Darren Loher Level 3 Communications Global Data Architecture On Thu, Dec 21, 2000 at 12:02:24PM -0700, David R Huberman wrote: > > > 1. Right now a POC can have any number of phones and/or mailboxes. Is > > this necessary? Can we delete all but one commercial phone, and all but > > one primary mailbox? Do we need to keep fax number? > > * The fax number doesn't seem particularly relevant in most cases, no. > > * If you want to only allow one commercial phone number and one e-mail > box, how about enhancing the database to allow multiple POC listings > on objects, ala RPSL? That allows providers, for example, to list > vanilla role accounts and list key techincal personal for, say, AS > registrations. > > > 2. Right now both ASes and Networks have handles and names. Ideally, the > > handle should be NET- or ASN- name. We would like to do some clean-up so > > that all resources would be the same. Get rid of an ASNBLK- or NETBLK-, > > as well as NETBLK-NET- and the like. Does anyone have a problem with ARIN > > possible changing your AS or Net handle/name? Cathy Murphy will be > > running a report to see how many people this will actually affect. > > * Are you talking about parent blocks only, or all registration objects? > I certainly like the idea of streamlining the database objects of > netname/handle for parent IP address objects and for AS registrations, > but changing any portion of downstream assignments has the potential > of creating havoc with many providers' SWIP scripts. Please clarify > > /david From ginny at arin.net Thu Dec 21 14:50:16 2000 From: ginny at arin.net (ginny listman) Date: Thu, 21 Dec 2000 14:50:16 -0500 (EST) Subject: 2 questions In-Reply-To: Message-ID: Okay.. >From what people are saying, I have come up with the following POC Types: Private (not displayed in whois): Billing, Membership and Administrative Public (displayed in whois): Technical, NOC and Abuse The next question is, is there a need to ever have more than one of any type of POC? Ginny On Thu, 21 Dec 2000, Sanche, Greg wrote: > > I also agree and support the use of multiple POC's, > as mentioned below and include a Billing POC. > > The Abuse and NOC e-mail addresses and phone numbers should be public > knownledge and > the Administrator and billing contact info should be protected from the > general public. > > Greg Sanche > AT&T Canada Corp. > Tel: 905 361-6142 Fax: 905 361-6001 > E-Mail : gsanche at attcanada.com > Greg.Sanche at attcanada.com > > > > > > -----Original Message----- > From: Darren Loher [mailto:dploher at level3.net] > Sent: Thursday, December 21, 2000 2:07 PM > To: David R Huberman > Cc: ginny listman; dbwg at arin.net > Subject: Re: 2 questions > > > I too would like the support for multiple POC's. Particularly > one for Abuse and one for Security. > > -Darren Loher > Level 3 Communications > Global Data Architecture > > On Thu, Dec 21, 2000 at 12:02:24PM -0700, David R Huberman wrote: > > > > > 1. Right now a POC can have any number of phones and/or mailboxes. Is > > > this necessary? Can we delete all but one commercial phone, and all but > > > one primary mailbox? Do we need to keep fax number? > > > > * The fax number doesn't seem particularly relevant in most cases, no. > > > > * If you want to only allow one commercial phone number and one e-mail > > box, how about enhancing the database to allow multiple POC listings > > on objects, ala RPSL? That allows providers, for example, to list > > vanilla role accounts and list key techincal personal for, say, AS > > registrations. > > > > > 2. Right now both ASes and Networks have handles and names. Ideally, > the > > > handle should be NET- or ASN- name. We would like to do some clean-up > so > > > that all resources would be the same. Get rid of an ASNBLK- or NETBLK-, > > > as well as NETBLK-NET- and the like. Does anyone have a problem with > ARIN > > > possible changing your AS or Net handle/name? Cathy Murphy will be > > > running a report to see how many people this will actually affect. > > > > * Are you talking about parent blocks only, or all registration objects? > > I certainly like the idea of streamlining the database objects of > > netname/handle for parent IP address objects and for AS registrations, > > but changing any portion of downstream assignments has the potential > > of creating havoc with many providers' SWIP scripts. Please clarify > > > > /david > From ginny at arin.net Thu Dec 21 15:03:50 2000 From: ginny at arin.net (ginny listman) Date: Thu, 21 Dec 2000 15:03:50 -0500 (EST) Subject: 2 questions In-Reply-To: Message-ID: On Thu, 21 Dec 2000, David R Huberman wrote: > > 2. Right now both ASes and Networks have handles and names. Ideally, the > > handle should be NET- or ASN- name. We would like to do some clean-up so > > that all resources would be the same. Get rid of an ASNBLK- or NETBLK-, > > as well as NETBLK-NET- and the like. Does anyone have a problem with ARIN > > possible changing your AS or Net handle/name? Cathy Murphy will be > > running a report to see how many people this will actually affect. > > * Are you talking about parent blocks only, or all registration objects? > I certainly like the idea of streamlining the database objects of > netname/handle for parent IP address objects and for AS registrations, > but changing any portion of downstream assignments has the potential > of creating havoc with many providers' SWIP scripts. Please clarify > > /david > The registration software will prepend NET- to the network name provided on the template to get the handle. However, some customers use a net name like NET-FOOBAR. What we want to do is call the net name FOOBAR, and call the handle NET-FOOBAR not NET-NET-FOOBAR. Also, there are a bunch of names/handles that have NETBLK- or ASNBLK- prepended. We like to change this to NET- and ASN-. Regardless, what is currently stored in the database is not uniform, and will require clean-up. I guess we really need to look at Cathy's report to see how many AS/Nets this will affect. Ginny From tchatfield at GemNets.Com Thu Dec 21 15:22:41 2000 From: tchatfield at GemNets.Com (Terry Chatfield) Date: Thu, 21 Dec 2000 15:22:41 -0500 Subject: 2 questions References: Message-ID: <3A426691.575A2AE2@GemNets.Com> Some companies may have a primary and backup for each type of POC. ginny listman wrote: > Okay.. > > >From what people are saying, I have come up with the following POC Types: > > Private (not displayed in whois): Billing, Membership and Administrative > Public (displayed in whois): Technical, NOC and Abuse > > The next question is, is there a need to ever have more than one of any > type of POC? > > Ginny > > On Thu, 21 Dec 2000, Sanche, Greg wrote: > > > > > I also agree and support the use of multiple POC's, > > as mentioned below and include a Billing POC. > > > > The Abuse and NOC e-mail addresses and phone numbers should be public > > knownledge and > > the Administrator and billing contact info should be protected from the > > general public. > > > > Greg Sanche > > AT&T Canada Corp. > > Tel: 905 361-6142 Fax: 905 361-6001 > > E-Mail : gsanche at attcanada.com > > Greg.Sanche at attcanada.com > > > > > > > > > > > > -----Original Message----- > > From: Darren Loher [mailto:dploher at level3.net] > > Sent: Thursday, December 21, 2000 2:07 PM > > To: David R Huberman > > Cc: ginny listman; dbwg at arin.net > > Subject: Re: 2 questions > > > > > > I too would like the support for multiple POC's. Particularly > > one for Abuse and one for Security. > > > > -Darren Loher > > Level 3 Communications > > Global Data Architecture > > > > On Thu, Dec 21, 2000 at 12:02:24PM -0700, David R Huberman wrote: > > > > > > > 1. Right now a POC can have any number of phones and/or mailboxes. Is > > > > this necessary? Can we delete all but one commercial phone, and all but > > > > one primary mailbox? Do we need to keep fax number? > > > > > > * The fax number doesn't seem particularly relevant in most cases, no. > > > > > > * If you want to only allow one commercial phone number and one e-mail > > > box, how about enhancing the database to allow multiple POC listings > > > on objects, ala RPSL? That allows providers, for example, to list > > > vanilla role accounts and list key techincal personal for, say, AS > > > registrations. > > > > > > > 2. Right now both ASes and Networks have handles and names. Ideally, > > the > > > > handle should be NET- or ASN- name. We would like to do some clean-up > > so > > > > that all resources would be the same. Get rid of an ASNBLK- or NETBLK-, > > > > as well as NETBLK-NET- and the like. Does anyone have a problem with > > ARIN > > > > possible changing your AS or Net handle/name? Cathy Murphy will be > > > > running a report to see how many people this will actually affect. > > > > > > * Are you talking about parent blocks only, or all registration objects? > > > I certainly like the idea of streamlining the database objects of > > > netname/handle for parent IP address objects and for AS registrations, > > > but changing any portion of downstream assignments has the potential > > > of creating havoc with many providers' SWIP scripts. Please clarify > > > > > > /david > > -------------- next part -------------- A non-text attachment was scrubbed... Name: Chat.vcf Type: text/x-vcard Size: 471 bytes Desc: Card for Terrence Chatfield URL: From Greg.Sanche at attcanada.com Thu Dec 21 15:41:50 2000 From: Greg.Sanche at attcanada.com (Sanche, Greg) Date: Thu, 21 Dec 2000 13:41:50 -0700 Subject: 2 questions Message-ID: Ginny ( ARIN ) Within a Large company or organization, there are varies divisions which use Registered IP's in there services ( not only their ISP's division ). Therefore a need for more than one POC within an organization. Greg Sanche AT&T Canada Corp. Tel: 905 361-6142 Fax: 905 361-6001 E-Mail : gsanche at attcanada.com Greg.Sanche at attcanada.com -----Original Message----- From: ginny listman [mailto:ginny at arin.net] Sent: Thursday, December 21, 2000 2:50 PM To: Sanche, Greg Cc: 'Darren Loher'; David R Huberman; dbwg at arin.net Subject: RE: 2 questions Okay.. >From what people are saying, I have come up with the following POC Types: Private (not displayed in whois): Billing, Membership and Administrative Public (displayed in whois): Technical, NOC and Abuse The next question is, is there a need to ever have more than one of any type of POC? Ginny On Thu, 21 Dec 2000, Sanche, Greg wrote: > > I also agree and support the use of multiple POC's, > as mentioned below and include a Billing POC. > > The Abuse and NOC e-mail addresses and phone numbers should be public > knownledge and > the Administrator and billing contact info should be protected from the > general public. > > Greg Sanche > AT&T Canada Corp. > Tel: 905 361-6142 Fax: 905 361-6001 > E-Mail : gsanche at attcanada.com > Greg.Sanche at attcanada.com > > > > > > -----Original Message----- > From: Darren Loher [mailto:dploher at level3.net] > Sent: Thursday, December 21, 2000 2:07 PM > To: David R Huberman > Cc: ginny listman; dbwg at arin.net > Subject: Re: 2 questions > > > I too would like the support for multiple POC's. Particularly > one for Abuse and one for Security. > > -Darren Loher > Level 3 Communications > Global Data Architecture > > On Thu, Dec 21, 2000 at 12:02:24PM -0700, David R Huberman wrote: > > > > > 1. Right now a POC can have any number of phones and/or mailboxes. Is > > > this necessary? Can we delete all but one commercial phone, and all but > > > one primary mailbox? Do we need to keep fax number? > > > > * The fax number doesn't seem particularly relevant in most cases, no. > > > > * If you want to only allow one commercial phone number and one e-mail > > box, how about enhancing the database to allow multiple POC listings > > on objects, ala RPSL? That allows providers, for example, to list > > vanilla role accounts and list key techincal personal for, say, AS > > registrations. > > > > > 2. Right now both ASes and Networks have handles and names. Ideally, > the > > > handle should be NET- or ASN- name. We would like to do some clean-up > so > > > that all resources would be the same. Get rid of an ASNBLK- or NETBLK-, > > > as well as NETBLK-NET- and the like. Does anyone have a problem with > ARIN > > > possible changing your AS or Net handle/name? Cathy Murphy will be > > > running a report to see how many people this will actually affect. > > > > * Are you talking about parent blocks only, or all registration objects? > > I certainly like the idea of streamlining the database objects of > > netname/handle for parent IP address objects and for AS registrations, > > but changing any portion of downstream assignments has the potential > > of creating havoc with many providers' SWIP scripts. Please clarify > > > > /david > From ginny at arin.net Thu Dec 21 15:59:08 2000 From: ginny at arin.net (ginny listman) Date: Thu, 21 Dec 2000 15:59:08 -0500 (EST) Subject: 2 questions In-Reply-To: Message-ID: If this seems redundant, I just want to make sure I understand it correctly. This is critical before we start seriously developing. So you want backup POCs of the same function, ie all Technical or Administrative, and would be the POC for the same NetBlock. Therefore, we need to build in the ability to have many technical contacts, many abuse contacts, ... As far as designing the template to handle this, it would sort of look like this: Network: other network fields: # Contact Information Contact Type...........: Add, Modify or Delete..: Name...................: Address................: Phone..................: Mailbox................: # Another Contact ... Of course it will be a whole lot prettier :-> Anyway, if we allow the ability to have multiple POCs of the various POC types, it will require an "Action" type for each POC. Otherwise, the POC list would continue to grow. Ginny On Thu, 21 Dec 2000, Sanche, Greg wrote: > > Ginny ( ARIN ) > > Within a Large company or organization, there are varies divisions which use > Registered IP's in > there services ( not only their ISP's division ). Therefore a need for more > than one POC within an > organization. > > Greg Sanche > AT&T Canada Corp. > Tel: 905 361-6142 Fax: 905 361-6001 > E-Mail : gsanche at attcanada.com > Greg.Sanche at attcanada.com > > > > -----Original Message----- > From: ginny listman [mailto:ginny at arin.net] > Sent: Thursday, December 21, 2000 2:50 PM > To: Sanche, Greg > Cc: 'Darren Loher'; David R Huberman; dbwg at arin.net > Subject: RE: 2 questions > > > Okay.. > > >From what people are saying, I have come up with the following POC Types: > > Private (not displayed in whois): Billing, Membership and Administrative > Public (displayed in whois): Technical, NOC and Abuse > > The next question is, is there a need to ever have more than one of any > type of POC? > > Ginny > > On Thu, 21 Dec 2000, Sanche, Greg wrote: > > > > > I also agree and support the use of multiple POC's, > > as mentioned below and include a Billing POC. > > > > The Abuse and NOC e-mail addresses and phone numbers should be public > > knownledge and > > the Administrator and billing contact info should be protected from the > > general public. > > > > Greg Sanche > > AT&T Canada Corp. > > Tel: 905 361-6142 Fax: 905 361-6001 > > E-Mail : gsanche at attcanada.com > > Greg.Sanche at attcanada.com > > > > > > > > > > > > -----Original Message----- > > From: Darren Loher [mailto:dploher at level3.net] > > Sent: Thursday, December 21, 2000 2:07 PM > > To: David R Huberman > > Cc: ginny listman; dbwg at arin.net > > Subject: Re: 2 questions > > > > > > I too would like the support for multiple POC's. Particularly > > one for Abuse and one for Security. > > > > -Darren Loher > > Level 3 Communications > > Global Data Architecture > > > > On Thu, Dec 21, 2000 at 12:02:24PM -0700, David R Huberman wrote: > > > > > > > 1. Right now a POC can have any number of phones and/or mailboxes. > Is > > > > this necessary? Can we delete all but one commercial phone, and all > but > > > > one primary mailbox? Do we need to keep fax number? > > > > > > * The fax number doesn't seem particularly relevant in most cases, no. > > > > > > * If you want to only allow one commercial phone number and one e-mail > > > box, how about enhancing the database to allow multiple POC listings > > > on objects, ala RPSL? That allows providers, for example, to list > > > vanilla role accounts and list key techincal personal for, say, AS > > > registrations. > > > > > > > 2. Right now both ASes and Networks have handles and names. Ideally, > > the > > > > handle should be NET- or ASN- name. We would like to do some clean-up > > so > > > > that all resources would be the same. Get rid of an ASNBLK- or > NETBLK-, > > > > as well as NETBLK-NET- and the like. Does anyone have a problem with > > ARIN > > > > possible changing your AS or Net handle/name? Cathy Murphy will be > > > > running a report to see how many people this will actually affect. > > > > > > * Are you talking about parent blocks only, or all registration objects? > > > I certainly like the idea of streamlining the database objects of > > > netname/handle for parent IP address objects and for AS registrations, > > > but changing any portion of downstream assignments has the potential > > > of creating havoc with many providers' SWIP scripts. Please clarify > > > > > > /david > > > From huberman at gblx.net Thu Dec 21 16:10:35 2000 From: huberman at gblx.net (David R Huberman) Date: Thu, 21 Dec 2000 14:10:35 -0700 (MST) Subject: 2 questions In-Reply-To: Message-ID: > Private (not displayed in whois): Billing, Membership and Administrative ------- * Billing POCs are held by ARIN billing upon the establishment of a new registering organization, correct? An e-mail to billing at arin.net can help effect changes to the registered billing POC, correct? * Membership POCs are held by ARIN Member Services also upon the establishment of a new registered organization, correct? An e-mail to memsvcs at arin.net can help effect changes to the registered membership POC, correct? * Administrative POCs are not well defined here. ARIN's RSG has historic records of correspondence between ARIN and a given customer. I cannot think of any existing mechanism that allows the customer to define to ARIN whom the administrative POC is for that organization's registrations. Such a system seems to be a good idea. Joe Schmo runs Global Crossing IP addressing for x many years. Joe Schmo leaves GBLX. On the way out, Joe Schmo updates ARIN's records to designate John Doe as the administrative contact to whom ARIN can turn with questions. > Public (displayed in whois): Technical, NOC and Abuse ------ * It seems to be that RPSL already defines these POCs quite well. ARIN would do well to model multiple POC listings after RPSL. Within each WHOIS registration would contain a mandatory technical contact, which can be filled by a role account AND/OR a individual handle, and an abuse contact, also filled by either a role or individual handle. > The next question is, is there a need to ever have more than one of any > type of POC? * Rather than thinking about it as "Technical, NOC, Abuse" it seems to be more flexible to think of it as tech-c: and abuse:. This allows registrants to put information into tech-c: as they desire. To answer your question, yes. Global Crossing could, for example, put IA12-ORG-ARIN into tech-c: for its address registrations but could put IA12-ORG-ARIN *and* an individual handle into its AS registration to assist in inter-provider communication. /david From Greg.Sanche at attcanada.com Thu Dec 21 16:14:57 2000 From: Greg.Sanche at attcanada.com (Sanche, Greg) Date: Thu, 21 Dec 2000 14:14:57 -0700 Subject: 2 questions Message-ID: May I recommended that we create a Parent name : e.g.: AT&T Canada Corp. with the proper Headquarter Name: address: etc... Under the parent name we create Divisions ( e.g.: Internet or ISP, IP Data Services, IP Telephony Services etc... )with their appropriate POC's. Greg Sanche AT&T Canada Corp. Tel: 905 361-6142 Fax: 905 361-6001 E-Mail : gsanche at attcanada.com Greg.Sanche at attcanada.com -----Original Message----- From: ginny listman [mailto:ginny at arin.net] Sent: Thursday, December 21, 2000 3:59 PM To: Sanche, Greg Cc: 'Darren Loher'; David R Huberman; dbwg at arin.net Subject: RE: 2 questions If this seems redundant, I just want to make sure I understand it correctly. This is critical before we start seriously developing. So you want backup POCs of the same function, ie all Technical or Administrative, and would be the POC for the same NetBlock. Therefore, we need to build in the ability to have many technical contacts, many abuse contacts, ... As far as designing the template to handle this, it would sort of look like this: Network: other network fields: # Contact Information Contact Type...........: Add, Modify or Delete..: Name...................: Address................: Phone..................: Mailbox................: # Another Contact ... Of course it will be a whole lot prettier :-> Anyway, if we allow the ability to have multiple POCs of the various POC types, it will require an "Action" type for each POC. Otherwise, the POC list would continue to grow. Ginny On Thu, 21 Dec 2000, Sanche, Greg wrote: > > Ginny ( ARIN ) > > Within a Large company or organization, there are varies divisions which use > Registered IP's in > there services ( not only their ISP's division ). Therefore a need for more > than one POC within an > organization. > > Greg Sanche > AT&T Canada Corp. > Tel: 905 361-6142 Fax: 905 361-6001 > E-Mail : gsanche at attcanada.com > Greg.Sanche at attcanada.com > > > > -----Original Message----- > From: ginny listman [mailto:ginny at arin.net] > Sent: Thursday, December 21, 2000 2:50 PM > To: Sanche, Greg > Cc: 'Darren Loher'; David R Huberman; dbwg at arin.net > Subject: RE: 2 questions > > > Okay.. > > >From what people are saying, I have come up with the following POC Types: > > Private (not displayed in whois): Billing, Membership and Administrative > Public (displayed in whois): Technical, NOC and Abuse > > The next question is, is there a need to ever have more than one of any > type of POC? > > Ginny > > On Thu, 21 Dec 2000, Sanche, Greg wrote: > > > > > I also agree and support the use of multiple POC's, > > as mentioned below and include a Billing POC. > > > > The Abuse and NOC e-mail addresses and phone numbers should be public > > knownledge and > > the Administrator and billing contact info should be protected from the > > general public. > > > > Greg Sanche > > AT&T Canada Corp. > > Tel: 905 361-6142 Fax: 905 361-6001 > > E-Mail : gsanche at attcanada.com > > Greg.Sanche at attcanada.com > > > > > > > > > > > > -----Original Message----- > > From: Darren Loher [mailto:dploher at level3.net] > > Sent: Thursday, December 21, 2000 2:07 PM > > To: David R Huberman > > Cc: ginny listman; dbwg at arin.net > > Subject: Re: 2 questions > > > > > > I too would like the support for multiple POC's. Particularly > > one for Abuse and one for Security. > > > > -Darren Loher > > Level 3 Communications > > Global Data Architecture > > > > On Thu, Dec 21, 2000 at 12:02:24PM -0700, David R Huberman wrote: > > > > > > > 1. Right now a POC can have any number of phones and/or mailboxes. > Is > > > > this necessary? Can we delete all but one commercial phone, and all > but > > > > one primary mailbox? Do we need to keep fax number? > > > > > > * The fax number doesn't seem particularly relevant in most cases, no. > > > > > > * If you want to only allow one commercial phone number and one e-mail > > > box, how about enhancing the database to allow multiple POC listings > > > on objects, ala RPSL? That allows providers, for example, to list > > > vanilla role accounts and list key techincal personal for, say, AS > > > registrations. > > > > > > > 2. Right now both ASes and Networks have handles and names. Ideally, > > the > > > > handle should be NET- or ASN- name. We would like to do some clean-up > > so > > > > that all resources would be the same. Get rid of an ASNBLK- or > NETBLK-, > > > > as well as NETBLK-NET- and the like. Does anyone have a problem with > > ARIN > > > > possible changing your AS or Net handle/name? Cathy Murphy will be > > > > running a report to see how many people this will actually affect. > > > > > > * Are you talking about parent blocks only, or all registration objects? > > > I certainly like the idea of streamlining the database objects of > > > netname/handle for parent IP address objects and for AS registrations, > > > but changing any portion of downstream assignments has the potential > > > of creating havoc with many providers' SWIP scripts. Please clarify > > > > > > /david > > > From huberman at gblx.net Thu Dec 21 16:17:20 2000 From: huberman at gblx.net (David R Huberman) Date: Thu, 21 Dec 2000 14:17:20 -0700 (MST) Subject: 2 questions In-Reply-To: Message-ID: > So you want backup POCs of the same function, ie all Technical or > Administrative, and would be the POC for the same NetBlock. We have not defined administrative POC, have we? Are you using that term in exchange with "NOC"? Address and AS registrations currently only have one contact, supposedly technical POC. If we're going to change that, can we please outlay our definitions for clarity's sake? (e.g. you say "administrative POC" and I think of a person from a registrant who is recognized by ARIN as authoratative for communications sake. I think of this as a non-public object. But this could also mean 'administrative POC' in the netsol use of the idea, i.e. NOC.) > Therefore, we need to build in the ability to have many technical > contacts, many abuse contacts ... Going back to my earlier e-mail, I want to be clear that I think it might be easier to approach this from a handle perspective. Allow tech-c: to include multiple POC handles. You can address the creation of new handles within the framework of database updates separately. /david From huberman at gblx.net Thu Dec 21 16:23:26 2000 From: huberman at gblx.net (David R Huberman) Date: Thu, 21 Dec 2000 14:23:26 -0700 (MST) Subject: Global POC handles? In-Reply-To: Message-ID: > Anyway, if we allow the ability to have multiple POCs of the various POC > types, it will require an "Action" type for each POC. Otherwise, the POC > list would continue to grow. Is this an inappropriate time to bring up Randy Bush's argument for global POC handles? Ginny, if ARIN is committed to re-working the WHOIS database to be more functionally appropriate to today's world, it seems a wonderful opportunity for ARIN to also offer to the networking community a service we seem to sorely lack. Perhaps ARIN will consider establishing an RPSL-compatible unique handle system? Though not much different than what exists today, it would have to take into account all of the major whois databases (for addresses, ASes, domain names, and route registries) and streamline the format. Were this database stored separately, and shared between various registries, we could quickly and effectively solve the problem of having multiple POC entries for singular entities all over the place. This issue has come up recently at both the RIPE and APNIC meetings and in the NANOG community. What a great opportunity for ARIN to stand up and solve an annoying problem for the networking community! /david From huberman at gblx.net Thu Dec 21 16:28:26 2000 From: huberman at gblx.net (David R Huberman) Date: Thu, 21 Dec 2000 14:28:26 -0700 (MST) Subject: 2 questions In-Reply-To: <20001221132236.C9248@skylab.eng.internex.net> Message-ID: > I don't think what you're asking for is multiple POC's -- but an additional > type of POC. If you just add more and more without it being specified in the > structure itself of ARIN's database for Security, Abuse, etc., then all you > have is more email addresses that EVERYONE autoparses and sends copies of all > security, notice, abuse, etc., to ALL of the contacts.... as opposed to using > an ARIN specified "ABUSE" POC for ABUSE. Are you proposing something like this? : > whois -h whois.arin.net 64.0.0.0 Concentric Network Corporation (NETBLK-CONCENTRIC-BLK5) 1400 Parkmoor Avenue San Jose, CA 95126-3429 Netname: CONCENTRIC-BLK5 Netblock: 64.0.0.0 - 64.3.255.255 Maintainer: CRC Technical Coordinator: DNS and IP ADMIN (DIA-ORG-ARIN) hostmaster at CONCENTRIC.NET (408) 817-2800 Fax- - - (408) 817-2630 Abuse & Security Coordinator: XO Security Dept (XO-ORG-ARIN) abuse at xo.com (xxx) xxx-xxxx Domain System inverse mapping provided by: NAMESERVER1.CONCENTRIC.NET 207.155.183.73 NAMESERVER2.CONCENTRIC.NET 207.155.184.72 NAMESERVER3.CONCENTRIC.NET 206.173.119.72 NAMESERVER.CONCENTRIC.NET 207.155.183.72 *Rwhois information on assignments from this block available from *rwhois.concentric.net 4321 ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE Record last updated on 01-Aug-2000. Database last updated on 21-Dec-2000 07:33:22 EDT. The ARIN Registration Services Host contains ONLY Internet Network Information: Networks, ASN's, and related POC's. Please use the whois server at rs.internic.net for DOMAIN related Information and whois.nic.mil for NIPRNET Information. From woeber at cc.univie.ac.at Thu Dec 21 17:02:15 2000 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 21 Dec 2000 23:02:15 +0100 Subject: Global POC handles? Message-ID: <009F4F2A.862D692E.1@cc.univie.ac.at> >Is this an inappropriate time to bring up Randy Bush's argument for global >POC handles? I believe it would be a perfect chance to give it another honest try. >This issue has come up recently at both the RIPE and APNIC meetings and in >the NANOG community. What a great opportunity for ARIN to stand up and >solve an annoying problem for the networking community! > >/david Btw, "we" (me plus a few folks from IRTs/CERTs in the RIPE region) are working on a proposal for an IRT object for our database. I expect (hope) that such a facility would be useful for tagging existing objects with references to IRT/CERT-contact data. Those objects would be protected and signed by strong authentication mechanisms to "avoid" accidents and to provide credibilty. (A revised proposal should become available within a few days.) I'm fully aware that the ARIN DB is quite a bit different than the RIPE DB, but I'd like to see the concepts (at least) to be as compatible as reasonably possible amongst the IP (and routing) registries. Wilfried. (RIPE DB-WG chair) _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber at CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From cathym at arin.net Thu Dec 21 18:00:00 2000 From: cathym at arin.net (Catherine Murphy) Date: Thu, 21 Dec 2000 18:00:00 -0500 (EST) Subject: 2 questions In-Reply-To: Message-ID: 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 Senior Software Engineer American Registry for Internet Numbers (ARIN) +1 703 227 9875 From ginny at arin.net Fri Dec 22 08:19:17 2000 From: ginny at arin.net (ginny listman) Date: Fri, 22 Dec 2000 08:19:17 -0500 (EST) Subject: 2 questions In-Reply-To: Message-ID: 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 > Senior Software Engineer > American Registry for Internet Numbers (ARIN) > +1 703 227 9875 > > > > > > > > From ginny at arin.net Fri Dec 22 10:32:15 2000 From: ginny at arin.net (ginny listman) Date: Fri, 22 Dec 2000 10:32:15 -0500 (EST) Subject: Conversion Plans Message-ID: Our conversion plan has be posted to the following website: http://www.arin.net/conversion/ This release was prior to any discussion of how many POC we should track, as well as any other comments that have been on the list in the last two days. Ginny From ginny at arin.net Wed Dec 27 09:35:11 2000 From: ginny at arin.net (ginny listman) Date: Wed, 27 Dec 2000 09:35:11 -0500 (EST) Subject: phone types Message-ID: Do we need the ability to allow a POC to enter a pager phone number? Ginny From alexk at tugger.net Wed Dec 27 12:00:13 2000 From: alexk at tugger.net (Alex Kamantauskas) Date: Wed, 27 Dec 2000 12:00:13 -0500 (EST) Subject: phone types In-Reply-To: Message-ID: Most people I know change pager services so frequently that maintaining the POC pager number record would become a pain... On Wed, 27 Dec 2000, ginny listman wrote: > Do we need the ability to allow a POC to enter a pager phone number? > > Ginny > -- Alex Kamantauskas alexk at tugger.net From ginny at arin.net Wed Dec 27 12:38:26 2000 From: ginny at arin.net (ginny listman) Date: Wed, 27 Dec 2000 12:38:26 -0500 (EST) Subject: phone types In-Reply-To: Message-ID: Of course this would be an optional field. Maintaining current page phone number, as with other phone number and mailboxes would be the POC's responsibility. If you feel keeping up with current page number requires too much maintainence, opt not to provide it. The only reason I ask the question is that a number of phone fields that are designate to be Commercial Phone are listed as (123) 456-7890 (Pager). I'm looking to clean-up the database, and one thing I would like to enforce is that phone numbers consist of the following: 01234567890+-() In the future, if you fill out the phone line with something like: 1-543.433.8765 (this is my pager) what gets store in the database, and displayed in whois: (543) 433-8765 Well at least for those phone number in the US. Other country phone numbers would be stored as entered. Just working on uniformity. Ginny On Wed, 27 Dec 2000, Alex Kamantauskas wrote: > > Most people I know change pager services so frequently that maintaining > the POC pager number record would become a pain... > > On Wed, 27 Dec 2000, ginny listman wrote: > > > Do we need the ability to allow a POC to enter a pager phone number? > > > > Ginny > > > > -- > Alex Kamantauskas > alexk at tugger.net > From alexk at tugger.net Wed Dec 27 12:40:59 2000 From: alexk at tugger.net (Alex Kamantauskas) Date: Wed, 27 Dec 2000 12:40:59 -0500 (EST) Subject: phone types In-Reply-To: Message-ID: Would there be fields for other devices? Cell phones, etc? On Wed, 27 Dec 2000, ginny listman wrote: > Of course this would be an optional field. Maintaining current page phone > number, as with other phone number and mailboxes would be the POC's > responsibility. If you feel keeping up with current page number requires > too much maintainence, opt not to provide it. > > The only reason I ask the question is that a number of phone fields that > are designate to be Commercial Phone are listed as (123) 456-7890 (Pager). > I'm looking to clean-up the database, and one thing I would like to > enforce is that phone numbers consist of the following: 01234567890+-() > > In the future, if you fill out the phone line with something like: > 1-543.433.8765 (this is my pager) > what gets store in the database, and displayed in whois: > (543) 433-8765 > Well at least for those phone number in the US. Other country phone > numbers would be stored as entered. Just working on uniformity. > > Ginny > > On Wed, 27 Dec 2000, Alex Kamantauskas wrote: > > > > > Most people I know change pager services so frequently that maintaining > > the POC pager number record would become a pain... > > > > On Wed, 27 Dec 2000, ginny listman wrote: > > > > > Do we need the ability to allow a POC to enter a pager phone number? > > > > > > Ginny > > > > > > > -- > > Alex Kamantauskas > > alexk at tugger.net > > > > -- Alex Kamantauskas alexk at tugger.net From ginny at arin.net Wed Dec 27 12:51:27 2000 From: ginny at arin.net (ginny listman) Date: Wed, 27 Dec 2000 12:51:27 -0500 (EST) Subject: phone types In-Reply-To: Message-ID: Well, a cell (or mobil) phone is really a commercial phone, both are voice. When placing a call, It doesn't matter if I'm calling a mobil phone. I'm just expecting a voice on the other end. Although pager numbers can be voice, it would be nice to know that you will be dialing a pager and may have to enter a number. As far as other devices, what else would you like to see? In the new schema, we were intending on removing DSN phone numbers. Those military folks that use DSN can get that information via the DoD NIC. (Any objections?) This leaves, Commercial, Fax and Pager so far. Ginny On Wed, 27 Dec 2000, Alex Kamantauskas wrote: > > Would there be fields for other devices? Cell phones, etc? > > On Wed, 27 Dec 2000, ginny listman wrote: > > > Of course this would be an optional field. Maintaining current page phone > > number, as with other phone number and mailboxes would be the POC's > > responsibility. If you feel keeping up with current page number requires > > too much maintainence, opt not to provide it. > > > > The only reason I ask the question is that a number of phone fields that > > are designate to be Commercial Phone are listed as (123) 456-7890 (Pager). > > I'm looking to clean-up the database, and one thing I would like to > > enforce is that phone numbers consist of the following: 01234567890+-() > > > > In the future, if you fill out the phone line with something like: > > 1-543.433.8765 (this is my pager) > > what gets store in the database, and displayed in whois: > > (543) 433-8765 > > Well at least for those phone number in the US. Other country phone > > numbers would be stored as entered. Just working on uniformity. > > > > Ginny > > > > On Wed, 27 Dec 2000, Alex Kamantauskas wrote: > > > > > > > > Most people I know change pager services so frequently that maintaining > > > the POC pager number record would become a pain... > > > > > > On Wed, 27 Dec 2000, ginny listman wrote: > > > > > > > Do we need the ability to allow a POC to enter a pager phone number? > > > > > > > > Ginny > > > > > > > > > > -- > > > Alex Kamantauskas > > > alexk at tugger.net > > > > > > > > > -- > Alex Kamantauskas > alexk at tugger.net > From alexk at tugger.net Wed Dec 27 13:03:05 2000 From: alexk at tugger.net (Alex Kamantauskas) Date: Wed, 27 Dec 2000 13:03:05 -0500 (EST) Subject: phone types In-Reply-To: Message-ID: On Wed, 27 Dec 2000, ginny listman wrote: > Well, a cell (or mobil) phone is really a commercial phone, both are > voice. When placing a call, It doesn't matter if I'm calling a mobil > phone. I'm just expecting a voice on the other end. I suppose I was viewing the cell/mobil phone as a secondary voice number -- if you call the primary Commercial number, and you get no answer (or voice mail), you can then try the secondary Commercial number (if one is supplied) and try your luck with the cell phone. > Although pager numbers can be voice, it would be nice to know that you > will be dialing a pager and may have to enter a number. As far as other > devices, what else would you like to see? > (Any objections?) This leaves, Commercial, Fax and Pager so far. Not really, I'm just playing devil's advocate -- Alex Kamantauskas alexk at tugger.net From ginny at arin.net Wed Dec 27 13:07:10 2000 From: ginny at arin.net (ginny listman) Date: Wed, 27 Dec 2000 13:07:10 -0500 (EST) Subject: phone types In-Reply-To: Message-ID: On Wed, 27 Dec 2000, Alex Kamantauskas wrote: > > On Wed, 27 Dec 2000, ginny listman wrote: > > > Well, a cell (or mobil) phone is really a commercial phone, both are > > voice. When placing a call, It doesn't matter if I'm calling a mobil > > phone. I'm just expecting a voice on the other end. > > I suppose I was viewing the cell/mobil phone as a secondary voice number > -- if you call the primary Commercial number, and you get no answer (or > voice mail), you can then try the secondary Commercial number (if one is > supplied) and try your luck with the cell phone. FYI, We will be allowing for multiple phones of all types. > > > Although pager numbers can be voice, it would be nice to know that you > > will be dialing a pager and may have to enter a number. As far as other > > devices, what else would you like to see? > > (Any objections?) This leaves, Commercial, Fax and Pager so far. > > Not really, I'm just playing devil's advocate > > -- > Alex Kamantauskas > alexk at tugger.net > From woeber at cc.univie.ac.at Wed Dec 27 13:12:28 2000 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 27 Dec 2000 19:12:28 +0100 Subject: phone types Message-ID: <009F53C1.6ADCB90E.9@cc.univie.ac.at> >I'm looking to clean-up the database, and one thing I would like to >enforce is that phone numbers consist of the following: 01234567890+-() That is probably a good idea. Whatever it is, the characterset should be uniform across the IP (and routing) registries! >In the future, if you fill out the phone line with something like: >1-543.433.8765 (this is my pager) >what gets store in the database, and displayed in whois: >(543) 433-8765 This does not sound like a good idea to me. Throwing info away and/or re-writing user-supplied info can get you into trouble - unless you know *very* well what you are doing (e.g. by looking at very well-defined semantics). >Well at least for those phone number in the US. Other country phone >numbers would be stored as entered. Just working on uniformity. Doesn't sound like a uniform approach to me :-) Is there any harm done to any US/CA-based consumers of the data to include the +1 ? >Ginny Wilfried. From alexk at tugger.net Wed Dec 27 13:16:08 2000 From: alexk at tugger.net (Alex Kamantauskas) Date: Wed, 27 Dec 2000 13:16:08 -0500 (EST) Subject: phone types In-Reply-To: Message-ID: >>> Well, a cell (or mobil) phone is really a commercial phone, both are >>> voice. When placing a call, It doesn't matter if I'm calling a mobil >>> phone. I'm just expecting a voice on the other end. >> >> I suppose I was viewing the cell/mobil phone as a secondary voice number >> -- if you call the primary Commercial number, and you get no answer (or >> voice mail), you can then try the secondary Commercial number (if one is >> supplied) and try your luck with the cell phone. > > FYI, We will be allowing for multiple phones of all types. > Sounds good to me!! -- Alex Kamantauskas alexk at tugger.net From ginny at arin.net Wed Dec 27 13:32:06 2000 From: ginny at arin.net (ginny listman) Date: Wed, 27 Dec 2000 13:32:06 -0500 (EST) Subject: phone types In-Reply-To: <009F53C1.6ADCB90E.9@cc.univie.ac.at> Message-ID: On Wed, 27 Dec 2000, Wilfried Woeber, UniVie/ACOnet wrote: > >I'm looking to clean-up the database, and one thing I would like to > >enforce is that phone numbers consist of the following: 01234567890+-() > > That is probably a good idea. Whatever it is, the characterset should be > uniform across the IP (and routing) registries! Are there any other characters we should include that would take into consideration non-US, non-CA phone numbers? > > >In the future, if you fill out the phone line with something like: > >1-543.433.8765 (this is my pager) > >what gets store in the database, and displayed in whois: > >(543) 433-8765 > > This does not sound like a good idea to me. > Throwing info away and/or re-writing user-supplied info can get you into > trouble - unless you know *very* well what you are doing (e.g. by > looking at very well-defined semantics). > As I look at what is currently stored in the phone fields of the current database, making the above assumption/conversion seems reasonable. A phone number should be a phone number, and not have other info stored with it. It is my intention to define this semantics in our registration software - both web based and internal tools. Do you have a problem with the format? With or without ()? If there is another format that is more socially accepted, let me know. This format is not a definite, just an idea. > >Well at least for those phone number in the US. Other country phone > >numbers would be stored as entered. Just working on uniformity. > > Doesn't sound like a uniform approach to me :-) > Is there any harm done to any US/CA-based consumers of the data to > include the +1 ? > I guess being only familiar with US phone numbers, I'm not sure how to handle other countries. CA phone numbers are similar to US, and can be included in the same format. As far as other countries, I guess we'll handle them as we find out the proper format. I have no objections to proceeding US/CA phone numbers with +1. > >Ginny > > Wilfried. > From Mike at netwright.net Wed Dec 27 13:50:28 2000 From: Mike at netwright.net (Mike Lieberman) Date: Wed, 27 Dec 2000 11:50:28 -0700 Subject: phone types In-Reply-To: Message-ID: <000501c07035$e1c86c40$fe00a9d8@SWEETNESS> On Wed, 27 Dec 2000, Ginny Listman, ARIN wrote: > > As I look at what is currently stored in the phone fields of > the current > database, making the above assumption/conversion seems reasonable. A > phone number should be a phone number, and not have other > info stored with > it. Why? If extensions are necessary to work one's way through a PBX or a PIN for a pager, or a web address for a text paging terminal... why is a number always a number? When calling during non-business hours, many "numbers" aren't useful with extra information, such as the proper extension, or after hours contact options. Frequently the "POC" is not known as the POC by the company PBX 'operator' and is certainly not designated as such by the dialing options on the pbx. While the 'role' remains, people change, different 'desks' get assigned to the 'role' over the years. We have found the 'simple' phone number to be of marginal value many times. From ginny at arin.net Wed Dec 27 13:54:42 2000 From: ginny at arin.net (ginny listman) Date: Wed, 27 Dec 2000 13:54:42 -0500 (EST) Subject: phone types In-Reply-To: <000501c07035$e1c86c40$fe00a9d8@SWEETNESS> Message-ID: I neglected to mention, we have two fields, phone_number and phone_ext. That said, is there still a problem? On Wed, 27 Dec 2000, Mike Lieberman wrote: > On Wed, 27 Dec 2000, Ginny Listman, ARIN wrote: > > > > As I look at what is currently stored in the phone fields of > > the current > > database, making the above assumption/conversion seems reasonable. A > > phone number should be a phone number, and not have other > > info stored with > > it. > > Why? If extensions are necessary to work one's way through a PBX or a PIN for > a pager, or a web address for a text paging terminal... why is a number > always a number? > > When calling during non-business hours, many "numbers" aren't useful with > extra information, such as the proper extension, or after hours contact > options. > > Frequently the "POC" is not known as the POC by the company PBX 'operator' > and is certainly not designated as such by the dialing options on the pbx. > While the 'role' remains, people change, different 'desks' get assigned to > the 'role' over the years. > > We have found the 'simple' phone number to be of marginal value many times. > From Mike at netwright.net Wed Dec 27 14:03:39 2000 From: Mike at netwright.net (Mike Lieberman) Date: Wed, 27 Dec 2000 12:03:39 -0700 Subject: phone types In-Reply-To: Message-ID: <000601c07037$b964ff50$fe00a9d8@SWEETNESS> Yes, that goes most of the way there, so long as you don't parse the extension field for numbers and other acceptable characters. On Wed, 27 Dec 2000, Ginny Listman, ARIN wrote: > > I neglected to mention, we have two fields, phone_number and > phone_ext. > That said, is there still a problem? > > On Wed, 27 Dec 2000, Mike Lieberman wrote: > > > On Wed, 27 Dec 2000, Ginny Listman, ARIN wrote: > > > > > > As I look at what is currently stored in the phone fields of > > > the current > > > database, making the above assumption/conversion seems > reasonable. A > > > phone number should be a phone number, and not have other > > > info stored with > > > it. > > > > Why? If extensions are necessary to work one's way through > a PBX or a PIN for > > a pager, or a web address for a text paging terminal... why > is a number > > always a number? > > > > When calling during non-business hours, many "numbers" > aren't useful with > > extra information, such as the proper extension, or after > hours contact > > options. > > > > Frequently the "POC" is not known as the POC by the company > PBX 'operator' > > and is certainly not designated as such by the dialing > options on the pbx. > > While the 'role' remains, people change, different 'desks' > get assigned to > > the 'role' over the years. > > > > We have found the 'simple' phone number to be of marginal > value many times. > > > > From Greg.Sanche at attcanada.com Wed Dec 27 14:57:37 2000 From: Greg.Sanche at attcanada.com (Sanche, Greg) Date: Wed, 27 Dec 2000 12:57:37 -0700 Subject: phone types Message-ID: Ginny, can the system accept pull down options? This would help in providing consistence in what is placed within these fields. eg: pager number extension number cell/mobile number etc... Greg Sanche AT&T Canada Corp. Tel: 905 361-6142 Fax: 905 361-6001 E-Mail : gsanche at attcanada.com Greg.Sanche at attcanada.com -----Original Message----- From: Sanche, Greg Sent: Wednesday, December 27, 2000 10:53 AM To: 'ginny listman' Subject: RE: phone types Pager number is one option, but I would strongly recommend a company's 1-800 NOC number which would have that person's pager number. This would limited the pager abuse on non critical issues. I guess it would depend on the size of the POC in determining if an 1-800 number could be used. Greg Sanche AT&T Canada Corp. Tel: 905 361-6142 Fax: 905 361-6001 E-Mail : gsanche at attcanada.com Greg.Sanche at attcanada.com -----Original Message----- From: ginny listman [mailto:ginny at arin.net] Sent: Wednesday, December 27, 2000 9:35 AM To: dbwg at arin.net Subject: phone types Do we need the ability to allow a POC to enter a pager phone number? Ginny From ginny at arin.net Wed Dec 27 15:14:12 2000 From: ginny at arin.net (ginny listman) Date: Wed, 27 Dec 2000 15:14:12 -0500 (EST) Subject: phone types In-Reply-To: Message-ID: Assuming the web-based application is used, pull-down and/or selection buttons will be used. However, ARIN will continue to provide a text-based application, that may be more difficult to use, and will require the user to read the directions more carefully. On Wed, 27 Dec 2000, Sanche, Greg wrote: > > Ginny, can the system accept pull down options? This would help in > providing consistence in what is placed within these fields. > > eg: pager number > extension number > cell/mobile number > etc... > > Greg Sanche > AT&T Canada Corp. > Tel: 905 361-6142 Fax: 905 361-6001 > E-Mail : gsanche at attcanada.com > Greg.Sanche at attcanada.com > > > > -----Original Message----- > From: Sanche, Greg > Sent: Wednesday, December 27, 2000 10:53 AM > To: 'ginny listman' > Subject: RE: phone types > > > > Pager number is one option, but I would strongly recommend a company's > 1-800 NOC number > which would have that person's pager number. This would limited the pager > abuse on > non critical issues. I guess it would depend on the size of the POC in > determining if > an 1-800 number could be used. > > Greg Sanche > AT&T Canada Corp. > Tel: 905 361-6142 Fax: 905 361-6001 > E-Mail : gsanche at attcanada.com > Greg.Sanche at attcanada.com > > > > -----Original Message----- > From: ginny listman [mailto:ginny at arin.net] > Sent: Wednesday, December 27, 2000 9:35 AM > To: dbwg at arin.net > Subject: phone types > > > Do we need the ability to allow a POC to enter a pager phone number? > > Ginny > From ginny at arin.net Wed Dec 27 15:16:16 2000 From: ginny at arin.net (ginny listman) Date: Wed, 27 Dec 2000 15:16:16 -0500 (EST) Subject: phone types In-Reply-To: <000601c07037$b964ff50$fe00a9d8@SWEETNESS> Message-ID: The extension field will be free-form. However, we will attempt to provide guidelines to follow regarding what should/should not be entered. Ginny On Wed, 27 Dec 2000, Mike Lieberman wrote: > Yes, that goes most of the way there, so long as you don't parse the > extension field for numbers and other acceptable characters. > > On Wed, 27 Dec 2000, Ginny Listman, ARIN wrote: > > > > I neglected to mention, we have two fields, phone_number and > > phone_ext. > > That said, is there still a problem? > > > > On Wed, 27 Dec 2000, Mike Lieberman wrote: > > > > > On Wed, 27 Dec 2000, Ginny Listman, ARIN wrote: > > > > > > > > As I look at what is currently stored in the phone fields of > > > > the current > > > > database, making the above assumption/conversion seems > > reasonable. A > > > > phone number should be a phone number, and not have other > > > > info stored with > > > > it. > > > > > > Why? If extensions are necessary to work one's way through > > a PBX or a PIN for > > > a pager, or a web address for a text paging terminal... why > > is a number > > > always a number? > > > > > > When calling during non-business hours, many "numbers" > > aren't useful with > > > extra information, such as the proper extension, or after > > hours contact > > > options. > > > > > > Frequently the "POC" is not known as the POC by the company > > PBX 'operator' > > > and is certainly not designated as such by the dialing > > options on the pbx. > > > While the 'role' remains, people change, different 'desks' > > get assigned to > > > the 'role' over the years. > > > > > > We have found the 'simple' phone number to be of marginal > > value many times. > > > > > > > > From ginny at arin.net Wed Dec 27 16:08:54 2000 From: ginny at arin.net (ginny listman) Date: Wed, 27 Dec 2000 16:08:54 -0500 (EST) Subject: Proceeding forward Message-ID: According to the discussion on this list, we will proceed as follows: There are three types of entities: Organizations, ASes and Networks (all ASes and Networks must have an associated Organization, ie ASes and Networks are the Organizations' resources) There will be the following types of POCs, with the following requirements: Administrative Contact (AD) - one and only one, mandatory for an Organization, optional for AS or Network Billing Contact (BI) - one and only one, mandatory for an Organization with ASes or Primary Allocated Networks, not available for Networks and ASes Membership Contact (ME) - zero or one, mandatory for an Organization that is a member, not permitted for ASes, Networks and non-member Organizations Technical Contact (TE) - one or many, optional for an Organization, mandatory for ASes or Network w/o an Organization TE, optional otherwise Abuse Contact (AB), NOC Contact (NO) - zero, one or many, optional for an Organization, AS or Network (these are new, and will be incorporated into the new schema) Am I forgetting anything? Phones will be stored in the international format as such for US/CA: +1-999-999-9999. We will get the format for other countries and implement those as well. The format of dash (-) separated blocks of numbers will be followed for all numbers. All POCs can have the following phones: Commercial Voice - one or many, mandatory Fax - zero, one or many, optional Voicemail - zero, one or many, optional (do we need this?) Mobile/Cell - zero, one or many, optional Pager - zero, one or many, optional One additional comment, do we need to distinguish between text email and pager email? Ginny From ginny at arin.net Wed Dec 27 16:09:42 2000 From: ginny at arin.net (ginny listman) Date: Wed, 27 Dec 2000 16:09:42 -0500 (EST) Subject: phone types (fwd) Message-ID: are dots (.) better than dashes (-)? ---------- Forwarded message ---------- Date: Wed, 27 Dec 2000 12:51:56 -0800 From: Paul Ebersman To: ginny listman Subject: Re: phone types ginny> Are there any other characters we should include that would ginny> take into consideration non-US, non-CA phone numbers? Using a period instead of a hyphen is more accepted outside the US and is becoming more common in the US. I vaguely remember it being some ISO standard to do so, but don't quote me. +. where would be .. in the US would probably be "acceptable" all over the world. From jkd at cyberspace.org Wed Dec 27 18:06:45 2000 From: jkd at cyberspace.org (John K. Doyle, Jr.) Date: Wed, 27 Dec 2000 18:06:45 -0500 (EST) Subject: phone types (fwd) In-Reply-To: Message-ID: Ginny, One possible way to resolve the phone number formatting issue would be to store it in ITU standard form. My memory may be foggy, but I believe that the old "CCITT" (now ITU) standard that is relevant is "E.163" John On Wed, 27 Dec 2000, ginny listman wrote: > are dots (.) better than dashes (-)? > > ---------- Forwarded message ---------- > Date: Wed, 27 Dec 2000 12:51:56 -0800 > From: Paul Ebersman > To: ginny listman > Subject: Re: phone types > > > ginny> Are there any other characters we should include that would > ginny> take into consideration non-US, non-CA phone numbers? > > Using a period instead of a hyphen is more accepted outside the US and > is becoming more common in the US. I vaguely remember it being some > ISO standard to do so, but don't quote me. > > +. where > would be .. in the US would probably be > "acceptable" all over the world. > > From linda at sat-tel.com Thu Dec 28 11:48:08 2000 From: linda at sat-tel.com (Linda) Date: Thu, 28 Dec 2000 11:48:08 -0500 Subject: [Fwd: Re: phone types] Message-ID: <3A4B6EC8.4ECC39BD@sat-tel.com> >I guess being only familiar with US phone numbers, I'm not sure how to >handle other countries. CA phone numbers are similar to US, and can be >included in the same format. As far as other countries, I guess we'll >handle them as we find out the proper format. I have no objections to >proceeding US/CA phone numbers with +1. > >Ginny The NANP (North American Numbering Plan) (1+) covers North America as well as the most of the Caribbean Islands as listed below. It should be the responsibility of the person submitting the contact information to include either the 1 or 011 contact number. ARIN should not have to take time to figure out if the number lies within the NANP or if the number is an international number. I think it would be wise to list either the 1 or 011 for contact numbers as ARIN's regions covers the North America Numbering Plan as well as international numbers. 50 United States Alberta Anguilla Antigua Bahamas Basseterre Bermuda British Columbia British Virgin Islands Cayman Islands District of Columbia Dominica Dominican Republic Grenada Jamaica Manitoba Montserrat New Brunswick Newfoundland Nova Scotia Ontario Prince Edward Island Puerto Rico Quebec Puerto Rico Saskatchewan St. Kitts/Nevis St. Lucia St. Vincent/Grenadines Turks & Caicos Trinidad and Tobago US Virgin Islands Yukon and NorthwestTerritories Linda From bmjames at swbell.net Thu Dec 28 12:00:49 2000 From: bmjames at swbell.net (Bruce) Date: Thu, 28 Dec 2000 11:00:49 -0600 Subject: phone types] References: <3A4B6EC8.4ECC39BD@sat-tel.com> Message-ID: <000401c070ef$baffe100$847fd840@a> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I agree It should be the responsibility of the person submitting the contact information to include either the 1 or 011 contact number. ARIN should not have to take time to figure out if the number lies within the NANP or if the number is an international number. - ----- Original Message ----- From: "Linda" To: "ARIN - DB WG" ; "ARIN - Ginny Listman" Sent: Thursday, December 28, 2000 10:48 AM Subject: [Fwd: Re: phone types] >I guess being only familiar with US phone numbers, I'm not sure how >to handle other countries. CA phone numbers are similar to US, and >can be included in the same format. As far as other countries, I >guess we'll handle them as we find out the proper format. I have no >objections to proceeding US/CA phone numbers with +1. > >Ginny The NANP (North American Numbering Plan) (1+) covers North America as well as the most of the Caribbean Islands as listed below. It should be the responsibility of the person submitting the contact information to include either the 1 or 011 contact number. ARIN should not have to take time to figure out if the number lies within the NANP or if the number is an international number. I think it would be wise to list either the 1 or 011 for contact numbers as ARIN's regions covers the North America Numbering Plan as well as international numbers. 50 United States Alberta Anguilla Antigua Bahamas Basseterre Bermuda British Columbia British Virgin Islands Cayman Islands District of Columbia Dominica Dominican Republic Grenada Jamaica Manitoba Montserrat New Brunswick Newfoundland Nova Scotia Ontario Prince Edward Island Puerto Rico Quebec Puerto Rico Saskatchewan St. Kitts/Nevis St. Lucia St. Vincent/Grenadines Turks & Caicos Trinidad and Tobago US Virgin Islands Yukon and NorthwestTerritories Linda -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.8 Comment: Signed and Sealed. iQA/AwUBOktxvi5+FY5y8qdIEQJvOgCgjv7mFGjPUjrpJP31bbqJpYt7ho8An157 uZ//XswC2Wok9Rbnk1GfwTXz =+xOY -----END PGP SIGNATURE----- From ginny at arin.net Fri Dec 29 08:57:02 2000 From: ginny at arin.net (ginny listman) Date: Fri, 29 Dec 2000 08:57:02 -0500 (EST) Subject: [Fwd: Re: phone types] In-Reply-To: <3A4B6EC8.4ECC39BD@sat-tel.com> Message-ID: On Thu, 28 Dec 2000, Linda wrote: > The NANP (North American Numbering Plan) (1+) covers North America as > well as the most of the Caribbean Islands as listed below. It should be > the responsibility of the person submitting the contact information to > include either the 1 or 011 contact number. ARIN should not have to > take time to figure out if the number lies within the NANP or if the > number is an international number. This is a great idea, but if we want valid data in the database, we will have to do some form of checking. Totally relying on the user to full read the instructions, and put valid information on every line, has created a database full of bogus information. I just did a database query and came up with close to 15K POCs that have an mailbox of nomailbox at NOWHERE. This is useless information, that we should not be storing. Going forward, we want to avoid storing or displaying invalid/useless information. > > Linda > From linda at sat-tel.com Fri Dec 29 09:53:47 2000 From: linda at sat-tel.com (Linda) Date: Fri, 29 Dec 2000 09:53:47 -0500 Subject: [Fwd: Re: phone types] References: Message-ID: <3A4CA57A.5F0543F2@sat-tel.com> Would it be difficult for ARIN to check when the template is parsed for either a 1 or 011 as the leading numbers for the contact number? If a person submits invalid information to ARIN and after it is parsed and found to contain errors a rejection message as is currently sent should be sent to the person so they may correct their error. I do not see a problem with asking people to include the 1 or 011 with their contact number. As for the nomailbox at NOWHERE will ARIN ask those POCs to give a correct mailbox now that you have found their address to be invalid? Linda ginny listman wrote: > On Thu, 28 Dec 2000, Linda wrote: > > > The NANP (North American Numbering Plan) (1+) covers North America as > > well as the most of the Caribbean Islands as listed below. It should be > > the responsibility of the person submitting the contact information to > > include either the 1 or 011 contact number. ARIN should not have to > > take time to figure out if the number lies within the NANP or if the > > number is an international number. > > This is a great idea, but if we want valid data in the database, we will > have to do some form of checking. Totally relying on the user to full > read the instructions, and put valid information on every line, has > created a database full of bogus information. I just did a database > query and came up with close to 15K POCs that have an mailbox of > nomailbox at NOWHERE. This is useless information, that we should not be > storing. Going forward, we want to avoid storing or displaying > invalid/useless information. > > > > > Linda > > From ginny at arin.net Fri Dec 29 10:01:30 2000 From: ginny at arin.net (ginny listman) Date: Fri, 29 Dec 2000 10:01:30 -0500 (EST) Subject: [Fwd: Re: phone types] In-Reply-To: <3A4CA57A.5F0543F2@sat-tel.com> Message-ID: It would not be difficult to check. However, a country code is a required field. If the country code is US or CA, if the +1 was not provided, the software should be intellegent enough to add it. I want to avoid sending back errors that would be easy for us to fix. If the information is input via the web, it would not allow you to submit. As far as sending a message back regarding invalid information, that is one of our goals. Ideally, manually processing by RSG should be at a minimum. As far as going back and asking for valid information for the "nomailbox" mailboxes, we plan on doing a re-registration to verify the existing data in the database. However, this will probably be 2-3 years away. This rule will be enforced going forward. Ginny On Fri, 29 Dec 2000, Linda wrote: > Would it be difficult for ARIN to check when the template is parsed for either > a 1 or 011 as the leading numbers for the contact number? If a person submits > invalid information to ARIN and after it is parsed and found to contain errors > a rejection message as is currently sent should be sent to the person so they > may correct their error. I do not see a problem with asking people to include > the 1 or 011 with their contact number. As for the nomailbox at NOWHERE will > ARIN ask those POCs to give a correct mailbox now that you have found their > address to be invalid? > > Linda > > ginny listman wrote: > > > On Thu, 28 Dec 2000, Linda wrote: > > > > > The NANP (North American Numbering Plan) (1+) covers North America as > > > well as the most of the Caribbean Islands as listed below. It should be > > > the responsibility of the person submitting the contact information to > > > include either the 1 or 011 contact number. ARIN should not have to > > > take time to figure out if the number lies within the NANP or if the > > > number is an international number. > > > > This is a great idea, but if we want valid data in the database, we will > > have to do some form of checking. Totally relying on the user to full > > read the instructions, and put valid information on every line, has > > created a database full of bogus information. I just did a database > > query and came up with close to 15K POCs that have an mailbox of > > nomailbox at NOWHERE. This is useless information, that we should not be > > storing. Going forward, we want to avoid storing or displaying > > invalid/useless information. > > > > > > > > Linda > > > > From linda at sat-tel.com Fri Dec 29 10:38:04 2000 From: linda at sat-tel.com (Linda) Date: Fri, 29 Dec 2000 10:38:04 -0500 Subject: [Fwd: Re: phone types] References: Message-ID: <3A4CAFDB.4F99646E@sat-tel.com> ginny listman wrote: > It would not be difficult to check. However, a country code is a required > field. If the country code is US or CA, if the +1 was not provided, the > software should be intellegent enough to add it. I want to avoid sending > back errors that would be easy for us to fix. If the information is input > via the web, it would not allow you to submit. >Does ARIN have a plan for the rest of the North American Numbering Plan community, excluding the US and Canada? > > > As far as sending a message back regarding invalid information, that is > one of our goals. Ideally, manually processing by RSG should be at a > minimum. > > As far as going back and asking for valid information for the "nomailbox" > mailboxes, we plan on doing a re-registration to verify the existing data > in the database. However, this will probably be 2-3 years away. This > rule will be enforced going forward. >Having invalid information for POCs makes more work for all parties involved including ARIN staff. > >Linda > > > Ginny > > On Fri, 29 Dec 2000, Linda wrote: > > > Would it be difficult for ARIN to check when the template is parsed for either > > a 1 or 011 as the leading numbers for the contact number? If a person submits > > invalid information to ARIN and after it is parsed and found to contain errors > > a rejection message as is currently sent should be sent to the person so they > > may correct their error. I do not see a problem with asking people to include > > the 1 or 011 with their contact number. As for the nomailbox at NOWHERE will > > ARIN ask those POCs to give a correct mailbox now that you have found their > > address to be invalid? > > > > Linda > > > > ginny listman wrote: > > > > > On Thu, 28 Dec 2000, Linda wrote: > > > > > > > The NANP (North American Numbering Plan) (1+) covers North America as > > > > well as the most of the Caribbean Islands as listed below. It should be > > > > the responsibility of the person submitting the contact information to > > > > include either the 1 or 011 contact number. ARIN should not have to > > > > take time to figure out if the number lies within the NANP or if the > > > > number is an international number. > > > > > > This is a great idea, but if we want valid data in the database, we will > > > have to do some form of checking. Totally relying on the user to full > > > read the instructions, and put valid information on every line, has > > > created a database full of bogus information. I just did a database > > > query and came up with close to 15K POCs that have an mailbox of > > > nomailbox at NOWHERE. This is useless information, that we should not be > > > storing. Going forward, we want to avoid storing or displaying > > > invalid/useless information. > > > > > > > > > > > Linda > > > > > > From ginny at arin.net Fri Dec 29 10:45:09 2000 From: ginny at arin.net (ginny listman) Date: Fri, 29 Dec 2000 10:45:09 -0500 (EST) Subject: [Fwd: Re: phone types] In-Reply-To: <3A4CAFDB.4F99646E@sat-tel.com> Message-ID: On Fri, 29 Dec 2000, Linda wrote: > > > ginny listman wrote: > > > It would not be difficult to check. However, a country code is a required > > field. If the country code is US or CA, if the +1 was not provided, the > > software should be intellegent enough to add it. I want to avoid sending > > back errors that would be easy for us to fix. If the information is input > > via the web, it would not allow you to submit. > > >Does ARIN have a plan for the rest of the North American Numbering Plan community, > excluding the US and Canada? > Right now, no. But we will be discussing it in the future. > > > > > > As far as sending a message back regarding invalid information, that is > > one of our goals. Ideally, manually processing by RSG should be at a > > minimum. > > > > As far as going back and asking for valid information for the "nomailbox" > > mailboxes, we plan on doing a re-registration to verify the existing data > > in the database. However, this will probably be 2-3 years away. This > > rule will be enforced going forward. > > >Having invalid information for POCs makes more work for all parties involved > including ARIN staff. > > > >Linda > > > > > > > Ginny > > > > On Fri, 29 Dec 2000, Linda wrote: > > > > > Would it be difficult for ARIN to check when the template is parsed for either > > > a 1 or 011 as the leading numbers for the contact number? If a person submits > > > invalid information to ARIN and after it is parsed and found to contain errors > > > a rejection message as is currently sent should be sent to the person so they > > > may correct their error. I do not see a problem with asking people to include > > > the 1 or 011 with their contact number. As for the nomailbox at NOWHERE will > > > ARIN ask those POCs to give a correct mailbox now that you have found their > > > address to be invalid? > > > > > > Linda > > > > > > ginny listman wrote: > > > > > > > On Thu, 28 Dec 2000, Linda wrote: > > > > > > > > > The NANP (North American Numbering Plan) (1+) covers North America as > > > > > well as the most of the Caribbean Islands as listed below. It should be > > > > > the responsibility of the person submitting the contact information to > > > > > include either the 1 or 011 contact number. ARIN should not have to > > > > > take time to figure out if the number lies within the NANP or if the > > > > > number is an international number. > > > > > > > > This is a great idea, but if we want valid data in the database, we will > > > > have to do some form of checking. Totally relying on the user to full > > > > read the instructions, and put valid information on every line, has > > > > created a database full of bogus information. I just did a database > > > > query and came up with close to 15K POCs that have an mailbox of > > > > nomailbox at NOWHERE. This is useless information, that we should not be > > > > storing. Going forward, we want to avoid storing or displaying > > > > invalid/useless information. > > > > > > > > > > > > > > Linda > > > > > > > > > From linda at sat-tel.com Fri Dec 29 11:27:53 2000 From: linda at sat-tel.com (Linda) Date: Fri, 29 Dec 2000 11:27:53 -0500 Subject: Phone Types Message-ID: <3A4CBB89.5C73F6D6@sat-tel.com> Linda Wrote: > >Does ARIN have a plan for the rest of the North American Numbering Plan community, > excluding the US and Canada? Ginny Wrote: Right now, no. But we will be discussing it in the future. Linda Wrote: The list of countries that I sent yesterday should include all of the North American Numbering Plan. I can double check my list for accuracy if that would help and get back to you. If the check was done by country it would be easy enough to automate adding the 1+. Linda -------------- next part -------------- An HTML attachment was scrubbed... URL: