Date: Thu, 22 Nov 2012 16:50:40 +1100
From: Geoff Huston <gih(_at_)apnic(_dot_)net>
Message-ID: <08FCD406-F556-4F7E-BA98-9591D161A3A6(_at_)apnic(_dot_)net>
| 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"
That's not what I said - what I said was that relying upon an RFC as
disqualifying a new one was bogus - that's never going to be possible,
nor should it be. Referencing existing RFCs is of course just fine.
| 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,
My guess would be that is because it doesn't intend to do either of
those things (still just a guess, I am not arguing the merits or
correctness of that particular draft). It is entirely reasonable
to leave existing procedures in place, but override them for a specific
case. If RFC's had an "Ignores" header, then perhaps this one should
say "Ignores: RFC2860 RFC773" (or perhaps Overrides), but there are
no such headers.
| yet the document's directions to the IANA appear to me to be inconsistent
| with those existing procedures and policies.
Yes, that is why it is an RFC, and why it should need IETF consensus to
proceed. If they were just to follow the existing guidelines, they'd
just get address space the normal way. Clearly the proponents of this
draft don't believe that is adequate, or they wouldn't have gone to all
the trouble of writing a draft and attempting to publish it as an RFC.
Before someone else raises it, one issue might be that this is apparently
just intended as an Informational RFC, yet the others are BCP or PS or
something. That's kind of unfortunate, but indicates something of a lack
of categories for RFCs - this is clearly not a BCP (its purpose isn't to
sent any policy, or describe how things should be done, aside from for
this one specific case), nor can it be on standards track (it isn't capable
of multiple independent implementations), Informational is all that is
plausible. Ideally we'd have a separate cagegory so we can divide the
Info docs that are "This is FYI" (that is agreed useful enough to pubish),
from "this is the IETF's consensus about ..."
That is, for this, Info is correct (as things stand) and that doesn't
have any effect upon my opinions.
| To claim, if I understand your line of argument correctly, that every
| RFC essentially is an implicit update of all existing RFCs,
Of course they are, or at least the ones published as the result of
IETF consensus are. Each of them adjusts the overall view of the
state of the world, and how things are, or should be done, in some
particular area, and necessarily have some impact on all kinds of
previous specifications. Where there's a major change, we note that
in order to make it easier to keep track of what's happening, but
whether that happens or not, clearly anything we agree is the right
thing to do is an update.
| 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.
There's nothing circular about it. We could adopt all kinds of bureaucratic
rules, requiring us to explicitly agree to vary the rules of procedure,
before doing anything that is different than has been done before - but
there's really no point. If we (the community as a whole) have agreed
that X is the right thing to do, then we will do whatever is necessary to be
done to make X happen (since that is what we want the result to be).
Insisting on lots of meaningless make-work just to get to the result that
will happen anyway is pointless, we all have better things to do.
| But I appreciate that I am by training a mathematician and not a lawyer,
If you attempt to apply rules of mathematics to this kind of process you
are certainly doomed - the two are nothing at all alike.
Just consider if we did have some rule where earlier RFCs (BCPs or
whatever) must always be followed - and then imagine that at some
point we decided that we're happy with the rules as we have them, and
include in a BCP a rule that says that none of this particular set
of RFCs (including itself) may ever be updated or obsoleted.
How would progress ever be made in the future given that combination
of events? In mathematics it doesn't matter, what is true is true, and
undisputable once proved. In other fields, circumstances change, and
what was correct yesterday is incorrect today.
There's a simple way out, which is one of the basic tenets of any
organisation like this - and that is that we cannot bind future
instances of ourselves. Anything we agree to do, following the
correct procedure to get that agreement (which itself can be altered
if that is so agreed), is always correct, and overrides anything
inconistent that existed earlier (to the extent necessary to give
effect to the new agreement).
| However, it seems to me that it would be more productive
| for the IETF to consider that this issue is a distinct issue,
I doubt it needs consideration at all, I doubt it is even really the
kind of thing that can be considered - even if we were to explicitly
say that existing rules apply and can't be overridden, that would be
meaningless. Attempting to believe that we know better than future
generations is one of the best ways to make a mess - they will just
ignore us anyway.
| 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.
That's fine, and in that case, the IESG should ignore your earlier message
as having almost no relevant content. And of course, my messages have
(beyond this point) no relevance to the consideration of the draft at all.
If you wanted (and if it is appropriate) you could reasonably request that
the authors of the draft explain why the existing procedures are inadequate,
and that the draft should be updated to include that explanation, and
(or course provided that the pposition is correct, and generally accepted)
that would be a push back on publishing this (and assigning the addr block).
Or (or perhaps later) you could argue that the authors reasons aren't
good ones, and that the existing procedures are adequate.
Or you could explain why the whole experiment is useless and a waste
of time, and that allocating address space to it would be senseless.
Or ...
Just not that "we have rules, this ignores them, so dump it" - that
line of argument is bogus.
kre