Hi Tero, few comments inline.
[a lot of text snipped] > This document should simply say that TS_SECLABEL MUST NOT be used > alone. This document must not try to do incompatible change to the > base RFC7296 which would make conforming implemntations > non-conforming. Unfortunately, this won't work. It is not enough to add new TS type, with security labels the semantics of TS types should be changed so, that there are "primary" TS types and "additional" ones. This is because in RFC 7296 individual Traffic Selectors in TS payload are combined with OR. In other words, traffic matching combination of any Traffic Selector in TSi and any Traffic Selector in TSr is protected. TS_SECLABEL cannot be treated with this semantics, it must be treated with AND (as additional condition for the traffic to match), which requires RFC 7296 update. I agree with you that current document text doesn't take into considerations the existence of other "primary" TS types, like TS_FC_ADDR_RANGE. > So I do not think this document should update RFC7296 at all, so most > of the section 3 is wrong. The "proper" way would be to introduce new TS types TS_IPV4_ADDR_RANGE_WITH_SECLABEL and TS_IPV6_ADDR_RANGE_WITH_SECLABEL. I recall that it was already tried before, but I don't remember why this way was abandoned. Regards, Valery. > -- > kivi...@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
