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