[rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02)

[Jaco Kroon]

Hi Tshepo,

On 2026/07/29 15:48, Tshepo Masuku wrote:
> Dear James,
>
> Thank you for considering the concern carefully and explaining your 
> decision openly. I genuinely appreciate that you engaged with the 
> substance rather than simply dismissing it.
>
> I understand the case for incremental improvement and agree that no 
> policy can anticipate every future scenario. My concern, however, is 
> not that the draft must be perfect. It is that the exception clause 
> sits at the boundary of what AFRINIC will be required, or permitted, 
> to enforce.
>
> The absence of data cuts both ways. If we do not know how frequently 
> restoration will be needed, that uncertainty does not necessarily 
> justify leaving the criteria undefined. It may instead support 
> beginning with a narrow, objective restoration rule and expanding it 
> later if operational evidence shows that broader exceptions are necessary.
>
> I also do not think restarting Last Call is, by itself, a sufficient 
> reason to retain ambiguous wording. Once adopted, the policy will be 
> binding until another proposal completes the PDP. During that period, 
> AFRINIC will have to interpret “where necessary” without agreed 
> criteria. That is not quite the same as a temporary implementation 
> experiment.
I don't think it's ambiguous, it may be vague, but not ambiguous.  I 
will concede it leaves the jay or nay decision to operational 
discretion, and one person may decide yes, another may decide no, but 
IMHO *any* reason to restore an object would be operational of nature, 
something like "Hi, we've deleted object X, but it has come to light 
it's still being referenced by {insert another object|operational peer 
name|AS} and we're having trouble getting the relevant party to update, 
could you please restore".

I don't foresee any other case of restoration case that I would consider 
to be valid.  But precisely that "cannot foresee" is why I believe it's 
best to leave it to Afrinic staff to determine the validity of any 
motivation for *restoration* of an object.  At that point it becomes a 
debate.  And I've not yet encountered Afrinic staff to be unreasonable 
and they'll most likely err on the side of restoring (exactly as it was, 
without modification) rather than not.
>
> A narrowly drafted restoration safeguard would not be an attempt to 
> build the whole castle at once. It would simply make the first brick 
> clear enough that operators and staff know what it permits. The common 
> layer should be minimal, but what it contains should also be 
> deterministic and auditable.

Without knowing what will or may be required in the future this is 
exceptionally difficult, as per James, to narrow down.  I agree with 
James that it's best to intentionally leave it vague.


Bottom line is:  no new "flat" objects, and restore only on motivation 
to Afrinic staff (which will likely be in the lines above).

At some point we would likely want to get a list of all "flat" objects 
and see if they're still *referenced*, confirming actual *use* is harder 
since we have no way of knowing whether any implementation references 
that object.  At least, none I'm aware of.  If there is a way it would 
likely involve Afrinic having to check some query log and if the object 
name hasn't been queried in some time.  But that's not to say there 
aren't gateway systems (such as rr.ntt.net - default queried server by 
at least bgpq4) running some form of irrd, that doesn't pull the entire 
database and then references "offline", so without looking into exactly 
how that infrastructure works, there's no way to identify completely 
unused objects I don't think.


I trust this answers your concern.


Kind regards,
Jaco


>
> I respect your decision not to revise the draft, and I appreciate your 
> constructive approach. However, because the difference between a 
> guaranteed restoration right and discretionary case-by-case approval 
> remains unresolved, I cannot support the proposal as currently written 
> and therefore maintain my objection.
>
> kind regards,
> Tshepo
>
>
> ------------------------------------------------------------------------
> *From:* James Bensley <james at inter.link>
> *Sent:* Wednesday, 29 July 2026 14:26:30
> *To:* Tshepo Masuku <TshepoMasuku26 at hotmail.com>; rpd at afrinic.net 
> <rpd at afrinic.net>; pdwg-chairs at afrinic.net <pdwg-chairs at afrinic.net>
> *Subject:* Re: [Last Call] Draft Policy Proposal - Hierarchical Names 
> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02)
> Dear Tshepo,
>
> After careful consideration I have decided not to revise the draft. 
> There are a couple of reasons for this:
>
>  *
>     I think this is becoming too prescriptive. If we try to define a
>     time period for restoration for example, for some people it will
>     be too long, for others too short. We have no data to make an
>     informed decision here. Similarly the point about having a public
>     log. That requires us to define what that looks like and how it
>     works. We have no idea how often this process would be enacted so
>     we can't described what that needs to look like. We have no data.
>     I think trying to make a perfect policy that covers all cases is
>     the wrong approach. I think we should be aiming to get "something"
>     implemented, let it run for a while, gather feedback, and then if
>     it needs adjusting, we can raise another policy change proposal.
>     Nothing is set in stone here. There's no need to get his perfect
>     first time, we can iterate over time.
>
>  *
>     Any changes to the draft will restart the Last Call and
>     potentially also require the staff to re-review the draft. The
>     changes you proposed, whilst valid, are optimising for a corner
>     case (how often to people delete their AS-SET by mistake? I would
>     say, rarely). Why delay getting "something" deployed, which we can
>     continue to iterate on, just to optimise for a corner case
>     (restores aren't blocked by this policy)?
>
>
> For these reasons I have decided not to modify the draft.
>
> With kind regards,
> James Bensley (he/him)
>
> ------------------------------------------------------------------------
> *From:* Tshepo Masuku <TshepoMasuku26 at hotmail.com>
> *Sent:* 28 July 2026 15:28
> *To:* James Bensley <james at inter.link>; rpd at afrinic.net 
> <rpd at afrinic.net>; pdwg-chairs at afrinic.net <pdwg-chairs at afrinic.net>
> *Subject:* Re: [Last Call] Draft Policy Proposal - Hierarchical Names 
> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02)
>
> Dear James,
>
> Thank you for engaging with the concern constructively. Your proposed 
> wording is a meaningful improvement because it begins replacing an 
> open-ended exception with objective conditions.
>
> I think a few points still need tightening before the rule is ready:
>
>   * Restoration should return the object to its last valid archived
>     state, not merely reuse the same key. Otherwise, an old flat name
>     could be restored with entirely different contents and become a
>     new object in substance.
>   * The text should define whether the restoration right is permanent
>     or subject to a recovery period.
>   * “Another maintainer within the same organisation” and an
>     organisation “responsible for the assets” require objective
>     evidence, such as registry history or documented legal succession.
>     Those terms should not be left entirely to staff interpretation.
>   * The residual case-by-case provision should expressly prohibit
>     creating a flat name that did not exist before implementation.
>   * Every exceptional decision should record the evidence relied upon
>     and provide a review or appeal path, not merely an audit entry.
>
> I would also suggest wording along these lines:
>
>     A restored object shall initially reflect its last valid archived
>     state, except that maintainer and contact attributes may be
>     updated where necessary to establish control by the verified
>     original holder or lawful successor.
>
> Because this changes the normative enforcement boundary, I believe v3 
> should be published with an updated Impact Assessment and receive 
> proper review. It should not be treated as a minor editorial 
> correction during the final days of Last Call.
>
> I remain opposed to DRAFT02 as written, but I appreciate your 
> willingness to address the defect directly. This is the kind of 
> concrete engagement that adds value to the process.
>
> Regards,
> Tshepo
>
>
>
>
> ------------------------------------------------------------------------
> *From:* James Bensley <james at inter.link>
> *Sent:* Tuesday, 28 July 2026 13:39:50
> *To:* Tshepo Masuku <TshepoMasuku26 at hotmail.com>; rpd at afrinic.net 
> <rpd at afrinic.net>; pdwg-chairs at afrinic.net <pdwg-chairs at afrinic.net>
> *Subject:* Re: [Last Call] Draft Policy Proposal - Hierarchical Names 
> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02)
> Dear Tshepo,
>
> Thank you for providing your feedback. I am in agreement with your 
> statement.
>
> I am the original author of this draft change, and I wrote in my last 
> update (version 2):
>
> "Exceptions MUST be allowed on a case-by-case basis. For example, a 
> non-hierarchically named AS-SET was deleted by mistake, so it should 
> be possible to restore this AS-SET without having to rename it."
>
> The staff assessment was to go with the following "7.8.7 Exceptions 
> for the creation of hierarchical names may be granted where necessary. 
> AFRINIC shall document the reason for any exception.".
>
> The staff asked me to review their assessment and I initially agreed, 
> because it was loser than my definition. There may be other scenarios 
> where restoration is required which I/we haven't thought of, so why 
> limit it to accidental deletion only. Opening it up to allow any case 
> to be reviewed has benefits. But as you say, it could also go the 
> other way, it could simply mean that every case is rejected.
>
> I am going to submit another version (v3) of the document, only 
> replacing the text I quoted above, with the text below, to fix the 
> problem you raised of the text having gone from being too strict 
> before to now being too lose (I will try to propose something in the 
> middle which guarantees delete/restoration is protected, anything else 
> needs a review).
>
> I am proposing the following text, what do you think?
>
> ------
> A non-hierarchical AS-SET existing before implementation of this 
> policy change, which has since been deleted, must be restorable when 
> the following conditions are met:
>
> - The same object key is requested for restoration (no AS-SET name 
> changes allowed)
> - No object with a conflicting name has been created between the date 
> of deletion and the date the restore is made
> - The restore request is coming from either a maintainer that was 
> present on the deleted object, or another maintainer within the same 
> organisation (in the case the maintainer was also deleted), or a 
> maintainer in an organisation responsible for the assets of the 
> original organisation (in the case of a merger or acquisition).
> - The restoration is recorded in an auditable log.
>
> Any other request for restoring a deleted AS-SET created before the 
> implementation date of this policy change will need to be reviewed by 
> AFRINIC on a case by case basis.
> -------
>
> With kind regards,
> James Bensley (he/him)
> ------------------------------------------------------------------------
> *From:* Tshepo Masuku <TshepoMasuku26 at hotmail.com>
> *Sent:* 27 July 2026 15:29
> *To:* hvisage at hevis.co.za <hvisage at hevis.co.za>; Nonjabulo Sphilile 
> <nonjabulosphilile at gmail.com>; Phetulo Dhlamini 
> <phetulodhlamini at gmail.com>; Taye Medoye <daniel.medoye at gmail.com>; 
> Thulisile Mazomba <thulisile.mazomba at gmail.com>; rpd at afrinic.net 
> <rpd at afrinic.net>
> *Subject:* Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical 
> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02)
> *⚠️ Caution:* This email originated from outside of your organization. 
> Do not click on links or open attachments unless you recognize the 
> sender and know the content is safe.
> Dear Hendrik and colleagues,
>
> Thank you for consolidating the discussion. I will not repeat the 
> earlier lifecycle, resolver, delegation, or membership arguments.
>
> There is, however, a separate defect in the actual text being considered.
>
> The proposal says that exceptions MUST be allowed on a case-by-case 
> basis and gives restoration of an accidentally deleted flat AS-SET as 
> the example. The staff-recommended wording instead says exceptions may 
> be granted “where necessary.” These are materially different rules.
>
> Under the first version, an eligible operator has a right to 
> restoration. Under the second, restoration depends on AFRINIC’s 
> discretion. The wording also changes a narrow restoration example into 
> an undefined general exception.
>
> That produces a concrete operational difference. If a grandfathered 
> flat AS-SET is accidentally deleted after implementation, one version 
> requires a restoration path while the other allows AFRINIC to refuse 
> it. Operators and peers referencing that object cannot know which 
> outcome the adopted policy guarantees.
>
> This is not an adjacent lifecycle problem. It is the enforcement 
> boundary of the present proposal.
>
> The text should therefore be amended to provide one deterministic 
> rule. For example:
>
> > A non-hierarchical AS-SET existing before commencement may be 
> restored only where the same object key is requested within a defined 
> recovery period, the request is authenticated by the maintainer 
> authorised immediately before deletion, no conflicting object has 
> intervened, and the restoration is recorded in an auditable log. No 
> other exception may authorise creation of a new non-hierarchical AS-SET.
>
> That would preserve accidental-deletion recovery without leaving the 
> supposedly closed namespace subject to undefined staff judgment.
>
> Documenting the reason after an exception is granted is not the same 
> as defining the conditions under which the exception is valid. 
> Implementation guidance also cannot resolve a conflict between “MUST” 
> and “may” after ratification.
>
> Before Last Call closes, the authors and co-chairs should identify 
> which wording is actually under consideration and resolve the 
> difference in normative force.
>
> Until then, I remain opposed to the proposal as written.
>
> Regards,
> Tshepo
> ------------------------------------------------------------------------
> *From:* hvisage at hevis.co.za <hvisage at hevis.co.za>
> *Sent:* Monday, 27 July 2026 15:11:31
> *To:* Tshepo Masuku <TshepoMasuku26 at hotmail.com>; Nonjabulo Sphilile 
> <nonjabulosphilile at gmail.com>; Phetulo Dhlamini 
> <phetulodhlamini at gmail.com>; Taye Medoye <daniel.medoye at gmail.com>; 
> Thulisile Mazomba <thulisile.mazomba at gmail.com>; rpd at afrinic.net 
> <rpd at afrinic.net>
> *Subject:* [Last Call] Draft Policy Proposal - Hierarchical Names for 
> New AS-SETs (AFPUB-2026-ASN-001-DRAFT02)
>
> Good day Tshepo, Nonjabulo, Phetulo, Taye, Thulisile, colleagues,
>
> Apologies to the human readers for this voluminous post, but I’d
> rather address as much in one email than to flood the mailing list
> With even more messages as I’d rather do a digest type response for
> all the similar objections at once.
>
> For nearly two weeks we have been asking for technical substance;
> today, in the week Last Call closes, technical reasons have at last
> been presented. Before I respond to them, let me add a seventh
> question to the six of 23 July (015344):
>
> Question 7: could you please provide the technical issues,
> difficulties, and real-world examples where implementation of this
> draft policy - as three RIRs have already implemented it, and the
> fourth is formally proposing - would negatively affect your current
> or future operations? We would like to understand those too.
> Operational evidence of that kind would genuinely add to the body
> of knowledge on this proposal.
>
> Note: numbers like (015344) are message IDs in the RPD archive -
> prepend https://lists.afrinic.net/pipermail/rpd/2026/ 
> <https://lists.afrinic.net/pipermail/rpd/2026/>and append
> .html to read any of them.
>
> So let's get to the objections we have been waiting two weeks for:
>
>  1. object lifecycle under changes of ASN control (015387,
>     escalated in 015391 and 015400) - answered by Jaco in (015388)
>     and (015394)
>
> 1b) its delegated-maintainer extension (015398, pressed again in
> 015400) - Jaco deferred to the RFC in (015399); the deferral is
> completed in section 1 below
> 2) recursive expansion of members: references (015389) - answered
> in (015390)
> 3) grandfathered flat objects (015392) - answered in (015395)
> 4) multi-source name resolution (015393) - answered in (015396,
> 015397)
> 5) anchor-ASN eligibility and authentication (015401) - addressed
> in section 5 below
> 6) implementation rollout process (015402) - addressed in section 6
> below; its delegation and 7.8.7 points are answered in section 1
> (the delegation question is 015398/015400 returning), and its
> benefit-scope point in the common ground just below
>
> I refer to and endorse Jaco's answers rather than repeat them. It
> was asked earlier in this Last Call that objections be addressed as
> grouped issues rather than piecemeal, and in that spirit I have
> collated the responses in a single email, adding what has not yet
> been shared: a precise statement of the authorisation model, the
> published data, and the cross-registry record.
>
> First, the common ground, because it is substantial. In today's own
> words:
>
>   * hierarchical naming "can strengthen creation authorisation" (015393)
>   * the proposal "secures the first object name" (015389)
>   * the concerns are "not questions about whether AS-SET membership
>     is correct" (015387)
>   * ASN-anchored naming "can reduce future flat-name collisions"
>     (015402)
>
> None of today's messages disputes what the proposal does. Each of
> today's objections asks it to also solve an adjacent problem -
>
>   * lifecycle
>   * delegation semantics
>   * expansion semantics
>   * legacy objects
>   * mirror copies
>   * anchor eligibility
>   * and every one of those problems exists today, everywhere, with or
>
> without this policy. That is not the discovery of a defect. It is
> the discovery that the proposal has a scope, which it states and
> which was put on this record weeks ago (015119, 015120, 015123; and
> the draft's own sections 7.8.3-7.8.6).
>
>  1. The authorisation model, changes of ASN control, and delegation
>     (015387, 015391, 015398, 015400, 015402)
>
> Jaco deferred to the RFC on the depth mechanics (015399). Rightly
> so - the RFC, followed to the top of the chain, completes his
> answer. (015398) states the rule correctly: a first-level object,
> AS12345:AS-CUSTOMERS, is created under the authorisation of the
> aut-num AS12345 as it stands at that moment - its maintainer chain,
> which follows the current registered holder. A deeper object,
> AS12345:AS-CUSTOMERS:AS-EU, is created under the authorisation of
> the maintainer of its immediate parent. Now ask where that parent
> came from: its own creation was authorised by the level above it,
> and so on, terminating at the aut-num itself. Every object in the
> tree exists because the level above authorised its creation.
> Delegation, where it exists, exists because the chain authorised
> it. And who controls each level is answerable, level by level, from
> the database as it stands - which is what verifiable control looks
> like in RPSL.
>
> The emphatic difference at the current state is that a flat name
> offers just a maintainer but no chain: no root, and no way to ask
> whether the name was ever anyone's to create - beyond that it must
> not already exist in THIS one database.
>
> (015400) concludes that because deeper control can be delegated,
> the "control model remains unspecified". The opposite is the case:
> the control model is fully specified - in the very RFC that
> (015398) cited, which is why deferring to it was the right answer.
> That deeper authority is delegated, and that delegated authority
> does not automatically follow the ASN, is not a gap in the model;
> it is the model, working as designed for twenty-seven years, for
> every hierarchical object family, at every RPSL-based registry. A
> policy does not "leave AFRINIC to interpret" what the RFC and the
> production database already define - any more than this proposal
> needs to restate what mnt-by means. What deterministically follows
> the ASN is the root of every chain: authority over creation and
> recreation at the first level of the namespace. That is precisely
>
>   * and only - what the proposal's attribution claim covers. The same
>
> depth question returns in (015402); the answer above stands.
>
> These semantics are not invented by this proposal. They are RFC
> 2622 (1999), operated by RPSL-based registries - AFRINIC's included
>
>   * for twenty-seven years. The proposal does not modify them; it
>
> gates which names may come into existence, nothing else. The two
> outcomes (015398) poses are therefore both answered by the
> semantics already in production: descendants do not move
> automatically, so no delegated maintainer is overridden - exactly
> as for every delegated object today. And the new holder gains
> precisely what the name anchors: authority over creation and
> recreation at the first level of its namespace. What the new holder
> does not get - control over objects a previous holder's delegates
> still maintain - is what nobody has today under flat names, for any
> object, ever. A stale delegated descendant is today's universal
> condition; the proposal neither creates nor worsens it, and no
> registry in those twenty-seven years has defined the demanded
> delegation-and-revocation regime for set objects in policy.
>
> How ASN control actually changes in this region is likewise not a
> matter for speculation. AFRINIC publishes it:
>
> https://ftp.afrinic.net/pub/stats/afrinic/transfers/transfers_latest.json 
> <https://ftp.afrinic.net/pub/stats/afrinic/transfers/transfers_latest.json>
>
> A full read of that file today: 75 ASN-carrying transfer events (91
> ASNs) from 2018 through 2026 - about nine such events a year - and
> every single one is a merger/acquisition succession, in which the
> organisation and its maintainer control pass together, so parent
> ASN and child objects move as one unit. That is the published
> record behind Jaco's description in (015394), with the frequency
> question answered exactly: none open-market, all successions that
> preserve the attribution chain by construction. Anyone can verify
> this from the file. So the concern of (015391) has been addressed -
> with our registry's own data.
>
> The cross-registry record answers the rest. I checked this week,
> across the policy, procedural and database-documentation layers of
> the other four RIRs. RIPE has required hierarchical names for new
> as-sets since December 2022 and operates full ASN transfers,
> including inter-RIR; APNIC likewise since July 2023 (prop-151);
> LACNIC's IRR has been structurally hierarchical since it launched
> in 2020; at ARIN hierarchical naming is available today and a
> mandate for new objects is formally proposed (ARIN-prop-342,
> pending) - the same direction. All four are silent on child as-set
> lifecycle at every layer. Across the deployed implementations that
> is roughly three and a half years of exactly the coexistence
> (015387) warns about - hierarchical mandates running over live ASN
> transfer markets - and I could not find one documented incident of
> the failure mode described. In every deployed implementation,
> lifecycle lives where it belongs: in standard RPSL authorisation
> and registry operations, not in naming-policy text.
>
> On 7.8.7 (015391, 015402): today the namespace has no rule at all -
> every creation, by anyone, of any name, is the exception. A closed
> default with documented-reason exceptions cannot be less
> deterministic than no default whatsoever. And credit where due:
> (015402) makes one point that verifies - the staff assessment's
> prose cites "7.8.6" for the restoration-of-deleted-objects
> exception, where 7.8.6 concerns editing and the exception clause is
> in fact 7.8.7. That is a cross-reference slip in the assessment's
> commentary, worth an erratum, and it changes nothing in the policy
> text: the clauses say what they say, and staff's own recorded
> caution about recall loopholes shows the right mechanism was
> analysed. As for the demanded exception criteria: 7.8.7 requires
> every exception to be documented with its reason - a discipline
> stricter than today, where no creation needs any reason at all.
>
>  2. Recursive expansion of members: references (015389)
>
> Correct as far as it goes - and it concedes the top level is
> secured. What members: may contain is a content question, expressly
> outside this proposal's scope, and outside the naming policies of
> every registry that already runs this rule: none coupled naming to
> expansion semantics, because that coupling is a different and
> larger policy. Jaco has already named the constructive path
> (015390): a members-qualification rule would be a coherent separate
> proposal, and wording was invited. Meanwhile every new hierarchical
> set is one fewer ambiguous reference for the next expansion to fear
>
>   * the gap this concern describes narrows with adoption and stays
>
> open without it.
>
>  3. Grandfathered flat objects and the transition window (015392)
>
> The capability described - register flat names now, populate them
> later - exists today, permanently, with or without this proposal.
> Anyone may do it this afternoon. The proposal is the only mechanism
> before this Working Group that ever closes that window; declining
> it preserves the window forever. If gaming of the implementation
> gap is the genuine worry, the remedy is a short implementation
> period - a staff scheduling matter - not an indefinitely open
> namespace. And, respectfully: (015392) describes with precision the
> squatting behaviour whose future possibility this policy exists to
> end. An objection that demonstrates the attack is an argument for
> closing the door.
>
>  4. Multi-source resolution (015393)
>
> Jaco's answer (015396, 015397) is complete: an ASN is delegated by
> exactly one registry, so a hierarchical name carries its
> authoritative source in its own first element. The question "which
> source is authoritative for this set?" has a deterministic answer
> precisely and only when the name is hierarchical; under a flat name
> that answer does not exist anywhere. The working-group draft cited
> in (015393) pursues the same determinism through source-qualified
> references - the two mechanisms are complements, not conflicts, and
> that draft's problem statement describes the flat-name condition
> this proposal removes for new AFRINIC sets. What a third-party
> mirror carries is today's condition for every object in every IRR
> database and is governed by no naming policy at any registry.
>
>  5. Anchor-ASN eligibility and authentication (015401)
>
> Taye, this is the kind of message Last Call is for: specific,
> technical, and naming the exact requirements it wants. Three
> responses.
>
> First, on substance: the properties you list - the leading ASN
> globally assigned, an authoritative aut-num present, creation
> authenticated against that object's maintainer, private-use and
> reserved ranges (RFC 6996) excluded, canonical ASPLAIN form (RFC
> 5396) - are, I would argue, what the Impact Assessment's own
> authorisation claim already entails. An anchor with no holder can
> authorise no one; a check that can pass in the absence of the
> aut-num it authenticates against would not be the check the
> assessment describes. So I read your list not as a new mechanism
> but as the strict, and correct, reading of the mechanism the
> proposal already claims.
>
> Second, on where it belongs: those are implementation semantics -
> the authentication mode of the database software and the eligible
> ASN ranges - and I would support AFRINIC staff recording exactly
> your list in the implementation guidance for this policy, alongside
> the failure behaviour per creation path. That is the normal home of
> such requirements at every registry, and section 7.8.7's
> documented-exception mechanism gives staff the instrument for any
> edge the guidance must handle. It is worth adding: even in the
> weakest imaginable configuration, an unattributable
> hierarchical-form name is no worse than today, where every name of
> any form requires no authorisation from anyone.
>
> Third, on form: yours is the closest any message in this Last Call
> has come to proposed text. If you formalise that list as wording -
> whether as implementation guidance or as a clarification for a
> future revision - I have no doubt this Working Group will engage it
> on its merits, exactly as was invited days ago (015390). It is the
> constructive instrument the process recognises.
>
>  6. Implementation rollout process (015402)
>
> Warning-only phases, test vectors, baselines, rollback plans and
> scheduled reviews are implementation artifacts. They are produced
> by registry staff during implementation - at every RIR - and they
> appear in no naming policy anywhere: RIPE shipped its hierarchical
> requirement through the database release process, with release
> notes and a release-candidate test environment, on the strength of
> a policy text that contains none of those artifacts. Nothing in
> this proposal forbids a staged, warning-first deployment; that is
> exactly the kind of detail the implementation phase exists to
> define, and 7.8.7's documented-exception mechanism gives staff the
> instrument for edge handling during it. Taken at face value,
> (015402)'s final section is an argument about deployment
> scheduling, which follows ratification - not a reason to withhold
> it.
>
> Stepping back, twice.
>
> Each of the demands in messages (015387), (015389), (015391),
> (015392), (015393), (015398), (015400) and (015402) carries the same
> condition: "before adoption" (015387, 015389, 015391), "before
> mandatory enforcement" (015393), "before this proceeds" (015398),
> "until ... addressed" (015392), "until that is clarified" (015400),
> "until ... clearly resolved" (015402).
> As Seun reminded the list (015386), this PDP has no conditional
> adoption: a proposal cannot pass Last Call subject to future
> homework. At day eleven of Last Call, "resolve and test before
> advancing" therefore spells "do not adopt". The process has exactly
> one instrument for a genuine, fixable concern: proposed text. Jaco
> invited it (015390).
>
> Let me emphasise the arithmetic: seven distinct technical concerns
> in a single day, after eleven days without one - and, section 5's 
> requirements
> list aside, still zero proposed amendments. Of the six questions of
> 23 July (015344), exactly one account engaged them point by point -
> Tshepo, in (015348) - and the record should credit those answers.
> In short:
>
>  1. Two-object case: tooling should bind to an explicitly selected
>     source or stop and report - the fail-closed behaviour supporters
>     had proposed; the live case itself stays unresolved either way,
>     the rule being prospective.
>  2. Squatting remedy: none - the victim is left to another
>     database's dispute or abuse process.
>  3. Is it an improvement? "Yes, narrowly."
>  4. Evidence bar: a four-part test - whose second criterion, that
>     the proposal "would have prevented" the incident, excludes by
>     construction every incident that already exists; a creation-time
>     rule is prospective by definition.
>  5. Impact Assessment: "I do not dispute the findings"; the
>     objection shifts to what the IA does not cover.
>  6. Capacity: individual, representing no organisation or resource
>     member.
>
> No other opposing account has answered any of the six. Today the
> bar has moved with nearly every message, and a seventh question now
> joins the list. My assessment, for the record:
> none of today's objections identifies a defect in what the proposal
> claims; and their cumulative effect, whatever the intent, has been
> to consume the finite attention of this Working Group - a cost
> long-standing participants have already described in their own
> words (015154, 015179).
>
> One further observation, offered for the record and without
> attributing it to any individual: this Last Call's objections began
> from the principle that the registry "may record... It may not
> rule" (015011). Today's objections ask the registry to pre-define
> delegation graphs, revocation processes, state machines, permanent
> reservations, transition audits and source-selection rules, in
> advance (015391, 015392, 015393, 015398, 015400, 015402). Those two
> standards pull in opposite directions, and the same seven-clause
> creation-time rule cannot be faulted under both at once. Which
> standard the Working Group actually holds is exactly what the
> Co-Chairs will weigh - against what the proposal actually claims: a
> creation-time naming rule, whose every stated boundary today's
> objection messages ask it to exceed.
>
> The community is entitled to expect Last Call to close on schedule
> and to be assessed on the record as it stands.
>
> Regards,
> Hendrik Visage (AS329532; also AS213481)
>
> [CompanySignature]
> Inter..link GmbH *|* Boxhagener Straße 80, 10245 Berlin, Germany *|* 
> Managing Directors: Marc Korthaus, Theo Voss *|* Commercial Register: 
> Amtsgericht Charlottenburg, HRB 138876 *|* VAT ID: DE281288887 *|* 
> Email: hello at inter.link <mailto:hello at inter.link> *|* Web: inter.link 
> <https://inter.link>
>
> _______________________________________________
> 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/20260729/4976ec14/attachment-0001.html>