Magnus Westerlund's IESG Discuss

[petervanderstok]

---

DISCUSS:

Section 5.6:

The EST-coaps client MUST support Block1 only if it sends EST-coaps requests with an IP packet size that exceeds the Path MTU.

I think the requirement for when Block1 is required to be supported in the above sentence is unclear. Is the intention to say: An EST-coaps MUST support block1 to be capable to send requests that would otherwise result in the reliance on IP level fragmentation?

[csosto-pk]

The EST-coaps client MUST support Block1 only if it sends EST-coaps requests with an IP packet size that exceeds the Path MTU.

I think the requirement for when Block1 is required to be supported in the above sentence is unclear. Is the intention to say: An EST-coaps MUST support block1 to be capable to send requests that would otherwise result in the reliance on IP level fragmentation?

Yes, that was the intention. We will rephrase it to say

   [...] The EST-coaps client MUST support
   Block1 only if it sends large EST-coaps requests that would 
   otherwise result to IP layer fragmentation

[csosto-pk]

From Magnus

Is it support or use block1 when the request is to big? I think the combination of support and only results in uncertainty towards what the implementor. Based on this reformulation I have the impression you want to make the implementation optional if the expected EST-coaps request size is less than what the IP MTU can send without fragmentation. However, that leads me to ask what is the behavior of a node that suddenly are faced with a request that is larger. Refuse to send it with an error or still rely on IP fragmentation? There is always the potential for a request being to large unless implementation support of block1 is mandated.

Our intention was to make Block1 and Block2 MTI for the server, Block2 MTI for the client and Block1 optional to implement for the client only if it needs it. I see your point about the confusion the word "support" could cause. RFC7959 says " Implementation of either Block option is intended to be optional. ". So, I think it makes more sense to replicate this language instead of support. We will use "implement" in place of "support" in our draft.

Regarding what happens if a client wants to send a large request and it has not implemented Block 1, I don't think we should define that in our draft. RFC7959 says when you see a Block message you MUST process it or reject the message. It does not mandate what the sender application does if it has a large message and does not have COAP Blocks implemented. The right behavior in this case is to depend on the lower layer protocol. So if COAP does not support it, then IP. I do not think we should interfere with that in our draft, it falls in general TCP/IP layering.

Does the above sound reasonable?

[csosto-pk]

To address this, we rephrased to

   EST-coaps servers MUST implement Block1 and Block2.  EST-coaps
   clients MUST implement Block2.  EST-coaps clients MUST implement
   Block1 only if they are expecting to send EST-coaps requests with a 
   packet size that exceeds the Path MTU.

[csosto-pk]

Magnus confirmed the changes look good

Yes, it makes sense I think it is good enough and cleare than the old text.

Thanks for resolving my Discuss in the upcoming version.

[csosto-pk]

Uploaded in v-18