Subject: [Dots] draft-reddy-dots-transport-01 questions/comments

From: "Roman D. Danyliw" <[email-masked]>
Date: Sat, 31 Oct 2015 01:01:13 +0000

Hello Tiru, Dan, Prashanth, Mike, Mohamed and Robert!

[Note: This entire message is written as an individual contributor.  Chair hat off]

In reading draft-reddy-dots-transport-01, I had a few questions and comments.  Given that this is an early -01 draft, I readily acknowledge that it might be premature to broach them so please defer as necessary.

** Page 5, Section 4.1.1: policy-id: "This identifier must be unique for each policy bound to the DOTS client."
I had difficulty understanding what this sentence meant.  Is this uniqueness property the same as saying that (a) every distinct SOS request needs a unique policy-id? (b) this policy-id needs to be unique relative to the active requests with the DOTS server?  The text clearly states that the "document does not make assumption about this identifier is generated" but are any assumptions made about the state kept?

** Page 5, Section 4.1.1: target-ip and target-port: Each of these fields can take a list.  What is the format of that list?  Figure 7 for example suggests that ranges are possible (e.g., 1-65535).

** Section 4 presents a RESTful API.  However, the current text only describes the request.  What do responses look like?  Does the client get back a 200 code on success?  What does the server return when an unrecognized policy-id is passed when trying to retrieve the active SOSes?  How are unrecognized fields treated?  

** Page 6, Section 4.1.1: Signal SOS: "... thus sending a maximum of 500 bytes of SOS message ..."
What happens if the SOS message needs to be more than 500 bytes?  Perhaps the request has a really long URL and a number of individual IP addresses that aren't aggregated.  Does the request then need to be split into separate SOS messages?

** Page 6, Section 4.1.1: Signal SOS: How should multiple instances of any of the fields be parsed (e.g., multiple target-ip or policy-id)?

** Page 7, Section 4.1.2: Retrieving SOS: What does a response look like when retrieving a specific SOS?  Is it an HTTP response with the body of the JSON that made the request?  

** Page 7, Section 4.1.2: Retrieving SOS: What does the response for all SOS look like?  In what order are they returned?

** Page 7, Section 4.2: REST: This introductory section explicitly references a DOTS client, relay and server.  Can there just be a client talking to the server?

** Page 8, Section 4.2.1.1: Install filtering rules: Are any of the described fields are optional?

** Page 9, Section 4.2.1.1: lifetime: "Upon expiry of this lifetime, and if the request is not reiterated, the rule will be withdrawn ..."
How is a request reiterated?  Just resend the same message?  

** Page 9, Section 4.2.1.1: lifetime: What happens if a message is "reiterated" without being expired.  For example:
Send: (time=0; policy-id=1; lifetime=100)
Send: (time=10; policy-id=1; lifetime=100)

At time=10 what is the value of the lifetime counter for policy-id=1?  Is it 90? Or 90+100?

Regards,
Roman