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
IPsec@ietf.org <mailto:IPsec@ietf.org>
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
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
