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

[<[e-mail]>]

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