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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf