Hi Christian (,Rob):
Thanks again for this conversation. Please see our comments inline.
>>
>> As a consequence, the resolution was to move forward with a pragmatic
>> approach at this point of time, by changing the names of the modules (and
>> prefixes) to refer to the I2NSF work.
>
> These
This is great news, Thanks!
IMO (Rob feel free to chime in here :) I don't think you need to say anything
more about the feature in your document (other than what was already
mentioned). This is the standard "outside the scope of this document" kind of
thing. It's enough to put that text that s
On Wed, 14 Oct 2020, Christian Hopps wrote:
I really don't understand the extreme back pressure against using ESP the way
it was designed. The next-header field is supposed to identify the payload, it
does so for every other
payload ESP carries. Any other solution to somehow infer the payload
Christian Hopps writes:
> I really don't understand the extreme back pressure against using
> ESP the way it was designed. The next-header field is supposed to
> identify the payload, it does so for every other payload ESP
> carries. Any other solution to somehow infer the payload type some
> other
Hi Paul,
My comment was only about using the next header field in ESP to identify the
ESP payload. I believe we've already agreed to remove the zero-conf section as
too controversial.
Tero, is suggesting that we should not use the next header field at all. That
is what I don't understand.
Tha
Hi Tero,
We are defining the payload in this document, the payload is meant for ESP. ESP
has a payload identifier why can't we use it? It feels like the clean KISS
solution to me. Yes, we are doing IKE negotiation, but using the designed for
payload identifier also allows the payload to be iden
Christian Hopps writes:
> > Earlier there was also another encapsuluation mode called a Bound
> > End-to-End Tunnel (BEET) mode for ESP [1] that was also proposed, and
> > in that case it would have been impossible to detect the mode from the
> > incoming packet, as lots of the information needed t
Christian Hopps writes:
> We are defining the payload in this document, the payload is meant
> for ESP. ESP has a payload identifier why can't we use it?
If that is only possible value the next-header field can have as all
packets of the Child SA which has been negotiated with USE_IPTFS then
what
> On Oct 15, 2020, at 4:48 PM, Tero Kivinen wrote:
>
> Christian Hopps writes:
>> We are defining the payload in this document, the payload is meant
>> for ESP. ESP has a payload identifier why can't we use it?
>
> If that is only possible value the next-header field can have as all
> packets
