Subject: [Roll] Time to move on the applicability statement

From: JP Vasseur <[email-masked]>
Date: Wed, 4 May 2011 03:42:26 -0700

Dear all,

As discussed during our last IETF meeting in Prague, now that RPL has been approved
and is in the RFC Editor queue, it is time to move on the "applicability statements", 
according to our charter. Many of you expressed some interest on various applicability 
IDs such as Industrial automation, urban networks, home automation, smart metering, ... 
What we'd like to propose is to adopt a common "structure" for all IDs.

What are we trying to achieve ? The IETF has produced a number of applicability statements. 
That being said, the objective may slightly differ according to the context. RPL has been 
designed to be flexible while meeting a number of requirements such as code size, memory 
requirements, ... As a result RPL is a flexible protocol offering various options depending on 
the use case requirements. A good example is the routing metric documents, that specifies a 
number of link/node metrics/constraints. Some deployments may require to implement a very 
small subset of those (even none of them) or a combination of metrics and/or constraints. 
This is also true for various RPL options and features.

The aim of the applicability statement is to describe how RPL could be used to satisfy the
requirement of a specific application. This is not a deployment guide ... Feel free to indicate
which mode of operation could be used, along with the metric, ... even mention which timers
setting could be used if you think that this is appropriate: the objective is not to provide a 
detailed deployment guide, but rather simply explain which options/features could be used for
a specific use case. Remember to focus on RPL not the entire solution scope including potentially
6lowpan, CoAP, ... Address management could be part of it though if using PIO in DIO.

One recommendation: be concise, no need to write a book ;-) Ideally ID should not exceed 20 
pages.

Note that one may support different mode of operation for example, according to the device
capability and network size: for example, I know that some implementations for smart metering
will support the non-storing while others will elect to use the storing mode. It is perfectly acceptable
to document both along with the assumption of the network and the devices capabilities.

Table of Content

1. Introduction
2. Overview of the Deployment Scenario
Mainly a very short summary of the deployment scenario and 
reference to the Reqs RFC)
3. Using RPL to Meet the Functional Requirements
Extract requirements from the Reqs RFC
Might be a simple list with pointers into the Reqs RFC
For each, list the RPL features that are used or explicitly not
used to meet the requirements 
4. RPL Profile
4.1 RPL Features
Mode of operation: storing versus non-storing
Use of P2P of the base specification or the P2P solution
Number of DAG
Repair Mode
Metrics
4.2 RPL Options (if any)
(for each RPL option you need to say:
    - should it be implemented [required, optional, not required]
    - should it be deployed [required, recommended, optional, not
       recommended, must not]
    - which requirement in section 3 it meets [if applicable] )
4.3 Recommended Configuration Defaults and Ranges
   (For each configurable thing in the RPL spec
     - default value
     - recommended ranges for implementations)
4.4 Additional Configuration Recommendations
   (Anything that is not configurable in the RPL spec that should be
     configurable in this deployment)
5. Other Related Protocols (OPTIONAL)
   (what else do you need implemented, what assumptions can/should
    be made)
6. Manageability (if applicable)
7. Security (if applicable)

Thanks.

JP.

ps: special thanks to Adrian for his input.