[dtn-interest] [Fwd: Review of draft-irtf-dtnrg-cbhe]

[Elwyn Davies <[e-mail]>]

Please find attached Bob Braden's review.

Regards,
Elwyn

--- Begin Message ---

This document is generally well written, although its consistency and 
clarity might be improved (see below). It is the product of a well 
respected expert in the DTN/IPN area.  It illustrates the fact, which 
practitioners of the protocol design art re-learn over and over, that 
writing a precise and clear description of even a simple protocol is 
actually VERY hard.

The terminology is slightly confusing.  The Introduction implicitly 
distinguishes between EID *expression* and EID *representation*, but 
these terms do not occur later.  The term "[EID] reference string" is 
also used without definition.

The relationships among scheme, namespace, scheme-specific part, and 
namespace-specific string are unclear in the document. (The reviewer can 
guess, but that's not the point, is it?) This is related to the first 
sentence on p6, which claims that that "dtn::ipn:9.37" is 
CBHE-conformant. I don't believe a naive reader can verify that, based 
on the preceding material in this document -- at least this reader could 
not.

Then comes: "... the conversion ... [into] two integers is therefore 
straightforward".  Huh? A bit more e

This is not supposed to be a "deep technical review", but the reviewer 
wants to note that the scheme seems awfully constrained. EG The reviewer 
wonders:
(1) Why not do the compression in the dictionary, not in the "primary 
block" (whatever that is)?  This change would only require some 
convention in the dictionary to distinguish a string from a compressed 
string.

(2) Apparently, the BP does not require a specific ordering of 
dictionary entries, but CBHE imposes an ordering in order to be able to 
decompress identically. That seems unnecessary; if two bundles with 
dictionaries in different order are congruent, why do you care which 
order comes out of decompression?

You say that the null ID compression must always be invertible.  But 
isn't that true for ALL compressions under CBHE?

A constraint that is not made clear: each DTN hop must know whether or 
not each next hop understands CBHE (OTOH, a receiver can test for CBHE 
encoding by the presence or absence of a null dictionary).  Furthermore, 
if a CBHE-compressed bundle is sent to a non-CBHE node, the bundle is 
apparently black-holed. That seems like a bad idea, even at Mars 
distances. By analogy with IP, it would seem better to send back a "CBHE 
Not Understood" control message (although may relate to a larger context 
with which the reviewer is unfamiliar).

Two editorial nits and a pet peeve of the reviewer:

The explanation in the first paragraph of page 9 seems gratuitous in 
this document.

The third paragraph of the Abstract might better be in the Introduction 
section.

The requirements word MUST is used exactly twice, and both uses seem 
inappropriate. Can you imagine a MAY or SHOULD in these places?
Both MUST occurrences and the reference to RFC 2119 should be removed: 
s/MUST/must/.

Cheers,

Bob Braden

--- End Message ---