Authors,

While reviewing this document during AUTH48, please resolve 
(as necessary) the following questions using the GitHub issue 
tracker (https://github.com/rfc-editor/rfc9131-AUTH48/issues). 
Each question below corresponds to an issue in the issue tracker.
These questions are also in the XML file.

For details on the process, please see 
https://github.com/rfc-editor/rfc9131-AUTH48

1) <!-- [rfced] FYI: Issue titles 

Because the AUTH48 of this document will be handled in GitHub, we have updated the style of our questions and comments to adapt to GitHub's issue tracker. The first line is the issue title.  The rest of the question or comment is the body of the issue.  -->


2) <!-- [rfced] Keywords for search

Please provide any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search -->


3) <!-- [rfced] Use of ">" in text

Section 1:  Does "before the resolution > process finishes" mean "before the address resolution process finishes"?  If not, will this sentence be clear to readers, or should the ">" be clarified?

Original (We added the period to the end of the sentence):
 Any additional packets arriving before the resolution > process finishes are likely to result in dropped packets

Perhaps:
 Any additional packets arriving before the address resolution process finishes are likely to result in dropped packets. -->


4) <!-- [rfced]  "gratuitous" and/or "unsolicited"?

Section 4.1: In following sentence, should it say both "gratuitous" and "unsolicited"? 

Current:
  the node can send gratuitous unsolicited Neighbor Advertisements -->


5) <!-- [rfced] FYI: "still completed"/"has completed"

Section 5.3.1:  We changed "the address resolution still completed" to "the address resolution process has completed" here.  Please let us know if this is incorrect.

Original:
 Any packets still arriving after the address resolution still completed are sent to the rightful address owner as well.

Currently:
 Any packets still arriving after the address resolution process has completed are sent to the rightful address owner as well. -->


6) <!-- [rfced] Is Duplicated a well-known state?

Section 5.3.1:  We could not find a state named "Duplicated" in any published RFC.  Please confirm that this text will be clear to readers.

Original:
 If the host starts sending packets from its Optimistic address but then changes the address state to Duplicated, the first return packet would trigger the address resolution process and would be buffered until the resolution is completed. -->


7) <!-- [rfced] FYI: "do introduce"/"do not introduce" 

Section 5.3.1:  We changed "do introduce any disruption" to "do not introduce any disruption" here.  Please let us know if this is
incorrect.

Original:
 Therefore, it's safe to conclude that the proposed changes do introduce any disruption for the rightful owner of the duplicated address.

Currently:
 Therefore, it's safe to conclude that the changes specified in this document do not introduce any disruption for the rightful owner of the duplicated address. -->


8) <!-- [rfced] Capitalization of "target address" 

Section 8.5:  Would you like to use either "target address" or "Target Address" (but not both forms) in this document?  We see that capitalization in RFC 4861 is inconsistent as well.  This sentence uses the only instance of the initial-capitalized form.

Original:
 The router could listen to all solicited node multicast address groups and upon receiving a Neighbor Solicitation from the unspecified address search its Neighbor Cache for the solicitation's Target Address. -->


9) <!-- [rfced] Please review inclusive language

Please review the "Inclusive Language" portion of the online Style Guide at <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>, and let us know if any changes are needed. -->


10) <!-- [rfced] FYI: 'all routers' / all-routers  

The following term was used inconsistently in this document. We chose to use the latter form. Please let us know any objections.

 'all routers' / all-routers (multicast address) -->


11) <!-- [rfced] FYI: neighbor cache / Neighbor Cache 
 
The following term was used inconsistently in this document. We chose to use the latter form. Please let us know any objections.

 neighbor cache / Neighbor Cache (per, with one exception (which appears to be an oversight) RFC 4861) -->


12) <!-- [rfced] ND cache or Neighbor Cache?

There are three instances of "ND cache" in this document. Should they be changed to "Neighbor Cache"?  -->


13) <!-- [rfced] FYI: neighbor discovery / Neighbor Discovery

The following term was used inconsistently in this document. We chose to use the latter form. Please let us know any objections.

 neighbor discovery / Neighbor Discovery -->


14) <!-- [rfced] FYI: optimistic address / Optimistic Address

The following term was used inconsistently in this document. We chose to use the latter form. Please let us know any objections.

 optimistic address / Optimistic address / Optimistic Address (per (with two exceptions, which appear to be oversights) RFC 4429) -->


15) <!-- [rfced] FYI: optimistic state / Optimistic state 

The following term was used inconsistently in this document. We chose to use the latter form. Please let us know any objections.

 optimistic state / Optimistic state (per RFC 4429) -->


16) <!-- [rfced] FYI: Preferred / preferred (state)

The following term was used inconsistently in this document. We chose to use the latter form. Please let us know any objections.

 Preferred / preferred (state) (per RFC 4862) -->


17) <!-- [rfced] FYI: solicited-node multicast address

Please note that per RFC 4861 and (with only two exceptions) post-6000 RFCs, we changed "Solicited Node Multicast Address" and "solicited node multicast address" to "solicited-node multicast address". -->


Thank you.

RFC Editor/lb/jm