Search RPD Archives
[rpd] RPD Digest, Vol 222, Issue 111
Nia Petronella
nonhlanhlapetronella85 at gmail.com
Tue Jul 21 11:13:49 UTC 2026
Dear Andrew,
Your reply clarifies where we disagree.
I am not arguing that AFRINIC has no authority to adopt policy. I am
arguing that the existence of authority does not prove that policy is the
correct instrument in every case. Authority to act is not a requirement to
act, and a bylaw cannot substitute for a necessity test.
Even accepting your reading of Article 3.4, it defines AFRINIC’s corporate
scope. It does not automatically turn every operational IRR setting into a
policy matter. Nor does a vote by members prove that a self-selecting
policy forum represents every network or party affected by the resulting
enforcement.
The concern is concrete: policy converts a technical setting that could be
implemented, tested, reviewed, and revised operationally into a binding
rule administered by AFRINIC. That adds rigidity, enforcement, and
precedent. If other RIRs can achieve the same result through operational
processes, proponents should explain what additional technical outcome
AFRINIC gains by using policy.
I also disagree that an objection is valid only if it proves immediate
operational harm or implementation failure. Policy design must consider
scope, proportionality, reversibility, and whether the least coercive
mechanism is being used. A proposal may be technically implementable and
still be unnecessary as binding policy.
Your IETF comparison points toward restraint, not automatic deference to
process. Rough consensus is disciplined by running code and operational
reality. It does not mean that a proposal proceeds unless objectors prove
catastrophe. Nor is an objection “addressed” merely because supporters
repeat that the bylaws permit policy. That does not answer why policy is
necessary here.
Finally, saying that “the community has consistently agreed” cannot resolve
a challenge about the limits of community mandate. Participation provides
expertise, support, warning, and objection. It does not make mailing-list
participants the legal principals of every affected operator.
My objection is therefore not that I simply dislike AFRINIC having power.
It is that the policy route has not been shown to be necessary for the
technical result sought. Kone’s question about the choice of instrument
remains unanswered.
I remain opposed to AFPUB-2026-ASN-001-DRAFT02.
Regards,
Nonhlanhla
On Tue, 21 Jul 2026, 12:20 pm Andrew Alston <aa at alstonnetworks.net> wrote:
> Hi Nia,
>
> Ok, let me try and further expand on what I have said.
>
> Firstly - in a rough consensus approach - an objection carries weight when
> it is factually backed up and proves a real problem. From what I can see,
> your objection fails to meet this threshold. It is the objector's
> obligation to substantiate objections to the point where they can be
> answered and addressed.
>
> Now, looking at your objection, it seems to be that the policy expands
> AfriNIC's mandate and grants them more power. I point out that AfriNIC's
> mandate is clearly spelled out in article 3.4 of the bylaws as currently
> written, which was amended by a supermajority vote of the members.
>
> In my opinion, you have yet to articulate the harm this policy creates or
> explain how it falls outside the scope of the PDP or the AfriNIC mandate as
> defined in its bylaws. While you may prefer AfriNIC to be simply a
> database without policy restrictions, that is not what this community has
> consistently agreed upon, nor is it what the bylaws voted on by the members
> endorse. As such, I believe your position has been addressed by the mandate
> given to AfriNIC under section 3.4 of the bylaws.
>
> During my tenure as an Area Director within the IETF, I often saw
> disagreements on particular standards. It was always the objector's
> responsibility to articulate the real problem, and then the working group
> decided if that disagreement was sufficient to justify blocking the
> proposal.
>
> From what I have seen - your objection seems to be "I don't like this
> because it gives AfriNIC power of enforcement where such is unnecessary".
> I disagree with this stance and believe that the policy committee has the
> right to set policy as it sees fit, and you have not demonstrated any real
> HARM from the policy.
>
> Thanks
>
> Andrew
>
>
>
>
> On Tue, Jul 21, 2026 at 12:57 PM Nia Petronella <
> nonhlanhlapetronella85 at gmail.com> wrote:
>
>> Dear Andrew,
>>
>> I do not accept the binary you have presented.
>>
>> No one is suggesting that AFRINIC should make operational changes in
>> secret or without community input. An operational change can be published,
>> consulted on, tested, documented, and reviewed. The real question is
>> whether that input must be converted into binding policy enforced by the
>> registry.
>>
>> Calling AFRINIC “community-driven” does not answer who the community is
>> or what it is authorised to bind. A self-selecting group of mailing-list
>> participants can provide expertise, support, and objection. It does not
>> automatically represent every member, resource holder, network, customer,
>> or other affected party.
>>
>> The institutional reality also remains unchanged: participants discuss
>> the policy, but AFRINIC interprets and enforces it. Community participation
>> therefore does not eliminate registry power. It can become the language
>> used to legitimise that power.
>>
>> This is why Kone’s examples matter. If LACNIC, RIPE NCC, and ARIN can
>> achieve the same technical outcome through operational mechanisms, then
>> policy is not technically inevitable. Proponents should explain what
>> additional technical result binding policy provides, beyond converting an
>> IRR setting into an enforceable obligation.
>>
>> I also disagree that an objection is valid only if it proves immediate
>> operational harm or implementation failure. The choice of instrument,
>> proportionality, reversibility, and expansion of enforcement authority are
>> legitimate policy concerns. Last Call is not limited to asking whether
>> software will break. It must also ask whether the proposed power is greater
>> than the problem requires.
>>
>> Rough consensus does not require every objection to be accommodated. But
>> an objection is not “addressed” merely because supporters repeat that the
>> community prefers policy. That is the very assumption being challenged.
>> Procedure cannot be used to prove its own mandate.
>>
>> The fact that the RIR system has operated this way for decades
>> demonstrates continuity of practice. It does not establish unlimited
>> legitimacy of scope.
>>
>> I support Kone’s questions and remain opposed to
>> AFPUB-2026-ASN-001-DRAFT02.
>>
>> Regards,
>> Nonhlanhla
>>
>>
>>
>> On Tue, 21 Jul 2026, 10:26 am Andrew Alston <aa at alstonnetworks.net>
>> wrote:
>>
>>> The answer to this is simple. AfriNiC is a community driven
>>> organisation - and anything done with regard to address allocation and
>>> management is done as per policy provided by the community. It is through
>>> policy that the community tells AfriNIC how to do things in regards to the
>>> allocation and handling of resources.
>>>
>>> Without policy, the discretion and rules are entirely in the hands of
>>> the registry, and the community voice is removed.
>>>
>>> This has been the way the RIR system has operated for decades and it
>>> works. The community exercises its voice and its right as to how things
>>> are done in relation to resource management through policy.
>>>
>>> Arguing that just because something can be done another way, is not in
>>> my view a valid argument against policy. Objections to policy need to be
>>> technically grounded and demonstrate that the policy would either cause
>>> harm or alternatively be impractical to implement. Anything else is simply
>>> arguing that policy should not exist because someone doesn’t like AfriNIC
>>> being told how the community wants things done - and that isn’t an argument
>>> that I believe rises to the level of a block on consensus.
>>>
>>> Please note - consensus does not require that the issue you raise have
>>> been fixed, it requires that they have been addressed, and should the
>>> community feel that despite the objections, the policy is something that
>>> should proceed based on the fact that the questions have been addressed if
>>> not necessarily accommodated, rough consensus still exists.
>>>
>>> Again, I support the policy and I see no technical or
>>> evidence/fact-based arguments against said policy.
>>>
>>> Andrew
>>>
>>> On Tue, Jul 21, 2026 at 09:34, Nia Petronella <
>>> nonhlanhlapetronella85 at gmail.com> wrote:
>>>
>>>> Dear PDWG,
>>>>
>>>> Kone is asking the right question.
>>>>
>>>> The issue is no longer whether hierarchical AS-SET naming is
>>>> technically possible or useful. It already exists. The issue is why AFRINIC
>>>> needs a binding policy to enforce what other RIRs largely treat as an
>>>> operational IRR matter.
>>>>
>>>> That distinction matters. An operational change adjusts how a service
>>>> is implemented. A policy creates an enforceable obligation and enlarges the
>>>> registry’s authority. If the same technical result can be achieved through
>>>> a community-reviewed implementation plan, then policy is not the minimum
>>>> necessary instrument.
>>>>
>>>> Saying that “the community prefers policy” is not enough. Participation
>>>> may guide technical work, but it does not turn every preference into a
>>>> mandate. A mailing list is not a legislature, and the availability of the
>>>> PDP should not make policy the default answer to every operational setting.
>>>>
>>>> This is how gatekeeping expands: the registry begins with a useful
>>>> technical function, then policy converts that function into permission and
>>>> enforcement. The recordkeeper gradually becomes the rule-maker.
>>>>
>>>> The proponents should therefore answer Kone directly: what technical
>>>> outcome can mandatory policy achieve here that an operational
>>>> implementation cannot?
>>>>
>>>> Until that is clearly demonstrated, I support Kone’s questions and
>>>> remain opposed to the policy route.
>>>>
>>>> Regards,
>>>> Nonhlanhla
>>>>
>>>>
>>>>
>>>> On Tue, 21 Jul 2026, 8:20 am <rpd-request at afrinic.net> wrote:
>>>>
>>>>> Send RPD mailing list submissions to
>>>>> rpd at afrinic.net
>>>>>
>>>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>>> https://lists.afrinic.net/mailman/listinfo/rpd
>>>>> or, via email, send a message with subject or body 'help' to
>>>>> rpd-request at afrinic.net
>>>>>
>>>>> You can reach the person managing the list at
>>>>> rpd-owner at afrinic.net
>>>>>
>>>>> When replying, please edit your Subject line so it is more specific
>>>>> than "Re: Contents of RPD digest..."
>>>>>
>>>>>
>>>>> Today's Topics:
>>>>>
>>>>> 1. Re: RPD Digest, Vol 222, Issue 110 (Tshepo Masuku)
>>>>>
>>>>>
>>>>> ----------------------------------------------------------------------
>>>>>
>>>>> Message: 1
>>>>> Date: Tue, 21 Jul 2026 06:19:05 +0000
>>>>> From: Tshepo Masuku <TshepoMasuku26 at hotmail.com>
>>>>> To: "rpd at afrinic.net" <rpd at afrinic.net>
>>>>> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 110
>>>>> Message-ID:
>>>>> <
>>>>> VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com
>>>>> >
>>>>>
>>>>> Content-Type: text/plain; charset="windows-1252"
>>>>>
>>>>> Dear All,
>>>>>
>>>>> Kone?s point is directly relevant. If LACNIC, RIPE NCC, and ARIN can
>>>>> implement hierarchical AS-SET naming through operational mechanisms, then
>>>>> proponents must explain why AFRINIC needs a binding policy to achieve the
>>>>> same technical result.
>>>>>
>>>>> Saying that each RIR works differently does not answer that question.
>>>>> Nor does saying that ?the community is on top of the RIR.? A community may
>>>>> advise, object, and coordinate. It does not acquire unlimited authority to
>>>>> convert every operational preference into policy. A mailing list is not a
>>>>> legislature.
>>>>>
>>>>> If AFRINIC can solve this through an operational change, policy adds
>>>>> governance where technical administration would be sufficient. Speed and
>>>>> preference do not create mandate.
>>>>>
>>>>> Kone provided specific examples. Those should be answered with
>>>>> evidence, not by questioning whether he has worked in every RIR for many
>>>>> years. Experience is relevant, but it is not authority and it is not a
>>>>> substitute for argument.
>>>>>
>>>>> The unanswered question remains: what technical necessity requires
>>>>> policy rather than operational implementation?
>>>>>
>>>>> Until that is answered, Kone?s objection stands, and I support it.
>>>>>
>>>>> Regards,
>>>>> Tshepo
>>>>>
>>>>>
>>>>> ________________________________
>>>>> From: rpd-request at afrinic.net <rpd-request at afrinic.net>
>>>>> Sent: Monday, July 20, 2026 11:10:57 pm
>>>>> To: rpd at afrinic.net <rpd at afrinic.net>
>>>>> Subject: RPD Digest, Vol 222, Issue 110
>>>>>
>>>>> Send RPD mailing list submissions to
>>>>> rpd at afrinic.net
>>>>>
>>>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>>> https://lists.afrinic.net/mailman/listinfo/rpd
>>>>> or, via email, send a message with subject or body 'help' to
>>>>> rpd-request at afrinic.net
>>>>>
>>>>> You can reach the person managing the list at
>>>>> rpd-owner at afrinic.net
>>>>>
>>>>> When replying, please edit your Subject line so it is more specific
>>>>> than "Re: Contents of RPD digest..."
>>>>>
>>>>>
>>>>> Today's Topics:
>>>>>
>>>>> 1. Re: Writing tools (Ben Roberts - AfriNIC)
>>>>> 2. Re: [Last Call] Draft Policy Proposal - Hierarchical Names
>>>>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Kone)
>>>>> 3. Re: [Last Call] Draft Policy Proposal - Hierarchical Names
>>>>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02)
>>>>> (jordi.palet at consulintel.es)
>>>>>
>>>>>
>>>>> ----------------------------------------------------------------------
>>>>>
>>>>> Message: 1
>>>>> Date: Mon, 20 Jul 2026 21:26:40 +0200
>>>>> From: Ben Roberts - AfriNIC <ben.roberts at afrinic.net>
>>>>> To: Nonjabulo Sphilile <nonjabulosphilile at gmail.com>
>>>>> Cc: rpd at afrinic.net
>>>>> Subject: Re: [rpd] Writing tools
>>>>> Message-ID: <09EB63D0-2FBC-48F9-B752-43E842D85096 at afrinic.net>
>>>>> Content-Type: text/plain; charset="us-ascii"
>>>>>
>>>>> An HTML attachment was scrubbed...
>>>>> URL: <
>>>>> https://lists.afrinic.net/pipermail/rpd/attachments/20260720/33c3ac9e/attachment-0001.html
>>>>> >
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> Message: 2
>>>>> Date: Mon, 20 Jul 2026 20:34:20 +0000
>>>>> From: Kone <bakenon.kone at sancfis.net>
>>>>> To: Seun Ojedeji <seun.ojedeji at gmail.com>
>>>>> Cc: rpd <rpd at afrinic.net>
>>>>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical
>>>>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02)
>>>>> Message-ID:
>>>>> <CADHquJpYPT91G8hHPsnXDJKp=
>>>>> 3cyspC-xR5t8iHs0EN4tTMhwQ at mail.gmail.com>
>>>>> Content-Type: text/plain; charset="utf-8"
>>>>>
>>>>> Hello Seun,
>>>>> You may have misread my earlier mail. I clearly stated that LACNIC,
>>>>> RIPE
>>>>> NCC, and ARIN do not require policy to enforce hierarchical AS?SET
>>>>> naming.
>>>>>
>>>>> To help close the ongoing discussions, I believe addressing the
>>>>> questions I
>>>>> raised would bring clarity:
>>>>> * LACNIC enforces hierarchical AS?SET naming operationally, as part of
>>>>> their IRR design from inception.
>>>>> * RIPE NCC handles IRR changes through their Numbered Work Items (NWI)
>>>>> process, not through policy.
>>>>> * ARIN uses the ACSP (Consultation and Suggestion Process) for IRR
>>>>> operational matters, again without policy.
>>>>>
>>>>>
>>>>> These examples show that other RIRs (except APNIC) treat AS?SET naming
>>>>> as
>>>>> an operational IRR matter, not a policy obligation.
>>>>>
>>>>> This is why I asked whether AFRINIC could address this operationally
>>>>> rather
>>>>> than through policy, and why Last Call discussions would benefit from
>>>>> clear
>>>>> answers to these points.
>>>>>
>>>>> Thanks.
>>>>> ---
>>>>> Kone
>>>>>
>>>>>
>>>>>
>>>>> Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji <seun.ojedeji at gmail.com> a
>>>>> ?crit :
>>>>>
>>>>> > Hello Bakenon,
>>>>> >
>>>>> > Do refer to the proposal as it references URL to other RIR's
>>>>> policies for
>>>>> > thiis:
>>>>> >
>>>>> > https://www.afrinic.net/afpub-2026-asn-001-draft02.html
>>>>> >
>>>>> > Regards
>>>>> >
>>>>> > ----
>>>>> > Sent from my mobile
>>>>> > kindly excuse typos
>>>>> >
>>>>> > On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, <bakenon.kone at sancfis.net
>>>>> >
>>>>> > wrote:
>>>>> >
>>>>> >> Dear PDWG,
>>>>> >>
>>>>> >> I have been following the discussions on the hierarchical AS?SET
>>>>> naming
>>>>> >> scheme and would like clarification on a few points:
>>>>> >>
>>>>> >> 1. Could this matter be addressed operationally, as is done in ARIN,
>>>>> >> LACNIC, and RIPE NCC, without requiring policy changes?
>>>>> >>
>>>>> >> 2. If yes, why are we taking the policy route? Is it because AFRINIC
>>>>> >> currently lacks a defined process for handling operational issues
>>>>> that
>>>>> >> affect IRR services?
>>>>> >>
>>>>> >> 3. Given that the hierarchical naming scheme is already supported
>>>>> and
>>>>> >> currently exists within the IRR, this proposal represents an
>>>>> enforcement
>>>>> >> change rather than the introduction of a new technical standard.
>>>>> Why is a
>>>>> >> formal policy required to change an operational enforcement
>>>>> setting, rather
>>>>> >> than a community-vetted technical implementation plan?"
>>>>> >>
>>>>> >> Thank you.
>>>>> >> ---
>>>>> >> Kone
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal <hytham at tra.gov.eg>
>>>>> a
>>>>> >> ?crit :
>>>>> >>
>>>>> >>> Dear PDWG,
>>>>> >>>
>>>>> >>>
>>>>> >>> The Policy Development Working Group (PDWG) Chairs have initiated
>>>>> a Last
>>>>> >>> Call for this proposal, following rough consensus at the
>>>>> AFRINIC-37 Public
>>>>> >>> Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June
>>>>> 2026.
>>>>> >>>
>>>>> >>> * Proposal Name: Hierarchical Names for New AS-SETs
>>>>> >>>
>>>>> >>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02
>>>>> >>>
>>>>> >>> * Proposal URL:
>>>>> >>> https://www.afrinic.net/afpub-2026-asn-001-draft02.html
>>>>> >>>
>>>>> >>> Last Call closes on: July 31, 2026, at 23:59 UTC.
>>>>> >>>
>>>>> >>>
>>>>> >>> Please note the staff observation regarding implementation
>>>>> constraints:
>>>>> >>> due to the current prioritization of the MyAFRINIC v2 deployment,
>>>>> physical
>>>>> >>> database implementation of this policy will be scheduled once the
>>>>> MyAFRINIC
>>>>> >>> v2 deployment is concluded.
>>>>> >>>
>>>>> >>>
>>>>> >>> As always, we kindly request that all participants adhere to the
>>>>> AFRINIC
>>>>> >>> Code of Conduct<https://www.afrinic.net/code> to maintain a
>>>>> respectful
>>>>> >>> and professional environment on the mailing list.
>>>>> >>>
>>>>> >>>
>>>>> >>> Kind regards,
>>>>> >>>
>>>>> >>>
>>>>> >>> Haitham el Nakhal
>>>>> >>>
>>>>> >>> AFRINIC PDWG Co-Chair
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>> _______________________________________________
>>>>> >>> RPD mailing list
>>>>> >>> RPD at afrinic.net
>>>>> >>> https://lists.afrinic.net/mailman/listinfo/rpd
>>>>> >>>
>>>>> >> _______________________________________________
>>>>> >> RPD mailing list
>>>>> >> RPD at afrinic.net
>>>>> >> https://lists.afrinic.net/mailman/listinfo/rpd
>>>>> >>
>>>>> >
>>>>> -------------- next part --------------
>>>>> An HTML attachment was scrubbed...
>>>>> URL: <
>>>>> https://lists.afrinic.net/pipermail/rpd/attachments/20260720/4563e1d5/attachment-0001.html
>>>>> >
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> Message: 3
>>>>> Date: Mon, 20 Jul 2026 23:10:04 +0200
>>>>> From: "jordi.palet at consulintel.es" <jordi.palet at consulintel.es>
>>>>> To: rpd <rpd at afrinic.net>
>>>>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical
>>>>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02)
>>>>> Message-ID: <F22A09CF-A827-4D7F-B077-E0B9C774AF00 at consulintel.es>
>>>>> Content-Type: text/plain; charset="utf-8"
>>>>>
>>>>> Hi Kone,
>>>>>
>>>>> And what is the relevance of that?
>>>>>
>>>>> If you have a good understanding about all the RIRs, you will know
>>>>> that each RIR has their own ways to do things. In many senses they act very
>>>>> similarly and in general we end up with very similarly policies, but not
>>>>> always. Some RIRs have decided that some aspects are operational and don?t
>>>>> need a policy proposal.
>>>>>
>>>>> However, despite that, the community is on top of the RIR, and the
>>>>> community sometimes, may decide that they prefer a policy if the RIR hasn?t
>>>>> been proactive in advance in any specific topic, or even if the RIR was
>>>>> proactive, the community may prefer to speed up things, or to show the way
>>>>> the community prefers.
>>>>>
>>>>> For example, if AFRINIC has any specific operational aspect already in
>>>>> place, and the community prefer to manage that in a different way, the
>>>>> community may opt either for suggesting the RIR to modify that operational
>>>>> aspect or to do actually enforce it by means of a policy proposal.
>>>>>
>>>>> I think is important to know, by personal experience, how the other 4
>>>>> RIRs work before stating something that is not correct, because if you
>>>>> don?t work in all the RIRs for many years, it will be difficult for you to
>>>>> know the past and I?m sure IA will not be able to be precise as well.
>>>>>
>>>>> Regards,
>>>>> Jordi
>>>>>
>>>>> @jordipalet
>>>>>
>>>>> > El 20 jul 2026, a las 22:34, Kone <bakenon.kone at sancfis.net>
>>>>> escribi?:
>>>>> >
>>>>> > Hello Seun,
>>>>> > You may have misread my earlier mail. I clearly stated that LACNIC,
>>>>> RIPE NCC, and ARIN do not require policy to enforce hierarchical AS?SET
>>>>> naming.
>>>>> >
>>>>> > To help close the ongoing discussions, I believe addressing the
>>>>> questions I raised would bring clarity:
>>>>> > * LACNIC enforces hierarchical AS?SET naming operationally, as part
>>>>> of their IRR design from inception.
>>>>> > * RIPE NCC handles IRR changes through their Numbered Work Items
>>>>> (NWI) process, not through policy.
>>>>> > * ARIN uses the ACSP (Consultation and Suggestion Process) for IRR
>>>>> operational matters, again without policy.
>>>>> >
>>>>> >
>>>>> > These examples show that other RIRs (except APNIC) treat AS?SET
>>>>> naming as an operational IRR matter, not a policy obligation.
>>>>> >
>>>>> > This is why I asked whether AFRINIC could address this operationally
>>>>> rather than through policy, and why Last Call discussions would benefit
>>>>> from clear answers to these points.
>>>>> >
>>>>> > Thanks.
>>>>> > ---
>>>>> > Kone
>>>>> >
>>>>> >
>>>>> >
>>>>> > Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji <seun.ojedeji at gmail.com
>>>>> <mailto:seun.ojedeji at gmail.com>> a ?crit :
>>>>> >> Hello Bakenon,
>>>>> >>
>>>>> >> Do refer to the proposal as it references URL to other RIR's
>>>>> policies for thiis:
>>>>> >>
>>>>> >> https://www.afrinic.net/afpub-2026-asn-001-draft02.html
>>>>> >>
>>>>> >> Regards
>>>>> >>
>>>>> >> ----
>>>>> >> Sent from my mobile
>>>>> >> kindly excuse typos
>>>>> >>
>>>>> >> On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, <
>>>>> bakenon.kone at sancfis.net <mailto:bakenon.kone at sancfis.net>> wrote:
>>>>> >>> Dear PDWG,
>>>>> >>>
>>>>> >>> I have been following the discussions on the hierarchical AS?SET
>>>>> naming scheme and would like clarification on a few points:
>>>>> >>>
>>>>> >>> 1. Could this matter be addressed operationally, as is done in
>>>>> ARIN, LACNIC, and RIPE NCC, without requiring policy changes?
>>>>> >>>
>>>>> >>> 2. If yes, why are we taking the policy route? Is it because
>>>>> AFRINIC currently lacks a defined process for handling operational issues
>>>>> that affect IRR services?
>>>>> >>>
>>>>> >>> 3. Given that the hierarchical naming scheme is already supported
>>>>> and currently exists within the IRR, this proposal represents an
>>>>> enforcement change rather than the introduction of a new technical
>>>>> standard. Why is a formal policy required to change an operational
>>>>> enforcement setting, rather than a community-vetted technical
>>>>> implementation plan?"
>>>>> >>>
>>>>> >>> Thank you.
>>>>> >>> ---
>>>>> >>> Kone
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal <hytham at tra.gov.eg
>>>>> <mailto:hytham at tra.gov.eg>> a ?crit :
>>>>> >>>> Dear PDWG,
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> The Policy Development Working Group (PDWG) Chairs have initiated
>>>>> a Last Call for this proposal, following rough consensus at the AFRINIC-37
>>>>> Public Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June
>>>>> 2026.
>>>>> >>>>
>>>>> >>>> * Proposal Name: Hierarchical Names for New AS-SETs
>>>>> >>>>
>>>>> >>>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02
>>>>> >>>>
>>>>> >>>> * Proposal URL:
>>>>> https://www.afrinic.net/afpub-2026-asn-001-draft02.html
>>>>> >>>>
>>>>> >>>> Last Call closes on: July 31, 2026, at 23:59 UTC.
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> Please note the staff observation regarding implementation
>>>>> constraints: due to the current prioritization of the MyAFRINIC v2
>>>>> deployment, physical database implementation of this policy will be
>>>>> scheduled once the MyAFRINIC v2 deployment is concluded.
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> As always, we kindly request that all participants adhere to the
>>>>> AFRINIC Code of Conduct<https://www.afrinic.net/code> to maintain a
>>>>> respectful and professional environment on the mailing list.
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> Kind regards,
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> Haitham el Nakhal
>>>>> >>>>
>>>>> >>>> AFRINIC PDWG Co-Chair
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> _______________________________________________
>>>>> >>>> RPD mailing list
>>>>> >>>> RPD at afrinic.net <mailto:RPD at afrinic.net>
>>>>> >>>> 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
>>>>> > _______________________________________________
>>>>> > RPD mailing list
>>>>> > RPD at afrinic.net
>>>>> > https://lists.afrinic.net/mailman/listinfo/rpd
>>>>>
>>>>>
>>>>>
>>>>> **********************************************
>>>>> IPv4 is over
>>>>> Are you ready for the new Internet ?
>>>>> 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.
>>>>>
>>>>> -------------- next part --------------
>>>>> An HTML attachment was scrubbed...
>>>>> URL: <
>>>>> https://lists.afrinic.net/pipermail/rpd/attachments/20260720/b6777fa7/attachment.html
>>>>> >
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> Subject: Digest Footer
>>>>>
>>>>> _______________________________________________
>>>>> RPD mailing list
>>>>> RPD at afrinic.net
>>>>> https://lists.afrinic.net/mailman/listinfo/rpd
>>>>>
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> End of RPD Digest, Vol 222, Issue 110
>>>>> *************************************
>>>>>
>>>>> -------------- next part --------------
>>>>> An HTML attachment was scrubbed...
>>>>> URL: <
>>>>> https://lists.afrinic.net/pipermail/rpd/attachments/20260721/e492c668/attachment.html
>>>>> >
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> Subject: Digest Footer
>>>>>
>>>>> _______________________________________________
>>>>> RPD mailing list
>>>>> RPD at afrinic.net
>>>>> https://lists.afrinic.net/mailman/listinfo/rpd
>>>>>
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> End of RPD Digest, Vol 222, Issue 111
>>>>> *************************************
>>>>>
>>>> _______________________________________________
>>>> RPD mailing list
>>>> RPD at afrinic.net
>>>> https://lists.afrinic.net/mailman/listinfo/rpd
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20260721/e1ecf293/attachment-0001.html>
More information about the RPD
mailing list