Hi, Yes, it makes sense I think it is good enough and cleare than the old text.
Thanks Magnus On Tue, 2019-12-24 at 14:49 +0000, Panos Kampanakis (pkampana) wrote: > Hi Magnus, > > This commit > https://protect2.fireeye.com/v1/url?k=d1144abb-8d9d9086-d1140a20-0cc47ad93c0c-fd2a1bbef3212950&q=1&e=548577ce-1875-434e-8e9a-6ccd51a577bd&u=https%3A%2F%2Fgithub.com%2FSanKumar2015%2FEST-coaps%2Fcommit%2F37f6337a3b389632c18b77d3c4d > b8f28aabe9b63 tries to address your feedback. Let us know if it does not > make sense. > > Rgs, > Panos > > > -----Original Message----- > From: Ace <ace-boun...@ietf.org> On Behalf Of Panos Kampanakis (pkampana) > Sent: Friday, December 20, 2019 12:19 PM > To: Magnus Westerlund <magnus.westerlund=40ericsson....@dmarc.ietf.org>; > i...@ietf.org > Cc: draft-ietf-ace-coap-...@ietf.org; i...@augustcellars.com; > ace-cha...@ietf.org; ace@ietf.org > 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 <ace-boun...@ietf.org> On Behalf Of Magnus Westerlund > Sent: Friday, December 20, 2019 4:34 AM > To: i...@ietf.org; Panos Kampanakis (pkampana) <pkamp...@cisco.com> > Cc: draft-ietf-ace-coap-...@ietf.org; i...@augustcellars.com; > ace-cha...@ietf.org; ace@ietf.org > 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: magnus.westerl...@ericsson.com > ---------------------------------------------------------------------- > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace -- Cheers Magnus Westerlund ---------------------------------------------------------------------- Networks, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerl...@ericsson.com ----------------------------------------------------------------------
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
