ietf
[Top] [All Lists]

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

2017-05-08 04:45:42
Hi, 

The clairification raised is my question. 

We did implement the protocol as the senarios described.
The problems were we met, not be thought out. 

I wish there will be an answer. 

Regards, 

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

From: Yoshifumi Nishida 
Sent: Monday, May 08, 2017 3:49 PM
To: Carsten Bormann 
Cc: ietf(_at_)ietf(_dot_)org ; Yoshifumi Nishida ; 
draft-ietf-core-coap-tcp-tls(_at_)ietf(_dot_)org ; Spencer Dawkins at IETF ; 
core(_at_)ietf(_dot_)org ; tsv-art(_at_)ietf(_dot_)org 
Subject: Re: [core] [Tsv-art] TSV-ART review of draft-ietf-core-coap-tcp-tls-07

Hi Carsten, 

Great. I will take a look at it when it's published.
Thanks for the efforts!
--
Yoshi 

On Mon, May 8, 2017 at 12:31 AM, Carsten Bormann <cabo(_at_)tzi(_dot_)org> 
wrote:

  Hi Spencer,

  I’m not Yoshi :-), but I just have started working on an update of
  https://lwig-wg.github.io/coap/#rfc.section.6
  with some of the new information that relates to CoAP over reliable; I hope 
that I will be able to push this during this week.

  Note that CoAP over TCP/TLS/WS does address application layer acknowledgement 
beyond the request-response acknowledgement semantics by introducing the 
custody option of the PING/PONG signaling messages.  This may be useful in 
compensating the decrease of information available to the CoAP application as a 
result of moving some of the transport functionality into TCP.

  Grüße, Carsten




  > On May 8, 2017, at 05:17, Spencer Dawkins at IETF 
<spencerdawkins(_dot_)ietf(_at_)gmail(_dot_)com> wrote:
  >
  > 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


  _______________________________________________
  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