Re: [dtn-interest] [Fwd: Review of draft-irtf-dtnrg-cbhe] - plus comments deadline

["Burleigh, Scott C (313B)" <[e-mail]>]

Elwyn, I'm starting on some revisions to the CBHE spec today, per Bob Braden's very constructive and helpful review.  I've inserted a couple of remarks in-line.

Scott

> -----Original Message-----
> From: [e-mail] [mailto:dtn-
> [e-mail]] On Behalf Of Elwyn Davies
> Sent: Wednesday, February 03, 2010 11:32 AM
> To: DTN
> Subject: [dtn-interest] [Fwd: Review of draft-irtf-dtnrg-cbhe] - plus
> comments deadline
> 
> Please find attached Bob Braden's review.
> 
> I should have asked for any comments to be sumitted by Monday 15 February.
> 
> Regards,
> Elwyn
> 
-------------------------------------------------------------------------------
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.

>>>>	Right, I'll work on simplifying and harmonizing the language here.

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.

>>>>	I will try to clarify.

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

>>>>	I'll add an explanatory sentence or two here, which I hope will help.

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.

>>>>	A reasonable approach, and it would avoid conflict with RFC5050 so long as CBHE remains strictly a convergence-layer adaptation.  But I think re-purposing the EID offset SDNVs in the bundle primary block is actually a little simpler, and it offers greater compression by eliminating the dictionary altogether.

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

>>>>	We have to be able to reconstruct the bundle as originally transmitted in order to enable operation of the Bundle Authentication Block mechanism, which relies on the re-computed hash at the receiver matching the hash computed by the sender.  The standard BAB-HMAC ciphersuite mandates "strict canonicalization".

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

>>>>	Yes, and the spec attempts to explain how this is ensured.

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

>>>>	This needs to be emphasized in the spec.

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

>>>>	On the other hand, transmission of a stream of CBHE-compressed bundles to a non-CBHE node at Mars that triggers a responding stream of "CBHE Not Understood" messages would still be bad: you've wasted a half hour of transmission opportunity (and delivered no data) either way.  The messages would tell you there's a problem, but I think the more general DTN network management facility that is slowly taking shape would likewise identify this sort of problem by generating diagnostic messages along the lines of "unintelligible bundle discarded" -- or, maybe better yet, aggregated statistics messages that would consume less bandwidth.  I think we're better off omitting a CBHE-specific mechanism.

Two editorial nits and a pet peeve of the reviewer:

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

>>>>	Sorry, I don't understand which paragraph is meant here.  The first paragraph of "Security Considerations"?  

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

>>>>	I agree, and Stephen said as much in his email of 11 November 2009 announcing the new boilerplate.  I think it's required to be in the Abstract, for some reason.

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

>>>>	I'm reworking these.  I believe there is one valid MUST in section 3.2 and one valid MAY (currently "may") in section 3.1, but maybe I misunderstand the rules for these things.