Re: TSV-ART review of draft-ietf-core-coap-tcp-tls-07

[Yoshifumi Nishida <[e-mail]>]

Hi Brian,

On Thu, Apr 20, 2017 at 12:31 PM, Brian Raymor <[e-mail]>
wrote:

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

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.


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

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.


> > 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:
>
> I don't have a strong opinion here. Updating 7959 is fine for me if it's
clearer to CoAP people.

Thanks,
--
Yoshi