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.

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

    IPsec@ietf.org  <mailto:IPsec@ietf.org>

    https://www.ietf.org/mailman/listinfo/ipsec


_______________________________________________
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

Reply via email to