Utilization after implementation and continued use is not likely to result in any substantial change of need. Addresses are issued based on an initial plan; the word plan is used six times in the NRPM and maps to utilization afterwards in 4.3.3. Whether it starts its utilization life on a server and grows up to move on to a router seems irrelevant. Based on my interpretation (and real world experience)in the NRPM that's defensible. Utilization is a rate of use, not actual use and whether it is on a server today and a router tomorrow? Irrelevant in that optic.
YMMV -M< On Wed, Sep 1, 2021 at 5:39 PM Mike Burns <m...@iptrading.com> wrote: > HI Chris and David, > > I think reclaiming resources for fraud of any kind is perfectly reasonable. > I do not see any need for reporting to ARIN any change of utilization. > Unlike the AFRINIC RSA (and the LACNIC RSA) the ARIN RSA doesn't put > resources at risk for utilization, whether that's a change of utilization > or lack of utilization. > This is how it should be in a registry that allows transfers, otherwise > sellers wouldn't risk coming to ARIN to book a transfer if ARIN could > revoke the addresses for utilization reasons. > > (I think this language in the RSA is one reason for LACNIC's anemic > transfer market. On the other hand it may prove useful to AFRINIC in this > peculiar and likely unique situation.) > > I think we need a clear leasing policy in ARIN, one that allows leased > addresses to be used as justification if those addresses are leased out > with valid recorded assignments (SWIPS). > Leasing has to be recognized as a valid distribution channel for IPv4 > addresses and policy must not stand in the way of that channel evolving > naturally along with the market. > This AFRINIC situation involves leasing, and everywhere leasing is > happening in a policy void. That's asking for problems. > > I think we are in the realm of "hard cases make bad law" if we try to > generalize from the situation in AFRINIC, which really can't be repeated. > There is no sense in trying to protect against a repeat occurence through > a knee-jerk reaction that leads to useless prophylactic policy clutter. > I suppose it bears repeating though, fraud at any point merits revocation. > > > Regards, > Mike > > > > > > ---- On Wed, 01 Sep 2021 16:35:19 -0400 *Chris Woodfield > <ch...@semihuman.com <ch...@semihuman.com>>* wrote ---- > > David - > > In addition to the RSA language John cited, Section 12 of the NRPM gives > ARIN the right to review an organization’s resource usage at any time for > continued compliance with community-driven policy. I suspect that these > reviews are not common, however. What’s more common, in my view, is an > organization’s request for additional resources, which must come with > justification that currently-held resources are being used in compliance > with policy. I do not believe that these are checked against the original > requests for consistency, however. > > I’d be curious if the clause below can be interpreted as giving > organizations a duty to report *any* substantial changes in an > organization’s allocation plans if they diverge from the justification > filed at the time of the request, or only when such changes would have the > effect of putting the organization out of compliance with current policy. I > can see the former interpretation being rather troublesome for a large > number of organizations, given how often business plans and environments > can change over time, as well as adding quite a bit of (IMO unnecessary) > overhead to IP allocation managers. > > That said, I can see ARIN being quite justified in reclaiming resources if > the justification documentation filed with the request had no bearing to > the org’s actual plans. I suspect that to be the unspoken subtext of the > current controversy, and I absolutely believe that ARIN would and should > act similarly in such a scenario (which, in the past, it has). > > Regards,, > > -Chris > > On Sep 1, 2021, at 1:21 PM, John Curran <jcur...@arin.net> wrote: > > David - > > Excellent question. The most important item is for the community to > determine its policy goals in this area, and then based on such what > requirements/duties belong in policy language in Number Resource Policy > Manual (NRPM.) > > The ARIN RSA places an explicit duty of “Information and Cooperation” on > number resource holders (see below) that can be used to enforce > community-developed policy in this area, but the communities thoughts on > the appropriate policy really should drive the discussion – > > *2.(c) Information and Cooperation. Holder has completed an application > provided by ARIN for one or more Services (the “Application”). Holder must > (i) promptly notify ARIN if any information provided in the Application > changes during the term of this Agreement, and (ii) make reasonable efforts > to promptly, accurately, and completely provide any information or > cooperation required pursuant to the Service Terms or in response to any > inquiry or request made to Holder by ARIN during the term of this > Agreement. In addition, Holder shall promptly provide ARIN with complete > and accurate information, and cooperation as required by any Service Terms > or that ARIN requests in connection with ARIN’s provision of any of the > Services to Holder. If Holder does not provide ARIN with such information > or cooperation that ARIN requests, ARIN may take such failure into account > in evaluating Holder’s subsequent requests for transfer, allocation or > assignment of additional number resources, or requests for changes to any > Services. * > > Note that material breach of Section 2(c) is one of the events that > provides ARIN clear right of termination for the RSA and subsequent > revocation of the number resources – so let’s be extra careful when > considering any reporting/information duties for placement into NRPM. > > Thanks! > /John > > > John Curran > President and CEO > American Registry for Internet Numbers > > > On 1 Sep 2021, at 3:47 PM, David Farmer <far...@umn.edu> wrote: > > > I changed the subject line, as this isn't directly related to the dispute > between AFRINIC and CI, but more some questions arising from it > specifically related to the ARIN registered resources. > ---- > > So, do ARIN resource holders have a duty to report changes in their use of > resources? If they do, where does that duty come from in policy or contract > language? And, what are the relevant changes that need to be reported? > > In my review of these questions; > > In the RSA I see where holders are granted, "The right to use the Included > Number Resources within the ARIN database" (RSA section 2.b bullet 2). > However, I don't see any limitation to that use, such as "originally > justified" or any obligation to report a change in such use. > > In policy, "An end-user is an organization receiving assignments of IP > addresses exclusively for use in its operational networks." (NRPM 2.6), > with an exception for incidental or transient use (last paragraph, section > 2.5). > > Maybe to align end-user requirements with the new Registration Services > Agreement we should change that so end-users have to report any use, other > than incidental or transient use, outside their organization. > > And ISP's have requirements to report the use by their customers that > exceed certain levels (NRPM sections 4.2.3.7 and 6.5.5). > > So, other than the ISP reporting requirements, I don't see direct > reporting obligations for change in use. Further, I don't see any guidance > to what might be a material change in use that is in need of reporting, as > I'm sure we don't want ARIN Staff tied up with reports of all possible > changes, most of which are probably irrelevant. > > Are there reporting requirements I'm missing? Maybe implied or indirect > requirement? > > Should something be added to ARIN's policies explicitly stating > requirements for reporting a change in the use of resources? > > Thanks > > > _______________________________________________ > ARIN-PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@arin.net if you experience any issues. > > > _______________________________________________ > ARIN-PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@arin.net if you experience any issues. > > > > _______________________________________________ > ARIN-PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@arin.net if you experience any issues. >
_______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.