Last summer during the chartering process of 6tisch, I asked if 6tisch wanted
or or ought to adopt draft-ietf-roll-rpl-industrial-applicability.  We did
not reach a clear conclusion, and agreed to revisit the question later on.

EXEC SUMMARY:
  I want to propose that the ROLL WG abandon this document as not particularly
  useful to real industry.   If this document normatively references 6tisch, 
  it will in essence be obsoleted by the documents it references.  If the
  document does no normatively reference 6tisch, it may have no value.

  6tisch will not adopt this document, as it has equivalent documents already
  planned.   The value of this document may have been simply to make the
  motiviation for creating 6tisch clear.


AUDIENCE:
  First, I want to recognize that the group of people working on 6tisch are
  people who think that they can not deploy into industrial settings without
  availability of deterministic behaviour.  Thus I want to acknowledge that
  asking 6tisch people if deterministic behaviour is useful is preaching to
  the choir.

  Second, I would ask that those of you who are in other SDOs that deal with
  this kind of thing (IEC, IEEE, ZigbeeIP) where I, a non-member, can not
  post, to please forward this email and/or a link to the thread.

BACKGROUND:
  The document deals with using RPL in Industrial settings, and does a very
  good job of explaining how things operate in that space.

  The document includes a diagram in section 2.1.1, on page 7:

  > It appears from the above sections that whether and the way RPL can
  > be applied for a given flow depends both on the deployment scenario
  > and on the class of application / traffic.  At a high level, this can
  > be summarized by the following matrix:
   
  > +---------------------+------------------------------------------------+
  > |   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    |
  > +---------------------+------------------------------------------------+
  > 
  > 
  >  ? : typically usable for all but higher-rate classes 0,1 PS traffic
  ===

  An X denotes that a non-deterministric LLN using RPL could be used in
  uring many phases of a plant, but it can not be used for class 0,1 traffic
  during "Normal Operation".   That is, an RPL LLN is useful during exceptional
  times, but not during normal times.   Whether normal operation can be served
  by a deterministric (6tisch) network, or whether it will require wired
  operation is clearly going to be decided on a case-by-case basis.

QUESTION:
  The group of deployments for which "Normal Operation" can be satisfied by a
  6tisch based solution, would in general be covered by 6tisch.  In
  particular whatever (security) bootstrap process used by 6tisch would be
  used during the other phases, so any security analysis done in this
  document is not useful.

  If the deployment can not be satisfied by 6tisch (e.g Normal Operation
  requires wires, etc.), then this document may well have some value. 
  In that case, this document might have value, but we have not at present
  identified the constituency that would be willing to work on this document.

  Does such a consitutency exist? 
  If it does not, then I suggest that it is not worth the cost to the IETF
  to publish this document.


-- 
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works 
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/