Search RPD Archives
[rpd] new version of "Multihoming not required for ASN"(AFPUB-2019-ASN-DRAFT04)
Owen DeLong
owen at delong.com
Thu Nov 28 18:48:24 UTC 2019
Sami,
The fee structure covers what happens with one or multiple ASNs already.
As such, I really don’t think action is required here.
I also don’t believe that this policy will dramatically increase the number of ASNs held by any given organization. It certainly hasn’t in the other 4 regions.
Owen
> On Nov 26, 2019, at 03:10 , Sami Salih <sami.salih at outlook.com> wrote:
>
> Hi Owen
> I think the fees structure specially the ASN part was based on the logic that single of few ASNs will be assigned to members, that why I think no categorisations in section 4 which is addressing ASN fees. This proposal will allow members to hold several ASNs, I'm ok with that, but such resources should be re valuated. For instance, maintenance fees is not applicable for ASN if the organization hold IP resources, this has been figured out based on one of few ASNs so it's need to be reevaluated. Also, in section 6, the assignment fees is waved for additional ASNs. I can't say it's should be changed, rather I think it should be revised with the new method proposed. Overall, we need to make some limits to assure the utilization of ASNs even it's may need 20000yr to be exhausted.
>
> Salam.
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
> From: Owen DeLong <owen at delong.com>
> Sent: Monday, November 25, 2019, 10:31 PM
> To: Sami Salih
> Cc: JORDI PALET MARTINEZ; rpd at afrinic.net
> Subject: Re: [rpd] new version of "Multihoming not required for ASN"(AFPUB-2019-ASN-DRAFT04)
>
>
>
>> On Nov 25, 2019, at 10:00 , Sami Salih <sami.salih at outlook.com <mailto:sami.salih at outlook.com>> wrote:
>>
>> Jordi
>> Positive depends on the side you stands :-)
>>
>> Owen
>> as Jordi clarified, if other documents are affected someone should take care of. I don't have a proposal yet but I just want this to be highlighted, I may come with some proposal for the way forward.
>>
>
> My point is I don’t believe that the documents are affected as you state and I don’t see anything in your statement here or previously which clarifies why you believe that they are affected.
>
> Owen
>
>> Salam
>>
>>
>> Get Outlook for Android <https://aka.ms/ghei36>
>> From: Owen DeLong <owen at delong.com <mailto:owen at delong.com>>
>> Sent: Monday, November 25, 2019 8:47:46 PM
>> To: Sami Salih <sami.salih at outlook.com <mailto:sami.salih at outlook.com>>
>> Cc: JORDI PALET MARTINEZ <jordi.palet at consulintel.es <mailto:jordi.palet at consulintel.es>>; rpd at afrinic.net <mailto:rpd at afrinic.net> <rpd at afrinic.net <mailto:rpd at afrinic.net>>
>> Subject: Re: [rpd] new version of "Multihoming not required for ASN"(AFPUB-2019-ASN-DRAFT04)
>>
>> I’m confused by your statement, Sami.
>>
>> Section 6 covers subsequent resource requests and would therefore be applicable to each ASN beyond the first one. Section 4 covers the first ASN.
>>
>> I don’t think that this policy has any impact on fees or costs to AfriNIC.
>>
>> Owen
>>
>>
>>> On Nov 25, 2019, at 09:28 , Sami Salih <sami.salih at outlook.com <mailto:sami.salih at outlook.com>> wrote:
>>>
>>> Hi Jordi
>>>
>>> I like this version of the proposal despite that some editorials are required.
>>> I would like to draw your attention to the impacts of this proposal on the AFRINIC Membership fees.
>>> https://afrinic.net/membership/cost#resource <https://afrinic.net/membership/cost#resource>
>>>
>>> I believe both section 4 and Section 6 should be revisit as it's not considering multiple ASNs for LIR and EU. Maybe such alignment will be made during staff analysis buts it's better to have it in mind earlier.
>>>
>>> Regards.
>>>
>>>
>>> Get Outlook for Android <https://aka.ms/ghei36>
>>> From: JORDI PALET MARTINEZ via RPD <rpd at afrinic.net <mailto:rpd at afrinic.net>>
>>> Sent: Monday, November 25, 2019 7:22:14 PM
>>> To: rpd at afrinic.net <mailto:rpd at afrinic.net> <rpd at afrinic.net <mailto:rpd at afrinic.net>>
>>> Subject: Re: [rpd] new version of "Multihoming not required for ASN"(AFPUB-2019-ASN-DRAFT04)
>>>
>>> If there is an editorial interpretation problem, we can adjust it, this is not an issue, because in the justification is clear also the intent.
>>>
>>> Hopefully the staff can say something about it :-)
>>>
>>> Regards,
>>> Jordi
>>>
>>> @jordipalet
>>>
>>>
>>>
>>>
>>> El 25/11/19 17:12, "Fernando Frediani" <fhfrediani at gmail.com <mailto:fhfrediani at gmail.com>> escribió:
>>>
>>> Right Jordi, I also see on that way. But the most important is that staff also understands the same way the technical justifications for organizations to receive an ASN whenever they feel like becoming an Autonomous Systems even if they have a single upstream. It is good for them and it is good for the RIR as well.
>>>
>>> Best regards
>>> Fernando Frediani
>>>
>>> On 25/11/2019 12:56, JORDI PALET MARTINEZ via RPD wrote:
>>> Hi Fernando,
>>>
>>> I think they read the same, as explained by Owen. I asked him about that when he proposed that text and I thought about that many times.
>>>
>>> I think it is clear that if you have a single upstream provider and ask you for a public ASN, it is a technical requirement for *that connection*.
>>>
>>> The “or” with the rest of the sentence mean that “both” are choices.
>>>
>>> Note that was the main motivation to have this policy change (single upstream, no other peerings).
>>>
>>> Regards,
>>> Jordi
>>>
>>> @jordipalet
>>>
>>>
>>>
>>>
>>> El 25/11/19 16:44, "Fernando Frediani" <fhfrediani at gmail.com <mailto:fhfrediani at gmail.com>> escribió:
>>>
>>> Hello Jordi
>>>
>>> The change you made on 7.2.2 from "Single interconnection, with a provider that requires a public" to "Show a unique routing policy or demonstrate a technical need for a coordinated globally unique" means different things in my view and may make things slightly more difficult for organizations to receive an ASN.
>>>
>>> When it says "show a unique routing policy" doesn't necessarily mean two Transit providers (it could be an IX, a private peering to another ASN, etc), but excludes the possibility to have an ASN with a single Transit Upstream. On the second part that says "demonstrate a technical need for a coordinated globally unique ASN" what kind of technical need could for example be acceptable to justify to have an ASN with a single Transit Upstream provider (have their own assigned IP space ?) ?
>>> My concern is not to exclude de possibility for organizations to have an ASN even if they have a single interconnection with their Transit Upstream.
>>>
>>> Could you clarify this please ?
>>>
>>> Thanks
>>> Fernando Frediani
>>>
>>> On 25/11/2019 08:45, JORDI PALET MARTINEZ via RPD wrote:
>>> Hi all,
>>>
>>> Find attached a new version of the proposal "Multihoming not required for ASN", following the latest inputs in the list.
>>>
>>> I've also prepared an online diff of the changes to the proposed policy text, so it is easy to track:
>>>
>>> https://www.diffchecker.com/omm6xj7m <https://www.diffchecker.com/omm6xj7m>
>>>
>>>
>>> Regards,
>>> Jordi
>>> @jordipalet
>>>
>>>
>>>
>>>
>>>
>>> **********************************************
>>> IPv4 is over
>>> Are you ready for the new Internet ?
>>> http://www.theipv6company.com <http://www.theipv6company.com/>
>>> The IPv6 Company
>>>
>>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> RPD mailing list
>>> RPD at afrinic.net <mailto:RPD at afrinic.net>
>>> https://lists.afrinic.net/mailman/listinfo/rpd <https://lists.afrinic.net/mailman/listinfo/rpd>
>>> _______________________________________________ RPD mailing list RPD at afrinic.net <mailto:RPD at afrinic.net> https://lists.afrinic.net/mailman/listinfo/rpd <https://lists.afrinic.net/mailman/listinfo/rpd>
>>>
>>> **********************************************
>>> IPv4 is over
>>> Are you ready for the new Internet ?
>>> http://www.theipv6company.com <http://www.theipv6company.com/>
>>> The IPv6 Company
>>>
>>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
>>>
>>>
>>>
>>> _______________________________________________
>>> RPD mailing list
>>> RPD at afrinic.net <mailto:RPD at afrinic.net>
>>> https://lists.afrinic.net/mailman/listinfo/rpd <https://lists.afrinic.net/mailman/listinfo/rpd>
>>> _______________________________________________ RPD mailing list RPD at afrinic.net <mailto:RPD at afrinic.net> https://lists.afrinic.net/mailman/listinfo/rpd <https://lists.afrinic.net/mailman/listinfo/rpd>
>>> **********************************************
>>> IPv4 is over
>>> Are you ready for the new Internet ?
>>> http://www.theipv6company.com <http://www.theipv6company.com/>
>>> The IPv6 Company
>>>
>>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
>>>
>>> From: JORDI PALET MARTINEZ via RPD <rpd at afrinic.net <mailto:rpd at afrinic.net>>
>>> Sent: Monday, November 25, 2019 7:22:14 PM
>>> To: rpd at afrinic.net <mailto:rpd at afrinic.net> <rpd at afrinic.net <mailto:rpd at afrinic.net>>
>>> Subject: Re: [rpd] new version of "Multihoming not required for ASN"(AFPUB-2019-ASN-DRAFT04)
>>>
>>> If there is an editorial interpretation problem, we can adjust it, this is not an issue, because in the justification is clear also the intent.
>>>
>>> Hopefully the staff can say something about it :-)
>>>
>>> Regards,
>>> Jordi
>>>
>>> @jordipalet
>>>
>>>
>>>
>>>
>>> El 25/11/19 17:12, "Fernando Frediani" <fhfrediani at gmail.com <mailto:fhfrediani at gmail.com>> escribió:
>>>
>>> Right Jordi, I also see on that way. But the most important is that staff also understands the same way the technical justifications for organizations to receive an ASN whenever they feel like becoming an Autonomous Systems even if they have a single upstream. It is good for them and it is good for the RIR as well.
>>>
>>> Best regards
>>> Fernando Frediani
>>>
>>> On 25/11/2019 12:56, JORDI PALET MARTINEZ via RPD wrote:
>>> Hi Fernando,
>>>
>>> I think they read the same, as explained by Owen. I asked him about that when he proposed that text and I thought about that many times.
>>>
>>> I think it is clear that if you have a single upstream provider and ask you for a public ASN, it is a technical requirement for *that connection*.
>>>
>>> The “or” with the rest of the sentence mean that “both” are choices.
>>>
>>> Note that was the main motivation to have this policy change (single upstream, no other peerings).
>>>
>>> Regards,
>>> Jordi
>>>
>>> @jordipalet
>>>
>>>
>>>
>>>
>>> El 25/11/19 16:44, "Fernando Frediani" <fhfrediani at gmail.com <mailto:fhfrediani at gmail.com>> escribió:
>>>
>>> Hello Jordi
>>>
>>> The change you made on 7.2.2 from "Single interconnection, with a provider that requires a public" to "Show a unique routing policy or demonstrate a technical need for a coordinated globally unique" means different things in my view and may make things slightly more difficult for organizations to receive an ASN.
>>>
>>> When it says "show a unique routing policy" doesn't necessarily mean two Transit providers (it could be an IX, a private peering to another ASN, etc), but excludes the possibility to have an ASN with a single Transit Upstream. On the second part that says "demonstrate a technical need for a coordinated globally unique ASN" what kind of technical need could for example be acceptable to justify to have an ASN with a single Transit Upstream provider (have their own assigned IP space ?) ?
>>> My concern is not to exclude de possibility for organizations to have an ASN even if they have a single interconnection with their Transit Upstream.
>>>
>>> Could you clarify this please ?
>>>
>>> Thanks
>>> Fernando Frediani
>>>
>>> On 25/11/2019 08:45, JORDI PALET MARTINEZ via RPD wrote:
>>> Hi all,
>>>
>>> Find attached a new version of the proposal "Multihoming not required for ASN", following the latest inputs in the list.
>>>
>>> I've also prepared an online diff of the changes to the proposed policy text, so it is easy to track:
>>>
>>> https://www.diffchecker.com/omm6xj7m <https://www.diffchecker.com/omm6xj7m>
>>>
>>>
>>> Regards,
>>> Jordi
>>> @jordipalet
>>>
>>>
>>>
>>>
>>>
>>> **********************************************
>>> IPv4 is over
>>> Are you ready for the new Internet ?
>>> http://www.theipv6company.com <http://www.theipv6company.com/>
>>> The IPv6 Company
>>>
>>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> RPD mailing list
>>> RPD at afrinic.net <mailto:RPD at afrinic.net>
>>> https://lists.afrinic.net/mailman/listinfo/rpd <https://lists.afrinic.net/mailman/listinfo/rpd>
>>> _______________________________________________ RPD mailing list RPD at afrinic.net <mailto:RPD at afrinic.net> https://lists.afrinic.net/mailman/listinfo/rpd <https://lists.afrinic.net/mailman/listinfo/rpd>
>>>
>>> **********************************************
>>> IPv4 is over
>>> Are you ready for the new Internet ?
>>> http://www.theipv6company.com <http://www.theipv6company.com/>
>>> The IPv6 Company
>>>
>>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
>>>
>>>
>>>
>>> _______________________________________________
>>> RPD mailing list
>>> RPD at afrinic.net <mailto:RPD at afrinic.net>
>>> https://lists.afrinic.net/mailman/listinfo/rpd <https://lists.afrinic.net/mailman/listinfo/rpd>
>>> _______________________________________________ RPD mailing list RPD at afrinic.net <mailto:RPD at afrinic.net> https://lists.afrinic.net/mailman/listinfo/rpd <https://lists.afrinic.net/mailman/listinfo/rpd>
>>> **********************************************
>>> IPv4 is over
>>> Are you ready for the new Internet ?
>>> http://www.theipv6company.com <http://www.theipv6company.com/>
>>> The IPv6 Company
>>>
>>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
>>>
>>> _______________________________________________
>>> RPD mailing list
>>> RPD at afrinic.net <mailto:RPD at afrinic.net>
>>> https://lists.afrinic.net/mailman/listinfo/rpd <https://lists.afrinic.net/mailman/listinfo/rpd>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20191128/0f331dff/attachment-0001.html>
More information about the RPD
mailing list