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/
- [Roll] proposal for common table of contents for … Michael Richardson
- Re: [Roll] proposal for common table of contents … Anders Brandt
- Re: [Roll] proposal for common table of contents … Michael Richardson
- Re: [Roll] proposal for common table of contents … Anders Brandt
- Re: [Roll] proposal for common table of contents … Michael Richardson
- Re: [Roll] proposal for common table of contents … Abdussalam Baryun
- Re: [Roll] proposal for common table of contents … Michael Richardson