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

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 10 Feb 2016 04:35:18 +0000

Hi Roman,

Thanks for the comments. We have updated the draft https://tools.ietf.org/html/draft-reddy-dots-transport-02 to address all your comments, Please have a look. See inline

> -----Original Message-----
> From: Dots [mailto:[email-masked]] On Behalf Of Roman D. Danyliw
> Sent: Saturday, October 31, 2015 6:31 AM
> To: [email-masked]
> Subject: [Dots] draft-reddy-dots-transport-01 questions/comments
> 
> 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 ?

Yes, it's discussed in the last paragraph of this section that DOTS client can directly talk to the DOTS server.

-Tiru

> 
> ** 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
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots