Subject: [dtn] on removing reactive fragmentation from base tcpcl spec

From: "Marc Blanchet" <[email-masked]>
Date: Thu, 29 Mar 2018 08:59:11 -0400

Hello,
  during IETF 101 session (as noted in the meeting minutes: 
https://datatracker.ietf.org/doc/minutes-101-dtn/), there was a 
unanimous decision in the room (no single hum for keeping, many hums for 
removing) to remove the reactive fragmentation from the TCPCL base spec 
and to write it in a separate spec. It is not about removing the feature 
itself, but removing from the base TCPCL spec in order to move it 
forward to IESG with BPbis. We did similarly with BP custody transfer.
  The discussion about this has already started, which is good. But this 
message is a formal notification for this discussion to occur, to 
confirm/not the decision taken during the meeting and hopefully come to 
a concensus.

Marc&Rick, co-chairs

---

From: "R. Atkinson" <[email-masked]>
Date: Thu, 29 Mar 2018 10:22:05 -0400

> On Mar 29, 2018, at 08:59, Marc Blanchet <[email-masked]> wrote:
> 
> Hello,
> during IETF 101 session (as noted in the meeting minutes: https://datatracker.ietf.org/doc/minutes-101-dtn/), there was a unanimous decision in the room (no single hum for keeping, many hums for removing) to remove the reactive fragmentation from the TCPCL base spec and to write it in a separate spec. It is not about removing the feature itself, but removing from the base TCPCL spec in order to move it forward to IESG with BPbis. 

I am OK either way on how the specification is packaged.

That said, I’m confused about one thing...

— Is the current intention that the Reactive Fragmentation capability 
     would be “mandatory to implement” or “optional to implement” ?

— Put another way, does this repackaging proposal change whether
     Reactive Fragmentation is optional/mandatory ?

Thanks,

Ran

---

From: "Marc Blanchet" <[email-masked]>
Date: Thu, 29 Mar 2018 10:56:11 -0400

On 29 Mar 2018, at 10:22, R. Atkinson wrote:

>> unanimous decision in the room (no single hum for keeping, many hums 
>> for removing) to remove the reactive fragmentation from the TCPCL 
>> base spec and to write it in a separate spec. It is not about 
>> removing the feature itself, but removing from the base TCPCL spec in 
>> order to move it forward to IESG with BPbis.
>

wg to decide.

Marc.

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Thu, 29 Mar 2018 15:19:37 +0000

I am in favor of defining the specification for TCPCL reactive fragmentation in a separate document.  As such, I think the right way to draft this specification would be in terms of the contact header extension mechanism defined in the TCPCL spec.  If the feature is defined as an extension to TCPCL, I think it will necessarily be optional to implement.  But maybe the reactive fragmentation extension item should be defined to have the CRITICAL flag set?  If either party to the TCPCL session does not implement reactive fragmentation, I think it may be mandatory to abort the session so that the other party doesn't proceed under an erroneous expectation of capability.

Scott

-----Original Message-----
From: dtn <[email-masked]> On Behalf Of R. Atkinson
Sent: Thursday, March 29, 2018 7:22 AM
To: Marc Blanchet <[email-masked]>
Cc: DTN WG <[email-masked]>
Subject: Re: [dtn] on removing reactive fragmentation from base tcpcl spec

Thanks,

Ran

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