The IESG has approved the following document:
- 'RPL Objective Function Zero'
  (draft-ietf-roll-of0-20.txt) as a Proposed Standard

This document is the product of the Routing Over Low power and Lossy
networks Working Group.

The IESG contact persons are Adrian Farrel and Stewart Bryant.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-roll-of0/




Technical Summary

  The Routing Protocol for Low Power and Lossy Networks (RPL)
  was designed as a generic core protocol that is agnostic to
  metrics and that is adapted to a given problem using Objective
  Functions (OF). This separation of Objective Functions from the core
  protocol specification allows RPL to adapt to meet the different
  optimization criteria required by the wide range of use cases.

  RPL forms Destination Oriented Directed Acyclic Graphs (DODAGs)
  within instances of the protocol.  Each instance is associated with a
  specialized Objective Function.  A DODAG is periodically
  reconstructed in a new Version to enable a global reoptimization of
  the graph.

  An Objective Function selects the DODAG Version that a device joins
  within an instance, and a number of neighbor routers within that
  DODAG Version as parents or feasible successors.  The OF generates
  the Rank of the device, that represents an abstract distance to the
  root within the DODAG.  In turn, the Rank is used by RPL to avoid 
  loops and verify forward progression towards a destination.

  This document defines Objective Function 0 (OF0) which operates on
  parameters that are obtained from provisionning, from the RPL DODAG
  Configuration option, and from the RPL DIO base container.

  OF0 is designed as a default OF that will allow interoperation
  between implementations in a wide spectrum of use cases.  

Working Group Summary

  No discontent. 

  There has been some confusion about the WG process because of the
  large number of revisions since the first WG last call. Here is the timeline:

> 01/05    New revision -05
> 02/22    WG last call on -05
> 03/13    On-list discussions of changes
> 03/13    New revision -06
> 03/13    New revision -07
> 03/14    WG last call on -07
> 03/16,,  On-list discussions
> 03/30    New revision -08
> 04/05    New revision -09
> 04/11    Comment on list
> 04/11    New revision -10
> 04/21    Comment on list
> 05/05    Notice to list about changes
> 05/05    New revision -11
> 05/08    WG chair review posted to list
> 05/10    Comment on list
> 05/17    Notice to list about changes
> 05/17    New revision -12
> 05/18..  On-list discussion
> 05/24    Publication request
> 06/01    AD review posted to list
> 06/11    AD review :: Revised I-D needed
> 06/17    New revision -13
> 06/20    New revision -14
> 06/20    IETF Last Call
> 07/04    IETF Last Call ends
> 07/08    New revision -15
> 07/16    Ballot issued
> 08/09    IESG Discusses
> 08/09..  On-list discussions
> 08/11    IESG telechat
 
   Thus: all changes as a result of comments made on the list. Plenty of explanation to
   the list about what was changing and why.

   A further poll of the WG will be carried out after changes to address IESG Discusses

Document Quality

  The OF0 has been extensively discussed and reviewed by key contributors
  of the Working Group. There are believed to be two implementations.

Personnel

  JP Vasseur (jvasseur@cisco.com) is the Document Shepherd.
  Adrian Farrel (adrian@olddog.co.uk) is the Responsible AD.

RFC Editor Note

Section 4.2.1
OLD
   2.   An implementation SHOULD validate a router prior to selecting it
        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.
NEW
   2.   Prior to selecting a router as the preferred parent, an
        implementation SHOULD validate the connectivity and suitability 
        of the router as discussed in Section 3.  This validation 
        involves checking the layer 2 connectivity to the router, the 
        layer 3 connectivity offered by the router, and may involve 
        examination of other factors such as locally or globally 
        configured 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 over one that does not succeed.
END