[Roll] Part 2: comment resolutions for AD Review of draft-ietf-roll-aodv-rpl-07

[Charlie Perkins <[e-mail]>]

  Hello folks,

Today we have submitted a revised version 8 for our 
draft-ietf-roll-aodv-rpl.  Here are the rest of some resolutions for 
comments made by our AD for the improvement of draft-ietf-roll-aodv-rpl-07.

Regards,
Charlie P.


 > ...
 > 672      Step 3:
 >
 > 674         If the 'H' bit is set to 1, then the router (TargNode or
 > 675         intermediate) MUST build the upward route entry 
accordingly.  The
 > 676         route entry MUST include at least the following items: Source
 > 677         Address, InstanceID, Destination Address, Next Hop, 
Lifetime, and
 > 678         Sequence Number.  The Destination Address and the 
InstanceID can
 > 679         be respectively learned from the DODAGID and the 
RPLInstanceID of
 > 680         the RREQ-DIO, and the Source Address is copied from the ART
 > 681         Option.  The next hop is the preferred parent.  The 
lifetime is
 > 682         set according to DODAG configuration and can be extended 
when the
 > 683         route is actually used.  The sequence number represents the
 > 684         freshness of the route entry, and it is copied from the 
Orig SeqNo
 > 685         field of the RREQ option.  A route entry with same source and
 > 686         destination address, same InstanceID, but stale sequence 
number,
 > 687         SHOULD be deleted.
 >
 > [major] "...MUST build the upward route entry accordingly."  I was 
going to ask what does "accordingly" mean, but the next sentence 
indicates what it has to include.  Instead of having two sentences 
trying to specify the same thing, please collapse them into one.
Done.
 >
 > [minor] This route is to OrigNode, correct?  Please say so.  I know 
that it has been mentioned that the RREQ-Instance is used for that -- 
remind the reader.
Done.
 >
 > [major] "...the Source Address is copied from the ART Option."   What 
is the "Source Address"?  I ask because I assumed that it is the address 
used by the local router to send data to the OrigNode, but the only 
address in the ART Option is the "Target Prefix".  What am I missing?

I used your text as follows:

                   ...the Source Address is the address used by the 
local router to
         send data to the OrigNode
 >
 > [nit] Please be consistent in how names are used.  For example, the 
paragraph above uses both "Next Hop" and "next hop" to refer to the same 
thing.

Fixed.


 >
 > [minor] "The lifetime is set according to DODAG configuration and can 
be extended when the route is actually used."  I think that this is a 
little confusing, because you seem to be talking about route lifetime 
and not the L (which I interpreted as lifetime too) value in the RREQ 
Option, right?  Please be specific.

Fixed.


 >
 > [nit] s/entry with same source/entry with the same source

Fixed.


 >
 > [major] "A route entry with same source and destination address, same 
InstanceID, but stale sequence number, SHOULD be deleted."  When would 
it be ok to not delete the entry?  IOW, why is that not a MUST?

Changed to MUST.


 >
 > 689         If the 'H' bit is set to 0, an intermediate router MUST 
include
 > 690         the address of the interface receiving the RREQ-DIO into the
 > 691         address vector.
 >
 > [major] Step 3 (at least the first paragraph) seems to be about 
building a route entry.  What is different if the H bit is set to 0?  
How is the route entry built?

I think that if H=0 there is no route entry, since source routing is to 
be used.


 >
 > [minor] This last paragraph talks about forwarding the RREQ, so 
perhaps it fits better in the next step.
Done, even though Step 4 now discusses more than just forwarding the RREQ.
 >
 > 693      Step 4:
 >
 > 695         An intermediate router transmits a RREQ-DIO via link-local
 > 696         multicast.  TargNode prepares a RREP-DIO.
 >
 > [minor] "TargNode prepares a RREP-DIO."  Please add a forward 
reference to §6.3.

Done.


 >
 > 698    6.2.2.  Additional Processing for Multiple Targets
 >
 > 700      If the OrigNode tries to reach multiple TargNodes in a 
single RREQ-
 > 701      instance, one of the TargNodes can be an intermediate router 
to the
 > 702      others, therefore it SHOULD continue sending RREQ-DIO to 
reach other
 > 703      targets.  In this case, before rebroadcasting the RREQ-DIO, a
 > 704      TargNode MUST delete the Target Option encapsulating its own 
address,
 > 705      so that downstream routers with higher ranks do not try to 
create a
 > 706      route to this TargetNode.
 >
 > [major] "...one of the TargNodes can be an intermediate router to the 
others, therefore it SHOULD continue sending RREQ-DIO to reach other 
targets."  When would a TargNode choose not to forward the RREQ?  IOW, 
why is that not a MUST?

Changed to MUST.


 >
 > 708      An intermediate router could receive several RREQ-DIOs from 
routers
 > 709      with lower ranks in the same RREQ-instance but have 
different lists
 > 710      of Target Options.  When rebroadcasting the RREQ-DIO, the
 > 711      intersection of these lists SHOULD be included.  For 
example, suppose
 > 712      two RREQ-DIOs are received with the same RPLInstance and 
OrigNode.
 > 713      Suppose further that the first RREQ has (T1, T2) as the 
targets, and
 > 714      the second one has (T2, T4) as targets.  Then only T2 needs 
to be
 > 715      included in the generated RREQ-DIO.  If the intersection is 
empty, it
 > 716      means that all the targets have been reached, and the router 
SHOULD
 > 717      NOT send out any RREQ-DIO.  Any RREQ-DIO message with 
different ART
 > 718      Options coming from a router with higher rank is ignored.
 >
 > [major] "...the intersection of these lists SHOULD be included."  
When would a node not include the intersection?  IOW, why is this not a 
MUST?

Changed to MUST.
 >
 > [major] "If the intersection is empty...the router SHOULD NOT send 
out any RREQ-DIO."  When would it be ok to sent the RREQ out? If there 
are no targets, then it seems like you would never want to.  IOW, why is 
that not a MUST NOT?

Changed to MUST NOT.
 >
 > [minor] I'm not sure about the intersection logic above...but maybe 
I'm missing something.  The example seems to imply that every RREQ 
should include all outstanding targets (?)...so that comparing the first 
one (T1, T2) with the second (T2, T4), implies that T1 has been 
found...is that correct?  If so, then it looks like T4 is still a valid 
target, but the intersection wouldn't include it.  What am I missing?

It is assumed that OrigNode was the eventual origination point for both 
the example incoming RREQs.  So the inference is that one path 
discovered a route for T4, and the other path discovered a route for T1, 
and neither path discovered a route for T2.  And, one might speculate, 
both paths discovered a route for T3 which isn't mentioned in the example.


 >
 > [minor] Related:  The specification above only applies to the period 
of time between receiving the first RREQ and the initial rebroadcast, 
right?  IOW, if a RREQ is received and rebroadcast....and then a second 
RREQ is received (with a different list of targets), then the 
rebroadcast should not include just the intersection, right?

That is correct.  The following text was added to clarify this point:

                                                           For the
         purposes of determining the intersection with previous incoming
         RREQ-DIOs, the intermediate router maintains a record of the
         targets that have been requested associated with the RREQ-Instance.


 >
 > 720    6.3.  Generating Route Reply (RREP) at TargNode
 >
 > 722    6.3.1.  RREP-DIO for Symmetric route
 >
 > 724      If a RREQ-DIO arrives at TargNode with the 'S' bit set to 1, 
there is
 > 725      a symmetric route along which both directions can fulfill the
 > 726      requirements.  Other RREQ-DIOs might later provide 
asymmetric upward
 > 727      routes (i.e.  S=0).  Selection between a qualified symmetric 
route
 > 728      and an asymmetric route that might have better performance is
 > 729      implementation-specific and out of scope.  If the 
implementation uses
 > 730      the symmetric route, the TargNode MAY delay transmitting the 
RREP-DIO
 > 731      for duration RREP_WAIT_TIME to await a better symmetric route.
 >
 > [major] RREP_WAIT_TIME is not defined anywhere.

By default it is set to equal 1/4 of the value determined by the L bit.


 >
 > [major] "...a better symmetric route."  What makes a route better?

I changed the sentence to say lower Rank.
 >
 > 733      For a symmetric route, the RREP-DIO message is unicast to 
the next
 > 734      hop according to the accumulated address vector (H=0) or the 
route
 > 735      entry (H=1).  Thus the DODAG in RREP-Instance does not need 
to be
 > 736      built.  The RPLInstanceID in the RREP-Instance is paired as 
defined
 > 737      in Section 6.3.3.  In case the 'H' bit is set to 0, the address
 > 738      vector received in the RREQ-DIO MUST be included in the 
RREP-DIO.
 > 739      TargNode increments its current sequence number and uses the
 > 740      incremented result in the Dest SeqNo in the ART option of 
the RREQ-
 > 741      DIO.  The address of the OrigNode MUST be encapsulated in 
the ART
 > 742      Option and included in this RREP-DIO message.
 >
 > 744    6.3.2.  RREP-DIO for Asymmetric Route
 >
 > 746      When a RREQ-DIO arrives at a TargNode with the 'S' bit set 
to 0, the
 > 747      TargNode MUST build a DODAG in the RREP-Instance rooted at 
itself in
 > 748      order to discover the downstream route from the OrigNode to the
 > 749      TargNode.  The RREP-DIO message MUST be re-transmitted via 
link-local
 > 750      multicast until the OrigNode is reached or MaxRank is exceeded.
 >
 > [minor] The previous section talked about delaying the RREP. Should 
that be considered here too?

A similar delay specification has been added.


 >
 > 752      The settings of the fields in RREP option and ART option are 
the same
 > 753      as for the symmetric route, except for the 'S' bit.
 >
 > 755    6.3.3.  RPLInstanceID Pairing
 >
 > [minor] Pairing only applied to symmetric routes, right? Please say so.

I think it is O.K. to mandate pairing for asymmetric routes.


 >
 > 757      Since the RPLInstanceID is assigned locally (i.e., there is no
 > 758      coordination between routers in the assignment of 
RPLInstanceID), the
 > 759      tuple (OrigNode, TargNode, RPLInstanceID) is needed to uniquely
 > 760      identify a discovered route.  The upper layer applications 
may have
 > 761      different requirements and they can initiate the route 
discoveries
 > 762      simultaneously.  Thus between the same pair of OrigNode and 
TargNode,
 > 763      there can be multiple AODV-RPL instances.  To avoid any 
mismatch, the
 > 764      RREQ-Instance and the RREP-Instance in the same route 
discovery MUST
 > 765      be paired somehow, e.g. using the RPLInstanceID.
 >
 > [minor] "The upper layer applications may have different requirements 
and they can initiate the route discoveries simultaneously."  The 
applications don't initiate route discovery...  Application requirements 
are mentioned several times in this document, but it is not clear to me 
how those requirements are reflected in the RREQ.

Fixed.


 >
 > [major] "..MUST be paired somehow, e.g. using the RPLInstanceID."  
There is no clear Normative action here. s/MUST/must

I think that the reformulated sentence uses MUST appropriately.


 >
 >
 > ...
 > 782    6.4.  Receiving and Forwarding Route Reply
 >
 > [-] Some of the comments above apply to this section too.

I hope they have been addressed but if not please advise.


 >
 >
 > ...
 > 803         If the constraints are not fulfilled, the router MUST NOT 
join the
 > 804         DODAG; the router MUST discard the RREQ-DIO, and does not 
execute
 > 805         the remaining steps in this section.
 >
 > [nit] s/and does not execute/and not execute

Fixed.


 >
 >
 > ...
 > 813      Step 3:
 >
 > 815         If the 'H' bit is set to 1, then the router (OrigNode or
 > 816         intermediate) MUST build a downward route entry. The 
route entry
 > 817         SHOULD include at least the following items: OrigNode 
Address,
 > 818         InstanceID, TargNode Address as destination, Next Hop, 
Lifetime
 > 819         and Sequence Number.  For a symmetric route, the next hop 
in the
 > 820         route entry is the router from which the RREP-DIO is 
received.
 > 821         For an asymmetric route, the next hop is the preferred 
parent in
 > 822         the DODAG of RREQ-Instance.  The InstanceID in the route 
entry
 > 823         MUST be the original RPLInstanceID (after subtracting the 
Shift
 > 824         field value).  The source address is learned from the ART 
Option,
 > 825         and the destination address is learned from the DODAGID.  The
 > 826         lifetime is set according to DODAG configuration and can be
 > 827         extended when the route is actually used.  The sequence 
number
 > 828         represents the freshness of the route entry, and is 
copied from
 > 829         the Dest SeqNo field of the ART option of the RREP-DIO.  
A route
 > 830         entry with same source and destination address, same 
InstanceID,
 > 831         but stale sequence number, SHOULD be deleted.
 >
 > [major] The description in §6.2.1 says that the "route entry MUST 
include...".  Why is SHOULD used in this case?  When is it ok to not 
include these items?  Should the same apply to §6.2.1?

Changed to MUST here also.


 >
 >
 > ...
 > 851    7.  Gratuitous RREP
 >
 > [minor] This section introduces T and O (instead of 
TargNode/OrigNode) to explain the operation.  That is not a bad thing, 
but I think that having consistent terminology is a really good thing.

Changed to TargNode / OrigNode.


 >
 >
 > ...
 > 872      In case of hop-by-hop routing, R MUST unicast the received 
RREQ-DIO
 > 873      hop-by-hop to T.  The routers along the route SHOULD build 
new route
 > 874      entries with the related RPLInstanceID and DODAGID in the 
downward
 > 875      direction.  Then T MUST unicast the RREP-DIO hop-by-hop to 
R, and the
 > 876      routers along the route SHOULD build new route entries in 
the upward
 > 877      direction.  Upon receiving the unicast RREP-DIO, R sends the
 > 878      gratuitous RREP-DIO to the OrigNode as defined in Section 6.3.
 >
 > [major] I don't understand how the "routers along the route" can do 
anything if the messages are unicast...??

The intention is for the routers along the way to be part of the new 
RPLInstance and DODAG.  They don't have to change the next hop information.


 >
 > 880    8.  Operation of Trickle Timer
 >
 > 882      The trickle timer operation to control 
RREQ-Instance/RREP-Instance
 > 883      multicast is similar to that in P2P-RPL [RFC6997].
 >
 > [major] "The trickle timer operation...is similar to that in P2P-RPL 
[RFC6997]."  Similar, or the same??
 >
 > Note that if it is the same, then rfc6997 would have to be a 
Normative Reference.

TODO: rewrite section 8.


 >
 > 885    9.  IANA Considerations
 >
 > 887    9.1.  New Mode of Operation: AODV-RPL
 >
 > 889      IANA is required to assign a new Mode of Operation, named 
"AODV-RPL"
 > 890      for Point-to-Point(P2P) hop-by-hop routing under the RPL 
registry.
 > 891      The value of TBD1 is assigned from the "Mode of Operation" space
 > 892      [RFC6550].
 >
 > [major] NEW>
 >    IANA is asked to assign a new Mode of Operation, named "AODV-RPL"
 >    for Point-to-Point(P2P) hop-by-hop routing from the "Mode of 
Operation"
 >    Registry [RFC6550].
 >
Done.


 >
 > 894 +-------------+---------------+---------------+
 > 895                 |    Value    |  Description  | Reference   |
 > 896 +-------------+---------------+---------------+
 > 897                 |   TBD1 (5)  |   AODV-RPL    | This document |
 > 898 +-------------+---------------+---------------+
 >
 > 900                           Figure 6: Mode of Operation
 >
 > 902    9.2.  AODV-RPL Options: RREQ, RREP, and Target
 >
 > 904      Three entries are required for new AODV-RPL options "RREQ", 
"RREP"
 > 905      and "ART" with values of TBD2 (0x0A), TBD3 (0x0B) and TBD4 
(0x0C)
 > 906      from the "RPL Control Message Options" space [RFC6550].
 >
 > [major] NEW>
 >    IANA is asked to assign three new AODV-RPL options "RREQ", "RREP" and
 >    "ART", as described in Figure 7 from the "RPL Control Message Options"
 >    Registry [RFC6550].
 >
 > 908 +-------------+------------------------+---------------+
 > 909             |    Value    |        Meaning         | Reference   |
 > 910 +-------------+------------------------+---------------+
 > 911             | TBD2 (0x0A) |      RREQ Option       | This document |
 > 912 +-------------+------------------------+---------------+
 > 913             | TBD3 (0x0B) |      RREP Option       | This document |
 > 914 +-------------+------------------------+---------------+
 > 915             | TBD3 (0x0C) |       ART Option       | This document |
 > 916 +-------------+------------------------+---------------+
 >
 > 918                           Figure 7: AODV-RPL Options
 >
 > 920    10.  Security Considerations
 >
 > 922      The security mechanisms defined in section 10 of [RFC6550] and
 > 923      section 11 of [RFC6997] can also be applied to the control 
messages
 > 924      defined in this specification.  The RREQ-DIO and RREP-DIO 
both have a
 > 925      secure variant, which provide integrity and replay 
protection as well
 > 926      as optional confidentiality and delay protection.
 >
 > [major] rfc6997/§11 mostly talks about the processing of the new 
messages defined there.  How does that apply to this document?
 >
 > [major] rfc6997 says that section "10 of [RFC6550] describe RPL's 
security framework...This security framework can also be used in P2P-RPL 
after taking into account the constraints specified in Section 11."  How 
does that apply to this document if both "section 10 of [RFC6550] and 
section 11 of [RFC6997]" are mentioned above?
TODO: Instead of citing RFC 6997, we need to adapt the text to be 
specific for AODV-RPL messages.
 >
 > [minor] §3 talks about the fact that an RREQ-DIO is a DIO message 
with the rREQ Option (and there's similar text for the RREP-DIO).  
However, I think it's confusing to the reader to mention that there are 
secure variants.  I think that expanding the description (at the end of 
§3) of what exactly the *-DIO messages are (and that the definition 
includes the secure variants) would go a long way.

Is it O.K. if we note that RREQ and RREP have secure variants, without 
having to reproduce the entire section?


 >
 > 928      AODV-RPL can operate in the three security modes defined in
 > 929      [RFC6550].  AODV-RPL messages SHOULD use a security mode at 
least as
 > 930      strong as the security mode used in RPL.
 >
 > [major] "AODV-RPL messages SHOULD use a security mode at least as 
strong as the security mode used in RPL."  What does that mean? As I 
asked before, what is the relationship in the network between RPL and 
AODV-RPL.  I have been assuming that the Options are simply included as 
an "add-on" to the base RPL already running, but this statement seems to 
imply that they are completely independent if they can have different 
security modes.   ??

AODV-RPL does not require RPL to be running.  All routes could be 
point-to-point.  I think they can be completely independent but still 
use the same route table.  As you note, this will require some 
bookkeeping to make sure that route entries discovered by secure 
messaging are distinguishable from route entries discovered by unsecured 
messaging.


 >
 > 932      o  Unsecured.  In this mode, RREQ-DIO and RREP-DIO are used 
without
 > 933         any security fields as defined in section 6.1 of 
[RFC6550].  The
 > 934         control messages can be protected by other security 
mechanisms,
 > 935         e.g. link-layer security.  This mode SHOULD NOT be used 
when RPL
 > 936         is using Preinstalled mode or Authenticated mode (see below).
 >
 > [major] There is a Normative contradiction: (above) "This mode SHOULD 
NOT be used when RPL is using Preinstalled mode or Authenticated mode 
(see below)." ...and... (below) "Unsecured messages MUST be dropped."  
It seems to me that maybe s/SHOULD NOT/MUST NOT
Agreed.
 >
 > [major] Related:  There's no indication on what should be done with 
unsecured messages in Authenticated mode.  I'm assuming the same drop 
action.
 >
 > 938      o  Preinstalled.  In this mode, AODV-RPL uses secure 
RREQ-DIO and
 > 939         RREP-DIO messages, and a node wishing to join a secured 
network
 > 940         will have been pre-configured with a shared key.  A node 
can use
 > 941         that key to join the AODV-RPL DODAG as a host or a router.
 > 942         Unsecured messages MUST be dropped.  This mode SHOULD NOT 
be used
 > 943         when RPL is using Authenticated mode.
 >
 > [major] When is it ok to use this mode with Authenticated mode?  IOW, 
why is that not a MUST NOT?

Changed to MUST NOT.


 >
 > ...
 > 961    11.  Future Work
 >
 > [minor] This section sounds appropriate for an Experimental document 
and not one in the Standards Track.
 >
 > [major] I would expect some of the items below to be specified in a 
Standards Track document.  For instance, "the initial state of a link" 
seems pretty basic. Put another way, what should be the settings (for 
the items mentioned here)?
 >
 > 963      There has been some discussion about how to determine the 
initial
 > 964      state of a link after an AODV-RPL-based network has begun 
operation.
 > 965      The current draft operates as if the links are symmetric until
 > 966      additional metric information is collected.  The means for 
making
 > 967      link metric information is considered out of scope for 
AODV-RPL.  In
 > 968      the future, RREQ and RREP messages could be equipped with 
new fields
 > 969      for use in verifying link metrics.  In particular, it is 
possible to
 > 970      identify unidirectional links; an RREQ received across a
 > 971      unidirectional link has to be dropped, since the destination 
node
 > 972      cannot make use of the received DODAG to route packets back 
to the
 > 973      source node that originated the route discovery operation.  
This is
 > 974      roughly the same as considering a unidirectional link to 
present an
 > 975      infinite cost metric that automatically disqualifies it for 
use in
 > 976      the reverse direction.
 >
 > [major] "The current draft operates as if the links are symmetric 
until additional metric information is collected."  §6 mandates a check 
to determine the state symmetry.  How is that (unspecified) check 
related to this text?  It seems to be that it is the same thing; is it?

In AODVv2, and to a certain extent in AODV, there is text that goes into 
some detail about how to determine link symmetry.  That could be adapted 
for incorporation into AODV-RPL.  Alternatively, and perhaps preferable, 
we could specify that link symmetry may be determined by procedures that 
are out of scope for the AODV-RPL specification.  Would that be O.K.

We could also change the AODV-RPL document to specify that whether or 
not a link is symmetric is not assumed to be symmetric by default.  That 
would be O.K. with me if the determination of link symmetry is out of 
scope.  For instance, some links could do this at layer 2.


 >
 > 978    12.  Contributors
 >
 > [minor] In general Contributors are listed list before the Author's 
Address at the bottom [rfc7322].

Fixed.


 >
 >
 > ...
 > 1060    Appendix A.  Example: ETX/RSSI Values to select S bit
 >
 > [minor] Please expand ETX/RSSI on first mention (§5).
Done.
 >
 > 1062      We have tested the combination of "RSSI(downstream)" and "ETX
 > 1063      (upstream)" to determine whether the link is symmetric or 
asymmetric
 > 1064      at the intermediate nodes.  The example of how the ETX and RSSI
 > 1065      values are used in conjuction is explained below:
 >
 > [style nit] Don't write in the first person ("We have...").

Fixed.


 >
 > [minor] It would be really nice to provide a reference for these tests.
TODO: provide a citation.
 >
 > [minor] Add references for ETX/RSSI.
TODO: provide a citation.
 >
 > [nit] s/conjuction/conjunction
Fixed.
 >
 >
 > ...
 > 1083      We tested the operations in this specification by making the
 > 1084      following experiment, using the above parameters.  In our 
experiment,
 > 1085      a communication link is considered as symmetric if the ETX 
value of
 > 1086      NodeA->NodeB and NodeB->NodeA (See Figure.8) are, say, 
within 1:3
 > 1087      ratio.  This ratio should be taken as a notional metric for 
deciding
 > 1088      link symmetric/asymmetric nature, and precise definition of 
the ratio
 > 1089      is beyond the scope of the draft.  In general, NodeA can 
only know
 > 1090      the ETX value in the direction of NodeA -> NodeB but it has 
no direct
 > 1091      way of knowing the value of ETX from NodeB->NodeA.  Using 
physical
 > 1092      testbed experiments and realistic wireless channel propagation
 > 1093      models, one can determine a relationship between RSSI and ETX
 > 1094      representable as an expression or a mapping table. Such a
 > 1095      relationship in turn can be used to estimate ETX value at 
nodeA for
 > 1096      link NodeB--->NodeA from the received RSSI from NodeB.  
Whenever
 > 1097      nodeA determines that the link towards the nodeB is 
bi-directional
 > 1098      asymmetric then the "S" bit is set to "S=0".  Later on, the 
link from
 > 1099      NodeA to Destination is asymmetric with "S" bit remains to "0".
 >
 > [nit] s/Figure.8/Figure 8
 >
 > [nit] s/within 1:3 ratio/within 1:3 a ratio
 >
 > [nit] s/, and precise definition of the ratio is beyond the scope of 
the draft./.    Not needed, this is just an example.

Fixed, fixed, and fixed.


 >
 > 1101    Appendix B.  Changelog
 >
 > [nit] Add a note to the RFC Editor to remove this section before 
publication.
 >
Done.

Also added a new section about Changes between revisions ...-07 and ...-08.