[core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07

Discussion:

Yoshifumi Nishida

2017-04-09 03:53:11 UTC

Document: draft-ietf-core-coap-tcp-tls-07
Reviewer: Yoshifumi Nishida

I've reviewed this document as part of TSV-ART's ongoing effort to review
key IETF documents. These comments were written primarily for the transport
area directors, but are copied to the document's authors for their
information and to allow them to address any issues raised.When done at the
time of IETF Last Call, the authors should consider this review together
with any other last-call comments they receive. Please always CC
tsv-***@ietf.org if you reply to or forward this review.

Summary: This document is well-written. It is almost ready to be published
as a PS draft once the following points are addressed.

1: It is not clear how the protocol reacts the errors from transport layers
(e.g. connection failure).
The protocol will just inform apps of the events and the app will decide
what to do or the protocol itself will do something?

2: There will be situations where the app layer is freezing while the
transport layer is still working. Since transport layers cannot detect this
type of failures, there should be some mechanisms for it somewhere in the
protocol or in the app layer. The doc needs to address this point. For
example, what will happen when a PONG message is not returned for a certain
amount of time?

3: Since this draft defines new SZX value, I think the doc needs to update
RFC7959. This point should be clarified more in the doc.

--
Yoshi

Carsten Bormann

2017-04-09 07:25:21 UTC

Permalink

Hi Yoshi,

thank you very much for your thoughtful review.

3: Since this draft defines new SZX value, I think the doc needs to update RFC7959. This point should be clarified more in the doc.

The spec does indeed define a new SZX value, for use with the environments this document is used in (reliable transports). It does not change or add anything to the way RFC 7959 is used with the existing unreliable transports; as such it does not really update RFC 7959 as much as it does extend it for its own purposes.
(However, the same argument could be made for RFC 7641, which we do say we update.)

Maybe we are not making the point forcefully enough that SZX=7 is meant for use within this spec?
(Again, however: any other future COAP transports that have larger messages might pick up SZX=7 as well.)

I don’t have a strong opinion on how to populate the “updates” graph of RFCs in these boundary cases; it might help to get some more guidance here.

Grüße, Carsten

Yoshifumi Nishida

2017-04-09 21:24:09 UTC

Permalink

Hi Carsten,

Post by Carsten Bormann
Hi Yoshi,
thank you very much for your thoughtful review.

Post by Yoshifumi Nishida
3: Since this draft defines new SZX value, I think the doc needs to

update RFC7959. This point should be clarified more in the doc.
The spec does indeed define a new SZX value, for use with the environments
this document is used in (reliable transports). It does not change or add
anything to the way RFC 7959 is used with the existing unreliable
transports; as such it does not really update RFC 7959 as much as it does
extend it for its own purposes.
(However, the same argument could be made for RFC 7641, which we do say we update.)
Maybe we are not making the point forcefully enough that SZX=7 is meant
for use within this spec?
(Again, however: any other future COAP transports that have larger
messages might pick up SZX=7 as well.)
I donât have a strong opinion on how to populate the âupdatesâ graph of
RFCs in these boundary cases; it might help to get some more guidance here.

Ok, I see the point. I don't have a strong opinion here either as I am not
a COAP expert.
It could be enough if the draft has more texts to articulate that it won't
cause conflict with unreliable transport COAP.
--
Yoshi

Brian Raymor

2017-04-20 19:31:38 UTC

Permalink

Thanks for your feedback.

1: It is not clear how the protocol reacts the errors from transport layers (e.g. connection failure).
The protocol will just inform apps of the events and the app will decide what to do or the protocol itself will do something?

The WebSockets case is addressed by RFC6455:

When the underlying TCP connection is closed, it is said that _The
WebSocket Connection is Closed_ and that the WebSocket connection is
in the CLOSED state. If the TCP connection was closed after the
WebSocket closing handshake was completed, the WebSocket connection
is said to have been closed _cleanly_.

-and-

If at any point the underlying transport layer connection is
unexpectedly lost, the client MUST _Fail the WebSocket Connection_.

It's possible to add language similar to the abort case, along the lines of "When the underlying TCP connection is closed or reset, the CoAP connection is closed and in flight messages may be lost".

2: There will be situations where the app layer is freezing while the
transport layer is still working. Since transport layers cannot detect
this type of failures, there should be some mechanisms for it somewhere in the protocol or in the app layer. The doc needs to address
this point. For example, what will happen when a PONG message is not returned for a certain amount of time?

PONG is modeled on similar mechanisms in RFC6455 and RFC7540. Neither provides any guidance for this case. It's expected that an application framework would define and enforce the appropriate policy for timeouts or retries.

3: Since this draft defines new SZX value, I think the doc needs to update RFC7959. This point should be clarified more in the doc.

Carsten responded to this issue and the final exchange is here - https://www.ietf.org/mail-archive/web/core/current/msg08562.html

My sense is that we should treat this as an update to RFC7959 based on the original language:

The value 7 for SZX (which would
indicate a block size of 2048) is reserved, i.e., MUST NOT be sent
and MUST lead to a 4.00 Bad Request response code upon reception
in a request.

and the use of "extension" in coap-tcp-tls:

The ’Block-wise Extension for Reliable Transport (BERT)’ extends the Block protocol
to enable the use of larger messages over a reliable transport.

The existing IANA entries for Block1 and Block2 will also need to reference coap-tcp-tls in addition to RFC7959.

Tracking in https://github.com/core-wg/coap-tcp-tls/issues/129

weigengyu

2017-04-21 05:08:43 UTC

Permalink

Hi，

Post by Brian Raymor
It's possible to add language similar to the abort case, along the lines
of "When the underlying TCP connection is closed or reset,
the CoAP connection is closed and in flight messages may be lost".

It is not necessary when CoAP over WEBSocket is concerned, I think.
By the API or the interface, CoAP only interacts with WEB socket, does not
need to touch issues of TCP.
CoAP would react to the events of WebSokcet.

But, issues on TCP should be concerned if it is CoAP over TCP.

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件-----
From: Brian Raymor
Sent: Friday, April 21, 2017 3:31 AM
To: Yoshifumi Nishida ; tsv-***@ietf.org
Cc: draft-ietf-core-coap-tcp-***@ietf.org ; ***@ietf.org ; ***@ietf.org
Subject: Re: [core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07

Thanks for your feedback.

Post by Brian Raymor
1: It is not clear how the protocol reacts the errors from transport
layers (e.g. connection failure).
The protocol will just inform apps of the events and the app will
decide what to do or the protocol itself will do something?

The WebSockets case is addressed by RFC6455:

When the underlying TCP connection is closed, it is said that _The
WebSocket Connection is Closed_ and that the WebSocket connection is
in the CLOSED state. If the TCP connection was closed after the
WebSocket closing handshake was completed, the WebSocket connection
is said to have been closed _cleanly_.

-and-

If at any point the underlying transport layer connection is
unexpectedly lost, the client MUST _Fail the WebSocket Connection_.

It's possible to add language similar to the abort case, along the lines of
"When the underlying TCP connection is closed or reset, the CoAP connection
is closed and in flight messages may be lost".

Post by Brian Raymor
2: There will be situations where the app layer is freezing while the
transport layer is still working. Since transport layers cannot detect
this type of failures, there should be some mechanisms for it somewhere in
the protocol or in the app layer. The doc needs to address
this point. For example, what will happen when a PONG message is not
returned for a certain amount of time?

PONG is modeled on similar mechanisms in RFC6455 and RFC7540. Neither
provides any guidance for this case. It's expected that an application
framework would define and enforce the appropriate policy for timeouts or
retries.

Post by Brian Raymor
3: Since this draft defines new SZX value, I think the doc needs to update
RFC7959. This point should be clarified more in the doc.

Carsten responded to this issue and the final exchange is here -
https://www.ietf.org/mail-archive/web/core/current/msg08562.html

My sense is that we should treat this as an update to RFC7959 based on the
original language:

The value 7 for SZX (which would
indicate a block size of 2048) is reserved, i.e., MUST NOT be sent
and MUST lead to a 4.00 Bad Request response code upon reception
in a request.

and the use of "extension" in coap-tcp-tls:

The ’Block-wise Extension for Reliable Transport (BERT)’ extends the
Block protocol
to enable the use of larger messages over a reliable transport.

The existing IANA entries for Block1 and Block2 will also need to reference
coap-tcp-tls in addition to RFC7959.

Tracking in https://github.com/core-wg/coap-tcp-tls/issues/129

_______________________________________________
core mailing list
***@ietf.org
https://www.ietf.org/mailman/listinfo/core

Yoshifumi Nishida

2017-04-21 08:25:38 UTC

Permalink

Hi Brian,

Post by Brian Raymor
Thanks for your feedback.

Post by Yoshifumi Nishida
1: It is not clear how the protocol reacts the errors from transport

layers (e.g. connection failure).

Post by Yoshifumi Nishida
The protocol will just inform apps of the events and the app will

decide what to do or the protocol itself will do something?
When the underlying TCP connection is closed, it is said that _The
WebSocket Connection is Closed_ and that the WebSocket connection is
in the CLOSED state. If the TCP connection was closed after the
WebSocket closing handshake was completed, the WebSocket connection
is said to have been closed _cleanly_.
-and-
If at any point the underlying transport layer connection is
unexpectedly lost, the client MUST _Fail the WebSocket Connection_.
It's possible to add language similar to the abort case, along the lines
of "When the underlying TCP connection is closed or reset, the CoAP
connection is closed and in flight messages may be lost".

OK. I also think we should state that the protocol should notify the
failure events to applications.
Since errors can happen not only in TCP, but also TLS and websocket level,
mentioning only TCP close or reset might not be enough.

Post by Brian Raymor

Post by Yoshifumi Nishida
2: There will be situations where the app layer is freezing while the
transport layer is still working. Since transport layers cannot detect
this type of failures, there should be some mechanisms for it somewhere

in the protocol or in the app layer. The doc needs to address

Post by Yoshifumi Nishida
this point. For example, what will happen when a PONG message is not

returned for a certain amount of time?
PONG is modeled on similar mechanisms in RFC6455 and RFC7540. Neither
provides any guidance for this case. It's expected that an application
framework would define and enforce the appropriate policy for timeouts or
retries.

The figure 1 in the draft indicates that this draft and RFC7252 are in the
same level.
So, I am looking at this draft and 7252.
When we use 7252, I think applications basically don't need to implement
timeouts or retry mechanisms as the protocol provides such things.
However, when we use this one, it seems applications will need to have such
mechanisms. Isn't it a bit confusing? I am thinking that there need to be
some guidance here.
BTW, PONG is one example.

Post by Brian Raymor

Post by Yoshifumi Nishida
3: Since this draft defines new SZX value, I think the doc needs to

update RFC7959. This point should be clarified more in the doc.
Carsten responded to this issue and the final exchange is here -
https://www.ietf.org/mail-archive/web/core/current/msg08562.html
My sense is that we should treat this as an update to RFC7959 based on the
I don't have a strong opinion here. Updating 7959 is fine for me if it's

clearer to CoAP people.

Thanks,
--
Yoshi

Brian Raymor

2017-04-21 18:15:41 UTC

Permalink

Hi Yoshi,

OK. I also think we should state that the protocol should notify the failure events to applications.
Since errors can happen not only in TCP, but also TLS and websocket level, mentioning only TCP close or reset might not
be enough.

After reviewing with the authors, an additional clarification was appended to 3.4 Connection Health - https://github.com/core-wg/coap-tcp-tls/pull/140/files

The opinion of the authors (and Gengyu WEIâs recent response - https://www.ietf.org/mail-archive/web/core/current/msg08622.html) is that RFC6455 covers the WebSocket case and does not need to be repeated here.

When we use 7252, I think applications basically don't need to implement timeouts or retry mechanisms as the protocol
provides such things.

RFC7252 provides timeouts and retries because it's implementing a TCP-like reliability mechanism over UDP - https://tools.ietf.org/html/rfc7252#section-2.1

However, when we use this one, it seems applications will need to have such mechanisms. Isn't it a bit confusing? I am thinking that
there need to be some guidance here.
BTW, PONG is one example.

For coap-tcp-tls, there are multiple early implementations. This has never been reported as a source of confusion.

I don't have a strong opinion here. Updating 7959 is fine for me if it's clearer to CoAP people.

I've merged the change - https://github.com/core-wg/coap-tcp-tls/pull/138/files

Thanks again for helping us to improve the quality of the draft,

âŠBrian

Yoshifumi Nishida

2017-04-21 21:07:52 UTC

Permalink

Hi Brian,

Just in case,
Reliable transports only provide reliability at transport level. It doesn't
provide reliability in application protocol level.

RFC7252 has reliability mechanisms in it since it uses UDP. This means it
has abilities to check both transport and app level reliability.
This draft only provides transport level reliability and apps will need to
detect app protocol failure by themselves.
This means 7252 and this draft are not totally equivalent from the
viewpoint of applications.

I am not saying this is wrong or bad, but I believe app developer should
aware this point.
--
Yoshi

Post by Carsten Bormann
Hi Yoshi,

Post by Yoshifumi Nishida
OK. I also think we should state that the protocol should notify the

failure events to applications.

Post by Yoshifumi Nishida
Since errors can happen not only in TCP, but also TLS and websocket

level, mentioning only TCP close or reset might not

Post by Yoshifumi Nishida
be enough.

After reviewing with the authors, an additional clarification was appended
to 3.4 Connection Health - https://github.com/core-wg/
coap-tcp-tls/pull/140/files
The opinion of the authors (and Gengyu WEIâs recent response -
https://www.ietf.org/mail-archive/web/core/current/msg08622.html) is that
RFC6455 covers the WebSocket case and does not need to be repeated here.

Post by Yoshifumi Nishida
When we use 7252, I think applications basically don't need to implement

timeouts or retry mechanisms as the protocol

Post by Yoshifumi Nishida
provides such things.

RFC7252 provides timeouts and retries because it's implementing a TCP-like
reliability mechanism over UDP - https://tools.ietf.org/html/
rfc7252#section-2.1

Post by Yoshifumi Nishida
However, when we use this one, it seems applications will need to have

such mechanisms. Isn't it a bit confusing? I am thinking that

Post by Yoshifumi Nishida
there need to be some guidance here.
BTW, PONG is one example.

For coap-tcp-tls, there are multiple early implementations. This has never
been reported as a source of confusion.

Post by Yoshifumi Nishida

Post by Brian Raymor
My sense is that we should treat this as an update to RFC7959 based on

I don't have a strong opinion here. Updating 7959 is fine for me if it's

clearer to CoAP people.
I've merged the change - https://github.com/core-wg/
coap-tcp-tls/pull/138/files
Thanks again for helping us to improve the quality of the draft,
âŠBrian

Brian Raymor

2017-04-21 21:57:38 UTC

Permalink

I think that I understand your perceptions better. Prior to adoption of coap-tcp-tls and before I was active in the WG, I recall discussions related to the confusion over application vs transport reliability in CoAP especially as related to CON and NON. What was intended?

Tim Carey outlined some concerns in:
https://tools.ietf.org/html/draft-carey-core-std-msg-vs-trans-adapt-00#section-2

This topic was presented in detail at IETF 93 - https://www.ietf.org/proceedings/93/slides/slides-93-core-0.pdf - starting on slide 23.

In any case, CON and NON are about message layer semantics, not about application semantics
-- you gave them a meaning they don't have.

By IETF 94, the authors were reporting â âMost of the Confusion around CON/NON was resolvedâ.

Where relevant, Iâve added clarifications - such as the Appendix related to differences in Observe for reliable transports.

Both Carsten and Hannes could probably offer more context if needed.

From: Yoshifumi Nishida [mailto:***@sfc.wide.ad.jp]
Sent: Friday, April 21, 2017 2:08 PM
To: Brian Raymor <***@microsoft.com>
Cc: Yoshifumi Nishida <***@sfc.wide.ad.jp>; tsv-***@ietf.org; draft-ietf-core-coap-tcp-***@ietf.org; ***@ietf.org; ***@ietf.org
Subject: Re: TSV-ART review of draft-ietf-core-coap-tcp-tls-07

Hi Brian,

Just in case,
Reliable transports only provide reliability at transport level. It doesn't provide reliability in application protocol level.

RFC7252 has reliability mechanisms in it since it uses UDP. This means it has abilities to check both transport and app level reliability.
This draft only provides transport level reliability and apps will need to detect app protocol failure by themselves.
This means 7252 and this draft are not totally equivalent from the viewpoint of applications.

I am not saying this is wrong or bad, but I believe app developer should aware this point.
--
Yoshi

On Fri, Apr 21, 2017 at 11:15 AM, Brian Raymor <***@microsoft.com<mailto:***@microsoft.com>> wrote:

Hi Yoshi,

OK. I also think we should state that the protocol should notify the failure events to applications.
Since errors can happen not only in TCP, but also TLS and websocket level, mentioning only TCP close or reset might not
be enough.

When we use 7252, I think applications basically don't need to implement timeouts or retry mechanisms as the protocol
provides such things.

RFC7252 provides timeouts and retries because it's implementing a TCP-like reliability mechanism over UDP - https://tools.ietf.org/html/rfc7252#section-2.1

However, when we use this one, it seems applications will need to have such mechanisms. Isn't it a bit confusing? I am thinking that
there need to be some guidance here.
BTW, PONG is one example.

For coap-tcp-tls, there are multiple early implementations. This has never been reported as a source of confusion.

I don't have a strong opinion here. Updating 7959 is fine for me if it's clearer to CoAP people.

I've merged the change - https://github.com/core-wg/coap-tcp-tls/pull/138/files

Thanks again for helping us to improve the quality of the draft,

âŠBrian

Yoshifumi Nishida

2017-04-30 04:24:37 UTC

Permalink

Hello,
As far as I've read -08 draft, I think this point has not been addressed
yet. I hope some folks could elaborate a bit more if they think this is not
an important point for the draft.
--
Yoshi

Post by Brian Raymor
I think that I understand your perceptions better. Prior to adoption of
coap-tcp-tls and before I was active in the WG, I recall discussions
related to the confusion over application vs transport reliability in CoAP
especially as related to CON and NON. What was intended?
https://tools.ietf.org/html/draft-carey-core-std-msg-vs-tran
s-adapt-00#section-2
This topic was presented in detail at IETF 93 -
https://www.ietf.org/proceedings/93/slides/slides-93-core-0.pdf -
starting on slide 23.
And in a related thread on the mailing list back in 2015 -
https://www.ietf.org/mail-archive/web/core/current/msg06280.html -

In any case, CON and NON are about message layer semantics, not about

application semantics

-- you gave them a meaning they don't have.

By IETF 94, the authors were reporting â âMost of the Confusion
around CON/NON was resolvedâ.
Where relevant, Iâve added clarifications - such as the Appendix related
to differences in Observe for reliable transports.
Both Carsten and Hannes could probably offer more context if needed.
*Sent:* Friday, April 21, 2017 2:08 PM
*Subject:* Re: TSV-ART review of draft-ietf-core-coap-tcp-tls-07
Hi Brian,
Just in case,
Reliable transports only provide reliability at transport level. It
doesn't provide reliability in application protocol level.
RFC7252 has reliability mechanisms in it since it uses UDP. This means it
has abilities to check both transport and app level reliability.
This draft only provides transport level reliability and apps will need to
detect app protocol failure by themselves.
This means 7252 and this draft are not totally equivalent from the
viewpoint of applications.
I am not saying this is wrong or bad, but I believe app developer should aware this point.
--
Yoshi
Hi Yoshi,

OK. I also think we should state that the protocol should notify the

failure events to applications.

Since errors can happen not only in TCP, but also TLS and websocket

level, mentioning only TCP close or reset might not

be enough.

After reviewing with the authors, an additional clarification was appended
to 3.4 Connection Health - https://github.com/core-wg/coa
p-tcp-tls/pull/140/files
The opinion of the authors (and Gengyu WEIâs recent response -
https://www.ietf.org/mail-archive/web/core/current/msg08622.html) is that
RFC6455 covers the WebSocket case and does not need to be repeated here.

When we use 7252, I think applications basically don't need to implement

timeouts or retry mechanisms as the protocol

provides such things.

RFC7252 provides timeouts and retries because it's implementing a TCP-like
reliability mechanism over UDP - https://tools.ietf.org/html/rf
c7252#section-2.1

However, when we use this one, it seems applications will need to have

such mechanisms. Isn't it a bit confusing? I am thinking that

there need to be some guidance here.
BTW, PONG is one example.

For coap-tcp-tls, there are multiple early implementations. This has never
been reported as a source of confusion.

Post by Brian Raymor
My sense is that we should treat this as an update to RFC7959 based on

I don't have a strong opinion here. Updating 7959 is fine for me if it's

clearer to CoAP people.
I've merged the change - https://github.com/core-wg/coa
p-tcp-tls/pull/138/files
Thanks again for helping us to improve the quality of the draft,
âŠBrian

weigengyu

2017-05-02 05:31:27 UTC

Permalink

Hi all,

Transfering CoAP defined in -08 draft for reliable transmission facilities is as important as CoAP over CON/NON message.
In -08 draft, it is just clear how to make a new message for tranfering over TCP,
or other reliable facilities in the scenario (I) CoAP/UDP ---> (C2C) Proxy ----> CoAP over TCP.
But in -08 draft it is unclear how to work for the scenario (II) CoAP/TCP ---> (C2C) Proxy ----> CoAP over UDP.

The problem is when the C2C Proxy have got a message form the CoAP/TCP side,
how the Proxy make a decision to delivery CON or NON message carrying CoAP over UDP?
Even for the scenario (I), the problem is the same when delivering the CoAP response.

In these scenarios a key problem is that should the CoAP semantics be End-to-End or Hop-by-Hop when a C2C proxy is existed.

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications

From: Yoshifumi Nishida
Sent: Sunday, April 30, 2017 12:24 PM
To: Brian Raymor
Cc: tsv-***@ietf.org ; Yoshifumi Nishida ; draft-ietf-core-coap-tcp-***@ietf.org ; ***@ietf.org ; ***@ietf.org
Subject: Re: [core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07

Hello,
As far as I've read -08 draft, I think this point has not been addressed yet. I hope some folks could elaborate a bit more if they think this is not an important point for the draft.
--
Yoshi

On Fri, Apr 21, 2017 at 2:57 PM, Brian Raymor <***@microsoft.com> wrote:

I think that I understand your perceptions better. Prior to adoption of coap-tcp-tls and before I was active in the WG, I recall discussions related to the confusion over application vs transport reliability in CoAP especially as related to CON and NON. What was intended?

Tim Carey outlined some concerns in:

https://tools.ietf.org/html/draft-carey-core-std-msg-vs-trans-adapt-00#section-2

This topic was presented in detail at IETF 93 - https://www.ietf.org/proceedings/93/slides/slides-93-core-0.pdf - starting on slide 23.

In any case, CON and NON are about message layer semantics, not about application semantics
-- you gave them a meaning they don't have.

By IETF 94, the authors were reporting â âMost of the Confusion around CON/NON was resolvedâ.

Where relevant, Iâve added clarifications - such as the Appendix related to differences in Observe for reliable transports.

Both Carsten and Hannes could probably offer more context if needed.

From: Yoshifumi Nishida [mailto:***@sfc.wide.ad.jp]
Sent: Friday, April 21, 2017 2:08 PM
To: Brian Raymor <***@microsoft.com>
Cc: Yoshifumi Nishida <***@sfc.wide.ad.jp>; tsv-***@ietf.org; draft-ietf-core-coap-tcp-***@ietf.org; ***@ietf.org; ***@ietf.org
Subject: Re: TSV-ART review of draft-ietf-core-coap-tcp-tls-07

Hi Brian,

Just in case,

Reliable transports only provide reliability at transport level. It doesn't provide reliability in application protocol level.

RFC7252 has reliability mechanisms in it since it uses UDP. This means it has abilities to check both transport and app level reliability.

This draft only provides transport level reliability and apps will need to detect app protocol failure by themselves.

This means 7252 and this draft are not totally equivalent from the viewpoint of applications.

I am not saying this is wrong or bad, but I believe app developer should aware this point.

--

Yoshi

On Fri, Apr 21, 2017 at 11:15 AM, Brian Raymor <***@microsoft.com> wrote:

Hi Yoshi,

OK. I also think we should state that the protocol should notify the failure events to applications.
Since errors can happen not only in TCP, but also TLS and websocket level, mentioning only TCP close or reset might not
be enough.

When we use 7252, I think applications basically don't need to implement timeouts or retry mechanisms as the protocol
provides such things.

RFC7252 provides timeouts and retries because it's implementing a TCP-like reliability mechanism over UDP - https://tools.ietf.org/html/rfc7252#section-2.1

However, when we use this one, it seems applications will need to have such mechanisms. Isn't it a bit confusing? I am thinking that
there need to be some guidance here.
BTW, PONG is one example.

For coap-tcp-tls, there are multiple early implementations. This has never been reported as a source of confusion.

I don't have a strong opinion here. Updating 7959 is fine for me if it's clearer to CoAP people.

I've merged the change - https://github.com/core-wg/coap-tcp-tls/pull/138/files

Thanks again for helping us to improve the quality of the draft,

âŠBrian

--------------------------------------------------------------------------------

Carsten Bormann

2017-05-02 06:01:22 UTC

Permalink

Post by weigengyu
The problem is when the C2C Proxy have got a message form the CoAP/TCP side,
how the Proxy make a decision to delivery CON or NON message carrying CoAP over UDP?

The question is not very different from the UDP to UDP proxying case.
If a request came in via a UDP CON (which is the equivalent of using a reliable transport protocol), should the proxy use CON or NON for the forwarded request?

I’d say, in both cases, CON should be the default way of forwarding the reliable request.
But there may be specific cases where a NON may be appropriate — CoAP does not provide the client with a way to control the proxy here.

Is that a problem? Tell me more about your use case.

Grüße, Carsten

weigengyu

2017-05-02 06:11:33 UTC

Permalink

Hi，

Post by Carsten Bormann
The question is not very different from the UDP to UDP proxying case.

Something is different.

Post by Carsten Bormann
If a request came in via a UDP CON (which is the equivalent of using a
reliable transport protocol),
should the proxy use CON or NON for the forwarded request?

If it keeps the semantics end-to-end, the proxy just forwards the message.
If it has the semantics hop-by-hop, the proxy can decide what type of
message to transfer.

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件-----
From: Carsten Bormann
Sent: Tuesday, May 02, 2017 2:01 PM
To: weigengyu
Cc: Yoshifumi Nishida ; Brian Raymor ; tsv-***@ietf.org ;
draft-ietf-core-coap-tcp-***@ietf.org ; ***@ietf.org ; ***@ietf.org
Subject: Re: [core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07

Post by Carsten Bormann
The problem is when the C2C Proxy have got a message form the CoAP/TCP side,
how the Proxy make a decision to delivery CON or NON message carrying CoAP over UDP?

The question is not very different from the UDP to UDP proxying case.
If a request came in via a UDP CON (which is the equivalent of using a
reliable transport protocol), should the proxy use CON or NON for the
forwarded request?

I’d say, in both cases, CON should be the default way of forwarding the
reliable request.
But there may be specific cases where a NON may be appropriate — CoAP does
not provide the client with a way to control the proxy here.

Is that a problem? Tell me more about your use case.

Grüße, Carsten

Yoshifumi Nishida

2017-05-07 05:48:44 UTC

Permalink

Post by Carsten Bormann
HiïŒ
The question is not very different from the UDP to UDP proxying case.
Something is different.
If a request came in via a UDP CON (which is the equivalent of using a

Post by Carsten Bormann
reliable transport protocol),
should the proxy use CON or NON for the forwarded request?

If it keeps the semantics end-to-end, the proxy just forwards the message.
If it has the semantics hop-by-hop, the proxy can decide what type of
message to transfer.

My interpretation for 5.2.3 in RFC7252 is CoAP layer can ignore the
preference of applications and alter the message type by its decisions. It
seems to me proxies can choose message types as they want.
--
Yoshi

Post by Carsten Bormann
Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----åå§é®ä»¶----- From: Carsten Bormann
Sent: Tuesday, May 02, 2017 2:01 PM
To: weigengyu
Subject: Re: [core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07

Post by Carsten Bormann
The problem is when the C2C Proxy have got a message form the CoAP/TCP side,
how the Proxy make a decision to delivery CON or NON message carrying CoAP over UDP?

The question is not very different from the UDP to UDP proxying case.
If a request came in via a UDP CON (which is the equivalent of using a
reliable transport protocol), should the proxy use CON or NON for the
forwarded request?
Iâd say, in both cases, CON should be the default way of forwarding the
reliable request.
But there may be specific cases where a NON may be appropriate â CoAP does
not provide the client with a way to control the proxy here.
Is that a problem? Tell me more about your use case.
GrÃŒÃe, Carsten

Spencer Dawkins at IETF

2017-05-08 03:17:55 UTC

Permalink

Hi, Yoshi,

Post by Yoshifumi Nishida
Hello,
As far as I've read -08 draft, I think this point has not been addressed
yet. I hope some folks could elaborate a bit more if they think this is not
an important point for the draft.

I've seen the subsequent e-mails in reply to yours, but it's not obvious to
me whether you think this point was addressed after reading those e-mails.

What do you think?

Thanks,

Spencer

Post by Yoshifumi Nishida
--
Yoshi

In any case, CON and NON are about message layer semantics, not about

application semantics

-- you gave them a meaning they don't have.

By IETF 94, the authors were reporting â âMost of the Confusion
around CON/NON was resolvedâ.
Where relevant, Iâve added clarifications - such as the Appendix related
to differences in Observe for reliable transports.
Both Carsten and Hannes could probably offer more context if needed.
*Sent:* Friday, April 21, 2017 2:08 PM
*Subject:* Re: TSV-ART review of draft-ietf-core-coap-tcp-tls-07
Hi Brian,
Just in case,
Reliable transports only provide reliability at transport level. It
doesn't provide reliability in application protocol level.
RFC7252 has reliability mechanisms in it since it uses UDP. This means it
has abilities to check both transport and app level reliability.
This draft only provides transport level reliability and apps will need
to detect app protocol failure by themselves.
This means 7252 and this draft are not totally equivalent from the
viewpoint of applications.
I am not saying this is wrong or bad, but I believe app developer should
aware this point.
--
Yoshi
On Fri, Apr 21, 2017 at 11:15 AM, Brian Raymor <
Hi Yoshi,

OK. I also think we should state that the protocol should notify the

failure events to applications.

Since errors can happen not only in TCP, but also TLS and websocket

level, mentioning only TCP close or reset might not

be enough.

After reviewing with the authors, an additional clarification was
appended to 3.4 Connection Health - https://github.com/core-wg/coa
p-tcp-tls/pull/140/files
The opinion of the authors (and Gengyu WEIâs recent response -
https://www.ietf.org/mail-archive/web/core/current/msg08622.html) is
that RFC6455 covers the WebSocket case and does not need to be repeated
here.

When we use 7252, I think applications basically don't need to

implement timeouts or retry mechanisms as the protocol

provides such things.

RFC7252 provides timeouts and retries because it's implementing a
TCP-like reliability mechanism over UDP - https://tools.ietf.org/html/rf
c7252#section-2.1

However, when we use this one, it seems applications will need to have

such mechanisms. Isn't it a bit confusing? I am thinking that

there need to be some guidance here.
BTW, PONG is one example.

For coap-tcp-tls, there are multiple early implementations. This has
never been reported as a source of confusion.

Post by Brian Raymor
My sense is that we should treat this as an update to RFC7959 based on

I don't have a strong opinion here. Updating 7959 is fine for me if

it's clearer to CoAP people.
I've merged the change - https://github.com/core-wg/coa
p-tcp-tls/pull/138/files
Thanks again for helping us to improve the quality of the draft,
âŠBrian

_______________________________________________
Tsv-art mailing list
https://www.ietf.org/mailman/listinfo/tsv-art

weigengyu

2017-05-08 04:52:20 UTC

Permalink

Hi,

A question related.
It needs clarifying the CoAP End-to-End Semancetics for the following scenarios:

1. CoAP EP1/UDP ----> CoAP to CoAP Proxy ----> CoAP EP2/UDP
2. CoAP EP1/UDP ----> CoAP to CoAP Proxy ----> CoAP EP2/TCP

The CoAP semantics including request/response and messages is defined in RFC7252.
How the CoAP end-to-end semantics keep in a way among three cases.

The CoAP end-to-end semancetics is required to keep
(1) between CoAP EP1 and CoAP EP2,
(2) or between CoAP EP1 and C2C proxy, and between C2C Proxy and CoAP EP2,
in another wors, the CoAP is hop-by-hop.
(3) or both (1) and (2).

For (1), the proxy needs just to forward the message what received.
For (2), the proxy needs to make a CoAP message by its decisions.
For (3), the proxy needs to have functions of (1) and (2) and to distinguish (1) from (2).

I wonder which is required? What needs to support?

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications

From: Spencer Dawkins at IETF
Sent: Monday, May 08, 2017 11:17 AM
To: Yoshifumi Nishida
Cc: tsv-***@ietf.org ; draft-ietf-core-coap-tcp-***@ietf.org ; ***@ietf.org ; ***@ietf.org
Subject: Re: [core] [Tsv-art] TSV-ART review of draft-ietf-core-coap-tcp-tls-07

Hi, Yoshi,

On Sat, Apr 29, 2017 at 11:24 PM, Yoshifumi Nishida <***@sfc.wide.ad.jp> wrote:

Hello,
As far as I've read -08 draft, I think this point has not been addressed yet. I hope some folks could elaborate a bit more if they think this is not an important point for the draft.

I've seen the subsequent e-mails in reply to yours, but it's not obvious to me whether you think this point was addressed after reading those e-mails.

What do you think?

Thanks,

Spencer

--
Yoshi

On Fri, Apr 21, 2017 at 2:57 PM, Brian Raymor <***@microsoft.com> wrote:

I think that I understand your perceptions better. Prior to adoption of coap-tcp-tls and before I was active in the WG, I recall discussions related to the confusion over application vs transport reliability in CoAP especially as related to CON and NON. What was intended?

Tim Carey outlined some concerns in:

https://tools.ietf.org/html/draft-carey-core-std-msg-vs-trans-adapt-00#section-2

This topic was presented in detail at IETF 93 - https://www.ietf.org/proceedings/93/slides/slides-93-core-0.pdf - starting on slide 23.