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

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 3 Aug 2016 14:53:20 +0000

Hi Roman,

Thanks for the review. Please see inline for responses.

> -----Original Message-----
> From: Dots [mailto:[email-masked]] On Behalf Of Roman D. Danyliw
> Sent: Monday, July 18, 2016 6:33 PM
> To: [email-masked]
> Subject: [Dots] Feedback on draft-reddy-dots-transport-05
> 
> 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.

Sure, will update.

> 
> (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.

Agreed (this draft was written before architecture draft). 
Removed enumerated list under paragraph two and referred to UC and architecture documents.

> 
> (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/

Will update draft to address all the above comments.

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

Yes.

> 
> (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.

Changed to Integer.

> 
> (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.

Yes, will formally specify formats for IP addresses, prefixes and ports.

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

Empty Acknowledgement is defined in CoAP, added reference.

> 
> (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/.

Fixed above comments.

> 
> (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.

Agreed, will update.

-Tiru

> 
> Roman
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots