<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jan 29, 2013, at 02:02 , <a href="mailto:sm+afrinic@elandsys.com">sm+afrinic@elandsys.com</a> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi Guy,<br>At 01:08 24-01-2013, Guy Antony Halse wrote:<br><blockquote type="cite">The problem with this, as with other drafts, is that it assumes that the<br>distinction between end user/end site and LIR is *completely* black and<br>white.<br></blockquote><br>I don't think that the distinction has to be completely black and white.<br></blockquote><div><br></div>If the distinction is not black and white, it becomes very difficult to make it</div><div>a consistent shade of gray. Policy that is not black and white tends to be</div><div>subjective in its nature and makes it very difficult for AfriNIC staff to apply</div><div>it consistently.</div><div><br><blockquote type="cite"><br><blockquote type="cite">Consider the following hypothetical situation:<br><br>I run the internal network for a large, for-profit company.  We want to dual<br>home, so we apply for PI address space.  At this stage we meet the above<br>definition, and thus we apply as an "end site".  We have two ISPs, and<br>everything is great.<br><br>Some time later, perhaps as part of a corporate social responsibility<br>programme, we lease a small NGO a single office in our building.  Although I<br>use the word "lease" (because an agreement exists, and they are a separate<br>legal entity), no money exchanges hands.  We do it because it is the right<br>thing(tm) to do.<br><br>The NGO then asks if we could possible give them Internet access.  We decide<br>that because the impact will be minimal on our operations, we can do so.  We<br>allocate them a subnet from our network, and use this to provide them with<br>Internet access free of charge.  Again it is the right thing(tm) to do.<br>They use less than 1% of our assigned address space, and virtually no bandwidth.<br><br></blockquote></blockquote><div><br></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div>Technically, at this point, you have become an LIR, IMHO. However, I accept that</div><div>there shouldn't necessarily be a fee implication to doing this. How about something</div><div>like this:</div><div><br></div><div>End-User -- An organization which does not delegate resources to other external</div><div>organizations and therefore does not generate SWIP or other sub-delegation or</div><div>re-assignment records.</div><div><br></div><div>Casual LIR -- An organization which is primarily an end-user, but may, in the course</div><div>of its operations, provide internet access and/or resources to a small number of other</div><div>organizations. An LIR qualifies as a casual LIR if it delegates less than 10% of its</div><div>total address holdings or if it provides connectivity and number resources to fewer</div><div>than 5 external organizations. Such an organization is subject to all LIR policies</div><div>regarding record keeping, but shall be billed at the end-user rates unless they</div><div>inform AfriNIC in writing that they wish to be treated as a full LIR.</div><div><br></div><div>Full LIR -- An organization which delegates number resources to external organizations,</div><div>but which does not qualify, or, has elected not to qualify as a Casual LIR.</div></blockquote><div><br></div><div>I believe this gives us a sufficiently black and white definition for consistent</div><div>application of policy while still allowing for the type of utilization you have</div><div>described above.</div><div><br></div><div><blockquote type="cite"><blockquote type="cite">At this stage we technically no longer meet the definition above; we are now<br>technically an LIR because the the space is not used internally any more and<br>because we've made a single, very small sub-allocation.<br><br></blockquote></blockquote><div><br></div>True.</div><div><br><blockquote type="cite"><blockquote type="cite">Assuming we're honest about it, in terms of AfriNIC's cost structures and<br>this policy, things change:<br><br> - 8.5 requires I register the allocation with AfriNIC;<br><br></blockquote></blockquote><div><br></div>Which is valid, IMHO.</div><div><br><blockquote type="cite"><blockquote type="cite"> - I am now subject to the requirements of sections 8 through 10;<br><br></blockquote></blockquote><div><br></div>As should be the case.</div><div><br><blockquote type="cite"><blockquote type="cite"> - The fees due to AfriNIC increase (outside the scope of this policy, but<br>   relevant to the discussion).<br><br></blockquote></blockquote><div><br></div>Which I agree could be adressed. What do you think of the above proposal?</div><div><br><blockquote type="cite"><blockquote type="cite">Our management decides that the additional cost and administrative burden<br>this imposes it too onerous and cannot be justified.  It was fine when we<br>were just running a UTP cable through the wall, but now we have to complete<br>paperwork and spend (recurring) money.  Thus we have two choices:<br><br></blockquote></blockquote><div><br></div>Well, failing to do the paperwork has implications for the community. Also, your</div><div>management should consider the risk that the actions committed with those</div><div>addresses could reflect on your organization even though you have given up</div><div>direct control of the addresses. Having this fact recorded is somewhat of a</div><div>liability and/or image shield for your organization. Technically, the paperwork</div><div>is pretty small.</div><div><br></div><div><blockquote type="cite"><blockquote type="cite"> a) lie (perhaps tacitly, by simply not telling) to AfriNIC.  This carries<br>    the risk we'll be caught, and lose our assignment (per 6.1); or<br><br></blockquote></blockquote>Undesirable for a number of other reasons, as well. (see my previous</div><div>paragraph).</div><div><br><blockquote type="cite"><blockquote type="cite"> b) cease providing the NGO with Internet access.<br><br></blockquote></blockquote><div><br></div>Unfortunate. However, I thin the fee issue is the bigger barrier than the</div><div>paperwork, right?</div><div><br><blockquote type="cite"><blockquote type="cite">Neither of these are desirable outcomes.<br></blockquote><br></blockquote><div><br></div>Agreed. Let's try to find a cooperative solution.</div><div><br></div><div>Finally, I chose 10% as a rather arbitrary number. I'm actually fine with</div><div>any value between 5 and 25, whatever the community thinks is most</div><div>appropriate. The number 10 organizations is also an arbitrary placeholder.</div><div>I think any number ≤20 is probably acceptable here and welcome</div><div>input from the community.</div><div><br></div><div><br><blockquote type="cite">[snip]<br><br><blockquote type="cite">Thus I'm really opposed to any definition of "end user" or "end site" that<br>doesn't allow /some/ flexibility for the grey areas.  I'm happy if this<br>flexibility is formally qualified in policy -- appropriate restrictions<br>include limitations on the amount of address space ("no more than 10%"),<br>they type of organisation or relationship ("not-for-profit"), or whether or<br>not this is how I make money or why I exist ("core business").<br></blockquote><br>I am ok with not including any definition of "end user" or "end site".  IPv4 PI address space is covered by AFPUB-2006-GEN-001 anyway.  Any limitation, restriction, relationship, etc. (re. case mentioned above) might have to be in AFPUB-2006-GEN-001.<br><br></blockquote><div><br></div>You kind of need a definition here of end-user and end-site, since they are referenced in regard to reassignments.</div><div><br><blockquote type="cite">As an off-topic comment, AfriNIC trained around 450 persons last year.  There are less than 10 persons who have commented on this proposal.  That doesn't provide a broad view of IP addressing-related problems across the region.  By the way, I am okay with objections as that is part of policy development.<br><br></blockquote>+1</div><div><br></div><div>Owen</div><div><br></div></body></html>