[rtgwg] Mohamed Boucadair's Yes on draft-ietf-rtgwg-vrrp-rfc8347bis-16: (with COMMENT)

[Mohamed Boucadair via Datatracker <[e-mail]>]

Mohamed Boucadair has entered the following ballot position for
draft-ietf-rtgwg-vrrp-rfc8347bis-16: Yes

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-rtgwg-vrrp-rfc8347bis/



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

Hi Acee, Xufeng, Athanasios, Ravi, and Mingui,

Thank you for the effort put into this document.

The justification provided in Section 6.1 is strong enough to proceed with the
NBC changes without intermediate deprecation steps per 9907.

I already reviewed this document in the past upon the request the authors [1],
so I only have very minor comments:

# No obsolete of VRRP Version 3

OLD:
  This document obsoletes VRRP Version 3 [RFC8347].

NEW :
  This document obsoletes [RFC8347].

# Inclusive language changes in RFC 9568

OLD:
   The following changes have been made consistent with IETF inclusive
   language guidelines:

NEW:
   The following changes have been made consistent with IETF inclusive
   language guidelines and changes made in [RFC9568]:

# grouping name

OLD:
   *  The leaf "effective-priority" was added to the grouping "grouping
      vrrp-state-attributes" to reflect the effective priority due to

NEW:
   *  The leaf "effective-priority" was added to the "vrrp-state-attributes"
      grouping to reflect the effective priority due to

# Fix tree

CURRENT:
             +--ro last-event?                     identityref
             +--ro new-active-reason?
    new-active-reason-type
             +--ro statistics

#  6527 not cited anymore

CURRENT:
   This module references [RFC3768], [RFC9568], and [RFC6527].
   …

   [RFC6527]  Tata, K., "Definitions of Managed Objects for Virtual
              Router Redundancy Protocol Version 3 (VRRPv3)", RFC 6527,
              DOI 10.17487/RFC6527, March 2012,
              https://www.rfc-editor.org/info/rfc6527.

You may remove that entry.

# Long line

OLD:
         when "derived-from-or-self(current()/../version,
               'vrrp:vrrp-v3')" {

NEW:

         when "derived-from-or-self(current()/../version, "
            + " 'vrrp:vrrp-v3')" {

# Better to use a reference statement + add section

OLD:
         description
           "Calculated based on the priority and advertisement
            interval configuration command parameters. Note that
            the units are microseconds rather than centiseconds units
            as configured for advertisement-interval. See RFC 9568.";

NEW:
         description
           "Calculated based on the priority and advertisement
            interval configuration command parameters. Note that
            the units are microseconds rather than centiseconds units
            as configured for advertisement-interval.”;
         reference
           "RFC 9568: Virtual Router Redundancy Protocol (VRRP)
                      Version 3 for IPv4 and IPv6, Section 6.1";

# Explain the type change as well

CURRENT:
         leaf active-transitions {
           type yang:counter64;
           description
             "The total number of times that this virtual router's
              state has transitioned to 'Active'.

              The identifier of this leaf is changed to reflect
              the updated terminology used in RFC 9568.";
         }

May also explain the change to counter64, instead of counter32 as in the
previous version.

# As this this is a revision, we need to follow 3.8.3.2 of RFC9907

OLD
   IANA is requested to update the following YANG module in the "YANG
   Module Names" registry [RFC6020] within the "YANG Parameters"
   registry group to reference this document:

NEW:
   IANA is requested to register the following YANG module in the "YANG
   Module Names" registry [RFC6020] [RFC9890] within the "YANG Parameters"
   registry group.

# Ops Considerations

You may also add a mention about the few type changes in addition to the
inclusive language changes.

# RFC8347 is cited as normative, while that will be obsoleted by this doc.
Please move that one to be listed as informative.

# RFC 6020 is normative: please fix it.

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/rtgwg/ju8w-9Q7ifgc2Jcby1nUSQZWb-M/