[ARIN-consult] Clarification question

[Nate Davis]

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: <https://lists.arin.net/pipermail/arin-consult/attachments/20101116/727fd2cd/attachment.html>