Subject: [core] Review of draft-becker-core-coap-sms-gprs-06

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Mon, 20 Mar 2017 18:39:49 +0000

Dear authors,

Thanks very much for keeping the ball rolling.

I've just finished reading -06 and have few comments.  See below.

Cheers, thanks,
t

== S3.1 ==
Last para: the text can be a bit misleading:
“[...] If the CoAP Client has sent a confirmable message, the CoAP Server MUST use a separate SMS message to transmit the ACK.”
The ACK *can* be piggybacked to the response. The MUST is for the sender to not trade an SMS-STATUS-REPORT for an application layer ACK.  Might be worth re-phrasing?

== S4 ==
First para:
“[...] the two other encodings are dependent on the language that needs to be encoded [...]”
8-bit data is not dependent on language (in fact it's not intended for text messages).

Second para:
“[...] Since not all MSs support 8 bit short message encoding, the preferred encoding scheme for CoAP messages over SMS is therefore 7 bit, […]”
I'm not sure we should prefer 7-bit over binary.  Maybe a better strategy would be to start optimistic (8-bit data) and fall back to one of the 7-bit ASCII encoding variants if that doesn't work.  The reasoning is that having 10-20 bytes more here can make a real difference.

When unpacking, how is the receiver supposed to know which of the three different encodings (b64, b85 and ASCII-optimized) has been used by the sender?

== S6 ==
I’m having a bit of trouble with the last para:
“To allow the CoAP client to detect that the short message contains a CoAP message, the TP-DATA-Coding-Scheme SHOULD be included.”
TP-DCS is a mandatory field in both SMS-SUBMIT and SMS-DELIVER messages, how can this be a SHOULD?  And: how DCS is supposed to act as an upper layer protocol identifier?

== S7.1 ==
Since the scope is generic "alternative transports", it'd seem wise to also have a Response-To-Uri-Scheme option as well?

"The options SHOULD NOT be used in the response."
Why is this not a MUST NOT?  I.e., when is it OK to use these options in a response?

== S8 ==
Do we need muxing?  If so, how can this be achieved (e.g., https://tools.ietf.org/html/rfc7925#appendix-A.3)?

== S9 ==
s/RESPONSE_TIMEOUT/ACK_TIMEOUT?

The text is still a tad hand-wavy; I'd like us to provide some guidance at least.  Extreme RTT variance is the killer here, but you can usually get around that with a SLA.
(A bit tangent, but another thing that might be worth taking into consideration in the draft is throughput guarantees/requirements.)

== S11 ==
It might be worth adding some text re:
- Spoofing TP-OA (not particularly easy, but certainly possible);
- Adding a reply-address UDH which is different from TP-OA;
- Using DTLS on top of the transport (see RFC 7925).

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 20 Mar 2017 20:24:55 +0100

Hi Thomas,

Good points.

Picking two up them:

> On 20 Mar 2017, at 19:39, Fossati, Thomas (Nokia - GB) <[email-masked]> wrote:
> 

One of the 7-bit variants (ASCII-optimized) may actually use less space than the 8-bit variants, depending on the data, so that may not be as clear-cut.

In any case, a device offering an SMS URI needs to be able to express whether it can accept 8-bit SMS.  We currently don’t have a good way to express this in an SMS URI, which would provide a client to hint to go with.

> When unpacking, how is the receiver supposed to know which of the three different encodings (b64, b85 and ASCII-optimized) has been used by the sender?

I think the WG should decide that in the standard.
(I’m obviously biased to ASCII-optimized, as it wins on almost all characteristics.)

> TP-DCS is a mandatory field in both SMS-SUBMIT and SMS-DELIVER messages, how can this be a SHOULD?  And: how DCS is supposed to act as an upper layer protocol identifier?

DCS will tell you whether the SMS was 7-bit or 8-bit.

The big issue is how a device finds out that this was a CoAP SMS in the first place; I’m not sure we have a very good multiplexing point for this.  Some heuristics may be required.

Grüße, Carsten

---

From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" <[email-masked]>
Date: Tue, 21 Mar 2017 12:24:20 +0000

Hi Carsten,

> On 20/03/2017 19:24, "Carsten Bormann" <[email-masked]> wrote:

For cipher-text PDUs -- e.g., if using DTLS or OSCOAP -- binary would probably make more sense.

> In any case, a device offering an SMS URI needs to be able to express whether it can accept 8-bit SMS.  We currently don’t have a good way to express this in an SMS URI, which would provide a clien…

I agree with you that encoding should be made visible upfront -- RD / link-format looking like obvious candidates.  This is probably part of the wider story about discovery, which likely includes other dimensions, e.g., de-muxing.

If not available upfront, a default encoding + fallback strategy seems like an acceptable compromise to me.  (We need to check whether SUBMIT & STATUS reports have all the information needed to take an informed decision.)

> (I’m obviously biased to ASCII-optimized, as it wins on almost all characteristics.)

Happy to go with that.  (It'd be nice to compare the encoders on a representative CoAP corpus.)

> DCS will tell you whether the SMS was 7-bit or 8-bit.

Sure, but this is a bit too coarse grained to act as an application protocol id.

> The big issue is how a device finds out that this was a CoAP SMS in the first place; I’m not sure we have a very good multiplexing point for this.  Some heuristics may be required.

My preference would be explicit mux signals over implicit/heuristics, even if that costs a few bytes.

Cheers, thanks,
t

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 21 Mar 2017 18:28:16 +0100

Hi Thomas,

> For cipher-text PDUs -- e.g., if using DTLS or OSCOAP -- binary would probably make more sense.

Yes.  (If your platform can do it.  Somewhat surprising [to me — we used binary SMS in the 1990s already] feedback from implementers about this was the original reason to do ASCII-optimized.)

> Happy to go with that.  (It'd be nice to compare the encoders on a representative CoAP corpus.)

That would be the right way to make a decision.  But note that ASCII-optimized in its worst case is as good as b64, so you can discard that if space efficiency is your major concern.  B85 is a bit more likely to occasionally beat ASCII-optimized.

Where do we get a good corpus of CoAP messages?

> Sure, but this is a bit too coarse grained to act as an application protocol id.

Right.

> My preference would be explicit mux signals over implicit/heuristics, even if that costs a few bytes.

Well, it seems there is no mux point that can be employed here.  We could define magic numbers/signatures (which is a heuristic, but can be pretty good if done right).

Grüße, Carsten

---

From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" <[email-masked]>
Date: Wed, 22 Mar 2017 12:44:18 +0000

Hi Carsten,

> Where do we get a good corpus of CoAP messages?

That's a very good question.
I was thinking that maybe we could start from pcap captures taken at ETSI interop events.
Do you think it’d be a problem from a legal viewpoint?  Or that they might be not representative enough?

Cheers, t

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 22 Mar 2017 13:49:16 +0100

> On 22 Mar 2017, at 13:44, Fossati, Thomas (Nokia - GB/Cambridge, UK) <[email-masked]> wrote:
> 
> Hi Carsten,
> 

Those would be a faithful mirror of what we wrote in the test descriptions.
(I’m also not aware of anyone keeping a sizable collection of these.)

A better “corpus” could be had from dreaming up a few use cases that are likely to use SMS, design exchanges for those, and capture those on a platform such as coap.me.

Grüße, Carsten

---

From: "weigengyu" <[email-masked]>
Date: Thu, 23 Mar 2017 14:58:40 +0800

Hi Carsten and all,

About CoAP/SMS or CoAP/DTLS/SMS, we may do some contributions.

The following is the abstract of my master course student's thesis, just 
completed this month.

Research and Development of Secure SMS for M2M and CoAP
ABSTRACT
The technology of Internet of Things is changing fast, and the new 
application is built on the network environment that based on the limited 
network and Internet integration. The Internet Engineering Task Force (IETF) 
CoRE defines a restricted application protocol (CoAP) for a large number of 
nodes and networks in the Internet of Things that rely heavily on 
battery-powered, processor-capable, and communication-constrained 
capabilities. The Open Mobile Alliance (OMA) proposed a new lightweight 
machine-to-machine (LWM2M) communication protocol standard, which clearly 
defined the protocol stack based on mobile short message to support the 
application of Internet of Things for CoAP / SMS (SMS) or CoAP / DTLS / SMS 
protocol. Datagram Transport Layer Security Protocol (DTLS) has become an 
important measure to construct "secure short message".
In this paper , the DTLS protocol based on "secure short message" , the 
communication framework and application of CoAP / SMS and CoAP / DTLS / SMS 
using short message are studied and developed. The main contributions of 
this paper are studying and developing the secure short message based on 
DTLS, and a practical application built on it, which are of great 
significance to the study of Internet of Things based on secure short 
message.
KEY WORDS: iot、m2m、coap、dtls、sms

The implementations did by extending Californium (Cf)  core and tested on 
Andoird.

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件----- 
From: Carsten Bormann
Sent: Wednesday, March 22, 2017 8:49 PM
To: Fossati, Thomas (Nokia - GB/Cambridge, UK)
Cc: [email-masked] ; [email-masked]
Subject: Re: [core] Review of draft-becker-core-coap-sms-gprs-06

A better “corpus” could be had from dreaming up a few use cases that are 
likely to use SMS, design exchanges for those, and capture those on a 
platform such as coap.me.

Grüße, Carsten

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

---

From: "Kepeng Li" <[email-masked]>
Date: Thu, 23 Mar 2017 20:44:19 +0800

Good to hear about that.

About the thesis, is it in Chinese or English? If it is published already,
can you send us the link?

I would be interested to read the thesis, and get some ideas.

Also welcome to contribute to the coap-sms draft.

Thanks,

Kind Regards
Kepeng

在 23/03/2017, 2:58 PM， "weigengyu" <[email-masked]> 写入:

>> I was thinking that maybe we could start from pcap captures taken at
>>ETSI 
>> interop events.
>

---

From: "weigengyu" <[email-masked]>
Date: Tue, 28 Mar 2017 12:26:48 +0800

Hi Kepeng,

It is in Chinese.  It will be accessed in the Lab of BUPT.

I will send you a PDF copy in another email.

Regards,

Gengyu WEI
-----原始邮件----- 
From: Kepeng Li
Sent: Thursday, March 23, 2017 8:44 PM
To: weigengyu ; Carsten Bormann ; Fossati, Thomas (Nokia - GB/Cambridge, UK)
Cc: [email-masked] ; [email-masked]
Subject: Re: [core] Review of draft-becker-core-coap-sms-gprs-06

Good to hear about that.

Thanks,

Kind Regards
Kepeng