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

[kaname nishizuka <[e-mail]>]

Hi Med,

Looks good to me.
Thanks for updating it.

regards,
kaname


On 2018/05/29 18:33, [e-mail] wrote:
> Hi all,
>
> It seems that this discussion has converged.
>
> I updated the draft as follows to reflect the outcome of the discussion:
>
> 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, 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
>
>> -----Message d'origine-----
>> De : Konda, Tirumaleswar Reddy [mailto:[e-mail]]
>> Envoyé : vendredi 18 mai 2018 08:24
>> À : kaname nishizuka; BOUCADAIR Mohamed IMT/OLN
>> Cc : [e-mail]
>> Objet : RE: [Dots] I-D Action: draft-ietf-dots-signal-channel-19.txt
>>
>>> -----Original Message-----
>>> From: kaname nishizuka [mailto:[e-mail]]
>>> Sent: Friday, May 18, 2018 8:06 AM
>>> To: [e-mail]; Konda, Tirumaleswar Reddy
>>> <[e-mail]>
>>> Cc: [e-mail]
>>> Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-19.txt
>>>
>>> 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.
>>>
>>> Re-,
>>>
>>> Please see inline.
>>>
>>> thanks,
>>> Kaname
>>>
>>>
>>> On 2018/05/16 17:15, [e-mail] wrote:
>>>> Re-,
>>>>
>>>> Please see inline.
>>>>
>>>> Cheers,
>>>> Med
>>>>
>>>>> -----Message d'origine-----
>>>>> De : Dots [mailto:[e-mail]] De la part de kaname
>>>>> nishizuka Envoyé : mercredi 16 mai 2018 09:51 À : BOUCADAIR Mohamed
>>>>> IMT/OLN; Konda, Tirumaleswar Reddy Cc : [e-mail] Objet : Re:
>>>>> [Dots] I-D Action: draft-ietf-dots-signal-channel-19.txt
>>>>>
>>>>> Re,
>>>>>
>>>>> I see, but I didn't feel "For example:" is reflecting my comment.
>>>> [Med] I was referring this this comment you made "It should be left as
>>> implementation- and deployment-specific".
>>>> Anyway, let's remove "For example:".
>>>>
>>>>> 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.
>>>>>
>>>> [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.
>> 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
>>
>>>
>>>
>>>
>>>>> regards,
>>>>> Kaname
>>>>>
>>>>>
>>>>> On 2018/05/16 16:33, [e-mail] wrote:
>>>>>> Re-,
>>>>>>
>>>>>> "For example" is there to accommodate a comment from Kaname who
>>>>>> wanted the
>>>>> behavior to be also implementation/deployment.
>>>>>> Cheers,
>>>>>> Med
>>>>>>
>>>>>>> -----Message d'origine-----
>>>>>>> De : Konda, Tirumaleswar Reddy
>>>>>>> [mailto:[e-mail]]
>>>>>>> Envoyé : mercredi 16 mai 2018 09:04 À : BOUCADAIR Mohamed
>>> IMT/OLN;
>>>>>>> kaname nishizuka Cc : [e-mail] Objet : RE: [Dots] I-D Action:
>>>>>>> draft-ietf-dots-signal-channel-19.txt
>>>>>>>
>>>>>>> Hi Med,
>>>>>>>
>>>>>>> Please see inline
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: [e-mail]
>>>>>>>> [mailto:[e-mail]]
>>>>>>>> Sent: Wednesday, May 16, 2018 12:26 PM
>>>>>>>> To: Konda, Tirumaleswar Reddy
>>>>>>>> <[e-mail]>;
>>>>>>>> kaname nishizuka <[e-mail]>
>>>>>>>> Cc: [e-mail]
>>>>>>>> Subject: RE: [Dots] I-D Action:
>>>>>>>> draft-ietf-dots-signal-channel-19.txt
>>>>>>>>
>>>>>>>> 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 Tiru,
>>>>>>>>
>>>>>>>> Please see inline.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Med
>>>>>>>>
>>>>>>>>> -----Message d'origine-----
>>>>>>>>> De : Konda, Tirumaleswar Reddy
>>>>>>>>> [mailto:[e-mail]]
>>>>>>>>> Envoyé : mercredi 16 mai 2018 08:11 À : BOUCADAIR Mohamed
>>>>>>>>> IMT/OLN; kaname nishizuka Cc : [e-mail] Objet : RE: [Dots]
>>>>>>>>> I-D Action: draft-ietf-dots-signal-channel-19.txt
>>>>>>>>>
>>>>>>>>> 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,
>>>>>>>> [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:
>>>>>>> Proposed text looks good. Nit: I don't see the need for "For example".
>>>>>>>
>>>>>>> Cheers,
>>>>>>> -Tiru
>>>>>>>
>>>>>>>>> -Tiru
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Dots [mailto:[e-mail]] On Behalf Of
>>>>>>>>>> [e-mail]
>>>>>>>>>> Sent: Wednesday, May 16, 2018 10:52 AM
>>>>>>>>>> To: kaname nishizuka <[e-mail]>
>>>>>>>>>> Cc: [e-mail]
>>>>>>>>>> Subject: Re: [Dots] I-D Action:
>>>>>>>>>> draft-ietf-dots-signal-channel-19.txt
>>>>>>>>>>
>>>>>>>>>> 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,
>>>>>>>>>>
>>>>>>>>>> Thank you for ACking. I will implement this change.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Med
>>>>>>>>>>
>>>>>>>>>>> -----Message d'origine-----
>>>>>>>>>>> De : kaname nishizuka [mailto:[e-mail]] Envoyé :
>>>>>>>>>>> mercredi
>>>>>>>>>>> 16 mai 2018 03:16 À : BOUCADAIR Mohamed IMT/OLN Cc :
>>>>>>>> [e-mail]
>>>>>>>>>> Objet
>>>>>>>>>>> : Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-19.txt
>>>>>>>>>>>
>>>>>>>>>>> Hi Med,
>>>>>>>>>>>
>>>>>>>>>>> Please see inline.
>>>>>>>>>>>
>>>>>>>>>>> thanks,
>>>>>>>>>>> kaname
>>>>>>>>>>>
>>>>>>>>>>> On 2018/05/15 22:26, [e-mail] wrote:
>>>>>>>>>>>> Hi Kaname,
>>>>>>>>>>>>
>>>>>>>>>>>> Please see inline.
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Med
>>>>>>>>>>>>
>>>>>>>>>>>>> -----Message d'origine-----
>>>>>>>>>>>>> De : kaname nishizuka [mailto:[e-mail]] Envoyé : lundi
>>>>>>>>>>>>> 14 mai 2018 11:49 À : BOUCADAIR Mohamed IMT/OLN Cc :
>>>>>>>>>>>>> [e-mail] Objet : Re: [Dots] I-D Action:
>>>>>>>>>>>>> draft-ietf-dots-signal-channel-19.txt
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Med,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please see inline.
>>>>>>>>>>>>>
>>>>>>>>>>>>> thanks,
>>>>>>>>>>>>> Kaname
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 2018/05/11 18:39, [e-mail] wrote:
>>>>>>>>>>>>>> Re-,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please see inline.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>> Med
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -----Message d'origine----- De : kaname nishizuka
>>>>>>>>>>>>>>> [mailto:[e-mail]] Envoyé :
>>>>>>>>>>>>>>> vendredi
>>>>>>>>>>>>>>> 11 mai 2018 10:59 À : BOUCADAIR Mohamed IMT/OLN Cc :
>>>>>>>>>>>>>>> [e-mail] Objet : Re: [Dots] I-D Action:
>>>>>>>>>>>>>>> draft-ietf-dots-signal-channel-19.txt
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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 be sent to the
>>>>>>>>>>>>>>> client owner
>>>>>>>>>>>>> of
>>>>>>>>>>>>>>> the conflicting request to notify withdrawal (section 4.4.2).
>>>>>>>>>>>>>>> In that case, the status code is '7' (Attack mitigation is
>>>>>>>>>>>>>>> withdrawn)
>>>>>>>>>>>>>> [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
>>>>>>>>>>>>>>> rejected) will be used.
>>>>>>>>>>>>>> [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.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [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.
>>>>>>>>>>>>>>> (B) will get 4.09
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [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.
>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> [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:
>>>>>>>>>>>>        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, 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:
>>>>>>>>>>>>
>>>>>>>>>>> Yes, it works for me.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 2018/05/11 15:09, [e-mail]
>>> wrote:
>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -----Message d'origine----- De : kaname nishizuka
>>>>>>>>>>>>>>>>> [mailto:[e-mail]] Envoyé :
>>>>>>>>>>>>>>>>> mercredi 9 mai 2018 10:41 À : BOUCADAIR Mohamed
>>> IMT/OLN
>>>>>>>> Cc :
>>>>>>>>>>>>>>>>> [e-mail] Objet : Re: [Dots] I-D Action:
>>>>>>>>>>>>>>>>> draft-ietf-dots-signal-channel-19.txt
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 2018/05/09 14:51, [e-mail]
>>> wrote:
>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> -----Message d'origine----- De : Dots
>>>>>>>>>>>>>>>>>>> [mailto:[e-mail]] De la part de
>>>>>>>>>>>>>>>>>>> [e-mail] Envoyé : lundi 7 mai
>>> 2018
>>>>>>>>>> 08:38
>>>>>>>>>>>>>>>>>>> À : kaname nishizuka; [e-mail] 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:
>>> https://mailarchive.ietf.org/arch/msg/dots/hA3MLKlkXFimpAn5KSYTayaVkjA.
>>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>>> Med
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> -----Message d'origine----- De : kaname nishizuka
>>>>>>>>>>>>>>>>>>>> [mailto:[e-mail]] Envoyé :
>>>>>>>>>>>>>>>>>>>> lundi 7 mai 2018 08:20 À : BOUCADAIR Mohamed
>>> IMT/OLN;
>>>>>>>>>>>>>>>>>>>> [e-mail] Objet : Re: [Dots] I-D Action:
>>>>>>>>>>>>>>>>>>>> draft-ietf-dots-signal-channel-
>>>>>>>>>>> 19.txt
>>>>>>>>>>>>>>>>>>>> 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/7zljzN8nycZX7E7ghg
>>>>>>>>>>>>> k1
>>>>>>>>>>>>> ux32
>>>>>>>>>>>>> MkM
>>>>>>>>>>>>>>>>>>>> ==
>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 2018/05/07 15:12,
>>> [e-mail]
>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>> Hi Kaname,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Please check
>>>>>>>>>>>>> https://mailarchive.ietf.org/arch/msg/dots/z_cZR9_u273HzC9o0I
>>>>>>>>>>>>> y9
>>>>>>>>>>>>> FeQZ
>>>>>>>>>>>>> 0Jo
>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> -----Message d'origine----- De : kaname nishizuka
>>>>>>>>>>>>>>>>>>>>>> [mailto:[e-mail]] Envoyé : mercredi 2 mai
>>>>>>>>>>>>>>>>>>>>>> 2018
>>>>>>>>>>>>>>>>>>>>>> 02:49 À : BOUCADAIR Mohamed IMT/OLN;
>>> [e-mail]
>>>>>>>>>> Objet :
>>>>>>>>>>>>>>>>>>>>>> Re: [Dots] I-D Action:
>>>>>>>>>>>>>>>>>>>>>> draft-ietf-dots-signal-channel-
>>>>>>>>>>>>> 19.txt
>>>>>>>>>>>>>>>>>>>>>> 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,
>>> [e-mail]
>>>>>>>>>> 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:[e-mail]] De la part de
>>>>>>>>>>> internet-
>>>>>>>>>>>>>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>>>>>>>>>>>>>> Envoyé : mardi 10 avril 2018 15:40 À :
>>>>>>>>>>>>>>>>>>>>>>>> [e-mail] Cc : [e-mail] 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-s
>>>>>>>>>>>>>>>>>>>>>>>> ig
>>>>>>>>>>>>>>>>>>>>>>>> nal-
>>>>>>>>>>> channel/
>>>>>>>>>>>>>>>>>>>>>>>> There are also htmlized versions available at:
>>>>>>>>>>>>>>>>>>>>>>>> https://tools.ietf.org/html/draft-ietf-dots-signal
>>>>>>>>>>>>>>>>>>>>>>>> -c
>>>>>>>>>>>>>>>>>>>>>>>> hann
>>>>>>>>>>>>>>>>>>>>>>>> el-19
>>>>>>>>>>>>>>>>>>>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-d
>>>>>>>>>>>>>>>>>>>>>>>> ot
>>>>>>>>>>>>>>>>>>>>>>>> s-si
>>>>>>>>>>>>>>>>>>>>>>>> gnal-
>>>>>>>>>>>>>>> channel-
>>>>>>>>>>>>>>>>>>> 19
>>>>>>>>>>>>>>>>>>>>>>>> A diff from the previous version is available at:
>>>>>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-
>>>>>>>>>>>>>>>>>>>>>>>> si
>>>>>>>>>>>>>>>>>>>>>>>> gnal
>>>>>>>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dots
>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>>>> Dots mailing list
>>>>>>>>>>>>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dots
>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>> Dots mailing list
>>>>>>>>>>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dots
>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>> Dots mailing list
>>>>>>>>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dots
>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>> Dots mailing list
>>>>>>>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dots
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> Dots mailing list
>>>>>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dots
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> Dots mailing list
>>>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dots
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Dots mailing list
>>>>>>>>>> [e-mail]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dots
>>>>>> _______________________________________________
>>>>>> Dots mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/dots
>>>>> _______________________________________________
>>>>> Dots mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/dots
>>>> _______________________________________________
>>>> Dots mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/dots