[Idr] Roman Danyliw's No Objection on draft-ietf-idr-bgp-flowspec-oid-14: (with COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-idr-bgp-flowspec-oid-14: 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 DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-flowspec-oid/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you Magnus Nystrom for the SECDIR review and for the subsequent updates
by the authors.

** Section 2.  Editorial. s/same autonomous system than/same autonomous system
as/

** Section 2.

   While the
   proposed modification cannot be used for inter-domain coordination of
   traffic filtering, it greatly simplifies distribution of intra-domain
   traffic filtering policies within an autonomous system which has a
   large number of border routers having complex BGP policies.

Should the above key detail be explicitly framed in an applicability statement?

** Section 4.1.  Editorial + normative guidance which frames the text on the
intent of the designed network, not the operator “knowing something”.

OLD
Disabling the new condition above (b.2.2) could be a good practice
      if the operator knew with certainty that a Flow Specification
      would not be originated inside the local domain.

An additional
      case would be if it was known for a fact that only the right
      egress border routers (i.e. those that were also egress border
      routers for the best routes) were originating a Flow Specification
      NLRI.

NEW
Disabling the new condition above (b.2.2) is RECOMMENDED in networks where
policy prohibits Flow Specification from originating inside the local domain or
where configuration dictates that only the egress border routers (i.e. those
that were also egress border routers for the best routes) will originating a
Flow  Specification NLRI.