Last Call Review of draft-ietf-ipsecme-labeled-ipsec-09
review-ietf-ipsecme-labeled-ipsec-09-secdir-lc-farrell-2023-04-04-00

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:-)