Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-19.txt

From: kaname nishizuka <[email-masked]>
Date: Wed, 2 May 2018 09:49:23 +0900

Hi,

I'd like to ask one clarification question about status code 8:

    o  A notification message with 'status' code set to '8 (Attack
       mitigation is rejected)' and 'conflict-status' set to '1' is sent
       to a DOTS client to indicate that this mitigation request is
       rejected because a conflict is detected.

If a mitigation request is rejected due to a conflict, it is rejected at PUT(4.09(Conflict)), so no resource will be created.
So it looks there is no chance to return '8 (Attack mitigation is rejected)'.

thanks,
Kaname

On 2018/04/10 22:47, [email-masked] wrote:
> Re-,
>
> This version addresses the comments raised during the WGLC, in particular:
> - (Clarification) Indicate that only one hop-limit is included
> - Specify the loop diagnostic payload
> - (Clarification) Indicate explicitly that GET messages with 'sid' are allowed
> - Update the redirect behavior.
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : Dots [mailto:[email-masked]] De la part de internet-
>> [email-masked]
>> Envoyé : mardi 10 avril 2018 15:40
>> À : [email-masked]
>> Cc : [email-masked]
>> Objet : [Dots] I-D Action: draft-ietf-dots-signal-channel-19.txt
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the DDoS Open Threat Signaling WG of the IETF.
>>
>>          Title           : Distributed Denial-of-Service Open Threat Signaling
>> (DOTS) Signal Channel Specification
>>          Authors         : Tirumaleswar Reddy
>>                            Mohamed Boucadair
>>                            Prashanth Patil
>>                            Andrew Mortensen
>>                            Nik Teague
>> 	Filename        : draft-ietf-dots-signal-channel-19.txt
>> 	Pages           : 86
>> 	Date            : 2018-04-10
>>
>> Abstract:
>>     This document specifies the DOTS signal channel, a protocol for
>>     signaling the need for protection against Distributed Denial-of-
>>     Service (DDoS) attacks to a server capable of enabling network
>>     traffic mitigation on behalf of the requesting client.
>>
>>     A companion document defines the DOTS data channel, a separate
>>     reliable communication layer for DOTS management and configuration
>>     purposes.
>>
>> Editorial Note (To be removed by RFC Editor)
>>
>>     Please update these statements with the RFC number to be assigned to
>>     this document:
>>
>>     o  "This version of this YANG module is part of RFC XXXX;"
>>
>>     o  "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling
>>        (DOTS) Signal Channel Specification";
>>
>>     o  "| [RFCXXXX] |"
>>
>>     o  reference: RFC XXXX
>>
>>     Please update TBD statements with the port number to be assigned to
>>     DOTS Signal Channel Protocol.
>>
>>     Also, please update the "revision" date of the YANG module.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-dots-signal-channel-19
>> https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-19
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-channel-19
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> Dots mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dots
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 4 May 2018 08:47:37 +0000

> -----Original Message-----
> From: Dots [mailto:[email-masked]] On Behalf Of kaname nishizuka
> Sent: Wednesday, May 2, 2018 6:19 AM
> To: [email-masked]; [email-masked]
> Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-19.txt
> 
> Hi,
> 
> If a mitigation request is rejected due to a conflict, it is rejected at
> PUT(4.09(Conflict)), so no resource will be created.

Good point. In this case, the resource should be created and the server should return success (2.01 or 2.04) response code 
along with the conflict-information.

-Tiru

> >> [email-masked] Envoyé : mardi 10 avril 2018 15:40 À :
> >> [email-masked] Cc : [email-masked] Objet : [Dots] I-D Action:
> >> draft-ietf-dots-signal-channel-19.txt
> >>
> >>

---

From: <[email-masked]>
Date: Mon, 7 May 2018 06:12:21 +0000

Hi Kaname, 

Please check https://mailarchive.ietf.org/arch/msg/dots/z_cZR9_u273HzC9o0Iy9FeQZ0Jo about the rationale for allowing to return code '8' even in a notification message. The intent was to have code '8' as a transition state. 

Cheers,
Med

> De : kaname nishizuka [mailto:[email-masked]]
> Envoyé : mercredi 2 mai 2018 02:49
> À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
> Objet : Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-19.txt
> 
> Hi,
>

---

From: kaname nishizuka <[email-masked]>
Date: Mon, 7 May 2018 15:19:54 +0900

Hi Med,

I've read the thread.
and the code '8' of the thread is different from the code '8' of the current draft.

they'd been discussing the 7,8 and 9 based on this definition, right?
https://mailarchive.ietf.org/arch/msg/dots/7zljzN8nycZX7E7ghgk1ux32MkM
==
7 | DOTS Server has detected conflicting mitigation requests from different
DOTS clients.  This mitigation request is currently inactive until the
conflicts are resolved. Another mitigation request is active.

8 | DOTS Server has detected conflicting mitigation requests from different
DOTS clients.  This mitigation request is currently active.

9 | DOTS Server has detected conflicting mitigation requests from different
DOTS clients.  All conflicting mitigation requests are inactive.
==

Kaname

---

From: <[email-masked]>
Date: Mon, 7 May 2018 06:37:50 +0000

Re-,

Agree that the codes are not the same, but alternatives ones as summarized here: https://mailarchive.ietf.org/arch/msg/dots/hA3MLKlkXFimpAn5KSYTayaVkjA. 

Cheers,
Med

> Envoyé : lundi 7 mai 2018 08:20
> > Please check
> https://mailarchive.ietf.org/arch/msg/dots/z_cZR9_u273HzC9o0Iy9FeQZ0Jo about
> the rationale for allowing to return code '8' even in a notification message.
> The intent was to have code '8' as a transition state.
> >
> > Cheers,
> > Med
> >

---

From: <[email-masked]>
Date: Wed, 9 May 2018 05:51:22 +0000

Hi Kaname, 

After thinking about this, I do think that you have a valid point. I suggest to make to make this change (marked with ^^^^)

OLD: 
   If the request is conflicting with an existing mitigation request
   from a different DOTS client, and the DOTS server decides to maintain
   the conflicting mitigation request, the DOTS server returns 4.09
   (Conflict) [RFC8132] to the requesting DOTS client.  The response
   includes enough information for a DOTS client to recognize the source
   of the conflict as described below: 

NEW:
   If the request is conflicting with an existing mitigation request
   from a different DOTS client, and the DOTS server decides to maintain
   the conflicting mitigation request, the DOTS server returns 2.01
                                                               ^^^^
   (Created) to the requesting DOTS client.  The response^
   ^^^^^^^^
   includes enough information for a DOTS client to recognize the source
   of the conflict as described below:

Cheers,
Med

> De : Dots [mailto:[email-masked]] De la part de
> [email-masked]
> Envoyé : lundi 7 mai 2018 08:38
> À : kaname nishizuka; [email-masked]
> Agree that the codes are not the same, but alternatives ones as summarized
> here: https://mailarchive.ietf.org/arch/msg/dots/hA3MLKlkXFimpAn5KSYTayaVkjA.
> 
> Cheers,
> Med
> 
> > and the code '8' of the thread is different from the code '8' of the
> current
> > draft.
> >

---

From: kaname nishizuka <[email-masked]>
Date: Wed, 9 May 2018 17:41:10 +0900

Hi Med,

I'm OK with this change.
However, to be precise, I'd like to suggest to state about the case the DOTS server decides NOT to maintain it.

NEW-2:
    If the request is conflicting with an existing mitigation request
    from a different DOTS client, and the DOTS server decides to maintain
    the conflicting mitigation request, the DOTS server returns 2.01
    (Created) to the requesting DOTS client.
    Otherwise, the DOTS server returns 4.09 (Conflict) [RFC8132].
    The response includes enough information for a DOTS client to
    recognize the source of the conflict as described below:

thanks,
Kaname

---

From: <[email-masked]>
Date: Fri, 11 May 2018 06:09:15 +0000

Hi Kaname,

If the server decides not to maintain the conflicting request, then the present request will be processed as normal: that is 2.01 will be returned to ack successful handling. A notification will be sent to the client owner of the conflicting request to notify withdrawal (section 4.4.2). 

The text focuses on the case ", and the DOTS server decides to maintain the conflicting mitigation request" because this is the one which requires additional specification vs. normal request that is accepted by a server.

Cheers,
Med

> Envoyé : mercredi 9 mai 2018 10:41
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : [email-masked]
> > After thinking about this, I do think that you have a valid point. I
> suggest to make to make this change (marked with ^^^^)
> >
> > OLD:
> >> here:
> https://mailarchive.ietf.org/arch/msg/dots/hA3MLKlkXFimpAn5KSYTayaVkjA.
> >>
> >> Cheers,
> >> Med
> >>
> >>>>>>>            Title           : Distributed Denial-of-Service Open
> Threat
> >>>>> Signaling
> >>>>>>>       Please update these statements with the RFC number to be
> assigned
> >>> to
> >>>>>>>       this document:
> >>>>>>>
> >>>>>>>       Please update TBD statements with the port number to be
> assigned
> >> to

---

From: kaname nishizuka <[email-masked]>
Date: Fri, 11 May 2018 17:58:58 +0900

Hi Med,

 > If the server decides not to maintain the conflicting request, then the present request will be processed as normal: that is 2.01 will be returned to ack successful handling. A notification will b…
In that case, the status code is '7' (Attack mitigation is withdrawn)
My original question is when the status code '8' (Attack mitigation is rejected) will be used.

In the text in the draft, "the conflicting mitigation request" is ambiguous whether it is already existing request or the request that just has arrived.

Say, the existing request is (A), then a mitigation request (B) arrived which are conflicting with A.

If B is selected.
(A) will get notification with the withdrawal code '7'
(B) will get 2.01

else If B is not selected.
(B) will get 4.09

Tiru said:
 > In this case, the resource should be created and the server should return success (2.01 or 2.04) response code along with the conflict-information.
In this situation, (B) will get 2.01 or 2.04 along with the rejected code '8'

(Which mitigation request will be selected by the DOTS server is implementation- and deployment-specific.)

Thanks,
Kaname

---

From: <[email-masked]>
Date: Fri, 11 May 2018 09:39:24 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : vendredi 11 mai 2018 10:59
>  > If the server decides not to maintain the conflicting request, then the
> present request will be processed as normal: that is 2.01 will be returned to
> ack successful handling. A notification will be sent to the client owner of
> the conflicting request to notify withdrawal (section 4.4.2).

[Med] Yes, that status will be sent to the owner of the (existing) request.

> My original question is when the status code '8' (Attack mitigation is

[Med] I got that. 

> 
> In the text in the draft, "the conflicting mitigation request" is ambiguous
> whether it is already existing request or the request that just has arrived.

[Med] It is related to the already existing request. 

> (A) will get notification with the withdrawal code '7'

[Med] Yes. The current text does calls out your step (1) in 4.4.2. Your step (2) is not called explicit in the text because there is no confusion about which code to return when a request is accepted to be honored. 

The text focuses on cases which requires specific handling: 
- inactive request because of a conflict
- multiple active conflicting requests

> else If B is not selected.

[Med] In this case, the resource is not created and as such case returning notification status code of 8 is not possible as you rightful pointed out. 
This is why we suggested to return 2.01 for this case too so that an update of the status can be sent to the client upon change. 

> Tiru said:
>  > In this case, the resource should be created and the server should return
> success (2.01 or 2.04) response code along with the conflict-information.
> (Which mitigation request will be selected by the DOTS server is
> implementation- and deployment-specific.)
> 
> Thanks,
> Kaname
> 
> 
> > If the server decides not to maintain the conflicting request, then the
> present request will be processed as normal: that is 2.01 will be returned to
> ack successful handling. A notification will be sent to the client owner of
> the conflicting request to notify withdrawal (section 4.4.2).
> >
> > The text focuses on the case ", and the DOTS server decides to maintain the
> conflicting mitigation request" because this is the one which requires
> additional specification vs. normal request that is accepted by a server.
> >
> > Cheers,
> > Med
> >
> >> However, to be precise, I'd like to suggest to state about the case the
> DOTS
> >> server decides NOT to maintain it.
> >>
> >> NEW-2:
> >>>>>>>           mitigation is rejected)' and 'conflict-status' set to '1'
> is
> >>>> sent
> >>>>>>>> - (Clarification) Indicate explicitly that GET messages with 'sid'
> are
> >>>>>>> allowed
> >>>>>>>>> This draft is a work item of the DDoS Open Threat Signaling WG of
> the
> >>>>>>> IETF.
> >>>>>>>>>        signaling the need for protection against Distributed
> Denial-
> >> of-
> >>>>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-
> channel-
> >>>> 19

---

From: kaname nishizuka <[email-masked]>
Date: Mon, 14 May 2018 18:49:22 +0900

Hi Med,

Please see inline.

thanks,
Kaname

> This is why we suggested to return 2.01 for this case too so that an update of the status can be sent to the client upon change.
I don't think it is needed to obligate returning of 2.01.
If it is obvious that the DOTS server need not to create resource of the conflicting request, it may return 4.09.
So, returning of 4.09 should be allowed in this case.
It should be left as implementation- and deployment-specific.

---

From: <[email-masked]>
Date: Tue, 15 May 2018 13:26:47 +0000

Hi Kaname,

Please see inline.

Cheers,
Med

> Envoyé : lundi 14 mai 2018 11:49
> >> Say, the existing request is (A), then a mitigation request (B) arrived
> which
> >> are conflicting with A.
> >>
> >> If B is selected.
> > [Med] Yes. The current text does calls out your step (1) in 4.4.2. Your
> step (2) is not called explicit in the text because there is no confusion
> about which code to return when a request is accepted to be honored.
> >
> > [Med] In this case, the resource is not created and as such case returning
> notification status code of 8 is not possible as you rightful pointed out.
> > This is why we suggested to return 2.01 for this case too so that an update
> of the status can be sent to the client upon change.

[Med] Do you mean that the text should be modified to allow for both 2.01 or 4.09 to be returned depending on some local policy? 

e.g., 

OLD:

NEW:
   If the request is conflicting with an existing mitigation request
   from a different DOTS client, the DOTS server may return 2.01 (Created)
   or 4.09 (Conflict) to the requesting DOTS client. The response
   includes enough information for a DOTS client to recognize the source
   of the conflict as described below:

> >>>>>>>>>            to a DOTS client to indicate that this mitigation
> request
> >> is
> >>>>>>>>> If a mitigation request is rejected due to a conflict, it is
> rejected
> >>>> at
> >>>>>>>>>>>         This document specifies the DOTS signal channel, a
> protocol
> >> for

---

From: kaname nishizuka <[email-masked]>
Date: Wed, 16 May 2018 10:16:23 +0900

Hi Med,

Please see inline.

thanks,
kaname

>     of the conflict as described below:

Yes, it works for me.

---

From: <[email-masked]>
Date: Wed, 16 May 2018 05:22:15 +0000

Hi Kaname, 

Thank you for ACking. I will implement this change. 

Cheers,
Med

> Envoyé : mercredi 16 mai 2018 03:16
> >>>> present request will be processed as normal: that is 2.01 will be
> returned
> >> to
> > [Med] Do you mean that the text should be modified to allow for both 2.01
> or 4.09 to be returned depending on some local policy?
> >
> > e.g.,
> >
> > OLD:
> >>>> In this situation, (B) will get 2.01 or 2.04 along with the rejected
> code
> >> '8'
> >>>> present request will be processed as normal: that is 2.01 will be
> returned
> >> to
> >>>>>>>>> the rationale for allowing to return code '8' even in a
> notification
> >>>>>>>> message.
> internet-
> >>>>>>>>>>>>>          o  "RFC XXXX: Distributed Denial-of-Service Open
> Threat
> >>>>>> Signaling
> >>>>>>>>>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-
> channel-
> >> 19
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Please note that it may take a couple of minutes from the time
> of
> >>>>>>>>>>> submission

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 16 May 2018 06:10:39 +0000

I propose to update the text as follows to make it more clear:

If the request is conflicting with an existing mitigation request from a different DOTS client, the DOTS server may either decide to maintain the conflicting request or reject the conflicting mitigation request. If the DOTS server decides to maintain
the conflicting mitigation request, the DOTS server returns 2.01 (Created) to the requesting DOTS client. If the DOTS server decides to reject the conflicting mitigation request, the DOTS server returns 4.09 (Conflict) [RFC8132] to the requesting DOTS client
For both 2.01 (Created) and 4.09 (Conflict) responses, the response message includes enough information for a DOTS client to recognize the source of the conflict as described below:

-Tiru

> From: Dots [mailto:[email-masked]] On Behalf Of
> Sent: Wednesday, May 16, 2018 10:52 AM
> To: kaname nishizuka <[email-masked]>
> Cc: [email-masked]
> This email originated from outside of the organization. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
> 
> Hi Kaname,
> 
> > De : kaname nishizuka [mailto:[email-masked]] Envoyé : mercredi 16
> > mai 2018 03:16 À : BOUCADAIR Mohamed IMT/OLN Cc : [email-masked]
> Objet
> > : Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-19.txt
> >
> > Hi Med,
> >
> > Please see inline.
> >
> > thanks,
> > kaname
> >
> > >> De : kaname nishizuka [mailto:[email-masked]] Envoyé : lundi 14
> > >> mai 2018 11:49 À : BOUCADAIR Mohamed IMT/OLN Cc : [email-masked]
> > >>>> De : kaname nishizuka [mailto:[email-masked]] Envoyé : vendredi
> > >>>> 11 mai 2018 10:59 À : BOUCADAIR Mohamed IMT/OLN Cc :
> > >>>> [email-masked] Objet : Re: [Dots] I-D Action:
> > >>>>    > If the server decides not to maintain the conflicting
> > >>>> request, then
> > >> the
> > >>>> ack successful handling. A notification will be sent to the
> > >>>> client owner
> > >> of
> > >>>> My original question is when the status code '8' (Attack
> > >>>> mitigation is
> > >>>> rejected) will be used.
> > >>> [Med] I got that.
> > >>>
> > >>>> whether it is already existing request or the request that just
> > >>>> has
> > >> arrived.
> > >> step (2) is not called explicit in the text because there is no
> > >> confusion about which code to return when a request is accepted to be
> honored.
> > >>> This is why we suggested to return 2.01 for this case too so that
> > >>> an
> > update
> > >> If it is obvious that the DOTS server need not to create resource
> > >> of the conflicting request, it may return 4.09.
> > >>>>    > In this case, the resource should be created and the server
> > >>>> should
> > >> return
> > >>>> ack successful handling. A notification will be sent to the
> > >>>> client owner
> > >> of
> > >>>>> The text focuses on the case ", and the DOTS server decides to
> > >>>>> maintain
> > >> the
> > >>>> conflicting mitigation request" because this is the one which
> > >>>> requires additional specification vs. normal request that is
> > >>>> accepted by a
> > server.
> > >>>>> Cheers,
> > >>>>> Med
> > >>>>>
> > >>>>>> De : kaname nishizuka [mailto:[email-masked]] Envoyé :
> > >>>>>> mercredi 9 mai 2018 10:41 À : BOUCADAIR Mohamed IMT/OLN Cc :
> > >>>>>> [email-masked] Objet : Re: [Dots] I-D Action:
> > >>>>>> However, to be precise, I'd like to suggest to state about the
> > >>>>>> case
> > the
> > >>>> DOTS
> > >>>>>>        If the request is conflicting with an existing
> > >>>>>> mitigation
> > request
> > >>>>>>        from a different DOTS client, and the DOTS server
> > >>>>>> decides to
> > >> maintain
> > >>>>>>        the conflicting mitigation request, the DOTS server
> > >>>>>> returns
> > 2.01
> > >>>>>>>        If the request is conflicting with an existing
> > >>>>>>> mitigation
> > request
> > >>>>>>>        from a different DOTS client, and the DOTS server
> > >>>>>>> decides to
> > >>>> maintain
> > >>>>>>>        the conflicting mitigation request, the DOTS server
> > >>>>>>> returns
> > 4.09
> > >>>>>>>        (Conflict) [RFC8132] to the requesting DOTS client.
> > >>>>>>> The
> > response
> > >>>>>>>        includes enough information for a DOTS client to
> > >>>>>>> recognize the
> > >>>> source
> > >>>>>>>        If the request is conflicting with an existing
> > >>>>>>> mitigation
> > request
> > >>>>>>>        from a different DOTS client, and the DOTS server
> > >>>>>>> decides to
> > >>>> maintain
> > >>>>>>>        the conflicting mitigation request, the DOTS server
> > >>>>>>> returns
> > 2.01
> > >>>>>>>
> > ^^^^
> > >>>>>>>        includes enough information for a DOTS client to
> > >>>>>>> recognize the
> > >>>> source
> > >>>>>>>> [email-masked] Envoyé : lundi 7 mai 2018
> 08:38
> > >>>>>>>> À : kaname nishizuka; [email-masked] Objet : Re: [Dots] I-D
> > >>>>>>>> Action: draft-ietf-dots-signal-channel-19.txt
> > >>>>>>>>
> > >>>>>>>> Re-,
> > >>>>>>>>
> > >>>>>>>> Agree that the codes are not the same, but alternatives ones
> > >>>>>>>> as
> > >>>> summarized
> > >>>>>>>> here:
> > >>>>>>
> >
> > >>>>>>>>> De : kaname nishizuka [mailto:[email-masked]] Envoyé :
> > >>>>>>>>> lundi 7 mai 2018 08:20 À : BOUCADAIR Mohamed IMT/OLN;
> > >>>>>>>>> [email-masked] Objet : Re: [Dots] I-D Action:
> > >>>>>>>>> and the code '8' of the thread is different from the code
> > >>>>>>>>> '8' of
> > the
> > >>>>>>>> current
> > >>>>>>>>> draft.
> > >>>>>>>>>
> > >>>>>>>>> they'd been discussing the 7,8 and 9 based on this
> > >>>>>>>>> definition,
> > right?
> > >>>>>>>>>
> > >>>>>>>>> 7 | DOTS Server has detected conflicting mitigation requests
> > >>>>>>>>> from
> > >>>>>> different
> > >>>>>>>>> DOTS clients.  This mitigation request is currently inactive
> > >>>>>>>>> until
> > >> the
> > >>>>>>>>> 8 | DOTS Server has detected conflicting mitigation requests
> > >>>>>>>>> from
> > >>>>>> different
> > >>>>>>>>> 9 | DOTS Server has detected conflicting mitigation requests
> > >>>>>>>>> from
> > >>>>>> different
> > >> https://mailarchive.ietf.org/arch/msg/dots/z_cZR9_u273HzC9o0Iy9FeQZ
> > >> 0Jo
> > >>>>>>>> about
> > >>>>>>>>>>> -----Message d'origine----- De : kaname nishizuka
> > >>>>>>>>>>> [mailto:[email-masked]] Envoyé : mercredi 2 mai 2018
> > >>>>>>>>>>> 02:49 À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
> Objet :
> > >>>>>>>>>>> Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-
> > >> 19.txt
> > >>>>>>>>>>> Hi,
> > >>>>>>>>>>>
> > >>>>>>>>>>>          o  A notification message with 'status' code set
> > >>>>>>>>>>> to '8
> > >> (Attack
> > >>>>>>>>>>>             mitigation is rejected)' and 'conflict-status'
> > >>>>>>>>>>> set to
> > >> '1'
> > >>>> is
> > >>>>>>>> sent
> > >>>>>>>>>>> So it looks there is no chance to return '8 (Attack
> > >>>>>>>>>>> mitigation is
> > >>>>>>>>> rejected)'.
> > >>>>>>>>>>> thanks,
> > >>>>>>>>>>> Kaname
> > >>>>>>>>>>>
> > >>>>>>>>>>>> This version addresses the comments raised during the
> > >>>>>>>>>>>> WGLC, in
> > >>>>>>>>> particular:
> > >>>>>>>>>>>> - (Clarification) Indicate explicitly that GET messages
> > >>>>>>>>>>>> with
> > 'sid'
> > >>>> are
> > >>>>>>>>>>> allowed
> > >>>>>>>>>>>>> -----Message d'origine----- De : Dots
> > >>>>>>>>>>>>> [mailto:[email-masked]] De la part de
> > internet-
> > >>>>>>>>>>>>> [email-masked]
> > >>>>>>>>>>>>> Envoyé : mardi 10 avril 2018 15:40 À :
> > >>>>>>>>>>>>> [email-masked] Cc : [email-masked] Objet : [Dots]
> > >>>>>>>>>>>>> I-D Action: draft-ietf-dots-signal-channel-
> > 19.txt
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> A New Internet-Draft is available from the on-line
> > >>>>>>>>>>>>> Internet-
> > >> Drafts
> > >>>>>>>>>>>>> directories.
> > >>>>>>>>>>>>> This draft is a work item of the DDoS Open Threat
> > >>>>>>>>>>>>> Signaling WG
> > of
> > >>>> the
> > >>>>>>>>>>> IETF.
> > >>>>>>>>>>>>>          Service (DDoS) attacks to a server capable of
> > >>>>>>>>>>>>> enabling
> > >>>> network
> > >>>>>>>>>>>>>          A companion document defines the DOTS data
> > >>>>>>>>>>>>> channel, a
> > >>>> separate
> > >>>>>>>>>>>>>          reliable communication layer for DOTS
> > >>>>>>>>>>>>> management and
> > >>>>>>>> configuration
> > >>>>>>>>>>>>>          purposes.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>          Please update these statements with the RFC
> > >>>>>>>>>>>>> number to
> > be
> > >>>>>> assigned
> > >>>>>>>>> to
> > >>>>>>>>>>>>>          this document:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>          o  "This version of this YANG module is part of
> > >>>>>>>>>>>>> RFC
> > >> XXXX;"
> > >>>>>>>>>>>>>          Please update TBD statements with the port
> > >>>>>>>>>>>>> number to
> > be
> > >>>>>> assigned
> > >>>>>>>> to
> > >>>>>>>>>>>>>          Also, please update the "revision" date of the
> > >>>>>>>>>>>>> YANG
> > >> module.
> > >>>>>>>>>>>>>

---

From: <[email-masked]>
Date: Wed, 16 May 2018 06:55:53 +0000

Hi Tiru, 

Please see inline. 

Cheers,
Med

> De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
> Envoyé : mercredi 16 mai 2018 08:11
> À : BOUCADAIR Mohamed IMT/OLN; kaname nishizuka
> Cc : [email-masked]
> Objet : RE: [Dots] I-D Action: draft-ietf-dots-signal-channel-19.txt
> 
> If the request is conflicting with an existing mitigation request from a
> different DOTS client, the DOTS server may either decide to maintain the
> conflicting request or reject the conflicting mitigation request. If the DOTS
> server decides to maintain
> the conflicting mitigation request,

[Med] I guess "conflicting mitigation request" points to the new request.   

 the DOTS server returns 2.01 (Created) to
> the requesting DOTS client. If the DOTS server decides to reject the
> conflicting mitigation request, the DOTS server returns 4.09 (Conflict)
> [RFC8132] to the requesting DOTS client

[Med] Idem as above.  

> For both 2.01 (Created) and 4.09 (Conflict) responses,

[Med] I like this.

 the response message
> includes enough information for a DOTS client to recognize the source of the
> conflict as described below:

[Med] What about?

NEW:

   If the request is conflicting with an existing mitigation request
   from a different DOTS client, the DOTS server may return 2.01
   (Created) or 4.09 (Conflict) to the requesting DOTS client.  For
   example:

   o  If the DOTS server decides to maintain the new mitigation request,
      the DOTS server returns 2.01 (Created) to the requesting DOTS
      client.

   o  If the DOTS server decides to reject the new mitigation request,
      the DOTS server returns 4.09 (Conflict) to the requesting DOTS
      client.

   For both 2.01 (Created) and 4.09 (Conflict) responses, the response
   includes enough information for a DOTS client to recognize the source
   of the conflict as described below:

> > > >>>>>>>>>>>>>               Title           : Distributed Denial-of-
> Service
> > > Open
> > > >>>>>> Threat
> > > >>>>>>>>>>> Signaling

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 16 May 2018 07:03:45 +0000

Hi Med,

Please see inline 

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Wednesday, May 16, 2018 12:26 PM
> To: Konda, Tirumaleswar Reddy <[email-masked]>;
> kaname nishizuka <[email-masked]>
> Cc: [email-masked]
> Subject: RE: [Dots] I-D Action: draft-ietf-dots-signal-channel-19.txt
> 
> > De : Konda, Tirumaleswar Reddy
> > [mailto:[email-masked]]
> > À : BOUCADAIR Mohamed IMT/OLN; kaname nishizuka Cc : [email-masked]
> > If the request is conflicting with an existing mitigation request from
> > a different DOTS client, the DOTS server may either decide to maintain
> > the conflicting request or reject the conflicting mitigation request.
> > If the DOTS server decides to maintain the conflicting mitigation
> > request,
> 
> > conflicting mitigation request, the DOTS server returns 4.09
> > (Conflict) [RFC8132] to the requesting DOTS client
> 
> [Med] Idem as above.
> 
> 

Proposed text looks good. Nit: I don't see the need for "For example". 

Cheers,
-Tiru

> > > This email originated from outside of the organization. Do not click
> > > links
> > or
> > > open attachments unless you recognize the sender and know the
> > > content is safe.
> > >
> > > Hi Kaname,
> > >
> > > > De : kaname nishizuka [mailto:[email-masked]] Envoyé : mercredi
> > > > 16 mai 2018 03:16 À : BOUCADAIR Mohamed IMT/OLN Cc :
> [email-masked]
> > > Objet
> > > > >> De : kaname nishizuka [mailto:[email-masked]] Envoyé : lundi
> > > > >> 14 mai 2018 11:49 À : BOUCADAIR Mohamed IMT/OLN Cc :
> > > > >>>> vendredi
> > > > >>> [Med] Yes, that status will be sent to the owner of the
> > > > >>> (existing)
> > > > request.
> > > > >>>
> > > > >>>> In the text in the draft, "the conflicting mitigation
> > > > >>>> request" is
> > > > >> ambiguous
> > > > >>>> whether it is already existing request or the request that
> > > > >>>> just has
> > > > >> arrived.
> > > > >>> [Med] In this case, the resource is not created and as such
> > > > >>> case
> > > > returning
> > > > >> notification status code of 8 is not possible as you rightful
> > > > >> pointed
> > out.
> > > > >>> This is why we suggested to return 2.01 for this case too so
> > > > >>> that an
> > > > update
> > > > >> If it is obvious that the DOTS server need not to create
> > > > >> resource of the conflicting request, it may return 4.09.
> > > > > [Med] Do you mean that the text should be modified to allow for
> > > > > both
> > > > > 2.01
> > > > >     includes enough information for a DOTS client to recognize
> > > > > the
> > source
> > (Created)
> > > > >     includes enough information for a DOTS client to recognize
> > > > > the
> > source
> > > > >>>>    > In this case, the resource should be created and the
> > > > >>>> server should
> > > > >> return
> > > > >>>>> request, then the
> > > > >>>>> The text focuses on the case ", and the DOTS server decides
> > > > >>>>> to maintain
> > > > >> the
> > > > >>>>>> [mailto:[email-masked]] Envoyé :
> > > > >>>>>> However, to be precise, I'd like to suggest to state about
> > > > >>>>>> the case
> > > > the
> > > > >>>> DOTS
> > > > >>>>>>        The response includes enough information for a DOTS
> > > > >>>>>> client
> > to
> > > > >>>>>>>> Agree that the codes are not the same, but alternatives
> > > > >>>>>>>> ones as
> > > > >>>> summarized
> > > > >>>>>>>> here:
> > > > >>>>>>
> > > >
> > >
> > > > >>>>>>>>> [mailto:[email-masked]] Envoyé :
> > > > >>>>>>>>> and the code '8' of the thread is different from the
> > > > >>>>>>>>> code '8' of
> > > > the
> > > > >>>>>>>> current
> > > > >>>>>>>>> draft.
> > > > >>>>>>>>>
> > > > >> https://mailarchive.ietf.org/arch/msg/dots/7zljzN8nycZX7E7ghgk1
> > > > >> ux32
> > > > >> MkM
> > > > >>>>>>>>> ==
> > > > >>>>>>>>> 7 | DOTS Server has detected conflicting mitigation
> > > > >>>>>>>>> requests from
> > > > >>>>>> different
> > > > >>>>>>>>> DOTS clients.  This mitigation request is currently
> > > > >>>>>>>>> inactive until
> > > > >> the
> > > > >>>>>>>>> 8 | DOTS Server has detected conflicting mitigation
> > > > >>>>>>>>> requests from
> > > > >>>>>> different
> > > > >>>>>>>>> 9 | DOTS Server has detected conflicting mitigation
> > > > >>>>>>>>> requests from
> > > > >>>>>> different
> > > > >>>>>>>>>>> I'd like to ask one clarification question about
> > > > >>>>>>>>>>> status code
> > 8:
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>          o  A notification message with 'status' code
> > > > >>>>>>>>>>> set to '8
> > > > >> (Attack
> > > > >>>>>>>>>>>> - (Clarification) Indicate explicitly that GET
> > > > >>>>>>>>>>>> messages with
> > > > 'sid'
> > > > >>>> are
> > > > >>>>>>>>>>> allowed
> > > > >>>>>>>>>>>>> [email-masked] Cc : [email-masked] Objet :
> > > > >>>>>>>>>>>>> [Dots] I-D Action: draft-ietf-dots-signal-channel-
> > > > 19.txt
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>          Service (DDoS) attacks to a server capable
> > > > >>>>>>>>>>>>> of enabling
> > > > >>>> network
> > > > >>>>>>>>>>>>>          traffic mitigation on behalf of the
> > > > >>>>>>>>>>>>> requesting
> > client.
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>          o  "This version of this YANG module is
> > > > >>>>>>>>>>>>> part of RFC
> > > > >> XXXX;"
> > > > >>>>>>>>>>>>>          Also, please update the "revision" date of
> > > > >>>>>>>>>>>>> the YANG
> > > > >> module.
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-dots-sig
> > > > >>>>>>>>>>>>> nal-
> > > > channel/
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> https://tools.ietf.org/html/draft-ietf-dots-signal-c
> > > > >>>>>>>>>>>>> hann
> > > > >>>>>>>>>>>>> el-19
> > > > >>>>>>>>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-dot
> > > > >>>>>>>>>>>>> s-si
> > > > >>>>>>>>>>>>> gnal-
> > > > >>>> channel-
> > > > >>>>>>>> 19
> > > > >>>>>>>>>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-si
> > > > >>>>>>>>>>>>> gnal
> > > > >>>>>>>>>>>>> -
> > > > channel-
> > > > >> 19
> > > > >>>>>>>>>>>>>

---

From: kaname nishizuka <[email-masked]>
Date: Wed, 16 May 2018 16:15:44 +0900

Hi Med, Tiru,

Thanks for the improvement of the wording.
I'm also OK with the proposed text.

thanks,
kaname

---

From: <[email-masked]>
Date: Wed, 16 May 2018 07:33:13 +0000

Re-,

"For example" is there to accommodate a comment from Kaname who wanted the behavior to be also implementation/deployment. 

Cheers,
Med

> Envoyé : mercredi 16 mai 2018 09:04
> > > > > >>> [Med] Yes. The current text does calls out your step (1) in
> 4.4.2.
> > > > > >>> Your

---

From: kaname nishizuka <[email-masked]>
Date: Wed, 16 May 2018 16:50:36 +0900

Re,

I see, but I didn't feel "For example:" is reflecting my comment.
Should we need to use success (2.01 or 2.04) in the first sentence like this?

    If the request is conflicting with an existing mitigation request
    from a different DOTS client, the DOTS server may return success (2.01 or 2.04)
    or  Conflict(4.09) to the requesting DOTS client.

regards,
Kaname

---

From: <[email-masked]>
Date: Wed, 16 May 2018 08:15:40 +0000

Re-,

Please see inline. 

Cheers,
Med

> De : Dots [mailto:[email-masked]] De la part de kaname nishizuka
> Envoyé : mercredi 16 mai 2018 09:51
> À : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy
> Cc : [email-masked]

[Med] I was referring this this comment you made "It should be left as implementation- and deployment-specific".

Anyway, let's remove "For example:".

>     or  Conflict(4.09) to the requesting DOTS client.

[Med] I don't think so. The text is about a request with a new cuid/mid.

> > "For example" is there to accommodate a comment from Kaname who wanted the
> behavior to be also implementation/deployment.
> >
> > Cheers,
> > Med
> >

---

From: kaname nishizuka <[email-masked]>
Date: Fri, 18 May 2018 11:35:42 +0900

Re-,

Please see inline.

thanks,
Kaname

> [Med] I don't think so. The text is about a request with a new cuid/mid.
[kaname] OK, the text is about a request with a new cuid/mid.
However, I'd like to point it out that the checking of conflict should be done at the arrival of a new PUT request with both a new cuid/mid case and the same mid(update of the mitigation request) case.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 18 May 2018 06:24:07 +0000

> From: kaname nishizuka [mailto:[email-masked]]
> Sent: Friday, May 18, 2018 8:06 AM
> To: [email-masked]; Konda, Tirumaleswar Reddy
> <[email-masked]>
> Cc: [email-masked]
> >> De : Dots [mailto:[email-masked]] De la part de kaname
> >> nishizuka Envoyé : mercredi 16 mai 2018 09:51 À : BOUCADAIR Mohamed
> >> IMT/OLN; Konda, Tirumaleswar Reddy Cc : [email-masked] Objet : Re:
> >> [Dots] I-D Action: draft-ietf-dots-signal-channel-19.txt
> >>
> >> Re,
> >>
> > [Med] I was referring this this comment you made "It should be left as
> implementation- and deployment-specific".
> >
> >>      from a different DOTS client, the DOTS server may return success
> >> (2.01 or
> >> 2.04)
> However, I'd like to point it out that the checking of conflict should be done
> at the arrival of a new PUT request with both a new cuid/mid case and the
> same mid(update of the mitigation request) case.

2.04 is discussed before the text explaining conflicts with an existing mitigation request from a different client.
<snip from Section 4.4.1>
   If the DOTS server finds the 'mid' parameter value conveyed in the
   PUT request in its configuration data bound to that DOTS client, it
   MAY update the mitigation request, and a 2.04 (Changed) response is
   returned to indicate a successful update of the mitigation request.
</snip>

-Tiru

> >>>> Envoyé : mercredi 16 mai 2018 09:04 À : BOUCADAIR Mohamed
> IMT/OLN;
> >>>> kaname nishizuka Cc : [email-masked] Objet : RE: [Dots] I-D Action:
> >>>>>> Envoyé : mercredi 16 mai 2018 08:11 À : BOUCADAIR Mohamed
> >>>>>> IMT/OLN; kaname nishizuka Cc : [email-masked] Objet : RE: [Dots]
> >>>>>> I-D Action: draft-ietf-dots-signal-channel-19.txt
> >>>>>>
> >>>>>> from a different DOTS client, the DOTS server may either decide
> >>>>>> to maintain the conflicting request or reject the conflicting mitigation
> request.
> >>>>>> the requesting DOTS client. If the DOTS server decides to reject
> >>>>>> includes enough information for a DOTS client to recognize the
> >>>>>> source of the conflict as described below:
> >>>>> [Med] What about?
> >>>>>
> >>>>> NEW:
> >>>>>
> >>>>>>> This email originated from outside of the organization. Do not
> >>>>>>> click links
> >>>>>> or
> >>>>>>>> mercredi
> >>>>>>>>>>>>      > If the server decides not to maintain the
> >>>>>>>>>>>> conflicting request, then
> >>>>>>>>>> the
> >>>>>>>>>> step (2) is not called explicit in the text because there is
> >>>>>>>>>> no confusion about which code to return when a request is
> >>>>>>>>>> accepted to be
> >>>>>>> honored.
> >>>>>>>>> [Med] Do you mean that the text should be modified to allow
> >>>>>>>>> for both
> >>>>>>>>> 2.01
> >>>>>>>>>>>> success (2.01 or 2.04) response code along with the
> >>>>>>>>>>>> conflict-
> >>>>>>>> information.
> >>>>>>>>>>>>> The text focuses on the case ", and the DOTS server
> >>>>>>>>>>>>> decides to maintain
> >>>>>>>>>> the
> >>>>>>>>>>>> conflicting mitigation request" because this is the one
> >>>>>>>>>>>> which requires additional specification vs. normal request
> >>>>>>>>>>>> that is accepted by a
> >>>>>>>> server.
> >>>>>>>>>>>>> Cheers,
> >>>>>>>>>>>>> Med
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> mercredi 9 mai 2018 10:41 À : BOUCADAIR Mohamed
> IMT/OLN
> >>>>> Cc :
> >>>>>>>>>>>>>> However, to be precise, I'd like to suggest to state
> >>>>>>>>>>>>>> about the case
> >>>>>>>> the
> >>>>>>>>>>>> DOTS
> >>>>>>>>>>>>>>          from a different DOTS client, and the DOTS
> >>>>>>>>>>>>>> server decides to
> >>>>>>>>>> maintain
> >>>>>>>>>>>>>>          the conflicting mitigation request, the DOTS
> >>>>>>>>>>>>>> server returns
> >>>>>>>> 2.01
> >>>>>>>>>>>>>>          Otherwise, the DOTS server returns 4.09
> >>>>>>>>>>>>>> (Conflict)
> >>>>>> [RFC8132].
> >>>>>>>>>>>>>>          The response includes enough information for a
> >>>>>>>>>>>>>> DOTS client
> >>>>>> to
> >>>>>>>>>>>>>>          recognize the source of the conflict as
> >>>>>>>>>>>>>> described
> >>>> below:
> >>>>>>>>>>>>>> thanks,
> >>>>>>>>>>>>>> Kaname
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>          from a different DOTS client, and the DOTS
> >>>>>>>>>>>>>>> server decides to
> >>>>>>>>>>>> maintain
> >>>>>>>>>>>>>>>          the conflicting mitigation request, the DOTS
> >>>>>>>>>>>>>>> server returns
> >>>>>>>> 4.09
> >>>>>>>>>>>>>>>          includes enough information for a DOTS client
> >>>>>>>>>>>>>>> to recognize the
> >>>>>>>>>>>> source
> >>>>>>>>>>>>>>>          from a different DOTS client, and the DOTS
> >>>>>>>>>>>>>>> server decides to
> >>>>>>>>>>>> maintain
> >>>>>>>>>>>>>>>          the conflicting mitigation request, the DOTS
> >>>>>>>>>>>>>>> server returns
> >>>>>>>> 2.01
> >>>>>>>> ^^^^
> >>>>>>>>>>>>>>>          includes enough information for a DOTS client
> >>>>>>>>>>>>>>> to recognize the
> >>>>>>>>>>>> source
> >>>>>>>>>>>>>>>>> On 2018/05/07 15:12,
> >>>>> wrote:
> >>>>>>>>>> https://mailarchive.ietf.org/arch/msg/dots/z_cZR9_u273HzC9o0I
> >>>>>>>>>> y9
> >>>>>>>>>> FeQZ
> >>>>>>>>>> 0Jo
> >>>>>>>>>>>>>>>> about
> >>>>>>>>>>>>>>>>>>>            o  A notification message with 'status'
> >>>>>>>>>>>>>>>>>>> code set to '8
> >>>>>>>>>> (Attack
> >>>>>>>>>>>>>>>>>>>               mitigation is rejected)' and
> >>>>>>>>>>>>>>>>>>> 'conflict-
> >>>> status'
> >>>>>>>>>>>>>>>>>>> set to
> >>>>>>>>>> '1'
> >>>>>>>>>>>> is
> >>>>>>>>>>>>>>>> sent
> >>>>>>>>>>>>>>>>>>> On 2018/04/10 22:47,
> >>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>> This version addresses the comments raised during
> >>>>>>>>>>>>>>>>>>>> the WGLC, in
> >>>>>>>>>>>>>>>>> particular:
> >>>>>>>>>>>>>>>>>>>>>            Service (DDoS) attacks to a server
> >>>>>>>>>>>>>>>>>>>>> capable of enabling
> >>>>>>>>>>>> network
> >>>>>>>>>>>>>>>>>>>>>            A companion document defines the DOTS
> >>>>>>>>>>>>>>>>>>>>> data channel, a
> >>>>>>>>>>>> separate
> >>>>>>>>>>>>>>>>>>>>>            Please update these statements with the
> >>>>>>>>>>>>>>>>>>>>> RFC number to
> >>>>>>>> be
> >>>>>>>>>>>>>> assigned
> >>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>            this document:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>            Please update TBD statements with the
> >>>>>>>>>>>>>>>>>>>>> port number to
> >>>>>>>> be
> >>>>>>>>>>>>>> assigned
> >>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>            Also, please update the "revision" date
> >>>>>>>>>>>>>>>>>>>>> of the YANG
> >>>>>>>>>> module.
> >>>>>>>>>>>>>>>>>>>>> until the htmlized version and diff are available
> >>>>>>>>>>>>>>>>>>>>> at
> >>>>>>>>>>>> tools.ietf.org.

---

From: <[email-masked]>
Date: Tue, 29 May 2018 09:33:09 +0000

Hi all,

It seems that this discussion has converged.

I updated the draft as follows to reflect the outcome of the discussion:

OLD: 

NEW:
   If the request is conflicting with an existing mitigation request
   from a different DOTS client, the DOTS server may return 2.01
   (Created) or 4.09 (Conflict) to the requesting DOTS client.  If the
   DOTS server decides to maintain the new mitigation request, the DOTS
   server returns 2.01 (Created) to the requesting DOTS client.  If the
   DOTS server decides to reject the new mitigation request, the DOTS
   server returns 4.09 (Conflict) to the requesting DOTS client.  For
   both 2.01 (Created) and 4.09 (Conflict) responses, the response
   includes enough information for a DOTS client to recognize the source
   of the conflict as described below:

Cheers,
Med

> Envoyé : vendredi 18 mai 2018 08:24
> À : kaname nishizuka; BOUCADAIR Mohamed IMT/OLN
> Cc : [email-masked]
> 2.04 is discussed before the text explaining conflicts with an existing
> mitigation request from a different client.
> > >>>>> click
> active.

---

From: kaname nishizuka <[email-masked]>
Date: Thu, 31 May 2018 16:14:49 +0900

Hi Med,

Looks good to me.
Thanks for updating it.

regards,
kaname