Re: [Roll] [roll] #99: clarify for readers how/where provisioning of devices occurs

Omprakash Gnawali <gnawali@cs.uh.edu> Sat, 02 June 2012 09:06 UTC

Return-Path: <gnawali@cs.uh.edu>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6017521F8A43 for <roll@ietfa.amsl.com>; Sat, 2 Jun 2012 02:06:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.613
X-Spam-Level:
X-Spam-Status: No, score=-5.613 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYKGLiqOswCP for <roll@ietfa.amsl.com>; Sat, 2 Jun 2012 02:06:45 -0700 (PDT)
Received: from dijkstra.cs.uh.edu (dijkstra.cs.uh.edu [129.7.240.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8A99021F8A51 for <roll@ietf.org>; Sat, 2 Jun 2012 02:06:43 -0700 (PDT)
Received: from localhost (dijkstra.cs.uh.edu [127.0.0.1]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 706D923CA8F for <roll@ietf.org>; Sat, 2 Jun 2012 04:06:38 -0500 (CDT)
X-Virus-Scanned: amavisd-new at cs.uh.edu
Received: from dijkstra.cs.uh.edu ([127.0.0.1]) by localhost (dijkstra.cs.uh.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dENTpmOA1G8B for <roll@ietf.org>; Sat, 2 Jun 2012 04:06:35 -0500 (CDT)
Received: from it.cs.uh.edu (www2.cs.uh.edu [129.7.240.6]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id F233023CA88 for <roll@ietf.org>; Sat, 2 Jun 2012 04:06:34 -0500 (CDT)
Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by it.cs.uh.edu (Postfix) with ESMTP id 0AF8E2A280C1 for <roll@ietf.org>; Sat, 2 Jun 2012 04:03:41 -0500 (CDT)
Received: by ggnc4 with SMTP id c4so2571352ggn.31 for <roll@ietf.org>; Sat, 02 Jun 2012 02:06:35 -0700 (PDT)
Received: by 10.236.193.67 with SMTP id j43mr955744yhn.17.1338627995970; Sat, 02 Jun 2012 02:06:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.146.165.20 with HTTP; Sat, 2 Jun 2012 02:06:15 -0700 (PDT)
In-Reply-To: <CBDF02C3-364B-4C93-A741-E29ADB2B08EF@gmail.com>
References: <058.aaa3fc2efaae8e26a2ada588bce49a89@trac.tools.ietf.org> <CAErDfUQdq57EtpY_4gmONwaC0t2JM7AgGWUMri_NjR+PgW8wrQ@mail.gmail.com> <19632.1337959850@marajade.sandelman.ca> <CBDF02C3-364B-4C93-A741-E29ADB2B08EF@gmail.com>
From: Omprakash Gnawali <gnawali@cs.uh.edu>
Date: Sat, 02 Jun 2012 04:06:15 -0500
Message-ID: <CAErDfUSBrY4FGoBLCMHNQU0ufzfuPaMnh0ZohB5UL5RaD=FxWQ@mail.gmail.com>
To: Ralph Droms <rdroms.ietf@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: roll@ietf.org, draft-ietf-roll-minrank-hysteresis-of@tools.ietf.org
Subject: Re: [Roll] [roll] #99: clarify for readers how/where provisioning of devices occurs
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 02 Jun 2012 09:06:46 -0000

On Fri, Jun 1, 2012 at 2:28 PM, Ralph Droms <rdroms.ietf@gmail.com> wrote:
>
> On May 25, 2012, at 11:30 AM 5/25/12, Michael Richardson wrote:
>
>>
>>>>>>> "Omprakash" == Omprakash Gnawali <gnawali@cs.uh.edu> writes:
>>    Omprakash> I was wondering if the first paragraph of 6.1 is enough for things
>>    Omprakash> that need to be configured/provisioned for MRHOF.
>>
>> I think that it works for *MRHOF*, but I think that we have a bigger
>> picture problem here.
>
> Given that the ZigBee IP spec prescribes the details of how to use MRHOF, a node that implements ZigBee IP and will not be used in any other deployment scenario can be configured at manufacturing time and there is no need for the node to "allow the [...] parameters to be configured at installation time".  However, I think draft-ietf-roll-minrank-hysteresis-of would be improved by expanding the sense of the text to something like:
>
>   An implementation needs specific values for the following
>   paramters: [...]  These parameters may be set at device
>   manufacturing time or configured at installation time.  RPL/MRHOF
>   do not provide a way for the appropriate values for these
>   parameters to be discovered through the network.


This is a good feedback based on what is happening in practice. Happy
to incorporate this by changing the existing text from:

An implementation SHOULD allow the following parameters to be
   configured at installation time: MAX_LINK_METRIC, MAX_PATH_COST,
   PARENT_SWITCH_THRESHOLD, PARENT_SET_SIZE, and ALLOW_FLOATING_ROOT.
   An implementation MAY allow these parameters to be configured
   dynamically at run time once a network has been deployed.

to:

An implementation needs specific values for the following
parameters: MAX_LINK_METRIC, MAX_PATH_COST,
   PARENT_SWITCH_THRESHOLD, PARENT_SET_SIZE, and ALLOW_FLOATING_ROOT.
These parameters may be set at device
manufacturing time, configured at installation time, or configured
at run time once a network has been deployed. MRHOF
does not directly help determine the values for these
parameters.

- om_p