Subject: [dtn] RFC5050bis Support

From: Rick Taylor <[email-masked]>
Date: Tue, 17 Oct 2017 15:43:20 +0000

Hi All,

Thank you everyone for showing your support for 5050bis, it's good to
hear from all of those who are keen to see the work succeed.

However I don't believe there was ever a question of lack of support
for the work, my personal concern was with the lack of on-list peer
review of the 3 work-items: BPbis, TCP-CL, and BPSec.

Of the three, BPbis has received solid reviews (thank you Lucas and
others).  I believe BPSec has had significant offline review by
cryptography experts, but I have noticed little recent on-list
discussion.  TCP-CL has had some comments, but my gut feeling is that
it is not quite polished/peer-reviewed enough to make it through the
IETF post-WG review stages without significant delay.

As a recap: The intention of the working group is for all three
documents to be eventually released as a set: The 'packet' format
(5050bis), a general-purpose interoperable transmission format (TCP-
CL), and a method for security (BPbis).

Please can I request that all of you find a few minutes in your
undoubtedly busy days to have another quick read of all three drafts,
and post a quick summary of any typos, inconsistencies, areas of
potential confusion, and/or any passing comments on readability and
style that you might find to the list before IETF-100?  Please don't
hold back opinion because you feel that you might look foolish, or
upset the 'DTN wizards' - I've met a lot of them, and they're human
really!

I look forward to seeing as many of you as can make it to Singapore.

Many thanks,

Rick Taylor

---

From: "Juan A. Fraire" <[email-masked]>
Date: Tue, 17 Oct 2017 18:31:05 +0200

Dear All,

I'm Juan Fraire, and I've been conducting some research on DTN with the
final goal of implementing DTN solutions in future Argentina Space Agency
(CONAE) LEO satellite constellations. I'm obviously in favor of having a
standardized and interoperable protocol to address my networks.

Although I've been involved in more abstract space-DTN concepts such as
routing and planning, I've gone through the draft-ietf-dtn-bpbis-08.txt
posted on August 8, 2017 and came up with the following questions and
comments. Most of them are cosmetic, except those highlighted in bold which
are rather conceptual.

   - *Section 1*
   - *Sec. 1, Par. 5:* DTN acronym is first used but never defined. It
      should be defined the first time Delay-Tolerant Networking is
named in Sec.
      1, 1st paragraph.
      - *Sec. 1, Par. 7:* We say BP always sits on top of a CLA. *Is there
      any scenario where we can think of BP without any underlying layer
      adaptation? BIB encapsulation is later described as a possible CLA, but
      readers might question about over-the-metal BP for example. If this is
      possible it should be stated, if not, then it should also be stated.*
      - *Sec. 1, Par. 9:* "This document describes the format of the
      protocol data...", well, it actually describes a few more things than
      format such as processing procedures, extension blocks, etc. Phrase needs
      to be updated.
   - *Section 3*
   - *Fig. 2:* Figure 2 is split in two pages, it is very difficult to
      understand like this.
      - *Sec. 3.1, Delivery definition:* What does "subject to a
      registration" exactly means? If it means a node already registered to the
      destination endpoint ID (EID) then it might clearer to state
that in those
      words.
      - *Sec. 3.2, par. 14:* "The source of every bundle is a node,
      identified by ... some singleton endpoint". This directly implies that
      being member of a singleton EID is mandatory in order to
transmit a bundle.
      This is not a minor statement that is later clarified in Sec.
4.1.5.2, but
      might worth to restate it clearly at this point. Also, in
Section 4.1.4 it
      is stated that the null (anonymous) EID can be used as source EID, if so,
      this should also be stated in this paragraph.
      - *Sec. 3.2, par. 15:* "... invokes the services of one or more
      CLAs", *in which cases more than one CLA can be invoked to transmit a
      single bundle? Does this suggest some kind of load balancing
feature in BP?
      If yes it can be clarified, if not, at least provide examples on how
      several CLAs can be used concurrently. This leaves a lot of
questions open
      for the inexperienced reader and potential implementation of a BP stack.*
      - *Sec. 3.2, par. 17:* "The bundle protocol does not natively ensure
      delivery of a bundle...", In general, this paragraph sounds unnecessarily
      strong and negative. I would add a sentence like "Although
bundle delivery
      is not natively supported, BP provides the user application the means to
      detect and recover from errors (i.e., user app acks, CRC, etc.)".
   - *Section 4*
   - *Sec. 4, par. 2:* This paragraph seems overly complicated to explain a
      simple bundle structure formed by 1) a mandatory primary block,
2) several
      and optional canonical blocks, 3) a mandatory and single payload block. I
      think a simple figure might be well suited to easily illustrate
the idea (I
      can contribute with one).
      - *Sec. 4.1.4, par. 2:* "The bundle’s destination endpoint is a
      singleton" processing control flag. *Why does the transmitter needs
      to know if the destination EID is a singleton or not? Even if true on
      transmission time, how about if this condition changes during the transit
      of the bundle? This kind of breaks the late binding assumption.*
      - *Sec. 4.1.5.1 <http://4.1.5.1>:* "dtn:none identifies the null
      endpoint". Does this mean that supporting the full dtn: schema (i.e.,
      string parsing in the SSP) is mandatory for any BP implementation? Maybe
      the only mandatory feature is to be able to parse the “zero” value in the
      SSP for the null EID only. Maybe none of them is mandatory. This must be
      clarified in the document.
      - *Sec. 4.1.5.2.:* "Every node MUST be a member of at least one
      singleton endpoint". *I'm still struggling to fit this Node ID "must"
      condition in my head. Why can't I have a very limited bundle node which
      only transmit as anonymous? Why can't I have a simple bundle
node which is
      only member of a many-node EID that only receives bundles? This is some
      typical sensor/actuator network scenarios with unidirectional links which
      are assumed to be natively supported by BP. In general, I was left with
      feeling that unidirectional links are just a "marketing"
assumption for BP
      and that are not seriously considered in this draft (for example all the
      status report idea is strongly based in bidirectional communications).*
      - *Sec. 4.1.6:* "DTN time is an unsigned integer". It might be useful
      for the inexperienced reader to know the possible range of DTN time based
      on the max size of the CBOR unsigned int range.
      - *Sec. 4.3, par. 2:* "(Note that, while CBOR..." This note does not
      seem to correspond to this section but a more general section describing
      the adoption of CBOR (Sec. 4.2?).
      - *Sec. 4.3:* Wouldn’t it be a good idea to include an extension
      block to define basic traffic flow-types/QoS/bundle-labeling (Flow label
      block is only mentioned but not defined) in this document? This is
      something that will be likely included in most BP implementations. I cant
      imagine a BP implementation that would not want to put some type of
      messages (configuration, telemetry, etc.) ahead in the transmission queue.
   - *Section 5*
   - *Sec. 5.4:* Figure 4 is named, but never found in this section. Also,
      there is no Figure 3 in the document. Figures numbering needs to be fixed.
      - Section 7
   - *Sec. 7:* CLAs are not requested to report which portion of a bundle
      was forwarded, thus, making reactive fragmentation an optional feature,
      which is ok. But I'm wondering if given the current CBOR formatting which
      requires a special end character does even allow to consider reactive
      fragmentation as before with SDNV encoding. Since I did not seem to find
      any reference to reactive fragmentation in the document I assume this is
      out of the table right now, is this right? This can also be clarified in
      the document.

Hope it helps,

Juan

On Tue, Oct 17, 2017 at 5:43 PM, Rick Taylor <[email-masked]
> wrote:

> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn
>

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 18 Oct 2017 00:06:19 +0000 (UTC)

> for the work, 

You believe wrongly.
https://www.ietf.org/mail-archive/web/dtn-interest/current/msg05237.html

Lloyd Wood
http://sat-net.com/L.Wood/dtn

________________________________
From: Rick Taylor <[email-masked]>
To: "[email-masked]" <[email-masked]> 
Sent: Wednesday, 18 October 2017, 2:43
Subject: [dtn] RFC5050bis Support

Hi All,

really!

Many thanks,

Rick Taylor

---

From: Lucas Kahlert <[email-masked]>
Date: Wed, 18 Oct 2017 16:40:46 +0200

Hello,

I have one more point for Step 1 of section 5.4.2 Forwarding Failed:

In its current form there is a potential loop 
(https://mailarchive.ietf.org/arch/msg/dtn/ne7OckZ2LbYZHTvC3HPYNGcWBBE). 
The suggested fix by Mr Burleigh was inserting the following text to 
Step 1 of section 5.4.2: "This forwarding SHALL be accomplished by 
performing Step 4 and Step 5 of section 5.4.". This solves the loop issue.

I thought I found another problem in the proposed solution. Mr. 
Burleighs explanation dispelled my concerns about that 
(https://mailarchive.ietf.org/arch/msg/dtn/giKzq47J0JTL0AplVdp-Rg8oLlw). 
But I think the proposed solution should be extended to address that no 
routing decision is required. I found it very hard to derive this from 
the proposed language.

Regards,
Lucas

---

From: 鈴木 清久 <[email-masked]>
Date: Thu, 19 Oct 2017 04:19:31 +0000

Dear IETF DTN WG,

Mainly I have been studying DTNs for application of various space activities since 2007. I think DTN is an important for enhancing telecommunication under disruptive circumstances such as loss of sight, small link budget, and attenuation for atmosphere….
I also think that standardization of 5050bis (for internet RFC) is an important first step of DTN.

Just quick comments for 5050bis as follows,

*General
I think separation of CT from 5050 is good idea to simplify.

*Hop count
Section 4.3.3 said " When a bundle's hop count exceeds its hop limit, the bundle SHOULD be deleted for the reason "hop limit exceeded", following the bundle deletion procedure defined in Section 5.10.". Bundles are still alive at "N-1"th hop in case that "N"th hop was limit exceeded and deletion. Under this situation, there is a possibility of bundles which get nowhere from "N-1"th hop (maybe backwards). 
I respect original 5050 concept, but just clarification.
The hop count limit exceeded may be able to treat expiration (section 5.5), but does not in 5050bis. Does treatment of exceeding hop count bet on a last bit of chance that bundle may reach the destination by "N-1"th's carrying etc? 

*Section 9 and Section13
BIBE is mentioned in this draft. Especially, there is a description such as "Migrate custody transfer to the bundle-in-bundle encapsulation specification." But there are not any references for "BIBE specification" in this draft. I think current BIBE I-D (although individual I-D) may be referred to as an informative at least.

Best Regards,
Kiyohisa Suzuki

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Rick Taylor
Sent: Wednesday, October 18, 2017 12:43 AM
To: [email-masked]
Subject: [dtn] RFC5050bis Support

Hi All,

Thank you everyone for showing your support for 5050bis, it's good to hear from all of those who are keen to see the work succeed.

However I don't believe there was ever a question of lack of support for the work, my personal concern was with the lack of on-list peer review of the 3 work-items: BPbis, TCP-CL, and BPSec.

Of the three, BPbis has received solid reviews (thank you Lucas and others).  I believe BPSec has had significant offline review by cryptography experts, but I have noticed little recent on-list discussion.  TCP-CL has had some comments, but my gut feeling is that it is not quite polished/peer-reviewed enough to make it through the IETF post-WG review stages without significant delay.

As a recap: The intention of the working group is for all three documents to be eventually released as a set: The 'packet' format (5050bis), a general-purpose interoperable transmission format (TCP- CL), and a method for security (BPbis).

Please can I request that all of you find a few minutes in your undoubtedly busy days to have another quick read of all three drafts, and post a quick summary of any typos, inconsistencies, areas of potential confusion, and/or any passing comments on readability and style that you might find to the list before IETF-100?  Please don't hold back opinion because you feel that you might look foolish, or upset the 'DTN wizards' - I've met a lot of them, and they're human really!

Many thanks,

Rick Taylor

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 19 Oct 2017 19:38:59 +0000

Lloyd,

This is in the realm of the IETF now, where it is about rough consensus
and running code. For sure, not everyone is going to like it but that does
not invalidate the consensus.

Thanks- Fred

> From: dtn [mailto:[email-masked]] On Behalf Of Lloyd Wood
> Sent: Tuesday, October 17, 2017 5:06 PM
> To: Rick Taylor <[email-masked]>; [email-masked]
> Subject: Re: [dtn] RFC5050bis Support
>

---

From: Marco Kaulea <[email-masked]>
Date: Sun, 22 Oct 2017 21:11:28 +0200

Hi All,

I only had time to go over TCP-CLv4, so for now I only have comments on that.
Comments are on the basis of draft-ietf-dtn-tcpclv4-02.

Section 4.1/4.1.1:
   There seems to be no way to determine if there are any header
extension items attached to a contact header. A parser would not be
able to know when the header ends.
   The easiest solution would probably be to define an end-of-list
item and append that to the list of items if any or directly to the
contact header.

Section 4.2 Par. 7:
    This paragraph is contradicted by 5.3.1 TLS Handshake Result. My
interpretation is that this paragraph is only applicable if the
connection does not upgrade to TLS. This should be cleared up.
    A reference to Section 7 Security Considerations would also be helpful.

Section 4.2/5.3/7:
    It is unclear what the correct behavior would be if one node
requires TLS and another does not support it. According to Section 4.2
the connection should proceed in the clear if either node does not
support TLS.
    On the other hand Section 7 specifies a method to prevent leaking
endpoint parameters, but is missing any instructions on how to abort
the connection if the other node does not support TLS.
    Would a SHUTDOWN with reason TLS failure the correct behavior?

Section 5.1 Table 3:
    XFER_REFUSE does not contain a link to the corresponding section

Section 5.2.1:
    In Section 4.1 the keepalive interval is defined as the longest
allowed time between to KEEPALIVE messages. This conflicts with this
section, which does count the longest allowed time between any
messages,
    KEEPALIVE or other. I'm assuming the latter is correct, but this
could be cleared up.

Section 5.4 Par. 1:
    Typo: "tranfering" => "transferring"

Section 5.4.2 Heading:
    "initialization" should be capitalized as all the other headings

Section 5.4.2 Last Paragraph:
    The error condition is defined by what the next message is. This
seems difficult to implement.
    What about during two way transmission of bundles, a XFER_INIT for
one direction might be directly followed by a XFER_ACK for the other
direction.
    This could use some clarification. (I might be missing something here)

Section 5.4.5 Table 6:
    "The receiver now has the complete bundle." This should probably
read, "The receiver already has the complete bundle", since the
transfer was aborted the bundle would have to been on the receiving
node before the transfer.

Section 6.1 Last Paragraph:
    I had to read this paragraph about ten times before I had any
understanding of what is being described. And I'm still not 100% sure.
This could use some clarification.

Section 8.3:
    Typo: "resrved for use" => "reserved for use"

I hope these comments are at least somewhat useful, the are from the
perspective of a software developer who is completely new to the IETF
process.
If any of my comments aren't clear feel free to ask.

Regards,
Marco

---

From: Lucas Kahlert <[email-masked]>
Date: Tue, 24 Oct 2017 16:23:30 +0200

Hello,

I have found a reference mistake in section "5.12 Canceling a 
Transmission": The specification refers to 5.14 for the deletion of the 
bundle. The correct section is "5.10 Bundle Deletion".

Furthermore, I have a question about the BPA interface definition:
The Application Agent should be able to cancel a transmission. This 
requires the Application Agent to hold some sort of reference to a 
bundle (e.g. Bundle ID) that will be passed to the BPA to cancel the 
transmission. This reference should be returned to the Application Agent 
after Step 1 in section "5.2 Bundle Transmission". I stumbled over this 
problem in my Activity Diagram (UML 2.5) model of BPbis.

Regards,
Lucas

---

From: Brian Sipos <[email-masked]>
Date: Mon, 30 Oct 2017 19:30:04 +0000

Marco, all of your comments are genuine issues and appreciated. Some of these peculiarities are due to inheriting some behavior (and spec. language) from the earlier protocol version, and it's helpful to have fresh reviewers to spot these things.

I'm making edits to a new draft version for yours and earlier comments since the last draft. The only one I've not dealt with is in Section 5.1 Table 3, which seems to be caused by the IETF xml-to-html conversion itself which I have no control over.

________________________________
From: dtn <[email-masked]> on behalf of Marco Kaulea <[email-masked]>
Sent: Sunday, October 22, 2017 15:11
To: [email-masked]
Cc: Rick Taylor
Subject: Re: [dtn] RFC5050bis Support

Hi All,

Section 4.1/4.1.1:

Section 4.2 Par. 7:

Section 4.2/5.3/7:

Section 5.1 Table 3:

Section 5.2.1:

Section 5.4 Par. 1:

Section 5.4.2 Heading:

Section 5.4.5 Table 6:

Section 8.3:

Regards,
Marco

_______________________________________________
dtn mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dtn
dtn Info Page - Internet Engineering Task Force<https://www.ietf.org/mailman/listinfo/dtn>
www.ietf.org
"This list is for discussions related to the formation of a Delay Tolerant Networking (DTN) working group. The IRTF DTNRG research group has worked on the particular ...