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

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 05 July 2012 17:43 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2722221F8744 for <roll@ietfa.amsl.com>; Thu, 5 Jul 2012 10:43:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.626
X-Spam-Level:
X-Spam-Status: No, score=-1.626 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoXBzA6+z8iP for <roll@ietfa.amsl.com>; Thu, 5 Jul 2012 10:43:00 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id D6A9221F872A for <roll@ietf.org>; Thu, 5 Jul 2012 10:42:59 -0700 (PDT)
Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id A287A818B for <roll@ietf.org>; Thu, 5 Jul 2012 13:39:57 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 8488398C40; Thu, 5 Jul 2012 13:43:11 -0400 (EDT)
Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 68B8898C2D for <roll@ietf.org>; Thu, 5 Jul 2012 13:43:11 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: roll@ietf.org
In-Reply-To: <10134.1337103877@marajade.sandelman.ca>
References: <20120430114209.21250.82110.idtracker@ietfa.amsl.com> <18151.1335822136@marajade.sandelman.ca> <BD8E8F5A-E564-49C9-96D0-55B76DA23AB0@cisco.com> <10134.1337103877@marajade.sandelman.ca>
X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Thu, 05 Jul 2012 13:43:11 -0400
Message-ID: <32407.1341510191@marajade.sandelman.ca>
Sender: mcr@sandelman.ca
Subject: Re: [Roll] proposal for common table of contents for applicability statements
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jul 2012 17:43:01 -0000

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 <mcr+IETF@sandelman.ca>;, Sandelman Software Works 
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/