Subject: [Dots] Feedback on draft-reddy-dots-transport-05

From: "Roman D. Danyliw" <[email-masked]>
Date: Mon, 18 Jul 2016 13:03:00 +0000

Hello!

WG chair hat off ...

In reading through draft-reddy-dots-transport-05 I have the following feedback:

(1) I'd recommend including language somewhere in the draft describing which set of use cases in the WG UC draft are satisfied.

(2) Section 1, I'd recommend citing the reference to NETCONF.

(3) Section 3, Solution Overview, enumerated list under paragraph two, I worry some of this text overlaps with the UC and architecture documents.  As it is a subset of what these other documents state, a reader might be confused on how many use cases this protocol solves per my comment #1 above.

(4) Section 4, third sentence.  I'd recommend s/The DOTS client must know a DOTS server's domain name/ The DOTS client MUST know a DOTS server's domain name/.

(5) Section 5.1, second from last paragraph.  It's nit.  s/JSON [RFC7159] payloads is/JSON [RFC7159] payloads are/

(6) Section 5.2.1, policy-id, In defining this policy-id, is that the same as a unique request id for each mitigation?

(7) policy-id, Policy-id is defined as a "number".  Should it be "integer"?  Using a floating point number would seem unintuitive to use here.

(8) Section 5.2.1, target-ip, How should multiple IPs be specified?  Could a prefix be used?  Figure 6 helps, but IMO it should be formally specified.

(9) Section 5.2.1, target-port, How should multiple ports be specified? Figure 6 helps, but IMO it should be formally specified.

(10) Section 5.2.1, A reference to an "Empty Acknowledgement" is made.  What is the format of such a message?

(11) Figure 9, There is a typo in the policy-data example, s/target-prtoocol/target-protocol/.

(12) Section 7, I recommend citing the relevant drafts collectively referenced as "(D)TLS RFCs".

(13) Section 7, bullet #2, I recommend s/the DOTS client may want to probe/the DOTS client MAY probe/.

(14) Section 9, IANA Considerations.  I recommend creating IANA registries to maintain the enumerated values of fields like 'status' and 'attack-status'.  This would allow future extensibility.

Roman