Robert Wilton 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: ---------------------------------------------------------------------- Hi, Thanks for this document. I found it pretty easy to read/follow and only have a few minor comments/suggestions. Minor level comments: (1) p 2, sec 1. Introduction Traffic Selector (TS) payloads specify the selection criteria for packets that will be forwarded over the newly set up IPsec SA as enforced by the Security Policy Database (SPD, see [RFC4301]). Should "SA" be defined, or is this wellknown? (2) p 3, sec 1.2. Traffic Selector clarification A Traffic Selector (no acronym) is one selector for traffic of a specific Traffic Selector Type (TS_TYPE). For example a Traffic Selector of TS_TYPE TS_IPV4_ADDR_RANGE for UDP traffic in the IP network 198.51.100.0/24 covering all ports, is denoted as (17, 0, 198.51.100.0-198.51.100.255) A Traffic Selector payload (TS) is a set of one or more Traffic Selectors of the same or different TS_TYPEs. It typically contains one or more of the TS_TYPE of TS_IPV4_ADDR_RANGE and/or TS_IPV6_ADDR_RANGE. For example, the above Traffic Selector by itself in a TS payload is denoted as TS((17, 0, 198.51.100.0-198.51.100.255)) Would be better to give IPv6 examples rather than IPv4 examples (both here and below)? (3) p 4, sec 2.2. TS_SECLABEL properties A zero length Security Label MUST NOT be used. If a received TS payload contains a TS_TYPE of TS_SECLABEL with a zero length Security Label, that specific Traffic Selector MUST be ignored. Why not just error (i.e., return TS_UNACCEPTABLE) , wouldn't this be the simpler thing to do? (4) p 4, sec 3. Traffic Selector negotiation 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. I note that this text, usign RFC 2119 language, seems to be somewhat repeating the text in 1.3 and 2.2 second paragraph. Please consider if it would be better to just state this requirement using RFC 2119 language only once. (5) p 5, sec 3.1. Example TS negotiation TSr = (((0,0,203.0.113.0-203.0.113.255), TS_SECLABEL1) Looks like you might have an extra openning brace. Nit level comments: (6) p 6, sec 5. IANA Considerations [Note to RFC Editor (please remove before publication): This value has already bee added via Early Allocation. Missing closing bracket (not that it matters ...) Thanks, Rob _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
