[Roll] proposal for common table of contents for applicability statements
Michael Richardson <mcr+ietf@sandelman.ca> Tue, 15 May 2012 17:44 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 A65F521F86CA for <roll@ietfa.amsl.com>; Tue, 15 May 2012 10:44:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.688
X-Spam-Level:
X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[AWL=0.266, 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 gU1y-I6f2pdc for <roll@ietfa.amsl.com>; Tue, 15 May 2012 10:44:39 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id B291A21F86BA for <roll@ietf.org>; Tue, 15 May 2012 10:44:39 -0700 (PDT)
Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 4BA868398 for <roll@ietf.org>; Tue, 15 May 2012 13:43:21 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 27AEF98B98; Tue, 15 May 2012 13:44:37 -0400 (EDT)
Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 247CF98281 for <roll@ietf.org>; Tue, 15 May 2012 13:44:37 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: roll@ietf.org
In-Reply-To: <BD8E8F5A-E564-49C9-96D0-55B76DA23AB0@cisco.com>
References: <20120430114209.21250.82110.idtracker@ietfa.amsl.com> <18151.1335822136@marajade.sandelman.ca> <BD8E8F5A-E564-49C9-96D0-55B76DA23AB0@cisco.com>
X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 15 May 2012 13:44:37 -0400
Message-ID: <10134.1337103877@marajade.sandelman.ca>
Sender: mcr@sandelman.ca
Subject: [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: Tue, 15 May 2012 17:44:40 -0000
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here is the table of contents from each of the applicability statements. I thought we had a third applicability statement as an independant draft, but I couldn't find one. We should have a building/home applicability statement. I feel that these two applicability statements are over broad, and that each should be split into two or three statements. In particular, I think that Energy-Constrained and Energy-Rich networks should be split into different documents as they have vastly different requirements. It may be that there is a further split for networks that are dense (urban) vs those that are less dense (suburban or rural). A major purpose of these documents is to permit a utility (etc.) to be able to write an RFP to procure equipment from multiple vendors that can interoperate. (there are NAFTA, GATT, etc. that governments needs to comply to, which an RFC easily satisfies) As such, there needs to be enough information as to the profile of RPL to be deployed (to each area), such that a vendor can actually implement something definite. I also feel that these document spend too much time on explaining what RPL is (and frankly they they do a really good, succint job at it, so I hate to lose that text, but I don't think it needs to be repeated) What I'd like to do (and I invite you to reply inline, keeping just this text, and +1 each part seperately) 1) is to synchronize these two documents' table of contents. 2) discuss adopting draft-phinney as a WG document! 3) make sure that we are also detailing security and routing issues properly, and yes, we need to have statments like: "Metering networks using ZigBee FOOBAR MUST in layer-2 have security BAZ enabled in order that RPL messages will be secured." or: "This statement applies to using RPL as the MESH over network on 802.15.4 technology with the 6LowPAN defined nd-18 including RFC6282 HC" The applicability statement is not the place to be general. Let's be specific, and in doing so, let's be succinct. draft-ietf-roll-applicability-ami-05.txt: 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Electric Metering . . . . . . . . . . . . . . . . . . . . 3 1.2. Gas and Water Metering . . . . . . . . . . . . . . . . . . 3 1.3. Routing Protocol for LLNs (RPL) . . . . . . . . . . . . . 4 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 5 2. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 5 2.1. Network Topology . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. Electric Meter Network . . . . . . . . . . . . . . . . 5 2.1.2. Energy-Constrained Network Infrastructure . . . . . . 6 2.2. Traffic Characteristics . . . . . . . . . . . . . . . . . 6 2.2.1. Smart Metering Data . . . . . . . . . . . . . . . . . 7 2.2.2. Distribution Automation Communication . . . . . . . . 8 2.2.3. Emerging Applications . . . . . . . . . . . . . . . . 8 3. Using RPL to Meet Functional Requirements . . . . . . . . . . 8 4. RPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. RPL Features . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.1. RPL Instances . . . . . . . . . . . . . . . . . . . . 9 4.1.2. Storing vs. Non-Storing Mode . . . . . . . . . . . . . 9 4.1.3. DAO Policy . . . . . . . . . . . . . . . . . . . . . . 10 4.1.4. Path Metrics . . . . . . . . . . . . . . . . . . . . . 10 4.1.5. Objective Function . . . . . . . . . . . . . . . . . . 10 4.1.6. DODAG Repair . . . . . . . . . . . . . . . . . . . . . 11 4.1.7. Multicast . . . . . . . . . . . . . . . . . . . . . . 11 4.1.8. Security . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.9. P2P communications . . . . . . . . . . . . . . . . . . 12 4.2. Recommended Configuration Defaults and Ranges . . . . . . 12 4.2.1. Trickle Parameters . . . . . . . . . . . . . . . . . . 12 4.2.2. Other Parameters . . . . . . . . . . . . . . . . . . . 13 5. Manageability Considerations . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Other Related Protocols . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10.1. Informative References . . . . . . . . . . . . . . . . . . 15 10.2. Normative References . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 draft-phinney-rpl-industrial-applicability-00: 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Deployment scenarii . . . . . . . . . . . . . . . . . . . 7 3.2. Applications and Traffic classes . . . . . . . . . . . . . 9 3.3. RPL applicability matrix . . . . . . . . . . . . . . . . . 10 4. Characterization of communication flows in IACS wireless networks . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Source-sink (SS) communication paradigm . . . . . . . . . 13 4.3. Publish-subscribe (PS, or pub/sub) communication paradigm . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.4. Peer-to-peer (P2P) communication paradigm . . . . . . . . 15 4.5. Peer-to-multipeer (P2MP) communication paradigm . . . . . 16 4.6. Additional considerations: Duocast and N-cast . . . . . . 17 4.7. RPL applicability per communication paradigm . . . . . . . 18 5. RPL profile . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.1. Use for process control . . . . . . . . . . . . . . . . . 21 5.2. RPL features . . . . . . . . . . . . . . . . . . . . . . . 21 5.2.1. Storing vs. non-storing mode . . . . . . . . . . . . . 21 5.2.2. DAO policy . . . . . . . . . . . . . . . . . . . . . . 21 5.2.3. Path metrics . . . . . . . . . . . . . . . . . . . . . 22 5.2.4. Objective functions . . . . . . . . . . . . . . . . . 22 5.2.5. DODAG repair . . . . . . . . . . . . . . . . . . . . . 22 5.2.6. Security . . . . . . . . . . . . . . . . . . . . . . . 22 5.3. RPL options . . . . . . . . . . . . . . . . . . . . . . . 22 5.4. Recommended configuration defaults and ranges . . . . . . 22 5.4.1. Trickle parameters . . . . . . . . . . . . . . . . . . 22 5.4.2. Other parameters . . . . . . . . . . . . . . . . . . . 23 5.4.3. Additional configuration recommendations . . . . . . . 23 6. Other related protocols . . . . . . . . . . . . . . . . . . . 24 7. Manageability . . . . . . . . . . . . . . . . . . . . . . . . 25 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 26 9. Security considerations . . . . . . . . . . . . . . . . . . . 27 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 11.1. Normative References . . . . . . . . . . . . . . . . . . . 29 11.2. Informative References . . . . . . . . . . . . . . . . . . 29 11.3. External Informative References . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 - -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUBT7KWBIqHRg3pndX9AQKEDgP/ddKMasN7jRNVl6ZGAtCchSYeV/0oUSQ0 Gn8FSRCbacZosnchjVDuDz5MMV4MToC8BPgBh2n0qW4jTpYK8KTPiwhGcJUgkwtv n1xmEJj6d9kftudUCFfmh2WlrXaPWlYdndM/avulkGK8mOVYphHYrtxf4nbyj1HV Y3ChARZ5nUM= =8qRA -----END PGP SIGNATURE-----
- [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