Hi Murray,

Thanks very much for reviewing.

We cleaned the glossary in version 9.
The document deals with an optimization of the customer MAC flush mechanisms in 
RFC7623, but if your implementation cannot enable this optimization, 
interoperability is still ok given that the procedures in RFC7623 are still 
enforced. The changes in version 9 should make this clearer.

Thanks!
Jorge


From: Murray Kucherawy via Datatracker <nore...@ietf.org>
Date: Wednesday, August 9, 2023 at 11:17 PM
To: The IESG <i...@ietf.org>
Cc: draft-ietf-bess-pbb-evpn-isid-cmacfl...@ietf.org 
<draft-ietf-bess-pbb-evpn-isid-cmacfl...@ietf.org>, bess-cha...@ietf.org 
<bess-cha...@ietf.org>, bess@ietf.org <bess@ietf.org>, Matthew Bocci (Nokia) 
<matthew.bo...@nokia.com>
Subject: Murray Kucherawy's No Objection on 
draft-ietf-bess-pbb-evpn-isid-cmacflush-08: (with COMMENT)

CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.



Murray Kucherawy has entered the following ballot position for
draft-ietf-bess-pbb-evpn-isid-cmacflush-08: 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/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-pbb-evpn-isid-cmacflush/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The term "B-Component" is in the glossary, but isn't used in this document.
Same with "CE" and "vES".

I find the use of SHOULD around an administrative option to be peculiar.  This
is normally associated with interoperability requirements, but even setting
that aside, let's say I decide to implement this in a way that the solution
overall or the capability defined in Section 4 simply can't be enabled or
disabled.  Is the implementation still viable?  I also concur with John's point
that the SHOULD-MAY combination is similarly strange.


_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Reply via email to