<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:0 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.apple-tab-span
{mso-style-name:apple-tab-span;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word;overflow-wrap: break-word;-webkit-nbsp-mode: space;line-break:after-white-space">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">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. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Not entirely sure how to reflect that, but as a policy shepherd on the AC, it would be helpful.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Thanks – <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Doug<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">--<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Douglas J. Camin<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">ARIN Advisory Council<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt">doug@dougcamin.com</span><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div id="mail-editor-reference-message-container">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">ARIN-PPML <arin-ppml-bounces@arin.net> on behalf of Owen DeLong via ARIN-PPML <arin-ppml@arin.net><br>
<b>Date: </b>Tuesday, November 28, 2023 at 1:29 PM<br>
<b>To: </b>Dale W. Carder <dwcarder@es.net><br>
<b>Cc: </b>Christian Tacit <ctacit@tacitlaw.com>, arin-ppml@arin.net <arin-ppml@arin.net><br>
<b>Subject: </b>Re: [arin-ppml] Sections 6.4.1 and 6.4.2 - Potential Simplification (from the NRPM Working Group)<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><br>
<br>
<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">On Nov 28, 2023, at 10:23, Dale W. Carder <dwcarder@es.net> wrote:<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:Helvetica">Thus spake owen--- via ARIN-PPML (</span><span style="font-size:11.0pt"><a href="mailto:arin-ppml@arin.net"><span style="font-size:9.0pt;font-family:Helvetica">arin-ppml@arin.net</span></a></span><span style="font-size:9.0pt;font-family:Helvetica">)
on Tue, Nov 21, 2023 at 05:54:49PM -0800:<br style="caret-color: rgb(0, 0, 0);font-variant-caps: normal;text-align:start;-webkit-text-stroke-width: 0px;word-spacing:0px">
<br>
</span><span style="font-size:11.0pt"><o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:Helvetica"><br>
<br>
<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:9.0pt;font-family:Helvetica">On Nov 20, 2023, at 12:59, Christian Tacit <ctacit@tacitlaw.com> wrote:<br>
<br>
Dear ARIN Community Members,<br>
<br>
In our continuing effort to simplify the NRPM, we are also considering the retirement of sections 6.4.1 and 6.4.2.<br>
<br>
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.”<br>
<br>
Community feedback and any proposals to address these sections are welcome.”<o:p></o:p></span></p>
</blockquote>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:Helvetica"><br>
All valid points. The legal conclusion can be left to the RSA or anywhere else ARIN’s lawyers which to stick it.<br>
<br>
Removing it from the NRPM makes sense to me.<o:p></o:p></span></p>
</blockquote>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:Helvetica"><br>
I agree.<br>
<br style="caret-color: rgb(0, 0, 0);font-variant-caps: normal;text-align:start;-webkit-text-stroke-width: 0px;word-spacing:0px">
<br>
</span><span style="font-size:11.0pt"><o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:Helvetica">6.4.2 needs to at least keep the following key details:<br>
+<span class="apple-tab-span"> </span>ARIN must apply procedures to minimize fragmentation of the address space<br>
+<span class="apple-tab-span"> </span>AIRN cannot guarantee that any block can be routed or will be accepted by any particular peer.<br>
<br>
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.<o:p></o:p></span></p>
</blockquote>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:Helvetica"><br>
There's overlap between 6.4.2 and 6.3.4 to some degree on fragmentation/aggregation.<br>
<br>
The routability aspect in 6.4.2 is also covered in 1.3.<br>
<br>
So with respect to Owen's points above this stuff could be merged<br>
together and retained.</span><span style="font-size:11.0pt"><o:p></o:p></span></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Owen<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
</div>
</div>
</div>
</body>
</html>