I have reviewed draft-ietf-dots-multihoming-09 for on behalf of the operations and and management area directorate. While I think this document is largely complete, I have a couple of questions ab out the ways in which is proposes to implment the various cases which may or may not add clarity to the document. It would seem that the chief difference between the residential CPE case and the enterprise case would seem to be the intercession of BGP, Who manages the CPE from the vantage point of configuration, In practice I don't see a meaningful difference between a single CPE and multiple CPEs in the enterprise case (5.2/5.3), source address selection is a coordination problem in either case? but in fact that's mostly a coordination problem. selecting the path to the dots server(s) can be achieved via route selection if no mechanism for signaling routes between CPEs that seems like a serious limitation. In a multihoming scenario involving a provider assigned prefix the prefix may well be both deaggrated for a large provider assignment and advertised to both providers (e.g. I have an office which receives a /24 assignment from lumen and also advertises that self same prefix to zayo), in this case the prefix must be advertised de-aggregated to both providers. enterprise pa assignments of this form are necessarily equivalent to pi prefixes from a usage standpoint. which ip is used for dots signaling in cases like this is necessarily a problem of coordination whether it be the cpe/router peer interface, router loopback, or some other source ip enclosed within the assigned prefix (or indeed some other prefix). > When PI addresses/prefixes are used, DOTS clients MUST contact all the DOTS gateways to send a DOTS message. When engaged in DOS related signaling not all dos attacks are in fact distributed, when attack traffic is unspoffed as it is in most upper layer targeting attacks it must necessarily follow a consistent path per attacker, moreover, your telemetry may well tell you which ingress interface and therefore provider needs to receive which signaling sending them to un-impacted providers unnecessary and may result in unintentional information leakage. > The use of anycast addresses is NOT RECOMMENDED to reach DOTS gateways. provider specific anycasts do not in principle seem worse then provider specific unicasts, they allow a provider reduce the ammount of coordination required within their own infrastructure. assigning a well know anycast for this purpose among all providers on the other hand sounds like a terrible idea, for the reasons that well known-anycasts are generally bad.