Subject: [Dots] WGLC for draft-ietf-dots-robust-blocks-01

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 17 Jan 2022 18:05:23 +0300

Hi,

this message starts a two-week working group last call for
draft-ietf-dots-robust-blocks-01.
The WGLC will end on Monday, January 31. Please, review the draft and send
your comments to the mailing list.

Regards,
Frank & Valery.

---

From: "Meiling Chen" <[email-masked]>
Date: Thu, 20 Jan 2022 16:53:04 +0800

Hi,
I have reviewed the draft, I think it is ready for publication.

Best,
Meiling 
From: Valery Smyslov
Date: 2022-01-17 23:05
To: [email-masked]
CC: dots-chairs; draft-ietf-dots-robust-blocks
Subject: [Dots] WGLC for draft-ietf-dots-robust-blocks-01
Hi,

Regards,
Frank & Valery.
 
_______________________________________________
Dots mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dots

---

From: tirumal reddy <[email-masked]>
Date: Mon, 24 Jan 2022 17:00:06 +0530

I reviewed the draft and it looks good to me. I don't think OSCORE
discussed in the security considerations of draft-ietf-core-new-block is
relevant to this draft.

Cheers,
-Tiru

---

From: <[email-masked]>
Date: Mon, 24 Jan 2022 11:50:41 -0000

Hi all,

I have re-reviewed the draft as well as being one of the Authors and can
find no issues.

The ability to dynamically configure and negotiate values for the first 4
parameter values has been implemented.

libcoap (outstanding PR) has been updated to support the configuration (the
last 2 parameter values are auto-computed based on the other parameters) as
a part of the work for draft-ietf-core-new-block and my DOTS implement does
the negotiation and pushes the resultant configuration.

Regards

Jon 

> -----Original Message-----
> From: Valery Smyslov [mailto: [email-masked]]
> Sent: 17 January 2022 15:05
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: WGLC for draft-ietf-dots-robust-blocks-01
> 
> Hi,
>

---

From: kaname nishizuka <[email-masked]>
Date: Sun, 30 Jan 2022 22:27:08 +0900

Hi,

I've reviewed the draft.
I found no issue around the specification.

The dynamic configuration and negotiation of the values are not implemented yet on my side(go-dots).
But it'll be a good candidate for the next interop with Jon.

The good news is that in our internal test, it's revealed that QBlock is more robust against certain rate of packet loss compared with normal block option. I will share the test result soon (maybe in the next IETF)

One more thing I'd like to mention is about cache behavior.
I think it can be stated what the cache key should be based on(how it is distinguished/identified).
There is no specific text on draft-ietf-core-new-block (and should not be)
If this draft can include a bit sense about DOTS specific cache strategy, it could get more friendly for implementers.
I'm not sure it's on CoAP side or DOTS side, still though.

Regards,
Kaname

---

From: <[email-masked]>
Date: Mon, 31 Jan 2022 07:55:53 +0000

Hi Kaname, 

Thank you for sharing the comments. 

We can't specify what cache key will be used as this will depend on used options (and their types). We may consider adding an example and reason about it, but still that's just an example and can't be generalized. That's why my current take on this is to make no change, but more opinions are welcome.    

Looking forward to reading more about the Q-Block tests results.

Cheers,
Med

> -----Message d'origine-----
> De : Dots <[email-masked]> De la part de kaname nishizuka
> Envoyé : dimanche 30 janvier 2022 14:27
> À : [email-masked]; Valery Smyslov <[email-masked]>;
> [email-masked]
> Cc : [email-masked]; [email-masked]
> Objet : Re: [Dots] WGLC for draft-ietf-dots-robust-blocks-01
> 
> Hi,
> 
> I've reviewed the draft.
> The good news is that in our internal test, it's revealed that QBlock is
> more robust against certain rate of packet loss compared with normal
> block option. I will share the test result soon (maybe in the next IETF)
> 
> There is no specific text on draft-ietf-core-new-block (and should not
> be) If this draft can include a bit sense about DOTS specific cache
> strategy, it could get more friendly for implementers.
> > I have re-reviewed the draft as well as being one of the Authors and
> > can find no issues.
> >
> > The ability to dynamically configure and negotiate values for the
> > first 4 parameter values has been implemented.
> >
> > libcoap (outstanding PR) has been updated to support the configuration
> > (the last 2 parameter values are auto-computed based on the other
> > parameters) as a part of the work for draft-ietf-core-new-block and my
> > DOTS implement does the negotiation and pushes the resultant
> configuration.
> >
> > Regards
> >
> > Jon
> >
> >> The WGLC will end on Monday, January 31. Please, review the draft and
> >> send your comments to the mailing list.
> >>
> >> Regards,
> >> Frank & Valery.
> >

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Mon, 31 Jan 2022 11:01:11 -0000

Hi Kaname,

Thanks for the feedback.

The cache-key in general is built from the presented options in the request.
Whether an option and its value is included in the cache-key is initially
determined from whether the Option is either Unsafe or (Safe-To-Forward and
NoCacheKey does not have all the bits set)
https://datatracker.ietf.org/doc/html/rfc7252#section-5.4.6

However, there are exceptions to this.  If you want the cache-key to be the
entire body spanning multiple payloads, then you would exclude BLOCK1 and
BLOCK2 options form the cache-key, but if you want access to specific
blocks, then you could include BLOCK1 and/or BLOCK2 as a part of the
cache-key definition.  This is hinted at in
https://datatracker.ietf.org/doc/html/rfc7959#section-2.10

Q-BLOCK1 and Q-BLOCK2 are also Critical and Unsafe as are BLOCK1 and BLOCK2
respectively.  For a proxy - aka DOTS gateway - for simplicity, it is
expected that the entire body is cached
https://datatracker.ietf.org/doc/html/draft-ietf-core-new-block#section-8
(i.e. Q-BLOCK1 and Q-BLOCK2 are not a part of the cache-key).

I don’t think anything extra needs to be added to dots-robust-blocks
regarding DOTS specific caching requirements as this draft is all about
tuning (should it be needed, but unlikely and not recommended unless you
really know what you are doing and have done lots of robustness testing) how
Q-Blocks work.  There was only one change to the recommended default CoAP
transmission parameters (MAX_RETRANSMIT changed from 4 to 3) as there were
timeout issues on lossy networks
https://datatracker.ietf.org/doc/html/rfc9132#section-4.5.2 

Regards

Jon
> From: [email-masked] [mailto:[email-masked]]
> Sent: 31 January 2022 07:56
> To: kaname nishizuka; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Dots] WGLC for draft-ietf-dots-robust-blocks-01
> 
> Hi Kaname,
> 
> We can't specify what cache key will be used as this will depend on used
> options (and their types). We may consider adding an example and reason
> about it, but still that's just an example and can't be generalized.
That's why my
> current take on this is to make no change, but more opinions are welcome.
> 
> ___________________________________________________________________
> ______________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
recu ce
> message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> If you have received this email in error, please notify the sender and
delete this
> message and its attachments.