[Dots] Feedback on draft-nishizuka-dots-inter-domain-mechanism-01

["Roman D. Danyliw" <[e-mail]>]

Hello WG!

WG chair hat off ...

In reading through draft-nishizuka-dots-inter-domain-mechanism-01 I have the following feedback:

(1) When an updated use case document is released, I'd recommend removing Section 3 and 4 and focus this document on describing only the protocol

(2) I recommend including language somewhere in the draft describing which set of use cases in the WG UC draft are satisfied.  Currently Section 3-4 describe candidate use cases, but what about the other uses cases currently in the WG UC document?

(3) Section 5, I recommend citing the references to HTTPS and TLS

(4) Section 5, Provisioning stage, "A DOTS client should register itself to the DOTS server, as well as enable capacity building in advance." In the context of DOTS, what protocol support is expected to "enable capacity building in advance"?

(5) Section 5.1.1, customer_name, How should this name be generated?

(6) Section 5.1.1, ip_version, To what traffic does this version number refer?

(7) Section 5.1.1, BGP_route, countermeasures, tunnel_information, next_hop, What is the format of this field?

(8) Section 5.1.1., SIP_URI and E164_number, I would recommend citing the reference.

(9) Section 5.1.1, protected_ports, To clarify, is this the subset of ports possible to enumerate in future mitigation requests?

(10) Section 5.1.1, whitelist and blacklist, I would recommend being explicit on what the DOTS server is supposed to do with this list.

(11) Section 5.1.1, How is a registration request rejection signaled? 

(12) When is the Heartbeat message sent

(13) I recommend adding the version field used in the messages in 5.2.1 to the provisioning messages in 5.1.1.

(14) Section 5.2.1, DST_IP is used in the definition of multiple fields but is not defined.  Is this field the same as dst_ip from packet_header?

(15) Section 5.2.1, max_bandwidth, What is meant by the "max bandwidth the DOTS client can undertake"?  Could you please clarify the semantics of this field.

(16) Section 5.2.1, packet_header, This field is defined a "IP packet header contents used for a report".  What report is this definition referencing?

(17) Section 5.2.1, current_throughputs, What does it mean to have multiple CSV separated values in this field?

(18) Section 5.2.1, health, Is there a standardized way to calculate this value?  Is it pre-negotiated, out-of-band, between client/server?

(19) Section 5.2.1, payload, Should this be in the signal channel or the data channel?

(20) Section 5.2.1, hash, Is this hash calculated on the complete payload or the truncated value per the offset field?

Roman