Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)
draft-ietf-roll-of0-20

[Ballot comment]
I've cleared my DISCUSS.  I hope the Working Group and the authors
will consider these COMMENTs before the document is published.

1. I consider the following comment to be a technical rather than an
editorial suggestion because of the redundancy and potential conflict
between the text in the Introduction of this document and the contents
of draft-ietf-roll-rpl-19.  It would improve the document to edit the
Introduction down to a paragraph that combines the following sentence
from the first paragraph with the content from the last paragraph:

  An Objective Function
  defines how a RPL node selects and optimizes routes within a RPL
  Instance based on the information objects available.

I think Adrian may have suggested some other text that better defines
an Objective Function.

2. (withdrawn)

3. (withdrawn)

4. In section 7.1, why is support of the DODAG Configuration option
only a SHOULD?

  An OF0 implementation SHOULD support the DODAG Configuration option
  as specified in section 6.7.6 of [I-D.ietf-roll-rpl] and apply the
  parameters contained therein.

5. I see that text has been added in section 4.2.1 about validating a
router.  The section still doesn't explain what the phrase "validate a
router" actually means.  Is there text in draft-ietf-roll-rpl that can
be cited here to explain the semantics or other intended meaning of
"validate a router"?

[Ballot comment]
I've cleared my DISCUSS.  I hope the Working Group and the authors
will consider these COMMENTs before the document is published.

1. I consider the following comment to be a technical rather than an
editorial suggestion because of the redundancy and potential conflict
between the text in the Introduction of this document and the contents
of draft-ietf-roll-rpl-19.  It would improve the document to edit the
Introduction down to a paragraph that combines the following sentence
from the first paragraph with the content from the last paragraph:

  An Objective Function
  defines how a RPL node selects and optimizes routes within a RPL
  Instance based on the information objects available.

I think Adrian may have suggested some other text that better defines
an Objective Function.

2. OF0 is specified to be applicable to both wired and wireless
networks.  That statement is probably true, but I think the contexts
in which "wired" and "wireless" are used could use clarification.  Do
I have it right that the differentiation isn't so much "wired" and
"wireless" as "fixed cost links" and "variable cost links"; a simple
hop count computation will work for the former while the latter
requires some weighting of links for "good" routing, regardless of the
underlying technology?  For example, would a simple hop count metric
work in a typical 802.11 network?

3. If the computation of the step_factor is entirely up to the node,
why are the rank_factor and stretch_factor needed?  Why not just leave
the entire computation to the implementation, with limitations that
the resulting step_factor lie in the range MINIMUM_STEP_OF_RANK and
MAXIMUM_STEP_OF_RANK?

4. In section 7.1, why is support of the DODAG Configuration option
only a SHOULD?

  An OF0 implementation SHOULD support the DODAG Configuration option
  as specified in section 6.7.6 of [I-D.ietf-roll-rpl] and apply the
  parameters contained therein.

5. I see that text has been added in section 4.2.1 about validating a
router.  The section still doesn't explain what the phrase "validate a
router" actually means.  Is there text in draft-ietf-roll-rpl that can
be cited here to explain the semantics or other intended meaning of
"validate a router"?

[Ballot discuss]
1. After discussion of this point, I understand that individual nodes
in a RPL Instance using OF0 can choose arbitrary methods to compute
rank, and that - as long as the computed rank meets contraints - the
RPL Instance will avoid or recover from loops and converge on feasible
routing.  This routing will not be optimized for any particular
metric.

I would still like to discuss the requirements for the rank
computation.  If a simple metric that leads to a hop-count computation
for path lengths and route computation is know to yield unusable
performance, why is it not required that a node use some sort of
computation based on link characteristics?  And, if the computation of
the step_factor is entirely up to the node, why are the rank_factor
and stretch_factor needed?  Why not just leave the entire computation
to the implementation, with limitations that the resulting step_factor
lie in the range MINIMUM_STEP_OF_RANK and MAXIMUM_STEP_OF_RANK?

2. Adrian pointed me to the WG last call on draft-ietf-roll-of0-07,
which broadens the applicability of OF0 to both wired and wireless
networks.  I see that the WG has considered the use of arbitrary rank
computation within a single OF and its relation to the specification
in draft-ietf-roll-rpl-19 that a RPL Instance use a single Objective
Function throughout.

3. Adrian pointed me to the text in draft-ietf-roll-rpl-19 that
specifies:

  If further guidance is not available then a RPL Router implementation
  MUST at least support the metric-less OF0

Thanks, Adrian, for clarifying points 2 and 3 for me.

4. In section 7.1, why is support of the DODAG Configuration option
only a SHOULD?

  An OF0 implementation SHOULD support the DODAG Configuration option
  as specified in section 6.7.6 of [I-D.ietf-roll-rpl] and apply the
  parameters contained therein.

5. This point is more editorial than completely technical, but I list
it as a Discuss because of the potential for confusion among
implementors.  I found the use of "DODAG Version" a little confusing,
because it appears sometimes to mean one of the successive Versions of
one DODAG and at other times to mean a specific DODAG chosen from
several DODAGs.  For example, from the Introduction:

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

  An instance of RPL running on a device uses an Objective Function to
  help it determine which DODAG Version it should join.  The OF is also
  used by the RPL instance to select a number of routers within the
  DODAG Version to serve as parents or as feasible successors.

In my opinion, the first use of "DODAG Version" refers to a sucessive
Version of one DODAG, while the second use refers to a selection of
one DODAG from many DODAGs.  Would it be possible to just use "DODAG"
for the second intended use?  Or am I confused about the intended
meanings?

6. In section 4.2.1, what does it mean to "validate a router"?  Why
would a router that passes validation ("succeeded that validation
process") only be "preferable"?

[Ballot comment]
I am clearing on the basis that the authors have agreed to fix
the following problem and that the responsible AD has
the resolution in hand.

The text that led to my concern was:

"The RPL instance uses the OF to compute a Rank for the device.  This
value represents an abstract distance to the root of the DODAG within
the DODAG Version.  The Rank is exchanged between nodes using RPL and
allows other RPL nodes to avoid loops and verify forward progression
toward the destination, as specified in [I-D.ietf-roll-rpl]."


Which associates OF, Rank and Loops. However on speaking to
Pascal I now realize that the use of inconsistent OFs will not
cause loops to form, because a node exports the output of the
OF as a new Rank and thus Rank always increases.

This confusion could be addressed by adding a sentence of the form

"Regardless of the particular OF used by a node, Rank will always
increase and thus, post convergence, loop free paths are always
formed."

This then takes me to the para that I picked up on before:

"It is important that devices deployed in a particular network or
environment use the same OF to build and operate DODAGs.  If they do
not, it is likely that sub-optimal paths will be selected.  In
practice, without a common definition of an OF, RPL implementations
cannot guarantee to interoperate correctly. "


It seems that [I-D.ietf-roll-rpl] does not currently support operation
of a network other than with a single consistent OF, although I
understand that there might be cases where it would make sense
to employ multiple OFs in the future.

Perhaps the text above could be replaced with:

"[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"

==========

Nit
"An implementation SHOULD allow to configure a... "

Do you mean "An implementation SHOULD allow the operator to configure a..." ?

[Ballot comment]
1. I consider the following comment to be a technical rather than an
editorial suggestion because of the redundancy and potential conflict
between the text in the Introduction of this document and the contents
of draft-ietf-roll-rpl-19.  It would improve the document to edit the
Introduction down to a paragrpah that combines the following sentence
from the first paragraph with the content from the last paragraph:

  An Objective Function
  defines how a RPL node selects and optimizes routes within a RPL
  Instance based on the information objects available.

Editing out the text describing RPL would also presumably address
Stewart's Discuss about the use of multiple OFs in one RPL Instance.

2. I don't understand this phrase from the last paragraph of the
Introduction:

  [...] OF0 enforces normalized values for the rank_increase of a
  normal link and its acceptable range

Do I have it right that a node uses OF0 to determine the rank_increase
for a successor within the range:

  MINIMUM_STEP_OF_RANK < stretched step_of_rank < MAXIMUM_STEP_OF_RANK

Unless I'm missing something, these limits on the stretched
step_of_rank enforce (indirectly) a range on rank_increase, but don't
normalize rank_increase by some normalizing factor.

3. Is there a reason to switch between "successor" and "parent"
throughout the document?  For example, the title of section 4.2 is
"Feasible Successors Selection" and the title of the immediately
following section 4.2.1 is "Selection Of The Preferred Parent".  Are
"successor" and "parent" are synonymous in this context?  Would it be
asking for foolish consistency to choose one or the other?

4. In section 7.1, what is "build-time"?

  At build-time [...]

Also in section 7.1, what is a "fixed constant" (as opposed to any
other kind of "constant").  Why are overridden values - I assume these
are overriden by some administrative method like CLI configuration or
some management protocol? - only applied at the next Version of the
DODAG?

5. In section 3, how is "good enough" defined?  From reading the rest
of the spec, I don't see where any assessment of quality is applied to
ensure that "good enough" is more than basic connectivity.  I suggest
just dropping "good enough".

6. OF0 is specified to be applicable to both wired and wireless
networks.  That statement is probably true, but I think the contexts
in which "wired" and "wireless" are used could use clarification.  Do
I have it right that the differentiation isn't so much "wired" and
"wireless" as "fixed cost links" and "variable cost links"; a simple
hop count computation will work for the former while the latter
requires some weighting of links for "good" routing, regardless of the
underlying technology?

[Ballot discuss]
1. After discussion of this point, I understand that individual nodes
in a RPL Instance using OF0 can choose arbitrary methods to compute
rank, and that - as long as the computed rank meets contraints - the
RPL Instance will avoid or recover from loops and converge on feasible
routing.  This routing will not be optimized for any particular
metric.

I would still like to discuss the requirements for the rank
computation.  If a simple metric that leads to a hop-count computation
for path lengths and route computation is know to yield unusable
performance, why is it not required that a node use some sort of
computation based on link characteristics?  And, if the computation of
the step_factor is entirely up to the node, why are the rank_factor
and stretch_factor needed?  Why not just leave the entire computation
to the implementation, with limitations that the resulting step_factor
lie in the range MINIMUM_STEP_OF_RANK and MAXIMUM_STEP_OF_RANK?

2. Adrian pointed me to the WG last call on draft-ietf-roll-of0-07,
which broadens the applicability of OF0 to both wired and wireless
networks.  I see that the WG has considered the use of arbitrary rank
computation within a single OF and its relation to the specification
in draft-ietf-roll-rpl-19 that a RPL Instance use a single Objective
Function throughout.

3. Adrian pointed me to the text in draft-ietf-roll-rpl-19 that
specifies:

  If further guidance is not available then a RPL Router implementation
  MUST at least support the metric-less OF0

Thanks, Adrian, for clarifying points 2 and 3 for me.

4. In section 7.1, why is support of the DODAG Configuration option
only a SHOULD?

  An OF0 implementation SHOULD support the DODAG Configuration option
  as specified in section 6.7.6 of [I-D.ietf-roll-rpl] and apply the
  parameters contained therein.

5. This point is more editorial than completely technical, but I list
it as a Discuss because of the potential for confusion among
implementors.  I found the use of "DODAG Version" a little confusing,
because it appears sometimes to mean one of the successive Versions of
one DODAG and at other times to mean a specific DODAG chosen from
several DODAGs.  For example, from the Introduction:

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

  An instance of RPL running on a device uses an Objective Function to
  help it determine which DODAG Version it should join.  The OF is also
  used by the RPL instance to select a number of routers within the
  DODAG Version to serve as parents or as feasible successors.

In my opinion, the first use of "DODAG Version" refers to a sucessive
Version of one DODAG, while the second use refers to a selection of
one DODAG from many DODAGs.  Would it be possible to just use "DODAG"
for the second intended use?  Or am I confused about the intended
meanings?

6. In section 4.2.1, what does it mean to "validate a router"?  Why
would a router that passes validation ("succeeded that validation
process") only be "preferable"?

[Ballot comment]
I now understand the history of the document between WGLC and now. However, there is scant little evidence of what happened in either the document writeup or the proto writeup. That would be useful in the future.

[Ballot discuss]
I have the same questions Ralph asks in his Discuss points
concerning interoperability and what is mandatory to implement.

As specified in -15, the variable behavior of of0
could be entirely determined by each elements (non-standard)
provisioning. With everything else being equal, swapping an
element from Vendor A with one from Vendor B can, and likely
will, result in substantially different network behavior, and
that's likely to be observable through the network's performance.
For someone to deploy this, they will have to ask each vendor
"What does your of0 actually do, and what knobs can I turn in it?".
If that's what the group expects the effect of this codepoint to be,
that interoperability consequence should be called out more clearly.

[Ballot comment]
I support point #2 of Ralph's DISCUSS. It appears that a lot changed between WG last call and what we've got, and there is scant little evidence of what happened in either the document writeup or the proto writeup.

[Ballot comment]
1. I consider the following comment to be a technical rather than an
editorial suggestion because of the redundancy and potential conflict
between the text in the Introduction of this document and the contents
of draft-ietf-roll-rpl-19.  It would improve the document to edit the
Introduction down to a paragrpah that combines the following sentence
from the first paragraph with the content from the last paragraph:

  An Objective Function
  defines how a RPL node selects and optimizes routes within a RPL
  Instance based on the information objects available.

Editing out the text describing RPL would also presumably address
Stewart's Discuss about the use of multiple OFs in one RPL Instance.

2. I don't understand this phrase from the last paragraph of the
Introduction:

  [...] OF0 enforces normalized values for the rank_increase of a
  normal link and its acceptable range

Do I have it right that a node uses OF0 to determine the rank_increase
for a successor within the range:

  MINIMUM_STEP_OF_RANK < stretched step_of_rank < MAXIMUM_STEP_OF_RANK

Unless I'm missing something, these limits on the stretched
step_of_rank enforce (indirectly) a range on rank_increase, but don't
normalize rank_increase by some normalizing factor.

3. Is there a reason to switch between "successor" and "parent"
throughout the document?  For example, the title of section 4.2 is
"Feasible Successors Selection" and the title of the immediately
following section 4.2.1 is "Selection Of The Preferred Parent".  Are
"successor" and "parent" are synonymous in this context?  Would it be
asking for foolish consistency to choose one or the other?

4. In section 7.1, what is "build-time"?

  At build-time [...]

Also in section 7.1, what is a "fixed constant" (as opposed to any
other kind of "constant").  Why are overridden values - I assume these
are overriden by some administrative method like CLI configuration or
some management protocol? - only applied at the next Version of the
DODAG?

5. In section 3, how is "good enough" defined?  From reading the rest
of the spec, I don't see where any assessment of quality is applied to
ensure that "good enough" is more than basic connectivity.  I suggest
just dropping "good enough".

[Ballot discuss]
1. I would like to discuss the interoperability and deployability of
nodes in a RPL Instance that uses OF0.  If I understand section 4.1
correctly, a node is free to compute step-of-rank using any method it
chooses.  There is a suggestion that using link properties for the
computation is preferred, but the specific link properties and the
method of computation are not specified.  Later, section 4.1 defines
two parameters, rank_factor and stretch_factor, that modify
step_of_rank to generate a "stretched step_of_rank".  The latter value
is then multiplied by the MinHopRankIncrease to compute the node's
rank_increase.

My concern is the degrees of freedom provided to the implementation in
the computation of rank_increase.  I'm hoping I can get an explanation
of some reason to believe that independent implementations, using
different methods to compute step_of_rank and potentially different
configured values for rank_factor and stretch_factor, will
interoperate successfully to form an operational network.

More specifically, if a simple metric that leads to a hop-count
computation for path lengths and route computation is know to yield
unusable performance, why is it not required that a node use some sort
of computation based on link characteristics?  And, if the computation
of the step_factor is entirely up to the node, why are the rank_factor
and stretch_factor needed?  Why not just leave the entire computation
to the implementation, with limitations that the resulting step_factor
lie in the range MINIMUM_STEP_OF_RANK and MAXIMUM_STEP_OF_RANK?

2. I see that the WG last call was conducted on draft-ietf-roll-of0-05,
while draft-ietf-roll-of0-12 was submitted for publication and we are
reviewing draft-ietf-roll-of0-15.  There is at least one major change
between the specification as reviewed in WG last call and the version
of the spec we are reviewing: OF0 is stated in draft-ietf-roll-of0-15
to be applicable to wired and wireless networks, while rev -05
explicitly constrains OF0 to wired networks.  As a point of
clarification, I think what's really intended here is that an OF based
on a hop count is only applicable to a network composed of fixed cost
links, and will be sub-optimal for a network composed of variable cost
links.

I'd like to know if the WG considered this major technical change and
my conclusion in point 1 that OF0 may bypass the RPL specification
requirement for a consistent objective function computation throughout
a RPL Instance by allowing nodes to choose any method for computing
the rank increase for that node, with the only constraint being the
range of values for the rank increase.

3. I would also like to discuss the requirement for a
mandatory-to-implement OF, whether OF0 is that mandatory-to-implement
OF and where the requirement to implement OF0 is specified.

4. In section 7.1, why is support of the DODAG Configuration option
only a SHOULD?

  An OF0 implementation SHOULD support the DODAG Configuration option
  as specified in section 6.7.6 of [I-D.ietf-roll-rpl] and apply the
  parameters contained therein.

5. This point is more editorial than completely technical, but I list
it as a Discuss because of the potential for confusion among
implementors.  I found the use of "DODAG Version" a little confusing,
because it appears sometimes to mean one of the successive Versions of
one DODAG and at other times to mean a specific DODAG chosen from
several DODAGs.  For example, from the Introduction:

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

  An instance of RPL running on a device uses an Objective Function to
  help it determine which DODAG Version it should join.  The OF is also
  used by the RPL instance to select a number of routers within the
  DODAG Version to serve as parents or as feasible successors.

In my opinion, the first use of "DODAG Version" refers to a sucessive
Version of one DODAG, while the second use refers to a selection of
one DODAG from many DODAGs.  Would it be possible to just use "DODAG"
for the second intended use?  Or am I confused about the intended
meanings?

6. In section 4.2.1, what does it mean to "validate a router"?  Why
would a router that passes validation ("succeeded that validation
process") only be "preferable"?

[Ballot comment]
I reviewed this document, but need to trust others with more background in routing to have reviewed it for its impact on forwarding.

I reviewed the management considerations, and am pleased that they provided an information model to monitor the parameters in use. It would have been nice to have a mandatory-to-implement management protocol and data model to ensure interoperable management.

[Ballot comment]
from the nits-checker:

  == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but
    does not include the phrase in its RFC 2119 key words list.

  == Unused Reference: 'I-D.ietf-roll-security-framework' is defined on line
    569, but no explicit reference was found in the text

Note that for the 1st one you can keep 'NOT RECOMMENDED' in the text you just need to add it to the 2119 paragraph immediately after RECOMMENDED.

[Ballot comment]
1. I consider the following comment to be a technical rather than an
editorial suggestion because of the redundancy and potential conflict
between the text in the Introduction of this document and the contents
of draft-ietf-roll-rpl-19.  It would improve the document to edit the
Introduction down to a paragrpah that combines the following sentence
from the first paragraph with the content from the last paragraph:

  An Objective Function
  defines how a RPL node selects and optimizes routes within a RPL
  Instance based on the information objects available.

Editing out the text describing RPL would also presumably address
Stewart's Discuss about the use of multiple OFs in one RPL Instance.

2. I don't understand this phrase from the last paragraph of the
Introduction:

  [...] OF0 enforces normalized values for the rank_increase of a
  normal link and its acceptable range

Do I have it right that a node uses OF0 to determine the rank_increase
for a successor within the range:

  MINIMUM_STEP_OF_RANK < stretched step_of_rank < MAXIMUM_STEP_OF_RANK

Unless I'm missing something, these limits on the stretched
step_of_rank enforce (indirectly) a range on rank_increase, but don't
normalize rank_increase by some normalizing factor.

3. Is there a reason to switch between "successor" and "parent"
throughout the document?  For example, the title of section 4.2 is
"Feasible Successors Selection" and the title of the immediately
following section 4.2.1 is "Selection Of The Preferred Parent".  Are
"successor" and "parent" are synonymous in this context?  Would it be
asking for foolish consistency to choose one or the other?

4. In section 7.1, what is "build-time"?

  At build-time [...]

Also in section 7.1, what is a "fixed constant" (as opposed to any
other kind of "constant").  Why are overridden values - I assume these
are overriden by some administrative method like CLI configuration or
some management protocol? - only applied at the next Version of the
DODAG?

5. In section 3, how is "good enough" defined?  From reading the rest
of the spec, I don't see where any assessment of quality is applied to
ensure that "good enough" is more than basic connectivity.  I suggest
just dropping "good enough".

[Ballot discuss]
1. I would like to discuss the interoperability and deployability of
nodes in a RPL Instance that uses OF0.  If I understand section 4.1
correctly, a node is free to compute step-of-rank using any method it
chooses.  There is a suggestion that using link properties for the
computation is preferred, but the specific link properties and the
method of computation are not specified.  Later, section 4.1 defines
two parameters, rank_factor and stretch_factor, that modify
step_of_rank to generate a "stretched step_of_rank".  The latter value
is then multiplied by the MinHopRankIncrease to compute the node's
rank_increase.

My concern is the degrees of freedom provided to the implementation in
the computation of rank_increase.  I'm hoping I can get an explanation
of some reason to believe that independent implementations, using
different methods to compute step_of_rank and potentially different
configured values for rank_factor and stretch_factor, will
interoperate successfully to form an operational network.

More specifically, if a simple metric that leads to a hop-count
computation for path lengths and route computation is know to yield
unusable performance, why is it not required that a node use some sort
of computation based on link characteristics?  And, if the computation
of the step_factor is entirely up to the node, why are the rank_factor
and stretch_factor needed?  Why not just leave the entire computation
to the implementation, with limitations that the resulting step_factor
lie in the range MINIMUM_STEP_OF_RANK and MAXIMUM_STEP_OF_RANK?

2. I would also like to discuss the requirement for a
mandatory-to-implement OF, whether OF0 is that mandatory-to-implement
OF and where the requirement to implement OF0 is specified.

3. In section 7.1, why is support of the DODAG Configuration option
only a SHOULD?

  An OF0 implementation SHOULD support the DODAG Configuration option
  as specified in section 6.7.6 of [I-D.ietf-roll-rpl] and apply the
  parameters contained therein.

4. This point is more editorial than completely technical, but I list
it as a Discuss because of the potential for confusion among
implementors.  I found the use of "DODAG Version" a little confusing,
because it appears sometimes to mean one of the successive Versions of
one DODAG and at other times to mean a specific DODAG chosen from
several DODAGs.  For example, from the Introduction:

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

  An instance of RPL running on a device uses an Objective Function to
  help it determine which DODAG Version it should join.  The OF is also
  used by the RPL instance to select a number of routers within the
  DODAG Version to serve as parents or as feasible successors.

In my opinion, the first use of "DODAG Version" refers to a sucessive
Version of one DODAG, while the second use refers to a selection of
one DODAG from many DODAGs.  Would it be possible to just use "DODAG"
for the second intended use?  Or am I confused about the intended
meanings?

5. In section 4.2.1, what does it mean to "validate a router"?  Why
would a router that passes validation ("succeeded that validation
process") only be "preferable"?

[Ballot discuss]
"It is important that devices deployed in a particular network or
  environment use the same OF to build and operate DODAGs.  If they do
  not, it is likely that sub-optimal paths will be selected. "

Surely it's rather more serious that that. Incompatible OF's may cause loops (look back 3 paragraphs), meaning that it is essential that the same OF be used to ensure LF operation.

IANA understands that upon approval of this document, there is a single
IANA action that needs to be completed.

IANA will register the following in the Objective Code Point Registry at
http://www.iana.org/assignments/rpl

OCP code: TBD
Description: A basic Objective Function that relies only on the objects
that are defined in [I-D.ietf-roll-rpl].
Reference: [ RFC-to-be ]

IANA notes that the authors suggest a value of zero for the OCP code.

IANA understands that this is the only IANA action that needs to be
completed upon approval of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (RPL Objective Function 0) to Proposed Standard


The IESG has received a request from the Routing Over Low power and Lossy
networks WG (roll) to consider the following document:
- 'RPL Objective Function 0'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-07-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

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.  An Objective Function defines how a RPL node
  selects and optimizes routes within a RPL Instance based on the
  information objects available.  This document specifies a basic
  Objective Function that relies only on the objects that are defined
  in RPL and does not use any extension.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-roll-of0/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-roll-of0/


No IPR declarations have been submitted directly on this I-D.

Please find the Proto-write-up for draft-ietf-roll-of0-12
Intended status : Standard Track

> (1.a)  Who is the Document Shepherd for this document?  Has the
>        Document Shepherd personally reviewed this version of the
>        document and, in particular, does he or she believe this
>        version is ready for forwarding to the IESG for publication?

JP Vasseur is the document shepherd.
He has personally reviewed the document and believes it is ready for
forwarding to the IESG for publication.

> (1.b)  Has the document had adequate review both from key WG members
>        and from key non-WG members?  Does the Document Shepherd have
>        any concerns about the depth or breadth of the reviews that
>        have been performed?

The I-D has been discussed in details by several key WG members of the
Working group for the past 6 months and during the course of the RPL
specification. Several comments have been made on the mailing list
during WG Last Call and addressed in this revision.

> (1.c)  Does the Document Shepherd have concerns that the document
>        needs more review from a particular or broader perspective,
>        e.g., security, operational complexity, someone familiar with
>        AAA, internationalization or XML?

No concerns.

> (1.d)  Does the Document Shepherd have any specific concerns or
>        issues with this document that the Responsible Area Director
>        and/or the IESG should be aware of?  For example, perhaps he
>        or she is uncomfortable with certain parts of the document, or
>        has concerns whether there really is a need for it.  In any
>        event, if the WG has discussed those issues and has indicated
>        that it still wishes to advance the document, detail those
>        concerns here.  Has an IPR disclosure related to this document
>        been filed?  If so, please include a reference to the
>        disclosure and summarize the WG discussion and conclusion on
>        this issue.

The document is sound.

> (1.e)  How solid is the WG consensus behind this document?  Does it
>        represent the strong concurrence of a few individuals, with
>        others being silent, or does the WG as a whole understand and
>        agree with it?

Good consensus.

> (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
>        discontent?  If so, please summarise the areas of conflict in
>        separate email messages to the Responsible Area Director.  (It
>        should be in a separate email because this questionnaire is
>        entered into the ID Tracker.)

No threats. No discontent.

> (1.g)  Has the Document Shepherd personally verified that the
>        document satisfies all ID nits?  (See
>        http://www.ietf.org/ID-Checklist.html and
>        http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
>        not enough; this check needs to be thorough.  Has the document
>        met all formal review criteria it needs to, such as the MIB
>        Doctor, media type and URI type reviews?

Checks have been made. No Errors.

> (1.h)  Has the document split its references into normative and
>        informative?  Are there normative references to documents that
>        are not ready for advancement or are otherwise in an unclear
>        state?  If such normative references exist, what is the
>        strategy for their completion?  Are there normative references
>        that are downward references, as described in [RFC3967]?  If
>        so, list these downward references to support the Area
>        Director in the Last Call procedure for them [RFC3967].

References split has been done.

> (1.i)  Has the Document Shepherd verified that the document IANA
>        consideration section exists and is consistent with the body
>        of the document?  If the document specifies protocol
>        extensions, are reservations requested in appropriate IANA
>        registries?  Are the IANA registries clearly identified?  If
>        the document creates a new registry, does it define the
>        proposed initial contents of the registry and an allocation
>        procedure for future registrations?  Does it suggest a
>        reasonable name for the new registry?  See [RFC2434].  If the
>        document describes an Expert Review process has Shepherd
>        conferred with the Responsible Area Director so that the IESG
>        can appoint the needed Expert during the IESG Evaluation?

This document does not require any IANA action.

> (1.j)  Has the Document Shepherd verified that sections of the
>        document that are written in a formal language, such as XML
>        code, BNF rules, MIB definitions, etc., validate correctly in
>        an automated checker?

No such formal language is used.

> (1.k)  The IESG approval announcement includes a Document
>        Announcement Write-Up.  Please provide such a Document
>        Announcement Write-Up.  Recent examples can be found in the
>        "Action" announcements for approved documents.  The approval
>        announcement contains the following sections:
>
>        Technical Summary
>          Relevant content can frequently be found in the abstract
>          and/or introduction of the document.  If not, this may be
>          an indication that there are deficiencies in the abstract
>          or introduction.                   
  The Routing Protocol for Low Power and Lossy Networks
  [I-D.ietf-roll-rpl] was designed as a generic core 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 the generic RPL
  core to avoid loops and verify forward progression towards a
  destination, as specified in [I-D.ietf-roll-rpl].

  The Objective Function 0 (OF0) operates on parameters that are
  obtained from provisionning, the RPL DODAG Configuration option and
  the RPL DIO base container [I-D.ietf-roll-rpl].

  The Rank of a node is obtained by adding a normalized scalar,
  rank_increase, to the Rank of a selected preferred parent.  The
  rank_increase can vary with a ratio from 1 ( excellent) to 9 (worst
  acceptable) to represent the link properties.  As a result, OF0 with
  default settings allows to encode a minimum of 28 (worst acceptable)
  hops and a maximum of 255 (excellent) hops.

  Since there is no default OF or metric container in the RPL main
  specification, it might happen that, unless two given implementations
  follow the same guidance for a specific problem or environment, those
  implementations will not support a common OF with which they could
  interoperate.

  OF0 is designed as a default OF that will allow interoperation
  between implementations in a wide spectrum of use cases.  This is why
  it is not specific as to how the link properties are transformed into
  a rank_increase and leaves that responsibility to the implementation;
  rather, OF0 enforces normalized values for the rank_increase of a
  normal link and its acceptable range, as opposed to formulating the
  details of its computation.  This is also why OF0 ignores metric
  containers. 
>        Working Group Summary
>          Was there anything in WG process that is worth noting?  For
>          example, was there controversy about particular points or
>          were there decisions where the consensus was particularly
>          rough?

No discontent.

>        Document Quality
>          Are there existing implementations of the protocol?  Have a
>          significant number of vendors indicated their plan to
>          implement the specification?  Are there any reviewers that
>          merit special mention as having done a thorough review,
>          e.g., one that resulted in important changes or a
>          conclusion that the document had no substantive issues?  If
>          there was a MIB Doctor, Media Type or other expert review,
>          what was its course (briefly)?  In the case of a Media Type
>          review, on what date was the request posted?

The OF0 has been extensively discussed and reviewed by key contributors
of the Working Group.