I believe we are in agreement on resolutions of all your comments. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA [email protected]
On Thu, Apr 8, 2021 at 3:29 AM Zaheduzzaman Sarker <[email protected]> wrote: > > Hi, > > Thanks for the responses. Please see inline below. > > BR > Zahed > > On 2021-04-07, 20:21, "Donald Eastlake" <[email protected]> wrote: > > Thanks for your comments. See below. > > On Wed, Apr 7, 2021 at 1:02 PM Zaheduzzaman Sarker via Datatracker > <[email protected]> wrote: > > > > Zaheduzzaman Sarker has entered the following ballot position for > > draft-ietf-bess-evpn-oam-req-frmwk-08: No Objection > > > > ... > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thanks for the document and thanks to David Black for TSVART review. > > > > Nits/comments: > > > > * P-MAC and C-MAC are these defined somewhere else? References would > be nice > > here. > > P-MAC does not occur in the draft; I think you mean B-MAC. C-MAC is > Customer/Client MAC address and B-MAC is Backbone MAC address as > further specified in RFC 7623. These can be spelled out and a > reference to RFC 7623 (which is already listed in the References for > the draft) added. > > Yes, I meant B-MAC and C-MAC . And yes spelling out and reference will be > helpful. > > > * Section 1.3, Section 2.1 and Section 2.2 describes P nodes in > different > > ways and that has created confusion to me. Can this be well defined in > the > > terminology section once and just be used in other place? > > OK, except I think it should be spelled out on first use in 2.1. But > certainly the wording should be parallel in these cases. > > > * Section 2.5 : "[802.3]" is this supposed to be a reference? it leads > to > > nowhere. > > Yes, it is intended to be reference to IEEE Std 802.3-2015 (or > whatever the most recent version is). I have no idea why the nits > checker doesn't complain about this being missing from the References > sections. If it did, it would already have been fixed. Since this is > just an example, I think it can be added as an Informational > Reference. > OK. > > > * Section 3.1.1.2.1 : first time encountered "network management > station > > (NMS)", if this document is not introducing it then I would suggest to > at this > > to section 1.3 and add some descriptive texts, otherwise define it. > > Would it be sufficient to add an entry in the terminology section > (1.3) and a reference to RFC 6623? > > Yes, that will do. > > > * Section 3.1.2.1 : would be nice to expand MTU. > > Sure. > > > * Section 3.2.1: I can't really parse - "EVPN Network OAM SHOULD > provide > > mechanisms for measuring packet loss for a given service [RFC7680] > [RFC6673]." > > are these IPPM mechanisms recommended to be used for EVPN networks? or > are > > those merely examples? > > These are examples. > > In that case, I would suggest to rephrase the sentence to be clear that those > are examples. > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > [email protected] > _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
