Re: [Dots] several comments on draft-ietf-dots-architecture-06:

["Konda, Tirumaleswar Reddy" <[e-mail]>]

Hi Frank,

Thanks for the review. Please see inline [TR]

From: Dots [mailto:[e-mail]] On Behalf Of Xialiang (Frank, Network Integration Technology Research Dept)
Sent: Wednesday, July 11, 2018 3:03 PM
To: [e-mail]
Cc: [e-mail]
Subject: [Dots] several comments on draft-ietf-dots-architecture-06:


CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.


________________________________
Hi draft authors,
I have several comments of this draft as below for your consideration:

1.       Section 1.2, / “so that only authorized clients can invoke the DOTS service” / “so that only authorized clients/servers can invoke/honor the DOTS service”;

[TR] DOTS client is both authenticated and authorized to invoke the DOTS service but the DOTS server is only authenticated by the DOTS client. I don’t see the need to add “server” and “honor” in the above line.



2.       Section 2.2.2, / If a DOTS server refuses a DOTS client’s request for mitigation, the DOTS server SHOULD include the refusal reason in the server signal sent to the client / If a DOTS server refuses a DOTS client’s request for mitigation, the DOTS server MUST include the refusal reason in the server signal sent to the client;

[TR] Agreed, we will update draft.



3.       Section 3.2.3, / "End-customer with a single upstream transit provider offering DDoS mitigation services" described in [I-D.ietf-dots-use-cases] /  "Upstream DDoS Mitigation by an Upstream Internet Transit Provider" described in [I-D.ietf-dots-use-cases];

[TR] Okay, will fix.



4.       Section 3.2.3, you say “For example, the recursing domain’s mitigator should incorporate into mitigation status messages available metrics such as dropped packet or byte counts from the recursed mitigation.”, but this is not described in current DOTS signal channel draft. What’s your opinion about whether we should add the specified content into the signal channel draft?


[TR] DOTS client is conveyed the mitigation metrics (e.g. bytes-dropped, bps-dropped etc.) by the DOTS server. The DOTS client is opaque to the recursion of the originating mitigation request to the secondary DOTS server, hence the signal channel draft does not discuss recursive signaling but explains conveying the mitigation metrics to the DOTS client in Section 4.4.2.


5.       Section 3.3.3, by reviewing the DOTS signal channel draft, my take is a signal session (sid) can carry multiple mitigation-scope requesting conversations (cuid + mid + cdid (optional)), is it right? If so, by saying “a DOTS operator may configure the DOTS session to trigger mitigation when the DOTS server ceases receiving DOTS client signals (or vice versa) beyond the miss count or period permitted by the protocol.”, which mitigation conversation do you mean to trigger, or all of them over the same signal session?

[TR] If the DOTS server creases receiving DOTS client signal, mitigation will be triggered for all the mitigation requests signaled over the same DOTS signal channel session.



Cheers,

-Tiru

Thanks!

B.R.
Frank