The last DISCUSS on draft-ietf-btns-connection-latching-10 concerns what the WG thinks is the best way for ULPs to handle connection latch transitions to the BROKEN state in the _absence_ of connection latching APIs for applications (or when apps are not aware of such APIs). The two options are: a) The ULP MAY/SHOULD/MUST pretend that the equivalent of a TCP reset occurred and the connection latch is transition to the CLOSED state (and destroyed/cleaned up); b) The ULP MAY/SHOULD/MUST act as though bits aren't moving and let ULP and/or application-layer timeout processing decide if and when to close the connection (and underlying connection latch). (b) means potentially hanging forever, but that's generally true now with existing ULPs. The I-D says (b), with "SHOULD". I'd be just as happy with (a), SHOULD, (b) MAY. I would not be happy with (a), MUST, nor with (b), MUST. Comments? Nico --
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.