Closed stoffi92 closed 4 years ago
suehares
commented
4 years ago I would remove: (ie. match - replace - delete communities on administrative boundaries). There is so much that could be said, saying nothing lets people trade on common wisdom.
We added the interfere based on Alissa comment.
Robert needs to review this for RR. My mind is getting fuzzy after all of the comments.
stoffi92
commented
4 years ago @raszuk also for your review
raszuk
commented
4 years ago I would remove both ... I do not understand section 7.7 all together. To me if there is any overlap in actions we should either take first action and log an error and do not apply any.
Mangling more with this is a slippery slope.
On Thu, Apr 23, 2020 at 10:09 PM Christoph Loibl notifications@github.com wrote:
@raszuk https://github.com/raszuk also for your review
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/stoffi92/rfc5575bis/issues/204#issuecomment-618637676, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIH6EHEHU3YKWX5DEKMG3TROCN6DANCNFSM4MOZ3EQQ .
stoffi92
commented
4 years ago Has been solved as suggested by Sue in #181
Section 7.7
other (e.g. there may be more than one conflicting traffic-rate-bytes Traffic Filtering Action associated with a single Flow Specification). Traffic Filtering Action interference has no impact
Maybe we should revise the earlier text about "Interferes with: No other [...]" to be explicit that it does self-interfere.
behaviour (ie. match - replace - delete communities on administrative boundaries). See also Section 12.
nit: could this parenthetical be expanded a little bit more? I feel like it's expected to be common knowledge among the main readership and so the current wording just serves as a trigger for this "well-known" (but not to me) concept, as opposed to standing on its own.