Subject: Re: [Roll] Questions on the RPL applicability statement

From: Michael Richardson <[email-masked]>
Date: Sat, 25 Jan 2014 11:37:39 -0500

Popa, Daniel <[email-masked]> wrote:
    > You're right. In our document the section numbers do not match the
    > section numbers from the template you proposed.

    > The questions we have are:

    > - What is the intent of the Section called "Other protocols"?

I'm not sure.  I don't have such a section.
There are two sections that say, "Other Parameters".

I've posted a -04 with some details of what I think belongs in the first of
those sections. The diffs are below.

    > - In your template there are 2 (distinct) sections called "Layer 2
    > applicability" and "Description of the Layer 2 features",
    > respectively. We wondering if these two sections are not somehow
    > redundant; what is the intent of having these 2 (distinct) sections?

section 2.3, layer-2, details what layer-2 technologies are going to be used.
This is at the high-level.  So in your document, you would write:

     This applicability statement applies to deployments using
     IEEE 802.15.4g, 802.15.4e, and for PowerLine Communication (PLC) IEEE P1901.2.

whereas in the home-building document it says:

   This document applies to [IEEE802.15.4] and [G.9959] which are
   adapted to IPv6 by the adaption layers [RFC4944] and
   [I-D.brandt-6man-lowpanz].

   (and it goes on to explain how 6lowpan is applied to form a layer-3, which
   actually, I think should go in the other section)

In the section of layer-2 features, I would expect to learn the significant
details about each of the layer-2s being used.... if you are using
the layer-2 security features, how they are configured (no security,
per-network keying, per-node pair keying,  bootstrapping of new nodes...)
and what assumptions one might reasonably be able to make about layer-3
security from layer-2 features.   This section will go a long long long way
towards making the security review easier:  if you claim that layer-2
guarantees no strangers on the network, then a whole bunch of threats go
away.

{I'm a bit upset at the security reviews that we have got... They have
occured, actually, way too soon, and in the wrong direction.  Still, all
questions are important to answer}

--
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Michael Richardson <[email-masked]>
Date: Sat, 25 Jan 2014 11:40:34 -0500

That diff of -03->-04 applicability template:

4.3.1.  Trickle Parameters

+   This section is intended to document the specific value (or ranges)
+   appropriate for this kind of deployment.  This includes trickle
+   specific parameters such as those of RFC6550, section 8.3.1: Imin
+   (DIOInternvalMin), Imax (DIOIntrevalDoublings), and k
+   (DIORedundancyConstant).  While it is not necessary to hard code
+   these parameters into RPL nodes, as they are announced as part of the
+   DIO message, it is important for researchers who are trying to
+   validate the convergence properties of the resulting deployment to
+   understand what values have been selected.

+4.3.2.  Other Parameters

+   There are additional values which are present in the DODAG
+   Configuration option.  The purpose of this section is to: a) document
+   what values are configured, b) if a default value is used, if it is
+   appropriate for this deployment.

+   These values include: MaxRankIncrease, MinHopRankIncrease, the
+   Objective Code Point to use, Default Lifetime, Lifetime Units...

+   In addition, the kinds of metrics which will be used (RFC6551) needs
+   to be specified.  If Objective Function 0 (RFC6552) is used, then it
+   specifies a number of values, but also needs definitions of the
+   stretch_of_rank, and rank_factor.

+   If MRHOF (RFC6719) is used, then section 5 of this document requires
+   selection of: MAX_LINK_METRIC, MAX_PATH_COST,
+   PARENT_SWITCH_THRESHOLD, PARENT_SET_SIZE, and ALLOW_FLOATING_ROOT.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

---

From: "Popa, Daniel" <[email-masked]>
Date: Tue, 28 Jan 2014 15:56:51 +0000

Hi Michael, 

Thanks for clarifying our questions. 

The remaining question is related to Section 8 " Other Related Protocols" as per  " draft-ietf-roll-applicability-template-04": What is the intent of this section? 

http://tools.ietf.org/pdf/draft-ietf-roll-applicability-template-04.pdf

Regards,
Daniel

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Michael Richardson
Envoyé : samedi 25 janvier 2014 17:38
À : [email-masked]
Cc : Popa, Daniel; Gillmore, Matthew
Objet : Re: Questions on the RPL applicability statement

I've posted a -04 with some details of what I think belongs in the first of those sections. The diffs are below.

In the section of layer-2 features, I would expect to learn the significant details about each of the layer-2s being used.... if you are using the layer-2 security features, how they are configured (no security, per-network keying, per-node pair keying,  bootstrapping of new nodes...) and what assumptions one might reasonably be able to make about layer-3
security from layer-2 features.   This section will go a long long long way
towards making the security review easier:  if you claim that layer-2 guarantees no strangers on the network, then a whole bunch of threats go away.

{I'm a bit upset at the security reviews that we have got... They have occured, actually, way too soon, and in the wrong direction.  Still, all questions are important to answer}