Skip to main content

Building Power-Efficient Constrained Application Protocol (CoAP) Devices for Cellular Networks
draft-ietf-lwig-cellular-06

Yes

(Brian Haberman)

No Objection

(Alia Atlas)
(Alvaro Retana)
(Barry Leiba)
(Deborah Brungard)
(Joel Jaeggli)
(Kathleen Moriarty)
(Terry Manderson)

Recuse

(Jari Arkko)

Note: This ballot was opened for revision 05 and is now closed.

Brian Haberman Former IESG member
Yes
Yes (for -05) Unknown

                            
Spencer Dawkins Former IESG member
Yes
Yes (2015-09-16 for -05) Unknown
Nice work. 

I had a couple of thoughts while reading through it. 

This is a very useful draft. Thank you for producing it.

You mention the difficulty of acting as a server behind a NAT. I wonder if you might also mention the power drain that's often required to maintain port bindings on NATs when a device is not actively transmitting. That may not be a problem for sleepy devices, but might be for real-time reachable devices.

In this text

Manufacturer Server

      The DNS name of the directory or proxy is hardwired to the
      software by the manufacturer, and the directory or proxy is
      actually run by the manufacturer.  This approach is suitable in
      many consumer usage scenarios, where it would be unreasonable to
      assume that the consumer runs any specific network services.  The
      manufacturer's web interface and the directory/proxy servers can
      co-operate to provide the desired functionality to the end user.
      For instance, the end user can register a device identity in the
      manufacturer's web interface and ask specific actions to be taken
      when the device does something.

   Delegating Manufacturer Server

      The DNS name of the directory or proxy is hardwired to the
      software by the manufacturer, but this directory or proxy merely
      redirects the request to a directory or proxy run by the whoever
      bought the device.  This approach is suitable in many enterprise
      environments, as it allows the enterprise to be in charge of
      actual data collection and device registries; only the initial
      bootstrap goes through the manufacturer.  In many cases there are
      even legal requirements (such as EU privacy laws) that prevent
      providing unnecessary information to third parties.
      
The reference to legal requirements under "Delegating Manufacturer Server" made me think this was only appliable to "Delegating Manufacturer Server", but not to "Manufacturer Server". Is that the case? Or is it applicable whether the Manufacturer Server is delegating or not?

I share Stephen's comment on Figure 1.
Alia Atlas Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Ben Campbell Former IESG member
No Objection
No Objection (2015-09-16 for -05) Unknown
I share the comments about figure 1.

-- 3, radio technology:
Can you elaborate on the meaning of "bundling applications together"? Does it mean bundling the messages together for multiple applications? Something else?

-- 7: "If sub-second response time is not
   needed, a slightly more infrequent checking process may save some
   power."
Perhaps more than slightly?

-- 7, paragraph 3:
Is the "device" in the 4th sentence the same as the "sensor"?
Deborah Brungard Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2015-09-15 for -05) Unknown

- intro: is CoAP really "point-to-point"? not sure that is a
good term to use here. I get what you mean when I get to the
end of page 6 though, but I still don't like the term as used
here.

- figure 1 doesn't tell me much to be honest, I'd say delete it
maybe or add some more text saying what it's there for.

- p6, proxies are provided for http yes, but why would they be
needed for coap? coap devices are not rendering html so don't
have a need for loads of DNS names/pictures/ads. I think that's
in the end a misleading conparison to make and would be better
omitted. (BTW, I don't mean you're trying to mislead, but  that
that comparison is likely to mislead the reader into thinking
they may get more from coap proxies than is the case.)

- p7, at end of section 3, you could (if you wanted), make the
point that "higher" layer network protocols like a DTN protocol
such as the BP could help (if deployed widely) as then
applications wouldn't assume that what they send is (almost)
immediately received. More practically, applications can
re-invent DTN functionality and get some of those benefits.

- section 5, I think it'd be worth noting that there is a need
for (but no good solution for) discovery of devices that are
manufactured by small manufs (or open source) and deployed in
small numbers. That is not the same as when a large vendor is
involved but would be worth noting.

- section 9: large numbers of esp. small battery powered
devices scattered everywhere are a significant polution threat.
(When not gathered at end of life.) That arguably ought be
noted as a reason to spend more on e.g.  PoE devices sometimes
- the overall environmental or carbon cost can be lower in the
end with a device that uses more power per hour.
Terry Manderson Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Jari Arkko Former IESG member
Recuse
Recuse (for -05) Unknown