Re: [bess] Zaheduzzaman Sarker's No Objection on draft-ietf-bess-evpn-oam-req-frmwk-08: (with COMMENT)

[Donald Eastlake <[e-mail]>]

I believe we are in agreement on resolutions of all your comments.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]

On Thu, Apr 8, 2021 at 3:29 AM Zaheduzzaman Sarker
<[e-mail]> wrote:
>
> Hi,
>
> Thanks for the responses. Please see inline below.
>
> BR
> Zahed
>
> On 2021-04-07, 20:21, "Donald Eastlake" <[e-mail]> wrote:
>
>     Thanks for your comments. See below.
>
>     On Wed, Apr 7, 2021 at 1:02 PM Zaheduzzaman Sarker via Datatracker
>     <[e-mail]> 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   [phone] (cell)
>      2386 Panoramic Circle, Apopka, FL 32703 USA
>      [e-mail]
>