Subject: [Roll] roll-rpl-industrial-applicability

From: Michael Richardson <[email-masked]>
Date: Mon, 02 Jan 2012 11:16:06 -0500

Some comments on draft-phinney-roll-rpl-industrial-applicability-00.
I promised myself during the last IETF that I'd read it, and new year's
day was a good to do that.

pg4:
>   A field device that belongs to an instance uses the OF to determine
>   which DODAG and which Version of that DODAG the device should join.

I did not think that the OF would tell us which Version of a DODAG to
use.  The version simply increments... I guess if the new values from
the new version do not satisfy the OF, one could stay with the
previously calculated parents, etc.

I was very pleased to read section 3.1.  Deployment scenarii.
In it, 6 scenarios are described:
     P1: Construction or major modification phase
     P2: Planned startup phase
     P3: Normal operation phase
     P4: Planned shutdown phase
     P5: Plant decommissioning phase.
     P6: Post-emergency recovery and repair phase.

The analysis that follows concerns me:

>   The deployment scenarios for wireless LLN devices may be different in
>   each of these phases.  In particular, during the Construction or
>   major modification phase (P1), LLN devices may be installed months
>   before the intended LLN can become usefully operational (because
>   needed routers and infrastructure devices are not yet installed or
>   active), and there are likely to be many personnel in whom the plant
>   owner/operator has only limited trust, such as subcontractors and
>   others in the plant area who have undergone only a cursory background
>   investigation (if any at all).  In general, during this phase, plant

I very much wish that this had appeared in RFC5673 as input into the
security mechanism.  I think that a major limitation in the current
documents in the security area here.  I could go on awhile about how I
think things should work to solve this; I didn't do that before, because
I didn't think that there was real requirements for a system a flexible
as I envision.   

NOTE: this is not a fault of this document, it's a failure of our
      requirements process for security.

draft-phinney-roll-rpl-industrial-applicability-00 recaps too many
things, and I find is way too chatty.  I expect an applicability
statement to be more to the point.  This relates to section 3 mostly, I
think.

The chart in section 3.3:

+---------------------+------------------------------------------------+
|   Phase \  Class    |   0       1       2       3       4       5    |
+=====================+================================================+
|   Construction      |                   X       X       X       X    |
+---------------------+------------------------------------------------+
|   Planned startup   |                   X       X       X       X    |
+---------------------+------------------------------------------------+
|   Normal operation  |                           ?       ?       ?    |
+---------------------+------------------------------------------------+
|   Planned shutdown  |                   X       X       X       X    |
+---------------------+------------------------------------------------+
|Plant decommissioning|                   X       X       X       X    |
+---------------------+------------------------------------------------+
| Recovery and repair |   X       X       X       X       X       X    |
+---------------------+------------------------------------------------+

also is of concern. What it says is that RPL can't be used for 

      *  Class 0: Emergency action - Always a critical function
      *  Class 1: Closed loop regulatory control - Often a critical
         function
      *  Class 2: Closed loop supervisory control - Usually non-critical
         function

during any phase, except during repair.  And, that we don't even know if
it can be used for Normal operation!  That's hardly an huge endorsement!

Thank you kindly for this -00 document.  I realize that section 5 is
where the meat will go, and I look forward to some clear recommendations
here.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.