[bess] Re: Mahesh Jethanandani's No Objection on draft-ietf-bess-evpn-redundant-mcast-source-14: (with COMMENT)

["Jorge Rabadan (Nokia)" <[e-mail]>]

Hi Mahesh,

Apologies for the delay.
Thank you very much for the review.
We took all your suggestions in the new version 15 just published.

Thanks!
Jorge

From: Mahesh Jethanandani via Datatracker <[e-mail]>
Date: Tuesday, February 4, 2025 at 11:13 AM
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Mahesh Jethanandani's No Objection on draft-ietf-bess-evpn-redundant-mcast-source-14: (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.



Mahesh Jethanandani has entered the following ballot position for
draft-ietf-bess-evpn-redundant-mcast-source-14: 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-evpn-redundant-mcast-source/



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

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "traditional"; alternatives might be "classic", "classical", "common",
   "conventional", "customary", "fixed", "habitual", "historic",
   "long-established", "popular", "prescribed", "regular", "rooted",
   "time-honored", "universal", "widely used", "widespread"
[jorge] thanks. I replaced with “classic”.


A run of idnits revealed probably one warning (for an IPv6 example) that might warrant attention.

draft-ietf-bess-evpn-redundant-mcast-source-14.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info)
  ----------------------------------------------------------------------

     No issues found here.

  Checking nits according to
  https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------

  == There is 1 instance of lines with non-ascii characters in the
     document.

  == The page length should not exceed 58 lines per page, but there was
     1 longer page, the longest (page 1) being 1660 lines


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------

  -- The document has examples using IPv4 documentation addresses
     according to RFC6890, but does not use any IPv6 documentation
     addresses.  Maybe there should be IPv6 examples, too?
[jorge] we included IPv6 examples now.



  Miscellaneous warnings:
  ----------------------------------------------------------------------

  -- The document date (30 January 2025) is 4 days in the past.  Is
     this intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative
     references to lower-maturity documents in RFCs)

     No issues found here.

     Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments
     (--).

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flarseggert%2Fietf-reviewtool&data=05%7C02%7Cjorge.rabadan%40nokia.com%7Ca96a2250011e4ead7cb308dd454ffcbc%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638742932053175612%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=i%2BaZ8H09Vt5y4eo79QbMJwP6%2FVsyqWXMiQRUyT8rCg8%3D&reserved=0)<https://github.com/larseggert/ietf-reviewtool>, so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 5, paragraph 1
> when forwarding G-traffic received on a S-ES. This label is allocated from a
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 5.1, paragraph 4
> ets from the redundant G-sources with a S-ESI label, regardless of the PMSI t
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".
[jorge] fixed in the new version.