[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>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-----