<div dir="ltr">I've reverted to the original thread name because this is squarely within addressing the objections and possibly getting to a basis to move past last call.<div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear Paul,</blockquote><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thank you for your detailed response.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I must admit that I am struggling to understand the direction of your argument. While you raise several points about policy and operational matters, it is not clear to me how they demonstrate that this proposal requires a policy solution rather than an operational one.</blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="background-color:transparent">Could you clarify which specific concern cannot be addressed operationally </span><span style="background-color:transparent">and why a policy obligation is the only appropriate approach?</span></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="background-color:transparent">I believe that distinction is central to the discussion.</span></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="background-color:transparent">*BR,*</span></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="background-color:transparent">*Thandeka Mseleku*</span></blockquote><div><br></div><div>That is probably because there are a couple of arguments in the post - and a lot of the argument is adopting a synthesis approach (it is also why I didn't use the subject line of the proposal)</div><div><br></div><div>The word policy here needs to be unpacked. Because in all instances we are dealing with a policy. You can have unwritten policies, informal policies etc ... So whatever comes up there is a "policy" involved. So the question, even if you are objecting to the proposal, is not whether there should be a policy (because there is one of some form) but rather whether a policy adopted by the RPD list and PDP processes as a community policy on AFRINIC. If the operational objective here is achieved through a software change then the policy underlying that software is where the policy is found. A comment appearing in some rust code (or is it rusty c code) is just as much a policy statement as anything else. What is being debated is about a formal "Policy" - big P policy. In this instance the big P policy is a formal community policy appearing in the CPM. </div></div><div>So in the case of AFRINIC there is a Consolidated Policy Manual. This Manual binds AFRINIC and informs implementation. Therefore if the community wishes to impose something onto an implementation and wants text to appear in the CPM then this is the means to do it.</div><div>The CPM in chapter 7 deals with ASN (<a href="https://afrinic.net/consolidated-policy-manual.html#ASN">https://afrinic.net/consolidated-policy-manual.html#ASN</a>) and this chapter certainly has implications for resource holders etc ... 7.7 potentially can allow for the scope creep for which concern has been expressed but that isn't at issue here.</div><div><br></div><div>So the question then is would CPM chapter 7 be better or worse with the addition of 7.8. I fear that the objectors to the policy are erroneously concluding the 7.8 will impose something that is better handled as an operational matter. This is wrong because what 7.8 will do is dictate to AFRINIC something that would otherwise be handled within 7.7. The outcome is to reduce discretion rather than create it.</div><div><br></div><div>In fact, thinking about it, my only disagreement with the proposal as written is that it doesn't slot in as 7.7 and renumber 7.7 to 7.8 - although I think most people would prefer to avoid renumbering here.</div><div><br></div><div>The specific concern which is addressed by inclusion in the CPM is that it directs the development of AFRINIC tools. More importantly the proposal correctly locates the "policy obligation" onto the right point - AFRINIC (in tool development). You'll notice that I indicate my concern that the explanation on implementation can be improved - discussed further below.</div><div><br></div><div>It is not necessary (I think Andrew and Jordi have properly addressed this aspect) that the proposal be "the only appropriate approach". The threshold is that the approach is not inappropriate.</div><div><br></div><div><pre style=""><blockquote class="gmail_quote" style="color:rgb(0,0,0);margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear Paul,</blockquote><div style="color:rgb(0,0,0)"> </div><blockquote class="gmail_quote" style="color:rgb(0,0,0);margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-family:Arial,Helvetica,sans-serif;background-color:transparent">Your own framing points to the central issue.</span></blockquote><div style="color:rgb(0,0,0)"> </div><blockquote class="gmail_quote" style="color:rgb(0,0,0);margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-family:Arial,Helvetica,sans-serif;background-color:transparent">RFC 2622 provides the specification, and AFRINIC’s database provides the </span><span style="font-family:Arial,Helvetica,sans-serif;background-color:transparent">implementation. The disputed extra layer is policy. If this is a </span><span style="font-family:Arial,Helvetica,sans-serif;background-color:transparent">service-side change that creates no obligation, sanction, or operational </span><span style="font-family:Arial,Helvetica,sans-serif;background-color:transparent">burden for resource holders, then a transparent implementation plan should </span><span style="font-family:Arial,Helvetica,sans-serif;background-color:transparent">be sufficient.</span></blockquote><div style="color:rgb(0,0,0)"> </div><blockquote class="gmail_quote" style="color:rgb(0,0,0);margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-family:Arial,Helvetica,sans-serif;background-color:transparent">A technical specification does not automatically require an institutional </span><span style="font-family:Arial,Helvetica,sans-serif;background-color:transparent">mandate. Policy creates permanence, interpretation risk, and precedent </span><span style="font-family:Arial,Helvetica,sans-serif;background-color:transparent">beyond the immediate database change. “It affects AFRINIC, not resource </span><span style="font-family:Arial,Helvetica,sans-serif;background-color:transparent">holders” is therefore not a complete safeguard, because AFRINIC remains the </span><span style="font-family:Arial,Helvetica,sans-serif;background-color:transparent">institution interpreting and enforcing the resulting rule.</span></blockquote><div style="color:rgb(0,0,0)"> </div><blockquote class="gmail_quote" style="color:rgb(0,0,0);margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-family:Arial,Helvetica,sans-serif;background-color:transparent">I support your request for the exact text and implementation plan. They </span><span style="font-family:Arial,Helvetica,sans-serif;background-color:transparent">should also state plainly that the change: </span><span style="font-family:Arial,Helvetica,sans-serif;background-color:transparent">is implemented only on the service side; </span><span style="font-family:Arial,Helvetica,sans-serif;background-color:transparent">creates no compliance duty or sanction for resource holders; </span><span style="font-family:Arial,Helvetica,sans-serif;background-color:transparent">cannot be extended to existing objects without a new review; </span><span style="font-family:Arial,Helvetica,sans-serif;background-color:transparent">and will be measured and reconsidered if the expected operational benefit </span><span style="font-family:Arial,Helvetica,sans-serif;background-color:transparent">does not appear.</span></blockquote><div style="color:rgb(0,0,0)"> </div><blockquote class="gmail_quote" style="color:rgb(0,0,0);margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-family:Arial,Helvetica,sans-serif;background-color:transparent">...  </span><span style="font-family:Arial,Helvetica,sans-serif;background-color:transparent">The registry should implement what the system technically requires. It </span><span style="font-family:Arial,Helvetica,sans-serif;background-color:transparent">should not turn implementation convenience into permanent policy authority.</span></blockquote><div style="color:rgb(0,0,0)"> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="color:rgb(0,0,0);font-family:Arial,Helvetica,sans-serif;background-color:transparent">Regards, </span><span style="color:rgb(0,0,0);font-family:Arial,Helvetica,sans-serif;background-color:transparent">Nonhlanhla</span></blockquote><br><br><font face="arial, sans-serif">I don't see any point of disagreement except that, for the reason I've given, there is a benefit in a "big P policy" - a formal inclusion in the CPM. The concerns you appear to be relying upon arise in the existing text in 7.7. I don't see any reason the co-chairs can't give us 3 things:<br>[1] the wording of the policy<br>[2] the implementation plan<br>[3] what the CPM chapter 7 will look like in its entirety.<br><br>Saying that they should do so is not an expression that they are obligated to - that's an entirely different debate - but rather is a proposition that doing so will align with the intent and objective of this process.<br><br>Because of the existing CPM paragraph 7 (I think they called sections but I am actually not sure) the text does in fact safeguard. An implementation plan speaks to how a given policy (whether formal or otherwise) is brought into effect. The argument that you can implement directly presupposes that there isn't a reason to put the text into the manual.<br><br>Therefore in addition to the fact that there is rough consensus at the PPM I think there is an adequate basis to infer that the proposal addresses the concerns raised when properly unpacked.</font></pre></div></div></div>