Hi Jorge, Thanks for your update. I am ok with the resolution of the nits / editorial, thank you. After looking more into the updating issue, I think that the main question here is: do you consider that this will be widely deployed? (As in, you would expect future deployments to widely implement these mechanisms?) In answer to Adrian you wrote: "The intend is definitively not to update RFC7432 but to specified new procedures, that was the agreement so far. In other words, this work does not mandate an upgrade of all the systems supporting RFC7432. The RFC7432 are still fine. Maybe we need to rephrase that sentence? " I just want to clarify that saying that your doc updates RFC7432 doesn't mean that it becomes mandatory for all the systems. I understand that you do not want to upgrade all the systems that already support RFC7432. But from my understanding an update to a document can also be an extension or optional mechanism (which is what you have here), which is considered to be an important addition to the existing RFC. We have an example in the CoRE wg with RFC7252 (Constrained Application Protocol) which is updated by RFC7959 (Block-Wise Transfers in the Constrained Application Protocol), which is an optional features, but which specifies: A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, so there is an expectation that the Block options will be widely used in CoAP implementations. Therefore, this specification updates RFC 7252. This is the only "open point" I have left, and is more of a question than a strong concern. I cc Martin for more input, but if we don't get any, this will be my Gen-ART review of v-07. Then it's up to the IESG to say what's the right way. Thanks for all your work! Francesca On 19/12/2018, 11:19, "Rabadan, Jorge (Nokia - US/Mountain View)" wrote: Hi Francesca, Thank you very much for your review. Please see in-line how we are resolving your comments in the next revision (07, to be published asap). Thanks. Jorge -----Original Message----- From: BESS on behalf of Francesca Palombini Date: Friday, December 14, 2018 at 5:13 PM To: "gen-art@ietf.org" Cc: "draft-ietf-bess-evpn-df-election-framework.all@ietf.org" , "ietf@ietf.org" , "bess@ietf.org" Subject: [bess] Genart last call review of draft-ietf-bess-evpn-df-election-framework-06 Reviewer: Francesca Palombini Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-bess-evpn-df-election-framework-06 Reviewer: Francesca Palombini Review Date: 2018-12-14 IETF LC End Date: 2018-12-18 IESG Telechat date: Not scheduled for a telechat Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Major issues: N/A Minor issues: I agree with the reviewers comments saying that this document should update RFC7432 and RFC8124. In particular, quoting RFC2232 (https://tools.ietf.org/html/rfc2223#section-12): [...] A document that merely updates an earlier document cannot stand on its own; it is something that must be added to or inserted into the previously existing document, and has limited usefulness independently. The terms Supercedes and Replaces are no longer used. Updates To be used as a reference from a new item that cannot be used alone (i.e., one that supplements a previous document), to refer to the previous document. The newer publication is a part that will supplement or be added on to the existing document; e.g., an addendum, or separate, extra information that is to be added to the original document. (Yes, RFC2232 is obsolete, but I could not find the same text in the more recent RFC7322) [JORGE] I think this document "can stand on its own" and it is "useful independently" of RFC7432, although the latter document is a normative reference of course. Please see the resolution to Adrian's comment: https://www.ietf.org/mail-archive/web/bess/current/msg03760.html Martin, please let us know if you are not okay with our resolution. Nits/editorial comments: "but they do not require any changes to the EVPN Route exchange and have minimal changes to their content per se." * what does their refer to? [JORGE] changed to the following for clarity: "These mechanisms do involve changes to the Default DF Election algorithm, but they do not require any changes to the EVPN Route exchange and have minimal changes in the EVPN routes." * Section 2.2.2: expand MAC-VRF on first usage for readability (or add a reference to its definition) [JORGE] added to the terminology section. * Figure 3: add a definition for ANY STATE (the figure is clear, but for consistency I would add that in the text as well) [JORGE] Added: "5. ANY_STATE: Refers to any of the above states." * Figure 3: add "or" between VLAN_CHANGE, RCVD_ES, LOST_ES (again, not necessary, suggested for readability of the figure) [JORGE] done, thx * Section 3.1: the term "re-entering" needs clarifying: I would consider a loop as re-entering the state, but from bullet 8. it seems like you don't. [JORGE] good point. Changed 8 to: "8. DF_CALC on VLAN_CHANGE, RCVD_ES or LOST_ES: do *****as in transition 7.******" * suggestion for figure 4 (otherwise it looks like there are 2 fields Bitmap of 1B each): 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0x06 | Sub-Type(0x06)| RSV | DF Alg | Bitmap ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [JORGE] done, thanks. * Section 3.2: why was Bit 0 left unassigned in Bitmap? [JORGE] there are implementations of https://tools.ietf.org/html/draft-ietf-bess-evpn-pref-df-02 using that bit. * IANA considerations: I think you want to specify that the policy for Alg 31 is Experimental use (right now the text describing the policy only says "RFC required", with no distinction for different values). [JORGE] ok, done. _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess