These are great, thanks! On Wed, Mar 17, 2021 at 7:33 AM Rabadan, Jorge (Nokia - US/Mountain View) < [email protected]> wrote:
> Hi Murray, > > > > Thanks for reviewing. Please see my comments in-line with [jorge]. > > We have addressed your comments, you should see the changes in the next > revision. > > > > Thx > > Jorge > > > > *From: *Murray Kucherawy via Datatracker <[email protected]> > *Date: *Thursday, January 21, 2021 at 5:23 AM > *To: *The IESG <[email protected]> > *Cc: *[email protected] < > [email protected]>, [email protected] < > [email protected]>, [email protected] <[email protected]>, Bocci, Matthew > (Nokia - GB) <[email protected]> > *Subject: *Murray Kucherawy's No Objection on > draft-ietf-bess-evpn-proxy-arp-nd-11: (with COMMENT) > > Murray Kucherawy has entered the following ballot position for > draft-ietf-bess-evpn-proxy-arp-nd-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/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-proxy-arp-nd/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > In addition to Barry's comments, I found that "BD" appears in the glossary > twice, and "SLLA" appears in the glossary but nowhere else in the document. > > [jorge] fixed both things, thanks. > > > > Are "Address Resolution" and "Large Data Center" formal terms? If not, > they > should be lowercase. > > [jorge] fixed address resolution. Since we are using DC as an acronym, I’m > using DC consistently now, throughout the document. Thanks. > > > > > > Alluding to a lot of things Alvaro pointed out: Many of the SHOULDs in this > document are bare, in that they give the implementer a choice but no > guidance > on how to make that choice. For instance: > > A Proxy-ARP/ND implementation SHOULD support static, dynamic and > EVPN-learned entries. > > How would I decide whether I've got a use case that justifies not doing > one of > those, and what are the interoperability implications of that decision? > > I suggest reviewing these. > > [jorge] we reviewed all those after Alvaro’s review. About the one you > point out, I changed it to: > > “A Proxy-ARP/ND implementation in an EVPN BD MUST support dynamic and > EVPN-learned entries, and SHOULD support static entries.” > > Since if the solution is implemented, at least dynamic and evpn entries > are needed. > > > > >
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
