--- 1/draft-ietf-roll-of0-19.txt	2011-09-08 08:16:20.000000000 +0200
+++ 2/draft-ietf-roll-of0-20.txt	2011-09-08 08:16:20.000000000 +0200
@@ -1,18 +1,18 @@
 
 ROLL                                                     P. Thubert, Ed.
 Internet-Draft                                             Cisco Systems
-Intended status: Standards Track                         August 26, 2011
-Expires: February 27, 2012
+Intended status: Standards Track                       September 5, 2011
+Expires: March 8, 2012
 
                       RPL Objective Function Zero
-                         draft-ietf-roll-of0-19
+                         draft-ietf-roll-of0-20
 
 Abstract
 
    The Routing Protocol for Low Power and Lossy Networks (RPL)
    specification defines a generic Distance Vector protocol that is
    adapted to a variety of networks types by the application of specific
    Objective Functions (OFs).  An OF states the outcome of the process
    used by a RPL node to select and optimize routes within a RPL
    Instance based on the information objects available; an OF is not an
    algorithm.
@@ -36,21 +36,21 @@
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF).  Note that other groups may also distribute
    working documents as Internet-Drafts.  The list of current Internet-
    Drafts is at http://datatracker.ietf.org/drafts/current/.
 
    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
-   This Internet-Draft will expire on February 27, 2012.
+   This Internet-Draft will expire on March 8, 2012.
 
 Copyright Notice
    Copyright (c) 2011 IETF Trust and the persons identified as the
    document authors.  All rights reserved.
 
    This document is subject to BCP 78 and the IETF Trust's Legal
    Provisions Relating to IETF Documents
    (http://trustee.ietf.org/license-info) in effect on the date of
    publication of this document.  Please review these documents
    carefully, as they describe your rights and restrictions with respect
@@ -64,29 +64,29 @@
    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
    2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
    3.  Objective Function Zero Overview . . . . . . . . . . . . . . .  4
    4.  OF0 Operations . . . . . . . . . . . . . . . . . . . . . . . .  5
      4.1.  Computing Rank . . . . . . . . . . . . . . . . . . . . . .  5
      4.2.  Parent Selection . . . . . . . . . . . . . . . . . . . . .  7
        4.2.1.  Selection Of The Preferred Parent  . . . . . . . . . .  7
        4.2.2.  Selection Of The Backup Feasible Successor . . . . . .  8
    5.  Abstract Interface to OF0  . . . . . . . . . . . . . . . . . .  9
    6.  OF0 Operands . . . . . . . . . . . . . . . . . . . . . . . . .  9
-     6.1.  Variables  . . . . . . . . . . . . . . . . . . . . . . . .  9
+     6.1.  Variables  . . . . . . . . . . . . . . . . . . . . . . . . 10
      6.2.  Configurable Parameters  . . . . . . . . . . . . . . . . . 10
      6.3.  Constants  . . . . . . . . . . . . . . . . . . . . . . . . 10
-   7.  Manageability Considerations . . . . . . . . . . . . . . . . . 10
+   7.  Manageability Considerations . . . . . . . . . . . . . . . . . 11
      7.1.  Device Configuration . . . . . . . . . . . . . . . . . . . 11
-     7.2.  Device Monitoring  . . . . . . . . . . . . . . . . . . . . 11
+     7.2.  Device Monitoring  . . . . . . . . . . . . . . . . . . . . 12
    8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
    9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
-   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
+   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
    11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
      11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
      11.2. Informative References . . . . . . . . . . . . . . . . . . 13
    Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
 
 1.  Introduction
 
    The Routing Protocol for Low Power and Lossy Networks (RPL)
    [I-D.ietf-roll-rpl]specification defines a generic Distance Vector
    protocol that is adapted to a variety of Low Power and Lossy Networks
@@ -251,25 +251,26 @@
    stretch) and the fixed constant MAXIMUM_RANK_STRETCH (Section 6.3).
 
    An implementation MUST maintain the stretched step_of_rank between
    the fixed constants MINIMUM_STEP_OF_RANK and MAXIMUM_STEP_OF_RANK
    (Section 6.3).  This range allows to reflect a large variation of
    link quality.
 
    The gap between MINIMUM_STEP_OF_RANK and MAXIMUM_RANK_STRETCH may not
    be sufficient in every case to strongly distinguish links of
    different types or categories in order to favor, say, powered over
-   battery-operated or wired over wireless, within a same DAG.  An
-   implementation SHOULD allow the operator to configure a factor called
-   rank_factor (Section 6.2) and to apply the factor on all links and
-   peers to multiply the effect of the stretched step_of_rank in the
-   rank_increase computation as further detailed below.
+   battery-operated or high-speed (wired) over lower-speed (wireless)
+   links, within a same DAG.  An implementation SHOULD allow the
+   operator to configure a factor called rank_factor (Section 6.2) and
+   to apply the factor on all links and peers to multiply the effect of
+   the stretched step_of_rank in the rank_increase computation as
+   further detailed below.
 
    Additionally, an implementation MAY recognize categories of peers and
    links, such as different link types, in which case it SHOULD be able
    to configure a more specific rank_factor to those categories.  The
    rank_factor MUST be set between the fixed constants
    MINIMUM_RANK_FACTOR and MAXIMUM_RANK_FACTOR (Section 6.3) .
 
    The variable rank_increase is represented in units expressed by the
    variable MinHopRankIncrease which defaults to the fixed constant
    DEFAULT_MIN_HOP_RANK_INCREASE ([I-D.ietf-roll-rpl]); with that
@@ -301,24 +302,27 @@
 
    As it scans all the candidate neighbors, OF0 keeps the parent that is
    the best for the following criteria (in order):
 
    1.   [I-D.ietf-roll-rpl] section 8 spells out the generic rules for a
         node to re-parent and in particular the boundaries to augment
         its Rank within a DODAG Version.  A candidate that would not
         satisfy those rules MUST NOT be considered.
 
    2.   An implementation SHOULD validate a router prior to selecting it
-        as preferred.  In most cases, a router that does not succeed the
-        validation process can not be further considered for selection
-        as preferred parent.  In any case a router that succeeded that
-        validation process SHOULD be preferred.
+        as preferred as discussed in Section 3.  The validation involves
+        layer 2 connectivity to the router, layer 3 connectivity offered
+        by the router, and may involve other factors such as policies.
+        In most cases, a router that does not succeed the validation
+        process cannot be further considered for selection as preferred
+        parent.  In any case a router that succeeded that validation
+        process SHOULD be preferred.
 
    3.   When multiple interfaces are available, a policy might be
         locally configured to order them and that policy applies first;
         that is a router on a higher order interface in the policy is
         preferable.
 
    4.   If the administrative preference of the root is configured to
         supersede the goal to join a Grounded DODAG, a router that
         offers connectivity to a more preferable root SHOULD be
         preferred.