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

From: Michael Richardson <[email-masked]>
Date: Thu, 05 Jul 2012 13:43:11 -0400

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/

---

From: Michael Richardson <[email-masked]>
Date: Tue, 31 Jul 2012 20:26:29 -0400

I have posted
  http://datatracker.ietf.org/doc/draft-richardson-roll-applicability-template

this includes the text that I had posted on July 5.
It includes quite a number of places where security parameters or
statements must be filled in. 

I would like some comments about what pieces I've missed, particularly
From people with more Zigbee and 802.15.4 clue than I have.