John Scudder has entered the following ballot position for draft-ietf-ipsecme-labeled-ipsec-11: 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-labeled-ipsec/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # John Scudder, RTG AD, comments for draft-ietf-ipsecme-labeled-ipsec-11 CC @jgscudder Thanks for this document. I have just one comment. ## COMMENTS I agree with Rob Wilton's point (4), about specifying things only once. The place I bumped into this was that Section 2.2 says, The TS_SECLABEL Traffic Selector Type MUST NOT be the only TS_TYPE present in the TS payload. If a TS payload is received with only TS_SECLABEL Traffic Selector types, an Error Notify message containing TS_UNACCEPTABLE MUST be returned. whereas Section 3 says, TS_SECLABEL MUST NOT be used without another TS_TYPE in a Traffic Selector Payload, as it does not specify a complete set of traffic selectors on its own. TS_SECLABEL is complimentary to another type of Traffic Selector. There MUST be an IP address Traffic Selector type in addtion to the TS_SECLABEL Traffic Selector type in the Traffic Selector Payload. The re-specification in Section 3 seems potentially problematic in that it introduces a restriction not in the Section 2.2 text. That is, 2.2 says only that TS_SECLABEL can't appear naked, whereas 3 says that it MUST be accompanied by an IP address Traffic Selector type. Possibly this could be viewed as an irrelevant difference, but (a) might there be other selector types introduced in the future, that would sufficiently contextualize TS_SECLABEL without the presence of an IP address selector, and (b) TS_FC_ADDR_RANGE is a thing? Please consider specifying this only once. My impulse would be to remove the quoted paragraph from Section 3 but what do I know? ### NITS In the second quote above, s/addtion/addition/ ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
