[Gen-art] Genart last call review of draft-ietf-dots-requirements-16

[Robert Sparks <[e-mail]>]

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.