On Tue, 31 Jan 2023, Valery Smyslov wrote:
The WG thought this would be a worse solution.
This could be solved by adding only two new TS types
TS_IPV4_ADDR_RANGE_WITH_CONSTRAINTS and TS_IPV6_ADDR_RANGE_WITH_CONSTRAINTS
with a format that allows to add new constraints to the Traffic Selector.
Valery Smyslov writes:
> 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
> >
Hi Paul,
> > 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.
>
> The fear of combinatory explosion if something else
On Tue, 31 Jan 2023, Valery Smyslov wrote:
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
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
Paul Wouters writes:
> On Fri, Sep 23, 2022 at 1:15 PM Paul Wouters wrote:
>
> On Mon, Jul 25, 2022 at 10:24 PM Tero Kivinen wrote:
>
> Labeled IPsec is ready for publication and
> will be submitted to the IESG immediately after this IETF.
>
> This has still not
