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

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

> -----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