[arin-ppml] Sections 6.5.1.a and 6.5.1.b - More section 6 Potential simplifications from the NRPM Working Group

[Owen DeLong]

> On Dec 14, 2023, at 17:56, John Curran <jcurran at arin.net> wrote:
> 
> 
> 
>>> On Dec 14, 2023, at 7:49 PM, Owen DeLong <owen at delong.com> wrote:
>>> 
>>> On Dec 14, 2023, at 14:45, John Curran <jcurran at arin.net> wrote:
>>> ….
>>> I am fairly clear what constitutes an ISP and/or a provider of connectivity services, but what services constitute network services?  
>>> 
>>> Does that include an IR that provides VPN/tunnel services?  Companies that provide network monitoring services?  CDN providers?  Networks providing DDoS Mitigation services?  Firms that provide IP address management services, including monitoring of one’s routing/IRR/RPKI/geolocation/rDNS status and leasing of IP address space?  SAAS operations that provide network configuration, monitoring, and IP address management?   
>>> 
>>> Or perhaps “all of the above except for those IR’s that _only_ provide IP address management services” to their customers?
>>> 
>>> Once we step away from ISPs providing connectivity services, things because very fluid and rather quickly. 
>>> 
>>> Note - the inherent flexibility of the term “IR” may not be problem what it comes to IPv6, but has obviously has some potential for interesting consequences for IPv4 administration. 
>> 
>> Right, so in terms of staff interpretation, what would be done with a request for IPv6 resources in each of those scenarios if it arrived today?
> 
> Owen – I believe that they would all be issued IPv6 resources if they requested such. 
> 
> Note in particular the rather thin difference between "Firms that provide IP address management services, including monitoring of one’s routing/IRR/RPKI/geolocation/rDNS status and leasing of IP address space” when compared to “Firms that provide address block management only” –– this is a very fine distinction indeed for ARIN staff to attempt to assert absent clear policy language and intent. 

Agreed. That’s one of the reasons I’ve been trying so hard to get clear guidance on the current interpretation of the policy language as practiced by staff. 

> 
>>>> Unless the answer to that question is yes, then I think the correct fix is to explicitly add the appropriate limitation to the definition of LIR, which is likely editorial since it wouldn’t change staff interpretation of the policy. If the answer to that question is yes, then we do, indeed, have an (at least to me) unexpected divergence between current IPv4 and IPv6 policy and I think the community needs to make a decision on whether we wish to continue to permit IPv6 to be handed out to “Address Management Services”.
>>> 
>>> Indeterminate - see above regarding companies providing “network services” (feel free provide any insight based on your understanding of policy intent.) 
>> 
>> The policy intent was definitely to cover all of the above except address management only. (i.e. all infrastructure based forms of network services). (At least that was the author’s intent when I wrote the policy).
> 
> Understood and thanks for providing that answer – would it be correct to derive from your answer that you consider VPN, virtual hosting, and "SAAS operations that provide network configuration, monitoring, and IP address management” all to be “infrastructure-based forms of network services”?

Yes. All of those seem legitimate to me and are in line with my thinking in writing 6.5.1.a. Since the idea of address leasing had not yet come to my attention at the time of writing, I failed to exclude it. Very hard to prohibit things you don’t know exist or may come to exist. 

>>>> I care not whether this change ends up editorial or not, my focus is on identifying the correct changes to NRPM to get to the desired result (and, for that matter, if there is a discrepancy between the interpretation being applied to IPv6 policy and IPv4 policy, whether or not the community wishes to continue that difference or which direction to go).
>>>> 
>>>> In general, I personally favor prohibiting “Address Management Services” without connectivity.
>>> 
>>> Policy proposals are relatively easy to submit if you wish to make NRPM clearer in any manner. 
>> 
>> I’m sure you are well aware that I am quite familiar with the PDP and how to submit a proposal. ;-)
>> 
>> Nonetheless, I’d like to see clearer answers to the questions you keep side-stepping and further community comment on which way the community as a whole wants to go on the issue.
> 
> No intention of side-stepping, but providing answers to hypothetical requests requires a bit of care (and in cases of ambiguity of policy language it also necessitates review of the policy development.) 

Sure, and I think the above answers are useful and what I was trying to obtain in my previous efforts. 

>> I don’t mind writing a policy proposal, it certainly won’t be my first, but I think it’s reasonable to first try to get a sense of what is likely to achieve support from the community and to get a firm stake in the ground as to where current policy actually stands.
> 
> The present policy language in NRPM doesn’t require that an LIR’s “network services” be for provision of connectivity, nor that they be “infrastructure based” – the staff implementation is faithful to the policy language, and if your intention was otherwise, then it is worth considering potential policy changes with respect to IPv6 policy language given the definition of the term LIR. 

Agreed. 

> ( and to the extent that community moves from the term “ISP” to “LIR” for IPv4 policy language, a similar condition would be created. ) 

Understood. I think the AC should put a pin in this pending the outcome of a larger community discussion that we’ve started here. 

Hopefully some other members of the community will chime in with opinions on what direction we want to go. In any case, I’ll try to draft a proposal based either on my own opinion to correct my omissions in 6.5.1.a and work towards making it possible to harmonize policy around LIR in lieu of ISP or on that combined with whatever community feedback is received by then. 

Thanks,

Owen


> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20231214/2dc15e98/attachment.htm>