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

[Anders Brandt <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of
> Michael Richardson
> Sent: Tuesday, May 15, 2012 19:45
> To: [e-mail]
> 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 <[e-mail]>, 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll