Subject: Re: [Roll] proposal for common table of contents for applicability statements

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 6 Jul 2012 10:24:53 +0200

+1

I will do my best to participate and review, thanking you,

Regards
AB

> Date: Thu, 05 Jul 2012 13:43:11 -0400
> From: Michael Richardson <[email-masked]>
> To: [email-masked]
> Subject: Re: [Roll] proposal for common table of contents for
>         applicability   statements
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="us-ascii"
>
>
> Here is my proposal for a common table of contents for applicability
> statements.  I will turn this into an ID tomorrow.
>
> Proposed template table of contents for applicability statements.
>
>    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
>      1.1.  Requirements Language  (RFC2119 reference)
>      1.2.  References/Overview of requirements documents, both
>            IETF and industry group.  (two pages maximum.  This text
>            should be (very) technical, should be aimed at IETF
> *participants*,
>            not industry group participants, and should explain this
>            industries' specific issues)
>      1.3   Out of scope requirements.
>            This should list other documents (if any) which deal with
>            situations where things are not in scope for this document.
>
>            (For instance, the AMI document tries to cover both line-powered
>            urban metering networks, and energy-constrained metering
> networks,
>            and also tries to deal with rural requirements.  This should
>            be three or four documents, so this section should list the
>            limits of what this document covers)
>
>    2.  Deployment Scenario
>      2.1.  Network Topologies
>        I would like to see a single scenario described, with possibly
>        multiple topologies that a single utility would employ.
>
>      2.2.  Traffic Characteristics  . . . . . . . . . . . . . . . . .  6
>        Explain what kind of traffic is being transmitted, where it is
>        initiated, and what kinds of protocols (CoAP, multicast, HTTPS,
> etc.)
>        are being used.  Explain what assumptions are being made about
>        authentication and authorization in those protocols.
>
>      for instance:
>      2.2.1.  General
>      2.2.2.  Source-sink (SS) communication paradigm
>      2.2.3.  Publish-subscribe (PS, or pub/sub) communication
>            paradigm
>      2.2.4.  Peer-to-peer (P2P) communication paradigm
>      2.2.5.  Peer-to-multipeer (P2MP) communication paradigm
>      2.2.6.  Additional considerations: Duocast and N-cast
>      2.2.7.  RPL applicability per communication paradigm
>
>
>      2.3 Layer 2 applicability.
>        Explain what layer-2 technologies this statement applies to, and
>        if there are options, they should be listed generally here, and
>        specifically in section 4.2.
>
>    3.  Using RPL to Meet Functional Requirements
>
>      This should explain in general terms how RPL is going to be used
>      in this network topology.  If trees that are multiple
>      layers deep are expected, then this should be described so that the
> fan
>      out is understood.
>      Some sample topologies (from simulations) should be explained, perhaps
>      with images references from other publications.
>
>      This section should tell an *implementer* in a lab, having a
> simulation
>      tool or a building/city/etc. to use as a testbed, how to construct
>      an LLN of sufficient complexity (but not too much) to validate an
>      implementation.
>
>    4.  RPL Profile
>      This section should list the various features of RPL plus other layers
>      of the LLN, and how they will be used.
>
>      4.1.  RPL Features
>        4.1.1.  RPL Instances
>        4.1.2.  Storing vs. Non-Storing Mode
>        4.1.3.  DAO Policy
>        4.1.4.  Path Metrics
>        4.1.5.  Objective Function
>        4.1.6.  DODAG Repair
>        4.1.7.  Multicast
>        4.1.8.  Security
>        4.1.9.  P2P communications
>
>      4.2.  Layer-two features
>        4.2.1.  Need layer-2 expert here.
>        4.2.2.  Security functions provided by layer-2.
>        4.2.3.  6LowPAN options assumed.
>        4.2.4.  MLE and other things
>
>       4.3.  Recommended Configuration Defaults and Ranges
>        4.3.1.  Trickle Parameters
>        4.3.2.  Other Parameters
>
>    5.  Manageability Considerations
>    6.  Security Considerations
>      6.1. Security Considerations during initial deployment.
>         (This section explains how nodes get their initial trust anchors,
>         initial network keys.  It explains if this happens at the factory,
>         in a deployment truck, if it is done in the field, perhaps
>         like
>
> http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/papers/CullenJennings.pdf)
>
>      6.2. Security Considerations during incremental deployment
>         (This section explains how that replaces a failed node takes
>         on the dead nodes' identity, or not.  How are nodes retired.
>         How are nodes removed if they are compromised)
>
>    7.  Other Related Protocols
>    8.  IANA Considerations
>    9.  Acknowledgements
>    10. References
>      10.1. Informative References
>      10.2. Normative References
>
>
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works
> IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 307 bytes
> Desc: not available
> URL:
> <http://www.ietf.org/mail-archive/web/roll/attachments/20120705/81bc77ee/attachment.sig>
>
> ------------------------------
>