Hi Magnus, This commit https://github.com/SanKumar2015/EST-coaps/commit/37f6337a3b389632c18b77d3c4d b8f28aabe9b63 tries to address your feedback. Let us know if it does not make sense.
Rgs, Panos -----Original Message----- From: Ace <[email protected]> On Behalf Of Panos Kampanakis (pkampana) Sent: Friday, December 20, 2019 12:19 PM To: Magnus Westerlund <[email protected]>; [email protected] Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [Ace] Magnus Westerlund's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS) Hi Magnus, I see your point about the confusion the word "support" could cause. 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. 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? Panos -----Original Message----- From: Ace <[email protected]> On Behalf Of Magnus Westerlund Sent: Friday, December 20, 2019 4:34 AM To: [email protected]; Panos Kampanakis (pkampana) <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [Ace] Magnus Westerlund's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS) Hi, On Fri, 2019-12-20 at 05:01 +0000, Panos Kampanakis (pkampana) wrote: > Thanks Magnus. > > > 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. > 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. Cheers Magnus Westerlund ---------------------------------------------------------------------- Networks, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: [email protected] ---------------------------------------------------------------------- _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
