Re: [Roll] AD review of draft-ietf-roll-minrank-hysteresis-of-04

"Adrian Farrel" <adrian@olddog.co.uk> Fri, 06 January 2012 20:10 UTC

Return-Path: <adrian@olddog.co.uk>
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 626F221F85C7 for <roll@ietfa.amsl.com>; Fri, 6 Jan 2012 12:10:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 yUII3GBrN7KZ for <roll@ietfa.amsl.com>; Fri, 6 Jan 2012 12:10:33 -0800 (PST)
Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id D6DD721F873E for <roll@ietf.org>; Fri, 6 Jan 2012 12:10:06 -0800 (PST)
Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q06KA3KZ018567; Fri, 6 Jan 2012 20:10:03 GMT
Received: from 950129200 (adsl-89-217-79-52.adslplus.ch [89.217.79.52]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q06KA0LX018543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 6 Jan 2012 20:10:01 GMT
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Omprakash Gnawali' <gnawali@cs.uh.edu>
References: <Acx9JebOqQuxacSeSJKxbycTLE63zA==> <09d401cc7d25$ffa16150$fee423f0$@olddog.co.uk> <CAErDfURa57Lco9KaSNPKrkA_v8PiwA7KUbdUAUALx8whxWvDSw@mail.gmail.com>
In-Reply-To: <CAErDfURa57Lco9KaSNPKrkA_v8PiwA7KUbdUAUALx8whxWvDSw@mail.gmail.com>
Date: Fri, 06 Jan 2012 20:10:00 -0000
Message-ID: <00a201ccccaf$2d51a410$87f4ec30$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQEt0YKbC1e7kTaVBMPToCrcou+LQQGThtBJAk9Gqb+XHpDP4A==
Content-Language: en-gb
Cc: draft-ietf-roll-minrank-hysteresis-of@tools.ietf.org, roll@ietf.org
Subject: Re: [Roll] AD review of draft-ietf-roll-minrank-hysteresis-of-04
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
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: Fri, 06 Jan 2012 20:10:34 -0000

Hi Omprakash,

Was the action with me? I think I fumbled and no-one chased me :-(

> Adrian, thanks for the feedback. I have incorporated some of your
> comments, but there are some items I wanted to run by you before
> posting a new version:
> 
> > In progressing the OG0 draft we learnt that there was no clear
> > understanding of what an objective function is. I think your draft does
> > a good job at explaining, but in an attempt to learn from the past, can
> > you please have a look at the text that got added to the OF0 document to
> > see whether anything can be added here.
> 
> I looked through both the drafts and also rpl draft. I could mention
> the relevant sections of RPL draft in the first sentence of section 1:
> 
> An objective function specifies how RPL [I-D.ietf-roll-rpl] selects
>    paths.
> 
> to:
> 
> An objective function describes how RPL [I-D.ietf-roll-rpl] selects
>    paths within the role defined in Section 3.2.1 and using the
>    guidelines listed in Section 14 of [I-D.ietf-roll-rpl].
> 
> Isn't that better than every OF draft describing what an OF is and
> what it is supposed to do?

I understand where you are coming from.

I think that, while section 14 of draft-ietf-roll-rpl is perfectly clear, our
non-RPL reviewers simply did not get the fact that an OF is an outcome not an
algorithm. Thus, when RPL was reviewed, it was read as though an OF was an
algorithm and no problems arose. However, when draft-ietf-roll-of0 was reviewed
there was huge confusion and we added paras 2 and 3 to Section 1 before the
reviewers "got it".

What I suggest here is that we take the statement of abstraction from OF0 and
fold it into your I-D. How about...

OLD
   An objective function specifies how RPL [I-D.ietf-roll-rpl] selects
   paths.  Objective functions can choose paths based on routing metrics
   or constraints.  For example, if an RPL instance uses an objective
   function that minimizes hop-count, RPL will select paths with minimum
   hop count.
NEW
   An objective function (OF) describes how RPL [I-D.ietf-roll-rpl] 
   selects paths.  An OF is not an algorithm, but states the outcome of
   the process or algorithm used by a RPL node to select and optimize 
   routes within a RPL Instance based on the information objects 
   available (such as routing metrics and constraints).  For example, if
   a RPL instance has an objective function that minimizes hop-count,
   RPL will select paths with minimum hop-count.

   The separation of OFs from the core protocol specification allows RPL
   to be adapted to meet the different optimization criteria required by
   the wide range of deployments, applications, and network designs.

   Section 14 of [I-D.ietf-roll-rpl] sets out guidelines for the
   creation, specification, and implementation of OFs.
END

> > Why is "Minimum Rank Objective Function with Hysteresis" MRHOF not
> > MROFH?
> 
> We can change the name to Minimum Rank Hysteresis Objective Function.

wfm

> > During the review process for OF0 we ended up adding the following
> > paragraph. Would you consider adding something similar to make this
> > point crystal clear?
> >
> >   The RPL specification [I-D.ietf-roll-rpl] requires the use of a
> >   common OF by all nodes in a network.  The possible use of multiple
> >   OFs with a single network is for further study.
> 
> Do you prefer to repeat this in each OF draft, even though it is
> already mentioned in rpl draft?

Well, we ended up having to add this short paragraph in order to get OF0 through
IESG review. You can choose to add the paragraph or fight the IESG later. I
always prefer the easy approach. Does it detract from the quality of your
document?

> > Section 5.1
> >
> > Can you add a statement on default values?
> 
> Here is the current statement on default values:
> 
> The parameter values are assigned depending on the selected metric.
>    The best values for these parameters should be experimentally
>    determined.  The working group has long experience routing with the
>    ETX metric.  Based on those experiences, these values are
>    RECOMMENDED:
> 
> If you think it would be better to clarify some aspect of the above
> statement or something
> additional, I am happy to add those statements. I will put the above statement
> and the table of default values as a separate subsection (5.1) and
manageability
> will become 5.2.

The text you quote is not in section 5.1 and does not mention defaults. 

How about

OLD
   The parameters MAX_LINK_METRIC, MAX_PATH_COST, MIN_PATH_COST,
   PARENT_SWITCH_THRESHOLD, PARENT_SET_SIZE, and ALLOW_FLOATING_ROOT
   should be configurable.
NEW
   The parameters MAX_LINK_METRIC, MAX_PATH_COST, MIN_PATH_COST,    
   PARENT_SWITCH_THRESHOLD, PARENT_SET_SIZE, and ALLOW_FLOATING_ROOT
   SHOULD be configurable. Defaults values SHOULD be applied so that
   configuration is not required. Defaults for the ETX metric SHOULD
   use the values shown in the previous section.
END

> > Can you also have a look at Section 7 of the OF0 draft. This gives
> > more substantive approach to describing manageability.
> 
> How about changing:
> 
>    The parameters MAX_LINK_METRIC, MAX_PATH_COST, MIN_PATH_COST,
>    PARENT_SWITCH_THRESHOLD, PARENT_SET_SIZE, and ALLOW_FLOATING_ROOT
>    should be configurable.
> 
> to
> 
>    Out of the box, the parameters MAX_LINK_METRIC, MAX_PATH_COST,
MIN_PATH_COST,
>    PARENT_SWITCH_THRESHOLD, PARENT_SET_SIZE, and ALLOW_FLOATING_ROOT
>    should be set to the default values. The default value MAY be different
from the ones
>    described in Section 5.1. These values may be further modified using
guidelines in Section 16
>    of [I-D.ietf-roll-rpl].

I think you have really only attempted to address my previous point here.
Wrt manageability I had hoped for more details. You might look at RFC 5706 for
advice (and you could use RFC 6123 as an example).

I think this is only a "nice to have", and certainly you don't need to go down
the path of a 10 page section. What I really wanted to understand was that you
had considered the manageability of your work. If so, we can move on.

Cheers,
Adrian