Subject: Re: [dtn] Canceling a Transmission

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Sun, 12 Nov 2017 13:50:57 +0000

Thanks, Lucas.  I looked for that incorrect reference but could not find it; I think this might be something I already fixed in an interim version of the spec.

On your second point: we actually have been fairly scrupulous about not defining a "service specification" for BP, which is where the change you propose would go.  Certainly we could change this, but that would be a fairly major change that we should not undertake lightly.  Absent a service specification, I think the change you propose should be considered an implementation matter (though of course an important one).

Scott

________________________________
From: dtn <[email-masked]> on behalf of Lucas Kahlert <[email-masked]>
Sent: Tuesday, October 24, 2017 7:23:30 AM
To: [email-masked]
Subject: Re: [dtn] Canceling a Transmission

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

On 17.10.2017 17:43, Rick Taylor wrote:
> 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
> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn
>

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

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Sun, 12 Nov 2017 13:59:01 +0000

Hi, Lucas.  I am not fully convinced that the language of 5.4 doesn't already state fairly clearly what is expected, but I can try making it a little more explicit.  Does the attached text do what you think is needed?

Scott

________________________________
From: dtn <[email-masked]> on behalf of Lucas Kahlert <[email-masked]>
Sent: Wednesday, October 18, 2017 7:40:46 AM
To: [email-masked]
Subject: Re: [dtn] RFC5050bis Support

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: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Tue, 21 Nov 2017 18:31:12 +0000

Kiyo, my belated thanks for this.  On the hop count question, I think we are okay since both the hop count text and the bundle lifetime expiration text reference the bundle deletion procedure defined in section 5.10; these are two of the ways that bundle deletion can be initiated, and there are actually a couple more.  Exceeding the hop count doesn't constitute lifetime expiration, but the effect is the same.

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of ?? ??
Sent: Wednesday, October 18, 2017 9:20 PM
To: [email-masked]
Subject: Re: [dtn] RFC5050bis Support

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: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Tue, 21 Nov 2017 19:08:09 +0000

Hi, Juan.  Finally getting back to your comments, I have inserted some notes in-line below in red text.

One point in particular that I would like everyone to weigh in on: Juan points out that the “destination endpoint is a singleton” flag is no longer really needed, now that custody transfer has been removed from the BP specification.  For the -09 draft I am planning to remove that flag.  If anybody can think of some reason why we still need the “destination endpoint is a singleton” flag in the bundle primary block, please speak up!

Scott

From: dtn [mailto:[email-masked]] On Behalf Of Juan A. Fraire
Sent: Tuesday, October 17, 2017 9:31 AM
To: Rick Taylor <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn] RFC5050bis Support

[https://mailtrack.io/trace/mail/f1464a775d79476cc5be36b7e3cfc36febcb7525.png?u=298567]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.  Okay.
     *   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? No, there will always need to be some sort of adaptation to the underlying layer, even if it’s hardware.  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. But as you point out, we already say that BP runs over underlying protocols.
     *   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.  I don’t think any additional text is really needed here, though.

  *   Section 3

     *   Fig. 2: Figure 2 is split in two pages, it is very difficult to understand like this.  Yes, this will need to be fixed when the RFC is published.
     *   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.  I think the definition in “Delivery” is already clear, though.
     *   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. I don’t think this is necessary.  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. I agree!
     *   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.  We could write quite a lot of explanatory and expository text here, but my preference would be to keep the specification fairly terse and leave this additional implementation discussion for another document.
     *   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.)".  I think the language of the spec is correct here, though; I don’t think we need to spell everything out.

  *   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).  I think the language is right for a specification (though not for a textbook); I don’t think we need to illustrate.
     *   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? We used to need this flag for the correct operation of custody transfer, but now that custody transfer is removed I think it is obsolete.  I’m excising it from the BP spec unless somebody remembers some other good reason for carrying it.  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? No, it doesn’t.  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.  I think it’s already clear, though.  The text says what it says, and it doesn’t say anything else.
     *   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. This is by the definition of nodes.  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).  I would say that any device that has enough processing power to send or consume a bundle has got enough processing power to be a DTN node, as defined in this specification.  I don’t think there’s a problem here.
     *   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.  But we don’t intend this document to be a CBOR tutorial; an interested reader can find this information.
     *   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?).  Good point, it’s now moved.
     *   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.  Right, this is an important consideration, but the WG determined a while ago that it needs to be addressed in a separate extension block definition document.

  *   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.  Figures 3 and 4 are in section 6.

  *   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.  Reactive fragmentation is only possible when contact is lost after the first byte of payload has been received but before the last byte of payload has been received.  An implementation is allowed to process a non-conformant bundle, which would always have been necessary in order to do reactive fragmentation, even before CBOR.  So I think it’s not an issue.
Hope it helps,

Juan

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

Many thanks,

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

---

From: 鈴木 清久 <[email-masked]>
Date: Wed, 22 Nov 2017 07:36:54 +0000

Thank you, Scott. I concur with you. 
Also I confirmed to reflect a reference of BIBE was inserted in I-D v9 (editorial and minor, but I commented...).

-Kiyo

-----Original Message-----
From: Burleigh, Scott C (312B) [mailto:[email-masked]] 
Sent: Wednesday, November 22, 2017 3:31 AM
To: 鈴木　清久 <[email-masked]>; [email-masked]
Subject: RE: RFC5050bis Support

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of ?? ??
Sent: Wednesday, October 18, 2017 9:20 PM
To: [email-masked]
Subject: Re: [dtn] RFC5050bis Support

Dear IETF DTN WG,

*General

*Hop count

*Section 9 and Section13

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,

Many thanks,

Rick Taylor

---

From: Rick Taylor <[email-masked]>
Date: Wed, 22 Nov 2017 10:19:11 +0000

Hi Scott,

Concerning the 'Destination Endpoint is a Singleton' flag, my personal
opinion would be to remove it.  I feel it conflates something about the
semantics of an address (whatever they actually are) with the details
of the encapsulation.

Cheers,

Rick

On Tue, 2017-11-21 at 19:08 +0000, Burleigh, Scott C (312B) wrote:
> One point in particular that I would like everyone to weigh in on:
> Juan points out that the “destination endpoint is a singleton” flag
> is no longer really needed, now that custody transfer has been
> removed from the BP specification.  For the -09 draft I am planning
> to remove that flag.  If anybody can think of some reason why we
> still need the “destination endpoint is a singleton” flag in the
> bundle primary block, please speak up!
>  
> Scott
>  
> 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.  Okay.
> 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? No, there will always need to be some sort of adaptation
> to the underlying layer, even if it’s hardware.  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. But as you point out,
> we already say that BP runs over underlying protocols.
> 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.  I don’t think any additional text is really needed here,
> though.
> Section 3
> Fig. 2: Figure 2 is split in two pages, it is very difficult to
> understand like this.  Yes, this will need to be fixed when the RFC
> is published.
> 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.  I think the definition in “Delivery” is already clear,
> though.
> 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. I don’t
> think this is necessary.  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. I agree!
> 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.  We could write quite a lot of explanatory and expository
> text here, but my preference would be to keep the specification
> fairly terse and leave this additional implementation discussion for
> another document.
> 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.)".  I think the language of the spec is
> correct here, though; I don’t think we need to spell everything out.
> 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).  I think the
> language is right for a specification (though not for a textbook); I
> don’t think we need to illustrate.
> 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? We used to need
> this flag for the correct operation of custody transfer, but now that
> custody transfer is removed I think it is obsolete.  I’m excising it
> from the BP spec unless somebody remembers some other good reason for
> carrying it.  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: "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? No, it doesn’t.  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.  I think it’s already clear,
> though.  The text says what it says, and it doesn’t say anything
> else.
> 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. This is by the definition of nodes.  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).  I would say that any device that has enough
> processing power to send or consume a bundle has got enough
> processing power to be a DTN node, as defined in this specification. 
> I don’t think there’s a problem here.
> 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.  But we don’t intend
> this document to be a CBOR tutorial; an interested reader can find
> this information.
> 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?).  Good point, it’s now moved.
> 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.  Right, this is an important consideration, but
> the WG determined a while ago that it needs to be addressed in a
> separate extension block definition document.
> 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.  Figures 3 and 4 are in section 6.
>  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.  Reactive fragmentation
> is only possible when contact is lost after the first byte of payload
> has been received but before the last byte of payload has been
> received.  An implementation is allowed to process a non-conformant
> bundle, which would always have been necessary in order to do
> reactive fragmentation, even before CBOR.  So I think it’s not an
> issue.
> Hope it helps,
>  
> Juan
>  
>  
>  
> On Tue, Oct 17, 2017 at 5:43 PM, Rick Taylor <rick@tropicalstormsoftw
> are.com> wrote:
> Hi All,
>