From richardj at arin.net Tue Feb 12 16:08:05 2002 From: richardj at arin.net (Richard Jimmerson) Date: Tue, 12 Feb 2002 16:08:05 -0500 Subject: ARIN Database and Template Transition Message-ID: <010101c1b409$5da0a900$e7fc95c0@cobalt> ARIN will transition to a new database and templates in June of 2002. Over the past year, ARIN has developed requirements for the new database with input from members of the ARIN user community at ARIN meetings and on the DB Working Group mailing list, dbwg at arin.net. A training program describing the new database and templates is currently under development. This training program will be offered in person at the upcoming ARIN meeting in April, and on-line for those who are unable to attend the meeting. Training will focus primarily on the new objects of the ARIN database and the newly designed templates. The newly designed templates are available now at: ftp://ftp.arin.net/pub/new-templates/ The templates incorporate the comments submitted via the DB Working Group with the efforts of Registration Services and Engineering Departments. ARIN is providing these templates well in advance of the conversion, and is encouraging those ISPs that have auto-generated SWIPs to revise those scripts, and submit templates as beta tests. ARIN will solicit beta testers from the community for the new database and templates. Participation will be open to all interested parties. More information about beta testing will soon become available. Regards, Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) From dispensa at positivenetworks.net Fri Feb 15 00:39:54 2002 From: dispensa at positivenetworks.net (Steve Dispensa) Date: Thu, 14 Feb 2002 23:39:54 -0600 Subject: Should registered space or reserved space be used? Message-ID: <000801c1b5e3$32ce5070$5a681a41@stevewinbook> [If this is not an appropriate forum for this question, I would appreciate being pointed in the right direction.] I am working on a VPN service provider network whose purpose is to connect remote users over L2TP to remote networks. All L2TP connections and all remote networks are aggregated in a POP. Traffic is switched in the POP from L2TP tunnels into appropriate remote networks and back again. An added requirement is that the case of overlapping IP address space among the remote networks must be handled properly. It seems particularly likely that many remote networks will choose to use one or more of the RFC 1918 blocks. Therefore, the probability of address space collision is quite high. The solution to this problem depends on the L2TP connections being given "unique" addresses within the scope of the VPN service provider's routing domain. In other words: - no two L2TP connections can have the same address - no L2TP address can fall within any network block in use in any remote network One final point: it is highly unlikely that the L2TP interfaces will ever be given a direct (non-NATted) route to the Internet. There are three options that I can see for addressing the L2TP connections: 1) Since Internet routability is not a concern, use RFC 1918 space. However, this violates the "no collisions" requirement. 2) Since Internet routability is not a concern and since no collisions are allowed, use "illegal" addresses, such as addresses out of Class E space or out of "permanently reserved" blocks (1/8 for instance). However, this seems like a Bad Idea to me. 3) Address all requirements by using registered space. However, given the lack of need for Internet routability, this sure seems like a waste of space. I hate to do #3, but it seems like the best move. This might be a paltry number of addresses, or it might turn into a big drain on address space. Then again, I could be completely missing an obvious solution. What do you think? Thanks, -Steve From ginny at arin.net Tue Feb 19 16:09:02 2002 From: ginny at arin.net (ginny listman) Date: Tue, 19 Feb 2002 16:09:02 -0500 (EST) Subject: ARIN Database and Template Transition Message-ID: >From I need some clarification on a couple of things: 1) Can the wording change for the lines 2 - 19 on the Reassign-detailed to be downstream org....? 2) So now we have 4 templates to deal with instead of 1, how does this make my life easier? 3) Will all assignments now only be on bit boundaries? 4) Except for customers who want their own contact POC information associated with their WHOIS registration is there any reason to use the detailed template? 5) The templates for detailed assignment and ARIN-REALLOCATE-3.0-200201 are the exact same templates except for the template heading. Can't there just be one template with a question on is this an assignment or an allocation to a "ISP type" customer? This would get rid of one template. 6) The netmod template is now part of the SWIP process for any customer that has an org ID and we need to modify or remove the registration. And the other "LONG" forms are only for New templates for customers that need POC information associated with them. The short form is only for customers that do not have POC information associated with them. What POC information will be seen on these "shorter" form? -Dawn Martin ##################################################################### 1. Registration Action: ## Specify N for New, M for Modify or R for Return/Remove. ## **REQUIRED** 2. Network Name: ## List a network name to identify the reassigned network, ## using no more than 50 characters. **REQUIRED** 3. IP Address and Prefix or Range: ## Identify the network being assigned using either IP address ## and CIDR prefix, e.g. 10.1.0.0/19, or IP address range, ## e.g. 10.1.0.0 - 10.1.31.255. **REQUIRED** 4. Customer Name: 5a. Customer Address: 5b. Customer Address: ## Use as many Customer Address lines as needed to specify ## street address, using no more than 200 total characters. 6. Customer City: 7. Customer State/Province: 8. Customer Postal Code: 9. Customer Country Code: 10. Public Comments: ## Comments listed here will appear in ARIN's WHOIS database. END OF TEMPLATE Dawn Martin WorldCom IP Planning Analyst dawn.martin at wcom.com (703)886-4746 -----Original Message----- From: owner-arin-announce at arin.net [mailto:owner-arin-announce at arin.net]On Behalf Of Richard Jimmerson Sent: Tuesday, February 12, 2002 4:08 PM To: arin-announce at arin.net; ppml at arin.net; dbwg at arin.net Subject: ARIN Database and Template Transition ARIN will transition to a new database and templates in June of 2002. Over the past year, ARIN has developed requirements for the new database with input from members of the ARIN user community at ARIN meetings and on the DB Working Group mailing list, dbwg at arin.net. A training program describing the new database and templates is currently under development. This training program will be offered in person at the upcoming ARIN meeting in April, and on-line for those who are unable to attend the meeting. Training will focus primarily on the new objects of the ARIN database and the newly designed templates. The newly designed templates are available now at: ftp://ftp.arin.net/pub/new-templates/ The templates incorporate the comments submitted via the DB Working Group with the efforts of Registration Services and Engineering Departments. ARIN is providing these templates well in advance of the conversion, and is encouraging those ISPs that have auto-generated SWIPs to revise those scripts, and submit templates as beta tests. ARIN will solicit beta testers from the community for the new database and templates. Participation will be open to all interested parties. More information about beta testing will soon become available. Regards, Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) From richardj at arin.net Tue Feb 19 16:18:49 2002 From: richardj at arin.net (Richard Jimmerson) Date: Tue, 19 Feb 2002 16:18:49 -0500 Subject: ARIN Database and Template Transition In-Reply-To: Message-ID: <016701c1b98b$063788a0$e7fc95c0@cobalt> Hello Dawn, Thank you for taking a close look at the templates and asking for clarification. Please see the responses to your questions in-line, below. >1) Can the wording change for the lines 2 - 19 on the >Reassign-detailed to be downstream org....? In an effort to reduce the length of the labels, the word "Downstream" was not included in each line of the template (lines 2 - 19). We can expand the comment section of the template to more clearly specify that lines 2 - 19 require information about the downstream organization. >2) So now we have 4 templates to deal with instead of 1, how does this >make my life easier? I believe you are referring to the following four templates: # reallocate -- creates a registration record for a downstream ISP customer. # reassign-detailed -- creates a registration record for a downstream end-user customer who will maintain their own in-addr.arpa and POC associations. # reassign-simple -- creates a registration record for a downstream end-user customer who will not maintain their own in-addr.arpa and contact information. # netmod -- may be used by a downstream customer who has been given the authority by their upstream to maintain their own in-addr.arpa and/or contact information. Separate templates were created for reallocations and reassignments to prevent confusion between the two actions that currently exists with the single SWIP template. reassign-detailed and reassign-simple allow the upstream to provide only the data that is required, as some reassignments do not require POC and/or in-addr.arpa information different from that of the upstream. The new netmod template functions much like that of the current netmod template, but will add the ability of a downstream customer to modify their contact and in-addr.arpa information, if given prior authorization by their upstream. Some upstream providers will choose to use one or two of the template choices on a regular basis, but will have an option to use any or all of the templates if needed. >3) Will all assignments now only be on bit boundaries? Reassignments to the downstream that are not on the bit boundary will be accepted. Either CIDR notation or range will be accepted. >4) Except for customers who want their own contact POC information >associated with their WHOIS registration is there any reason to use the >detailed template? The reassign-detailed template would be used if there was a need for the downstream to maintain their own contact or in-addr.arpa information. If the downstream does not need to maintain any of this information, the reassign-simple template may be used. >5) The templates for detailed assignment and ARIN-REALLOCATE-3.0-200201 >are the exact same templates except for the template heading. Can't there >just be one template with a question on is this an assignment or an >allocation to a "ISP type" customer? This would get rid of one template. In gathering requirements for the new database and templates it was made clear to ARIN that there was a need to eliminate the confusion between making reassignments and reallocations by separating the templates. >6) The netmod template is now part of the SWIP process for any customer >that has an org ID and we need to modify or remove the registration. >And the other "LONG" forms are only for New templates for customers that >need POC information associated with them. The short form is only for >customers that do not have POC information associated with them. What >POC information will be seen on these "shorter" form? In the case of simple reassignments, the POCs will be whatever is associated with the upstream's network, either the net-tech POC or the org-tech POC. Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of ginny listman > Sent: Tuesday, February 19, 2002 4:09 PM > To: ppml at arin.net; dbwg at arin.net > Subject: RE: ARIN Database and Template Transition > > > >From > > I need some clarification on a couple of things: > > 1) Can the wording change for the lines 2 - 19 on the > Reassign-detailed to be downstream > org....? > > 2) So now we have 4 templates to deal with instead of 1, how does this > make my > life easier? > > 3) Will all assignments now only be on bit boundaries? > > 4) Except for customers who want their own contact POC information > associated > with their WHOIS registration is there any reason to use the > detailed template? > > 5) The templates for detailed assignment and > ARIN-REALLOCATE-3.0-200201 are the > exact same templates except for the template heading. Can't there > just be one > template with a question on is this an assignment or an allocation > to a "ISP type" > customer? This would get rid of one template. > > 6) The netmod template is now part of the SWIP process for any > customer that has an > org ID and we need to modify or remove the registration. And the > other "LONG" forms > are only for New templates for customers that need POC information > associated with > them. The short form is only for customers that do not have POC > information associated > with them. What POC information will be seen on these "shorter" > form? > > -Dawn Martin > > ##################################################################### > 1. Registration Action: > ## Specify N for New, M for Modify or R for Return/Remove. > ## **REQUIRED** > 2. Network Name: > ## List a network name to identify the reassigned network, > ## using no more than 50 characters. **REQUIRED** > 3. IP Address and Prefix or Range: > ## Identify the network being assigned using either IP address > ## and CIDR prefix, e.g. 10.1.0.0/19, or IP address range, > ## e.g. 10.1.0.0 - 10.1.31.255. **REQUIRED** > 4. Customer Name: > 5a. Customer Address: > 5b. Customer Address: > ## Use as many Customer Address lines as needed to specify > ## street address, using no more than 200 total characters. > 6. Customer City: > 7. Customer State/Province: > 8. Customer Postal Code: > 9. Customer Country Code: > 10. Public Comments: > ## Comments listed here will appear in ARIN's WHOIS database. > > END OF TEMPLATE > > > Dawn Martin > WorldCom IP Planning Analyst > dawn.martin at wcom.com > (703)886-4746 > > > -----Original Message----- > From: owner-arin-announce at arin.net > [mailto:owner-arin-announce at arin.net]On Behalf Of Richard Jimmerson > Sent: Tuesday, February 12, 2002 4:08 PM > To: arin-announce at arin.net; ppml at arin.net; dbwg at arin.net > Subject: ARIN Database and Template Transition > > > ARIN will transition to a new database and templates in > June of 2002. > > Over the past year, ARIN has developed requirements for the > new database with input from members of the ARIN user community > at ARIN meetings and on the DB Working Group mailing list, > dbwg at arin.net. > > A training program describing the new database and templates is > currently under development. This training program will be offered > in person at the upcoming ARIN meeting in April, and on-line for > those who are unable to attend the meeting. Training will focus > primarily on the new objects of the ARIN database and the newly > designed templates. The newly designed templates are available > now at: > ftp://ftp.arin.net/pub/new-templates/ The templates incorporate the comments submitted via the DB Working Group with the efforts of Registration Services and Engineering Departments. ARIN is providing these templates well in advance of the conversion, and is encouraging those ISPs that have auto-generated SWIPs to revise those scripts, and submit templates as beta tests. ARIN will solicit beta testers from the community for the new database and templates. Participation will be open to all interested parties. More information about beta testing will soon become available. Regards, Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) From Dawn.Martin at wcom.com Thu Feb 21 10:54:06 2002 From: Dawn.Martin at wcom.com (Dawn Martin) Date: Thu, 21 Feb 2002 10:54:06 -0500 Subject: ARIN Database and Template Transition In-Reply-To: <016701c1b98b$063788a0$e7fc95c0@cobalt> Message-ID: <001201c1baef$fec862e0$0a0a0a0a@lteng122> Richard, Is this going to be an agenda item at the next ARIN meeting? If not, can it be put on the agenda? I would really like to see some more discussion from the membership before this is implemented. I believe that this might be more of an education issue that needs to be addressed rather than changing the process for updating WHOIS. Has anyone else said anything about this or is it just me? Dawn Martin dawn.martin at wcom.com -----Original Message----- From: dbwg-request at arin.net [mailto:dbwg-request at arin.net]On Behalf Of Richard Jimmerson Sent: Tuesday, February 19, 2002 4:19 PM To: Dawn.Martin at wcom.com Cc: ppml at arin.net; dbwg at arin.net Subject: RE: ARIN Database and Template Transition Hello Dawn, Thank you for taking a close look at the templates and asking for clarification. Please see the responses to your questions in-line, below. >1) Can the wording change for the lines 2 - 19 on the >Reassign-detailed to be downstream org....? In an effort to reduce the length of the labels, the word "Downstream" was not included in each line of the template (lines 2 - 19). We can expand the comment section of the template to more clearly specify that lines 2 - 19 require information about the downstream organization. >2) So now we have 4 templates to deal with instead of 1, how does this >make my life easier? I believe you are referring to the following four templates: # reallocate -- creates a registration record for a downstream ISP customer. # reassign-detailed -- creates a registration record for a downstream end-user customer who will maintain their own in-addr.arpa and POC associations. # reassign-simple -- creates a registration record for a downstream end-user customer who will not maintain their own in-addr.arpa and contact information. # netmod -- may be used by a downstream customer who has been given the authority by their upstream to maintain their own in-addr.arpa and/or contact information. Separate templates were created for reallocations and reassignments to prevent confusion between the two actions that currently exists with the single SWIP template. reassign-detailed and reassign-simple allow the upstream to provide only the data that is required, as some reassignments do not require POC and/or in-addr.arpa information different from that of the upstream. The new netmod template functions much like that of the current netmod template, but will add the ability of a downstream customer to modify their contact and in-addr.arpa information, if given prior authorization by their upstream. Some upstream providers will choose to use one or two of the template choices on a regular basis, but will have an option to use any or all of the templates if needed. >3) Will all assignments now only be on bit boundaries? Reassignments to the downstream that are not on the bit boundary will be accepted. Either CIDR notation or range will be accepted. >4) Except for customers who want their own contact POC information >associated with their WHOIS registration is there any reason to use the >detailed template? The reassign-detailed template would be used if there was a need for the downstream to maintain their own contact or in-addr.arpa information. If the downstream does not need to maintain any of this information, the reassign-simple template may be used. >5) The templates for detailed assignment and ARIN-REALLOCATE-3.0-200201 >are the exact same templates except for the template heading. Can't there >just be one template with a question on is this an assignment or an >allocation to a "ISP type" customer? This would get rid of one template. In gathering requirements for the new database and templates it was made clear to ARIN that there was a need to eliminate the confusion between making reassignments and reallocations by separating the templates. >6) The netmod template is now part of the SWIP process for any customer >that has an org ID and we need to modify or remove the registration. >And the other "LONG" forms are only for New templates for customers that >need POC information associated with them. The short form is only for >customers that do not have POC information associated with them. What >POC information will be seen on these "shorter" form? In the case of simple reassignments, the POCs will be whatever is associated with the upstream's network, either the net-tech POC or the org-tech POC. Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of ginny listman > Sent: Tuesday, February 19, 2002 4:09 PM > To: ppml at arin.net; dbwg at arin.net > Subject: RE: ARIN Database and Template Transition > > > >From > > I need some clarification on a couple of things: > > 1) Can the wording change for the lines 2 - 19 on the > Reassign-detailed to be downstream > org....? > > 2) So now we have 4 templates to deal with instead of 1, how does this > make my > life easier? > > 3) Will all assignments now only be on bit boundaries? > > 4) Except for customers who want their own contact POC information > associated > with their WHOIS registration is there any reason to use the > detailed template? > > 5) The templates for detailed assignment and > ARIN-REALLOCATE-3.0-200201 are the > exact same templates except for the template heading. Can't there > just be one > template with a question on is this an assignment or an allocation > to a "ISP type" > customer? This would get rid of one template. > > 6) The netmod template is now part of the SWIP process for any > customer that has an > org ID and we need to modify or remove the registration. And the > other "LONG" forms > are only for New templates for customers that need POC information > associated with > them. The short form is only for customers that do not have POC > information associated > with them. What POC information will be seen on these "shorter" > form? > > -Dawn Martin > > ##################################################################### > 1. Registration Action: > ## Specify N for New, M for Modify or R for Return/Remove. > ## **REQUIRED** > 2. Network Name: > ## List a network name to identify the reassigned network, > ## using no more than 50 characters. **REQUIRED** > 3. IP Address and Prefix or Range: > ## Identify the network being assigned using either IP address > ## and CIDR prefix, e.g. 10.1.0.0/19, or IP address range, > ## e.g. 10.1.0.0 - 10.1.31.255. **REQUIRED** > 4. Customer Name: > 5a. Customer Address: > 5b. Customer Address: > ## Use as many Customer Address lines as needed to specify > ## street address, using no more than 200 total characters. > 6. Customer City: > 7. Customer State/Province: > 8. Customer Postal Code: > 9. Customer Country Code: > 10. Public Comments: > ## Comments listed here will appear in ARIN's WHOIS database. > > END OF TEMPLATE > > > Dawn Martin > WorldCom IP Planning Analyst > dawn.martin at wcom.com > (703)886-4746 > > > -----Original Message----- > From: owner-arin-announce at arin.net > [mailto:owner-arin-announce at arin.net]On Behalf Of Richard Jimmerson > Sent: Tuesday, February 12, 2002 4:08 PM > To: arin-announce at arin.net; ppml at arin.net; dbwg at arin.net > Subject: ARIN Database and Template Transition > > > ARIN will transition to a new database and templates in > June of 2002. > > Over the past year, ARIN has developed requirements for the > new database with input from members of the ARIN user community > at ARIN meetings and on the DB Working Group mailing list, > dbwg at arin.net. > > A training program describing the new database and templates is > currently under development. This training program will be offered > in person at the upcoming ARIN meeting in April, and on-line for > those who are unable to attend the meeting. Training will focus > primarily on the new objects of the ARIN database and the newly > designed templates. The newly designed templates are available > now at: > ftp://ftp.arin.net/pub/new-templates/ The templates incorporate the comments submitted via the DB Working Group with the efforts of Registration Services and Engineering Departments. ARIN is providing these templates well in advance of the conversion, and is encouraging those ISPs that have auto-generated SWIPs to revise those scripts, and submit templates as beta tests. ARIN will solicit beta testers from the community for the new database and templates. Participation will be open to all interested parties. More information about beta testing will soon become available. Regards, Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) From richardj at arin.net Thu Feb 21 12:41:36 2002 From: richardj at arin.net (Richard Jimmerson) Date: Thu, 21 Feb 2002 12:41:36 -0500 Subject: ARIN Database and Template Transition In-Reply-To: <001201c1baef$fec862e0$0a0a0a0a@lteng122> Message-ID: <00b401c1baff$027d2fb0$e7fc95c0@cobalt> Hello Dawn, > Is this going to be an agenda item at the next ARIN meeting? If not, > can it be put on the agenda? I would really like to see some more > discussion from the membership before this is implemented. ARIN has been working with its members and the general ARIN user community for the past year to finalize plans for a new database schema and templates. ARIN's last two public policy meetings (April and October 2001) featured discussions about the new database schema and templates. On both occasions, the location of the templates on the ARIN FTP site was announced and comments were solicited. The templates that are to be released in June are a result of the feedback received following these two meetings. The next ARIN meeting will also feature the new templates, but in their final form, as part of a tutorial. > Has anyone else said anything about this or is it just me? Other than your own, ARIN has only received messages indicating an interest to participate in upcoming beta-testing of the new database and templates in response to the February 12 announcement to this list. The instructions of two of the new templates have been modified based on your feedback. Best Regards, Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Dawn Martin > Sent: Thursday, February 21, 2002 10:54 AM > To: richardj at arin.net > Cc: ppml at arin.net; dbwg at arin.net > Subject: RE: ARIN Database and Template Transition > > > Richard, > > Is this going to be an agenda item at the next ARIN meeting? If not, > can it be > put on the agenda? I would really like to see some more discussion > from the membership > before this is implemented. I believe that this might be more of an > education > issue that needs to be addressed rather than changing the process for > updating WHOIS. > Has anyone else said anything about this or is it just me? > > Dawn Martin > dawn.martin at wcom.com > > -----Original Message----- > From: dbwg-request at arin.net [mailto:dbwg-request at arin.net]On Behalf Of > Richard Jimmerson > Sent: Tuesday, February 19, 2002 4:19 PM > To: Dawn.Martin at wcom.com > Cc: ppml at arin.net; dbwg at arin.net > Subject: RE: ARIN Database and Template Transition > > > Hello Dawn, > > Thank you for taking a close look at the templates and asking > for clarification. Please see the responses to your questions > in-line, below. > > >1) Can the wording change for the lines 2 - 19 on the > >Reassign-detailed to be downstream org....? > > In an effort to reduce the length of the labels, the word "Downstream" > was not included in each line of the template (lines 2 - 19). We can > expand the comment section of the template to more clearly specify > that lines 2 - 19 require information about the downstream > organization. > > >2) So now we have 4 templates to deal with instead of 1, how does > this > >make my life easier? > > I believe you are referring to the following four templates: > > # reallocate -- creates a registration record for a downstream ISP > customer. > > # reassign-detailed -- creates a registration record for a downstream > end-user customer who will maintain their own in-addr.arpa and POC > associations. > > # reassign-simple -- creates a registration record for a downstream > end-user customer who will not maintain their own in-addr.arpa and > contact information. > > # netmod -- may be used by a downstream customer who has been given > the authority by their upstream to maintain their own in-addr.arpa > and/or contact information. > > Separate templates were created for reallocations and reassignments to > prevent confusion between the two actions that currently exists with > the > > single SWIP template. > > reassign-detailed and reassign-simple allow the upstream to provide > only > > the data that is required, as some reassignments do not require POC > and/or in-addr.arpa information different from that of the upstream. > > The new netmod template functions much like that of the current netmod > template, but will add the ability of a downstream customer to modify > their contact and in-addr.arpa information, if given prior > authorization > > by their upstream. > > Some upstream providers will choose to use one or two of the template > choices on a regular basis, but will have an option to use any or all > of the templates if needed. > > >3) Will all assignments now only be on bit boundaries? > > Reassignments to the downstream that are not on the bit boundary will > be accepted. Either CIDR notation or range will be accepted. > > >4) Except for customers who want their own contact POC information > >associated with their WHOIS registration is there any reason to use > the > >detailed template? > > The reassign-detailed template would be used if there was a need for > the > > downstream to maintain their own contact or in-addr.arpa information. > If > the downstream does not need to maintain any of this information, the > reassign-simple template may be used. > > >5) The templates for detailed assignment and > ARIN-REALLOCATE-3.0-200201 > > >are the exact same templates except for the template heading. Can't > there > >just be one template with a question on is this an assignment or an > >allocation to a "ISP type" customer? This would get rid of one > template. > > In gathering requirements for the new database and templates it was > made > > clear to ARIN that there was a need to eliminate the confusion between > making reassignments and reallocations by separating the templates. > > >6) The netmod template is now part of the SWIP process for any > customer > > >that has an org ID and we need to modify or remove the registration. > >And the other "LONG" forms are only for New templates for customers > that > >need POC information associated with them. The short form is only for > >customers that do not have POC information associated with them. > What > >POC information will be seen on these "shorter" form? > > In the case of simple reassignments, the POCs will be whatever is > associated with the upstream's network, either the net-tech POC or the > org-tech POC. > > Richard Jimmerson > Director of Operations > American Registry for Internet Numbers (ARIN) > > > > > > -----Original Message----- > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > > Behalf Of ginny listman > > Sent: Tuesday, February 19, 2002 4:09 PM > > To: ppml at arin.net; dbwg at arin.net > > Subject: RE: ARIN Database and Template Transition > > > > > > >From > > > > I need some clarification on a couple of things: > > > > 1) Can the wording change for the lines 2 - 19 on the > > Reassign-detailed to be downstream > > org....? > > > > 2) So now we have 4 templates to deal with instead of 1, how does > this > > make my > > life easier? > > > > 3) Will all assignments now only be on bit boundaries? > > > > 4) Except for customers who want their own contact POC information > > associated > > with their WHOIS registration is there any reason to use the > > detailed template? > > > > 5) The templates for detailed assignment and > > ARIN-REALLOCATE-3.0-200201 are the > > exact same templates except for the template heading. Can't there > > just be one > > template with a question on is this an assignment or an > allocation > > to a "ISP type" > > customer? This would get rid of one template. > > > > 6) The netmod template is now part of the SWIP process for any > > customer that has an > > org ID and we need to modify or remove the registration. And the > > other "LONG" forms > > are only for New templates for customers that need POC > information > > associated with > > them. The short form is only for customers that do not have POC > > information associated > > with them. What POC information will be seen on these "shorter" > > form? > > > > -Dawn Martin > > > > > ##################################################################### > > 1. Registration Action: > > ## Specify N for New, M for Modify or R for Return/Remove. > > ## **REQUIRED** > > 2. Network Name: > > ## List a network name to identify the reassigned network, > > ## using no more than 50 characters. **REQUIRED** > > 3. IP Address and Prefix or Range: > > ## Identify the network being assigned using either IP > address > > ## and CIDR prefix, e.g. 10.1.0.0/19, or IP address range, > > ## e.g. 10.1.0.0 - 10.1.31.255. **REQUIRED** > > 4. Customer Name: > > 5a. Customer Address: > > 5b. Customer Address: > > ## Use as many Customer Address lines as needed to specify > > ## street address, using no more than 200 total characters. > > 6. Customer City: > > 7. Customer State/Province: > > 8. Customer Postal Code: > > 9. Customer Country Code: > > 10. Public Comments: > > ## Comments listed here will appear in ARIN's WHOIS > database. > > > > END OF TEMPLATE > > > > > > Dawn Martin > > WorldCom IP Planning Analyst > > dawn.martin at wcom.com > > (703)886-4746 > > > > > > -----Original Message----- > > From: owner-arin-announce at arin.net > > [mailto:owner-arin-announce at arin.net]On Behalf Of Richard Jimmerson > > Sent: Tuesday, February 12, 2002 4:08 PM > > To: arin-announce at arin.net; ppml at arin.net; dbwg at arin.net > > Subject: ARIN Database and Template Transition > > > > > > ARIN will transition to a new database and templates in > > June of 2002. > > > > Over the past year, ARIN has developed requirements for the > > new database with input from members of the ARIN user community > > at ARIN meetings and on the DB Working Group mailing list, > > dbwg at arin.net. > > > > A training program describing the new database and templates is > > currently under development. This training program will be offered > > in person at the upcoming ARIN meeting in April, and on-line for > > those who are unable to attend the meeting. Training will focus > > primarily on the new objects of the ARIN database and the newly > > designed templates. The newly designed templates are available > > now at: > > > ftp://ftp.arin.net/pub/new-templates/ > > The templates incorporate the comments submitted via the DB Working > Group with the efforts of Registration Services and Engineering > Departments. ARIN is providing these templates well in advance of > the conversion, and is encouraging those ISPs that have auto-generated > SWIPs to revise those scripts, and submit templates as beta tests. > > ARIN will solicit beta testers from the community for the new database > and templates. Participation will be open to all interested parties. > More information about beta testing will soon become available. > > Regards, > > Richard Jimmerson > Director of Operations > American Registry for Internet Numbers (ARIN) > > From huberman at gblx.net Thu Feb 21 14:30:05 2002 From: huberman at gblx.net (David R Huberman) Date: Thu, 21 Feb 2002 12:30:05 -0700 (MST) Subject: ARIN Database and Template Transition In-Reply-To: <00b401c1baff$027d2fb0$e7fc95c0@cobalt> Message-ID: Richard, I have a few questions/comments about the new templates. In no particular order: (1) net-isp.txt - In the "3 Month Projection Section", what is the intended purpose of "10. Additional Information"? Outside of a stated need of a [insert requested netblock here] and projections that support this stated need, are there any other criteria by which ARIN hostmasters judge 3-month needs? (2) net-isp.txt - How about changing 7. to read: 7. Reassignment Option (SWIP/RWHOIS/Other/Not applicable) (3) transfer.txt - I'm not entirely certain I understand nor like item 6. - the ability to remove existing SWIP information at the time of transfer. Since I'm unclear of the motivations for this action, can you please offer an explanation of the thinking behind this item? It seems dangerous to me. Thanks. (4) Throughout the templates, the phrase **REQUIRED** is used inconsistently. In most cases, a field is required. In most cases, it's fairly intuitive when a field is optional. I'm not sure what the final visual product of these templates is supposed to look like, but perhaps a final consistency check would be warranted for the "**REQUIRED**" statements. [My point: apply it to ALL required fields or get rid of it everywhere.] (5) net-end-user.txt is currently unavailable on the FTP server. Please put it back up. (6) netmod.txt - Whoa! What is "REMOVE"?? Maybe I'm missing the boat, but what is "REMOVE" doing in a netmod template? The instructions fairly clearly indicate this is to remove a downstream assignment/allocation. Is this intentional? Did ARIN staff decide it was a good idea to extend the scope of netmods to allow parent POCs to quickly remove SWIPs? (7) In poc.txt, the instructional text is inconsistently placed above and below the item to which it refers. In most cases, the text is for the item above it. But look at 14. and 17. /david *--------------------------------* | Global Crossing API | | Manager, Global IP Addressing | | (703) 627-5800 | | huberman at gblx.net | *--------------------------------* From richardj at arin.net Fri Feb 22 09:30:59 2002 From: richardj at arin.net (Richard Jimmerson) Date: Fri, 22 Feb 2002 09:30:59 -0500 Subject: ARIN Database and Template Transition In-Reply-To: <3C754013.54DDA835@sat-tel.com> Message-ID: <007701c1bbad$8e40c3f0$edfc95c0@cobalt> Hello Linda, Thank you for your inquiry. > Will the new templates and accompanying instructions be available in > Spanish? Yes, we have made arrangements to translate the template instructions into Spanish. Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) > -----Original Message----- > From: dbwg-request at arin.net [mailto:dbwg-request at arin.net] On > Behalf Of Linda > Sent: Thursday, February 21, 2002 1:45 PM > To: ARIN DBWG; ARIN PPML > Subject: Re: ARIN Database and Template Transition > > > Will the new templates and accompanying instructions be available in > Spanish? Would it be possible to place a link to templates > on the library > page? > > Regards, > Linda Werner > > Richard Jimmerson wrote: > > > Hello Dawn, > > > > > Is this going to be an agenda item at the next ARIN > meeting? If not, > > > can it be put on the agenda? I would really like to see some more > > > discussion from the membership before this is implemented. > > > > ARIN has been working with its members and the general ARIN user > > community for the past year to finalize plans for a new database > > schema and templates. ARIN's last two public policy meetings > > (April and October 2001) featured discussions about the new > > database schema and templates. On both occasions, the location > > of the templates on the ARIN FTP site was announced and comments > > were solicited. > > > > The templates that are to be released in June are a result of > > the feedback received following these two meetings. > > > > The next ARIN meeting will also feature the new templates, but in > > their final form, as part of a tutorial. > > > > > Has anyone else said anything about this or is it just me? > > > > Other than your own, ARIN has only received messages indicating > > an interest to participate in upcoming beta-testing of the new > > database and templates in response to the February 12 announcement > > to this list. > > > > The instructions of two of the new templates have been modified > > based on your feedback. > > > > Best Regards, > > > > Richard Jimmerson > > Director of Operations > > American Registry for Internet Numbers (ARIN) > > > > > -----Original Message----- > > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > > > Behalf Of Dawn Martin > > > Sent: Thursday, February 21, 2002 10:54 AM > > > To: richardj at arin.net > > > Cc: ppml at arin.net; dbwg at arin.net > > > Subject: RE: ARIN Database and Template Transition > > > > > > > > > Richard, > > > > > > Is this going to be an agenda item at the next ARIN > meeting? If not, > > > can it be > > > put on the agenda? I would really like to see some more > discussion > > > from the membership > > > before this is implemented. I believe that this might be > more of an > > > education > > > issue that needs to be addressed rather than changing the > process for > > > updating WHOIS. > > > Has anyone else said anything about this or is it just me? > > > > > > Dawn Martin > > > dawn.martin at wcom.com > > > > > > -----Original Message----- > > > From: dbwg-request at arin.net > [mailto:dbwg-request at arin.net]On Behalf Of > > > Richard Jimmerson > > > Sent: Tuesday, February 19, 2002 4:19 PM > > > To: Dawn.Martin at wcom.com > > > Cc: ppml at arin.net; dbwg at arin.net > > > Subject: RE: ARIN Database and Template Transition > > > > > > > > > Hello Dawn, > > > > > > Thank you for taking a close look at the templates and asking > > > for clarification. Please see the responses to your questions > > > in-line, below. > > > > > > >1) Can the wording change for the lines 2 - 19 on the > > > >Reassign-detailed to be downstream org....? > > > > > > In an effort to reduce the length of the labels, the word > "Downstream" > > > was not included in each line of the template (lines 2 - > 19). We can > > > expand the comment section of the template to more clearly specify > > > that lines 2 - 19 require information about the downstream > > > organization. > > > > > > >2) So now we have 4 templates to deal with instead of 1, how does > > > this > > > >make my life easier? > > > > > > I believe you are referring to the following four templates: > > > > > > # reallocate -- creates a registration record for a > downstream ISP > > > customer. > > > > > > # reassign-detailed -- creates a registration record for > a downstream > > > end-user customer who will maintain their own > in-addr.arpa and POC > > > associations. > > > > > > # reassign-simple -- creates a registration record for a > downstream > > > end-user customer who will not maintain their own > in-addr.arpa and > > > contact information. > > > > > > # netmod -- may be used by a downstream customer who has > been given > > > the authority by their upstream to maintain their own > in-addr.arpa > > > and/or contact information. > > > > > > Separate templates were created for reallocations and > reassignments to > > > prevent confusion between the two actions that currently > exists with > > > the > > > > > > single SWIP template. > > > > > > reassign-detailed and reassign-simple allow the upstream > to provide > > > only > > > > > > the data that is required, as some reassignments do not > require POC > > > and/or in-addr.arpa information different from that of > the upstream. > > > > > > The new netmod template functions much like that of the > current netmod > > > template, but will add the ability of a downstream > customer to modify > > > their contact and in-addr.arpa information, if given prior > > > authorization > > > > > > by their upstream. > > > > > > Some upstream providers will choose to use one or two of > the template > > > choices on a regular basis, but will have an option to > use any or all > > > of the templates if needed. > > > > > > >3) Will all assignments now only be on bit boundaries? > > > > > > Reassignments to the downstream that are not on the bit > boundary will > > > be accepted. Either CIDR notation or range will be accepted. > > > > > > >4) Except for customers who want their own contact POC > information > > > >associated with their WHOIS registration is there any > reason to use > > > the > > > >detailed template? > > > > > > The reassign-detailed template would be used if there was > a need for > > > the > > > > > > downstream to maintain their own contact or in-addr.arpa > information. > > > If > > > the downstream does not need to maintain any of this > information, the > > > reassign-simple template may be used. > > > > > > >5) The templates for detailed assignment and > > > ARIN-REALLOCATE-3.0-200201 > > > > > > >are the exact same templates except for the template > heading. Can't > > > there > > > >just be one template with a question on is this an > assignment or an > > > >allocation to a "ISP type" customer? This would get rid of one > > > template. > > > > > > In gathering requirements for the new database and > templates it was > > > made > > > > > > clear to ARIN that there was a need to eliminate the > confusion between > > > making reassignments and reallocations by separating the > templates. > > > > > > >6) The netmod template is now part of the SWIP process for any > > > customer > > > > > > >that has an org ID and we need to modify or remove the > registration. > > > >And the other "LONG" forms are only for New templates > for customers > > > that > > > >need POC information associated with them. The short > form is only for > > > >customers that do not have POC information associated with them. > > > What > > > >POC information will be seen on these "shorter" form? > > > > > > In the case of simple reassignments, the POCs will be whatever is > > > associated with the upstream's network, either the > net-tech POC or the > > > org-tech POC. > > > > > > Richard Jimmerson > > > Director of Operations > > > American Registry for Internet Numbers (ARIN) > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > > > > Behalf Of ginny listman > > > > Sent: Tuesday, February 19, 2002 4:09 PM > > > > To: ppml at arin.net; dbwg at arin.net > > > > Subject: RE: ARIN Database and Template Transition > > > > > > > > > > > > >From > > > > > > > > I need some clarification on a couple of things: > > > > > > > > 1) Can the wording change for the lines 2 - 19 on the > > > > Reassign-detailed to be downstream > > > > org....? > > > > > > > > 2) So now we have 4 templates to deal with instead of > 1, how does > > > this > > > > make my > > > > life easier? > > > > > > > > 3) Will all assignments now only be on bit boundaries? > > > > > > > > 4) Except for customers who want their own contact POC > information > > > > associated > > > > with their WHOIS registration is there any reason to use the > > > > detailed template? > > > > > > > > 5) The templates for detailed assignment and > > > > ARIN-REALLOCATE-3.0-200201 are the > > > > exact same templates except for the template > heading. Can't there > > > > just be one > > > > template with a question on is this an assignment or an > > > allocation > > > > to a "ISP type" > > > > customer? This would get rid of one template. > > > > > > > > 6) The netmod template is now part of the SWIP process for any > > > > customer that has an > > > > org ID and we need to modify or remove the > registration. And the > > > > other "LONG" forms > > > > are only for New templates for customers that need POC > > > information > > > > associated with > > > > them. The short form is only for customers that do > not have POC > > > > information associated > > > > with them. What POC information will be seen on > these "shorter" > > > > form? > > > > > > > > -Dawn Martin > > > > > > > > > > > > ##################################################################### > > > > 1. Registration Action: > > > > ## Specify N for New, M for Modify or R for > Return/Remove. > > > > ## **REQUIRED** > > > > 2. Network Name: > > > > ## List a network name to identify the > reassigned network, > > > > ## using no more than 50 characters. **REQUIRED** > > > > 3. IP Address and Prefix or Range: > > > > ## Identify the network being assigned using either IP > > > address > > > > ## and CIDR prefix, e.g. 10.1.0.0/19, or IP > address range, > > > > ## e.g. 10.1.0.0 - 10.1.31.255. **REQUIRED** > > > > 4. Customer Name: > > > > 5a. Customer Address: > > > > 5b. Customer Address: > > > > ## Use as many Customer Address lines as needed > to specify > > > > ## street address, using no more than 200 total > characters. > > > > 6. Customer City: > > > > 7. Customer State/Province: > > > > 8. Customer Postal Code: > > > > 9. Customer Country Code: > > > > 10. Public Comments: > > > > ## Comments listed here will appear in ARIN's WHOIS > > > database. > > > > > > > > END OF TEMPLATE > > > > > > > > > > > > Dawn Martin > > > > WorldCom IP Planning Analyst > > > > dawn.martin at wcom.com > > > > (703)886-4746 > > > > > > > > > > > > -----Original Message----- > > > > From: owner-arin-announce at arin.net > > > > [mailto:owner-arin-announce at arin.net]On Behalf Of > Richard Jimmerson > > > > Sent: Tuesday, February 12, 2002 4:08 PM > > > > To: arin-announce at arin.net; ppml at arin.net; dbwg at arin.net > > > > Subject: ARIN Database and Template Transition > > > > > > > > > > > > ARIN will transition to a new database and templates in > > > > June of 2002. > > > > > > > > Over the past year, ARIN has developed requirements for the > > > > new database with input from members of the ARIN user community > > > > at ARIN meetings and on the DB Working Group mailing list, > > > > dbwg at arin.net. > > > > > > > > A training program describing the new database and templates is > > > > currently under development. This training program > will be offered > > > > in person at the upcoming ARIN meeting in April, and on-line for > > > > those who are unable to attend the meeting. Training will focus > > > > primarily on the new objects of the ARIN database and the newly > > > > designed templates. The newly designed templates are available > > > > now at: > > > > > > > ftp://ftp.arin.net/pub/new-templates/ > > > > > > The templates incorporate the comments submitted via the > DB Working > > > Group with the efforts of Registration Services and Engineering > > > Departments. ARIN is providing these templates well in advance of > > > the conversion, and is encouraging those ISPs that have > auto-generated > > > SWIPs to revise those scripts, and submit templates as beta tests. > > > > > > ARIN will solicit beta testers from the community for the > new database > > > and templates. Participation will be open to all > interested parties. > > > More information about beta testing will soon become available. > > > > > > Regards, > > > > > > Richard Jimmerson > > > Director of Operations > > > American Registry for Internet Numbers (ARIN) > > > > > > > From richardj at arin.net Fri Feb 22 11:24:55 2002 From: richardj at arin.net (Richard Jimmerson) Date: Fri, 22 Feb 2002 11:24:55 -0500 Subject: ARIN Database and Template Transition In-Reply-To: <007701c1bbad$8e40c3f0$edfc95c0@cobalt> Message-ID: <00b301c1bbbd$76cd8cc0$edfc95c0@cobalt> Hello Linda, I neglected to respond to your second question. > > Would it be possible to place a link to templates > > on the library page? We will certainly do this once the translations are complete. Best Regards, Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Richard Jimmerson > Sent: Friday, February 22, 2002 9:31 AM > To: 'Linda' > Cc: dbwg at arin.net; ppml at arin.net > Subject: RE: ARIN Database and Template Transition > > > Hello Linda, > > Thank you for your inquiry. > > > Will the new templates and accompanying instructions be available in > > Spanish? > > Yes, we have made arrangements to translate the template instructions > into Spanish. > > Richard Jimmerson > Director of Operations > American Registry for Internet Numbers (ARIN) > > > > -----Original Message----- > > From: dbwg-request at arin.net [mailto:dbwg-request at arin.net] On > > Behalf Of Linda > > Sent: Thursday, February 21, 2002 1:45 PM > > To: ARIN DBWG; ARIN PPML > > Subject: Re: ARIN Database and Template Transition > > > > > > Will the new templates and accompanying instructions be available in > > Spanish? Would it be possible to place a link to templates > > on the library > > page? > > > > Regards, > > Linda Werner > > > > Richard Jimmerson wrote: > > > > > Hello Dawn, > > > > > > > Is this going to be an agenda item at the next ARIN > > meeting? If not, > > > > can it be put on the agenda? I would really like to > see some more > > > > discussion from the membership before this is implemented. > > > > > > ARIN has been working with its members and the general ARIN user > > > community for the past year to finalize plans for a new database > > > schema and templates. ARIN's last two public policy meetings > > > (April and October 2001) featured discussions about the new > > > database schema and templates. On both occasions, the location > > > of the templates on the ARIN FTP site was announced and comments > > > were solicited. > > > > > > The templates that are to be released in June are a result of > > > the feedback received following these two meetings. > > > > > > The next ARIN meeting will also feature the new templates, but in > > > their final form, as part of a tutorial. > > > > > > > Has anyone else said anything about this or is it just me? > > > > > > Other than your own, ARIN has only received messages indicating > > > an interest to participate in upcoming beta-testing of the new > > > database and templates in response to the February 12 announcement > > > to this list. > > > > > > The instructions of two of the new templates have been modified > > > based on your feedback. > > > > > > Best Regards, > > > > > > Richard Jimmerson > > > Director of Operations > > > American Registry for Internet Numbers (ARIN) > > > > > > > -----Original Message----- > > > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > > > > Behalf Of Dawn Martin > > > > Sent: Thursday, February 21, 2002 10:54 AM > > > > To: richardj at arin.net > > > > Cc: ppml at arin.net; dbwg at arin.net > > > > Subject: RE: ARIN Database and Template Transition > > > > > > > > > > > > Richard, > > > > > > > > Is this going to be an agenda item at the next ARIN > > meeting? If not, > > > > can it be > > > > put on the agenda? I would really like to see some more > > discussion > > > > from the membership > > > > before this is implemented. I believe that this might be > > more of an > > > > education > > > > issue that needs to be addressed rather than changing the > > process for > > > > updating WHOIS. > > > > Has anyone else said anything about this or is it just me? > > > > > > > > Dawn Martin > > > > dawn.martin at wcom.com > > > > > > > > -----Original Message----- > > > > From: dbwg-request at arin.net > > [mailto:dbwg-request at arin.net]On Behalf Of > > > > Richard Jimmerson > > > > Sent: Tuesday, February 19, 2002 4:19 PM > > > > To: Dawn.Martin at wcom.com > > > > Cc: ppml at arin.net; dbwg at arin.net > > > > Subject: RE: ARIN Database and Template Transition > > > > > > > > > > > > Hello Dawn, > > > > > > > > Thank you for taking a close look at the templates and asking > > > > for clarification. Please see the responses to your questions > > > > in-line, below. > > > > > > > > >1) Can the wording change for the lines 2 - 19 on the > > > > >Reassign-detailed to be downstream org....? > > > > > > > > In an effort to reduce the length of the labels, the word > > "Downstream" > > > > was not included in each line of the template (lines 2 - > > 19). We can > > > > expand the comment section of the template to more > clearly specify > > > > that lines 2 - 19 require information about the downstream > > > > organization. > > > > > > > > >2) So now we have 4 templates to deal with instead of > 1, how does > > > > this > > > > >make my life easier? > > > > > > > > I believe you are referring to the following four templates: > > > > > > > > # reallocate -- creates a registration record for a > > downstream ISP > > > > customer. > > > > > > > > # reassign-detailed -- creates a registration record for > > a downstream > > > > end-user customer who will maintain their own > > in-addr.arpa and POC > > > > associations. > > > > > > > > # reassign-simple -- creates a registration record for a > > downstream > > > > end-user customer who will not maintain their own > > in-addr.arpa and > > > > contact information. > > > > > > > > # netmod -- may be used by a downstream customer who has > > been given > > > > the authority by their upstream to maintain their own > > in-addr.arpa > > > > and/or contact information. > > > > > > > > Separate templates were created for reallocations and > > reassignments to > > > > prevent confusion between the two actions that currently > > exists with > > > > the > > > > > > > > single SWIP template. > > > > > > > > reassign-detailed and reassign-simple allow the upstream > > to provide > > > > only > > > > > > > > the data that is required, as some reassignments do not > > require POC > > > > and/or in-addr.arpa information different from that of > > the upstream. > > > > > > > > The new netmod template functions much like that of the > > current netmod > > > > template, but will add the ability of a downstream > > customer to modify > > > > their contact and in-addr.arpa information, if given prior > > > > authorization > > > > > > > > by their upstream. > > > > > > > > Some upstream providers will choose to use one or two of > > the template > > > > choices on a regular basis, but will have an option to > > use any or all > > > > of the templates if needed. > > > > > > > > >3) Will all assignments now only be on bit boundaries? > > > > > > > > Reassignments to the downstream that are not on the bit > > boundary will > > > > be accepted. Either CIDR notation or range will be accepted. > > > > > > > > >4) Except for customers who want their own contact POC > > information > > > > >associated with their WHOIS registration is there any > > reason to use > > > > the > > > > >detailed template? > > > > > > > > The reassign-detailed template would be used if there was > > a need for > > > > the > > > > > > > > downstream to maintain their own contact or in-addr.arpa > > information. > > > > If > > > > the downstream does not need to maintain any of this > > information, the > > > > reassign-simple template may be used. > > > > > > > > >5) The templates for detailed assignment and > > > > ARIN-REALLOCATE-3.0-200201 > > > > > > > > >are the exact same templates except for the template > > heading. Can't > > > > there > > > > >just be one template with a question on is this an > > assignment or an > > > > >allocation to a "ISP type" customer? This would get rid of one > > > > template. > > > > > > > > In gathering requirements for the new database and > > templates it was > > > > made > > > > > > > > clear to ARIN that there was a need to eliminate the > > confusion between > > > > making reassignments and reallocations by separating the > > templates. > > > > > > > > >6) The netmod template is now part of the SWIP process for any > > > > customer > > > > > > > > >that has an org ID and we need to modify or remove the > > registration. > > > > >And the other "LONG" forms are only for New templates > > for customers > > > > that > > > > >need POC information associated with them. The short > > form is only for > > > > >customers that do not have POC information associated > with them. > > > > What > > > > >POC information will be seen on these "shorter" form? > > > > > > > > In the case of simple reassignments, the POCs will be > whatever is > > > > associated with the upstream's network, either the > > net-tech POC or the > > > > org-tech POC. > > > > > > > > Richard Jimmerson > > > > Director of Operations > > > > American Registry for Internet Numbers (ARIN) > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > > > > > Behalf Of ginny listman > > > > > Sent: Tuesday, February 19, 2002 4:09 PM > > > > > To: ppml at arin.net; dbwg at arin.net > > > > > Subject: RE: ARIN Database and Template Transition > > > > > > > > > > > > > > > >From > > > > > > > > > > I need some clarification on a couple of things: > > > > > > > > > > 1) Can the wording change for the lines 2 - 19 on the > > > > > Reassign-detailed to be downstream > > > > > org....? > > > > > > > > > > 2) So now we have 4 templates to deal with instead of > > 1, how does > > > > this > > > > > make my > > > > > life easier? > > > > > > > > > > 3) Will all assignments now only be on bit boundaries? > > > > > > > > > > 4) Except for customers who want their own contact POC > > information > > > > > associated > > > > > with their WHOIS registration is there any reason > to use the > > > > > detailed template? > > > > > > > > > > 5) The templates for detailed assignment and > > > > > ARIN-REALLOCATE-3.0-200201 are the > > > > > exact same templates except for the template > > heading. Can't there > > > > > just be one > > > > > template with a question on is this an assignment or an > > > > allocation > > > > > to a "ISP type" > > > > > customer? This would get rid of one template. > > > > > > > > > > 6) The netmod template is now part of the SWIP process for any > > > > > customer that has an > > > > > org ID and we need to modify or remove the > > registration. And the > > > > > other "LONG" forms > > > > > are only for New templates for customers that need POC > > > > information > > > > > associated with > > > > > them. The short form is only for customers that do > > not have POC > > > > > information associated > > > > > with them. What POC information will be seen on > > these "shorter" > > > > > form? > > > > > > > > > > -Dawn Martin > > > > > > > > > > > > > > > > > ##################################################################### > > > > > 1. Registration Action: > > > > > ## Specify N for New, M for Modify or R for > > Return/Remove. > > > > > ## **REQUIRED** > > > > > 2. Network Name: > > > > > ## List a network name to identify the > > reassigned network, > > > > > ## using no more than 50 characters. **REQUIRED** > > > > > 3. IP Address and Prefix or Range: > > > > > ## Identify the network being assigned using either IP > > > > address > > > > > ## and CIDR prefix, e.g. 10.1.0.0/19, or IP > > address range, > > > > > ## e.g. 10.1.0.0 - 10.1.31.255. **REQUIRED** > > > > > 4. Customer Name: > > > > > 5a. Customer Address: > > > > > 5b. Customer Address: > > > > > ## Use as many Customer Address lines as needed > > to specify > > > > > ## street address, using no more than 200 total > > characters. > > > > > 6. Customer City: > > > > > 7. Customer State/Province: > > > > > 8. Customer Postal Code: > > > > > 9. Customer Country Code: > > > > > 10. Public Comments: > > > > > ## Comments listed here will appear in ARIN's WHOIS > > > > database. > > > > > > > > > > END OF TEMPLATE > > > > > > > > > > > > > > > Dawn Martin > > > > > WorldCom IP Planning Analyst > > > > > dawn.martin at wcom.com > > > > > (703)886-4746 > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: owner-arin-announce at arin.net > > > > > [mailto:owner-arin-announce at arin.net]On Behalf Of > > Richard Jimmerson > > > > > Sent: Tuesday, February 12, 2002 4:08 PM > > > > > To: arin-announce at arin.net; ppml at arin.net; dbwg at arin.net > > > > > Subject: ARIN Database and Template Transition > > > > > > > > > > > > > > > ARIN will transition to a new database and templates in > > > > > June of 2002. > > > > > > > > > > Over the past year, ARIN has developed requirements for the > > > > > new database with input from members of the ARIN user > community > > > > > at ARIN meetings and on the DB Working Group mailing list, > > > > > dbwg at arin.net. > > > > > > > > > > A training program describing the new database and > templates is > > > > > currently under development. This training program > > will be offered > > > > > in person at the upcoming ARIN meeting in April, and > on-line for > > > > > those who are unable to attend the meeting. Training > will focus > > > > > primarily on the new objects of the ARIN database and > the newly > > > > > designed templates. The newly designed templates are > available > > > > > now at: > > > > > > > > > ftp://ftp.arin.net/pub/new-templates/ > > > > > > > > The templates incorporate the comments submitted via the > > DB Working > > > > Group with the efforts of Registration Services and Engineering > > > > Departments. ARIN is providing these templates well in > advance of > > > > the conversion, and is encouraging those ISPs that have > > auto-generated > > > > SWIPs to revise those scripts, and submit templates as > beta tests. > > > > > > > > ARIN will solicit beta testers from the community for the > > new database > > > > and templates. Participation will be open to all > > interested parties. > > > > More information about beta testing will soon become available. > > > > > > > > Regards, > > > > > > > > Richard Jimmerson > > > > Director of Operations > > > > American Registry for Internet Numbers (ARIN) > > > > > > > > > > > From richardj at arin.net Fri Feb 22 13:39:50 2002 From: richardj at arin.net (Richard Jimmerson) Date: Fri, 22 Feb 2002 13:39:50 -0500 Subject: ARIN Database and Template Transition In-Reply-To: Message-ID: <00f201c1bbd0$4f96d040$edfc95c0@cobalt> Hello David, Thank you for submitting your questions/comments. > (1) net-isp.txt - In the "3 Month Projection Section", what > is the intended purpose of "10. Additional Information"? > Outside of a stated need of a [insert requested netblock here] > and projections that support this stated need, are there any > other criteria by which ARIN hostmasters judge 3-month needs? Many of the new templates include an "additional information" section to allow template users to elaborate on certain types of information. This addition to the templates was made in response to feedback received on the new templates over the past year. > (2) net-isp.txt - How about changing 7. to read: > > 7. Reassignment Option (SWIP/RWHOIS/Other/Not applicable) We will add a short statement in the instructions portion of this numbered item to indicate this may not be applicable to some organizations. > (3) transfer.txt - I'm not entirely certain I understand nor like > item 6. - the ability to remove existing SWIP information at the > time of transfer. Since I'm unclear of the motivations for this > action, can you please offer an explanation of the thinking behind > this item? It seems dangerous to me. Thanks. It is fairly common in the transfer process that the organization who the block of IP address space is being transferred to uses a RWHOIS server and requests all reassignments in the ARIN database be removed. > (4) Throughout the templates, the phrase **REQUIRED** is used > inconsistently. In most cases, a field is required. In most cases, > it's fairly intuitive when a field is optional. I'm not sure what > the final visual product of these templates is supposed to look like, > but perhaps a final consistency check would be warranted for the > "**REQUIRED**" statements. [My point: apply it to ALL required > fields or get rid of it everywhere.] We will conduct a review of the templates for consistency in the use of **REQUIRED**. > (5) net-end-user.txt is currently unavailable on the FTP server. > Please put it back up. We just verified this file is on the FTP server with the same timestamp as the other template files in the new-templates directory. Please try opening this file again and let us know if you are still unable to do so. > (6) netmod.txt - Whoa! What is "REMOVE"?? Maybe I'm missing the > boat, but what is "REMOVE" doing in a netmod template? The > instructions fairly clearly indicate this is to remove a > downstream assignment/allocation. Is this intentional? Yes, it is intentional. > Did ARIN staff decide it was a good idea to extend the scope > of netmods to allow parent POCs to quickly remove SWIPs? Yes, as well as modify "network" records. There are only minor differences between a SWIP and a direct ARIN registration, primarily the identity of the parent. > (7) In poc.txt, the instructional text is inconsistently > placed above and below the item to which it refers. > In most cases, the text is for the item above it. > But look at 14. and 17. Anytime it is specified lines may be duplicated, it is placed before the beginning of that line. The instructions after a line specifically relate to the contents of that field. Usually, the duplication instructions accompany a section delimiter, but we see this is not the case with these lines. We can modify the instructions relating to duplications on this template to be consistent with the others. Best Regards, Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) > -----Original Message----- > From: David R Huberman [mailto:huberman at gblx.net] > Sent: Thursday, February 21, 2002 2:30 PM > To: Richard Jimmerson > Cc: ppml at arin.net; dbwg at arin.net > Subject: RE: ARIN Database and Template Transition > > > Richard, > > I have a few questions/comments about the new templates. > > In no particular order: > > (1) net-isp.txt - In the "3 Month Projection Section", what > is the intended purpose of "10. Additional Information"? > Outside of a stated need of a [insert requested netblock here] > and projections that support this stated need, are there any > other criteria by which ARIN hostmasters judge 3-month needs? > > (2) net-isp.txt - How about changing 7. to read: > > 7. Reassignment Option (SWIP/RWHOIS/Other/Not applicable) > > (3) transfer.txt - I'm not entirely certain I understand nor like > item 6. - the ability to remove existing SWIP information at the > time of transfer. Since I'm unclear of the motivations for this > action, can you please offer an explanation of the thinking behind > this item? It seems dangerous to me. Thanks. > > (4) Throughout the templates, the phrase **REQUIRED** is used > inconsistently. In most cases, a field is required. In most cases, > it's fairly intuitive when a field is optional. I'm not sure what > the final visual product of these templates is supposed to look like, > but perhaps a final consistency check would be warranted for the > "**REQUIRED**" statements. [My point: apply it to ALL required > fields or get rid of it everywhere.] > > (5) net-end-user.txt is currently unavailable on the FTP server. > Please put it back up. > > (6) netmod.txt - Whoa! What is "REMOVE"?? Maybe I'm missing the > boat, but what is "REMOVE" doing in a netmod template? The > instructions fairly clearly indicate this is to remove a > downstream assignment/allocation. Is this intentional? Did > ARIN staff decide it was a good idea to extend the scope > of netmods to allow parent POCs to quickly remove SWIPs? > > (7) In poc.txt, the instructional text is inconsistently > placed above and below the item to which it refers. > In most cases, the text is for the item above it. > But look at 14. and 17. > > /david > > *--------------------------------* > | Global Crossing API | > | Manager, Global IP Addressing | > | (703) 627-5800 | > | huberman at gblx.net | > *--------------------------------* > From thinman at clp.cw.net Mon Feb 25 16:31:44 2002 From: thinman at clp.cw.net (Tanya Hinman) Date: Mon, 25 Feb 2002 16:31:44 -0500 Subject: Should registered space or reserved space be used? In-Reply-To: <000801c1b5e3$32ce5070$5a681a41@stevewinbook> Message-ID: Steve, We too have been considering similar options in regards to VPN services. The option of using Public Address Space would most likely cause your company problems obtaining more address space in the future, since routing of public addresses on a private network is against Internet Policy. Not to mention the fact that IPv4 space is limited. We have considered re-using our own public address space privately, but that causes an issue of non-unique addresses on our network as a whole. We would also have problems if we were to use 1918 space, due to non-unique addresses between our VPN network and the customers' networks. It seems that the only solution is to use what you have called "illegal" addresses. If you know for certain that they will never be announced outside of your VPN network, then it should not be an issue. It would be great to hear from others that have dealt with similar issues when using VPN. Thanks, Tanya -----Original Message----- From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Steve Dispensa Sent: Friday, February 15, 2002 12:40 AM To: ppml at arin.net Subject: Should registered space or reserved space be used? [If this is not an appropriate forum for this question, I would appreciate being pointed in the right direction.] I am working on a VPN service provider network whose purpose is to connect remote users over L2TP to remote networks. All L2TP connections and all remote networks are aggregated in a POP. Traffic is switched in the POP from L2TP tunnels into appropriate remote networks and back again. An added requirement is that the case of overlapping IP address space among the remote networks must be handled properly. It seems particularly likely that many remote networks will choose to use one or more of the RFC 1918 blocks. Therefore, the probability of address space collision is quite high. The solution to this problem depends on the L2TP connections being given "unique" addresses within the scope of the VPN service provider's routing domain. In other words: - no two L2TP connections can have the same address - no L2TP address can fall within any network block in use in any remote network One final point: it is highly unlikely that the L2TP interfaces will ever be given a direct (non-NATted) route to the Internet. There are three options that I can see for addressing the L2TP connections: 1) Since Internet routability is not a concern, use RFC 1918 space. However, this violates the "no collisions" requirement. 2) Since Internet routability is not a concern and since no collisions are allowed, use "illegal" addresses, such as addresses out of Class E space or out of "permanently reserved" blocks (1/8 for instance). However, this seems like a Bad Idea to me. 3) Address all requirements by using registered space. However, given the lack of need for Internet routability, this sure seems like a waste of space. I hate to do #3, but it seems like the best move. This might be a paltry number of addresses, or it might turn into a big drain on address space. Then again, I could be completely missing an obvious solution. What do you think? Thanks, -Steve From bondyl at bellsouth.net Mon Feb 25 23:19:10 2002 From: bondyl at bellsouth.net (luis bondy) Date: Mon, 25 Feb 2002 20:19:10 -0800 Subject: No subject Message-ID: <000801c1be7c$bdf385c0$f942fea9@luisbondyr> -------------- next part -------------- An HTML attachment was scrubbed... URL: From memsvcs at arin.net Tue Feb 26 16:41:48 2002 From: memsvcs at arin.net (Member Services) Date: Tue, 26 Feb 2002 16:41:48 -0500 (EST) Subject: Register Now for ARIN IX Message-ID: Join your colleagues who have already made plans to attend ARIN's Public Policy and Members Meeting, April 7-10 in Las Vegas. Meeting details and registration information are available at: http://www.arin.net/meetings/ARIN_IX/index.html April is a busy time in Las Vegas and our hotel reservation cutoff date is mid-March. After registering for the meeting please be sure to secure your hotel room at the Green Valley Ranch. Don't forget to sign up for the Sunday evening foosball tournament, with or without a partner! Revisit the agenda page periodically for the latest update on Sunday tutorials and the expanded meeting agenda. Suggestions for agenda topics are welcome and can be sent to memsvcs at arin.net or be brought up on the policy mailing list. We are grateful to Cox Communications for their sponsorship of this meeting. Susan Hamlin Director, Member Services