Hi Mahesh, please see inline.
> Mahesh Jethanandani has entered the following ballot position for > draft-ietf-ipsecme-ikev2-rename-esn-03: 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-ipsecme-ikev2-rename-esn/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > No reference entries found for these items, which were mentioned in the text: > [RFCXXXX]. This is false positive. "RFCXXXX" is not a real reference, this is an instructions for IANA to reference this RFC (when it is published). > Possible DOWNREF from this Standards Track doc to [IKEV2-IANA]. If so, the > IESG > needs to approve it. False positive: this is a reference to IANA registry page for IKEv2. > Found terminology that should be reviewed for inclusivity; see > https://www.rfc-editor.org/part2/#inclusive_language for background and more > guidance: > > * Term "he"; alternatives might be "they", "them", "their" This is false positive. There is no any instance of "He" as a pronoun in the text. The only instance of "He" is in the References section as a last name of one of the authors of draft-pan-ipsecme-anti-replay-notification (Qi He). > ------------------------------------------------------------------------------- > 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://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 3, paragraph 3 > + NIT: > > Section 3, paragraph 3 > > * By "sequence numbers" here we assume logical entities (like > > counters) that can be used for replay protection on receiving > > sides. In particular, these entities are not necessary the > > content of the Sequence Number field in the IPsec packets, but may > > be constructed using some information, that is not necessary > > transmitted. > > > s/that is not necessary transmitted/that is not necessarily transmitted/ Fixed, thank you. > Document references draft-ietf-ipsecme-g-ikev2-19, but -20 is the latest > available revision. This cannot be fixed. The drafts reference each other and cannot be published at the same time. Thus one of them would always reference "old" version of the other. > Paragraph 2 > > kev2-rename-esn-03 Abstract This documents clarifies and extends the meaning > > ^^^^^^^^^ > Consider using the singular form after the singular determiner "This". This is a typo. Fixed, thank you. > Section 1, paragraph 1 > > ate packets. Both AH and ESP allow to use either a 32-bit counter or a > > 64-bit > > ^^^^^^ > Did you mean "using"? Or maybe you should add a pronoun? In active voice, > "allow" + "to" takes an object, usually a pronoun. I changed: s/to use/using > Section 1, paragraph 3 > > ction is enabled on receiving side. Thus the sender should always send the > > in > > ^^^^ > A comma may be missing after the conjunctive/linking adverb "Thus". Added comma, thanks. > Section 3, paragraph 7 > > on whether these properties allow to achieve replay protection. Some > > existing > > ^^^^^^^^^^ > Did you mean "achieving"? Or maybe you should add a pronoun? In active voice, > "allow" + "to" takes an object, usually a pronoun. I changed: s/to achieve/achieving Thank you for the careful review. I made all these fixes in my local copy. Regards, Valery. _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
