Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[rpd] Version: 5.0 "Internet Number Resources review by AFRINIC"

Nishal Goburdhan nishal at
Mon Nov 27 09:10:58 UTC 2017

On 23 Nov 2017, at 20:17, Arnaud AMELINA wrote:

> Hi Nishal,


> We acknowledged that this has been raised and discussed. Main concerns
> being addressed were issues of limited resources.

ok.  i can see how your intent would have not been immediately obvious, 
since you seem to have initially listed as discrete categories 
“EU-ASN”, and, well, there isn’t a shortage of ASNs for general 
use.  or, “IPv6 Large users” because, again, there isn’t really an 
ipv6 shortage.  well, not until the Borg invade, anyway [1].  so 
“limited resources” were certainly not the first words in my mind.

either way, i am happy you’ve moved past that.  i am sure others are 

> The authors have no issue
> with turning the  13.3.1 to the text below:
> {
>  13.3.1 Random
> The member is chosen by AFRINIC at random between the membership.
> }

minor nit:  s/between/from
and, thanks!  treating everyone equally feels less like a witch-hunt, 
eh?  :-)

> We have noted your support to a v6.0 with the new 13.3.1 .

i support the changed text;  but it is premature to say that this is 
support for a v6, since a v6 might include other changes that i might 
not support.  sorry to split hairs, but let’s see the text for 
complete v6 first, ok?

> Same for the two
> others who also opposed v5.0 for the same reason.

i don’t think that either you or i, can do that.  i would _assume_ 
that they support the changed text, as i do.  but, it’s presumptive to 
call support for an as-yet unpublished document.

again, thanks for the edit.

i have a one more question:
13.2 reads:  “ and ASN mappable to two-octet ASNs.”.
with the exception of IXP route-servers, afrinic no longer makes a 
distinction between these, and 32bit ASNs.  this was a point that seemed 
to cause a lot of angst a the mic, in the discussion of the IXP resource 
reservation policies.  given that:
* operators don’t - or more correctly, can’t - care about the ASN 
that they’re allocated
* bgp community support has been extended (and is only just waiting 
implementation), which means that part of the IXP reservation policy 
might not be needed in the future
..why do you want to audit the two ASN types separately?    surely, 
it’s not necessary to add:  “and ASN mappable to two-octet ASNs” ?

other than that, this reads ok to me.  good luck.   :-)



More information about the RPD mailing list