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

[Robert Assimiti <[e-mail]>]

Message: 1
Date: Tue, 15 May 2012 13:44:37 -0400
From: Michael Richardson <[e-mail]>
To: [e-mail]
Subject: [Roll] proposal for common table of contents for
	applicability	statements
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=us-ascii

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

Robert: Michael, the industrial applicability statement mainly addresses energy constrained battery operated instruments. Routers present on the backbone are typically line powered. We intend to introduce a new section in our second draft that addressed these energy-rich scenario as well, but having two separate drafts based solely on this criteria is overkill in my opinion. Could we just provide two concise profiles for the two scenarios within the same draft?

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)

Robert: Fully agree that the drafts should be less verbose on explaining what RPL is and focus on concise recommendations for implementation ready profiles.


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/0oUSQ0
Gn8FSRCbacZosnchjVDuDz5MMV4MToC8BPgBh2n0qW4jTpYK8KTPiwhGcJUgkwtv
n1xmEJj6d9kftudUCFfmh2WlrXaPWlYdndM/avulkGK8mOVYphHYrtxf4nbyj1HV
Y3ChARZ5nUM=
=8qRA
-----END PGP SIGNATURE-----


------------------------------

_______________________________________________
Roll mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/roll


End of Roll Digest, Vol 52, Issue 15
************************************