Subject: Re: [Dots] 2nd WGLC on draft-ietf-dots-signal-channel-21

From: <[email-masked]>
Date: Tue, 7 Aug 2018 14:22:42 +0000

Hi Roman, WG,

A new version which addresses the comments raised during the WGLC is available online. The changes are as follows: 

Major: 

- Mitigation on loss: this is now defined as an attribute of mitigation requests. Added NEW text to clarify the corresponding behavior (include when conflicts with immediate mitigation requests) and update the YANG module.  

Minor: 

- Mandate the use of Observe option: this is coherent with the tone used in previous versions + the corresponding RFC is already classified as normative.
- Add a note for implementers to set the type of the CoAP message (Minor). This is a behavior offered by RFC7641, but it is worth to remind implementers to set this as NON for mitigation notifications.
- Define a behavior to ease mid rollover.  
- Add an explicit statement that PUT used for efficacy update is handled as a refresh request. 

Editorial 
- Reorganize some parts of the text for better readability
- Fix nits

Cheers,
Med

> -----Message d'origine-----
> De : Dots [mailto:[email-masked]] De la part de Roman Danyliw
> Envoyé : lundi 23 juillet 2018 20:55
> À : [email-masked]
> Objet : [Dots] 2nd WGLC on draft-ietf-dots-signal-channel-21
> 
> Hello!
> 
> Consistent with our discussion at the Montreal meeting, we are starting a
> second working group last call (WGLC) for the DOTS Signal Channel draft:
> 
> DOTS Signal Channel Specification
> draft-ietf-dots-signal-channel-21
> https://tools.ietf.org/html/draft-ietf-dots-signal-channel-21
> 
> Please send comments to the DOTS mailing list -- feedback on remaining issues
> or needed changes; as well as endorsements that this draft is ready.
> 
> This WGLC will end on August 5, 2018.
> 
> Thanks,
> Roman
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: Roman Danyliw <[email-masked]>
Date: Fri, 10 Aug 2018 20:25:25 +0000

Hello WG!

Tiru/Med/Prashanth/Andrew/Nik: thank you for resolving all feedback on the signal draft provided during WGLC.

After review of the WGLC feedback and the latest -22, this document appears to be ready to progression.  The chairs will work to get it shepherded.

Roman

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Tuesday, August 7, 2018 10:23 AM
> To: Roman Danyliw <[email-masked]>; [email-masked]
> Subject: RE: 2nd WGLC on draft-ietf-dots-signal-channel-21
> 
> Hi Roman, WG,
> 
> A new version which addresses the comments raised during the WGLC is
> available online. The changes are as follows:
> 
> Major:
> 
> - Mitigation on loss: this is now defined as an attribute of mitigation
> requests. Added NEW text to clarify the corresponding behavior (include
> when conflicts with immediate mitigation requests) and update the YANG
> module.
> 
> Minor:
> 
> - Mandate the use of Observe option: this is coherent with the tone used in
> previous versions + the corresponding RFC is already classified as normative.
> - Add a note for implementers to set the type of the CoAP message (Minor).
> This is a behavior offered by RFC7641, but it is worth to remind
> implementers to set this as NON for mitigation notifications.
> > Envoyé : lundi 23 juillet 2018 20:55 À : [email-masked] Objet : [Dots]
> > 2nd WGLC on draft-ietf-dots-signal-channel-21
> >
> > Hello!
> >
> > Consistent with our discussion at the Montreal meeting, we are
> > starting a second working group last call (WGLC) for the DOTS Signal
> Channel draft:
> >
> > Please send comments to the DOTS mailing list -- feedback on remaining
> > issues or needed changes; as well as endorsements that this draft is ready.
> >

---

From: kaname nishizuka <[email-masked]>
Date: Mon, 13 Aug 2018 10:28:42 +0900

Hi Med, Tiru and Jon,

Thank you all for the intensive discussion about the trigger-mitigation behavior.
I've read the thread and satisfied with the updated draft because it's solving the problem I raised at the beginning of the thread.

I'd like to add two comments about the status parameter 3 and 7.

For 7, whether a mitigation request with 'trigger-mitigation' set to false will be withdrawn due to overlap is implementation specific.
The dots server can continue to protect wider prefix range until the dots client explicitly delete it.
In my experience, "protect automatically and withdraw manually" is best practice for DDoS protection.

For 3, also the protection can continue till the mitigation is withdrawn or the lifetime expires even it is originally trigger-mitigation:false.

However, It's not intended to change the text in the draft. I know it works for other implementations. It's just a comment.

thanks,
kaname

---

From: <[email-masked]>
Date: Mon, 13 Aug 2018 05:34:55 +0000

Hi Roman, 

To help preparing the write-up, I don't have any IPR related to this specification. 

Cheers,
Med

> Envoyé : vendredi 10 août 2018 22:25
> À : [email-masked]
> Objet : Re: [Dots] 2nd WGLC on draft-ietf-dots-signal-channel-21
> 
> Hello WG!
> 
> After review of the WGLC feedback and the latest -22, this document appears
> to be ready to progression.  The chairs will work to get it shepherded.
> 
> Roman
> 
> > - Add an explicit statement that PUT used for efficacy update is handled as
> a
> > refresh request.
> >
> > Editorial

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 16 Aug 2018 06:15:23 +0000

(Including the CoRE WG chairs to the mail-thread)

Hi all,

Updates to CoAP by DOTS signal channel draft were discussed in the CoRE WG interim virtual meeting yesterday. 

Posting the suggestions for further discussion:

As per RFC7252 critical/elective rules apply to non-proxying endpoints.  A proxy processes options based on Unsafe/Safe-to-Forward classes as defined in Section 5.7 of RFC7252.
Unsafe Option : An option that would need to be understood by a proxy receiving the message in order to safely forward the message (Section 5.4.2).  Not every critical option is an unsafe option.

"Elective and Unsafe Options looks suitable for Hop-limit."

The CoRE WG would like to see a new draft discussing Hop-Limit Option.

Cheers,
-Tiru

> From: Dots <[email-masked]> On Behalf Of
> [email-masked]
> Sent: Tuesday, August 7, 2018 7:53 PM
> Subject: Re: [Dots] 2nd WGLC on draft-ietf-dots-signal-channel-21
> 
> 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 Roman, WG,
> 
> - Mitigation on loss: this is now defined as an attribute of mitigation requests.
> Added NEW text to clarify the corresponding behavior (include when conflicts
> with immediate mitigation requests) and update the YANG module.
> 
> Minor:
> 
> This is a behavior offered by RFC7641, but it is worth to remind implementers
> to set this as NON for mitigation notifications.
> > starting a second working group last call (WGLC) for the DOTS Signal Channel
> draft:
> >

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 16 Aug 2018 06:20:32 +0000

Hi all,

Posting the suggestions from CoRE WG for further discussion:

CoRE WG had previously discussed and decided not use 3.00 (Alternate server) response code.
The suggestion is to either use 4.29 (Too Many Requests) or 5.03 (Service Unavailable) with the error response body already explained in the DOTS signal channel draft 
to convey the alternate server details.

Regards,
-Tiru

> > This email originated from outside of the organization. Do not click
> > links or open attachments unless you recognize the sender and know the
> content is safe.
> >
> > Hi Roman, WG,
> >
> > Added NEW text to clarify the corresponding behavior (include when
> > conflicts with immediate mitigation requests) and update the YANG module.
> >
> > Minor:
> >
> > - Mandate the use of Observe option: this is coherent with the tone
> > used in previous versions + the corresponding RFC is already classified as
> normative.
> > > Envoyé : lundi 23 juillet 2018 20:55 À : [email-masked] Objet :
> > > [Dots] 2nd WGLC on draft-ietf-dots-signal-channel-21
> > >
> > > Hello!
> > >
> > > Channel
> > > Please send comments to the DOTS mailing list -- feedback on
> > > remaining issues or needed changes; as well as endorsements that this
> draft is ready.
> > >

---

From: "Xialiang (Frank, Network Integration Technology Research Dept)" <[email-masked]>
Date: Thu, 16 Aug 2018 06:35:55 +0000

Hi Tiru,
Thanks for your joint-discussion with CoRE WG and bring the information here.

Please keep on the discussion and address the issue together with CoRE experts.

B.R.
Frank

-----邮件原件-----
发件人: Dots [mailto:[email-masked]] 代表 Konda, Tirumaleswar Reddy
发送时间: 2018年8月16日 14:15
收件人: [email-masked]; Roman Danyliw <[email-masked]>; [email-masked]; [email-masked]
主题: Re: [Dots] 2nd WGLC on draft-ietf-dots-signal-channel-21

Hi all,

Cheers,
-Tiru

> links or open attachments unless you recognize the sender and know the content is safe.
> 
> Hi Roman, WG,
> 
> used in previous versions + the corresponding RFC is already classified as normative.
> > remaining issues or needed changes; as well as endorsements that this draft is ready.
> >

---

From: "Xialiang (Frank, Network Integration Technology Research Dept)" <[email-masked]>
Date: Thu, 16 Aug 2018 06:36:08 +0000

+1

-----邮件原件-----
发件人: Dots [mailto:[email-masked]] 代表 Konda, Tirumaleswar Reddy
发送时间: 2018年8月16日 14:21
收件人: [email-masked]; Roman Danyliw <[email-masked]>; [email-masked]; [email-masked]
主题: Re: [Dots] 2nd WGLC on draft-ietf-dots-signal-channel-21

Hi all,

CoRE WG had previously discussed and decided not use 3.00 (Alternate server) response code.
The suggestion is to either use 4.29 (Too Many Requests) or 5.03 (Service Unavailable) with the error response body already explained in the DOTS signal channel draft to convey the alternate server details.

Regards,
-Tiru

> > > De : Dots [mailto:[email-masked]] De la part de Roman 
> > > Danyliw Envoyé : lundi 23 juillet 2018 20:55 À : [email-masked] Objet :

---

From: <[email-masked]>
Date: Thu, 16 Aug 2018 07:08:22 +0000

Hi Tiru, 

Thank you for sharing this. 

What would be the harm if the option is maintained in the signal-channel draft? The option will be listed under the CoAP IANA options registry anyway and others can use the option if needed.  

We can define the option in a separate I-D, if really needed, but there is dependency risk that I'd like to avoid if possible. 

Cheers,
Med

> De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
> Envoyé : jeudi 16 août 2018 08:15
> À : BOUCADAIR Mohamed IMT/OLN; Roman Danyliw; [email-masked]; core-
> [email-masked]
> Objet : RE: 2nd WGLC on draft-ietf-dots-signal-channel-21
> 
> As per RFC7252 critical/elective rules apply to non-proxying endpoints.  A
> proxy processes options based on Unsafe/Safe-to-Forward classes as defined in
> Section 5.7 of RFC7252.
> Unsafe Option : An option that would need to be understood by a proxy
> receiving the message in order to safely forward the message (Section 5.4.2).
> Not every critical option is an unsafe option.
> 
> requests.
> conflicts
> implementers

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 16 Aug 2018 09:15:10 +0200

> What would be the harm if the option is maintained in the signal-channel draft? The option will be listed under the CoAP IANA options registry anyway and others can use the option if needed.  

The risk is that change requests from the CoRE side would slow down completion of the signal-channel draft.
(We’d be playing a form of Chinese whispers, essentially.)
It is probably more expedient to get this small part of the work completed in the CoRE WG.

> We can define the option in a separate I-D, if really needed, but there is dependency risk that I'd like to avoid if possible. 

That risk would need to be weighed agains the above risk.

The CoRE WG is very open to picking up and completing relevant work from other WGs (or even SDOs), and we are getting better in doing this in a timely way.

Grüße, Carsten

---

From: <[email-masked]>
Date: Thu, 16 Aug 2018 09:06:19 +0000

Re-,

Thank you, Carsten. 

Please expect a draft from us soon.

Cheers,
Med

> De : Carsten Bormann [mailto:[email-masked]]
> Envoyé : jeudi 16 août 2018 09:15
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Konda, Tirumaleswar Reddy; Roman Danyliw; [email-masked]; core-
> [email-masked]
> Objet : Re: 2nd WGLC on draft-ietf-dots-signal-channel-21
> 
> > What would be the harm if the option is maintained in the signal-channel
> draft? The option will be listed under the CoAP IANA options registry anyway
> and others can use the option if needed.
> 
> > We can define the option in a separate I-D, if really needed, but there is
> dependency risk that I'd like to avoid if possible.
> 
> The CoRE WG is very open to picking up and completing relevant work from
> other WGs (or even SDOs), and we are getting better in doing this in a timely
> way.
> 
> Grüße, Carsten

---

From: <[email-masked]>
Date: Thu, 16 Aug 2018 09:42:07 +0000

Re-,

Thank you, Tiru. 

Is the issue about privacy? If yes, isn't this valid for the other codes as well?

If we are not that "purist", 4.29 or 5.03 can do the job. We can even allow for both codes.

As a reminder, we wanted to cover the following redirect cases: 
* S1 (overloaded) redirects a client to another server S2 (that belong to the same provider). Fall back to S1 can be automatically triggered by S2.
* S1 (overloaded) redirects a client to another server S2 (that belong to the same provider). Fall back to S1 is explicitly triggered by S2 (policy-based).

Cheers,
Med

> Envoyé : jeudi 16 août 2018 08:21
> The suggestion is to either use 4.29 (Too Many Requests) or 5.03 (Service
> Unavailable) with the error response body already explained in the DOTS
> signal channel draft

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 16 Aug 2018 10:41:54 +0000

> From: [email-masked] <[email-masked]>
> Sent: Thursday, August 16, 2018 3:12 PM
> To: Konda, Tirumaleswar Reddy <[email-masked]>;
> Roman Danyliw <[email-masked]>; [email-masked]; [email-masked]

No, I don't think the issue is about privacy. The error code was discussed for a privacy use case, multi-cast CoAP server (using unsecure CoAP messages) redirects the CoAP client to a unicast CoAP server to retrieve privacy-sensitive information using CoAPs. 

> If we are not that "purist", 4.29 or 5.03 can do the job. We can even allow for

I don't see the need to allow both codes, we should pick one.

Cheers,
-Tiru

> * S1 (overloaded) redirects a client to another server S2 (that belong to the
> same provider). Fall back to S1 can be automatically triggered by S2.
> * S1 (overloaded) redirects a client to another server S2 (that belong to the
> same provider). Fall back to S1 is explicitly triggered by S2 (policy-based).
> 
> Cheers,
> Med
> 
> > De : Konda, Tirumaleswar Reddy
> > [mailto:[email-masked]]
> > [email-masked] Objet : RE: 2nd WGLC on
> > Unavailable) with the error response body already explained in the
> > DOTS signal channel draft to convey the alternate server details.
> >
> > Regards,
> > -Tiru
> >
> > >
> > > > This email originated from outside of the organization. Do not
> > > > click links or open attachments unless you recognize the sender
> > > > and know the
> > > content is safe.
> > > >
> > > > Hi Roman, WG,
> > > >
> > > > A new version which addresses the comments raised during the WGLC
> > > > is available online. The changes are as follows:
> > > >
> > > > Major:
> > > >
> > > > - Mandate the use of Observe option: this is coherent with the
> > > > tone used in previous versions + the corresponding RFC is already
> > > > classified
> > as
> > > normative.

---

From: <[email-masked]>
Date: Thu, 16 Aug 2018 12:19:48 +0000

Re-,

I suggest to proceed with 5.03. 

Cheers,
Med

> Envoyé : jeudi 16 août 2018 12:42
> No, I don't think the issue is about privacy. The error code was discussed
> for a privacy use case, multi-cast CoAP server (using unsecure CoAP messages)
> redirects the CoAP client to a unicast CoAP server to retrieve privacy-
> sensitive information using CoAPs.
> 
> >
> > If we are not that "purist", 4.29 or 5.03 can do the job. We can even allow
> for
> > both codes.
>

---

From: "Mortensen, Andrew" <[email-masked]>
Date: Fri, 17 Aug 2018 03:51:54 +0000

> On Aug 16, 2018, at 8:19 AM, [email-masked] wrote:
> 
> [EXTERNAL EMAIL]
> 
> Re-,
> 

+1

andrew

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 17 Aug 2018 03:59:07 +0000

> From: Mortensen, Andrew <[email-masked]>
> Sent: Friday, August 17, 2018 9:22 AM
> To: [email-masked]
> Cc: Konda, Tirumaleswar Reddy <[email-masked]>;

Yup, 5.03 looks suitable.

-Tiru

> <[email-masked]>
> >>> links
> >> or
> >>> open attachments unless you recognize the sender and know the
> >>> content is
> >> safe.
> >>>
> >>> Re-,
> >>>
> >>> Thank you, Tiru.
> >>>
> >>> Is the issue about privacy? If yes, isn't this valid for the other
> >>> codes as
> >> well?
> >>
> >> No, I don't think the issue is about privacy. The error code was
> >> discussed for a privacy use case, multi-cast CoAP server (using
> >> unsecure CoAP messages) redirects the CoAP client to a unicast CoAP
> >> server to retrieve privacy- sensitive information using CoAPs.
> >>
> >>>
> >>> * S1 (overloaded) redirects a client to another server S2 (that
> >>> belong to
> >> the
> >>> * S1 (overloaded) redirects a client to another server S2 (that
> >>> belong to
> >> the
> >>> same provider). Fall back to S1 is explicitly triggered by S2
> >>> (policy-
> >> based).
> >>>
> >>> Cheers,
> >>> Med
> >>>
> >>>> CoRE WG had previously discussed and decided not use 3.00
> >>>> (Alternate
> >>>> server) response code.
> >>>>>> Added NEW text to clarify the corresponding behavior (include

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 21 Aug 2018 14:55:36 +0000

I hold no IPR for this draft.

-Tiru

> Sent: Monday, August 13, 2018 11:05 AM
> > Envoyé : vendredi 10 août 2018 22:25 À : [email-masked] Objet : Re:
> > After review of the WGLC feedback and the latest -22, this document
> > appears to be ready to progression.  The chairs will work to get it shepherded.
> >
> > Roman
> >
> > > - Mitigation on loss: this is now defined as an attribute of
> > > mitigation requests. Added NEW text to clarify the corresponding
> > > behavior (include when conflicts with immediate mitigation requests)
> > > and update the YANG module.
> > >
> > > Minor:
> > >
> > > > Danyliw Envoyé : lundi 23 juillet 2018 20:55 À : [email-masked]
> > > > remaining issues or needed changes; as well as endorsements that
> > > > this draft is
> > ready.
> > > >