[dtn-interest] [Fwd: Review of draft-irtf-dtnrg-cbhe] - plus comments deadline
Elwyn Davies <elwynd@folly.org.uk> Wed, 03 February 2010 19:32 UTC
Received: from b.painless.aaisp.net.uk (b.painless.aaisp.net.uk [81.187.30.52]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id o13JWbF0029333 for <dtn-interest@mailman.dtnrg.org>; Wed, 3 Feb 2010 11:32:37 -0800
Received: from 153.107.2.81.in-addr.arpa ([81.2.107.153] helo=[81.187.254.251]) by b.painless.aaisp.net.uk with esmtp (Exim 4.69) (envelope-from <elwynd@folly.org.uk>) id 1Nckxr-0000YR-VT for dtn-interest@mailman.dtnrg.org; Wed, 03 Feb 2010 19:32:40 +0000
Message-ID: <4B69CF48.2000806@folly.org.uk>
Date: Wed, 03 Feb 2010 19:32:24 +0000
From: Elwyn Davies <elwynd@folly.org.uk>
User-Agent: Thunderbird 2.0.0.19 (X11/20081209)
MIME-Version: 1.0
To: DTN <dtn-interest@mailman.dtnrg.org>
Content-Type: multipart/mixed; boundary="------------080908090408010109070003"
Subject: [dtn-interest] [Fwd: Review of draft-irtf-dtnrg-cbhe] - plus comments deadline
X-BeenThere: dtn-interest@maillists.intel-research.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Delay Tolerant Networking Interest List <dtn-interest.maillists.intel-research.net>
List-Unsubscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-interest>, <mailto:dtn-interest-request@maillists.intel-research.net?subject=unsubscribe>
List-Archive: <http://maillists.intel-research.net/pipermail/dtn-interest>
List-Post: <mailto:dtn-interest@maillists.intel-research.net>
List-Help: <mailto:dtn-interest-request@maillists.intel-research.net?subject=help>
List-Subscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-interest>, <mailto:dtn-interest-request@maillists.intel-research.net?subject=subscribe>
X-List-Received-Date: Wed, 03 Feb 2010 19:32:38 -0000
Please find attached Bob Braden's review. I should have asked for any comments to be sumitted by Monday 15 February. 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 ---
- [dtn-interest] [Fwd: Review of draft-irtf-dtnrg-c… Elwyn Davies
- Re: [dtn-interest] [Fwd: Review of draft-irtf-dtn… Burleigh, Scott C (313B)