RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks
draft-ietf-roll-rpl-19

[Ballot comment]
I've cleared my DISCUSS.  Some of my COMMENTs still apply to
rev -19, and I've moved a former DISCUSS issue to the COMMENTs.

C10.  In my opinion, the
    details about how to generate the downward source routes are all
    implementation details.  All that's needed for rule 3 is:

  3.  In non-storing mode, the DODAG Root MUST be able to generate
      source routes for destinations learned from DAOs

D4. I see that the text in section 12 has been edited; it seems less
    clear to me now than the the corresponding text in the previous
    revision.  I strongly recommend that section 12 be edited out of
    the document and multicast support be published as a separate
    document.

General Comment: In my opinion, this document could be improved
to increase the probability that independently developed implementations
will be interoperable.

The document includes some functions, such as the multicast delivery
framework in section 12, that is incomplete and other discussion,
such as the explanation of greediness in section 3, that are not central
to the spec.  Both kinds of text could be edited out.

I support Jari's Comment in which he suggests additional work on the
specification.

[Ballot comment]
I have decided to clear my Discuss after the changes in -19 added text that describes what parts of RPL and other documents are actually required for different types of implementations.

However, I think the text is still weaker than it could be. E.g., it does not point to the 6MAN documents as something that is required to implement. I continue to worry that RPL is not sufficiently interoperable, and I think the IETF needs to seriously consider further work in this area. Such further work may include:

- applicability notes
- bis versions of this RFC to remove material that turns out to be not truly needed or strengthening of the required-to-implement rules
- operational experience of running RPL

Similarly, I am still concerned about the interaction of this specification with Neighbor Discovery, but since Ralph Droms is holding a Discuss on those aspects I let him hold that discuss. Please keep in the loop on how the resolution of the ND specification aspect is going.

[Ballot discuss]
(Updated on March 2nd to reflect the latest situation. I am working on
text suggestions to fix the remaining issues. Stay tuned.)

This is a well written document and I was positively surprised that
it is in relatively good shape. I did have a number of concerns or
question marks, however, and would like to discuss them. Some of this
is indeed questions -- pardon my lack of understanding of the entire
system.

1. Removed.

2. Removed.

3. The protocol mechanisms are complex and the document is long. Just
the base document is 140 pages long, and there are mandatory pieces
elsewhere (drafts in ROLL and 6MAN). But yet we are talking about small
devices. I'm left wondering whether the working group could have
modularized the specification in a different way. For instance, the
document supports both storing and non-storing modes, couldn't
those have been in different specs? Why does the protocol provide
an "IP layer VLAN" mechanism (= instances) alongside everything else
that it does?

I am happy with all the specific text fragments that were added.
I am still trying to determine if the document as a whole makes
it clear at the beginning what parts are mandatory and optional and
what other components and assumptions are needed for this to
work.

4. Thanks for the updated specification regarding ND options, and
the very useful examples in Appendix A. I am still in the process
of reviewing the full end result in order make sure that we're not
forgetting something. I'm still concerned about what the document
should say about interfacing the rest of the world (and not just other
RPL nodes).

5. Removed

6. Some changes to -rpl where agreed upon discussing -metrics. Please add
them to a new version of the -rpl draft as well. The changes relate to describing
what OFs and metric attributes are mandatory to implement, and what the
interoperability model is.

[Ballot discuss]
(Updated on March 2nd to reflect the latest situation. I am working on
text suggestions to fix the remaining issues.)

This is a well written document and I was positively surprised that
it is in relatively good shape. I did have a number of concerns or
question marks, however, and would like to discuss them. Some of this
is indeed questions -- pardon my lack of understanding of the entire
system.

1. Removed.

2. Removed.

3. The protocol mechanisms are complex and the document is long. Just
the base document is 140 pages long, and there are mandatory pieces
elsewhere (drafts in ROLL and 6MAN). But yet we are talking about small
devices. I'm left wondering whether the working group could have
modularized the specification in a different way. For instance, the
document supports both storing and non-storing modes, couldn't
those have been in different specs? Why does the protocol provide
an "IP layer VLAN" mechanism (= instances) alongside everything else
that it does?

4. Thanks for the updated specification regarding ND options, and
the very useful examples in Appendix A. I did have a few remaining
smaller issues within those, however:

5. Removed

6. Some changes to -rpl where agreed upon discussing -metrics. Please add
them to a new version of the -rpl draft as well. The changes relate to describing
what OFs and metric attributes are mandatory to implement, and what the
interoperability model is.

[Ballot discuss]
(Updated on December 23rd to reflect current document and all the
other information we've received in the meantime.)

This is a well written document and I was positively surprised that
it is in relatively good shape. I did have a number of concerns or
question marks, however, and would like to discuss them. Some of this
is indeed questions -- pardon my lack of understanding of the entire
system.

1. Removed.

2. Removed.

3. The protocol mechanisms are complex and the document is long. Just
the base document is 140 pages long, and there are mandatory pieces
elsewhere (drafts in ROLL and 6MAN). But yet we are talking about small
devices. I'm left wondering whether the working group could have
modularized the specification in a different way. For instance, the
document supports both storing and non-storing modes, couldn't
those have been in different specs? Why does the protocol provide
an "IP layer VLAN" mechanism (= instances) alongside everything else
that it does?

4. Thanks for the updated specification regarding ND options, and
the very useful examples in Appendix A. I did have a few remaining
smaller issues within those, however:

5. Removed

6. Some changes to -rpl where agreed upon discussing -metrics. Please add
them to a new version of the -rpl draft as well. The changes relate to describing
what OFs and metric attributes are mandatory to implement, and what the
interoperability model is.

[Ballot discuss]
(Updated on December 23rd to reflect current document and all the
other information we've received in the meantime.)

This is a well written document and I was positively surprised that
it is in relatively good shape. I did have a number of concerns or
question marks, however, and would like to discuss them. Some of this
is indeed questions -- pardon my lack of understanding of the entire
system.

1. Removed.

2. Removed.

3. The protocol mechanisms are complex and the document is long. Just
the base document is 140 pages long, and there are mandatory pieces
elsewhere (drafts in ROLL and 6MAN). But yet we are talking about small
devices. I'm left wondering whether the working group could have
modularized the specification in a different way. For instance, the
document supports both storing and non-storing modes, couldn't
those have been in different specs? Why does the protocol provide
an "IP layer VLAN" mechanism (= instances) alongside everything else
that it does?

4. Thanks for the updated specification regarding ND options, and
the very useful examples in Appendix A. I did have a few remaining
smaller issues within those, however:

  Section 9.4:

  4.  In order to enable an optimum compression of the routing header,
      the parent SHOULD set the 'R' flag in all PIOs with the 'A' flag
      set and the 'L' flag cleared, and the child SHOULD prefer to use
      as transit the address of the parent that is found in the PIO
      that is used to autoconfigure the address that is advertised as
      target in the DAO message.

  Its unclear why this recommendation is made. This removes the address
  autoconfiguration capability.

5. Removed

6. Some changes to -rpl where agreed upon discussing -metrics. Please add
them to a new version of the -rpl draft as well. The changes relate to describing
what OFs and metric attributes are mandatory to implement, and what the
interoperability model is.

[Ballot discuss]
(Updated on December 23rd to reflect current document and all the
other information we've received in the meantime.)

This is a well written document and I was positively surprised that
it is in relatively good shape. I did have a number of concerns or
question marks, however, and would like to discuss them. Some of this
is indeed questions -- pardon my lack of understanding of the entire
system.

1. Removed.

2. Removed.

3. The protocol mechanisms are complex and the document is long. Just
the base document is 140 pages long, and there are mandatory pieces
elsewhere (drafts in ROLL and 6MAN). But yet we are talking about small
devices. I'm left wondering whether the working group could have
modularized the specification in a different way. For instance, the
document supports both storing and non-storing modes, couldn't
those have been in different specs? Why does the protocol provide
an "IP layer VLAN" mechanism (= instances) alongside everything else
that it does?

4. Thanks for the updated specification regarding ND options, and
the very useful examples in Appendix A. I did have a few remaining
smaller issues within those, however:

  Section 9.4:

    A parent that
    advertises a prefix in a PIO with the 'A' flag set MUST ensure
    that the address or the whole prefix in the PIO is reachable from
    the root by advertising it as a DAO target.

  Not specific enough. It would seem that if you advertise a prefix with
  'A' set, the parent should ensure that the whole prefix is
  reachable. Otherwise a node that configures an address from this
  prefix will not be reachable.

  Section 9.4:

  4.  In order to enable an optimum compression of the routing header,
      the parent SHOULD set the 'R' flag in all PIOs with the 'A' flag
      set and the 'L' flag cleared, and the child SHOULD prefer to use
      as transit the address of the parent that is found in the PIO
      that is used to autoconfigure the address that is advertised as
      target in the DAO message.

  Its unclear why this recommendation is made. This removes the address
  autoconfiguration capability.

5. I do not understand how NUD and RPL interact. Section 8.2.1
says that if NUD fails then the upward entity should be removed
from consideration. However, since RFC 4861 specifies that NUD
is only run if there's traffic to send, what causes traffic to be
sent? My understanding is that this you actually want to avoid
traffic being sent unless you have some real payload traffic to
go out. However, I think the document should explain it.

6. Some changes to -rpl where agreed upon discussing -metrics. Please add
them to a new version of the -rpl draft as well. The changes relate to describing
what OFs and metric attributes are mandatory to implement, and what the
interoperability model is.

[Ballot discuss]
(Updated on December 23rd to reflect current document and all the
other information we've received in the meantime.)

This is a well written document and I was positively surprised that
it is in relatively good shape. I did have a number of concerns or
question marks, however, and would like to discuss them. Some of this
is indeed questions -- pardon my lack of understanding of the entire
system.

1. Removed.

2. Removed.

3. The protocol mechanisms are complex and the document is long. Just
the base document is 140 pages long, and there are mandatory pieces
elsewhere (drafts in ROLL and 6MAN). But yet we are talking about small
devices. I'm left wondering whether the working group could have
modularized the specification in a different way. For instance, the
document supports both storing and non-storing modes, couldn't
those have been in different specs? Why does the protocol provide
an "IP layer VLAN" mechanism (= instances) alongside everything else
that it does?

4. Thanks for the updated specification regarding ND options, and
the very useful examples in Appendix A. I did have a few remaining
smaller issues within those, however:

  Section 9.4:

    A parent that
    advertises a prefix in a PIO with the 'A' flag set MUST ensure
    that the address or the whole prefix in the PIO is reachable from
    the root by advertising it as a DAO target.

  Not specific enough. It would seem that if you advertise a prefix with
  'A' set, the parent should ensure that the whole prefix is
  reachable. Otherwise a node that configures an address from this
  prefix will not be reachable.

  Section 9.4:

  4.  In order to enable an optimum compression of the routing header,
      the parent SHOULD set the 'R' flag in all PIOs with the 'A' flag
      set and the 'L' flag cleared, and the child SHOULD prefer to use
      as transit the address of the parent that is found in the PIO
      that is used to autoconfigure the address that is advertised as
      target in the DAO message.

  Its unclear why this recommendation is made. This removes the address
  autoconfiguration capability.

  Appendix A.1:

  Its confusing when the example has both names and bits for prefixes,
  e.g., is EXT_1::0//64 same as 2001:DB8:1:1::/64?

  Appendix A.1:

    3. Node Z may interact with another neighboring non-RPL router in
      EXT_2::/64. Node Z may repackage the information learned from
      the RPL network in order to announce that information into the
      other neighboring network. For example, Node Z may repackage a
      RIO to indicate reachability to EXT_1::/64.

  On the first read I was confused which direction the information
  flows to. Please be more specific. E.g., ... may repackage a
  RPL RIO sent by the root node to a RIO in a router advertisement
  sent to the second external network.

  Appendix A.1:

    4. Node Z, on behalf of the non-RPL aware host Host1, will send DAOs
      containing Host1 as a Target and itself (Node Z) as a parent in
      the Transit Information option.  (In storing mode that Transit
      Information option does not need to contain the address of Node
      Z).  A non-storing root then becomes aware of the 1-hop link Node
      Z -- Host1 for use in constructing source routes.

  But in IPv6 neighbor discovery, there is no guarantee that you know
  what address(es) Host1 has allocated for itself. RFC 3041 and so on.
  Shouldn't Z advertise a prefix of some sort?

  Appendix A.1:

  This example would be better if it talked about what L and A flag
  settings and PIOs get used. Your example starts from a complex case
  (external networks) but doesn't cover the basic case.

  Section A.3.3.

    Node A will conceptually collect the following information into
    its RIB:
      o A::/128 connected

  Hmm. Isn't this A::A (that's the only address A has that is directly
  connected)

5. I do not understand how NUD and RPL interact. Section 8.2.1
says that if NUD fails then the upward entity should be removed
from consideration. However, since RFC 4861 specifies that NUD
is only run if there's traffic to send, what causes traffic to be
sent? My understanding is that this you actually want to avoid
traffic being sent unless you have some real payload traffic to
go out. However, I think the document should explain it.

6. Some changes to -rpl where agreed upon discussing -metrics. Please add
them to a new version of the -rpl draft as well. The changes relate to describing
what OFs and metric attributes are mandatory to implement, and what the
interoperability model is.

[Ballot discuss]
(Updated on December 23rd to reflect current document and all the
other information we've received in the meantime.)

This is a well written document and I was positively surprised that
it is in relatively good shape. I did have a number of concerns or
question marks, however, and would like to discuss them. Some of this
is indeed questions -- pardon my lack of understanding of the entire
system.

1. RPL relies on a new model for packet forwarding as well as the routing
machinery. Yet the IESG only sees this document, while some others are
still in the 6MAN working group. Given that the documents have now
progressed to WGLC, I don't think we have a big problem though. I will
hold this discuss until the WGLC is finished and I have myself reviewed
the documents again to ensure that they are safe.

2. Removed.

3. The protocol mechanisms are complex and the document is long. Just
the base document is 140 pages long, and there are mandatory pieces
elsewhere (drafts in ROLL and 6MAN). But yet we are talking about small
devices. I'm left wondering whether the working group could have
modularized the specification in a different way. For instance, the
document supports both storing and non-storing modes, couldn't
those have been in different specs? Why does the protocol provide
an "IP layer VLAN" mechanism (= instances) alongside everything else
that it does?

4. Thanks for the updated specification regarding ND options, and
the very useful examples in Appendix A. I did have a few remaining
smaller issues within those, however:

  Section 6.7.10:

    In particular, a RPL node may use this
    option for the purpose of State-Less Address Auto-Configuration
    (SLAAC) from a prefix advertised by a parent as specified in
    [RFC4862], and advertise its own address as specified in [RFC3775].
    The root of a DODAG is authoritative for setting that information.
    The information is propagated down the DODAG unchanged, with the
    exception that a RPL router may update (extend) the prefix by
    appending it's own suffix.

  The last sentence does not seem completely correct. You cannot extend
  the prefix without changing the interface ID part. Did you mean
  "extend" as (a) making the prefix longer or (b) replacing a different
  IID? Per RFC 3775, the IID and the prefix share the same 128 bits, so
  any attempt to do (a) will result in IID being overwritten.

  Section 9.4:

    A parent that
    advertises a prefix in a PIO with the 'A' flag set MUST ensure
    that the address or the whole prefix in the PIO is reachable from
    the root by advertising it as a DAO target.

  Not specific enough. It would seem that if you advertise a prefix with
  'A' set, the parent should ensure that the whole prefix is
  reachable. Otherwise a node that configures an address from this
  prefix will not be reachable.

  Section 9.4:

  4.  In order to enable an optimum compression of the routing header,
      the parent SHOULD set the 'R' flag in all PIOs with the 'A' flag
      set and the 'L' flag cleared, and the child SHOULD prefer to use
      as transit the address of the parent that is found in the PIO
      that is used to autoconfigure the address that is advertised as
      target in the DAO message.

  Its unclear why this recommendation is made. This removes the address
  autoconfiguration capability.

  Appendix A.1:

  Its confusing when the example has both names and bits for prefixes,
  e.g., is EXT_1::0//64 same as 2001:DB8:1:1::/64?

  Appendix A.1:

    3. Node Z may interact with another neighboring non-RPL router in
      EXT_2::/64. Node Z may repackage the information learned from
      the RPL network in order to announce that information into the
      other neighboring network. For example, Node Z may repackage a
      RIO to indicate reachability to EXT_1::/64.

  On the first read I was confused which direction the information
  flows to. Please be more specific. E.g., ... may repackage a
  RPL RIO sent by the root node to a RIO in a router advertisement
  sent to the second external network.

  Appendix A.1:

    4. Node Z, on behalf of the non-RPL aware host Host1, will send DAOs
      containing Host1 as a Target and itself (Node Z) as a parent in
      the Transit Information option.  (In storing mode that Transit
      Information option does not need to contain the address of Node
      Z).  A non-storing root then becomes aware of the 1-hop link Node
      Z -- Host1 for use in constructing source routes.

  But in IPv6 neighbor discovery, there is no guarantee that you know
  what address(es) Host1 has allocated for itself. RFC 3041 and so on.
  Shouldn't Z advertise a prefix of some sort?

  Appendix A.1:

  This example would be better if it talked about what L and A flag
  settings and PIOs get used. Your example starts from a complex case
  (external networks) but doesn't cover the basic case.

  Section A.3.3.

    Node A will conceptually collect the following information into
    its RIB:
      o A::/128 connected

  Hmm. Isn't this A::A (that's the only address A has that is directly
  connected)

5. I do not understand how NUD and RPL interact. Section 8.2.1
says that if NUD fails then the upward entity should be removed
from consideration. However, since RFC 4861 specifies that NUD
is only run if there's traffic to send, what causes traffic to be
sent? My understanding is that this you actually want to avoid
traffic being sent unless you have some real payload traffic to
go out. However, I think the document should explain it.

6. Some changes to -rpl where agreed upon discussing -metrics. Please add
them to a new version of the -rpl draft as well. The changes relate to describing
what OFs and metric attributes are mandatory to implement, and what the
interoperability model is.

[Ballot comment]
C8. The definition of DAO-ACK rejection codes seems unclear to me:

        Status 0 is unqualified
        acceptance, 1 to 127 are unassigned and undetermined, and 128
        and greater are rejection codes used to indicate that the node
        should select an alternate parent.

Is it the case that 1 to 127 might be used to indicate some
non-rejection status while 128-255 are used to indicate a status that
requires selection of a new parent?

C10. The update to section 9.2, rule 3, actually went in the opposite
    direction from what I was trying to suggest.  In my opinion, the
    details about how to generate the downward source routes are all
    implementation details.  All that's needed for rule 3 is:

  3.  In non-storing mode, the DODAG Root MUST be able to generate
      source routes for destinations learned from DAOs

C12. It seems surprising that the following text, which is the first indication
    that the root of a grounded DODAG would act as a gateway between
    an LLN and other networks, appears in the description of
    multicast behavior in section 12:

      For unicast traffic, it is expected that the grounded DODAG root acts
      as a Low power and lossy network Border Router (LBR) and MAY
      redistribute the RPL routes over the external infrastructure using
      whatever routing protocol is used in the other routing domain.

C13. I'm not sure I understand the details of how NS/NA messages are
    used to maintain routing adjacencies.  I understand, in
    principle, that an NS/NA message exchange confirms destination
    reachability.  When, exactly, would this exchange be used?  Can
    traffic received from the neighbor be used, as in ND NUD, to
    confirm the routing adjacency?

[Ballot discuss]
Edited to reflect issues that have been resolved or updated based on rev -18.

D2. The RPL Prefix Information option (PIO) is based on the Neighbor
    Discovery PIO.  I understand that RPL uses the PIO for passing the
    global address of the sending node to the receiver of a DIO
    message.  I also understand that the RPL PIO may be used to
    propagate information about prefix(es) assigned to the LLN across
    the participating nodes.  Is it possible to use the PIO to carry
    the global address of the parent without configuring the
    corresponding prefix?  How are the Valid and Preferred Lifetimes,
    and the L and A bits from the RPL PIO to be used in a node running
    RPL?  Why would those functions from ND be duplicated in RPL?
    6lowpan-ND also defines a mechanism for communicating the
    prefix(es) in an LLN.  For RPL, why not just define a simple
    option that carries the GUA of the sending node if required for
    non-storing mode?

D4. I see that the text in section 12 has been edited; it seems less
    clear to me now than the the corresponding text in the previous
    revision.  I strongly recommend that section 12 be edited out of
    the document and multicast support be published as a separate
    document.

[Ballot comment]
C8. The definition of DAO-ACK rejection codes seems unclear to me:

        Status 0 is unqualified
        acceptance, 1 to 127 are unassigned and undetermined, and 128
        and greater are rejection codes used to indicate that the node
        should select an alternate parent.

Is it the case that 1 to 127 might be used to indicate some
non-rejection status while 128-255 are used to indicate a status that
requires selection of a new parent?

C10. The update to section 9.2, rule 3, actually went in the opposite
    direction from what I was trying to suggest.  In my opinion, the
    details about how to generate the downward source routes are all
    implementation details.  All that's needed for rule 3 is:

  3.  In non-storing mode, the DODAG Root MUST be able to generate
      source routes for destinations learned from DAOs

C12. It seems surprising that this text, which is the first indication
    that the root of a grounded DODAG would act as a gateway between
    an LLN and other networks, appears in the description of
    multicast behavior in section 12:

      For unicast traffic, it is expected that the grounded DODAG root acts
      as a Low power and lossy network Border Router (LBR) and MAY
      redistribute the RPL routes over the external infrastructure using
      whatever routing protocol is used in the other routing domain.

C13. I'm not sure I understand the details of how NS/NA messages are
    used to maintain routing adjacencies.  I understand, in
    principle, that an NS/NA message exchange confirms destination
    reachability.  When, exactly, would this exchange be used?  Can
    traffic received from the neighbor be used, as in ND NUD, to
    confirm the routing adjacency?

[Ballot discuss]
Edited to reflect issues that have been resolved or updated based on rev -18.

D2. The RPL Prefix Information option (PIO) is based on the Neighbor
    Discovery PIO.  I understand that RPL uses the PIO for passing the
    global address of the sending node to the receiver of a DIO
    message.  I also understand that the RPL PIO may be used to
    propagate information about prefix(es) assigned to the LLN across
    the participating nodes.  Is it possible to use the PIO to carry
    the global address of the parent without configuring the
    corresponding prefix?  How are the Valid and Preferred Lifetimes,
    and the L and A bits from the RPL PIO to be used in a node running
    RPL?  Why would those functions from ND be duplicated in RPL?
    6lowpan-ND also defines a mechanism for communicating the
    prefix(es) in an LLN.  For RPL, why not just define a simple
    option that carries the GUA of the sending node if required for
    non-storing mode?

D4. The text in section 12 is improved.  However, while the second
    paragraph states "RPL provide a trivial mapping betwen MLD queries
    and RPL DAOs", in my opinion this section should be rewritten to
    be more precise and more closely follow the MLD RFCs.  For
    example, if I understand RPL multicast operation correctly, I
    think "MLD queries" in the second paragraph should be replaced
    with "MLD Listener Report messages".  In the sixth paragraph, "MLD
    requests" should be replaced with MLD Listener Report messages".

    Formally speaking, I don't agree that RPL "maps" MLD Listener
    Report messages into DAO messages.  Rather, the router with which
    a ndoe exchanges MLD messages identifies multicast groups for
    which ther are listeners, and then uses DAO messages to report
    those groups up the DODAG.

    Does a RPL router ever send MLD Query messages to identify the
    listeners of a multicast group attached to the router?  More
    generally, does the RPL router implement full MLDv1 and MLDv2, and
    then report the multicast groups of interest up the DODAG in a
    DAO?

    Are there references available for proxy MLD and proxy IGMP?

    Does the LBR infer that it should perform proxy MLD for every
    mulitcast address it receives in a DAO?  If not, how does it
    determine which multicast groups it should proxy?

[Ballot discuss]
(Updated on December 23rd to reflect current document and all the
other information we've received in the meantime.)

This is a well written document and I was positively surprised that
it is in relatively good shape. I did have a number of concerns or
question marks, however, and would like to discuss them. Some of this
is indeed questions -- pardon my lack of understanding of the entire
system.

1. RPL relies on a new model for packet forwarding as well as the routing
machinery. Yet the IESG only sees this document, while some others are
still in the 6MAN working group. Given that the documents have now
progressed to WGLC, I don't think we have a big problem though. I will
hold this discuss until the WGLC is finished and I have myself reviewed
the documents again to ensure that they are safe.

2. Removed.

3. The protocol mechanisms are complex and the document is long. Just
the base document is 140 pages long, and there are mandatory pieces
elsewhere (drafts in ROLL and 6MAN). But yet we are talking about small
devices. I'm left wondering whether the working group could have
modularized the specification in a different way. For instance, the
document supports both storing and non-storing modes, couldn't
those have been in different specs? Why does the protocol provide
an "IP layer VLAN" mechanism (= instances) alongside everything else
that it does?

4. Thanks for the updated specification regarding ND options, and
the very useful examples in Appendix A. I did have a few remaining
smaller issues within those, however:

  Section 6.7.10:

    In particular, a RPL node may use this
    option for the purpose of State-Less Address Auto-Configuration
    (SLAAC) from a prefix advertised by a parent as specified in
    [RFC4862], and advertise its own address as specified in [RFC3775].
    The root of a DODAG is authoritative for setting that information.
    The information is propagated down the DODAG unchanged, with the
    exception that a RPL router may update (extend) the prefix by
    appending it's own suffix.

  The last sentence does not seem completely correct. You cannot extend
  the prefix without changing the interface ID part. Did you mean
  "extend" as (a) making the prefix longer or (b) replacing a different
  IID? Per RFC 3775, the IID and the prefix share the same 128 bits, so
  any attempt to do (a) will result in IID being overwritten.

  Section 9.4:

    A parent that
    advertises a prefix in a PIO with the 'A' flag set MUST ensure
    that the address or the whole prefix in the PIO is reachable from
    the root by advertising it as a DAO target.

  Not specific enough. It would seem that if you advertise a prefix with
  'A' set, the parent should ensure that the whole prefix is
  reachable. Otherwise a node that configures an address from this
  prefix will not be reachable.

  Section 9.4:

  4.  In order to enable an optimum compression of the routing header,
      the parent SHOULD set the 'R' flag in all PIOs with the 'A' flag
      set and the 'L' flag cleared, and the child SHOULD prefer to use
      as transit the address of the parent that is found in the PIO
      that is used to autoconfigure the address that is advertised as
      target in the DAO message.

  Its unclear why this recommendation is made. This removes the address
  autoconfiguration capability.

  Appendix A.1:

  Its confusing when the example has both names and bits for prefixes,
  e.g., is EXT_1::0//64 same as 2001:DB8:1:1::/64?

  Appendix A.1:

    3. Node Z may interact with another neighboring non-RPL router in
      EXT_2::/64. Node Z may repackage the information learned from
      the RPL network in order to announce that information into the
      other neighboring network. For example, Node Z may repackage a
      RIO to indicate reachability to EXT_1::/64.

  On the first read I was confused which direction the information
  flows to. Please be more specific. E.g., ... may repackage a
  RPL RIO sent by the root node to a RIO in a router advertisement
  sent to the second external network.

  Appendix A.1:

    4. Node Z, on behalf of the non-RPL aware host Host1, will send DAOs
      containing Host1 as a Target and itself (Node Z) as a parent in
      the Transit Information option.  (In storing mode that Transit
      Information option does not need to contain the address of Node
      Z).  A non-storing root then becomes aware of the 1-hop link Node
      Z -- Host1 for use in constructing source routes.

  But in IPv6 neighbor discovery, there is no guarantee that you know
  what address(es) Host1 has allocated for itself. RFC 3041 and so on.
  Shouldn't Z advertise a prefix of some sort?

  Appendix A.1:

  This example would be better if it talked about what L and A flag
  settings and PIOs get used. Your example starts from a complex case
  (external networks) but doesn't cover the basic case.

  Section A.3.3.

    Node A will conceptually collect the following information into
    its RIB:
      o A::/128 connected

  Hmm. Isn't this A::A (that's the only address A has that is directly
  connected)

5. I do not understand how NUD and RPL interact. Section 8.2.1
says that if NUD fails then the upward entity should be removed
from consideration. However, since RFC 4861 specifies that NUD
is only run if there's traffic to send, what causes traffic to be
sent? My understanding is that this you actually want to avoid
traffic being sent unless you have some real payload traffic to
go out. However, I think the document should explain it.

[Ballot discuss]
(Updated on December 23rd to reflect current document and all the
other information we've received in the meantime.)

This is a well written document and I was positively surprised that
it is in relatively good shape. I did have a number of concerns or
question marks, however, and would like to discuss them. Some of this
is indeed questions -- pardon my lack of understanding of the entire
system.

1. RPL relies on a new model for packet forwarding as well as the routing
machinery. Yet the IESG only sees this document, while some others are
still in -00 stage at the 6MAN working group. I would normally not worry
about a normative reference to a draft, but in this case the success
of the architectural model depends on these drafts going forward as is.
I have looked at them myself and I actually believe they too are in good
shape. But I wonder if we should hold the approval of this document
until we see the whole set of documents (at least emerge from the WG,
maybe even IETF Last Call).

2. Removed.

3. The protocol mechanisms are complex and the document is long. Just
the base document is 140 pages long, and there are mandatory pieces
elsewhere (drafts in ROLL and 6MAN). But yet we are talking about small
devices. I'm left wondering whether the working group could have
modularized the specification in a different way. For instance, the
document supports both storing and non-storing modes, couldn't
those have been in different specs? Why does the protocol provide
an "IP layer VLAN" mechanism (= instances) alongside everything else
that it does?

4. Thanks for the updated specification regarding ND options, and
the very useful examples in Appendix A. I did have a few remaining
smaller issues within those, however:

  Section 6.7.10:

    In particular, a RPL node may use this
    option for the purpose of State-Less Address Auto-Configuration
    (SLAAC) from a prefix advertised by a parent as specified in
    [RFC4862], and advertise its own address as specified in [RFC3775].
    The root of a DODAG is authoritative for setting that information.
    The information is propagated down the DODAG unchanged, with the
    exception that a RPL router may update (extend) the prefix by
    appending it's own suffix.

  The last sentence does not seem completely correct. You cannot extend
  the prefix without changing the interface ID part. Did you mean
  "extend" as (a) making the prefix longer or (b) replacing a different
  IID? Per RFC 3775, the IID and the prefix share the same 128 bits, so
  any attempt to do (a) will result in IID being overwritten.

  Section 9.4:

    A parent that
    advertises a prefix in a PIO with the 'A' flag set MUST ensure
    that the address or the whole prefix in the PIO is reachable from
    the root by advertising it as a DAO target.

  Not specific enough. It would seem that if you advertise a prefix with
  'A' set, the parent should ensure that the whole prefix is
  reachable. Otherwise a node that configures an address from this
  prefix will not be reachable.

  Section 9.4:

  4.  In order to enable an optimum compression of the routing header,
      the parent SHOULD set the 'R' flag in all PIOs with the 'A' flag
      set and the 'L' flag cleared, and the child SHOULD prefer to use
      as transit the address of the parent that is found in the PIO
      that is used to autoconfigure the address that is advertised as
      target in the DAO message.

  Its unclear why this recommendation is made. This removes the address
  autoconfiguration capability.

  Appendix A.1:

  Its confusing when the example has both names and bits for prefixes,
  e.g., is EXT_1::0//64 same as 2001:DB8:1:1::/64?

  Appendix A.1:

    3. Node Z may interact with another neighboring non-RPL router in
      EXT_2::/64. Node Z may repackage the information learned from
      the RPL network in order to announce that information into the
      other neighboring network. For example, Node Z may repackage a
      RIO to indicate reachability to EXT_1::/64.

  On the first read I was confused which direction the information
  flows to. Please be more specific. E.g., ... may repackage a
  RPL RIO sent by the root node to a RIO in a router advertisement
  sent to the second external network.

  Appendix A.1:

    4. Node Z, on behalf of the non-RPL aware host Host1, will send DAOs
      containing Host1 as a Target and itself (Node Z) as a parent in
      the Transit Information option.  (In storing mode that Transit
      Information option does not need to contain the address of Node
      Z).  A non-storing root then becomes aware of the 1-hop link Node
      Z -- Host1 for use in constructing source routes.

  But in IPv6 neighbor discovery, there is no guarantee that you know
  what address(es) Host1 has allocated for itself. RFC 3041 and so on.
  Shouldn't Z advertise a prefix of some sort?

  Appendix A.1:

  This example would be better if it talked about what L and A flag
  settings and PIOs get used. Your example starts from a complex case
  (external networks) but doesn't cover the basic case.

  Section A.3.3.

    Node A will conceptually collect the following information into
    its RIB:
      o A::/128 connected

  Hmm. Isn't this A::A (that's the only address A has that is directly
  connected)

5. I do not understand how NUD and RPL interact. Section 8.2.1
says that if NUD fails then the upward entity should be removed
from consideration. However, since RFC 4861 specifies that NUD
is only run if there's traffic to send, what causes traffic to be
sent? My understanding is that this you actually want to avoid
traffic being sent unless you have some real payload traffic to
go out. However, I think the document should explain it.

[Ballot discuss]
(Updated on December 23rd to reflect current document and all the
other information we've received in the meantime.)

This is a well written document and I was positively surprised that
it is in relatively good shape. I did have a number of concerns or
question marks, however, and would like to discuss them. Some of this
is indeed questions -- pardon my lack of understanding of the entire
system.

1. RPL relies on a new model for packet forwarding as well as the routing
machinery. Yet the IESG only sees this document, while some others are
still in -00 stage at the 6MAN working group. I would normally not worry
about a normative reference to a draft, but in this case the success
of the architectural model depends on these drafts going forward as is.
I have looked at them myself and I actually believe they too are in good
shape. But I wonder if we should hold the approval of this document
until we see the whole set of documents (at least emerge from the WG,
maybe even IETF Last Call).

2. Removed.

3. The protocol mechanisms are complex and the document is long. Just
the base document is 140 pages long, and there are mandatory pieces
elsewhere (drafts in ROLL and 6MAN). But yet we are talking about small
devices. I'm left wondering whether the working group could have
modularized the specification in a different way. For instance, the
document supports both storing and non-storing modes, couldn't
those have been in different specs?

4. Thanks for the updated specification regarding ND options, and
the very useful examples in Appendix A. I did have a few remaining
smaller issues within those, however:

  Section 6.7.10:

    In particular, a RPL node may use this
    option for the purpose of State-Less Address Auto-Configuration
    (SLAAC) from a prefix advertised by a parent as specified in
    [RFC4862], and advertise its own address as specified in [RFC3775].
    The root of a DODAG is authoritative for setting that information.
    The information is propagated down the DODAG unchanged, with the
    exception that a RPL router may update (extend) the prefix by
    appending it's own suffix.

  The last sentence does not seem completely correct. You cannot extend
  the prefix without changing the interface ID part. Did you mean
  "extend" as (a) making the prefix longer or (b) replacing a different
  IID? Per RFC 3775, the IID and the prefix share the same 128 bits, so
  any attempt to do (a) will result in IID being overwritten.

  Section 9.4:

    A parent that
    advertises a prefix in a PIO with the 'A' flag set MUST ensure
    that the address or the whole prefix in the PIO is reachable from
    the root by advertising it as a DAO target.

  Not specific enough. It would seem that if you advertise a prefix with
  'A' set, the parent should ensure that the whole prefix is
  reachable. Otherwise a node that configures an address from this
  prefix will not be reachable.

  Section 9.4:

  4.  In order to enable an optimum compression of the routing header,
      the parent SHOULD set the 'R' flag in all PIOs with the 'A' flag
      set and the 'L' flag cleared, and the child SHOULD prefer to use
      as transit the address of the parent that is found in the PIO
      that is used to autoconfigure the address that is advertised as
      target in the DAO message.

  Its unclear why this recommendation is made. This removes the address
  autoconfiguration capability.

  Appendix A.1:

  Its confusing when the example has both names and bits for prefixes,
  e.g., is EXT_1::0//64 same as 2001:DB8:1:1::/64?

  Appendix A.1:

    3. Node Z may interact with another neighboring non-RPL router in
      EXT_2::/64. Node Z may repackage the information learned from
      the RPL network in order to announce that information into the
      other neighboring network. For example, Node Z may repackage a
      RIO to indicate reachability to EXT_1::/64.

  On the first read I was confused which direction the information
  flows to. Please be more specific. E.g., ... may repackage a
  RPL RIO sent by the root node to a RIO in a router advertisement
  sent to the second external network.

  Appendix A.1:

    4. Node Z, on behalf of the non-RPL aware host Host1, will send DAOs
      containing Host1 as a Target and itself (Node Z) as a parent in
      the Transit Information option.  (In storing mode that Transit
      Information option does not need to contain the address of Node
      Z).  A non-storing root then becomes aware of the 1-hop link Node
      Z -- Host1 for use in constructing source routes.

  But in IPv6 neighbor discovery, there is no guarantee that you know
  what address(es) Host1 has allocated for itself. RFC 3041 and so on.
  Shouldn't Z advertise a prefix of some sort?

  Appendix A.1:

  This example would be better if it talked about what L and A flag
  settings and PIOs get used. Your example starts from a complex case
  (external networks) but doesn't cover the basic case.

  Section A.3.3.

    Node A will conceptually collect the following information into
    its RIB:
      o A::/128 connected

  Hmm. Isn't this A::A (that's the only address A has that is directly
  connected)

5. I do not understand how NUD and RPL interact. Section 8.2.1
says that if NUD fails then the upward entity should be removed
from consideration. However, since RFC 4861 specifies that NUD
is only run if there's traffic to send, what causes traffic to be
sent? My understanding is that this you actually want to avoid
traffic being sent unless you have some real payload traffic to
go out. However, I think the document should explain it.

[Ballot discuss]
(Updated on December 23rd to reflect current document and all the
other information we've received in the meantime.)

This is a well written document and I was positively surprised that
it is in relatively good shape. I did have a number of concerns or
question marks, however, and would like to discuss them. Some of this
is indeed questions -- pardon my lack of understanding of the entire
system.

1. RPL relies on a new model for packet forwarding as well as the routing
machinery. Yet the IESG only sees this document, while some others are
still in -00 stage at the 6MAN working group. I would normally not worry
about a normative reference to a draft, but in this case the success
of the architectural model depends on these drafts going forward as is.
I have looked at them myself and I actually believe they too are in good
shape. But I wonder if we should hold the approval of this document
until we see the whole set of documents (at least emerge from the WG,
maybe even IETF Last Call).

3. The protocol mechanisms are complex and the document is long. Just
the base document is 140 pages long, and there are mandatory pieces
elsewhere (drafts in ROLL and 6MAN). But yet we are talking about small
devices. I'm left wondering whether the working group could have
modularized the specification in a different way. For instance, the
document supports both storing and non-storing modes, couldn't
those have been in different specs?

4. Thanks for the updated specification regarding ND options, and
the very useful examples in Appendix A. I did have a few remaining
smaller issues within those, however:

  Section 6.7.10:

    In particular, a RPL node may use this
    option for the purpose of State-Less Address Auto-Configuration
    (SLAAC) from a prefix advertised by a parent as specified in
    [RFC4862], and advertise its own address as specified in [RFC3775].
    The root of a DODAG is authoritative for setting that information.
    The information is propagated down the DODAG unchanged, with the
    exception that a RPL router may update (extend) the prefix by
    appending it's own suffix.

  The last sentence does not seem completely correct. You cannot extend
  the prefix without changing the interface ID part. Did you mean
  "extend" as (a) making the prefix longer or (b) replacing a different
  IID? Per RFC 3775, the IID and the prefix share the same 128 bits, so
  any attempt to do (a) will result in IID being overwritten.

  Section 9.4:

    A parent that
    advertises a prefix in a PIO with the 'A' flag set MUST ensure
    that the address or the whole prefix in the PIO is reachable from
    the root by advertising it as a DAO target.

  Not specific enough. It would seem that if you advertise a prefix with
  'A' set, the parent should ensure that the whole prefix is
  reachable. Otherwise a node that configures an address from this
  prefix will not be reachable.

  Section 9.4:

  4.  In order to enable an optimum compression of the routing header,
      the parent SHOULD set the 'R' flag in all PIOs with the 'A' flag
      set and the 'L' flag cleared, and the child SHOULD prefer to use
      as transit the address of the parent that is found in the PIO
      that is used to autoconfigure the address that is advertised as
      target in the DAO message.

  Its unclear why this recommendation is made. This removes the address
  autoconfiguration capability.

  Appendix A.1:

  Its confusing when the example has both names and bits for prefixes,
  e.g., is EXT_1::0//64 same as 2001:DB8:1:1::/64?

  Appendix A.1:

    3. Node Z may interact with another neighboring non-RPL router in
      EXT_2::/64. Node Z may repackage the information learned from
      the RPL network in order to announce that information into the
      other neighboring network. For example, Node Z may repackage a
      RIO to indicate reachability to EXT_1::/64.

  On the first read I was confused which direction the information
  flows to. Please be more specific. E.g., ... may repackage a
  RPL RIO sent by the root node to a RIO in a router advertisement
  sent to the second external network.

  Appendix A.1:

    4. Node Z, on behalf of the non-RPL aware host Host1, will send DAOs
      containing Host1 as a Target and itself (Node Z) as a parent in
      the Transit Information option.  (In storing mode that Transit
      Information option does not need to contain the address of Node
      Z).  A non-storing root then becomes aware of the 1-hop link Node
      Z -- Host1 for use in constructing source routes.

  But in IPv6 neighbor discovery, there is no guarantee that you know
  what address(es) Host1 has allocated for itself. RFC 3041 and so on.
  Shouldn't Z advertise a prefix of some sort?

  Appendix A.1:

  This example would be better if it talked about what L and A flag
  settings and PIOs get used. Your example starts from a complex case
  (external networks) but doesn't cover the basic case.

  Section A.3.3.

    Node A will conceptually collect the following information into
    its RIB:
      o A::/128 connected

  Hmm. Isn't this A::A (that's the only address A has that is directly
  connected)

5. I do not understand how NUD and RPL interact. Section 8.2.1
says that if NUD fails then the upward entity should be removed
from consideration. However, since RFC 4861 specifies that NUD
is only run if there's traffic to send, what causes traffic to be
sent? And if no traffic is sent, don't the lower level nodes
think that we still have connectivity to some place? (Remember that
in an ad hoc network radio it is quite likely to have unidirectional
connectivity)? Since the upward direction routes are constructed
by messages sent from the root towards the leafs, how do the leafs
find the currently correct route?

[Ballot comment]
Edited to reflect issues that have been resolved or updated based on rev -17.

C7. The definitions of the 'K', 'D' and 'Flags' fields in section
    6.4.1 are a little confusing in relation to the IANA Registry
    request in section 19.12, which refers to bits 0 and 1 of of the
    '8-bit Destination Advertisement Object (DAO) Flag Field'.  The
    same confusion might be true for other flags and flags fields in
    section 6.

C8. The use of DAO-ACK rejection codes seems underdefined.

C10. In section 9.2, rule 3, what is the alternative to the DODAG root
    storing the source routing table entries?  Computing them on
    demand?  If so, isn't that simply an implementation issue?  Also
    s/destination/destinations/

C12. It seems surprising that this text, which is the first indication
    that the root of a grounded DODAG would act as a gateway between
    an LLN and other networks, appears in the description of
    multicast behavior in section 12:

      For unicast traffic, it is expected that the grounded DODAG root acts
      as a Low power and lossy network Border Router (LBR) and MAY
      redistribute the RPL routes over the external infrastructure using
      whatever routing protocol is used in the other routing domain.

C13. I'm not sure I understand the details of how NS/NA messages are
    used to maintain routing adjacencies.  I understand, in
    principle, that an NS/NA message exchange confirms destination
    reachability.  When, exactly, would this exchange be used?  Can
    traffic received from the neighbor be used, as in ND NUD, to
    confirm the routing adjacency?

[Ballot discuss]
Edited to reflect issues that have been resolved or updated based on rev -17.

D2. The RPL Prefix Information option (PIO) is based on the Neighbor
    Discovery PIO.  I understand that RPL uses the PIO for passing the
    global address of the sending node to the receiver of a DIO
    message.  I also understand that the RPL PIO may be used to
    propagate information about prefix(es) assigned to the LLN across
    the participating nodes.  Is it possible to use the PIO to carry
    the global address of the parent without configuring the
    corresponding prefix?  How are the Valid and Preferred Lifetimes,
    and the L and A bits from the RPL PIO to be used in a node running
    RPL?  Why would those functions from ND be duplicated in RPL?
    6lowpan-ND also defines a mechanism for communicating the
    prefix(es) in an LLN.  For RPL, why not just define a simple
    option that carries the GUA of the sending node if required for
    non-storing mode?

D4. The text in section 12 is improved.  However, while the second
    paragraph states "RPL provide a trivial mapping betwen MLD queries
    and RPL DAOs", in my opinion this section should be rewritten to
    be more precise and more closely follow the MLD RFCs.  For
    example, if I understand RPL multicast operation correctly, I
    think "MLD queries" in the second paragraph should be replaced
    with "MLD Listener Report messages".  In the sixth paragraph, "MLD
    requests" should be replaced with MLD Listener Report messages".

    Formally speaking, I don't agree that RPL "maps" MLD Listener
    Report messages into DAO messages.  Rather, the router with which
    a ndoe exchanges MLD messages identifies multicast groups for
    which ther are listeners, and then uses DAO messages to report
    those groups up the DODAG.

    Does a RPL router ever send MLD Query messages to identify the
    listeners of a multicast group attached to the router?  More
    generally, does the RPL router implement full MLDv1 and MLDv2, and
    then report the multicast groups of interest up the DODAG in a
    DAO?

    Are there references available for proxy MLD and proxy IGMP?

    Does the LBR infer that it should perform proxy MLD for every
    mulitcast address it receives in a DAO?  If not, how does it
    determine which multicast groups it should proxy?

D5. The specification of RPL is substantially incomplete without the
    corresponding specifications from the 6man group:
    draft-ietf-6man-rpl-option and
    draft-ietf-6man-rpl-routing-header.  Given that the RPL draft normatively
    references the 6man drafts, RPL cannot be published as an RFC
    until the 6man drafts are also approved for publication as RFCs.
    Since the three drafts are very tightly coupled, I don't think it
    makes sense to approve the RPL specification now (thus making it
    difficult to change) before the 6man drafts are also ready for
    publication.

D8. RPL has two major, non-interoperable operating modes -- storing
    node and non-storing node, and a lot of functionality that is only
    applicable in cases where the RPL network is connected to a
    non-RPL network, or there is more than one active DAG within a
    single RPL instance.

    While there are two groups (that I am aware of) who have begun
    interoperability testing of RPL, it is my understanding that one
    of those groups last tested version -06 or -07 of the RPL spec,
    which was quite different from the current version, and that they
    only tested storing mode.  The other group has only tested
    non-storing mode, and has not tested all of the functions of RPL
    in -17.  While interoperable implementations are not required for
    publication of this document, it is a complicated protocol with
    significant impacts on IP forwarding as well as routing, and it
    would be advantageous to have more complete implementation
    experience before publishing this doc.

[Ballot discuss]
[Revised to exclude issues resolved in -15 and -16, and **adding one new issue covering
the new text on RFC 3610**.  Thanks for the many clarifications!]

Overall, I found this to be a well written document.  However, I did find a number of issues
that should be addressed before publication.

(7) There are two different nonces specified in this document.  There is a 16-bit nonce in
the Consistency Check base object, and a CCM nonce.  Both are generally referred to as
"nonce".  To remove the confusion, I strongly recommend that the notation for all
references to nonces explicitly state "nonce" or "CCM nonce".

I believe that most of the issues with nonces will be resolved once these clarifications
are introduced.

***New issue (8) ***

(8) The text describing the use of CCM in conjunction with digital signatures
is improved but still incomplete.  RFC 3610 computes a flags field that relies
in part on M, and the values are incorrect if M=0.  I suggest the following fix:

CURRENT TEXT
  It uses CCM mode
  [RFC3610] as the encryption scheme with M=0 (as a stream-cipher).
  Note that although [RFC3610] disallows CCM mode with M=0, this
  specification explicitly allows CCM mode with M=0 when used in
  conjunction with a signature as in this case, because the signature
  provides sufficient protection.

SUGGESTED TEXT
  It uses CCM mode
  [RFC3610] as the encryption scheme with M=0 (as a stream-cipher).
  Note that although [RFC3610] disallows CCM mode with M=0, this
  specification explicitly allows CCM mode with M=0 when used in
  conjunction with a signature as in this case, because the signature
  provides sufficient protection.  Note that the value of M' in the flags
  field is set to zero.

[Note: I would like to revisit this issue with the AD and authors.  After
review, I have concerns about using CCM with M=0.  This is unlikely
to be supported by any current toolkits, so we are creating a requirement
for custom coding.  Perhaps it would be simpler to specify counter mode
for use with digital signatures and CCM the rest of the time...]

[Ballot discuss]
[Revised to exclude issues resolved in -15 and -16, and **adding one new issue covering the new text on RFC 3610**.
Thanks for the many clarifications!]

Overall, I found this to be a well written document.  However, I did find a number of issues that should be addressed
before publication.

(7) There are two different nonces specified in this document.  There is a 16-bit nonce in the Consistency Check
base object, and a CCM nonce.  Both are generally referred to as "nonce".  To remove the confusion, I strongly recommend that the notation for all references to nonces explicitly state "nonce" or "CCM nonce".

I believe that most of the issues with nonces will be resolved once these clarifications are introduced.

***New issue (8) ***

(8) The text describing the use of CCM in conjunction with digital signatures
is improved but still incomplete.  RFC 3610 computes a flags field that relies
in part on M, and the values are incorrect if M=0.  I suggest the following fix:

CURRENT TEXT
  It uses CCM mode
  [RFC3610] as the encryption scheme with M=0 (as a stream-cipher).
  Note that although [RFC3610] disallows CCM mode with M=0, this
  specification explicitly allows CCM mode with M=0 when used in
  conjunction with a signature as in this case, because the signature
  provides sufficient protection.

SUGGESTED TEXT
  It uses CCM mode
  [RFC3610] as the encryption scheme with M=0 (as a stream-cipher).
  Note that although [RFC3610] disallows CCM mode with M=0, this
  specification explicitly allows CCM mode with M=0 when used in
  conjunction with a signature as in this case, because the signature
  provides sufficient protection.  Note that the value of M' in the flags
  field is set to zero.

[Note: I would like to revisit this issue with the AD and authors.  After
review, I have concerns about using CCM with M=0.  This is unlikely
to be supported by any current toolkits, so we are creating a requirement
for custom coding.  Perhaps it would be simpler to specify counter mode
for use with digital signatures and CCM the rest of the time...]

[Ballot discuss]
[Revised to exclude issues resolved in -15 and -16, and **adding one new issue covering the new text on RFC 3610**.
Thanks for the many clarifications!]

Overall, I found this to be a well written document.  However, I did find a number of issues that should be addressed
before publication.

(7) There are two different nonces specified in this document.  There is a 16-bit nonce in the Consistency Check
base object, and a CCM nonce.  Both are generally referred to as "nonce".  To remove the confusion, I strongly recommend that the notation for all references to nonces explicitly state "nonce" or "CCM nonce".

***New issue (8) ***

(8) The text describing the use of CCM in conjunction with digital signatures
is improved but still incomplete.  RFC 3610 computes a flags field that relies
in part on M, and the values are incorrect if M=0.  I suggest the following fix:

CURRENT TEXT
  It uses CCM mode
  [RFC3610] as the encryption scheme with M=0 (as a stream-cipher).
  Note that although [RFC3610] disallows CCM mode with M=0, this
  specification explicitly allows CCM mode with M=0 when used in
  conjunction with a signature as in this case, because the signature
  provides sufficient protection.

SUGGESTED TEXT
  It uses CCM mode
  [RFC3610] as the encryption scheme with M=0 (as a stream-cipher).
  Note that although [RFC3610] disallows CCM mode with M=0, this
  specification explicitly allows CCM mode with M=0 when used in
  conjunction with a signature as in this case, because the signature
  provides sufficient protection.  Note that the value of M' in the flags
  field is set to zero.

[Note: I would like to revisit this issue with the AD and authors.  After
review, I have concerns about using CCM with M=0.  This is unlikely
to be supported by any current toolkits, so we are creating a requirement
for custom coding.  Perhaps it would be simpler to specify counter mode
for use with digital signatures and CCM the rest of the time...]

[Ballot discuss]
[Revised to exclude issues resolved in -15 and -16, and **adding one new issue covering the new text on RFC 3610**.
Thanks for the many clarifications!]

Overall, I found this to be a well written document.  However, I did find a number of issues that should be addressed
before publication.

(7) There are two different nonces specified in this document.  There is a 16-bit nonce in the Consistency Check
base object, and a CCM nonce.  Both are generally referred to as "nonce".  To remove the confusion, I strongly recommend that the notation for all references to nonces explicitly state "nonce" or "CCM nonce".

***New issue (8) ***

(8) The text describing the use of CCM in conjunction with digital signatures
is improved but still incomplete.  RFC 3610 computes a flags field that relies
in part on M, and the values are incorrect if M=0.  I suggest the following fix:

CURRENT TEXT
  It uses CCM mode
  [RFC3610] as the encryption scheme with M=0 (as a stream-cipher).
  Note that although [RFC3610] disallows CCM mode with M=0, this
  specification explicitly allows CCM mode with M=0 when used in
  conjunction with a signature as in this case, because the signature
  provides sufficient protection.

SUGGESTED TEXT
  It uses CCM mode
  [RFC3610] as the encryption scheme with M=0 (as a stream-cipher).
  Note that although [RFC3610] disallows CCM mode with M=0, this
  specification explicitly allows CCM mode with M=0 when used in
  conjunction with a signature as in this case, because the signature
  provides sufficient protection.  Note that the value of M' in the flags
  field is set to zero.

[Note: I would like to revisit this issue with the AD and authors.  After review, I have
concerns about using CCM with M=0.  This is unlikely to be supported by any current
toolkits, so we are creating a requirement for custom coding.  Perhaps it would be
simpler to specify counter mode for use with digital signatures and CCM the rest
of the time...]

[Ballot comment]
The Security Considerations includes the following text:

  Replay protection is provided via the use of a non-repeating value
  (nonce) in the packet protection process and storage of some status
  information for each originating device on the receiving device,
  which allows detection of whether this particular nonce value was
  used previously by the originating device.

I believe this refers to the CCM nonce, not the nonce that appears in the
CC base object.  It would also be good to elaborate on "some status
information" - to my knowledge, the information is the triple {originating
device, key id K, last CCM nonce received from the sender}.

[Ballot discuss]
[Revised to exclude issues resolved in -15 and -16, and **adding one new issue covering the new text on RFC 3610**.
Thanks for the many clarifications!]

Overall, I found this to be a well written document.  However, I did find a number of issues that should be addressed
before publication.

(7) There are two different nonces specified in this document.  There is a 16-bit nonce in the Consistency Check
base object, and a CCM nonce.  Both are generally referred to as "nonce".  To remove the confusion, I strongly recommend that the notation for all references to nonces explicitly state "nonce" or "CCM nonce".

***New issue (8) ***

(8) The text describing the use of CCM in conjunction with digital signatures
is improved but still incomplete.  RFC 3610 computes a flags field that relies
in part on M, and the values are incorrect if M=0.  I suggest the following fix:

CURRENT TEXT
                                                                                  It uses CCM mode
  [RFC3610] as the encryption scheme with M=0 (as a stream-cipher).
  Note that although [RFC3610] disallows CCM mode with M=0, this
          specification explicitly allows CCM mode with M=0 when used in
  conjunction with a signature as in this case, because the signature
  provides sufficient protection.
SUGGESTED TEXT
                                                                                  It uses CCM mode
  [RFC3610] as the encryption scheme with M=0 (as a stream-cipher).
  Note that although [RFC3610] disallows CCM mode with M=0, this
          specification explicitly allows CCM mode with M=0 when used in
  conjunction with a signature as in this case, because the signature
  provides sufficient protection.  Note that the value of M' in the flags
          field is set to zero.

[Note: I would like to revisit this issue with the AD and authors.  After review, I have
concerns about using CCM with M=0.  This is unlikely to be supported by any current
toolkits, so we are creating a requirement for custom coding.  Perhaps it would be
simpler to specify counter mode for use with digital signatures and CCM the rest
of the time...]

[Ballot discuss]
[Revised to exclude issues resolved in -15 and -16.  Thanks for the many clarifications!]

Overall, I found this to be a well written document.  However, I did find a number of issues that should be addressed
before publication.

[Note: AD has agreed to review this issue.]
(5) In section 6.1, the document states:

  Message authentication codes (MACs) and signatures cover the entire
  ICMPv6 RPL message

This cannot be exactly correct... the MACs and signatures need to be calculated over the entire message excluding the MAC or signature itself.  Adding detail to address (3) will help clarify this as well.

[Note: AD has agreed to review this issue.]
(7) I believe we have a systemic problem with the nonce.  In general, a nonce is just a random value.  This specification seems to mix in counters in the definition.  In section 10.6:

  The Counter value used in constructing the Nonce to secure the
  outgoing packet MUST be an increment of the last Counter transmitted
  to the particular destination address.

I was also surprised to find that receivers are expected to maintain them:

  storage of some status
  information for each originating device on the receiving device,
  which allows detection of whether this particular nonce value was
  used previously by the originating device.

Maintaining a history of nonces sounds really problematic.

[Ballot discuss]
[Revised to exclude issues resolved in -15 and note issues where general agreement exists for -16.  Thanks for
the many clarifications!]

Overall, I found this to be a well written document.  However, I did find a number of issues that should be addressed
before publication.

[Issue 1 resolved, text to appear in -16]
(1) I understand that the switch to RSA signatures reflects the community consensus, and support that decision.
However, the decision to specify *only* 3072 bit signatures is problematic.  IMHO, devices on LLNs are unlikely
to support such computationally intensive algorithms.

I believe that 2048 bit RSA is sufficiently strong for many roll applications; one could even argue that 1024 bit RSA
would provide a significant upgrade over the 32 and 64 bit MACs.  At a minimum, I believe that a 2048 bit option
should be allowed.  Note that this should not require much additional device footprint, since RSA implementations
are not usually hard-coded to a particular key size.

[Agreement to address Issue 4 by adding security considerations noting the gap and that these other issues need to
be resolved before asymmetric keys are useful, and add informative references to the work currently underway.]
(4) The text in Section 3.3.3 on asymmetric keys (paragraph 4) implies use of a certificate authority, but there is no payload defined to include a certificate in a message.  While the "process by which this key is obtained is out of scope", the process for  sharing the node's public key has to be defined somewhere.  Even if the certificate itself is not distributed y the node, there needs to be a mechanism to inform the receiving node where to find it, and which certificate to request.  I beleive at least one well defined mechanism is needed for this document to progress.

[Note: AD has agreed to review this issue.]
(5) In section 6.1, the document states:

  Message authentication codes (MACs) and signatures cover the entire
  ICMPv6 RPL message

This cannot be exactly correct... the MACs and signatures need to be calculated over the entire message excluding the MAC or signature itself.  Adding detail to address (3) will help clarify this as well.

[Note: AD has agreed to review this issue.]
(7) I believe we have a systemic problem with the nonce.  In general, a nonce is just a random value.  This specification seems to mix in counters in the definition.  In section 10.6:

  The Counter value used in constructing the Nonce to secure the
  outgoing packet MUST be an increment of the last Counter transmitted
  to the particular destination address.

I was also surprised to find that receivers are expected to maintain them:

  storage of some status
  information for each originating device on the receiving device,
  which allows detection of whether this particular nonce value was
  used previously by the originating device.

Maintaining a history of nonces sounds really problematic.

[Ballot discuss]
[Revised to exclude issues resolved in -15.  Thanks for the many clrifications!]

Overall, I found this to be a well written document.  However, I did find a number of issues that should be addressed
before publication.

(1) I understand that the switch to RSA signatures reflects the community consensus, and support that decision.
However, the decision to specify *only* 3072 bit signatures is problematic.  IMHO, devices on LLNs are unlikely
to support such computationally intensive algorithms.

I believe that 2048 bit RSA is sufficiently strong for many roll applications; one could even argue that 1024 bit RSA
would provide a significant upgrade over the 32 and 64 bit MACs.  At a minimum, I believe that a 2048 bit option
should be allowed.  Note that this should not require much additional device footprint, since RSA implementations
are not usually hard-coded to a particular key size.

(4) The text in Section 3.3.3 on asymmetric keys (paragraph 4) implies use of a certificate authority, but there is no payload defined to include a certificate in a message.  While the "process by which this key is obtained is out of scope", the process for  sharing the node's public key has to be defined somewhere.  Even if the certificate itself is not distributed y the node, there needs to be a mechanism to inform the receiving node where to find it, and which certificate to request.  I beleive at least one well defined mechanism is needed for this document to progress.

(5) In section 6.1, the document states:

  Message authentication codes (MACs) and signatures cover the entire
  ICMPv6 RPL message

This cannot be exactly correct... the MACs and signatures need to be calculated over the entire message excluding the MAC or signature itself.  Adding detail to address (3) will help clarify this as well.

(7) I believe we have a systemic problem with the nonce.  In general, a nonce is just a random value.  This specification seems to mix in counters in the definition.  In section 10.6:

  The Counter value used in constructing the Nonce to secure the
  outgoing packet MUST be an increment of the last Counter transmitted
  to the particular destination address.

I was also surprised to find that receivers are expected to maintain them:

  storage of some status
  information for each originating device on the receiving device,
  which allows detection of whether this particular nonce value was
  used previously by the originating device.

Maintaining a history of nonces sounds really problematic.

[Ballot discuss]
[revised to exclude issues resolved in -15]

Overall, I found this to be a well written document.  However, I did find a number of issues that should be addressed
before publication.

(1) I understand that the switch to RSA signatures reflects the community consensus, and support that decision.
However, the decision to specify *only* 3072 bit signatures is problematic.  IMHO, devices on LLNs are unlikely
to support such computationally intensive algorithms.

I believe that 2048 bit RSA is sufficiently strong for many roll applications; one could even argue that 1024 bit RSA
would provide a significant upgrade over the 32 and 64 bit MACs.  At a minimum, I believe that a 2048 bit option
should be allowed.  Note that this should not require much additional device footprint, since RSA implementations
are not usually hard-coded to a particular key size.

(4) The text in Section 3.3.3 on asymmetric keys (paragraph 4) implies use of a certificate authority, but there is no payload defined to include a certificate in a message.  While the "process by which this key is obtained is out of scope", the process for  sharing the node's public key has to be defined somewhere.  Even if the certificate itself is not distributed y the node, there needs to be a mechanism to inform the receiving node where to find it, and which certificate to request.  I beleive at least one well defined mechanism is needed for this document to progress.

(5) In section 6.1, the document states:

  Message authentication codes (MACs) and signatures cover the entire
  ICMPv6 RPL message

This cannot be exactly correct... the MACs and signatures need to be calculated over the entire message excluding the MAC or signature itself.  Adding detail to address (3) will help clarify this as well.

(7) I believe we have a systemic problem with the nonce.  In general, a nonce is just a random value.  This specification seems to mix in counters in the definition.  In section 10.6:

  The Counter value used in constructing the Nonce to secure the
  outgoing packet MUST be an increment of the last Counter transmitted
  to the particular destination address.

I was also surprised to find that receivers are expected to maintain them:

  storage of some status
  information for each originating device on the receiving device,
  which allows detection of whether this particular nonce value was
  used previously by the originating device.

Maintaining a history of nonces sounds really problematic.

[Ballot discuss]
D1. draft-ietf-roll-rpl-12 refers to draft-ietf-6man-rpl-option-00 as
    a normative reference.  It appears that the definitions for the
    contents of the IPv6 Hop-by-Hop RPL option differ between the two
    documents.  Which definition is correct?

D2. The RPL Prefix Information option (PIO) is based on the Neighbor
    Discovery PIO.  I understand that RPL uses the PIO for passing the
    global address of the sending node to the receiver of a DIO
    message.  I also understand that the RPL PIO may be used to
    propagate information about prefix(es) assigned to the LLN across
    the participating nodes.  Is it possible to use the PIO to carry
    the global address of the parent without configuring the
    corresponding prefix?  How are the Valid and Preferred Lifetimes,
    and the L and A bits from the RPL PIO to be used in a node running
    RPL?  Why would those functions from ND be duplicated in RPL?
    6lowpan-ND also defines a mechanism for communicating the
    prefix(es) in an LLN.  For RPL, why not just define a simple
    option that carries the GUA of the sending node if required for
    non-storing mode?

D4. In section 12, how is an MLD request mapped to a DAO message, and
    how do the nodes between the source node (that mapped MLD->DAO)
    and the DODAG root process the resulting DAO?  Where do the MLD
    requests come from?  E.g., in this network:

      root----A----B----C----D

    does D send an MLD request to C, which maps that request into a
    DAO?  Or does D intercept the MLD request and map it into a DAO to
    be send to C?

D5. The specification of RPL is substantially incomplete without the
    corresponding specifications from the 6man group:
    draft-ietf-6man-rpl-option-00 and
    draft-ietf-6man-rpl-routing-header-00.  The 6man-rpl-option draft
    has only recently been adopted by the 6man WG (July 2010), and
    both 6man drafts still need more work before they will be ready
    for publication, IMO.  Given that the RPL draft normatively
    references the 6man drafts, RPL cannot be published as an RFC
    until the 6man drafts are also approved for publication as RFCs.
    Since the three drafts are very tightly coupled, I don't think it
    makes sense to approve the RPL specification now (thus making it
    difficult to change) before the 6man drafts are also ready for
    publication.

D6. Section 11.2.2.1 of the document current says:

    "A RPL router that forwards a packet in the RPL network MUST check
    if the packet includes an IPv6 Hop-by-Hop RPL Option, and that the
    RPL Option contains RPL Packet Information (Figure 32).  If not,
    then the RPL router MUST insert a RPL Option with RPL Packet
    Information as specified in [I-D.ietf-6man-rpl-option].  If the
    router is an ingress router that injects the packet into the RPL
    network, the router MUST set the RPLInstanceID field in the RPL
    Packet Information.  The details of how that router determines the
    mapping to a RPLInstanceID are out of scope for this specification
    and left to future specification.

    "A router that forwards a packet to outside the RPL network MUST
    remove the RPL Option as specified in [I-D.ietf-6man-rpl-option]."

    There are at least two significant issues with this
    description:

    - When the RPL header is added to the packet, there is no
      guarantee that there will already be a hop-by-hop options header
      in the packet.  If not, it will need to be inserted, too.
      Depending on how this is done, it could cause the next header
      field to change in the IPv6 header, thus invalidating the
      pseudo-header checksum on packets that are received from outside
      of the RPL instance and are destined to somewhere inside the RPL
      instance.

    - Removing an option from a packet may, depending on how it is
      done, have similar issues.  Could this result in sending an
      empty hop-by-hop option header?  Or would the hop-by-hop header
      be removed if it is now empty?

D7. The draft indicates that a RPL node can forward a packet upwards
    within a particular DAG, by sending it to a lower-ranked node
    within that DAG.  It also indicates that a particular RPL node may
    be in more than one DAG.  The RPL option doesn't contain a DAG
    ID...  So, I am wondering:

    So, if RPL Node A, who happens to be in two DAGs (DAG 1 and DAG 2)
    wants to forward a packet out on to the Internet using the border
    router for DAG 1, but it can't reach that border router directly,
    it forwards the packet to a lower-ranked node in DAG 1, right?
    Let's call this node Node B.

    What if Node B is _also_ in DAG 1 and DAG 2?  How does Node B know
    that the packet should be forwarded in DAG 1 and not DAG 2?

D8. It is my understanding that the Routing area requires multiple
    interoperable implementations of a specification in order to
    publish the specification, and I don't think that RPL currently
    meets that requirement.

    RPL has two major, non-interoperable operating modes -- storing
    node and non-storing node, and a lot of functionality that is only
    applicable in cases where the RPL network is connected to a
    non-RPL network, or there is more than one active DAG within a
    single RPL instance.

    While there are two groups (that I am aware of) who have begun
    interoperability testing of RPL, it is my understanding that one
    of those groups last tested version -06 or -07 of the RPL spec,
    which was quite different from the current version, and that they
    only tested storing mode.  The other group has only tested
    non-storing mode, and has only tested in a single-DAG environment,
    with no routing outside the RPL instance.  This second group just
    started testing the -12 version earlier this month, and has not
    fully tested even the non-storing mode, single DAG
    functionality. Also, to my knowledge, no information about the
    coverage or results of this testing is publicly available.

[Ballot comment]
C2. Does RPL assume symmetric reachability across a link or can it support
    asymmetric reachability?

C7. The definitions of the 'K', 'D' and 'Flags' fields in section
    6.4.1 are a little confusing in relation to the IANA Registry
    request in section 19.12, which refers to bits 0 and 1 of of the
    '8-bit Destination Advertisement Object (DAO) Flag Field'.  The
    same confusion might be true for other flags and flags fields in
    section 6.

C8. Are the DAO ACK Object status rejection codes defined somewhere?

C10. In section 9.2, rule 3, what is the alternative to the DODAG root
    storing the source routing table entries?  Computing them on
    demand?  If so, isn't that simply an implementation issue?

C12. It seems surprising that this text, which is the first indication
    that the root of a grounded DODAG would act as a gateway between
    an LLN and other networks, appears in the description of
    multicast behavior in section 12:

      For unicast traffic, it is expected that the grounded DODAG root acts
      as a Low power and lossy network Border Router (LBR) and MAY
      redistribute the RPL routes over the external infrastructure using
      whatever routing protocol is used in the other routing domain.

C13. I'm not sure I understand the details of how NS/NA messages are
    used to maintain routing adjacencies.  I understand, in
    principle, that an NS/NA message exchange confirms destination
    reachability.  When, exactly, would this exchange be used?  Can
    traffic received from the neighbor be used, as in ND NUD, to
    confirm the routing adjacency?

C14. The description of the Pad1 option (section 6.7.2) says both that
    it is used for inserting one or two octets or padding, and that
    if more than octet of padding is needed, the PadN option should
    be used.

[Ballot discuss]
D1. draft-ietf-roll-rpl-12 refers to draft-ietf-6man-rpl-option-00 as
    a normative reference.  It appears that the definitions for the
    contents of the IPv6 Hop-by-Hop RPL option differ between the two
    documents.  Which definition is correct?

D2. The RPL Prefix Information option (PIO) is based on the Neighbor
    Discovery PIO.  I understand that RPL uses the PIO for passing the
    global address of the sending node to the receiver of a DIO
    message.  I also understand that the RPL PIO may be used to
    propagate information about prefix(es) assigned to the LLN across
    the participating nodes.  Is it possible to use the PIO to carry
    the global address of the parent without configuring the
    corresponding prefix?  How are the Valid and Preferred Lifetimes,
    and the L and A bits from the RPL PIO to be used in a node running
    RPL?  Why would those functions from ND be duplicated in RPL?
    6lowpan-ND also defines a mechanism for communicating the
    prefix(es) in an LLN.  For RPL, why not just define a simple
    option that carries the GUA of the sending node if required for
    non-storing mode?

D4. In section 12, how is an MLD request mapped to a DAO message, and
    how do the nodes between the source node (that mapped MLD->DAO)
    and the DODAG root process the resulting DAO?  Where do the MLD
    requests come from?  E.g., in this network:

      root----A----B----C----D

    does D send an MLD request to C, which maps that request into a
    DAO?  Or does D intercept the MLD request and map it into a DAO to
    be send to C?

D6. Section 11.2.2.1 of the document current says:

    "A RPL router that forwards a packet in the RPL network MUST check
    if the packet includes an IPv6 Hop-by-Hop RPL Option, and that the
    RPL Option contains RPL Packet Information (Figure 32).  If not,
    then the RPL router MUST insert a RPL Option with RPL Packet
    Information as specified in [I-D.ietf-6man-rpl-option].  If the
    router is an ingress router that injects the packet into the RPL
    network, the router MUST set the RPLInstanceID field in the RPL
    Packet Information.  The details of how that router determines the
    mapping to a RPLInstanceID are out of scope for this specification
    and left to future specification.

    "A router that forwards a packet to outside the RPL network MUST
    remove the RPL Option as specified in [I-D.ietf-6man-rpl-option]."

    There are at least two significant issues with this
    description:

    - When the RPL header is added to the packet, there is no
      guarantee that there will already be a hop-by-hop options header
      in the packet.  If not, it will need to be inserted, too.
      Depending on how this is done, it could cause the next header
      field to change in the IPv6 header, thus invalidating the
      pseudo-header checksum on packets that are received from outside
      of the RPL instance and are destined to somewhere inside the RPL
      instance.

    - Removing an option from a packet may, depending on how it is
      done, have similar issues.  Could this result in sending an
      empty hop-by-hop option header?  Or would the hop-by-hop header
      be removed if it is now empty?

D7. The draft indicates that a RPL node can forward a packet upwards
    within a particular DAG, by sending it to a lower-ranked node
    within that DAG.  It also indicates that a particular RPL node may
    be in more than one DAG.  The RPL option doesn't contain a DAG
    ID...  So, I am wondering:

    So, if RPL Node A, who happens to be in two DAGs (DAG 1 and DAG 2)
    wants to forward a packet out on to the Internet using the border
    router for DAG 1, but it can't reach that border router directly,
    it forwards the packet to a lower-ranked node in DAG 1, right?
    Let's call this node Node B.

    What if Node B is _also_ in DAG 1 and DAG 2?  How does Node B know
    that the packet should be forwarded in DAG 1 and not DAG 2?

D8. It is my understanding that the Routing area requires multiple
    interoperable implementations of a specification in order to
    publish the specification, and I don't think that RPL currently
    meets that requirement.

    RPL has two major, non-interoperable operating modes -- storing
    node and non-storing node, and a lot of functionality that is only
    applicable in cases where the RPL network is connected to a
    non-RPL network, or there is more than one active DAG within a
    single RPL instance.

    While there are two groups (that I am aware of) who have begun
    interoperability testing of RPL, it is my understanding that one
    of those groups last tested version -06 or -07 of the RPL spec,
    which was quite different from the current version, and that they
    only tested storing mode.  The other group has only tested
    non-storing mode, and has only tested in a single-DAG environment,
    with no routing outside the RPL instance.  This second group just
    started testing the -12 version earlier this month, and has not
    fully tested even the non-storing mode, single DAG
    functionality. Also, to my knowledge, no information about the
    coverage or results of this testing is publicly available.

[Ballot discuss]
This is a well written document and I was positively surprised that
it is in relatively good shape. I did have a number of concerns or
question marks, however, and would like to discuss them. Some of this
is indeed questions -- pardon my lack of understanding of the entire
system.

1. RPL relies on a new model for packet forwarding as well as the routing
machinery. Yet the IESG only sees this document, while some others are
still in -00 stage at the 6MAN working group. I would normally not worry
about a normative reference to a draft, but in this case the success
of the architectural model depends on these drafts going forward as is.
I have looked at them myself and I actually believe they too are in good
shape. But I wonder if we should hold the approval of this document
until we see the whole set of documents (at least emerge from the WG,
maybe even IETF Last Call).

2. I am happy to see that there has been implementations of this
and some interoperability/ability to implement has been verified.
But given the (new?) algorithms for the actual routing decisions,
what kind of assurances we have that it works well in all conditions?
Has this type of routing mechanism been used before, and what experiences
we have from that? Has there been any formal analysis, simulation, etc?

3. The protocol mechanisms are complex and the document is long. Just
the base document is 140 pages long, and there are mandatory pieces
elsewhere (drafts in ROLL and 6MAN). But yet we are talking about small
devices. I'm left wondering whether the working group could have
modularized the specification in a different way. For instance, the
document supports both storing and non-storing modes, couldn't
those have been in different specs?

4. The specification borrows ND options Prefix Information and Route
Information. There's a little bit information about how RI gets used
in Section 9.7 but it is unclear to me if this is sufficient. I think
the specifications needs to describe how the information gets used
and distributed. What behaviour change happen in the node that receives
it? Will there be re-distribution of the RFC 4191 option to nodes
attached to a "regular" interface on the ad hoc network? Also, I found
no text relating to the use of the PI option.

5. I do not understand how NUD and RPL interact. Section 8.2.1
says that if NUD fails then the upward entity should be removed
from consideration. However, since RFC 4861 specifies that NUD
is only run if there's traffic to send, what causes traffic to be
sent? And if no traffic is sent, don't the lower level nodes
think that we still have connectivity to some place? (Remember that
in an ad hoc network radio it is quite likely to have unidirectional
connectivity)? Since the upward direction routes are constructed
by messages sent from the root towards the leafs, how do the leafs
find the currently correct route?

[Ballot discuss]
draft-ietf-roll-rpl-12 refers to draft-ietf-6man-rpl-option-00 as a
normative reference.  It appears that the definitions for the contents
of the IPv6 Hop-by-Hop RPL option differ between the two documents.
Which definition is correct?

The RPL Prefix Information option (PIO) is based on the Neighbor
Discovery PIO.  I understand that RPL uses the PIO for passing the
global address of the sending node to the receiver of a DIO message.
I also understand that the RPL PIO may be used to propagate
information about prefix(es) assigned to the LLN across the
participating nodes.  Is it possible to use the PIO to carry the
global address of the parent without configuring the corresponding
prefix?  How are the Valid and Preferred Lifetimes, and the L and A
bits from the RPL PIO to be used in a node running RPL?  Why would
those functions from ND be duplicated in RPL?  6lowpn-ND also defines
a mechnism for communicating the prefix(es) in an LLN.  For RPL, why
not just define a simple option that carries the GUA of the sending
node if required for non-storing mode?

Section 9.1, rule 5 indicates that all DAO messages sent in a RPL
instance operating in non-storing mode are unicast to the DODAG root.
But section 9.7 describes how an intermediate node aggregates DAO
information before propagting the DAO information upward.

In section 12, how is an MLD request mapped to a DAO message, and how
do the nodes between the source node (that mapped MLD->DAO) and the
DODAG root process the resulting DAO?  Where do the MLD requests come
from?  E.g., in this network:

  root----A----B----C----D

does D send an MLD request to C, which maps that reqeust into a DAO?
Or does D intercept the MLD request and map it into a DAO to be send
to C?

In my opinion, RPL is tied into the IP forwarding layer in a couple of
important ways.  Foe example, if I understand the IP forwarding model
under RPL correctly, every IP datagram in an LLN using RPL will be
required to carry an IPv6 Hop-by-Hop RPL option.  Because of that
tie-in, I've asked for an IP Directorate review of
draft-ietf-roll-rpl-12.  Margaret Wasserman provided the review
included below.  Note that I've copied Margaret's review here
verbatim; I will re-read her review and move pieces between
DISCUS and COMMENT as appropriate.

From Margaret:

As a member of the IP directorate, I was encouraged to review
draft-ietf-roll-rpl-12.txt.

In general, I support the RPL effort, and I think that the IETF should
publish the RPL protocol as a standards track RFC.  This protocol has
already been adopted by a couple of industry standards bodies for
inclusion in their "profiles", and it is likely to be widely deployed
in the future.

However, I have several concerns about approving version -12 of this
specification, at this time.  Here are my concerns, roughly in descending
order of importance:

(0) The specification of RPL is, IMO, substantially incomplete without
  the corresponding specifications from the 6man group:
  draft-ietf-6man-rpl-option-00.txt and
  draft-ietf-6man-rpl-routing-header-00.  The 6man-rpl-option draft
  has only recently been adopted by the 6man WG (July 2010), and
  both 6mand drafts still need more work before they will be ready
  for publication, IMO.  Given that the RPL draft normatively
  references the 6man drafts, RPL cannot be published as an RFC
  until the 6man drafts are also approved for publication as RFCs.
  Since the three drafts are very tightly coupled, I don't think it
  makes sense to approve the RPL specification now (thus making it
  difficult to change) before the 6man drafts are also ready for
  publication.

(1) IMO, there are a couple of important technical issues with this
  specification that should be addressed before it is approved.

  (a) Section 11.2.2.1 of the document current says:

          "A RPL router that forwards a packet in the RPL network
          MUST check if the packet includes an IPv6 Hop-by-Hop RPL
          Option, and that the RPL Option contains RPL Packet
          Information (Figure 32).  If not, then the RPL router MUST
          insert a RPL Option with RPL Packet Information as
          specified in [I-D.ietf-6man-rpl-option].  If the router is
          an ingress router that injects the packet into the RPL
          network, the router MUST set the RPLInstanceID field in
          the RPL Packet Information.  The details of how that
          router determines the mapping to a RPLInstanceID are out
          of scope for this specification and left to future
          specification.

          "A router that forwards a packet to outside the RPL
          network MUST remove the RPL Option as specified in
          [I-D.ietf-6man-rpl-option]."

      There are at least two significant issues with this
      description:

          - When the RPL header is added to the packet, there is no
            guarantee that there will already be a hop-by-hop
            options header in the packet.  If not, it will need to
            be inserted, too.  Depending on how this is done, it
            could cause the next header field to change in the IPv6
            header, thus invalidating the pseudo-header checksum on
            packets that are received from outside of the RPL
            instance and are destined to somewhere inside the RPL
            instance.
          - Removing an option from a packet may, depending on how
            it is done, have similar issues.  Could this result in
            sending an empty hop-by-hop option header?  Or would
            the hop-by-hop header be removed if it is now empty?
          - Inserting a header into a packet increases the size
            of the packet, and could result in MTU/fragmentation
            issues.

          I realize that the 6man draft talks about tunneling these
          packets, which would resolve the checksum issues listed
          above.  The MTU/fragmentation issues still apply, though.

          The 6man draft currently addresses the MTU issues by
          saying that you should use a link with a high-enough MTU
          but there are issues with that, as well: (1) 6lowpan,
          which is the only link type I know of that RPL has been
          run over to date, has an MTU of 1280, not 1280+++ as
          required by the 6lowpan spec, and (2) there is no
          explanation of what RPL routers should do if adding the
          RPL header results in a packet that won't fit --
          presumably send a "packet too big" error, but with what
          MTU size indicated?

          At the very least, this section of the RPL draft is
          incompatible with the 6man draft.  Since these
          options are essential to RPL operation, this is one
          of the reasons I don't think we should approve this
          document before the 6man draft is finished -- because
          we've left some very hard problems for the 6man spec
          to solve, and I'm not convinced they can be solved
          without changes to the RPL spec.

  (b) The draft indicates that a RPL node can forward a packet
      upwards within a particular DAG, by sending it to a lower-ranked
      node within that DAG.  It also indicates that a particular RPL
      node may be in more than one DAG.  The RPL option doesn't
      contain a DAG ID...  So, I am wondering:

      So, if RPL Node A, who happens to be in two DAGs (DAG 1 and
      DAG 2) wants to forward a packet out on to the Internet using
      the border router for DAG 1, but it can't reach that border
      router directly, it forwards the packet to a lower-ranked node
      in DAG 1, right?  Let's call this node Node B.

      What if Node B is _also_ in DAG 1 and DAG 2?  How does Node B
      know that the packet should be forwarded in DAG 1 and not
      DAG 2?

(2) It is my understanding that the Routing area requires multiple
  interoperable implementations of a specification in order to
  publish the specification, and I don't think that RPL currently
  meets that requirement.

  RPL has two major, non-interoperable operating modes -- storing
  node and non-storing node, and a lot of functionality that is only
  applicable in cases where the RPL network is connected to a
  non-RPL network, or there is more than one active DAG within a
  single RPL instance.

  While there are two groups (that I am aware of) who have begun
  interoperability testing of RPL, it is my understanding that one
  of those groups last tested version -06 or -07 of the RPL spec,
  which was quite different from the current version, and that they
  only tested storing mode.  The other group has only tested
  non-storing mode, and has only tested in a single-DAG environment,
  with no routing outside the RPL instance.  This second group just
  started testing the -12 version earlier this month, and has not
  fully tested even the non-storing mode, single DAG
  functionality. Also, to my knowledge, no information about the
  coverage or results of this testing is publicly available.


(3) There are also a couple of minor technical issues with the specification
  that should be addressed before it is published.

  (a) The description of the Pad1 option (section 6.7.2) says both
      that it is used for inserting one or two octets or padding,
      and that if more than octet of padding is needed, the PadN
      option should be used.

  (b) The description of the RPL option is unclear to me.  In
      section 6.7.1, Figure 19 shows the "RPL Option Generic
      Format".  There are then several types of RPL options
      describe.  However, in section 11.2, Figure 32, there is a RPL
      option defined that doesn't appear to contain a type.
      Furthermore, there is a RPL option defined
      draft-ietf-6man-rpl-option that shows an option with a type
      (RPL) length, and a set of sub-TLVs.  The option in Figure 32
      doesn't have a TLV format, and it isn't clear to me whether a
      single RPL option (as decribed in the 6man draft) can contain
      many of the RPL options described in the RPL spec, or only
      one.  Am I missing something here?

(4) I also wonder why it is necessary to list 10 authors on this
  specification.  I haven't been able to find any justification for
  why this document should be an exception to the "5 authors or
  less" rule.  In similar cases in the past, WGs have chosen to list
  no more than a few people as editors on the first page, and to
  include a list of authors later in the draft in an "Authors" or
  "Contributors" section, and I think that should probably be done
  in this case.

Thanks,
Margaret

[Ballot discuss]
In my opinion, RPL is tied into the IP forwarding layer in a couple of
important ways.  Foe example, if I understand the IP forwarding model
under RPL correctly, every IP datagram in an LLN using RPL will be
required to carry an IPv6 Hop-by-Hop RPL option.  Because of that
tie-in, I've asked for an IP Directorate review of
draft-ietf-roll-rpl-12.  I expected to receive it before the telechat
review, but  I haven't received the review, yet; this paragraph is a
placeholder for that review.

draft-ietf-roll-rpl-12 refers to draft-ietf-6man-rpl-option-00 as a
normative reference.  It appears that the definitions for the contents
of the IPv6 Hop-by-Hop RPL option differ between the two documents.
Which definition is correct?

The RPL Prefix Information option (PIO) is based on the Neighbor
Discovery PIO.  I understand that RPL uses the PIO for passing the
global address of the sending node to the receiver of a DIO message.
I also understand that the RPL PIO may be used to propagate
information about prefix(es) assigned to the LLN across the
participating nodes.  Is it possible to use the PIO to carry the
global address of the parent without configuring the corresponding
prefix?  How are the Valid and Preferred Lifetimes, and the L and A
bits from the RPL PIO to be used in a node running RPL?  Why would
those functions from ND be duplicated in RPL?  6lowpn-ND also defines
a mechnism for communicating the prefix(es) in an LLN.  For RPL, why
not just define a simple option that carries the GUA of the sending
node if required for non-storing mode?

Section 9.1, rule 5 indicates that all DAO messages sent in a RPL
instance operating in non-storing mode are unicast to the DODAG root.
But section 9.7 describes how an intermediate node aggregates DAO
information before propagting the DAO information upward.

In section 12, how is an MLD request mapped to a DAO message, and how
do the nodes between the source node (that mapped MLD->DAO) and the
DODAG root process the resulting DAO?  Where do the MLD requests come
from?  E.g., in this network:

  root----A----B----C----D

does D send an MLD request to C, which maps that reqeust into a DAO?
Or does D intercept the MLD request and map it into a DAO to be send
to C?

In my opinion, RPL is tied into the IP forwarding layer in a couple of
important ways.  Foe example, if I understand the IP forwarding model
under RPL correctly, every IP datagram in an LLN using RPL will be
required to carry an IPv6 Hop-by-Hop RPL option.  Because of that
tie-in, I've asked for an IP Directorate review of
draft-ietf-roll-rpl-12.  Margaret Wasserman provided the review
included below.  Note that I've copied Margaret's review here
verbatim; I will re-read her review and move pieces between
DISCUS and COMMENT as appropriate.

From Margaret:

As a member of the IP directorate, I was encouraged to review
draft-ietf-roll-rpl-12.txt.

In general, I support the RPL effort, and I think that the IETF should
publish the RPL protocol as a standards track RFC.  This protocol has
already been adopted by a couple of industry standards bodies for
inclusion in their "profiles", and it is likely to be widely deployed
in the future.

However, I have several concerns about approving version -12 of this
specification, at this time.  Here are my concerns, roughly in descending
order of importance:

(0) The specification of RPL is, IMO, substantially incomplete without
  the corresponding specifications from the 6man group:
  draft-ietf-6man-rpl-option-00.txt and
  draft-ietf-6man-rpl-routing-header-00.  The 6man-rpl-option draft
  has only recently been adopted by the 6man WG (July 2010), and
  both 6mand drafts still need more work before they will be ready
  for publication, IMO.  Given that the RPL draft normatively
  references the 6man drafts, RPL cannot be published as an RFC
  until the 6man drafts are also approved for publication as RFCs.
  Since the three drafts are very tightly coupled, I don't think it
  makes sense to approve the RPL specification now (thus making it
  difficult to change) before the 6man drafts are also ready for
  publication.

(1) IMO, there are a couple of important technical issues with this
  specification that should be addressed before it is approved.

  (a) Section 11.2.2.1 of the document current says:

          "A RPL router that forwards a packet in the RPL network
          MUST check if the packet includes an IPv6 Hop-by-Hop RPL
          Option, and that the RPL Option contains RPL Packet
          Information (Figure 32).  If not, then the RPL router MUST
          insert a RPL Option with RPL Packet Information as
          specified in [I-D.ietf-6man-rpl-option].  If the router is
          an ingress router that injects the packet into the RPL
          network, the router MUST set the RPLInstanceID field in
          the RPL Packet Information.  The details of how that
          router determines the mapping to a RPLInstanceID are out
          of scope for this specification and left to future
          specification.

          "A router that forwards a packet to outside the RPL
          network MUST remove the RPL Option as specified in
          [I-D.ietf-6man-rpl-option]."

      There are at least two significant issues with this
      description:

          - When the RPL header is added to the packet, there is no
            guarantee that there will already be a hop-by-hop
            options header in the packet.  If not, it will need to
            be inserted, too.  Depending on how this is done, it
            could cause the next header field to change in the IPv6
            header, thus invalidating the pseudo-header checksum on
            packets that are received from outside of the RPL
            instance and are destined to somewhere inside the RPL
            instance.
          - Removing an option from a packet may, depending on how
            it is done, have similar issues.  Could this result in
            sending an empty hop-by-hop option header?  Or would
            the hop-by-hop header be removed if it is now empty?
          - Inserting a header into a packet increases the size
            of the packet, and could result in MTU/fragmentation
            issues.

          I realize that the 6man draft talks about tunneling these
          packets, which would resolve the checksum issues listed
          above.  The MTU/fragmentation issues still apply, though.

          The 6man draft currently addresses the MTU issues by
          saying that you should use a link with a high-enough MTU
          but there are issues with that, as well: (1) 6lowpan,
          which is the only link type I know of that RPL has been
          run over to date, has an MTU of 1280, not 1280+++ as
          required by the 6lowpan spec, and (2) there is no
          explanation of what RPL routers should do if adding the
          RPL header results in a packet that won't fit --
          presumably send a "packet too big" error, but with what
          MTU size indicated?

          At the very least, this section of the RPL draft is
          incompatible with the 6man draft.  Since these
          options are essential to RPL operation, this is one
          of the reasons I don't think we should approve this
          document before the 6man draft is finished -- because
          we've left some very hard problems for the 6man spec
          to solve, and I'm not convinced they can be solved
          without changes to the RPL spec.

  (b) The draft indicates that a RPL node can forward a packet
      upwards within a particular DAG, by sending it to a lower-ranked
      node within that DAG.  It also indicates that a particular RPL
      node may be in more than one DAG.  The RPL option doesn't
      contain a DAG ID...  So, I am wondering:

      So, if RPL Node A, who happens to be in two DAGs (DAG 1 and
      DAG 2) wants to forward a packet out on to the Internet using
      the border router for DAG 1, but it can't reach that border
      router directly, it forwards the packet to a lower-ranked node
      in DAG 1, right?  Let's call this node Node B.

      What if Node B is _also_ in DAG 1 and DAG 2?  How does Node B
      know that the packet should be forwarded in DAG 1 and not
      DAG 2?

(2) It is my understanding that the Routing area requires multiple
  interoperable implementations of a specification in order to
  publish the specification, and I don't think that RPL currently
  meets that requirement.

  RPL has two major, non-interoperable operating modes -- storing
  node and non-storing node, and a lot of functionality that is only
  applicable in cases where the RPL network is connected to a
  non-RPL network, or there is more than one active DAG within a
  single RPL instance.

  While there are two groups (that I am aware of) who have begun
  interoperability testing of RPL, it is my understanding that one
  of those groups last tested version -06 or -07 of the RPL spec,
  which was quite different from the current version, and that they
  only tested storing mode.  The other group has only tested
  non-storing mode, and has only tested in a single-DAG environment,
  with no routing outside the RPL instance.  This second group just
  started testing the -12 version earlier this month, and has not
  fully tested even the non-storing mode, single DAG
  functionality. Also, to my knowledge, no information about the
  coverage or results of this testing is publicly available.


(3) There are also a couple of minor technical issues with the specification
  that should be addressed before it is published.

  (a) The description of the Pad1 option (section 6.7.2) says both
      that it is used for inserting one or two octets or padding,
      and that if more than octet of padding is needed, the PadN
      option should be used.

  (b) The description of the RPL option is unclear to me.  In
      section 6.7.1, Figure 19 shows the "RPL Option Generic
      Format".  There are then several types of RPL options
      describe.  However, in section 11.2, Figure 32, there is a RPL
      option defined that doesn't appear to contain a type.
      Furthermore, there is a RPL option defined
      draft-ietf-6man-rpl-option that shows an option with a type
      (RPL) length, and a set of sub-TLVs.  The option in Figure 32
      doesn't have a TLV format, and it isn't clear to me whether a
      single RPL option (as decribed in the 6man draft) can contain
      many of the RPL options described in the RPL spec, or only
      one.  Am I missing something here?

(4) I also wonder why it is necessary to list 10 authors on this
  specification.  I haven't been able to find any justification for
  why this document should be an exception to the "5 authors or
  less" rule.  In similar cases in the past, WGs have chosen to list
  no more than a few people as editors on the first page, and to
  include a list of authors later in the draft in an "Authors" or
  "Contributors" section, and I think that should probably be done
  in this case.

Thanks,
Margaret

[Ballot discuss]
Overall, I found this to be a well written document.  However, I did find a number of issues that should be addressed
before publication.

(1) I understand that the switch to RSA signatures reflects the community consensus, and support that decision.
However, the decision to specify *only* 3072 bit signatures is problematic.  IMHO, devices on LLNs are unlikely
to support such computationally intensive algorithms.

I believe that 2048 bit RSA is sufficiently strong for many roll applications; one could even argue that 1024 bit RSA
would provide a significant upgrade over the 32 and 64 bit MACs.  At a minimum, I believe that a 2048 bit option
should be allowed.  Note that this should not require much additional device footprint, since RSA implementations
are not usually hard-coded to a particular key size.

(2) The document references SHA2 is a number of locations.  SHA2 is an ambiguous term, as it refers to a family
of algorithms: SHA-224, SHA-256, SHA-384, and SHA-512.  The wg needs to select which specific SHA2 algorithm
will be used.  I strongly encourage the wg to select SHA-256; there is no performance advantage with SHA-224, and
the additional security provided by SHA-384 and SHA-512 is overkill even for 3072 bit RSA.

(3) The document does not specify option payload(s) for the MAC or signature.  I believe this is a requirement for this document to go forward.  Note that the specification references RFC 3447, but fails to specify a padding scheme (both PKCS #1 v1.5 and PSS padding are included in 3447).  These sort of details need to be clarified to achieve interoperability.

(4) The text in Section 3.3.3 on asymmetric keys (paragraph 4) implies use of a certificate authority, but there is no payload defined to include a certificate in a message.  While the "process by which this key is obtained is out of scope", the process for  sharing the node's public key has to be defined somewhere.  Even if the certificate itself is not distributed y the node, there needs to be a mechanism to inform the receiving node where to find it, and which certificate to request.  I beleive at least one well defined mechanism is needed for this document to progress.

(5) In section 6.1, the document states:

  Message authentication codes (MACs) and signatures cover the entire
  ICMPv6 RPL message

This cannot be exactly correct... the MACs and signatures need to be calculated over the entire message excluding the MAC or signature itself.  Adding detail to address (3) will help clarify this as well.

(6) in section 6.1, the descriptions of the KIM field in Figures 8 and 11 are inconsistent, and the text fails to clarify the disconnect.  Figure 8 shows the KIM as 3 bits, Figure 11 implies 2 bits, and the text is silent on length.  I assume that the KIM field is 3 bits based on the length of the reserved field (5 bits) but would like to see it clearly stated.

(7) I believe we have a systemic problem with the nonce.  In general, a nonce is just a random value.  This specification seems to mix in counters in the definition.  In section 10.6:

  The Counter value used in constructing the Nonce to secure the
  outgoing packet MUST be an increment of the last Counter transmitted
  to the particular destination address.

I was also surprised to find that receivers are expected to maintain them:

  storage of some status
  information for each originating device on the receiving device,
  which allows detection of whether this particular nonce value was
  used previously by the originating device.

Maintaining a history of nonces sounds really problematic.

[Ballot discuss]
Overall, I found this to be a well written document.  However, I did find a number of issues that should be addressed
before publication.

(1) I understand that the switch to RSA signatures reflects the community consensus, and support that decision.
However, the decision to specify *only* 3072 bit signatures is problematic.  IMHO, devices on LLNs are unlikely
to support such computationally intensive algorithms.

I believe that 2048 bit RSA is sufficiently strong for many roll applications; one could even argue that 1024 bit RSA
would provide a significant upgrade over the 32 and 64 bit MACs.  At a minimum, I believe that a 2048 bit option
should be allowed.  Note that this should not require much additional device footprint, since RSA implementations
are not usually hard-coded to a particular key size.

(2) The document references SHA2 is a number of locations.  SHA2 is an ambiguous term, as it refers to a family
of algorithms: SHA-224, SHA-256, SHA-384, and SHA-512.  The wg needs to select which specific SHA2 algorithm
will be used.  I strongly encourage the wg to select SHA-256; there is no performance advantage with SHA-224, and
the additional security provided by SHA-384 and SHA-512 is overkill even for 3072 bit RSA.

(3) The document does not specify option payload(s) for the MAC or signature.  I believe this is a requirement for this document to go forward.  Note that the specification references RFC 3447, but fails to specify a padding scheme (both PKCS #1 v1.5 and PSS padding are included in 3447).  These sort of details need to be clarified to achieve interoperability.

(4) The text in Section 3.3.3 on asymmetric keys (paragraph 4) implies use of a certificate authority, but there is no payload defined to include a certificate in a message.  While the "process by which this key is obtained is out of scope", the process for  sharing the node's public key has to be defined somewhere.  Even if the certificate itself is not distributed y the node, there needs to be a mechanism to inform the receiving node where to find it, and which certificate to request.  I beleive at least one well defined mechanism is needed for this document to progress.

(5) In section 6.1, the document states:

  Message authentication codes (MACs) and signatures cover the entire
  ICMPv6 RPL message

This cannot be exactly correct... the MACs and signatures need to be calculated over the entire message excluding the MAC or signature itself.  Adding detail to address (3) will help clarify this as well.

(6) in section 6.1, the descriptions of the KIM field in Figures 8 and 11 are inconsistent, and the text fails to clarify the disconnect.  Figure 8 shows the KIM as 3 bits, Figure 11 implies 2 bits, and the text is silent on length.  I assume that the KIM field is 3 bits based on the length of the reserved field (5 bits) but would like to see it clearly stated.

[Ballot comment]
In section 6.1, the text on the security level should note that the values are not necessarily ordered.  The initial
set of values provide increasing level of security as the LVL value increases, but this could change when new
values are assigned.  For example, if a new KIM=3 level is assigned for Sign-2048, the value would be higher and the security level lower.  Such an assignment is inevitable over the life of the specification, but early implementers may assume these values are ordered.


In 18.1: I believe the word "neither" should be deleted from paragraph 1, sentence 4

OLD
  it cannot always be assumed they have neither a
  trusted computing base nor a high-quality random number generator
  aboard.
NEW
  it cannot always be assumed they have a
  trusted computing base nor a high-quality random number generator
  aboard.

[Ballot discuss]
Overall, I found this to be a well written document.  However, I did find a number of issues that should be addressed
before publication.

(1) I understand that the switch to RSA signatures reflects the community consensus, and support that decision.
However, the decision to specify *only* 3072 bit signatures is problematic.  IMHO, devices on LLNs are unlikely
to support such computationally intensive algorithms.

I believe that 2048 bit RSA is sufficiently strong for many roll applications; one could even argue that 1024 bit RSA
would provide a significant upgrade over the 32 and 64 bit MACs.  At a minimum, I believe that a 2048 bit option
should be allowed.  Note that this should not require much additional device footprint, since RSA implementations
are not usually hard-coded to a particular key size.

(2) The document references SHA2 is a number of locations.  SHA2 is an ambiguous term, as it refers to a family
of algorithms: SHA-224, SHA-256, SHA-384, and SHA-512.  The wg needs to select which specific SHA2 algorithm
will be used.  I strongly encourage the wg to select SHA-256; there is no performance advantage with SHA-224, and
the additional security provided by SHA-384 and SHA-512 is overkill even for 3072 bit RSA.

(3) The document does not specify option payload(s) for the MAC or signature.  I believe this is a requirement for this document to go forward.  Note that the specification references RFC 3447, but fails to specify a padding scheme (both PKCS #1 v1.5 and PSS padding are included in 3447).  These sort of details need to be clarified to achieve interoperability.

(4) The text on asymmetric keys implies use of a certificate authority, but there is no payload defined to include a certificate in a message,  I believe this is a requirement for this document to go forward.

(5) In section 6.1, the document states:

  Message authentication codes (MACs) and signatures cover the entire
  ICMPv6 RPL message

This cannot be exactly correct... the MACs and signatures need to be calculated over the entire message excluding the MAC or signature itself.  Adding detail to address (3) will help clarify this as well.

(6) in section 6.1, the descriptions of the KIM field in Figures 8 and 11 are inconsistent, and the text fails to clarify the disconnect.  Figure 8 shows the KIM as 3 bits, Figure 11 implies 2 bits, and the text is silent on length.  I assume that the KIM field is 3 bits based on the length of the reserved field (5 bits) but would like to see it clearly stated.

[Ballot comment]
In section 6.1

In 18.1: I believe the word "neither" should be deleted from paragraph 1, sentence 4

OLD
  it cannot always be assumed they have neither a
  trusted computing base nor a high-quality random number generator
  aboard.
NEW
  it cannot always be assumed they have a
  trusted computing base nor a high-quality random number generator
  aboard.

[Ballot discuss]
Overall, I found this to be a well written document.  However, I did find a number of issues that should be addressed
before publication.

(1) I understand that the switch to RSA signatures reflects the community consensus, and support that decision.
However, the decision to specify *only* 3072 bit signatures is problematic.  IMHO, devices on LLNs are unlikely
to support such computationally intensive algorithms.

I believe that 2048 bit RSA is sufficiently strong for many roll applications; one could even argue that 1024 bit RSA
would provide a significant upgrade over the 32 and 64 bit MACs.  At a minimum, I believe that a 2048 bit option
should be allowed.  Note that this should not require much additional device footprint, since RSA implementations
are not usually hard-coded to a particular key size.

(2) The document references SHA2 is a number of locations.  SHA2 is an ambiguous term, as it refers to a family
of algorithms: SHA-224, SHA-256, SHA-384, and SHA-512.  The wg needs to select which specific SHA2 algorithm
will be used.  I strongly encourage the wg to select SHA-256; there is no performance advantage with SHA-224, and
the additional security provided by SHA-384 and SHA-512 is overkill even for 3072 bit RSA.

(3) The document does not specify option payload(s) for the MAC or signature.  I believe this is a requirement for this document to go forward.  Note that the specification references RFC 3447, but fails to specify a padding scheme (both PKCS #1 v1.5 and PSS padding are included in 3447).  These sort of details need to be clarified to achieve interoperability.

(4) The text on asymmetric keys implies use of a certificate authority, but there is no payload defined to include a certificate in a message,  I believe this is a requirement for this document to go forward.

(5) In section 6.1, the document states:

  Message authentication codes (MACs) and signatures cover the entire
  ICMPv6 RPL message

This cannot be exactly correct... the MACs and signatures need to be calculated over the entire message excluding the MAC or signature itself.  Adding detail to address (3) will help clarify this as well.

(6) in section 6.1,

[Ballot discuss]
Overall, I found this to be a well written document.  However, I did find a number of issues that should be addressed
before publication.

(1) I understand that the switch to RSA signatures reflects the community consensus, and support that decision.
However, the decision to specify *only* 3072 bit signatures is problematic.  IMHO, devices on LLNs are unlikely
to support such computationally intensive algorithms.

I believe that 2048 bit RSA is sufficiently strong for many roll applications; one could even argue that 1024 bit RSA
would provide a significant upgrade over the 32 and 64 bit MACs.  At a minimum, I believe that a 2048 bit option
should be allowed.  Note that this should not require much additional device footprint, since RSA implementations
are not usually hard-coded to a particular key size.

(2) The document references SHA2 is a number of locations.  SHA2 is an ambiguous term, as it refers to a family
of algorithms: SHA-224, SHA-256, SHA-384, and SHA-512.  The wg needs to select which specific SHA2 algorithm
will be used.  I strongly encourage the wg to select SHA-256; there is no performance advantage with SHA-224, and
the additional security provided by SHA-384 and SHA-512 is overkill even for 3072 bit RSA.

(3) The document does not specify option payload(s) for the MAC or signature.  I believe this is a requirement for this document to go forward.  Note that the specification references RFC 3447, but fails to specify a padding scheme (both PKCS #1 v1.5 and PSS padding are included in 3447).  These sort of details need to be clarified to achieve interoperability.

(4) The text on asymmetric keys implies use of a certificate authority, but there is no payload defined to include a certificate in a message,  I believe this is a requirement for this document to go forward.

(5) In section 6.1, the document states:

  Message authentication codes (MACs) and signatures cover the entire
  ICMPv6 RPL message

This cannot be exactly correct... the MACs and signatures need to be calculated over the entire message excluding the MAC or signature itself.

[Ballot discuss]
Like Ralph, I am concerned about reliance on hop-by-hop options. Normally, I would let Ralph hold the discuss, but since this is a big issues, I would like to remain involved in the discussion.

[Ballot discuss]
Overall, I found this to be a well written document.  However, I did find a number of issues that should be addressed
before publication.

(1) I understand that the switch to RSA signatures reflects the community consensus, and support that decision.
However, the decision to specify *only* 3072 bit signatures is problematic.  IMHO, devices on LLNs are unlikely
to support such computationally intensive algorithms.

I believe that 2048 bit RSA is sufficiently strong for many roll applications; one could even argue that 1024 bit RSA
would provide a significant upgrade over the 32 and 64 bit MACs.  At a minimum, I believe that a 2048 bit option
should be allowed.  Note that this should not require much additional device footprint, since RSA implementations
are not usually hard-coded to a particular key size.

(2) The document references SHA2 is a number of locations.  SHA2 is an ambiguous term, as it refers to a family
of algorithms: SHA-224, SHA-256, SHA-384, and SHA-512.  The wg needs to select which specific SHA2 algorithm
will be used.  I strongly encourage the wg to select SHA-256; there is no performance advantage with SHA-224, and
the additional security provided by SHA-384 and SHA-512 is overkill even for 3072 bit RSA.

(3) The document does not specify option payload(s) for the MAC or signature.  I believe this is a requirement for this document to go forward.  Note that the specification references RFC 3447, but fails to specify a padding scheme (both PKCS #1 v1.5 and PSS padding are included in 3447).  These sort of details need to be clarified to achieve interoperability.

(4) The text on asymmetric keys implies use of a certificate authority, but there is no payload defined to include a certificate in a message,  I believe this is a requirement for this document to go forward.

[Ballot discuss]
Overall, I found this to be a well written document.  However, I did find a number of issues that should be addressed
before publication.

(1) I understand that the switch to RSA signatures reflects the community consensus, and support that decision.
However, the decision to specify *only* 3072 bit signatures is problematic.  IMHO, devices on LLNs are unlikely
to support such computationally intensive algorithms.

I believe that 2048 bit RSA is sufficiently strong for many roll applications; one could even argue that 1024 bit RSA
would provide a significant upgrade over the 32 and 64 bit MACs.  At a minimum, I believe that a 2048 bit option
should be allowed.  Note that this should not require much additional device footprint, since RSA implementations
are not usually hard-coded to a particular key size.

(2) The document references SHA2 is a number of locations.  SHA2 is an ambiguous term, as it refers to a family
of algorithms: SHA-224, SHA-256, SHA-384, and SHA-512.  The wg needs to select which specific SHA2 algorithm
will be used.  I strongly encourage the wg to select SHA-256; there is no performance advantage with SHA-224, and
the additional security provided by SHA-384 and SHA-512 is overkill even for 3072 bit RSA.

(3) The document does not specify option payload(s) for the MAC or signature.  I believe this is a requirement for this document to go forward.  Note that the specification references RFC 3447, but fails to specify a padding scheme (both PKCS #1 v1.5 and PSS padding are included in 3447).  These sort of details need to be clariifed to achieve interoperability.

(4) The text on asymmetric keys implies use of a certificate authority, but there is no payload defined to include a certificate in a message,  I believe this is a requirement for this document to go forward.

[Ballot comment]
In 18.1: I believe the word "neither" should be deleted from paragraph 1, sentence 4

OLD
  it cannot always be assumed they have neither a
  trusted computing base nor a high-quality random number generator
  aboard.
NEW
  it cannot always be assumed they have a
  trusted computing base nor a high-quality random number generator
  aboard.

[Ballot discuss]
Overall, I found this to be a well written document.  However, I did find a number of issues that should be addressed
before publication.

(1) I understand that the switch to RSA signatures reflects the community consensus, and support that decision.
However, the decision to specify *only* 3072 bit signatures is problematic.  IMHO, devices on LLNs are unlikely
to support such computationally intensive algorithms.

I believe that 2048 bit RSA is sufficiently strong for many roll applications; one could even argue that 1024 bit RSA
would provide a significant upgrade over the 32 and 64 bit MACs.  At a minimum, I believe that a 2048 bit option
should be allowed.  Note that this should not require much additional device footprint, since RSA implementations
are not usually hard-coded to a particular key size.

(2) The document references SHA2 is a number of locations.  SHA2 is an ambiguous term, as it refers to a family
of algorithms: SHA-224, SHA-256, SHA-384, and SHA-512.  The wg needs to select which specific SHA2 algorithm
will be used.  I strongly encourage the wg to select SHA-256; there is no performance advantage with SHA-224, and
the additional security provided by SHA-384 and SHA-512 is overkill even for 3072 bit RSA.

(3) The document does not specify option payload(s) for the MAC or signature.  I believe this is a requirement for this document to go forward.

(4) The text on asymmetric keys implies use of a certificate authority, but there is no payload defined to include a certificate in a message,  I believe this is a requirement for this document to go forward.

[Ballot comment]
Is RPL intended only for multi-link subnet networks that share a
single set of prefixes across the entire LLN?

Does RPL assume symmetric reachbility across a link or can it support
asymmetric reachability?

The "virtual root" deployment model seems under-specified.  I wonder
if it might be better to rewrite the references to "virtual root" as
future work?

Section 2 - expand "LBR" on first use.

Section 6 includes descriptions of the semantics of some RPL messages
and options.  It might be better to combine the text describing
semantics into the related text in sections 8 and 9, to gather the
definitions on the semantics into one plase for ease of understanding,
to avoid redundancy and to avoid conflicting text.  For example,
section 6.4 specifies that a DAO is unicast to the DODAG root, but
rule 2 in section 9.7 seems to indicate that DAO objects are sent to
the parent node, which aggregates routing information from DAOs before
sending that information up the DODAG.  As another example, section
6.7.8 includes extensive information about how Transit Information and
RPL Target options are related and carried in a DAO, while section 9.6
has additional text describing those options as part of the structure
of a DAO message.

In section 6.3.1, I think the definition of "Control Field" is out of
sync with the format of the DIO base object; that definition could
probably just be dropped and all of the fields and flags listed in
order.

The definitions of the 'K', 'D' and 'Flags' fields in section 6.4.1
are a little confusing in relation to the IANA Registry request in
section 19.12, which refers to bits 0 and 1 of of the '8-bit
Destination Advertisement Object (DAO) Flag Field'.  The same
confusion might be true for other flags and flags fields in section 6.

Are the DAO ACK Object status rejection codes defined somewhere?

In section 8.2.2.4, what is an "effective rank"?

In section 9.2, rule 3, what is the alternative to the DODAG root
storing the source routing table entries?  Computing them on demand?
If so, isn't that simply an implementation issue?
I'm feeling really dense - I'm completely confused by section 9.9.  In
that section, what is "the node's prefix"?

It seems surprising that this text, which is the first indication that
the root of a grounded DODAG would act as a gateway between an LLN and
other networks, appears in the description of multicast behavior in
section 12:

  For unicast traffic, it is expected that the grounded DODAG root acts
  as a Low power and lossy network Border Router (LBR) and MAY
  redistribute the RPL routes over the external infrastructure using
  whatever routing protocol is used in the other routing domain.

I'm not sure I understand the details of how NS/NA messages are used
to maintain routing adjacencies.  I understand, in principle, that an
NS/NA message exchange confirms destination reachability.  When,
exactly, would this exchange be used?  Can traffic received from the
neighbor be used, as in ND NUD, to confirm the routing adjacency?
Section 17.7 mentions the use of ND NUD, but doesn't mention the use
of NS/NA from section 13.

[Ballot discuss]
In my opinion, RPL is tied into the IP forwarding layer in a couple of
important ways.  Foe example, if I understand the IP forwarding model
under RPL correctly, every IP datagram in an LLN using RPL will be
required to carry an IPv6 Hop-by-Hop RPL option.  Because of that
tie-in, I've asked for an IP Directorate review of
draft-ietf-roll-rpl-12.  I expected to receive it before the telechat
review, but  I haven't received the review, yet; this paragraph is a
placeholder for that review.

draft-ietf-roll-rpl-12 refers to draft-ietf-6man-rpl-option-00 as a
normative reference.  It appears that the definitions for the contents
of the IPv6 Hop-by-Hop RPL option differ between the two documents.
Which definition is correct?

The RPL Prefix Information option (PIO) is based on the Neighbor
Discovery PIO.  I understand that RPL uses the PIO for passing the
global address of the sending node to the receiver of a DIO message.
I also understand that the RPL PIO may be used to propagate
information about prefix(es) assigned to the LLN across the
participating nodes.  Is it possible to use the PIO to carry the
global address of the parent without configuring the corresponding
prefix?  How are the Valid and Preferred Lifetimes, and the L and A
bits from the RPL PIO to be used in a node running RPL?  Why would
those functions from ND be duplicated in RPL?  6lowpn-ND also defines
a mechnism for communicating the prefix(es) in an LLN.  For RPL, why
not just define a simple option that carries the GUA of the sending
node if required for non-storing mode?

Section 9.1, rule 5 indicates that all DAO messages sent in a RPL
instance operating in non-storing mode are unicast to the DODAG root.
But section 9.7 describes how an intermediate node aggregates DAO
information before propagting the DAO information upward.

In section 12, how is an MLD request mapped to a DAO message, and how
do the nodes between the source node (that mapped MLD->DAO) and the
DODAG root process the resulting DAO?  Where do the MLD requests come
from?  E.g., in this network:

  root----A----B----C----D

does D send an MLD request to C, which maps that reqeust into a DAO?
Or does D intercept the MLD request and map it into a DAO to be send
to C?

[Ballot discuss]
I'm not finding guidance for implementations on what to do when
the extension points in the Security Level in 6.1 are exercised.
What is an implementation that's coded using this spec and deployed
supposed to do with a packet that shows up some year with KIM=0,1,2
and LVL=4? I'm looking for some text along the lines of "if a security
option is not understood, the entire message must be silently dropped"
or some other agreed-upon way of processing such messages.

Similarly, I'm not finding what to do if a message with an unknown
control code arrives.

Unless I missed something that should have been obvious (apologies if so),
I suggest a careful review of all places where such extension might
get exercised to see if additional text is needed.

Sections 6 and 19.2 do not agree on the set of control codes being defined.
(0x8A is not in 19.2). (Section 6 says there are three codes just before a
table containing 8 codes).

[Ballot comment]
S3.8 - "RPL avoids creating loops when undergoing topology changes and includes rank-based datapath validation mechanisms for detecting  loops when they do occur (see Section 11 for more details)."

As far as I can see from Section 11 this should be "RPL trys to avoids creating loops...." since the text in section 11 indicates that loops may form. In any case the sentence is self contradicting.

=======

I note that there are 10 Authors on the title page. This does not worry me per se, but I think that we need a consistent policy.

[Ballot comment]
1. It seems to me that 17.2.2 and the following sub-sections have an indentation problem - i.e. 17.2.3, 17.2.4, ... should actually be sub-sections of 17.2.2

2. in section 17.2.6:

> This section deals with the set of parameters
  related to DAO message and provides recommendations on their
  configuration.

s/DAO message/DAO messages/

3. In section 17.4.1:

> A RPL implementation SHOULD provide a way
  to monitor the candidate neighbor list with some metric reflecting
  local confidence

s/to monitor the candidate neighbor list/to allow for the candidate neighbor list to be monitored/

4. In section 17.4.3:

> A RPL implementation SHOULD provide the ability to monitor the
  following parameters

s/SHOULD provide the ability to monitor the following parameters/SHOULD allow for the following parameters to be monitored/

[Ballot discuss]
1. I salute the manageability consideration section which is well written and detailed. However, I am missing some of the manageability functionality that was included in the requirements documents. Even if these are informational, I still expected to find reflected in the document the following (taking into account the nature of the devices implementing RPL):
- regular measurement reporting (section 4.3) and alert reporting (section 4.5) of temperature and environmental data as recommended in RFC 5548
- verbose diagnostic mode as recommended in RFC 5867, section 5.6.1

2. Section 16 talks about RPL constants and variables. It is not clear what happens if the device loses power (may be battery power) - how are these reconfigured? are any variables that need to be kept in non-volatile memory?

3. In section 17.2.6:

> A RPL implementation MAY allow
  for configuring the DelayDAO timer.

If this is a MAY then should not the Delay DAO timer have a default value defined? In this case I would have expected the parameter to be listed in 17.2.8

IANA has questions about this document.

This document, upon approval, will require significant coordination
between the editors and IANA. IANA expects to have many IANA Actions as
a result of approval of this document. The actions will fall into two
main groups:

- registration of parameters and values in registries not specific to
RPL; and,
- the creation of a new, master registry for RPL and a series of
subregistries within it.

Part 1: registration of parameters and values in registries not specific
to RPL. IANA understands that there are three actions of this type that
need to be completed upon approval of the document.

First, in the ICMPv6 "type" Numbers subregistry in the Internet Control
Message Protocol version 6 (ICMPv6) Parameters registry located at:

http://www.iana.org/assignments/icmpv6-parameters

a new "type" number will be added to the registry.

Type Name Reference
---- ---------------------------------------- ---------
tbd1 RPL Control Message RFC-to-be

The authors have suggested a value of 155 for tbd1.

Second, in the ICMPv6 "Code" Fields subregistry in the Internet Control
Message Protocol version 6 (ICMPv6) Parameters registry located at:

http://www.iana.org/assignments/icmpv6-parameters

a new "Code" field will be added to the registry under Type number 1
("Destination Unreachable").

tbd2 - Error in Source Routing Header [RFC-to-be]

The authors suggest a code of 7 for tbd2.

Third, in the Link-Local Scope Multicast Addresses registry in:

http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml

the document requires the allocation of a new permanent multicast
address with a link local scope for RPL nodes called all-RPL-nodes.

The authors suggest an allocation of FF02::1A

Part 2: creation of a new, master registry for RPL and a series of
subregistries within it.

IANA will create a master registry for all RPL-related parameters, codes
and other strings and values that need to be registered on behalf of
RPL. The initial subregistries of the master (yet-to-be-created) RPL
registry will be subregistries for:

- RPL Control Codes
- RPL Mode of Operation DIO Control Field Values
- RPL Control Message Options
- RPL Objective Code Points
- RPL Security Section Flags
- RPL Key Identification Modes
- RPL KIM Levels
- RPL DODAG Informational Solicitation Flags
- RPL DODAG Information Object Flags
- RPL Destination Advertisement Object
- RPL Consistency Check Flags
- RPL DODAG Configuration Option Flags
- RPL Target Option Flags
- RPL Transit Information Option Flags
- RPL Solicited Information Option Flags


RPL Control Codes Subregistry
Reference:
[This document]

Registration procedures:
New codes may be allocated in this subregistry only by an IETF Consensus
action. Each code will be registered with the following properties:

- Code
- Description
- Defining RFC

Initial registrations in this subregistry:

+------+----------------------------------------------+-------------+
| Code | Description | Reference |
+------+----------------------------------------------+-------------+
| 0x00 | DODAG Information Solicitation | This |
| | | document |
| | | |
| 0x01 | DODAG Information Object | This |
| | | document |
| | | |
| 0x02 | Destination Advertisement Object | This |
| | | document |
| | | |
| 0x03 | Destination Advertisement Object | This |
| | Acknowledgment | document |
| | | |
| 0x80 | Secure DODAG Information Solicitation | This |
| | | document |
| | | |
| 0x81 | Secure DODAG Information Object | This |
| | | document |
| 0x82 | Secure Destination Advertisement Object | This |
| | | document |
| | | |
| 0x83 | Secure Destination Advertisement Object | This |
| | Acknowledgment | document |
+------+----------------------------------------------+-------------+

RPL Mode of Operation DIO Control Field Values
Reference:
[This document]

Registration procedures:
New fields may be allocated only by an IETF Consensus action. Each field
should
be registered with the following propertioes:

- Mode of Operation
- Capability description
- Defining RFC

Initial registrations in this subregistry:

+-----+----------------------------------------------+--------------+
| MOP | Description | Reference |
+-----+----------------------------------------------+--------------+
| 000 | No downward routes maintained by RPL | This |
| | | document |
| | | |
| 001 | Non-Storing mode of operation | This |
| | | document |
| | | |
| 010 | Storing mode of operation with no multicast | This |
| | support | document |
| | | |
| 011 | Storing mode of operation with multicast | This |
| | support | document |
+-----+----------------------------------------------+--------------+

IANA QUESTION: should the other bits, 100 - 111, be shown as
unallocated, reserved or given some other indication?

RPL Control Message Options
Reference:
[This document]

Registration procedures:
IANA QUESTION: What are the registration procedures for the RPL Control
Message Options?

Each option should be registered with the following properties:

- Value
- Meaning
- Reference

Initial values for the subregistry:

+-------+-----------------------+---------------+
| Value | Meaning | Reference |
+-------+-----------------------+---------------+
| 0 | Pad1 | This document |
| | | |
| 1 | PadN | This document |
| | | |
| 2 | DAG Metric Container | This Document |
| | | |
| 3 | Routing Information | This Document |
| | | |
| 4 | DODAG Configuration | This Document |
| | | |
| 5 | RPL Target | This Document |
| | | |
| 6 | Transit Information | This Document |
| | | |
| 7 | Solicited Information | This Document |
| | | |
| 8 | Prefix Information | This Document |
| | | |
| 9 | Target Descriptor | This Document |
+-------+-----------------------+---------------+

RPL Objective Code Points
Reference:
[This document]

Registration procedures:
IANA QUESTION: What are the registration procedures for the RPL
Objective Code Points Subregistry?
IANA QUESTION: What properties of the Code Points should be registered?

Initial values for the subregistry:
There are no initial values for this subregistry.

RPL Security Section Flags
Reference
[This document]

Registration procedures:
New bit numbers may be allocated only by an IETF Consensus action. Each
bit should be registered with the following properties:

- Bit number (counting from bit 0 as the most significant bit)
- Capability description
- Defining RFC

Initial values for the subregistry:
There are no initial values for this subregistry.

RPL Key Identification Modes
Reference
[This document]

Registration procedures:
New values may be allocated only by an IETF Consensus action. Each mode
value should be registered with the following properties:

- Value
- Description
- Defining RFC

Initial values for the subregistry:

+-------+---------------+---------------+
| Value | Description | Reference |
+-------+---------------+---------------+
| 0 | See Figure 11 | This document |
| | | |
| 1 | See Figure 11 | This document |
| | | |
| 2 | See Figure 11 | This document |
| | | |
| 3 | See Figure 11 | This document |
+-------+---------------+---------------+

Descriptive text for each one of the RPL Key Identification Nodes is in
Figure 11 of the Document.
IANA QUESTION: should values 4 - 7 be shown as unallocated, reserved or
given some other indication?

RPL KIM Levels
Reference:
[This document]

Registration procedures:
New values may be allocated only by an IETF Consensus action. Each level
should be registered with the following properties:

- Level
- KIM value
- Description
- Defining RFC

Initial values for the subregistry:

+-------+-----------+--------------+---------------+
| Level | KIM value | Description | Reference |
+-------+-----------+--------------+---------------+
| 0 | 0 | See Figure 9 | This document |
| | | | |
| 1 | 0 | See Figure 9 | This document |
| | | | |
| 2 | 0 | See Figure 9 | This document |
| | | | |
| 3 | 0 | See Figure 9 | This document |
| | | | |
| 0 | 1 | See Figure 9 | This document |
| | | | |
| 1 | 1 | See Figure 9 | This document |
| | | | |
| 2 | 1 | See Figure 9 | This document |
| | | | |
| 3 | 1 | See Figure 9 | This document |
| | | | |
| 0 | 2 | See Figure 9 | This document |
| | | | |
| 1 | 2 | See Figure 9 | This document |
| | | | |
| 2 | 2 | See Figure 9 | This document |
| | | | |
| 3 | 2 | See Figure 9 | This document |
| | | | |
| 0 | 3 | See Figure 9 | This document |
| | | | |
| 1 | 3 | See Figure 9 | This document |
+-------+-----------+--------------+---------------+

Descriptive text for each one of the RPL KIM levels is in Figure 9 of
the Document.

RPL DODAG Informational Solicitation Flags
Reference
[This document]

Registration procedures:
New bit numbers may be allocated only by an IETF Consensus action. Each
bit should be registered with the following properties:

- Bit number (counting from bit 0 as the most significant bit)
- Capability description
- Defining RFC

Initial values for the subregistry:
There are no initial values for this subregistry.

RPL DODAG Information Object Flags
Reference
[This document]

Registration procedures:
New bit numbers may be allocated only by an IETF Consensus action. Each
bit should be registered with the following properties:

- Bit number (counting from bit 0 as the most significant bit)
- Capability description
- Defining RFC

Initial values for the subregistry:
There are no initial values for this subregistry.


RPL Destination Advertisement Object
Reference
[This document]

Registration procedures:
New bit numbers may be allocated only by an IETF Consensus action. Each
bit should be registered with the following properties:

- Bit number (counting from bit 0 as the most significant bit)
- Capability description
- Defining RFC

Initial values for the subregistry:

+------------+--------------------------+---------------+
| Bit number | Description | Reference |
+------------+--------------------------+---------------+
| 0 | DAO-ACK request | This document |
| | | |
| 1 | DODAGID field is present | This document |
+------------+--------------------------+---------------+

IANA QUESTION: Some of the descriptive text in section 19.11 and 19.12
of the current draft of the document appears to be the same. However,
the initial values section of 19.11 is different from 19.12. IANA
suspects that a different registry was intended to be described in
Section 19.12 of the current document. It may have been the DAO-Ack Base
Flags subregistry. What was it and what are the proper registration
procedures and initial values for this subregistry?

RPL Consistency Check Flags
Reference
[This document]

Registration procedures:
New bit numbers may be allocated only by an IETF Consensus action. Each
bit should be registered with the following properties:

- Bit number (counting from bit 0 as the most significant bit)
- Capability description
- Defining RFC

Initial value for the subregistry:

+------------+-------------+---------------+
| Bit number | Description | Reference |
+------------+-------------+---------------+
| 0 | CC Response | This document |
+------------+-------------+---------------+

RPL DODAG Configuration Option Flags
Reference
[This document]

Registration procedures:
New bit numbers may be allocated only by an IETF Consensus action. Each
bit should be registered with the following properties:

- Bit number (counting from bit 0 as the most significant bit)
- Capability description
- Defining RFC

Initial values for the subregistry:

+------------+------------------------+---------------+
| Bit number | Description | Reference |
+------------+------------------------+---------------+
| 4 | Authentication Enabled | This document |
| | | |
| 5-7 | Path Control Size | This document |
+------------+------------------------+---------------+

RPL Target Option Flags
Reference
[This document]

Registration procedures:
New bit numbers may be allocated only by an IETF Consensus action. Each
bit should be registered with the following properties:

- Bit number (counting from bit 0 as the most significant bit)
- Capability description
- Defining RFC

Initial values for the subregistry:
There are no initial values for this subregistry.

RPL Transit Information Option Flags
Reference
[This document]

Registration procedures:
New bit numbers may be allocated only by an IETF Consensus action. Each
bit should be registered with the following properties:

- Bit number (counting from bit 0 as the most significant bit)
- Capability description
- Defining RFC

Initial value for the subregistry:

+------------+-------------+---------------+
| Bit number | Description | Reference |
+------------+-------------+---------------+
| 0 | External | This document |
+------------+-------------+---------------+

RPL Solicited Information Option Flags
Reference
[This document]

Registration procedures:
New bit numbers may be allocated only by an IETF Consensus action. Each
bit should be registered with the following properties:

- Bit number (counting from bit 0 as the most significant bit)
- Capability description
- Defining RFC

Initial values for the subregistry:

+------------+----------------------------+---------------+
| Bit number | Description | Reference |
+------------+----------------------------+---------------+
| 0 | Version Predicate match | This document |
| | | |
| 1 | InstanceID Predicate match | This document |
| | | |
| 2 | DODAGID Predicate match | This document |
+------------+----------------------------+---------------+

IANA understands that the actions described in Parts 1 and 2 of this
response represent all of the actions required upon approval of this
document.

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?

David Culler 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?

Yes, the document has had adequate review. 

It represents the culmination of a very active, transparent,  and fully documented process.  The author team is diverse, has met on a weekly or biweekly basis for more than a year, has engaged throughout with the entire WG, and has communicated the developmental steps clearly through a ticket tracking mechanisms as well as extended interim meetings.  The protocol and the document
have gotten progressively simpler over the past 6 months to reach convergence.  The
process has been informed by active implementation.  The document addresses all issues that were articulated in response to Last Call on  draft-ietf-roll-rpl-10.  Although numerous, these issues were almost all clarification or editorial matters.  The WG has had a chance to comment on the resolution of those issues in 11.  Multiple external bodies, such as Zigbee/IP and IPSO, are actively tracking and commenting on this work, so it has received ample review outside the WG.

> (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?

The shepherd has no such concerns.  Outside organizations have already thoroughly reviewed it or its immediate predecessors.  Many of the WG members come from such
organizations and have brought those perspectives into the process.

The process in arriving at this
document involved establishing a shared perspective.

> (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.  It has been developed through a systematic
process to achieve a particular well-defined goal.  Time has been and
contyinues to be of the essense in impacting important on-going
industry developments.  The protocol described therein represents the
knowledge and experience of several of the highly related production
implementations, as well as experience IETF networking know-how.

Two IPR disclosures were made.  The first involved certain aspects of
the basic protocol that may overlap with work on TD in NEMO covered by
CISCO patents.  The disclosure was made after a merge of three
candidate starting points.  There was considerable discussion of
alternatives on the mailing list.  The WG consensed on accepting
Cisco's statement of IPR, after the terms had been modified,
and moving forward with the protocol as defined.

2010-02-23 1270 Cisco's Statement of IPR relating to draft-ietf-roll-rpl-06
2009-11-30 1246 Cisco's Statement of IPR related to draft-dt-roll-rpl-01
2009-04-15 1134 Cisco System's Statement of IPR related to draft-thubert-roll-fundamentals-01

A second disclosure was made in relation to the use of compact
signature schemes for one of the scurity modes.  This issue is related
to a broader question of the IPR around the use of ECDSA, which is
used in IEEE P1363 and FIPS-180-1 and appears in RFC4050, 4492, 4754
and others.  The WG decided to
forego the use of this scheme in the core spec as use a less
efficient, full-strength, RSA scheme.  It retains sufficient
extensibility to address the use of compact schemes in the future.

2010-07-21 1366 Certicom Corp.'s Statement of IPR claimed in draft-ietf-roll-rpl-10

> (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?

It represents strong consensus of a large group.  Those with
implementation experience are most vocal in their support.  Most
hesitation raised has been related the pace and focused nature of the
development.  Some WG members might prefer to explore various
optimizations and intellectually interesting alternatives,
curiosities, and optimizations.  The solution has been structured to
provide a means of gaining deep implementation experience with a
simple, adequate, and powerful core, while leaving room for
improvements to followed from grounded experience, rather than
hypothetical possibilities.

> (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 Known 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].

Yes.  References split.

There is a downref:

"Downref: Normative reference to an Informational draft:
draft-ietf-roll-trickle (ref. 'I-D.ietf-roll-trickle')"

draft-ietf-roll-trickle is currently in Working Group Last Call and considerable
support has been received so far to move that draft-ietf-roll-trickle
to Standard track, which would solve the issue (decision to be taken after WG
Last Call for draft-ietf-roll-trickle based on WG consensus).

> (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?

Yes. The document defines a new IPv6 routing protocol for Low power
and Lossy Networks (LLN) that typically operates with constraints on
(any subset of) processing power, memory and energy (battery),
and their interconnects are characterized by (any subset of) high
loss rates, low data rates and instability.

The IANA section of this document requires a detailed list of new
IANA registries.

> (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.                   


  Low power and Lossy Networks (LLNs) are a class of network in which
  both the routers and their interconnects are constrained: LLN routers
  typically operate with constraints on (any subset of) processing
  power, memory and energy (battery), and their interconnects are
  characterized by (any subset of) high loss rates, low data rates and
  instability.  LLNs are comprised of anything from a few dozen and up
  to thousands of routers, and support point-to-point traffic (between
  devices inside the LLN), point-to-multipoint traffic (from a central
  control point to a subset of devices inside the LLN) and multipoint-
  to-point traffic (from devices inside the LLN towards a central
  control point).  The latter is especially common, as it represents all forms
  for sensor data acquisition and meter reading. 
  The document specifies the IPv6 Routing Protocol
  for LLNs (RPL), which provides a mechanism whereby multipoint-to-
  point traffic from devices inside the LLN towards a central control
  point, as well as point-to-multipoint traffic from the central
  control point to the devices inside the LLN, is supported.  Support
  for point-to-point traffic is also available.

  Introduction

  Low power and Lossy Networks (LLNs) consist of largely of constrained
  nodes (with limited processing power, memory, and sometimes energy
  when they are battery operated or energy scavenging).  These routers
  are interconnected by lossy links, typically supporting only low data
  rates, that are usually unstable with relatively low packet delivery
  rates.  Another characteristic of such networks is that the traffic
  patterns are not simply point-to-point, but in many cases point-to-
  multipoint or multipoint-to-point.  Furthermore such networks may
  potentially comprise up to thousands of nodes.  These characteristics
  offer unique challenges to a routing solution: the IETF ROLL Working
  Group has defined application-specific routing requirements for a Low
  power and Lossy Network (LLN) routing protocol, specified in
  [RFC5867], [RFC5826], [RFC5673], and [RFC5548].

  This document specifies the IPv6 Routing Protocol for Low power and
  lossy networks (RPL).  Note that although RPL was specified according
  to the requirements set forth in the aforementioned requirement
  documents, its use is in no way limited to these applications.

  Design Principles

  RPL was designed with the objective to meet the requirements spelled
  out in [RFC5867], [RFC5826], [RFC5673], and [RFC5548].

  A network may run multiple instances of RPL concurrently.  Each such
  instance may serve different and potentially antagonistic constraints
  or performance criteria.  This document defines how a single instance
  operates.

  In order to be useful in a wide range of LLN application domains, RPL
  separates packet processing and forwarding from the routing
  optimization objective.  Examples of such objectives include
  minimizing energy, minimizing latency, or satisfying constraints.
  This document describes the mode of operation of RPL.  Other
  companion documents specify routing objective functions.  A RPL
  implementation, in support of a particular LLN application, will
  include the necessary objective function(s) as required by the
  application.

  A set of companion documents to this specification will provide
  further guidance in the form of applicability statements specifying a
  set of operating points appropriate to the Building Automation, Home
  Automation, Industrial, and Urban application scenarios.
 
>        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?

Considering that there were a number of discussed items, several decisions
had to be made that required WG consensus. All decisions were driven by
good/excellent consensus. Very few decisions were made with only a rough
consensus (extensions to carry MTU, SLLA options or support of siblings).
That being said, the document has been written so as to allow for future
extensions including the ones listed above, which was seen an acceptable
approach.

>        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?

Good.

During the course of the design of this document, a number of implementations
have been reported (more than 10) and two interoperability events took place
under the control of the IPSO (IP for Smart Object) alliance and the Zigbee
alliance. Interoperability results were shared on the ROLL WG mailing list,
concerns have been addressed and all issues known so far have been fixed.