Comments inline...
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.
Regarding port assignment - I know what I'm about to suggest is somewhat
mickey-mouse (and could be interpreted as inviting self-assignment of
ports), but maybe we could make a distinction between the port ranges used
by system processes and the port ranges used by applications (by application
I mean software that is not stand alone and must run on top of another
system like an OS). My only thought behind this is that we could minimize
critical conflicts because an application developer who was denied their
port request would at least know not to self-assign a port from the system
range because there would be no end user remediation of conflicts, whereas
if they picked from the application range, at least they know there'd always
be a workaround to conflicts in the vein of "you can't run my app while
you're running app x". Again this is not to encourage self-assignment, but
to make it a little less problematic when it happens.
This is pretty off the cuff so if it's utterly stupid please treat it like a
brainstorming session and don't forever write me off as an idiot (if you
haven't already).
Thanks,
Nick Staff
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf