Multihoming Deployment Considerations for DDoS Open Threat Signaling (DOTS)
draft-ietf-dots-multihoming-13

Understood that the multihoming is talking about the edge router itself and not hosts within the next.

Agreed this is simpler and not necessary to complicate the document.

Thanks.

Thanks for working on this specification. Thanks to Mirja Kuhlewind for the TSVART review.

I agree with the my fellow TSV AD and TSVART reviewer that no TSV related issue is found in this specification.

Thank you for the work put into this document: it is short, easy to read.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Valery Smyslov for the shepherd's write-up including the WG consensus (including "not too many reviews") *BUT* it lacks the justification of the intended status. 

Authors may also expect an internet directorate review by Dave Thaler, the delay in the review (caused by late addition of this document to the telechat agenda) should not hinder the publication process though.

I also second Erik Kline's DISCUSS about source address selection.

I hope that this helps to improve the document,

Regards,

-éric

Note for the shepherding AD: missing consensus boilerplate.

## Section 4.2

Suggest to state the obvious in bullet 2, i.e., that addresses from one PvD is used when communicating over this PvD (to be symmetric with bullet 1). This is purely cosmetic.

## Section 4.3

Another cosmetic suggestion: please use CPE1 and CPE2, again for symmetry.

## Section 5.1

I am always uneasy when I read normative MUST / SHOULD in an informational document but the authors may ignore this comment.

There is a "SHOULD use the certificate" without specifying when the SHOULD does not apply. 

## Section 5.2

Another cosmetic comment, the graphical convention of figures 7 & 8 (i.e., having the DOTS clients in a central dotted box) should also be used in figure 6.

Section 4, paragraph 1, comment:
> 4.  Multi-Homing Scenarios

I'm surprised to not see this section referring to any of the MULTI6 documents.
It's been a while since I read them, but IIRC, they dealt with many of these
scenarios and gave similar recommendations.

The datatracker state does not indicate whether the consensus boilerplate
should be included in this document.

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "blindly"; alternatives might be "visually impaired", "unmindful of",
   "unconcerned about", "negligent of", "unaware", "uncomprehending",
   "unaware", "uncritical", "unthinking", "hasty", "blocked", "opaque"

Thanks to Mirja Kuhlewind for the TSVART review.

There is nothing at all wrong with this document, but it is not what I expected. IIUC DOTS will often have different interfaces for its DOTS channel and the "data plane" where DoS attacks come in. I had thought the multihoming reference would refer to that, but it does not.

Hi,

Thanks for this document.

Two comments on section 5.1:

1.
   The DOTS client MUST resolve the DOTS server's name provided by each
   provisioning domain using either the DNS servers learned from the
   respective provisioning domain or from the DNS servers associated
   with the interface(s) for which a DOTS server was explicitly
   configured (Section 4).

It wasn't clear to me why the DNS lookup MUST be done relative to each provisioning domain?

2.
   DOTS signaling
   session to a given DOTS server must be established using the
   interface from which the DOTS server was provisioned.

If I have read and understood the draft correctly that it also seems that requests to ask a DOTS server to mitigate an attack must also be done on the same interface on which that attack is occurring.  Is my understanding correct, and if so, why is this a requirement?  I.e., communicating to a DOTS server via a separate link that isn't under attack would seem to be beneficial (when that is possible).  Is the reasoning here that these are stub networks and hence will only be routable via the interface provided by the ISP's gateway?

Regards,
Rob