I think Owen’s feedback here is important and worth highlighting to potentially 
reinforce knowledge of that point – duplicative language likely exists in the 
NRPM because in the past it was pointed out that people reading the document 
had a hard time jumping around to piece together the full meaning of a 
particular section. So, effort was made to replicate language inline to meet 
that need. The pendulum is currently swinging the other way – we are discussing 
efforts to remove duplicative language because it is difficult to keep in sync 
administratively.

I bring this up not to take a stance one way or another but to point out that 
having a (relatively) agreed-to organizing principal on this concept will be 
helpful to the AC and anyone contributing policy suggestions.

Not entirely sure how to reflect that, but as a policy shepherd on the AC, it 
would be helpful.

Thanks –


Doug



--
Douglas J. Camin
ARIN Advisory Council
[email protected]

From: ARIN-PPML <[email protected]> on behalf of Owen DeLong via 
ARIN-PPML <[email protected]>
Date: Tuesday, November 28, 2023 at 1:29 PM
To: Dale W. Carder <[email protected]>
Cc: Christian Tacit <[email protected]>, [email protected] 
<[email protected]>
Subject: Re: [arin-ppml] Sections 6.4.1 and 6.4.2 - Potential Simplification 
(from the NRPM Working Group)



On Nov 28, 2023, at 10:23, Dale W. Carder <[email protected]> wrote:

Thus spake owen--- via ARIN-PPML 
([email protected]<mailto:[email protected]>) on Tue, Nov 21, 2023 at 
05:54:49PM -0800:



On Nov 20, 2023, at 12:59, Christian Tacit <[email protected]> wrote:

Dear ARIN Community Members,

In our continuing effort to simplify the NRPM, we are also considering the 
retirement of sections 6.4.1 and 6.4.2.

We believe that section 6.4.1 is out of scope since it constitutes a legal 
conclusion regarding IPv6 addresses not constituting property, rather than 
policy. Section 6.4.2 is a general statement regarding the lack of guarantee of 
the routability of address space and also provides that RIRs (and not just 
ARIN) “must apply procedures that reduce the possibility of fragmented address 
space which may lead to a loss of routability”. To the extent that this section 
validly articulates policy statements, it applies more broadly to both IPv4 and 
IPv6 resources, and the statement in the NRMP should only apply to ARIN. In 
fact, a proper routability constraint statement limited to ARIN is already 
embedded in Section 1.3 of the NRPM, and thus not needed in Section 6.”

Community feedback and any proposals to address these sections are welcome.”

All valid points. The legal conclusion can be left to the RSA or anywhere else 
ARIN’s lawyers which to stick it.

Removing it from the NRPM makes sense to me.

I agree.


6.4.2 needs to at least keep the following key details:
+ ARIN must apply procedures to minimize fragmentation of the address space
+ AIRN cannot guarantee that any block can be routed or will be accepted by any 
particular peer.

Since we don’t have a section of the policy manual for things that apply 
broadly to IPv4 and IPv6, we have, traditionally, duplicated them in sections 4 
and 6, which I think is fine. Preventing fragmentation in IPv4 is already a 
lost cause at this point, so it is what it is.

There's overlap between 6.4.2 and 6.3.4 to some degree on 
fragmentation/aggregation.

The routability aspect in 6.4.2 is also covered in 1.3.

So with respect to Owen's points above this stuff could be merged
together and retained.

Merged, yes, but 6.3.4 talks about the goal and desirability of reducing 
fragmentation. 6.4.2 makes it actual policy that staff must take the 
appropriate steps to do so.

In the past, ew’ve received feedback that depending on a statement far removed 
is confusing to consumers of the document, hence several places in the NRPM 
where text has been duplicated from section 1 into more specific sections 
(mostly 4, 5, and 6). I’m not opposed to reducing or eliminating that 
duplication, so long as we do so consciously and don’t just spin back the other 
way putting duplication back in place a few years later when we get the same 
feedback again.

Owen

_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.

Reply via email to