Re: [6lowapp] Next version of charter proposal up on 6lowapp.net

[Arjun Roychowdhury <[e-mail]>]

>
> There seems to be a wide divergence of opinion on the meaning of
> "constrained", from full-on WS* to unable to contain any strings.  I would
> offer a working definition, borrowed from Einstein, that CoNodes should
> be "as simple as possible, but no simpler."
>

ARC> agree.


>
> I believe that by moving as much functionality as possible from the
> CoNodes into the CoGII nodes, we end up with a lower total system cost
> and, ultimately, greater ubiquity. The definition of CoNode should admit
> wired (e.g. power line connected) as well as wireless Devices.
>

ARC> This is usually the same argument for a network full of
'interoperability gateways' though (and the core principle of dumb nodes,
intelligent networks). The problem with heavy reliance on CoGII is that
while it results in short term low system cost, over a longer term, these
CoGII elements become single point of failures, complicate network
management and make the end-end architecture brittle. Pushing functionality
by default to CoGII also results in quicker architecture and deployment -
but in the longer run, we have a system that is full of technology islands
patched together with frail bridges.

So the CoGII approach, to me, really should be "as few as possible and no
more"


>
> As a general approach to foster consensus, I'd suggest the WG might
> add to its "objectives and architecture" document a specification of
> which services must be present in a CoNode and which must be
> present in the CoGII node (and how the CoGII node differs from a
> ROLL node; e.g. where does header de/compression reside?)
>



> I support the viewpoint that a collection of CoNodes should be able to
> implement some non-trivial applications without requiring a CoGII
> node (e.g. the "one light, one switch" scenario).  Others may disagree
> with this (perhaps even strongly) but I believe statements of this sort
> will help focus the debate and lead to the the ultimate meaning of
> "constrained".
>

ARC> +1


>
> I personally find it easier in the early stages to think in terms of
> abstract
> services rather than specific protocols.  For example, "BACnet relies on
> the ability to enumerate all the devices on the network and to query the
> value of objects within a device."  The first is accomplished using the
> "Who-is" or "Who-has" services (indeed, one might argue that having
> two such mechanisms runs counter to interoperability) while the second
> is accomplished using the "ReadProperty" service.  If we can reach
> consensus on which services we need then mapping to specific
> implementations might be easier.
>

ARC> +1


>
> Lastly, might I suggest using in the charter "CoNet" in place of "CNN"?
>
> Respectfully submitted, Kerry Lynn
>
> --
>
Arjun Roychowdhury