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

[Fossati, Thomas (Nokia - GB)]

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

[Carsten Bormann]

Hi Thomas,

Good points.

Post by Fossati, Thomas (Nokia - GB)
“[...] 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.

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.

Post by Fossati, Thomas (Nokia - GB)
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.)

Post by Fossati, Thomas (Nokia - GB)
== S6 ==
“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?

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

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

Hi Carsten,

Post by Carsten Bormann

Post by Fossati, Thomas (Nokia - GB)
“[...] 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.

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.

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

Post by Carsten Bormann
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.

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

Post by Carsten Bormann

Post by Fossati, Thomas (Nokia - GB)
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.)

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

Post by Carsten Bormann

Post by Fossati, Thomas (Nokia - GB)
== S6 ==
“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?

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.

Post by Carsten Bormann
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

[Carsten Bormann]

Hi Thomas,

Post by Fossati, Thomas (Nokia - GB/Cambridge, UK)

Post by Carsten Bormann

Post by Fossati, Thomas (Nokia - GB)
“[...] 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.

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.

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

Post by Fossati, Thomas (Nokia - GB/Cambridge, UK)

Post by Carsten Bormann
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.

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

Post by Carsten Bormann

Post by Fossati, Thomas (Nokia - GB)
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.)

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?

Post by Fossati, Thomas (Nokia - GB/Cambridge, UK)

Post by Carsten Bormann

Post by Fossati, Thomas (Nokia - GB)
== S6 ==
“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?

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.

Right.

Post by Fossati, Thomas (Nokia - GB/Cambridge, UK)

Post by Carsten Bormann
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.

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

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

Hi Carsten,

Post by Carsten Bormann
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

[Carsten Bormann]

Post by Fossati, Thomas (Nokia - GB/Cambridge, UK)
Hi Carsten,

Post by Carsten Bormann
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.

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

[weigengyu]

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: draft-becker-core-coap-sms-***@ietf.org ; ***@ietf.org
Subject: Re: [core] Review of draft-becker-core-coap-sms-gprs-06

On 22 Mar 2017, at 13:44, Fossati, Thomas (Nokia - GB/Cambridge, UK)
Hi Carsten,

Post by Carsten Bormann
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.

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

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

[Kepeng Li]

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

Post by weigengyu
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)
Subject: Re: [core] Review of draft-becker-core-coap-sms-gprs-06

On 22 Mar 2017, at 13:44, Fossati, Thomas (Nokia - GB/Cambridge, UK)
Hi Carsten,

Post by Carsten Bormann
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.

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
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

[weigengyu]

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
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件-----
From: Kepeng Li
Sent: Thursday, March 23, 2017 8:44 PM
To: weigengyu ; Carsten Bormann ; Fossati, Thomas (Nokia - GB/Cambridge, UK)
Cc: draft-becker-core-coap-sms-***@ietf.org ; ***@ietf.org
Subject: Re: [core] Review of draft-becker-core-coap-sms-gprs-06

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

Post by weigengyu
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)
Subject: Re: [core] Review of draft-becker-core-coap-sms-gprs-06

On 22 Mar 2017, at 13:44, Fossati, Thomas (Nokia - GB/Cambridge, UK)
Hi Carsten,

Post by Carsten Bormann
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.

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
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core