General AD hat on:
I'm concerned that since rfc2434bis is in progress, any changes to
RFC 2434 should be made in that draft, not by an additional document.
Otherwise we will end up with a patchwork quilt of documents.
So I'd encourage the authors of iana-reg-policy to figure out where
their ideas would impact draft-narten-iana-considerations-rfc2434bis,
and as the saying goes "send text."
General AD hat off:
1. I agree with those who've said that we can't reasonably make
blanket retroactive changes to the intent of previous
IANA Considerations based on or citing RFC 2434. We can clearly
change the intent of future IANA Considerations (see previous
comment from the AD :-). But if existing, published documents
need to change (2780 to take an example) I think they have to
be changed explicitly.
2. It's easy to say that if a namespace is too small, we should
make it bigger. But, to take a recently contentious example,
there's a *reason* the IPv6 option field is only 3+5 bits long.
It wasn't an idle choice. It was to keep the IPv6 header as
short as possible and as nicely aligned as possible, for the benefit
of hardware designers and wirless networks in particular.
There was also a *reason* the diffserv code point was limited to
6 bits - as above, plus the fact that the ECN folk really needed
the other two bits.
So clearly, these small fields need prudent stewardship.
As a matter of fact, I can make an argument for prudent stewardship
in seemingly much larger fields. 32 bits seemed like a lot in 1980,
no doubt; 128 bits seemed like a lot in 1995. But see
draft-narten-iana-rir-ipv6-considerations-00.txt for why even
a 128 bit field needs prudent stewardship. And even the rather
large domain name space turns out to need prudent stewardship,
as Vint knows only too well.
So however large the namespace gets, it needs prudent stewardship.
I can't disagree that namespaces should be as large as reasonably
possible on engineering grounds. But actually extending a deployed
namespace is a massive undertaking. A good example is the BGP4 AS
number space - we've known for years that it is filling up, but the
deployment effort involved in expanding it has prevented any action.
So even if we can theoretically expand the namespace, it needs prudent
stewardship in practice.
3. Thus I come to the key question - how high should the bar be for
assignments in clearly constrained namespaces? This month's poster
child is IPv6 option numbers, but at an even more basic level, we
should probably be more worried about port numbers, where we seem
pretty close to running out of well-known numbers, and moving along
nicely through the registered port numbers.
I'm on the side of fairly rigorous review in these constrained spaces.
With the experience of the Larry Roberts request, I actually think
RFC 2780 is too lax - it would be better if IETF Review (in rfc2434bis
terminology) was required for option numbers.
Contrary to what I understand the present draft to mean, I think
that for some very critical namespaces, such as IP header fields,
that may have fundamental impact on packet flows, a technical
review of the proposed usage of the parameter is *always*
required before an assignment, regardless of scarcity.
Clarity of definition is *not* enough to justify a registration;
we also need to agree as a community that the proposed usage will
not be a cause of collateral damage to the Internet. There's every
reason that the same standard should apply to specifications
developed outside the IETF exactly as to IETF documents.
For the more critical namespaces covered by 2780, I am quite sure this
applies. There can be other namespaces where it certainly doesn't.
I think we should concentrate on getting the definitions in 2434bis
right. I also think an update of 2780 is needed in the light of
experience.
Brian
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf