[Lwip] Spencer Dawkins' Yes on draft-ietf-lwig-cellular-05: (with COMMENT)

["Spencer Dawkins" <[e-mail]>]

Spencer Dawkins has entered the following ballot position for
draft-ietf-lwig-cellular-05: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lwig-cellular/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.