Tl;dr: I propose changing almost all the BMP registries to FCFS. Hi GROW/BMP Fans,
With the pair of draft-evens BMP drafts, we now have some allocation requests from our freshly-minted BMP registries. (https://www.iana.org/assignments/bmp-parameters/bmp-parameters.xhtml#initiation-message-tlvs) I took a look at the registries and TBH I'm not sure why we established them with the policies given. Most of the code points are 16-bit fields, which means they're not a scarce resource, but nevertheless they have restrictive allocation policies -- they're all split 50/50 between Standards Action and Specification Required. Maybe when I was proposing the policies I was thinking Spec Req'd was more permissive than it actually is? But it ain't, not really, it's pretty close to Standards Action in practice. I have in recent times become a fan of the First Come, First Served allocation policy, as a way to virtually eliminate the need to squat on code points. Administrative overhead is very low, you can generally get a code point in a couple business days with about 10 minutes of paperwork. The downside of FCFS is that if you have something that actually does need to be locked down either because it's a scarce resource or for some other reason, you can't. Furthermore I've become less enamored of splitting policies -- it now seems to me to be needless, and unhelpful, structure since a rational and experienced person will always select a code point from the most permissive range, FCFS. OTOH inexperienced people can be confused by having too many choices. The goal of protecting resources from being exhausted by a run on the FCFS "bank" can be satisfied by marking a good-sized range Reserved or by choosing a sufficiently large field size that code points are too cheap to meter. All the BMP registries other than BMP Peer Flags have their policies split 50/50 between Standards Action and Specification Required, modulo four Experimental and one Reserved at the top of each range. I'd like to suggest to the WG that we fix this by changing all the two-byte fields' 50/50 splits to 100% FCFS (keeping the Experimental and Reserved at the top unchanged). In the case of the one-byte fields "BMP Message Types" and "BMP Peer Types" I suggest changing the Standards Action portion (0-127) to FCFS and making the Specification Required portion (128-250) Reserved instead. I propose leaving Peer Flags the way they are, Standards Action. There are only five unallocated flags, it seems reasonable to have a higher bar to allocating one. Registration policies have to be changed by an RFC, so if this proposal sounds good to the WG I volunteer to write a short Internet Draft to make it so. Before going to the effort i wanted to solicit feedback though. Thanks, --John _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
