Re: [IPsec] Preliminary minutes for the IPsecME meeting

> > The RFCs are always being published in serial :-)
> 
> We have clusters :)

That's not a problem, cluster members are well aware of each other :-)

> > So, my idea that every new application RFC must define its relative
> > order in regard to all already published application RFCs
> > and whether piggybacking with each of them is allowed.
> 
> Joking aside, I do feel it is important that the intermediate exchange
> is a general concept, and should have the least amounts of hooks and
> order of payloads or what not. I do not think it is a good idea to
> insist on building a linked list of RFCs/payloads. The generic model of
> IKE is payloads can be in any order. And if a payload won't fit in the
> first intermediary exchange, it should be able to send it in the next
> one without knowing anything about the other things going on.

I don't like this, as this complicates responder's state machine.
The responder should know what it would receive next 
(with some flexibility, of course). So, if initiator splits payload
into several exchange, the responder must be prepared to this,
so it must be stated in some application draft whether splitting this particular
payload over several exchanges is OK and under what conditions.

> Of course, there are exceptions, such as if we need QSKE before our new
> imaginary payloads, but than those payloads might belong better in
> IKE_AUTH.

So, you still have to have some exceptions?

I don't think we disagree in general. I'd only rather to avoid anarchy 
as much as possible. It doesn't mean that the order of intermediates
must be fixed, it just must be specified what is OK and what isn't. 
So, if for some application it doesn't matter whether its data is sent first or last, 
it must be stated so. If for other the order is important, it also must be stated.
If neither of published (so far) RFCs specifies ordering, you can 
perform exchanges in any order (as in your dream), if some specify, their order
must be honored.

Regards,
Valery.

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