Date: Fri, 01 Jul 2005 11:32:41 +0200
From: Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx>
Message-ID: <D07251C5026B6872A94D3256@B50854F0A9192E8EC6CDA126>
I have yet to read John's draft, but there's one comment that you
made that I want to comment on.
| Summary: I think the document offers very good advice for future registry
| management.
| I think that a blanket retrofitting of a new meaning on the "IESG approval"
| IANA considerations is a thoroughly bad idea.
I would agree with that, as a general principal. New methods and
specifications should apply to those who use it later, not retrospectively
to what has been done before.
There are two exceptions, one is where what has been specified before
turns out to be so broken that it cannot be allowed to continue.
I don't think that applies here (despite the controversy, and despite
that I'm on the side of the controversy opposite to that you're apparently
on...)
And second, when the specification before has been ambiguous, or unclear,
and all possible interpretations that have been made cannot possibly be
correct simultaneously.
That one may be appropriate here. That is, I certainly believe that
2434 means "verify the documentation is adequate" just as John's draft
is apparently proposing. That is, for me, not a change at all.
I certainly would never have ignored a proposal to register trivial
things like IPv6 option codes if it required approval of the use of
the option, rather than documentation of the thing. That is, when
2780 was proposed, I assumed it was using 2434 in the way I interpret
2434, and IESG approval meant a check that the documentation was of
adequate quality for the purpose, and no more than that.
Others apparently thought it meant something different that that, anything
from examination of the quality of the option proposed (making the
IESG judge and jury), to being an "escape route" or fallback, though
from just what I am not sure.
In this situation, both cannot remain, and leaving ambiguity in place for
all those existing documents doesn't help anyone. Any clarification
is going to be seen as a change by some people, the question is, what
change is best to make, or what is the best actual definition.
For what it is worth, I agree with you that "IESG approval" should not
mean "with community consent", that would (almost) be "IETF consensus"
(though perhaps without requiring an RFC to emerge at the end).
For me, IESG approval, and Expert review demand essentially the same
examination - the only difference between them is that it doesn't
make a lot of sense to appoint an expert to look after a space in which
it is not expected that any registrations will actually be requested (pr
where the number is very small). That is, in the period between
registrations the expert can be expected to have retired/resigned, so
each new request would require finding and appointing a new expert.
That's more work than just doing the review. This is what I would
expect of IPv6 option codes (I believe, in about 10 years now, aside
from Router Alert, this one is the one and only addition requested).
As far as history goes, and the OID tree - do remember that the OID tree
has vendor space, in which anyone can trivially register anything.
Once there, the OID is just as good as any other OID.
The Vendor space gets used two ways - one is to actually identify
vendors, and their products (etc). For that it is just fine.
The other is for vendor private MIB variables - for that I (with
hindsight, naturally) believe it has been a failure. All it does
is require data to be sought in multiple different places, depending upon
which vendor's equipment is being managed. Certainly, some of what is
there is truly vendor specific information, but much of it is just
general data that could have been in the standard MIB, but either
wasn't considered, or someone thought it a poor idea. Yet the
customers apparently want it, so into the vendor private MIB it goes.
The IETF may have tried to control MIB contents using registration
control, but at that it failed miserably. That isn't surprising,
it is a tool not suited to the task.
kre
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf