Reviewer: Russ Housley Review result: Has Nits I reviewed this document as part of the Security Directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Security Area Directors. Document authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments. Document: draft-ietf-bess-evpn-df-election-framework-06 Reviewer: Russ Housley Review Date: 2018-12-09 IETF LC End Date: 2018-12-18 IESG Telechat date: unknown Summary: Has Nits Major Concerns: None Minor Concerns: Please spell out EVPN on first use. I suspect that "Ethernet VPN" is good enough since "VPN" is quite well known. The Abstract seems to be overly complete, so it reads more like an Introduction. I suggest someting like: An alternative to the default Designated Forwarder (DF) selection algorithm in Ethernet VPN (EVPN) networks is defined. The DF is the Provider Edge (PE) router responsible for sending broadcast, unknown unicast and multicast (BUM) traffic to multi-homed Customer Equipment (CE) on a particular Ethernet Segment (ES) within a VLAN. In addition, the capability to influence the DF election result for a VLAN based on the state of the associated Attachment Circuit (AC) is specified. I suggest that the original Abstract text become Section 2. Section 3 says: ... In addition, since the specification in EVPN [RFC7432] does leave several questions open as to the precise final state machine behavior of the DF election, section 3.1 describes precisely the intended behavior. This seems like an update to RFC 7432. If that is the intent, please update the Introduction and the Title Page Heading to say so. Nits: Section 2.2.1: s/multi homed/multi-homed/ Section 4: s/the state of the server states/the server states./
