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

Anders Brandt <Anders_Brandt@sigmadesigns.com> Wed, 16 May 2012 08:41 UTC

Return-Path: <Anders_Brandt@sigmadesigns.com>
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 2B3E521F870F for <roll@ietfa.amsl.com>; Wed, 16 May 2012 01:41:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 FOvRPvKpwXjs for <roll@ietfa.amsl.com>; Wed, 16 May 2012 01:41:16 -0700 (PDT)
Received: from maildk.sigmadesigns.com (maildk.sigmadesigns.com [195.215.56.173]) by ietfa.amsl.com (Postfix) with ESMTP id 98B7721F8711 for <roll@ietf.org>; Wed, 16 May 2012 01:41:15 -0700 (PDT)
From: Anders Brandt <Anders_Brandt@sigmadesigns.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, "roll@ietf.org" <roll@ietf.org>
Thread-Topic: [Roll] proposal for common table of contents for applicability statements
Thread-Index: AQHNMsJyaj9Nyv35dEeh8V08XPl0uJbMGDVA
Date: Wed, 16 May 2012 08:41:13 +0000
Message-ID: <03F31C213F2C6941BFDDBB4336E9E6CD0ABE8F25@cph-ex1>
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>
In-Reply-To: <10134.1337103877@marajade.sandelman.ca>
Accept-Language: en-US, da-DK
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.10.79]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-FEAS-SYSTEM-WL: anders_brandt@sigmadesigns.com
X-Mailman-Approved-At: Wed, 16 May 2012 19:37:12 -0700
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: Wed, 16 May 2012 08:41:20 -0000

Hi Michael

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

It is here

http://tools.ietf.org/html/draft-brandt-roll-rpl-applicability-home-building-01

In its current state it is more like a problem statement...

RPL P2P is in its final stages and solves most of the issues that were
addressed in this draft. Thus, it is about time to get it revived.

I will try to get this done before the cutoff date but cannot promise.

Thanks,
  Anders

> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
> Michael Richardson
> Sent: Tuesday, May 15, 2012 19:45
> To: roll@ietf.org
> Subject: [Roll] proposal for common table of contents for applicability
> statements
> 
> -----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/0o
> USQ0
> Gn8FSRCbacZosnchjVDuDz5MMV4MToC8BPgBh2n0qW4jTpYK8KTPiwhGcJUg
> kwtv
> n1xmEJj6d9kftudUCFfmh2WlrXaPWlYdndM/avulkGK8mOVYphHYrtxf4nbyj1
> HV
> Y3ChARZ5nUM=
> =8qRA
> -----END PGP SIGNATURE-----
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll