On Thu, 25 Feb 2016, Tero Kivinen wrote:

It is notify from the server to client. I.e. client sends empty
TIMEOUT_PERIOD_FOR_LIVENESS_CHECK in the CFG_REQUEST and server will
send value in seconds inside its TIMEOUT_PERIOD_FOR_LIVENESS_CHECK in
CFG_REPLY. I.e. the server asks client to use following livenss
timeout period.

Ok, then it should use NOTIFY and not CP.

I think that is bad policy and I think it can be silently be allowed,
but I do not really think we should encourage it.

[ little off-topic. your arguments make sense and I will look at our
  implementation again :) ]

That is my inderstanding what this is. You can go and download the
http://www.3gpp.org/ftp/Specs/html-info/24302.htm and check yourself.

So unless people object I will say "go ahead" in few days.

I would _really_ prefer a 2 page draft that states the problem and
the solution, so that it becomes clear if these are local policy
suggestions or actual configuration requirements the client has to
accept or reject.

If we could even get few paragraph explanation that would be really
good, thats why I said it would be nice if 3gpp people would run their
additions through this list before writing it in their draft.

Now I have to check that 116 page document and find out what it is
supposed to do :-)

So this is a real problem. If we (implementors) want to implement these
IKEv2 extensions, we need to have clear proper RFC's. I do not want to
find 116 pages on third party websites (that may or may not be behind
a registration or pay wall)

Yes. The IKEv2 registries are filling up with non-ikev2 entries. It
would really make sense to run this through the working group. I'll
bring this issue up in the TEG/TLC next week.

What is TEG/TLC?

https://www.icann.org/resources/pages/tlg-73-2012-02-25-en

It is a liaison group for the ICANN board consisting of various groups
including ETSI, ITU, W3C and IETF. While this does not relate directly
to ICANN (names/dns), it does have the right people there to talk about
this kind of issue.

Paul

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to