On Mon, 9 Jan 2023 at 09:43, Alexander Clouter <alex+i...@coremem.com>
wrote:
Section 4.2.12.5 - PAC-Acknowledgement TLV
>
> Unclear how this should be used, it looks like the peer could be expected
> to send:
>
> PAC TLV[PAC-Acknowledgement]
>
> After reading section 3.8.1 and getting confused, I am wondering now if
> this is actually:
>
> PAC TLV[PAC-Info{carbon copy of server sent TLV}, PAC-Acknowledgement]
>
> This would let the client acknowledge PACs out of order. Though this does
> not help the server side provisioning PACs out of order.
>
Section 3.8.1 has this restriction:
A PAC TLV containing a PAC-Acknowledge attribute MUST be sent by the
peer to acknowledge the receipt of the Tunnel PAC. A PAC TLV
containing a PAC-Acknowledge attribute MUST NOT be used by the peer
to acknowledge the receipt of other types of PACs.
Assuming that only one Tunnel PAC is provisioned by the server, then
out-of-order acks from the peer can't happen.
The problem with this assumption is that I couldn't find a limit for the
number of Tunnel PACs that can be provisioned. I'd say it does not make
sense to provision multiple Tunnel PACs, or does it?
In any case, it seems that PAC-Acknowledge does not cause a problem where
the peer and server have a different understanding of which type PAC was
acknowledged: It's always the Tunnel PAC.
--
Heikki Vatiainen
h...@radiatorsoftware.com
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
