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

["Panos Kampanakis (pkampana)" <[e-mail]>]

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 <[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