Francesca, thank you for your reviews. Jorge, thanks for your responses. I entered a No Objection ballot but did raise a further question about this document updating RFC 7432.
Alissa > On Dec 19, 2018, at 5:19 AM, Rabadan, Jorge (Nokia - US/Mountain View) > <jorge.raba...@nokia.com> 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 <bess-boun...@ietf.org> on behalf of Francesca Palombini > <francesca.palomb...@ericsson.com> > Date: Friday, December 14, 2018 at 5:13 PM > To: "gen-...@ietf.org" <gen-...@ietf.org> > Cc: "draft-ietf-bess-evpn-df-election-framework....@ietf.org" > <draft-ietf-bess-evpn-df-election-framework....@ietf.org>, "i...@ietf.org" > <i...@ietf.org>, "bess@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 > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > 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 > > > _______________________________________________ > Gen-art mailing list > gen-...@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
