[bess] Roman Danyliw's No Objection on draft-ietf-bess-evpn-bum-procedure-updates-11: (with COMMENT)

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

Roman Danyliw has entered the following ballot position for
draft-ietf-bess-evpn-bum-procedure-updates-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/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-bum-procedure-updates/



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

** I support Lars Eggert’s DISCUSS position.  I have come to the same
conclusion as the GENART reviewer (Paul Kyzivat).  It isn’t clear what this
document is updating.

-- The document header and abstract explicitly say that RC7432 is updated. 
However, I can’t find a clear explanation of how the next in this documents
updates RFC7432

-- Section 5.1. is titled as “Changes to Section 7.2.2 of [RFC7117]” and
changes behavior in RFC7117, but RFC7117 is not being updated (according to the
header and abstract).

** Section 9.
   They do not introduce new security concerns besides what have been
   discussed in [RFC6514], [RFC7117], [RFC7432] and [RFC7524].

Which parts of these security considerations specifically apply here.  For
example, RFC7524 and RFC7432 makes references to MPLS mechanisms (which seem
out of scope here).  Additionally, it appears some of the guidance across these
documents is directed at securing generic EVPN technology – this is helpful,
but please be clear about this case.  What specific guidance is relevant to the
procedures for handling BUM traffic?