Reviewer: Robert Sparks Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-dots-requirements-16 Reviewer: Robert Sparks Review Date: 2018-11-14 IETF LC End Date: 2018-11-23 IESG Telechat date: Not scheduled for a telechat Summary: Ready for publication as an Informational RFC, but with nits to consider before publication Biggest Nit: In DM-004, you point to SIG-007 where you mean to point to SIG-008. The rest of the internal references should be inspected to make sure they haven't drifted as the document evolved. The rest are all really small polishing nits: Nits: Section 1.1 third paragraph, second sentence: This sentence doesn't scan well (the page break in -16 may hide that). Eliding words to highlight the issue in the structure : "Such ... interfaces tie ... while also limiting ...". One possible adjustment would be "Such proprietary interfaces tie a subscriber to a service and limit the abilities of network elements that would otherwise be capable of participating in attack mitigation". That said, the paragraph is just as effective if you simply delete the sentence. Section 1.2, definition of "DOTS gateway". This description does not admit the notion of an aggregating gateway as described in the architecture document. As this is the _definition_ the architecture document points to, and is being published as part of an introduction to DOTS, it should be adjusted. Section 2 paragraph 2: This paragraph is written as a description of protocols that already exist instead of as requirements. The rest of the section uses more of a requirements framing. Section 2.1, GEN-001: "operational and proprietary" scans oddly. almost an apples and oranges kind of mismatch. There are operational defenses that are proprietary. Paragraph 3 of SEC-002: This paragraph doesn't read as sensibly when you have the pictures of aggregating gateways from the architecture document in mind. Does it constrain the types of connections that can be aggregated to those that share equivalent security properties? If so, it should be explicit. DM-007 implies that the ability for a client to express acceptable loss is described in GEN-002. GEN-002 is only a requirement about resiliency - it mentions resiliency against loss, but is silent about acceptable loss, so it's not clear what the "as described in" in this requirement is really pointing to. It is unclear what DM-009 is trying to constrain/accomplish. I think it is trying to say you MUST NOT bake _assumptions_ about specific characteristics of any given transport into the data model, but instead, you must model them explicitly. Please adjust the requirement to clarify. MicroNits: Section 1.1 first paragraph: "networks of all kinds" overreaches as written. There are networks (isolated LANs for example) that are not so afflictable. Section 1.2, definition of "DDoS attack target": The phrase "with a finite set of resources, such as network bandwidth, memory, or CPU," is unnecessary. All network connected entities have finite resources. I suggest deleting the phrase. If you really want to retain it, say something like "more constrained than some other actor". Section 1.2, definition of "DOTS signal": "concise" is unnecessary in the definition, and comes off as solution rather than requirement. You already do a good job of motivating the need for parsimonious message sizes in the requirements part of the document.
