ietf
[Top] [All Lists]

Re: [core] [Tsv-art] TSV-ART review of draft-ietf-core-coap-tcp-tls-07

2017-05-08 00:00:44
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-art(_at_)ietf(_dot_)org ; 
draft-ietf-core-coap-tcp-tls(_at_)ietf(_dot_)org ; core(_at_)ietf(_dot_)org ; 
ietf(_at_)ietf(_dot_)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 
<nishida(_at_)sfc(_dot_)wide(_dot_)ad(_dot_)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 
<Brian(_dot_)Raymor(_at_)microsoft(_dot_)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.



    And in a related thread on the mailing list back in 2015 - 
https://www.ietf.org/mail-archive/web/core/current/msg06280.html - Carsten 
responded:



    > 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:nishida(_at_)sfc(_dot_)wide(_dot_)ad(_dot_)jp] 
    Sent: Friday, April 21, 2017 2:08 PM
    To: Brian Raymor <Brian(_dot_)Raymor(_at_)microsoft(_dot_)com>
    Cc: Yoshifumi Nishida <nishida(_at_)sfc(_dot_)wide(_dot_)ad(_dot_)jp>; 
tsv-art(_at_)ietf(_dot_)org; draft-ietf-core-coap-tcp-tls(_at_)ietf(_dot_)org; 
core(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)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 
<Brian(_dot_)Raymor(_at_)microsoft(_dot_)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.



      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. 



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



      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





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





--------------------------------------------------------------------------------
_______________________________________________
core mailing list
core(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/core