Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6
draft-ietf-rtgwg-vrrp-rfc5798bis-18

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-rtgwg-vrrp-rfc5798bis and RFC 9568, changed IESG state to RFC Published)

[Ballot comment]
I am afraid that I cannot offer a detailed review of this document, i.e., I will rely on Dave Thaler's intdir review at https://datatracker.ietf.org/doc/review-ietf-rtgwg-vrrp-rfc5798bis-15-intdir-telechat-thaler-2023-12-27/
(and I have seen that Acee and Dave have discussed the topics).

After reading Erik Kline's ballot review, I second his points.

[Ballot comment]
In Section 2.5, there's this:

The Active Router SHOULD observe that this situation is occurring and log the problem.

I understand "SHOULD log", but I don't understand "SHOULD observe".  How about:

The Active Router SHOULD log the problem if it observes that this situation is occurring.

[Ballot comment]
Thanks for doing this work!

I have a few small comments below, I hope they're helpful.

### Section 4.1

“The IPvX example above shows a Virtual Router configured to cover the IPv4 address owned by Router-1 (VRID=1, IPvX_Address=A)”

Shouldn’t that be “IPvX” not “IPv4”?

### Section 6.4.3

Pretty nitty, the RFCEd would presumably catch this, and I’m puzzled how it would have happened, but “@ Discard ADVERTISEMENT” isn’t at the same indent level as all the other @ items (it should be one space further in).

### Section 8.2.4

“Additional configuration MAY be required in order for Unsolicited Neighbor Advertisements to update the corresponding neighbor cache.”

Did you really intend the BCP 14-style MAY there? If so, OK, but it reads as though a lowercase “may” would do the job.

[Ballot comment]
# Internet AD comments for draft-ietf-rtgwg-vrrp-rfc5798bis-16
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

* Thanks to Dave Thaler for the INT-DIR review.

## Comments

### S5.1.2.2, S8.2.4

* Super-nit-y, but RFC 5952 S4.3 indicates lowercase (ff02:...).

### S6.4.3

* "MUST respond to ND Neighbor Solicitation message"

  I think it might be helpful to reiterate here that the (R)outer Flag MUST
  be set in these messages (similar to the text in S6.4.1).

## Nits

### S1.4

* "will normally take more than 10 seconds to learn the default
  routers on a LAN"

  I found this wording to be misleading.  Hosts regularly learn default
  routers as soon as they join the network.  I think this text might actually
  mean something more like: "to learn *about a change in* the default routers
  on a LAN" and/or (possibly) "to learn *all* the default routers on a LAN".

  I see that 5798 had somewhat similarly worded text, so no strong feelings
  about changing this; just for your consideration.

### S5.1.1.3, S5.1.2.3, S7.1, S9

* Up to you, but RFC 5082 might be cite-able here, if it helps anything.

### S5.2.5

* "is ignored" -> "MUST be ignored", in order to use standards terminology?

### S6.4.3

* "the primary IPvX Address of the sender is greater than the local primary
  IPvX Address"

  I assume the comparison function implied here means "when IPvX addresses
  are treated as network-byte order unsigned integers"?

### S8.1.1

* Super nit-y, but you might consider:

  "running between a group of routers" ->
  "running among a group of routers"

### S8.3.2

* "Skew_Time is inversely proportional to the priority"

  Strictly speaking I think this isn't quite true (given the formula in
  S6.1, it's linear but with a negative coefficient?).  But it's been a long,
  long time since I've had any proper maths course, so maybe ignore me.

  "Skew_Time decreases with increasing priority", perhaps.  Or
  just leave it as is, since the figurative meaning is correct.

### S9

* If it helps, perhaps drop a reference to RFC 9099 S2.3, for some IPv6
  link-layer security considerations discussion.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-rtgwg-vrrp-rfc5798bis-12. If any part of this review is inaccurate, please let us know.

We understand that upon approval of this document, we should replace all references to RFC 5798 in the IANA registries with references to this document. Those registrations are listed below.

First, in the Protocol Numbers registry at

https://www.iana.org/assignments/protocol-numbers

IANA will replace the reference for the following registration with a reference to this document:

112 VRRP Virtual Router Redundancy Protocol [this document]

Second, in the Local Network Control Block (224.0.0.0 - 224.0.0.255 (224.0.0/24)) registry in the IPv4 Multicast Address Space registry group at

https://www.iana.org/assignments/multicast-addresses

IANA will replace the reference to RFC 5798 for the following registration with a reference to this document:

224.0.0.18 VRRP [RFC3768][this document]

Third, in the Link-Local Scope Multicast Addresses registry in the IPv6 Multicast Address Space registry group at

https://www.iana.org/assignments/ipv6-multicast-addresses

IANA will replace the reference for the following registration with a reference to this document:

FF02:0:0:0:0:0:0:12 VRRP [this document]

Fourth, in the "IANA Unicast 48-bit MAC Addresses" registry in the IANA OUI Ethernet Numbers registry group at

https://www.iana.org/assignments/ethernet-numbers

IANA has assigned two blocks of Ethernet unicast addresses as follows (in hexadecimal):

IANA will replace the references for the following registrations with references to this document:

00-01-00 to 00-01-FF VRRP (Virtual Router Redundancy Protocol) [this document]
00-02-00 to 00-02-FF VRRP IPv6 (Virtual Router Redundancy Protocol IPv6) [this document]

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

Amanda Baber
IANA Operations Manager

The following Last Call announcement was sent out (ends 2023-12-11):

From: The IESG
To: IETF-Announce
CC: draft-ietf-rtgwg-vrrp-rfc5798bis@ietf.org, james.n.guichard@futurewei.com, rtgwg-chairs@ietf.org, rtgwg@ietf.org, yingzhen.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6) to Proposed Standard


The IESG has received a request from the Routing Area Working Group WG
(rtgwg) to consider the following document: - 'Virtual Router Redundancy
Protocol (VRRP) Version 3 for IPv4 and IPv6'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-12-11. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines version 3 of the Virtual Router Redundancy
  Protocol (VRRP) for IPv4 and IPv6.  It is based on VRRP (version 2)
  for IPv4 that is defined in RFC 3768 and in "Virtual Router
  Redundancy Protocol for IPv6", and obsoletes the prevision
  specification of this version documented in RFC 5798.  VRRP specifies
  an election protocol that dynamically assigns responsibility for a
  Virtual Router to one of the VRRP Routers on a LAN.  The VRRP Router
  controlling the IPv4 or IPv6 address(es) associated with a Virtual
  Router is called the Active Router, and it forwards packets sent to
  these IPv4 or IPv6 addresses.  Active Routers are configured with
  virtual IPv4 or IPv6 addresses, and Backup Routers infer the address
  family of the virtual addresses being advertised based on the IP
  protocol version.  Within a VRRP Router, the Virtual Routers in each
  of the IPv4 and IPv6 address families are independent of one another
  and always treated as separate Virtual Router instances.  The
  election process provides dynamic failover in the forwarding
  responsibility should the Active Router become unavailable.  For
  IPv4, the advantage gained from using VRRP is a higher-availability
  default path without requiring configuration of dynamic routing or
  router discovery protocols on every end-host.  For IPv6, the
  advantage gained from using VRRP for IPv6 is a quicker switchover to
  Backup Routers than can be obtained with standard IPv6 Neighbor
  Discovery mechanisms.

  The VRRP terminology has been updated to conform to inclusive
  language guidelines for IETF technologies.  The IETF has designated
  National Institute of Standards and Technology (NIST) "Guidance for
  NIST Staff on Using Inclusive Language in Documentary Standards" for
  its inclusive language guidelines.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-vrrp-rfc5798bis/



No IPR declarations have been submitted directly on this I-D.

Thank you for the document. Given the BIS nature of the document, all changes seem appropriate and no obvious errors were found during AD review. However, several idnits picked up as follows. Authors, please review and fix where appropriate:

  == There are 3 instances of lines with multicast IPv4 addresses in the
    document.  If these are generic example addresses, they should be changed
    to use the 233.252.0.x range defined in RFC 5771

  == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses
    in the document.  If these are example addresses, they should be changed.

  -- The draft header indicates that this document obsoletes RFC5798, but the
    abstract doesn't seem to directly say this.  It does mention RFC5798
    though, so this could be OK.

  ** Obsolete normative reference: RFC 3768 (Obsoleted by RFC 5798)

  -- Obsolete informational reference (is this intentional?): RFC 2338
    (Obsoleted by RFC 3768)

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
 
  The WG has reached broad agreement that this document is needed.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
 
  No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)
 
  No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

  No known implementation of this draft.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
 
  NA.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
  The document has gone through routing, security and ops directorate reviews.
 
  All reveiew comments have been addressed.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
 
  NA.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

  No errors found.


## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

  Yes. The changes improved the readability of the original RFC.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

    NA.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

    Proposed Standard. This document is RFC5798bis.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

    There were IPR disclosures from IBM and Cisco for RFC 5798. Efforts have been
    made to reach the IPR holders, including announcement on the WG list:
    https://mailarchive.ietf.org/arch/msg/rtgwg/YtW2RcXu14V3H465iRXoxRfXGAk/

    Later we received confirmation from Mike Fox (mjfox@us.ibm.com) and Cisco Legal
    team that both patents had expired.


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

    There are two authors listed on this draft, and they have actively contributed
    to this document.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

    No.


16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

    NA.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

  ** Obsolete normative reference: RFC 3768 (Obsoleted by RFC 5798)


18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

    No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

    The publication of this document will obsolete RFC 5798. The datatracker
    metadata correctly reflects this, and it's listed on the title page, abstract
    and the introduction.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

    This is a bis version of RFC 5798. There is no new IANA assignment needed,
    however the IANA considerations was augmented to include all the IPv4/IPv6
    multicast address allocation and Ethernet MAC addrss allocation.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

    NA.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
 
  The WG has reached broad agreement that this document is needed.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
 
  No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)
 
  No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

  No known implementation of this draft.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
 
  NA.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
  The document has gone through routing, security and ops directorate reviews.
 
  All reveiew comments have been addressed.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
 
  NA.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

  No errors found.


## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

  Yes. The changes improved the readability of the original RFC.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

    NA.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

    Proposed Standard. This document is RFC5798bis.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

    There were IPR disclosures from IBM and Cisco for RFC 5798. Efforts have been
    made to reach the IPR holders, including announcement on the WG list:
    https://mailarchive.ietf.org/arch/msg/rtgwg/YtW2RcXu14V3H465iRXoxRfXGAk/

    Later we received confirmation from Mike Fox (mjfox@us.ibm.com) and Cisco Legal
    team that both patents had expired.


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

    There are two authors listed on this draft, and they have actively contributed
    to this document.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

    No.


16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

    NA.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

  ** Obsolete normative reference: RFC 3768 (Obsoleted by RFC 5798)


18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

    No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

    The publication of this document will obsolete RFC 5798. The datatracker
    metadata correctly reflects this, and it's listed on the title page, abstract
    and the introduction.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

    This is a bis version of RFC 5798. There is no new IANA assignment needed,
    however the IANA considerations was augmented to include all the IPv4/IPv6
    multicast address allocation and Ethernet MAC addrss allocation.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

    NA.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
 
  The WG has reached broad agreement that this document is needed.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
 
  No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)
 
  No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

  No known implementation of this draft.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
 
  NA.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
  The document has gone through routing, security and ops directorate reviews.
 
  All reveiew comments have been addressed.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
 
  NA.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

  No errors found.


## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

  Yes. The changes improved the readability of the original RFC.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

    NA.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

    Proposed Standard. This document is RFC5798bis.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

    There is an IPR for RFC 5798, however the IPR is not linked to this document
    yet. A case has been opened for this issue:
    https://github.com/ietf-tools/datatracker/issues/6557
    This issue needs to be addressed for the document to progress.


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

    There are two authors listed on this draft, and they have actively contributed
    to this document.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

    No.


16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

    NA.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

  ** Obsolete normative reference: RFC 3768 (Obsoleted by RFC 5798)


18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

    No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

    The publication of this document will obsolete RFC 5798. The datatracker
    metadata correctly reflects this, and it's listed on the title page, abstract
    and the introduction.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

    This is a bis version of RFC 5798. There is no new IANA assignment needed,
    however the IANA considerations was augmented to include all the IPv4/IPv6
    multicast address allocation and Ethernet MAC addrss allocation.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

    NA.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/