Date: Wed, 21 Nov 2012 17:16:58 +1100
From: Geoff Huston <gih@xxxxxxxxx>
Message-ID: <99B9866C-41D6-4784-AA69-CD25E5910F4B@xxxxxxxxx>
I have no idea whether the allocation requested is reasonable or not,
I haven't read the draft (and unless it becomes more widely used than
currently, might never do so), but I do know that this argument ...
| The guidelines for IP address allocations were documented in RFC2050,
| adopted in November 1996 as a Best Current Practice. ...
is totally bogus in these circumstances.
The rules in RFCs and BCPs bind ordinary users making ordinary requests
for address space - were I to approach IANA with a request for address
space to be allocated, a quick denial quoting the relevant RFC would indeed
be the correct response.
But when the IETF publishes an updated RFC, that always overrides any
earlier RFC, and establishes new policy - either for the general case, or
perhaps (as seems to be happening here) just a one off override of the
normal rules.
Doing that is always acceptable, whatever the issue - it is never adequate
to simply refuse to consider such requests upon the basis that they don't
follow the rules and should be done some other way.
Now, when the IETF (via the last call consensus mechanism) consider whether
the proposed RFC should be published, it is perfectly reasonable to point
out the existing policy, and ask for reasons why use of that mechanism would
not be adequate - if the proponents cannnot explain why doing it the way
they are suggesting is required, or at least is better than the normal way,
then the request (to publish the RFC, not just to perform whatever allocation
it requested - that just falls out of the failure to publish the RFC) should
be refused.
On the other hand, if the proponents can convince the IETF that the
procedure they're suggesting is the best way to proceed, then that's
what should happen - and that it isn't being done the way that the
normal allocation rules would suggest it should be done is 100% irrelevant.
If you have an argument against the proposal, please make it upon the
merits of the request, and not based upon some supposed viloation of
address allocation quidelines.
What the result will be I have no idea - I don't know if this allocation
should happen or not. I might suggest however, that if Noel is correct
about the way this allocation would be used (and Noel usually is correct)
then it may be that an assignment out of the 0::/3 address space (which is
out of the ordinary allocation space for which the guidelines apply)
sounds like it might be the right thing to do - perhaps something like
10f0::/12 (or something near there not currently allocated).
kre