Subject: [Dots] DOTS requirements (-01) feedback

From: Flemming Andreasen <[email-masked]>
Date: Wed, 29 Jun 2016 10:38:19 -0400

Hi

I took a closer look at the -01 version of the DOTS requirements, and 
apart from various editorial nits (which I have shared with the authors 
off-list), there are a few of items that warrant further discussion and 
feedback (feel free to break these into more specific threads):

1. DDoS (in DOTS) is not just about network devices and bandwidth but 
about resource constrained devices with network connectivity in general. 
We should make that clear throughout, because it affects our overall 
scope and data model.

1a) A specific example shows up in requirement OP-006, where we talk 
about addresses and prefixes, while on the other hand it does recognize 
that attacked resources may be identified by higher-level naming 
schemes, like SIP-URIs, E.164 numbers etc. It's not clear to me all of 
this is fully vetted and that we in fact always have an address or 
prefix indication - more discussion on this whole area is needed.

1b) Another example is DATA-003 which again is address focused. That may 
be enough, but we should discuss further (e.g. allow for extensibility 
to enable user-based whitelists)

2. Need to get rid of relays and replace with DOTS Gateway. More 
importantly though, we need to consider what requirements we have on 
DOTS Gateways (if any).

3. Inter- and intra-domain shows up, however it's not really clear what 
we mean by that. Maybe this is something the architecture draft should 
clarify, because the requirements draft does seem to assume some level 
of familiarity with the overall architecture.

4. OP-008 talks about conflicting requests to DOTS servers. It's not 
clear if this requires DOTS servers to coordinate with each other, and 
if so, if that applies across administrative boundaries as well. Related 
to that last point, DOTS clients may have relationships with different 
provides (each of which will have DOTS servers), and there doesn't seem 
to be clarity on the requirements associated with that.

5. OP-009: Need to clarify how this caching works and in particular how 
it relates to DNS TTL values.

6. DATA-001 talks about "transactional" transport, however it's not 
clear what the transaction is actually for. Presumably it's for some 
higher-level construct in the "to-be-defined" data model, but it's not 
clear here. I'm also not clear on whether we really need that or 
standard e2e reliable message delivery wouldn't suffice.

7. We need a section with requirements for the overall data model.

8. The congestion control section states the transmission rate will be 
negligible and hence link congestion is not a concern. I think we need 
explicit requirements around that because I'm guessing we will 
ultimately need to have some form of congestion control in place.

Thanks

-- Flemming