Yoav Nir writes:
> IKEv2 has an underlying assumption that peers are always available
> to respond (for example to liveness check).
Can you point me to that in RFC5996, I think I might have missed that.
I am under the understanding that either end of the IKEv2 protocol can
crash/shutdown/go silent
Hi Tero.
IKEv2 has an underlying assumption that peers are always available to respond
(for example to liveness check). If you're doing a special profile for minimal
implementation that are not always available (because they're in a low-power
mode), you should also profile the server that talks
Yoav Nir writes:
> There are two things I'm wondering about, though. Why is this draft
> written like a mini-RFC5996, instead of just referencing 5996 and
> describing a profile. You could skip all of Appendix A and much of
> the explanation in section 2.
One of the reasons is that I wanted the do
Shoichi Sakane writes:
> This draft describes a scenario to use IKEv2 for a minimum specification.
> The document only allows one side to be a responder.
More correct way is to say, that this document only describes the
node which is always the initiator of the communication.
> I would like to a
I also agree that this draft is useful, and I support its going forward, either
as a WG document or as an individual document.
While data communications may originate from either side (sensor notifies
controller, controller queries sensor, controller sends command to actuator), I
think it is r
I strongly support this draft. It must be useful for the implementers
to develop IKEv2 to enable a kind of m2m communication with IPsec.
This draft describes a scenario to use IKEv2 for a minimum specification.
The document only allows one side to be a responder. I would like to a
little extend
Thanks, Tero. I doubt that this will become a WG item because we are
hoping to shut the WG down after our two current documents are finished.
However, I would encourage people on the list to review the document,
particularly for things that Tero missed that *need* to be in a minimal
implementat
I wrote draft about the minimal IKEv2 implementation. It does not try
to change anything in the RFC5996, it just explains what kind of
implementation would be useful in some machine to machine
communication scenarios and which would still be complient to the
RFC5996 (with an exception of not suppor
