Re: [Lwip] Stephen Farrell's No Objection on draft-ietf-lwig-cellular-05: (with COMMENT)

[Jari Arkko <[e-mail]>]

Stephen,

Ari and I were preparing the final changes to the draft
for the RFC editor today, and as a part of that I promised
to reply to your comments, Stephen. Thanks for the
review!

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

CoAP is not point-to-point, we were referring to the cellular
networks and their communication model to individual
devices. If you read this wrong, it means we should
write the text better...

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

I have no strong opinion on this, but it was there to provide
an overview of the kind of strategies one can use to
manage power and communications in different situations.
It is possible that it is too high level, of course.

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

I think you point that this is a not a good example is valid,
but the general point that some tasks can be hosted on
(other) network devices is still valid. Perhaps a reformulation
of this paragraph in that light would help.

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

I think that would be a reasonable point to add. (If done
in a concise manner.)

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

Agreed.

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

True, but IMHO outside the scope of this document.

Jari