Thanks for your comments, Tom. On Jul 20, 2015, at 11:53 AM, t.petch <[email protected]> wrote: > > 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 believe IANA sort of does this as part of their normal procedures -- most registries I look at have the headings value, name, reference, or similar. They do not have a separate column for current/historic/deprecated, rather, IANA appears to favor putting an annotation such as "(deprecated)" in the description as needed. So, I think there is nothing to do here. > 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. True. You would pick on the only one-byte field in the whole document, wouldn't you? Nonetheless there is plenty of space available so I think this is not a serious issue and should neither hold up progress nor justify the effort of changing multiple implementations. IMHO. > 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 think the notion that change procedures are different for pre-existing code points depending on the assignment policy covering the code point in question is novel, however I've updated all the registries as you request. (A conceivable consequence of the idea that assignment policy affects change procedures might be that FCFS code points could be deprecated by a simple request too, something I think would be frowned upon.) > 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. I don't understand this point. > 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 <blush>. Fixed. Thanks. Also, in the case of 10.6 I listed zero as reserved. > 10.8 'two types for information ' or 'two types of information '? And written that way in multiple other sections too. Did you deliberately object only to this one? It scans OK for me but if the WG wants me to change the wording I'm not going to fight about it. Note, I likely will NOT be at GROW (sorry) but I'd be happy to talk after IDR if you'd like to conclude f2f. I've just submitted -11 with these changes. Regards, --John _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
