Reviewer: Robert Sparks Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-ipsecme-g-ikev2-17 Reviewer: Robert Sparks Review Date: 2024-12-08 IETF LC End Date: 2024-12-10 IESG Telechat date: Not scheduled for a telechat Summary: Essentially ready for publication as a proposed standard RFC but with nits to address before publication. This document is well written and easy to follow. (I agree with Russ, but won't repeat the points in his last call review). There are quite a few places where article and noun agreement should be adjusted. I convinced myself that the recommendation for excluding a GM while preserving forward access control works when the first of the two rekey messages never arrives at one of the remaining group members, but would like those following this closely to think through that case again to make sure there's not an issue. Nits in document order. There are places where there are bare SHOULDs that are not clarified by other text. When would a member chose _NOT_ to follow the SHOULD in the last sentence of 2.3.1? Should the document discuss what a GCKS would do if a GM included transform types it SHOULD NOT (end of 3rd paragraph of 2.3.3) or if it provided a non-zero SPI length field? 7th paragraph of 2.3.3 fails to parse at "by inclusion one". Consider "listens" instead of "passively listens". The 3rd paragraph of 2.4.1.4 may benefit from future-proofing - the timescales called out here may not be the same a decade from now. The last paragraph of 2.4.3 is harder to follow than the rest of the document. Can it be simplified? 2nd paragraph of 3.2 - should "Besides" be "Additionally"? The version of the Group Key Bag Attributes table in section 4.5.2 doesn't match the version in section 9. I think you should go with what's in section 9, but please remove the trailing comma after "GIKE_REKEY," - it makes it look like the next row is a continuation of _this_ value in the column. Consider calling out that several of the "new" values for registries were already established by other documents. See AUTHORIZATION_FAILED as an example, Section 8.2.4 has a bare (and only) mention of protection from reflection attacks (vs replay attack) - should more be said? -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
