From info at arin.net Mon Nov 15 12:31:21 2010 From: info at arin.net (ARIN) Date: Mon, 15 Nov 2010 12:31:21 -0500 Subject: [ARIN-consult] Call for Community Consultation - ARIN Services and Database Access for Invalid Points of Contact (POCs) Message-ID: <4CE16E69.1080709@arin.net> ARIN is seeking community input regarding the availability of ARIN services to invalid Points of Contact (POCs) identified by ARIN's POC Validation Process. Please refer to Number Resource Policy Manual section 3.6 Annual Whois POC Validation for background, https://www.arin.net/policy/nrpm.html#three6. Based on feedback expressed at the recent ARIN Public Policy and Member Meeting in Atlanta as well as the Public Policy Mailing List (PPML), ARIN is considering implementing changes to the services available to Invalid POCs. These changes are intended to further improve the accuracy of POC data in ARIN's Whois by requiring users to validate their invalid POCs prior to requesting services and database changes. The proposed changes limit services to users linked to Invalid POCs in the following manner: ? ARIN Online users would only have access to POC validation and modification features until they validate any non-validated POCs to which they are linked. Once validated, an ARIN Online user would have access to all available ARIN Online functionality. ? Any service requests made through ARIN?s RESTful Provisioning Service, https://www.arin.net/resources/restful-interfaces.html, would be returned with a message directing users to validate their associated POC information through ARIN Online. ? Template submissions for POC, organization, network modifications, v4 simple reassignments, v4 detailed reassignments, v4 reallocations, v6 detailed reassignments and v6 reallocation requests would be returned with a message directing users to validate their associated POC information through ARIN Online. ? Templates requesting resources directly from ARIN (v4 ISP request, v4 End-User request, v6 ISP request, v6 End-User request, ASN, experimental), or requesting resource transfers or ASN modifications would be accepted and ticketed, however, they will not be processed if the POC is invalid. ARIN staff would notify submitters via email to validate their associated POC information through ARIN Online. ? Other services and/or functionality may be added in this change of service at ARIN's discretion. This change in service will be implemented in early-to-mid 2011 if supported by the community. Comments regarding this proposed service change for Invalid POCs can be submitted through the ARIN Consultation and Suggestion Process, available at: https://www.arin.net/participate/acsp/index.html. Discussion on arin-consult at arin.net will close on 15 December 2010, at Noon EST. ARIN welcomes community-wide participation. Please address any process questions to info at arin.net. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From Marla.Azinger at FTR.com Mon Nov 15 12:54:38 2010 From: Marla.Azinger at FTR.com (Azinger, Marla) Date: Mon, 15 Nov 2010 12:54:38 -0500 Subject: [ARIN-consult] Clarification question Message-ID: <2E2FECEBAE57CC4BAACDE67638305F10492D9EF092@ROCH-EXCH1.corp.pvt> I just want to make sure I interpret this correctly. This is saying that direct allocation or assignment recipients of ARIN will basically be forced to update/validate the POC info before gaining any new ARIN resources. Correct? Its NOT saying that direct allocation or assignment recipients of ARIN who have re-assignments or re-allocations recorded in WHOIS with an invalidated or incorrect POC on a re-assignment or re-allocation visible in WHOIS will then block the direct ARIN recipient from getting more ARIN resources? For example if direct recipient "ISP Jingle" has a /18 from ARIN and 5 of his re-assignments to his customers have invalidated or incorrect POC info, these 5 customer of ISP Jingle wont block ISP Jingle from receiving more resources from ARIN will it? This is really only concerning the POC info on the Direct Recipient of ARIN, correct? Thank you Marla -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndavis at arin.net Mon Nov 15 15:14:11 2010 From: ndavis at arin.net (Nate Davis) Date: Mon, 15 Nov 2010 15:14:11 -0500 Subject: [ARIN-consult] Clarification question In-Reply-To: <2E2FECEBAE57CC4BAACDE67638305F10492D9EF092@ROCH-EXCH1.corp.pvt> References: <2E2FECEBAE57CC4BAACDE67638305F10492D9EF092@ROCH-EXCH1.corp.pvt> Message-ID: Marla, Thanks for your question. The overall goal of this proposed change is to improve all WHOIS POC data, not just those associated with organizations having direct relationship with ARIN. Therefore this includes direct allocation/assignment POCs as well as indirect allocation/assignment POCs. So, an ISP having all valid POCs will NOT be prevented from using ARIN Online or updating the database in cases where their downstream customers have invalid POCs. In the example you cite, assuming ISP Jingle has valid POCs while still having invalid POCs among the 5 downstream reassignments, ISP Jingle will have all access to all services through ARIN Online as well the ability to submit database changes to ARIN. ISP Jingle will not be able to use ARIN Online or request database updates if it?s own POCs are not all valid. Granted the likelihood of an indirect allocation/assignment POC using ARIN Online to maintain data is small, we still wish to provide them the capability to update their records in cases where their upstream ARIN direct organization does not. Please note the community requested that we include indirect POCs as part of POC validation, therefore this is consistent with that policy. Regards, Nate Davis Chief Operating Officer The American Registry for Internet Numbers From: arin-consult-bounces at arin.net [mailto:arin-consult-bounces at arin.net] On Behalf Of Azinger, Marla Sent: Monday, November 15, 2010 12:55 PM To: arin-consult at arin.net Subject: [ARIN-consult] Clarification question I just want to make sure I interpret this correctly. This is saying that direct allocation or assignment recipients of ARIN will basically be forced to update/validate the POC info before gaining any new ARIN resources. Correct? Its NOT saying that direct allocation or assignment recipients of ARIN who have re-assignments or re-allocations recorded in WHOIS with an invalidated or incorrect POC on a re-assignment or re-allocation visible in WHOIS will then block the direct ARIN recipient from getting more ARIN resources? For example if direct recipient "ISP Jingle" has a /18 from ARIN and 5 of his re-assignments to his customers have invalidated or incorrect POC info, these 5 customer of ISP Jingle wont block ISP Jingle from receiving more resources from ARIN will it? This is really only concerning the POC info on the Direct Recipient of ARIN, correct? Thank you Marla -------------- next part -------------- An HTML attachment was scrubbed... URL: From Marla.Azinger at FTR.com Mon Nov 15 16:06:02 2010 From: Marla.Azinger at FTR.com (Azinger, Marla) Date: Mon, 15 Nov 2010 16:06:02 -0500 Subject: [ARIN-consult] Clarification question In-Reply-To: References: <2E2FECEBAE57CC4BAACDE67638305F10492D9EF092@ROCH-EXCH1.corp.pvt> Message-ID: <2E2FECEBAE57CC4BAACDE67638305F10492D9EF3A5@ROCH-EXCH1.corp.pvt> That helps a bit, but let me ask for your response on one more example. For example if ARIN see's the following Situation visible in WHOIS or RWHOIS: ISP Jingle = valid POC customer of ISP Jingle "Hip Shop" = Invalid POC Possible Answers to how ARIN would respond are: 1. ISP Jingle will not be barred from a new allocation from ARIN if they request one, but Hip Shop will be blocked from an additional re-assignment until ISP Jingle gets their POC updated/validated. Correct? OR 2. ISP Jingle will be barred from a new allocation from ARIN if they request one, as long as their customer Hip Shop has an invalid POC on record in WHOIS. Correct? Sorry for the at nausea questioning and clarifications but I just want to make sure I fully understand how much this change will impact the entities and databases I manage. The below items are the ones I'm focusing on here. I just want to make sure I interpret the level/layer at which the invalid POC alarm will go off at and exactly how this impacts Direct Allocations from ARIN. * ARIN Online users would only have access to POC validation and modification features until they validate any non-validated POCs to which they are linked. Once validated, an ARIN Online user would have access to all available ARIN Online functionality. * Templates requesting resources directly from ARIN (v4 ISP request, v4 End-User request, v6 ISP request, v6 End-User request, ASN, experimental), or requesting resource transfers or ASN modifications would be accepted and ticketed, however, they will not be processed if the POC is invalid. ARIN staff would notify submitters via email to validate their associated POC information through ARIN Online. ________________________________ From: arin-consult-bounces at arin.net [mailto:arin-consult-bounces at arin.net] On Behalf Of Nate Davis Sent: Monday, November 15, 2010 12:14 PM To: arin-consult at arin.net Subject: Re: [ARIN-consult] Clarification question Marla, Thanks for your question. The overall goal of this proposed change is to improve all WHOIS POC data, not just those associated with organizations having direct relationship with ARIN. Therefore this includes direct allocation/assignment POCs as well as indirect allocation/assignment POCs. So, an ISP having all valid POCs will NOT be prevented from using ARIN Online or updating the database in cases where their downstream customers have invalid POCs. In the example you cite, assuming ISP Jingle has valid POCs while still having invalid POCs among the 5 downstream reassignments, ISP Jingle will have all access to all services through ARIN Online as well the ability to submit database changes to ARIN. ISP Jingle will not be able to use ARIN Online or request database updates if it's own POCs are not all valid. Granted the likelihood of an indirect allocation/assignment POC using ARIN Online to maintain data is small, we still wish to provide them the capability to update their records in cases where their upstream ARIN direct organization does not. Please note the community requested that we include indirect POCs as part of POC validation, therefore this is consistent with that policy. Regards, Nate Davis Chief Operating Officer The American Registry for Internet Numbers From: arin-consult-bounces at arin.net [mailto:arin-consult-bounces at arin.net] On Behalf Of Azinger, Marla Sent: Monday, November 15, 2010 12:55 PM To: arin-consult at arin.net Subject: [ARIN-consult] Clarification question I just want to make sure I interpret this correctly. This is saying that direct allocation or assignment recipients of ARIN will basically be forced to update/validate the POC info before gaining any new ARIN resources. Correct? Its NOT saying that direct allocation or assignment recipients of ARIN who have re-assignments or re-allocations recorded in WHOIS with an invalidated or incorrect POC on a re-assignment or re-allocation visible in WHOIS will then block the direct ARIN recipient from getting more ARIN resources? For example if direct recipient "ISP Jingle" has a /18 from ARIN and 5 of his re-assignments to his customers have invalidated or incorrect POC info, these 5 customer of ISP Jingle wont block ISP Jingle from receiving more resources from ARIN will it? This is really only concerning the POC info on the Direct Recipient of ARIN, correct? Thank you Marla -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon Nov 15 17:22:44 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 15 Nov 2010 14:22:44 -0800 Subject: [ARIN-consult] Call for Community Consultation - ARIN Services and Database Access for Invalid Points of Contact (POCs) References: <4CE16E69.1080709@arin.net> Message-ID: <95843C7D-68B6-4221-A4AF-A1C79C997D46@delong.com> I support the proposed changes to service levels for invalid POCs. Owen From scottleibrand at gmail.com Mon Nov 15 19:27:20 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 15 Nov 2010 16:27:20 -0800 Subject: [ARIN-consult] Call for Community Consultation - ARIN Services and Database Access for Invalid Points of Contact (POCs) In-Reply-To: <95843C7D-68B6-4221-A4AF-A1C79C997D46@delong.com> References: <4CE16E69.1080709@arin.net> <95843C7D-68B6-4221-A4AF-A1C79C997D46@delong.com> Message-ID: +1 On Mon, Nov 15, 2010 at 2:22 PM, Owen DeLong wrote: > I support the proposed changes to service levels for invalid POCs. > > Owen > > _______________________________________________ > ARIN-Consult > You are receiving this message because you are subscribed to the ARIN Consult Mailing > List (ARIN-consult at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > From mysidia at gmail.com Mon Nov 15 20:43:09 2010 From: mysidia at gmail.com (James Hess) Date: Mon, 15 Nov 2010 19:43:09 -0600 Subject: [ARIN-consult] [arin-announce] Call for Community Consultation - ARIN Services and Database Access for Invalid Points of Contact (POCs) In-Reply-To: <4CE16D2A.7040601@arin.net> References: <4CE16D2A.7040601@arin.net> Message-ID: On Mon, Nov 15, 2010 at 11:26 AM, ARIN wrote: > ? Template submissions for POC, organization, network modifications, v4 > simple reassignments, v4 detailed reassignments, v4 reallocations, v6 > detailed reassignments and v6 reallocation requests would be returned with a If the information is bad in the first place, 'validating' will be impossible. I would suggest modifying the proposal, to make sure Template submissions that request to fix, replace, or delete invalid POC entries through Org or POC modifications can still be processed, even if there are unvalidated POC entries that exist. If there is bad POC data, it would probably not be beneficial to reject modification requests designed to expunge or fix the invalid POC. Even if that means a new Org template needs to be created to 'report one of your POCs as dead' and 'request all instances of poc X changed to poc Y', or request the proper fix of POC X details. -- -JH From ndavis at arin.net Tue Nov 16 13:18:00 2010 From: ndavis at arin.net (Nate Davis) Date: Tue, 16 Nov 2010 13:18:00 -0500 Subject: [ARIN-consult] Clarification question In-Reply-To: <2E2FECEBAE57CC4BAACDE67638305F10492D9EF3A5@ROCH-EXCH1.corp.pvt> References: <2E2FECEBAE57CC4BAACDE67638305F10492D9EF092@ROCH-EXCH1.corp.pvt> <2E2FECEBAE57CC4BAACDE67638305F10492D9EF3A5@ROCH-EXCH1.corp.pvt> Message-ID: Marla, Good clarifying question. The proposed service change impacts organizations that directly request services and database updates from ARIN. ISP Jingle will not be impacted from requesting ARIN services and database update as a result of their downstream?s invalid POC data. That being said, neither one of your two proposed answers are quite correct. For the example you cited, the answer would be ISP Jingle will not be barred from requesting services from ARIN because they have valid POCs. Furthermore ISP Jingle can continue to subdelegate, SWIP, etc. to customers such as Hip Shop even though the Hip Shop POCs are invalid. However, if Hip Shop were to come to ARIN for services or database update, they would be unable to do so until such time that they corrected their invalid POC information. Regards, Nate From: Azinger, Marla [mailto:Marla.Azinger at FTR.com] Sent: Monday, November 15, 2010 4:06 PM To: Nate Davis; arin-consult at arin.net Subject: RE: Clarification question That helps a bit, but let me ask for your response on one more example. For example if ARIN see's the following Situation visible in WHOIS or RWHOIS: ISP Jingle = valid POC customer of ISP Jingle "Hip Shop" = Invalid POC Possible Answers to how ARIN would respond are: 1. ISP Jingle will not be barred from a new allocation from ARIN if they request one, but Hip Shop will be blocked from an additional re-assignment until ISP Jingle gets their POC updated/validated. Correct? OR 2. ISP Jingle will be barred from a new allocation from ARIN if they request one, as long as their customer Hip Shop has an invalid POC on record in WHOIS. Correct? Sorry for the at nausea questioning and clarifications but I just want to make sure I fully understand how much this change will impact the entities and databases I manage. The below items are the ones I'm focusing on here. I just want to make sure I interpret the level/layer at which the invalid POC alarm will go off at and exactly how this impacts Direct Allocations from ARIN. ? ARIN Online users would only have access to POC validation and modification features until they validate any non-validated POCs to which they are linked. Once validated, an ARIN Online user would have access to all available ARIN Online functionality. ? Templates requesting resources directly from ARIN (v4 ISP request, v4 End-User request, v6 ISP request, v6 End-User request, ASN, experimental), or requesting resource transfers or ASN modifications would be accepted and ticketed, however, they will not be processed if the POC is invalid. ARIN staff would notify submitters via email to validate their associated POC information through ARIN Online. ________________________________ From: arin-consult-bounces at arin.net [mailto:arin-consult-bounces at arin.net] On Behalf Of Nate Davis Sent: Monday, November 15, 2010 12:14 PM To: arin-consult at arin.net Subject: Re: [ARIN-consult] Clarification question Marla, Thanks for your question. The overall goal of this proposed change is to improve all WHOIS POC data, not just those associated with organizations having direct relationship with ARIN. Therefore this includes direct allocation/assignment POCs as well as indirect allocation/assignment POCs. So, an ISP having all valid POCs will NOT be prevented from using ARIN Online or updating the database in cases where their downstream customers have invalid POCs. In the example you cite, assuming ISP Jingle has valid POCs while still having invalid POCs among the 5 downstream reassignments, ISP Jingle will have all access to all services through ARIN Online as well the ability to submit database changes to ARIN. ISP Jingle will not be able to use ARIN Online or request database updates if it?s own POCs are not all valid. Granted the likelihood of an indirect allocation/assignment POC using ARIN Online to maintain data is small, we still wish to provide them the capability to update their records in cases where their upstream ARIN direct organization does not. Please note the community requested that we include indirect POCs as part of POC validation, therefore this is consistent with that policy. Regards, Nate Davis Chief Operating Officer The American Registry for Internet Numbers From: arin-consult-bounces at arin.net [mailto:arin-consult-bounces at arin.net] On Behalf Of Azinger, Marla Sent: Monday, November 15, 2010 12:55 PM To: arin-consult at arin.net Subject: [ARIN-consult] Clarification question I just want to make sure I interpret this correctly. This is saying that direct allocation or assignment recipients of ARIN will basically be forced to update/validate the POC info before gaining any new ARIN resources. Correct? Its NOT saying that direct allocation or assignment recipients of ARIN who have re-assignments or re-allocations recorded in WHOIS with an invalidated or incorrect POC on a re-assignment or re-allocation visible in WHOIS will then block the direct ARIN recipient from getting more ARIN resources? For example if direct recipient "ISP Jingle" has a /18 from ARIN and 5 of his re-assignments to his customers have invalidated or incorrect POC info, these 5 customer of ISP Jingle wont block ISP Jingle from receiving more resources from ARIN will it? This is really only concerning the POC info on the Direct Recipient of ARIN, correct? Thank you Marla -------------- next part -------------- An HTML attachment was scrubbed... URL: From Marla.Azinger at FTR.com Tue Nov 16 19:19:00 2010 From: Marla.Azinger at FTR.com (Azinger, Marla) Date: Tue, 16 Nov 2010 19:19:00 -0500 Subject: [ARIN-consult] Clarification question In-Reply-To: References: <2E2FECEBAE57CC4BAACDE67638305F10492D9EF092@ROCH-EXCH1.corp.pvt> <2E2FECEBAE57CC4BAACDE67638305F10492D9EF3A5@ROCH-EXCH1.corp.pvt> Message-ID: <2E2FECEBAE57CC4BAACDE67638305F10492DA7EC75@ROCH-EXCH1.corp.pvt> Thank you for taking the time to make it clear for me. Cheers Marla ________________________________ From: Nate Davis [mailto:ndavis at arin.net] Sent: Tuesday, November 16, 2010 10:18 AM To: Azinger, Marla; arin-consult at arin.net Subject: RE: Clarification question Marla, Good clarifying question. The proposed service change impacts organizations that directly request services and database updates from ARIN. ISP Jingle will not be impacted from requesting ARIN services and database update as a result of their downstream's invalid POC data. That being said, neither one of your two proposed answers are quite correct. For the example you cited, the answer would be ISP Jingle will not be barred from requesting services from ARIN because they have valid POCs. Furthermore ISP Jingle can continue to subdelegate, SWIP, etc. to customers such as Hip Shop even though the Hip Shop POCs are invalid. However, if Hip Shop were to come to ARIN for services or database update, they would be unable to do so until such time that they corrected their invalid POC information. Regards, Nate From: Azinger, Marla [mailto:Marla.Azinger at FTR.com] Sent: Monday, November 15, 2010 4:06 PM To: Nate Davis; arin-consult at arin.net Subject: RE: Clarification question That helps a bit, but let me ask for your response on one more example. For example if ARIN see's the following Situation visible in WHOIS or RWHOIS: ISP Jingle = valid POC customer of ISP Jingle "Hip Shop" = Invalid POC Possible Answers to how ARIN would respond are: 1. ISP Jingle will not be barred from a new allocation from ARIN if they request one, but Hip Shop will be blocked from an additional re-assignment until ISP Jingle gets their POC updated/validated. Correct? OR 2. ISP Jingle will be barred from a new allocation from ARIN if they request one, as long as their customer Hip Shop has an invalid POC on record in WHOIS. Correct? Sorry for the at nausea questioning and clarifications but I just want to make sure I fully understand how much this change will impact the entities and databases I manage. The below items are the ones I'm focusing on here. I just want to make sure I interpret the level/layer at which the invalid POC alarm will go off at and exactly how this impacts Direct Allocations from ARIN. * ARIN Online users would only have access to POC validation and modification features until they validate any non-validated POCs to which they are linked. Once validated, an ARIN Online user would have access to all available ARIN Online functionality. * Templates requesting resources directly from ARIN (v4 ISP request, v4 End-User request, v6 ISP request, v6 End-User request, ASN, experimental), or requesting resource transfers or ASN modifications would be accepted and ticketed, however, they will not be processed if the POC is invalid. ARIN staff would notify submitters via email to validate their associated POC information through ARIN Online. ________________________________ From: arin-consult-bounces at arin.net [mailto:arin-consult-bounces at arin.net] On Behalf Of Nate Davis Sent: Monday, November 15, 2010 12:14 PM To: arin-consult at arin.net Subject: Re: [ARIN-consult] Clarification question Marla, Thanks for your question. The overall goal of this proposed change is to improve all WHOIS POC data, not just those associated with organizations having direct relationship with ARIN. Therefore this includes direct allocation/assignment POCs as well as indirect allocation/assignment POCs. So, an ISP having all valid POCs will NOT be prevented from using ARIN Online or updating the database in cases where their downstream customers have invalid POCs. In the example you cite, assuming ISP Jingle has valid POCs while still having invalid POCs among the 5 downstream reassignments, ISP Jingle will have all access to all services through ARIN Online as well the ability to submit database changes to ARIN. ISP Jingle will not be able to use ARIN Online or request database updates if it's own POCs are not all valid. Granted the likelihood of an indirect allocation/assignment POC using ARIN Online to maintain data is small, we still wish to provide them the capability to update their records in cases where their upstream ARIN direct organization does not. Please note the community requested that we include indirect POCs as part of POC validation, therefore this is consistent with that policy. Regards, Nate Davis Chief Operating Officer The American Registry for Internet Numbers From: arin-consult-bounces at arin.net [mailto:arin-consult-bounces at arin.net] On Behalf Of Azinger, Marla Sent: Monday, November 15, 2010 12:55 PM To: arin-consult at arin.net Subject: [ARIN-consult] Clarification question I just want to make sure I interpret this correctly. This is saying that direct allocation or assignment recipients of ARIN will basically be forced to update/validate the POC info before gaining any new ARIN resources. Correct? Its NOT saying that direct allocation or assignment recipients of ARIN who have re-assignments or re-allocations recorded in WHOIS with an invalidated or incorrect POC on a re-assignment or re-allocation visible in WHOIS will then block the direct ARIN recipient from getting more ARIN resources? For example if direct recipient "ISP Jingle" has a /18 from ARIN and 5 of his re-assignments to his customers have invalidated or incorrect POC info, these 5 customer of ISP Jingle wont block ISP Jingle from receiving more resources from ARIN will it? This is really only concerning the POC info on the Direct Recipient of ARIN, correct? Thank you Marla -------------- next part -------------- An HTML attachment was scrubbed... URL: