Benjamin Kaduk has entered the following ballot position for draft-ietf-grow-bmp-adj-rib-out-07: 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-grow-bmp-adj-rib-out/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the discussion about my Discuss point; it seems that the document will probably be clear enough to the intended audience that I do not need to press the point further, even if it remains somewhat unclear to readers in a broader audience. Section 1 An example of pre-policy verses post-policy is when an inbound policy applies attribute modification or filters. Pre-policy would contain information prior to the inbound policy changes or filters of data. Post policy would convey the changed data or would not contain the filtered data. I think we had some discussion relating to my question about policy being used to inject new data, and even some suggested edits from Jeff, but I couldn't find those in the -07. Perhaps I just missed them, though.Section 8 Section 8 I agree with the conclusion from discussions on Alvaro's point, that implementations SHOULD only use this with trusted/authorized monitoring devices. But I think it's the role of the security considerations to clarify why this is the case (i.e., that new information would be made available otherwise), and not just provide a rule to be blindly adhered to. _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
