Hi Ben, Thanks for the review.
On 8/17/15, 6:44 PM, "Ben Campbell" <b...@nostrum.com> wrote: >Ben Campbell has entered the following ballot position for >draft-ietf-ospf-prefix-link-attr-10: No Objection > >When responding, please keep the subject line intact and reply to all >email addresses included in the To and CC lines. (Feel free to cut this >introductory paragraph, however.) > > >Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >for more information about IESG DISCUSS and COMMENT positions. > > >The document, along with other ballot positions, can be found here: >https://datatracker.ietf.org/doc/draft-ietf-ospf-prefix-link-attr/ > > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >I concur with Kathleen's DISCUSS and Alvaro's comment about the security >considerations. > >Other comments: > >-- 2.1, definition of N-Flag > >There are a couple of occurrences of "NOT" in caps that are not combined >with other 2119 keywords. I assume those are not intentional? We will change these to “not”. > >-- 2.1, 4th paragraph from end, last sentence (also occurs in 3.1): > >The 2119 MAY here doesn’t seem helpful, since this is internal to a >router and does not impact seem interoperability. I suggest it be >restated without 2119 language, unless you want to make it a SHOULD or >stronger. Depending on the application data being advertised and the timing of the flooding, this could occur naturally so I will make it a “may” in both cases. Thanks, Acee >(I am not a stickler that >2119 keywords never be used for things that are not observable by a peer, >but MAYs seem especially useless in that context. I did not object to the >SHOULD in the prior paragraph, since that might have operational value.) > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
