Re: [Ace] Magnus Westerlund's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS)

[Magnus Westerlund <[e-mail]>]

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 <[e-mail]> On Behalf Of Panos Kampanakis (pkampana)
> Sent: Friday, December 20, 2019 12:19 PM
> To: Magnus Westerlund <magnus.westerlund=[e-mail]>;
> [e-mail]
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> 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 <[e-mail]> On Behalf Of Magnus Westerlund
> Sent: Friday, December 20, 2019 4:34 AM
> To: [e-mail]; Panos Kampanakis (pkampana) <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> 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  [phone]
> Torshamnsgatan 23           | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
> 
> 
> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace
-- 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------