Starting with the easy part, IANA Considerations, I would like to see more.
I think that for most if not all the registries, you should be setting up a table, with columns for the RFC in which it is defined and a status, e.g. Current, Historic, Deprecated or some such. I note that the individual message types are not versioned, that is if you want to change the format of a Peer Down notification, you either have the change the BMP version or else deprecate Peer Down and introduce Peer Downer or some such. I think it a mistake not to define that assignment policy for the types that are defined in this I-D. They may become obsolete or superseded in which case you need to specify what is required to update them. I believe that all the all the assignment policies should start at zero. I would like to see a Group name for these registries - if there isn't one, then BMP Initiation Message TLVs could appear after Blocks Extensible Exchange Protocol and Route Mirroring TLVs after Route Distinguisher Type Field. 10.1 'defines five message types ' and then lists seven 10.2 'defines nine statistics types ' and then lists fourteen 10.5 'defines four types ' and then lists five 10.6 most registries start with zero; this one starts with one and zero has no assignment policy 10.8 'two types for information ' or 'two types of information '? Tom Petch ----- Original Message ----- From: "Christopher Morrow" <[email protected]> To: <[email protected]>; <[email protected]>; <[email protected]>; <[email protected]> Sent: Sunday, July 19, 2015 12:05 AM > Howdy Grow folk, > I think at the meeting in 48hrs time Jon Scudder plans to ask (again) > for WGLC for: draft-ietf-grow-bmp > (https://www.ietf.org/internet-drafts/draft-ietf-grow-bmp-09.txt) > > Let's all have read through ,decide if we're happy and get this > pushed along to the IESG for review/pulication. This is the abstract > of the document: > > "This document defines a protocol, BMP, that can be used to monitor > BGP sessions. BMP is intended to provide a more convenient interface > for obtaining route views for research purpose than the screen- > scraping approach in common use today. The design goals are to keep > BMP simple, useful, easily implemented, and minimally service- > affecting. BMP is not suitable for use as a routing protocol." > > Thanks! > -chris morrow > (co-chair 1 or 2) _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
