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

[Robert Cragie <[e-mail]>]

Some comments on the charter.

    * Generally, I like bullet points for clarity
    * Para 1 could do with a more bullet points. Suggested change:

        "Applications are being developed for networks where a
        substantial number of nodes:

        * Use very limited packet sizes
        * Have limited range
        * Exhibit a high degree of packet loss
        * Have restrictions on available power budget
        * May be powered off at any point in time but periodically "wake
        up" for brief periods of time
        * Have restrictions on the complexity that can be supported due
        to limited code size and limited RAM

        More generally, we speak of constrained-node/network (CNN)
        applications whenever at least some of the nodes and networks
        involved exhibit these characteristics.  This WG is
        concentrating on requirements from energy (e.g. Smart Energy
        2.0) and building management applications."

    * +1 for CoNet
    * +1 for CoNode. The idea of a "CoNode" makes more sense than a
      CoNet. It is possible to imagine a CoNet with nodes which don't
      have all the properties of a CoNode and thus could communicate
      using a different application protocol, i.e. one more familiar to
      the wider Internet (e.g. WS-*, HTTP REST). Do we only want to
      consider a CoNet containining CoNodes? If so, these non-CoNodes
      are probably out of scope of the discussion.
    * Para 2: "are becoming increasing important" -> "are becoming
      increasingly important"
    * Para 2: "a framework a limited class of applications" -> "a
      framework for a limited class of applications"
    * Para 3 could do with more bullet points. Suggested change:

        "The general architecture consists of nodes on the CNN, called
        Devices, that have one or more Resources that may represent
        sensors and actuators or other parameters.

        * Devices send messages to change Resources on other Devices
        * Devices send messages to query Resources on other Devices
        * Devices can send notifications about changed Resource values
        to subscribed Devices.

        In other words, the architecture requires push, pull and a
        notify approach to manipulating Resources.

        As part of the framework for building these applications, the WG
        will define a Constrained-node/network Application Protocol
        (CoAP) for manipulation of Resources on Devices. The framework
        will also specify a way to define new interface profiles that
        can be defined by vendors and other standards bodies to define
        the particular Resources on a Device and what manipulation is
        possible."

    * Should Device be CoDevice (i.e. CoNode + application functionality)?
    * "CoAP will be designed to be used between Devices (intra- or
      inter-CNN) as well as between Devices and general nodes on the
      Internet.". This suggests that we are defining an application
      protocol which would be suited to the wider Internet. However,
      then there is the introduction of the CoGII. This brings me back
      to my earlier post regarding intersection - are we trying to
      achieve this? Or is the CoAP really aimed at CoNodes only? In this
      case, the description as is of the CoGII is about right, i.e. an
      application layer gateway.
    * If we are considering a CoNet with CoNodes and non-CoNodes, there
      could also be a more general router between the non-CoNodes and
      the wider Internet using a different application protocol (e.g.
      WS-*, HTTP REST)
    * I agree with other comments re. specifiying EXI - not necessary
      for the purposes of the charter. State the requirement and in
      development state that EXI would meet the requirement
    * I think if you have the notion of the CoGII you can really come up
      with any binding you want so whilst I think HTTP REST may be the
      most important, others should become second-class citizens at this
      stage.
    * Commissioning methodologies. Whilst important, the suggestions
      seem to me too specific
    * Duckling mode general procedure is quite specific but the details
      are vague. Imprinting a shared secret seems like some sort of
      magic the way it is described
    * Out-of-band key mode. Too specific with regard to barcodes/URLs.
      There are many ways to set up a shared secret out-of-band
    * Certificate mode. Again, too specific with regard to barcodes and
      certificate replacement. Other issues need to be considered with
      certificates too (authentication, revocation etc.)
    * "In all modes, once Device A and Device B have formed a secure
      connection with Device C, Device C can be used to transitively
      introduce A and B so now A and B have a secure connection with C."
      I don't quite get this statement - should it say "so now A and B
      have a secure connection with each other"?
    * The use of a heavyweight syntax such as CMS (rfc5652) seems at
      odds with the aims of CoAP. In conjunction with a CoGII, there may
      be no need for such protection - symmetric key frame protection
      such as AES-CCM may well suffice.

In summary, my main question is: Do we want to limit the CoNet to just 
CoNodes and a (optional) CoGII? Is it enough to acknowledge that there 
will be another non-CoNode application protocol, which is suitable for 
some nodes in, say, 6LoWPAN, i.e. those with enough horsepower, power 
budget, link reliability to be able to natively handle RESTful HTTP/TCP?

Robert

Carsten Bormann wrote:
> I have put a new version of the WG charter proposal on the wiki page at
> http://6lowapp.net
> =
> http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp
> (charter text is at the end of the page).
>
> Obviously, I could not pick up every comment that was on the list 
> (they were partially going in conflicting directions), but please do 
> comment on the new version.
>
> Gruesse, Carsten
>
> _______________________________________________
> 6lowapp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lowapp
>