Reviewer: Stephen Farrell Review result: Has Issues This is basically fine, but I think there's one issue that isn't quite a nit: 1.3: "Typically, the other TS_TYPE would be of type TS_IPV4_ADDR_RANGE and/or TS_IPV6_ADDR_RANGE." That seems a bit vague, and maybe less future proof than might be the case, e.g. say if someone defines a new TS type for gold, silver etc. service level that's also intended to be combined with address TS's, I'm not sure it'd make sense to combine this and that (putative) new service level TS with no address type TS's and have things make sense. Maybe better to say this TS MUST be combined with an address type selector? (That statement might go in section 3.) nits: 2.2: Typo? "(with deemed the Security Label optional)" s/with/which/ ? 2/3: I wasn't entirely clear what's meant by "optional" - it doesn't seem to map to a protocol flag or simiilar but to whether or not an implementation chooses to emit one of these TS's - is that right? If so, it could maybe be clearer. 3: the SHOULD level fallback to a new child SA without the label seems a bit odd for a MAC system - is that really the right choice? (I'll believe you if you say "yes," so just asking in case this is an oversight:-) -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
