Hi Alissa, Thanks for your review and comments.
We will correct the improper normative language in section 7 in next version. As for the security considerations, we will discuss among coauthors and come back to you. Best regards, Jie > -----Original Message----- > From: Alissa Cooper [mailto:ali...@cooperw.in] > Sent: Wednesday, December 05, 2018 10:22 AM > To: The IESG <i...@ietf.org> > Cc: draft-ietf-opsawg-ipfix-bgp-commun...@ietf.org; Tianran Zhou > <zhoutian...@huawei.com>; opsawg-cha...@ietf.org; Tianran Zhou > <zhoutian...@huawei.com>; opsawg@ietf.org > Subject: Alissa Cooper's No Objection on > draft-ietf-opsawg-ipfix-bgp-community-11: (with COMMENT) > > Alissa Cooper has entered the following ballot position for > draft-ietf-opsawg-ipfix-bgp-community-11: 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-opsawg-ipfix-bgp-community/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 7: > > "BGP speakers that support the extended message SHOULD be careful to > export the BGP communities in the IPFIX message properly, so that > they only convey as many communities as possible in the IPFIX > message. The Collector which receives an IPFIX message with maximum > length and BGP communities contained in its data set SHOULD be aware > that the BGP communities may be truncated due to limited message > space." > > This uses normative language improperly. "SHOULD be careful" and "SHOULD > be aware" are not actionable by implementations. It seems like in the first > case > this is trying to convey something more like "SHOULD only convey as many > communities as possible without exceeding the 65536-byte limit of an IPFIX > message." The second one seems like it should not be a normative > recommendation. > > Section 8: > > "This document itself does not directly introduce any new security issues." > > I question whether this is true. The motivation for the document describes the > use of BGP communities in IPFIX as inputs to, e.g., traffic optimization > applications. Given that there are known problems associated with the > integrity and authenticity of BGP communities (e.g., [1]), couldn't the > propagation of false BGP communities to these other applications cause the > applications to misbehave in ways above and beyond whatever damage the > false communities do to the operation of BGP itself? > > [1] > https://datatracker.ietf.org/meeting/103/materials/slides-103-grow-bgp-com > munities-spread-their-wings-01 > _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
