With respect Robert, I disagree with your line of argument and I disagree
with your assertion that a reference to an existing RFC is "bogus under
these circumstances"
This eid draft does not claim to obsolete or update either the description
of roles and responsibilities in RFC2860 or the directions to the IANA in
RFC4773, yet the document's directions to the IANA appear to me to be
inconsistent
with those existing procedures and policies.
To claim, if I understand your line of argument correctly, that every
RFC essentially is an implicit update of all existing RFCs, and every
RFC does not need to explicitly obsolete or update any other RFC, as
it does does so by default upon publication of the RFC is not a line
of argument that I find that I could agree with.
For me, it's like proclaiming that: "everything I do is right, and if
whatever I do contravenes existing processes and procedures then my
actions implicitly update those processes and procedures such that
everything I do is right" I find that I cannot agree with such a
circular self-referential line of reasoning.
Instead, I believe that the processes and processes that the IETF follow are
deliberative decisions, and that we update and amend those processes and
procedures explicitly, and documents that perform such updates say so
explicitly, and are accepted and published on the basis of explicit
consideration of the processes and procedures and acceptance of the
amendment.
But I appreciate that I am by training a mathematician and not a lawyer,
and you may indeed be making some critical observations about the nature
of the IETF's processes and procedures whose finer points may well have
escaped me. However, it seems to me that it would be more productive
for the IETF to consider that this issue is a distinct issue, and not
confound the consideration of the IETF Last Call of this particular
eid draft with the broader issue of the manner by which the IETF crafts
and maintains its own procedures, processes and policies.
regards,
Geoff
speaking for myself and noone else
On 22/11/2012, at 6:09 AM, Robert Elz <kre(_at_)munnari(_dot_)OZ(_dot_)AU>
wrote:
Date: Wed, 21 Nov 2012 17:16:58 +1100
From: Geoff Huston <gih(_at_)apnic(_dot_)net>
Message-ID: <99B9866C-41D6-4784-AA69-CD25E5910F4B(_at_)apnic(_dot_)net>
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