Subject: [core] Review of draft-silverajan-core-coap-alternative-transports-07

From: "Rahman, Akbar" <[email-masked]>
Date: Tue, 2 Jun 2015 05:24:14 +0000

Hi,

I had an action from the last IETF in Dallas to review the Alternative Transports draft (as recorded in the Etherpad minutes):

-----------------------------------------------------------------------------------------------------------

http://etherpad.tools.ietf.org:9000/p/notes-ietf-92-core?useMonospaceFont=true

** Alternative Transports
09:10- Alternative Transports (HT, BS)

draft-silverajan-core-coap-alternative-transports (Bill)

Longer history and gives recommendations how to design alternative transports for CoAP

Hannes: Document is a good discussion input for the design decisions. But should we produce this kind of documents?
Carsten <hat off>: Document work or result? It is important to inform people why we did specific things as we did them. Principles can be usefull for future work.
Andrew <hat off>: +1 to Carsten
Barry: For first use case, an appendix to result document would be better.

Carsten: Who would review? -> Thomas Fossati, Hannes, Simon Lemay, Akbar

-----------------------------------------------------------------------------------------------------------

Following are the comments from my review of

https://tools.ietf.org/html/draft-silverajan-core-coap-alternative-transports-07

1.       Overall, I think the draft is in good shape and I think it should progress.  Thanks to the Authors for their good work!

2.       Abstract - Editorial: 3rd sentence in Abstract is too long (i.e. run on sentence) and should be re-worded and probably split into multiple sentences.

3.       Section 1 - Reference to “non-IP network” in 2nd paragraph is unclear as the paragraph starts off by talking about the “Internet” (implying IP networks).  I am assuming the reference to non-IP network is about SMS.  If so then the subject matter should be more precisely introduced.

4.       Section 2.1 – Section refers to OMA LWM2M spec being drafted.  But I believe the v1.0 version of the spec is already released.

5.       Section 2.5 – Is there any real value for putting reference to such purely speculative ideas in an Internet-Draft?  What for example would it mean to run CoAP over Twitter?  Can Twitter really be called a transport channel?  Either the section should have more supporting description or better yet just remove from the document.

6.       Section 4.2 – It should be clarified how this scheme is backward compatible (or not) with the current URI format for UDP specified in https://tools.ietf.org/html/rfc7252#section-6.1

7.       Section 5 – Property 3 description is unclear.  In fact, contrary to the current description, there is a multicast model of request/response already supported as described in https://tools.ietf.org/html/rfc7390#section-2.5 .

8.       Section 7 – I think in fact there are many risk factors introduced when considering new transports.  For example, will it be mandatory to have a security mode with each new transport (e.g TLS for TCP)?  So this section needs significant updating.

9.       General – I was looking for some guidance on how to interpret Core Link Format (RFC 6690) with Alternate transports, but didn’t see it.  Do you think it is worth covering?

Best Regards,

Akbar

---

From: Bill Silverajan <[email-masked]>
Date: Wed, 24 Jun 2015 23:27:25 +0300

Hi Akbar,

Thanks for your thorough review and positive comments regarding the 
draft. I rectified version -08 of the Alternative Transports draft based 
on your comments. Detailed response inline:

On 2/6/15 8:24 AM, Rahman, Akbar wrote:

> 1.Overall, I think the draft is in good shape and I think it should
> progress.  Thanks to the Authors for their good work!
>
> 2.Abstract - Editorial: 3^rd sentence in Abstract is too long (i.e. run
> on sentence) and should be re-worded and probably split into multiple
> sentences.
>

It's now split and the result has also been worded to reflect the 
specific transports for each example property.

> 3.Section 1 - Reference to “non-IP network” in 2^nd paragraph is unclear
> as the paragraph starts off by talking about the “Internet” (implying IP
> networks).  I am assuming the reference to non-IP network is about SMS.
> If so then the subject matter should be more precisely introduced.
>

The reference to "non-IP network" was a legacy remnant that encompassed 
other possible radio technologies such as BLE, Zigbee smart, SMS and so 
on. I removed the phrase now, and the passage has been rewritten. For 
SMS, the phrase "cellular networks in which the Short Messaging Service 
(SMS) can be utilised" has been introduced.

> 4.Section 2.1 – Section refers to OMA LWM2M spec being drafted.  But I
> believe the v1.0 version of the spec is already released.
>

Thanks, I updated the reference.

> 5.Section 2.5 – Is there any real value for putting reference to such
> purely speculative ideas in an Internet-Draft?  What for example would
> it mean to run CoAP over Twitter?  Can Twitter really be called a
> transport channel?  Either the section should have more supporting
> description or better yet just remove from the document.
>

I thought removing the section was a far better idea, now that we have a 
clearer idea of what kinds of transport alternatives there are for CoAP.

> 6.Section 4.2 – It should be clarified how this scheme is backward
> compatible (or not) with the current URI format for UDP specified in
> https://tools.ietf.org/html/rfc7252#section-6.1
>

How about this, now in Section 4.2: "CoAP resources transported over UDP 
or DTLS must conform to Section 6 of [RFC7252] and utilise "coap" or 
"coaps" for the URI scheme, instead of "coap+udp" or "coap+dtls"?

> 7.Section 5 – Property 3 description is unclear.  In fact, contrary to
> the current description, there is a multicast model of request/response
> already supported as described in
> https://tools.ietf.org/html/rfc7390#section-2.5 .
>

This is now property 1, and rewritten to refer to rfc 7390, specifically 
its request/response model.

> 8.Section 7 – I think in fact there are many risk factors introduced
> when considering new transports.  For example, will it be mandatory to
> have a security mode with each new transport (e.g TLS for TCP)?  So this
> section needs significant updating.
>

I gave this a go and described some aspects where security must be 
considered in Section 7. However, you raised a very interesting point 
that I think should be discussed further: Should new transports for CoAP 
offer both a secure and non-secure channel? And should there be a 
correlation in the URI scheme between these (2 or more) modes?

I think it would be great to get some guidance from the WG about this.

> 9.General – I was looking for some guidance on how to interpret Core
> Link Format (RFC 6690) with Alternate transports, but didn’t see it.  Do
> you think it is worth covering?
>

It's worthwhile covering. I'm not sure whether this draft is the 
appropriate document, though. Therefore I refrained from mentioning Core 
Link formats here. In general, I assume you're implying what happens if 
links return refer to resources available on transports/URIs other than 
the original request?

Regards,
Bill

> Best Regards,
>
> Akbar
>
>
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>