Ben Campbell has entered the following ballot position for draft-ietf-sidr-bgpsec-protocol-21: Yes
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-sidr-bgpsec-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I share some of the concerns about deployability, but have nothing new to add to that conversation. Otherwise I just have a few minor comments: -2: draft-ietf-sidr-bgpsec-protocol explicitly excludes non-capitalized versions of 2119 words. This draft does not. It seems different 2119 approaches among the various bgpsec draft could be confusing to the reader. [Update: Oops, sorry, I meant to say draft-ietf-sidr-bgpsec-ops excludes non-capitalized versions of 2119 words. (That is to say, it treats them as their normal English equivalents.)] - 5.2, step 2: I'm almost sure I've missed something here, but if I understand correctly, previous sections talked about how a peer can propagate a BGPsec_Path attribute without modification. Will that cause a problem in this step if the immediate peer propagated an unmodified BGPsec_Path that came from a different AS? - 8.4, last paragraph: The text describes a replay attack, and delegates the mitigation solution to draft-ietf-sidr-bgpsec-rollover. This is an informational reference; it seems like it should be normative. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
