On 04.02.23 08:57, Alexander Clouter wrote:
I agree on both points, Result TLV should be final and is easy to explain to others.
It may be easy, but I don't think it's quite right.To me, the way to look at this is that when a Result TLV is transmitted by the server, it is a signal that the server has no more requirements of the peer, and if it is transmitted by the peer, then it is a signal that the peer has no more requirements of the server.
So it is possible that there is more work to do if one side isn't finished. And this is important to recognize because Result-TLVs can be piggybacked on Intermediate-Result-TLVs, if we believe C.3 in 7170. Also, see C.9.
In particular, because either side may send a Request-Action frame, one side may not know when it REALLY is finished. EAP-Success an only occur when the server has sent its last Result TLV and has seen the client's Result TLV. And the client can only expect a completed state when the server has sent a Result TLV and the client has not sent anything after its last Result TLV.
So for example, if a server has no demands of a client in normal operating state, it might immediately send (under our current draft) an Intermediate-Result with CB Request and Result. But then the peer sends back a PKCS#10 request because it wants to renew its cert earlier than the server may want it to. The server will need to send another Result TLV eventually.
I don't think that behavior should be proscribed. Eliot
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
