Reliable Multicast Transport Building Block: Tree Auto-Configuration
draft-sjkoh-rmt-bb-tree-config-03

Reviewed by Joel Halpern, Gen-ART:

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.

[Ballot comment]
Note: I have no objection to either sending a DNP until they are cleaned up or sending a "no problem - please clean them up".
Gen-ART review on the documents (critical) is sent to the RFC Editor independently, and also recorded in the comment logs.

[Ballot comment]
Not an end run around any WG in the Security Area, but the document
  claims to be associated with a WG.  The RFC Editor needs to remove
  the text that claim affiliation with the RMT working group.

Put back on agenda to figure out whether we should send a DNP note to RFC Editor because they look too much like RMT documents or a No-problem note and ask the RFC Editor to make sure they don't.

[Note]: 'There is a note of concern from an RMT WG Chair in the ballot comments:  these documents retain all the RMT WG boilerplate.  History:  they were not handled by the WG because the authors stopped work on them (stopped doing any updates, did not appear for over a year), so their work item was dropped by consensus.' added by Allison Mankin

[Ballot comment]
I am very concerned about how close these are to an end run of the WG.

Much of the security considerations section boils down to "just use IPsec" -- and use it with preshared keys, which seems really dubious here.

[Note]: 'There is a note of concern from an RMT WG Chair in the ballot comments:  these documents retain all the RMT WG boilerplate.  History:  they were not handled by the WG because the authors stopped work on them (stopped doing any updates, did not appear for over a year), so their work item was dropped by consensus.' added by Allison Mankin

[Ballot comment]
Email from one of the WG Chairs:

Date:    Thu, 25 Mar 2004 17:00:03 PST
To:      Allison Mankin
cc:      rogerkermode@msn.com
From:    Lorenzo Vicisano
Subject: Re: Time-Sensitive: RFC Editor publishing TRACK bbs


Allison,

My major concern about these publications are that these documents
contains all RMT boiler-plate info and plenty of reference to the
RMT work and documents. All this makes these docs. quite
indistinguishable from the rest of our publications..

In addition to this, I'm suspecting that these are candidates for experimental
status .. which is exactly the status of the WG documents..

This could create a lot of confusion. I'm wondering if this could be a
case similar to the second example in section 5
draft-iesg-rfced-documents-00.txt.

        thanks,
        Lorenzo