In the DOTS signal channel draft, if two mitigation requests have overlapping mitigations scopes, then the overlapped lower number mitigation-id is automatically deleted by the DOTS server.
Jon’s DOTS server implementation uses the above approach but Kaname’s implementation maintains both the mitigation requests, and the DOTS server automatically falls back to use the lower number mitigation-id after the higher number mitigation-id is deleted by the DOTS client. The disadvantage of the latter approach is, the DOTS server and client could end-up maintaining a long list of overlapping mitigation requests and looks error-prone.
Based on the discussions in DOTS WG session at IETF-100, the draft has been updated to handle overlapping mitigation requests from a DOTS client and the rationale for the low mitigation-id deletion.
In the DOTS signal channel draft, if two mitigation requests have overlapping mitigations scopes, then the overlapped lower number mitigation-id is automatically deleted by the DOTS server.
Jon’s DOTS server implementation uses the above approach but Kaname’s implementation maintains both the mitigation requests, and the DOTS server automatically falls back to use the lower number mitigation-id after the higher number mitigation-id is deleted by the DOTS client. The disadvantage of the latter approach is, the DOTS server and client could end-up maintaining a long list of overlapping mitigation requests and looks error-prone.
This issue is raised in the virtual interim meeting https://datatracker.ietf.org/meeting/interim-2017-dots-03/materials/minutes-interim-2017-dots-03-201710021000/.