Re: [dtn] working group last call on draft-ietf-dtn-bpbis

Fred, some responses in-line below.

Scott

-----Original Message-----
From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of Templin, Fred L
Sent: Friday, January 20, 2017 2:27 PM
To: dtn <dtn@ietf.org>
Subject: Re: [dtn] working group last call on draft-ietf-dtn-bpbis

Hi, here are my review comments for draft-ietf-dtn-bpbis:

Fred Templin
fred.l.templin@boeing.com

---

1) Abstract, instead of "This Internet Draft", say: "This document" so that the text can carry
     forward into RFC publication.

Sure.

2) Page 4, figure 1 is split between two pages. Make it fit onto a single page.

Sure.

3) Page 4, figure 1, "Trans1" and "Trans3" are unexplained. Are they the same as "T1/T3"?
     Why not just call them "T1" and "T3"?

Yep, fine with me.

4) Page 6, "Partial payload" is it the case that payload fragmentation is limited to 2-fragment
     fragmentation, or can it be N-fragment? The definition makes it appear that only 2-fragment
    fragmentation is supported.

Bundles can be split up into an unlimited number of fragments, but the way to do that is to split a single bundle into two fragments, each of which is a full-fledged bundle - and since each fragment is a bundle it can then be split into two fragments, each of which is a bundle, and so on.  The rules for dividing one bundle into two fragments can be described exactly, in a fairly concise way.  The rules for dividing a single bundle directly into N bundles would be much more complicated, harder to grasp, and easier to get wrong, and they are really not necessary.  (The development of multicellular organisms is sort of a model here.)  But certainly I can add a sentence somewhere to the effect that fragments are bundles and are therefore amenable to further fragmentation, such that the net result is fragmentation of a single bundle into N fragments, N>= 2.

5) Page 6, figure 2 is split between two pages. Make it fit onto a single page.

Sure.

6) Section 3.2, page 14, the sentence: "However, in some environments there may be
    segments of the end-to-end path for which no reliable convergence-layer protocol
    is available; in such environments the use of reliable convergence-layer protocols
    wherever possible can reduce the incidence of data loss." - this seems to be saying
    two contradictory things. It basically seems says: "when no reliable convergence-layer
    protocol is available, use a reliable convergence-layer protocol" which is an
    oxymoron - perhaps a misunderstanding?

The writing here is bad.  The idea is that even though some segments of the end-to-end path can't be served by reliable CL protocols, you're still better off overall if you use reliable CL protocols on those segments that can be.  I will fiddle with this text to make it clearer.

7) Section 4.1.5.1, page 18, should there be an informative reference for "dtn:" and "ipn:"?

All we are doing in this section is saying what to do with various string values.  There happen to be some documents that discuss the schemes identified by those strings, and we could insert some informative references to those documents if they would be helpful to the reader.

8) Section 4.2.2, page 22, "Total Application Data Unit Length" only appears if the bundle is
    a fragment. But, does it mean that only "two-fragment" fragmented bundles are possible?

No, it doesn't mean that (see above).

9) Section 4.3.4, page 25, why does it need to include both a hop limit and hop count? Isn't
    it sufficient to just have a hop limit that decrements to 0?

A fair point, but having both fields actually does provide additional information - if you only decrement hop limit to zero you have no idea what value it started out with, which might be important for some routers.  That said, I'm fine either way.

10) Section 5.8, page 32, why is only "2-fragment" fragmentation supported? Why not
    "N-fragment"?

As discussed above, a bundle can be divided into any number of fragments.

11) Section 6.1.2, figure 6, page 42, change: "No known route destination from here."
    to: "No known route to destination from here."

Yes.

_______________________________________________
dtn mailing list
dtn@ietf.org
https://www.ietf.org/mailman/listinfo/dtn