[arin-ppml] Global policy- use of "may & should" ARIN-PPML Digest, Vol 49, Issue 15
Scott Leibrand
scottleibrand at gmail.com
Fri Jul 24 17:53:00 EDT 2009
My main reason for wording it the way I did was to accomplish something
very similar to what Bill suggested, while keeping the text as close as
possible to the original text. Rewritten from scratch, I'd probably go
with something closer to Bill's wording.
Does anyone else have any detailed feedback on how we should word this?
Thanks much,
Scott
RudOlph Daniel wrote:
> 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?
>
> Rudi Daniel
>
>
>
> On Fri, Jul 24, 2009 at 2:36 PM, Scott
> Leibrand<scottleibrand at gmail.com <mailto:scottleibrand at gmail.com>>
> wrote:
> > This is an update on the status of the Global Policy for the
> Allocation
> > of IPv4 Blocks to Regional Internet Registries, which is policy
> proposal
> > 2009-3 here in the ARIN region. Please also see below for an updated
> > version of 2009-3.
> [...]
> > Each RIR through their respective chosen policies and strategies may
> > recover IPv4 address space which is under their administration and
> > designate any such space for return to the IANA. Each RIR shall at
> > quarterly intervals return any such designated address space to
> the IANA
> > in aggregated blocks of /24 or larger, for inclusion in the
> recovered
> > IPv4 pool.
>
> Scott,
>
> Let's parse that: Each RIR [...] may [...] designate any such space
> for return to the IANA.
>
> I object to the intentionally ambiguous and potentially dishonest use
> of the word "may" here. Policy should not describe what we might or
> might not do, it should describe what we will and won't do.
>
> If the intention is to establish an IANA method for accepting returns
> which we might or might not later authorize in some other ARIN policy,
> try replacing "may" with something more precise like "is permitted but
> not required to."
>
> If the intention is that we in fact do return space to IANA as a
> consequence of this policy then replace "may" with "will" and describe
> the criteria for which space returned to ARIN will be subsequently be
> returned to IANA.
>
> Regards,
> Bill Herrin
>
>
> --
> William D. Herrin ................ herrin at dirtside.com
> <mailto:herrin at dirtside.com> bill at herrin.us <mailto:bill at herrin.us>
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 24 Jul 2009 14:54:41 -0500
> From: "Kevin Kargel" <kkargel at polartel.com
> <mailto:kkargel at polartel.com>>
> To: "William Herrin" <bill at herrin.us <mailto:bill at herrin.us>>,
> "Scott Leibrand"
> <scottleibrand at gmail.com <mailto:scottleibrand at gmail.com>>
> Cc: PPML <ppml at arin.net <mailto:ppml at arin.net>>
> Subject: Re: [arin-ppml] Update on 2009-3: Global Policy for the
> Allocationof IPv4 Blocks to RIRs
> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49D89 at mail>
> Content-Type: text/plain; charset="us-ascii"
>
> >
> > Let's parse that: Each RIR [...] may [...] designate any such space
> > for return to the IANA.
> >
> > I object to the intentionally ambiguous and potentially
> dishonest use
> > of the word "may" here. Policy should not describe what we might or
> > might not do, it should describe what we will and won't do.
>
> I agree. Without an explicitly associated 'must' or 'may not'
> then 'may' is
> meaningless. The same applies to "is permitted" or "should". We
> don't need
> rules to allow anything that is not otherwise proscribed.
>
> Anything that does not describe a requirement or an exception is
> just excess
> verbiage.
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/x-pkcs7-signature
> Size: 3224 bytes
> Desc: not available
> URL:
> <http://lists.arin.net/pipermail/arin-ppml/attachments/20090724/cbe35cde/attachment-0001.bin>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 24 Jul 2009 14:55:18 -0500
> From: "Kevin Kargel" <kkargel at polartel.com
> <mailto:kkargel at polartel.com>>
> To: "PPML" <ppml at arin.net <mailto:ppml at arin.net>>
> Subject: [arin-ppml] FW: Update on 2009-3: Global Policy for the
> Allocationof IPv4 Blocks to RIRs
> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49D8A at mail>
> Content-Type: text/plain; charset="us-ascii"
>
>
> >
> > Let's parse that: Each RIR [...] may [...] designate any such space
> > for return to the IANA.
> >
> > I object to the intentionally ambiguous and potentially
> dishonest use
> > of the word "may" here. Policy should not describe what we might or
> > might not do, it should describe what we will and won't do.
>
> I agree. Without an explicitly associated 'must' or 'may not'
> then 'may' is
> meaningless. The same applies to "is permitted" or "should". We
> don't need
> rules to allow anything that is not otherwise proscribed.
>
> Anything that does not describe a requirement or an exception is
> just excess
> verbiage.
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/x-pkcs7-signature
> Size: 3224 bytes
> Desc: not available
> URL:
> <http://lists.arin.net/pipermail/arin-ppml/attachments/20090724/d161873f/attachment.bin>
>
> ------------------------------
>
> _______________________________________________
> ARIN-PPML mailing list
> ARIN-PPML at arin.net <mailto:ARIN-PPML at arin.net>
> http://lists.arin.net/mailman/listinfo/arin-ppml
>
> End of ARIN-PPML Digest, Vol 49, Issue 15
> *****************************************
>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
More information about the ARIN-PPML
mailing list