Hello Haisheng,
I'm afraid your reply presents more questions than answers.
As I mentioned in my last email, regardless of whether a member applies for an
allocation that lands on a nibble boundary (e.g. a /28) or one that doesn't
(e.g. a /29), they still need to provide justification. The proposal that you
have submitted intends to introduce text that reads:
Where an account holder explicitly requests nibble-boundary alignment for a
subsequent allocation larger than the default doubling, it must provide a
long-term IPv6 address plan as part of the documentation justifying its new
requirements
Section 4.3 retains the existing text of 8.3.4 directly above that addition:
If an account holder needs more address space, it must provide documentation
justifying its new requirements. The allocation size will be based on the new
needs (the number of users, the extent of the infrastructure, the hierarchical
and geographical structuring of the account holder's operations, the
segmentation of infrastructure for security and the planned longevity of the
allocation).
And Section 8.0 defines the long-term IPv6 address plan you're now requiring as
documentation covering expected user/customer/site growth, extent of
infrastructure, hierarchical and geographical network structure, security
segmentation, and planned longevity - four of those five items match the
retained 8.3.4 wording almost verbatim.
If a member requests a subsequent allocation larger than doubling, they already
have to document exactly this. What does the long-term IPv6 address plan ask
for that the existing text doesn't already cover? As drafted, it reads as the
same documentation, restated under a new name, and required only of members who
ask for alignment - not of members who request the identical size increase
without it.
You have said:
the intended meaning of this statement is not that simply leaving other policy
sections unchanged should itself be considered an advantage
However, you have an advantage that says:
Preserves existing policy scope - The proposal does not amend Section 9
assignments, reduce the /32 minimum allocation size, or alter the default
one-bit doubling mechanism.
What you said in your reply, directly contradicts one of the stated
"advantages" of this proposal.
Something else that I've been able to identify, another disadvantage reads:
Nibble-boundary alignment may result in the delegation of more address space
than the exact non-aligned calculated requirement. For example, where a
calculated requirement is larger than /32 but can be satisfied by /30, the
smallest nibble-boundary aligned block that can satisfy that requirement is
/28... The additional address space results from alignment to the applicable
nibble boundary.
However, you then go on to say in your response to my email:
prop-170 does not introduce a requirement that all allocations larger than
one-bit doubling must be nibble-boundary aligned
Section 4.3 of the proposal gates the alignment mechanism behind an explicit
request:
Where an account holder explicitly requests nibble-boundary alignment for a
subsequent allocation larger than the default doubling, it must provide a
long-term IPv6 address plan...
but the disadvantage above doesn't carry that qualifier. It simply states that
a requirement satisfiable by /30 results in a /28 delegation - nothing in that
sentence ties the outcome to an explicit alignment request. Read on its own,
without the benefit of this thread, it presents /28 as the consequence of
*having* that calculated requirement, not the consequence of *choosing*
alignment.
This also sits awkwardly next to the very next sentence in the same
disadvantage: "It is not an independent justification for a larger underlying
requirement." In the example given, /28 is objectively a larger allocation than
the underlying requirement (satisfiable by /30) - four times the address space,
in fact. If the scenario only arises when an applicant opts in, that sentence
is a fair caveat. If it's describing what happens to any qualifying request, it
contradicts itself in the same breath.
This isn't just a wording nitpick. The proposal's own "Implementation
discretion" disadvantage acknowledges that terms like "will normally" and "the
smallest nibble-boundary aligned block" require APNIC/NIR guidance to apply
consistently. An ambiguous trigger condition in the text evaluators will
actually work from is exactly the kind of inconsistency the proposal already
names as a risk.
Regards,Christopher Hawker
_______________________________________________
SIG-policy - https://mailman.apnic.net/[email protected]/
To unsubscribe send an email to [email protected]
