Reviewer: Dave Thaler Review result: Ready with Issues I am an assigned INT directorate reviewer for draft-ietf-dots-multihoming-12. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see https://datatracker.ietf.org/group/intdir/about/ Technical comments potentially worth a discuss: * Section 4.2: multiple PVDs is not synonymous with distinct administrative entities, as evidenced by section 4.1, so would recommend: OLD: That router is connected to multiple provisioning domains (i.e., OLD: managed by distinct administrative entities). NEW: That router is connected to multiple provisioning domains NEW: managed by distinct administrative entities. * Section 5.2: > when PI addresses/prefixes are assigned and absent any > policy, the client-domain DOTS gateway MUST send mitigation requests > to all its DOTS servers. Otherwise, the attack traffic may still be > delivered via the ISP which hasn't received the mitigation request. If RPF checks are applied by policy to all inbound traffic, then I think the attack could only come via a PVD that advertises to the client domain prefixes covering the attack sources. In that case the MUST might be too strong if no attack is coming from one of the PVDs (e.g., an IPv6-only PVD). Do we really want to require sending it to such networks? Section 5.2: > The use of anycast > addresses to reach these DOTS servers is NOT RECOMMENDED. If a well- > known anycast address is used to reach multiple DOTS servers, the CPE > may not be able to select the appropriate provisioning domain to > which the mitigation request should be forwarded. As a consequence, > the request may not be forwarded to the appropriate DOTS server. If each PVD uses a different anycast address for their own DOTS servers, is there still a problem? If so, can the document explain what is the problem? The current text only seems to explain the case when the same anycast address is used by different PVDs but the statement above about NOT RECOMMENDED is not currently constrained to that case. * Section 5.3: > Note that anycast addresses cannot be > used to establish DOTS sessions between DOTS clients and client- > domain DOTS gateways because only one DOTS gateway will receive the > mitigation request. I wonder if this is too strongly worded. I suspect you mean that G1 and G2 cannot use the same anycast address. But if G1 and G1' both use the same anycast address for redundancy in that topological location, is there a problem? In contrast, I observe that the last paragraph of this section says only "NOT RECOMMENDED", not "MUST NOT". Editorial nits: * Section 3: in the two definitions, either remove "are" after the colon or remove the colon so they're either sentences or definitions, not a weird mix. * Section 3: re "Provider-Independent (PI) addresses: are globally-unique addresses which are not assigned by a transit provider". Change "which" to "that" per Chicago Manual of Style ("which" and "that" have the same meaning in British English but slightly different meanings in American English) * Section 5.1: "DOTS signaling session to a given DOTS server must be established using the interface from which the DOTS server was provisioned." Grammar: insert "A" at the start of the sentence * Section 5.2: typo "One of more DOTS clients", s/of/or/ * Section 5.2: s/an unicast/a unicast/ * Section 5.2: "the attack traffic may still be delivered via the ISP which hasn't received the mitigation request", s/which/that/ Dave Thaler -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
