Re: [bess] Secdir last call review of draft-ietf-bess-evpn-df-election-framework-06

["Rabadan, Jorge (Nokia - US/Mountain View)" <[e-mail]>]

Hi Russ,

Thank you very much for your review.
We'll publish a new version once we make all the changes suggested by the different reviewers.

Please see some comments in-line with [JORGE].
Thank you.
Jorge


-----Original Message-----
From: Russ Housley <[e-mail]>
Date: Sunday, December 9, 2018 at 3:29 AM
To: "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Secdir last call review of draft-ietf-bess-evpn-df-election-framework-06
Resent-From: <[e-mail]>
Resent-To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, Stephane Litkowski <[e-mail]>
Resent-Date: Sunday, December 9, 2018 at 3:29 AM

    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.

[JORGE] done.
    
    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.

[JORGE] OK, done, thanks.
    
    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.

[JORGE] The authors, chairs and AD have discussed this a few times and we agreed that the document should not be an update of RFC7432, since it is not suggesting any changes to the existing RFC7432 procedures, but new procedures. That section is just a description of the existing state machine. However, if you and other reviewers still think it should be an update, we can maybe change the test or discuss it again. The intend is definitively not to update RFC7432.
    
    
    Nits:
    
    Section 2.2.1:  s/multi homed/multi-homed/
    
    Section 4:  s/the state of the server states/the server states./
[JORGE] fixed, thank you.