Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt]

[Lou Berger <[e-mail]>]

Thanks Valery.  Based on the subsequent discussions, I suspect it may be 
best to just drop the whole section/capability.  So much for postel's law...

Lou

On 10/14/2020 2:26 AM, Valery Smyslov wrote:
>
> Hi Lou,
>
> Valery,
>
> >    If IKE is used to negotiate using IP-TFS, then such switching 
> MUST NOT take place.
>
> I read this added line as saying you can switch from tunnel to TFS, I 
> think you mean that use of TFS is controlled via IKE.  How about?
>
>    If IKE is used to negotiate using IP-TFS, then use of
>    TFS is controlled per Section 5.1.
>               I think the text is still a bit ambiguous,  since 
> previous sentence uses a normative SHOULD
>               to support switching from tunnel to IPTFS and the 
> proposed text doesn’t forbid this
>               behavior explicitly if IKE is used. I’d like to see more 
> explicit language for IKE case.
>               How about:
>    If IKE is used to negotiate using IP-TFS, then use of
>    TFS is controlled per Section 5.1, and thus the option of switching
>    to IP-TFS receive-side operation on receipt of the first IP-TFS payload
>    MUST NOT be used.
>               Feel free to change the text keeping its sense...
>               Regards,
>               Valery.
>
> Lou
>
> On 10/13/2020 10:37 AM, Valery Smyslov wrote:
>
>     Valery,
>
>     How about this:
>
>     OLD
>        Receive-side operation of IP-TFS does not require any per-SA
>        configuration on the receiver; as such, an IP-TFS implementation
>        SHOULD support the option of switching to IP-TFS receive-side
>        operation on receipt of the first IP-TFS payload.
>
>     NEW
>        Receive-side operation of IP-TFS does not require any per-SA
>        configuration on the receiver; as such, for tunnels created
>        without IKE, an IP-TFS implementation
>        SHOULD support the option of switching to IP-TFS receive-side
>        operation on receipt of the first IP-TFS payload for tunnels.
>
>     I can live with MAY, but would prefer SHOULD.
>
>     Does this work for you?
>
>     Yes, with the following addition.
>
>        Receive-side operation of IP-TFS does not require any per-SA
>
>        configuration on the receiver; as such, for tunnels created
>
>        without IKE, an IP-TFS implementation
>
>        SHOULD support the option of switching to IP-TFS receive-side
>
>        operation on receipt of the first IP-TFS payload for tunnels.
>
>        If IKE is used to negotiate using IP-TFS, then such switching
>
>        MUST NOT take place.
>
>                   With this addition I don’t mind having SHOULD for
>     ike-less case.
>
>                   Regards,
>
>                   Valery.
>
>     Lou
>
>     On 10/13/2020 10:06 AM, Valery Smyslov wrote:
>
>             I can live with MAY.
>
>         OK, but it must be negotiable in any case if you plan to use it with IKE.
>
>         Otherwise we'll get black holes.
>
>           
>
>             On 10/13/2020 9:16 AM, Valery Smyslov wrote:
>
>                 If you badly need this feature, then please make it MAY and negotiable,
>
>                 so that people can ignore it. SHOULD is too strong for it,
>
>                 leaving it non-negotiable is just unacceptable, IMHO.
>
>           
>
>         _______________________________________________
>
>         IPsec mailing list
>
>         [e-mail]  <mailto:[e-mail]>
>
>         https://www.ietf.org/mailman/listinfo/ipsec
>
>           
>
>
>
>     _______________________________________________
>
>     IPsec mailing list
>
>     [e-mail]  <mailto:[e-mail]>
>
>     https://www.ietf.org/mailman/listinfo/ipsec
>