<div class="gmail_quote"><div>My tendency is to agree with Bill Herrin and Kevin on the use of "may" and "should" in policy statemebts; but does the AC have a motive in the use of such?</div><div><br></div>
<div>Rudi Daniel</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
<br>
On Fri, Jul 24, 2009 at 2:36 PM, Scott Leibrand<<a href="mailto:scottleibrand@gmail.com">scottleibrand@gmail.com</a>> wrote:<br>
> This is an update on the status of the Global Policy for the Allocation<br>
> of IPv4 Blocks to Regional Internet Registries, which is policy proposal<br>
> 2009-3 here in the ARIN region. Please also see below for an updated<br>
> version of 2009-3.<br>
[...]<br>
> Each RIR through their respective chosen policies and strategies may<br>
> recover IPv4 address space which is under their administration and<br>
> designate any such space for return to the IANA. Each RIR shall at<br>
> quarterly intervals return any such designated address space to the IANA<br>
> in aggregated blocks of /24 or larger, for inclusion in the recovered<br>
> IPv4 pool.<br>
<br>
Scott,<br>
<br>
Let's parse that: Each RIR [...] may [...] designate any such space<br>
for return to the IANA.<br>
<br>
I object to the intentionally ambiguous and potentially dishonest use<br>
of the word "may" here. Policy should not describe what we might or<br>
might not do, it should describe what we will and won't do.<br>
<br>
If the intention is to establish an IANA method for accepting returns<br>
which we might or might not later authorize in some other ARIN policy,<br>
try replacing "may" with something more precise like "is permitted but<br>
not required to."<br>
<br>
If the intention is that we in fact do return space to IANA as a<br>
consequence of this policy then replace "may" with "will" and describe<br>
the criteria for which space returned to ARIN will be subsequently be<br>
returned to IANA.<br>
<br>
Regards,<br>
Bill Herrin<br>
<br>
<br>
--<br>
William D. Herrin ................ <a href="mailto:herrin@dirtside.com">herrin@dirtside.com</a> <a href="mailto:bill@herrin.us">bill@herrin.us</a><br>
3005 Crane Dr. ...................... Web: <<a href="http://bill.herrin.us/" target="_blank">http://bill.herrin.us/</a>><br>
Falls Church, VA 22042-3004<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Fri, 24 Jul 2009 14:54:41 -0500<br>
From: "Kevin Kargel" <<a href="mailto:kkargel@polartel.com">kkargel@polartel.com</a>><br>
To: "William Herrin" <<a href="mailto:bill@herrin.us">bill@herrin.us</a>>, "Scott Leibrand"<br>
<<a href="mailto:scottleibrand@gmail.com">scottleibrand@gmail.com</a>><br>
Cc: PPML <<a href="mailto:ppml@arin.net">ppml@arin.net</a>><br>
Subject: Re: [arin-ppml] Update on 2009-3: Global Policy for the<br>
Allocationof IPv4 Blocks to RIRs<br>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49D89@mail><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
><br>
> Let's parse that: Each RIR [...] may [...] designate any such space<br>
> for return to the IANA.<br>
><br>
> I object to the intentionally ambiguous and potentially dishonest use<br>
> of the word "may" here. Policy should not describe what we might or<br>
> might not do, it should describe what we will and won't do.<br>
<br>
I agree. Without an explicitly associated 'must' or 'may not' then 'may' is<br>
meaningless. The same applies to "is permitted" or "should". We don't need<br>
rules to allow anything that is not otherwise proscribed.<br>
<br>
Anything that does not describe a requirement or an exception is just excess<br>
verbiage.<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: smime.p7s<br>
Type: application/x-pkcs7-signature<br>
Size: 3224 bytes<br>
Desc: not available<br>
URL: <<a href="http://lists.arin.net/pipermail/arin-ppml/attachments/20090724/cbe35cde/attachment-0001.bin" target="_blank">http://lists.arin.net/pipermail/arin-ppml/attachments/20090724/cbe35cde/attachment-0001.bin</a>><br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Fri, 24 Jul 2009 14:55:18 -0500<br>
From: "Kevin Kargel" <<a href="mailto:kkargel@polartel.com">kkargel@polartel.com</a>><br>
To: "PPML" <<a href="mailto:ppml@arin.net">ppml@arin.net</a>><br>
Subject: [arin-ppml] FW: Update on 2009-3: Global Policy for the<br>
Allocationof IPv4 Blocks to RIRs<br>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49D8A@mail><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
<br>
><br>
> Let's parse that: Each RIR [...] may [...] designate any such space<br>
> for return to the IANA.<br>
><br>
> I object to the intentionally ambiguous and potentially dishonest use<br>
> of the word "may" here. Policy should not describe what we might or<br>
> might not do, it should describe what we will and won't do.<br>
<br>
I agree. Without an explicitly associated 'must' or 'may not' then 'may' is<br>
meaningless. The same applies to "is permitted" or "should". We don't need<br>
rules to allow anything that is not otherwise proscribed.<br>
<br>
Anything that does not describe a requirement or an exception is just excess<br>
verbiage.<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: smime.p7s<br>
Type: application/x-pkcs7-signature<br>
Size: 3224 bytes<br>
Desc: not available<br>
URL: <<a href="http://lists.arin.net/pipermail/arin-ppml/attachments/20090724/d161873f/attachment.bin" target="_blank">http://lists.arin.net/pipermail/arin-ppml/attachments/20090724/d161873f/attachment.bin</a>><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
ARIN-PPML mailing list<br>
<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a><br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
<br>
End of ARIN-PPML Digest, Vol 49, Issue 15<br>
*****************************************<br>
</blockquote></div><br><br clear="all"><br><br>