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

[kaname nishizuka <[e-mail]>]

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.




>> 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/7zljzN8nycZX7E7ghgk1
>>>>>>>>>> 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_u273HzC9o0Iy9
>>>>>>>>>> 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-sig
>>>>>>>>>>>>>>>>>>>>> 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-dot
>>>>>>>>>>>>>>>>>>>>> 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