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

From: Magnus Westerlund via Datatracker <[email-masked]>
Date: Thu, 19 Dec 2019 04:53:38 -0800

Magnus Westerlund has entered the following ballot position for
draft-ietf-ace-coap-est-17: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/

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

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Fri, 20 Dec 2019 05:01:13 +0000

Thanks Magnus. 

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

Rgs,
Panos

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Magnus Westerlund via Datatracker
Sent: Thursday, December 19, 2019 7:54 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [Ace] Magnus Westerlund's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

Section 5.6:

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?

_______________________________________________
Ace mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ace

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 20 Dec 2019 09:33:30 +0000

Hi,

>    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-masked]
----------------------------------------------------------------------

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Fri, 20 Dec 2019 17:18:41 +0000

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-masked]> On Behalf Of Magnus Westerlund
Sent: Friday, December 20, 2019 4:34 AM
To: [email-masked]; Panos Kampanakis (pkampana) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
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:
> > 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

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

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Tue, 24 Dec 2019 14:49:27 +0000

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-masked]> On Behalf Of Panos Kampanakis (pkampana)
Sent: Friday, December 20, 2019 12:19 PM
To: Magnus Westerlund <magnus.westerlund=[email-masked]>;
[email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
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.

Panos

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Magnus Westerlund
Sent: Friday, December 20, 2019 4:34 AM
To: [email-masked]; Panos Kampanakis (pkampana) <[email-masked]>
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Ace] Magnus Westerlund's Discuss on
draft-ietf-ace-coap-est-17: (with DISCUSS)

Hi,

>    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

---

From: Magnus Westerlund <[email-masked]>
Date: Sun, 29 Dec 2019 13:47:22 +0000

Hi,

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

Thanks

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

Magnus Westerlund