Document: draft-sjkoh-rmt-bb-tree-config-03.txt
          draft-chiu-rmt-bb-track-03.txt
Review: Joel M. Halpern
Date: 12 februari 2005 

I these documents are not yet ready for publications as informational RFCs.
I find them hard to read.  Sufficiently so that I find myself
wondering about the technical correctness of the material.  I assume
this has been sufficiently reviewed somewhere to know that?  The loop
free condition in tree-config for example, as written is almost
certainly wrong.

There is one major typographic problem making quality review of the
second document impossible.  See the last line of this review.

Both documents have out of date IPR sections and no patent disclosure.

With regard to tree-config:
The document (in section 6.2.4) claims that "the distance can be
approximately determined by the number of aggregation levels on
address has in common with another."  This is, at best, a bad idea.
The number of leading bits in common is not a good comparator.  Given
that this is being used to build a tree that gets one closer to the
source, please remove it.  Many of the other metrics ought to have
caveats about their stability or reliability (delay for example).

Section 7 loop free conditions are confusing.
For example, after stating that levels are up to 127, and then stating
that 128 is used to indicate unconnected, the text states:
   2.  If the requesting node has children, the RH can accept it as
        a child if

       a.  RH's level is 128, i.e., it is the top of a sub-tree not
           yet connected to the sender, or

       b.  RH's level is less than 128, i.e., it is connected to the
           sender.
which, to this reader, seems to translate to "always", as the level
will always either be 128 or less than 128.

Further, to call section 7 a detailed description of the tree building
process is ingenuous.  It simply is not detailed.

I may be misreading things, but it looks like this building block
allows a range of metrics for tree building.  Further, it looks like
unless the beacon / hop count mechanism is used, this could easily and
frequently produce trees which diverge radically from routing.  They
will still be loop free I think.  This is odd since the text makes the
point early on of the importance of being consistent with routing.

The security considerations section ought to indicate what kind of
threats a protocol for this building block would be vulnerable to,
even if the specific mechanisms are deferred to the actual protocol.
If one ignores the introductory text, what follows may be a good
start, particularly since the security mechanisms needed are still,
according to this document, the subject of research.


With regard to track:
The phrasing in section 4 that Track is responsible for the reliable
ordered transmission (and retransmission) of data, but the Data
Channel Protocol is responsible for goodput leaves me confused.
reliable transmisssion is what I understand to be necessary for
goodput.  It appears that both the Data Channel and the Track are
"able" to do retransmission.  Huh?

I think that the description of sender reliability in section 5 has a
typo: "Sender reliable delivery is similar to TCP, where the sender
knows the identity of the senders in a Data Session..."  I suspect
that "senders" is "receivers".  Section 6.1.1 lists three major
entities: "sender, sender, and Repair Head."  Is the second sender a
receiver?
As the text continues to use "sender" for both "sender" and "receiver"
this review terminates.