Subject: [dtn] I-D Action: draft-ietf-dtn-bpbis-03.txt

From: Brian Haberman <[email-masked]>
Date: Wed, 27 Apr 2016 08:26:39 -0400

All,
     This note starts a 4-week DTN Working Group last call on advancing:

        Title           : Bundle Protocol
        Authors         : Scott Burleigh
                          Kevin Fall
                          Edward J. Birrane
        Filename        : draft-ietf-dtn-bpbis-03.txt

as a Proposed Standard. Substantive comments should be sent to the DTN
mailing list. Editorial comments can be sent to the document authors.
This last call will end May 25, 2016.

Regards,
Brian

---

From: "Marc Blanchet" <[email-masked]>
Date: Wed, 27 Apr 2016 08:36:52 -0400

we would need a shepherd for this document. Anyone interested please 
contact co-chairs at [email-masked]

Regards, Marc.

On 27 Apr 2016, at 8:26, Brian Haberman wrote:

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

---

From: Gilbert Clark <[email-masked]>
Date: Wed, 27 Apr 2016 10:45:47 -0400

Hi:

Apologies that I haven't spoken up before last call ... I was expecting 
there to be a few more revisions before the document entered this 
state.  Basically, I thought there was still more time than there was :)

Based on a reading of the document as it exists at present, this appears 
(to me, anyway) like it would be more suitably classified as an 
informational document than as a proposed standard. Fundamentally, I 
believe a standard should describe a set of things that make two 
implementations of the standard interoperable.  In this case, there is 
not a specific bundle definition (beyond "it must contain X, Y, and 
Z").  There is not a minimal list of viable convergence layer adapters 
that MUST be supported in order for a BP implementation to be considered 
complete (in order to facilitate communication between BP agents).  
There is additionally not, to my knowledge, any kind of representation 
specification that has been submitted in conjunction with this draft to 
precisely define the objects and fields defined within.  Sure, the 
document specifies that when X happens, then a BPA should respond with Y 
... but how can we say this is a protocol specification without either 
A) specifying what Y should look like in the document, or B) submitting 
an additional document (in tandem with this one) that explains a 
possible definition for Y and reference said model document from the 
core protocol draft?

In other words, (in my humble opinion) the selection and submission of 
at least one convergence layer and representation format should both be 
requirements for this protocol to be considered any kind of standard, 
and the document should additionally specify that, at a minimum, a BP 
implementation MUST support the representation format in the document as 
indicated above.  Realistically, it should also specify support of one 
convergence layer: no one would have to use it internally, but there 
*would* need to be support for that adapter in order to facilitate 
inter-implementation communication when necessary.

 From an implementor's perspective, I would additionally argue that less 
attention should be paid to implementation details (read: that 
application agent diagram strikes me as being completely irrelevant to 
any kind of protocol specification itself), and more attention should be 
paid to the clear, concise definition of state descriptions / diagrams 
to describe the lifecycle of the elements defined in this document.  I 
really don't care what an application agent is supposed to look like, 
since my implementation of an application agent won't affect my ability 
to talk to someone else running BP - only the stuff I write to the wire 
will do that.

I'll try to go back through and do an additional review here to offer 
more specific points of feedback ... but hopefully the above relatively 
clearly articulates a few concerns I have with the document as it exists 
at the moment.

Cheers,
Gilbert Clark

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Wed, 27 Apr 2016 15:36:18 +0000

Hi, Gilbert.  I understand your concerns, but I think we are okay.  The intent is to publish multiple representation specifications enabling bundles to be appropriately encoded for multiple different transmission environments.  The first of those to emerge is a CBOR representation specification that I posted on March 4 (https://datatracker.ietf.org/doc/draft-burleigh-dtn-rs-cbor/) and announced to this mailing list on that date.  There has been a little bit of discussion of that draft, and I am preparing to post an -01 edition of the spec on Friday.  I am expecting additional representation specifications (JSON for sure, and maybe others) to take shape in coming months.

As to convergence-layer standardization, I disagree.  The IP specification in isolation is not sufficient to enable communication between two IP nodes (you need underlying PPP or Ethernet or etc.), but IP certainly a standard.  The SMTP specification in isolation is not sufficient to enable communication between SMTP clients and servers (you need underlying TCP/IP), but SMTP is certainly a standard.

It is certainly true that a minimum set of representations and convergence-layer adapters is required in order for a BP implementation to be considered complete.  But specifications and implementations are different things.

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Gilbert Clark
Sent: Wednesday, April 27, 2016 7:46 AM
To: [email-masked]
Subject: Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-03.txt

Hi:

Apologies that I haven't spoken up before last call ... I was expecting there to be a few more revisions before the document entered this state.  Basically, I thought there was still more time than there was :)

Based on a reading of the document as it exists at present, this appears (to me, anyway) like it would be more suitably classified as an informational document than as a proposed standard. Fundamentally, I believe a standard should describe a set of things that make two implementations of the standard interoperable.  In this case, there is not a specific bundle definition (beyond "it must contain X, Y, and Z").  There is not a minimal list of viable convergence layer adapters that MUST be supported in order for a BP implementation to be considered complete (in order to facilitate communication between BP agents).  
There is additionally not, to my knowledge, any kind of representation specification that has been submitted in conjunction with this draft to precisely define the objects and fields defined within.  Sure, the document specifies that when X happens, then a BPA should respond with Y ... but how can we say this is a protocol specification without either
A) specifying what Y should look like in the document, or B) submitting an additional document (in tandem with this one) that explains a possible definition for Y and reference said model document from the core protocol draft?

In other words, (in my humble opinion) the selection and submission of at least one convergence layer and representation format should both be requirements for this protocol to be considered any kind of standard, and the document should additionally specify that, at a minimum, a BP implementation MUST support the representation format in the document as indicated above.  Realistically, it should also specify support of one convergence layer: no one would have to use it internally, but there
*would* need to be support for that adapter in order to facilitate inter-implementation communication when necessary.

 From an implementor's perspective, I would additionally argue that less attention should be paid to implementation details (read: that application agent diagram strikes me as being completely irrelevant to any kind of protocol specification itself), and more attention should be paid to the clear, concise definition of state descriptions / diagrams to describe the lifecycle of the elements defined in this document.  I really don't care what an application agent is supposed to look like, since my implementation of an application agent won't affect my ability to talk to someone else running BP - only the stuff I write to the wire will do that.

I'll try to go back through and do an additional review here to offer more specific points of feedback ... but hopefully the above relatively clearly articulates a few concerns I have with the document as it exists at the moment.

Cheers,
Gilbert Clark

---

From: Gilbert Clark <[email-masked]>
Date: Wed, 27 Apr 2016 13:33:35 -0400

Hi Scott:

> The intent is to publish multiple representation specifications enabling bundles to be appropriately encoded for multiple different transmission environments.  The first of those to emerge is a CBOR representation specification that I posted on March 4 (https://datatracker.ietf.org/doc/draft-burleigh-dtn-rs-cbor/) and announced to this mailing list on that date.  There has been a little bit of discussion of that draft, and I am preparing to post an -01 edition of the spec on Friday.  I am expecting additional representation specifications (JSON for sure, and maybe others) to take shape in coming months.

I understand that these are a work in progress, but I do think there 
needs to be at *least* one encoding that should be spoken and / or 
understood by all implementations in order to make the argument that BP 
can be considered a standard which guarantees any kind of 
implementation-independent operation at all.  That, I think, is a pretty 
basic requirement for standardization from an IETF perspective.  It is 
also, I believe, a large piece of what separates an informational 
document from a proposed standard.

'm therefore going to stand by my objection that any proposed standard 
for BP should either include or reference a corresponding proposed 
standard for the way that protocol should appear on the wire.  
Naturally, feel free to continue submission despite this objection if 
such represents the consensus of the rest of this group, but I doubt my 
personal opinion on this particular matter will change :)

> As to convergence-layer standardization, I disagree.  The IP specification in isolation is not sufficient to enable communication between two IP nodes (you need underlying PPP or Ethernet or etc.),…

Fair point.  I'll withdraw the argument that a convergence layer adapter 
*must* be specified to proceed with adoption.

I still think it'd be a *really good idea* to do this, though: the 
specification of a convergence layer seems to be pretty tightly coupled 
to the operation of BP itself.  If two people do not agree on a CLA, 
they will not be able to inter-operate with each other. As such, the 
selection of and support for a *minimal* common CLA seems to be a 
requirement for interoperability, and therefore something that should be 
included as part of this (or possibly another) specification that comes 
out of this group.

> It is certainly true that a minimum set of representations and convergence-layer adapters is required in order for a BP implementation to be considered complete.  But specifications and implementat…

Kind of.  I believe IETF processes tend to place a large emphasis on 
both running code and operational experience [1], which implies that, 
from an IETF perspective, the expectation is that specifications are 
*based on* existing implementations to the extent that is possible.  
Thus, the assertion that specification and implementation are two 
different things is correct.  However, given the extent to which I 
understand that implementation drives specification in the IETF 
environment, I think it could be an issue if we submit a draft which 
does not completely specify the technological details necessary for two 
independent parties to communicate when we also have no existing code 
*for the existing version of the draft* - I know we have code for 
previous revisions of the document, but I am not certain of the extent 
to which they will apply given the extent to which this document has 
been rewritten.

Ideally, we'd already have two, inter-operable versions of the code 
based on *this draft specification*, just so we could point to that and 
say: "Hey, here's exactly how we're doing this, and we've proven that it 
works.  The documentation to back it up should be along shortly."  From 
the IETF perspective, I really do think that anything else is really 
going to be kind of a gamble.

Cheers,
Gilbert

[1] Quoting RFC 7127 -

    Usually, neither implementation nor operational experience is
    required for the designation of a specification as a Proposed
    Standard.  However, such experience is highly desirable and will
    usually represent a strong argument in favor of a Proposed Standard
    designation.

    The IESG may require implementation and/or operational experience
    prior to granting Proposed Standard status to a specification that
    materially affects the core Internet protocols or that specifies
    behavior that may have significant operational impact on the
    Internet.

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Wed, 27 Apr 2016 19:18:52 +0000

Thanks for the reference, Gilbert, and I agree that implementation and operational experience are desirable.  But as this text notes, they are not required: the BP spec does not materially affect the core Internet protocols and does not specify behavior that will have a significant operational impact on the Internet (as an Internet Standard it would, but that's not on the table right now, and by the time it is there will be plenty of implementations and plenty of operational experience).  So for the purpose of advancing this specification to the status of Proposed Standard I think everything is in place.

I certainly wouldn't object to including a reference to the CBOR representation specification in the BP spec, so long as it's not a normative reference.  My understanding of the sense of the WG is that we specifically do *not* want every conformant BP implementation to be required to implement any single universally required representation.  This is not an obstacle to interoperability testing, and it's not an obstacle to interoperation on the network so long as the transformation from one representation to another is mechanical.  As was pointed out in the early conversations on this topic, CBHE has for many years provided an existence proof of this.

Likewise I wouldn't object to including non-normative references to one or more convergence-layer adapter specifications in the BP spec.  Again, we specifically do *not* want every conformant BP implementation to be required to implement any single universally required convergence-layer adapter.  Experience with RFC5050 (and, for that matter, IP) has clearly demonstrated that this is not necessary.

Implementations are different from specifications.  Specifications have value in themselves, in isolation.  Implementations only have value if they can be demonstrated, and this is always only possible when they are deployed in conjunction with a whole raft of other implementations (an overlying application, underlying link and physical protocols, hardware, an electric power grid, etc.).  We don't include the specification for A/C power distribution in the specification for IP, even though IP interoperation is difficult to demonstrate without an A/C power distribution system.  I think the scope of the BP spec is appropriate.

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Gilbert Clark
Sent: Wednesday, April 27, 2016 10:34 AM
To: [email-masked]
Subject: Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-03.txt

> The intent is to publish multiple representation specifications enabling bundles to be appropriately encoded for multiple different transmission environments.  The first of those to emerge is a CBO…

I understand that these are a work in progress, but I do think there needs to be at *least* one encoding that should be spoken and / or understood by all implementations in order to make the argument that BP can be considered a standard which guarantees any kind of implementation-independent operation at all.  That, I think, is a pretty basic requirement for standardization from an IETF perspective.  It is also, I believe, a large piece of what separates an informational document from a proposed standard.

'm therefore going to stand by my objection that any proposed standard for BP should either include or reference a corresponding proposed standard for the way that protocol should appear on the wire.  
Naturally, feel free to continue submission despite this objection if such represents the consensus of the rest of this group, but I doubt my personal opinion on this particular matter will change :)

I still think it'd be a *really good idea* to do this, though: the specification of a convergence layer seems to be pretty tightly coupled to the operation of BP itself.  If two people do not agree on a CLA, they will not be able to inter-operate with each other. As such, the selection of and support for a *minimal* common CLA seems to be a requirement for interoperability, and therefore something that should be included as part of this (or possibly another) specification that comes out of this group.

> It is certainly true that a minimum set of representations and convergence-layer adapters is required in order for a BP implementation to be considered complete.  But specifications and implementat…

Kind of.  I believe IETF processes tend to place a large emphasis on both running code and operational experience [1], which implies that, from an IETF perspective, the expectation is that specifications are *based on* existing implementations to the extent that is possible.  
Thus, the assertion that specification and implementation are two different things is correct.  However, given the extent to which I understand that implementation drives specification in the IETF environment, I think it could be an issue if we submit a draft which does not completely specify the technological details necessary for two independent parties to communicate when we also have no existing code *for the existing version of the draft* - I know we have code for previous revisions of the document, but I am not certain of the extent to which they will apply given the extent to which this document has been rewritten.

Ideally, we'd already have two, inter-operable versions of the code based on *this draft specification*, just so we could point to that and
say: "Hey, here's exactly how we're doing this, and we've proven that it works.  The documentation to back it up should be along shortly."  From the IETF perspective, I really do think that anything else is really going to be kind of a gamble.

Cheers,
Gilbert

[1] Quoting RFC 7127 -

---

From: <[email-masked]>
Date: Thu, 28 Apr 2016 04:39:28 +0000 (UTC)

I agree with Gilbert.

This protocol is being pushed through at a rapid pace, even though
it's at best a sketch of what the protocol might be. And, as a
sketch, it should be informational.

Scott's 'we can go for proposed std without demonstrated interop
because we do not affect core IETF protocols! but we still want
to be a standard! even though no-one will use it!' argument is

just evidence that a standard is desired, regardless of utility.

CCSDS people are pushing for an IETF standard in the hope that that
will get more traction than a CCSDS-published equivalent standard

wouldget - while, as is usual for CCSDS, touting not having to
interoperate with the standards put out by IETF (just as
CCSDS is an ISO subgroup but its protocols don't interoperate
with ISO HDLC, frame relay etc.)as a plus.
This is informally called 'having your cake and eating it'.

Proposed std makes no sense here. Informational does.

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

----- Original Message -----
From: Gilbert Clark <[email-masked]>
To: [email-masked]
Sent: Thursday, 28 April 2016, 0:45
Subject: Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-03.txt

Hi:

Cheers,
Gilbert Clark

---

From: Gilbert Clark <[email-masked]>
Date: Thu, 28 Apr 2016 09:20:55 -0400

Hi Scott:

Just keeping the conversation moving here :)

Inline:

> Thanks for the reference, Gilbert, and I agree that implementation and operational experience are desirable.  But as this text notes, they are not required: the BP spec does not materially affect t…

Right.  I didn't intend to imply they were required (and my apologies if 
it came across that way).

Instead, I intended to imply that moving forward into proposed standard 
territory without such prototypes could turn this into an uphill 
battle.  Even if consensus is achieved within the WG, there are many 
people beyond the WG (many of them technical experts in their own right) 
who will be closely examining the items we wish to propose.  As this 
will be the first deliverable from this IETF WG (of which I am aware), 
I'd imagine scrutiny will be even closer than it would be otherwise.

If we nail the first deliverable with a minimum of fuss and a solid 
foundation, it will allow people to focus on other things in the 
confidence that we seem to know what we're doing.  If our first ever 
submission does not seem well-prepared and / or to have addressed 
necessary questions, though, then things could A) take more time, just 
because back-and-forth at the AD level tends to have much longer 
turnaround, and B) turn out to be more difficult for us down the road.

> I certainly wouldn't object to including a reference to the CBOR representation specification in the BP spec, so long as it's not a normative reference.  My understanding of the sense of the WG is that we specifically do *not* want every conformant BP implementation to be required to implement any single universally required representation.

I actually think that we do want *conformant* BP implementations to 
implement *at least* one common encoding we select as a standard, and 
implementations may choose to implement support for additional encodings 
as they see fit.  If nodes that are not outward-facing choose to not 
strictly conform with that requirement, then that's not really an issue 
as long as there's not an expectation that one can inter-operate with 
those nodes without going through some sort of compliant intermediary.

Just to be clear - from my perspective, an IETF proposed standard isn't 
intended to legislate how someone runs a DTN on their end.  It is only 
intended to legislate how border agents in DTNs can interface with each 
other without necessitating any human involvement whatsoever.  For 
example, Google could have their own version of TCP they wrote to 
optimize their network traffic at scale, and we mere mortals would 
neither ever know nor ever care because they don't try to use their 
custom implementation to talk to anyone else.

Short version: as far as proposed standards and the IETF is concerned, I 
would argue that the internals don't matter: the *unassisted* 
inter-operation component *does*, and should be the primary focus of the 
IETF specification here.

> This is not an obstacle to interoperability testing, and it's not an obstacle to interoperation on the network so long as the transformation from one representation to another is mechanical.

The issue I see with inter-operation is that, without an understanding 
that a node can speak an encoding, one has no idea how to start a 
conversation with a node.  I guess one could take a happy dtn eyeballs 
approach and just throw everything at the destination to see what 
sticks, but ... that seems like it could strain the network a bit.

With that said, if we want to add a capability negotiation component 
spoken in a common language with a common encoding, that might alleviate 
my concerns to some extent ... but I do think it'd be easier to just 
pick a common protocol and encoding which we expect border nodes to be 
able to speak and go with that instead.

At the risk of dooming my inbox to a relatively fast and violent death, 
what was the motivation for not electing to adopt support for a common 
encoding and convergence layer?  Note that this question is asked based 
on the assumption that the common encoding and convergence layer would 
not necessarily be used within one's own network, only that support for 
said common encoding and convergence layer would be *required* to exist 
in any BP-conformant implementation and used as a fallback in the case 
that the encoding or convergence layer adapter was not otherwise known.

> As was pointed out in the early conversations on this topic, CBHE has for many years provided an existence proof of this.

Sorry, I think I missed that conversation - would you mind explaining 
this again or pointing me to a relevant thread?

> Likewise I wouldn't object to including non-normative references to one or more convergence-layer adapter specifications in the BP spec.  Again, we specifically do *not* want every conformant BP im…

My experience with 5050, though, says that I need to call / e-mail / 
etc. the people I want to talk to and ask them what convergence layers 
they're running.  From an implementation perspective, that's not bad - I 
don't mind.  From an inter-operability perspective, however, I don't 
think that's so great: the emphasis here should be on how I want to talk 
to someone I've *never met* without actually having to call them to ask 
them how to do it, not on how DTN should be designed and deployed in my 
own network.

> Implementations are different from specifications.  Specifications have value in themselves, in isolation.  Implementations only have value if they can be demonstrated, and this is always only poss…

I'm not arguing that the scope of the BP specification is inappropriate 
by any means: I'm just arguing that other specifications should be 
included with it in order to tell a complete story.  People should be 
able to use this specifications to implement a complete version of the 
protocol.

In the end, though, I'm not necessarily the one who needs to be 
convinced: the area directors and others involved in the approval of 
such a proposed standard are the ones whose opinions matter. Instead, 
what I'm doing here is trying to lay the groundwork for that 
conversation: because based on experiences in other working groups, I'm 
pretty sure those examining the drafts outside of this WG would have 
similar types of questions or concerns.

I do feel guilty for being difficult here, but I also feel like we 
should have our ducks in a row before we start pushing these drafts up 
the chain for others outside our working group to review.

Cheers,
Gilbert

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 28 Apr 2016 16:03:57 +0000

HI,

RFC4301 is an example of a document was published as Proposed Standard, but did
not itself include detailed bits-over-the-wire specifications.

Thanks - Fred
[email-masked]

> Sent: Thursday, April 28, 2016 6:21 AM
> To: [email-masked]
> > Thanks for the reference, Gilbert, and I agree that implementation and operational experience are desirable.  But as this text notes,
> they are not required: the BP spec does not materially affect the core Internet protocols and does not specify behavior that will have a
> significant operational impact on the Internet (as an Internet Standard it would, but that's not on the table right now, and by the time
> it is there will be plenty of implementations and plenty of operational experience).  So for the purpose of advancing this specification
> to the status of Proposed Standard I think everything is in place.
> 
> > I certainly wouldn't object to including a reference to the CBOR representation specification in the BP spec, so long as it's not a
> normative reference.  My understanding of the sense of the WG is that we specifically do *not* want every conformant BP
> implementation to be required to implement any single universally required representation.
> 
> > This is not an obstacle to interoperability testing, and it's not an obstacle to interoperation on the network so long as the
> transformation from one representation to another is mechanical.
> 
> > Likewise I wouldn't object to including non-normative references to one or more convergence-layer adapter specifications in the BP
> spec.  Again, we specifically do *not* want every conformant BP implementation to be required to implement any single universally
> required convergence-layer adapter.  Experience with RFC5050 (and, for that matter, IP) has clearly demonstrated that this is not
> necessary.
> 
> > Implementations are different from specifications.  Specifications have value in themselves, in isolation.  Implementations only have
> value if they can be demonstrated, and this is always only possible when they are deployed in conjunction with a whole raft of other
> implementations (an overlying application, underlying link and physical protocols, hardware, an electric power grid, etc.).  We don't
> include the specification for A/C power distribution in the specification for IP, even though IP interoperation is difficult to demonstrate
> without an A/C power distribution system.  I think the scope of the BP spec is appropriate.
>

---

From: "gclark mti-systems.com" <[email-masked]>
Date: Thu, 28 Apr 2016 13:39:59 -0400 (EDT)

Fred:

RFC 4301 is an architecture specification.  In other words, it does not have the
word "protocol" anywhere in its title.  Thus, I find this observation to be
unrelated to the conversation happening here.

If you can find a protocol specification that omits a wire representation, then
that might be useful ...

-Gilbert

> On April 28, 2016 at 12:03 PM "Templin, Fred L" <[email-masked]>
> wrote:
> 
> 
> HI,
> 
> > > Thanks for the reference, Gilbert, and I agree that implementation and
> > > operational experience are desirable.  But as this text notes,
> > they are not required: the BP spec does not materially affect the core
> > Internet protocols and does not specify behavior that will have a
> > significant operational impact on the Internet (as an Internet Standard it
> > would, but that's not on the table right now, and by the time
> > it is there will be plenty of implementations and plenty of operational
> > experience).  So for the purpose of advancing this specification
> > > I certainly wouldn't object to including a reference to the CBOR
> > > representation specification in the BP spec, so long as it's not a
> > normative reference.  My understanding of the sense of the WG is that we
> > specifically do *not* want every conformant BP
> > > This is not an obstacle to interoperability testing, and it's not an
> > > obstacle to interoperation on the network so long as the
> > > As was pointed out in the early conversations on this topic, CBHE has for
> > > many years provided an existence proof of this.
> > 
> > > Likewise I wouldn't object to including non-normative references to one or
> > > more convergence-layer adapter specifications in the BP
> > spec.  Again, we specifically do *not* want every conformant BP
> > implementation to be required to implement any single universally
> > required convergence-layer adapter.  Experience with RFC5050 (and, for that
> > matter, IP) has clearly demonstrated that this is not
> > necessary.
> > 
> > > Implementations are different from specifications.  Specifications have
> > > value in themselves, in isolation.  Implementations only have
> > value if they can be demonstrated, and this is always only possible when
> > they are deployed in conjunction with a whole raft of other
> > implementations (an overlying application, underlying link and physical
> > protocols, hardware, an electric power grid, etc.).  We don't
> > include the specification for A/C power distribution in the specification
> > for IP, even though IP interoperation is difficult to demonstrate

---

From: "gclark mti-systems.com" <[email-masked]>
Date: Thu, 28 Apr 2016 13:43:04 -0400 (EDT)

Well, okay, it does actually have protocol in its title ... but is still
something completely different :)

-Gilbert

> On April 28, 2016 at 1:39 PM "gclark mti-systems.com" <[email-masked]>
> wrote:
> 
> 
> Fred:
> 
> > > without an A/C power distribution system.  I think the scope of the BP
> > > spec
> > > is appropriate.
> > >

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 28 Apr 2016 17:47:10 +0000

Hi Gilbert,

> From: gclark mti-systems.com [mailto:[email-masked]]
> Sent: Thursday, April 28, 2016 10:43 AM
> To: Templin, Fred L <[email-masked]>; dtn <[email-masked]>

I am not sure I see the difference. RFC4301 is one example of a precedence
that could be followed by other publications.

Thanks - Fred

---

From: "gclark mti-systems.com" <[email-masked]>
Date: Thu, 28 Apr 2016 14:35:12 -0400 (EDT)

Hi Fred:

> On April 28, 2016 at 1:47 PM "Templin, Fred L" <[email-masked]>
> wrote:
> 
> 
> Hi Gilbert,
> 

One difference is that the objectives of an architecture document is different
than the objectives of a protocol document.  Normally, an architecture describes
a way to do something in the abstract.  A protocol describes the mechanics of
achieving an objective laid out in an architecture somewhere.  Thus, I doubt the
content of one could reasonably be used as precedent to justify the content of
the other.

>From another perspective, 4301 is based on 2401, which I *believe* (someone will
no doubt correct me if I'm wrong :) was originally published as a companion to
2402 and 2406 (as evidenced by the way the three documents actually cite each
other in the references).  As such, while the two are separate documents, they
explain something that is part of a more coherent whole - 2401 explains a
higher-level architecture, while 2402 and 2406 describe an implementation.
 Thus, the three documents *together* serve to define the standard being
proposed: no one of these three documents would be sufficient to achieve such a
definition in and of itself.

Also, as far as I'm aware, the three documents referenced here were published
simultaneously.  That is another difference here: we'll only be publishing a
single RFC that will serve as an incomplete specification of the minimal pieces
necessary to make the bundle protocol work between two different vendors.  We
will not be advancing this draft as part of a *coherent collection* of documents
necessary for someone to implement the protocol.  The continued existence of a
working group is never guaranteed: if the working group (as an example - not
asserting this would actually happen) were to be closed before the companion
documents were published, there would forever be an RFC publicly available that
described a standard which did not yet completely exist.

-Gilbert

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Thu, 28 Apr 2016 20:57:51 +0000

Hi, Gilbert. More inline:

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Gilbert Clark
Sent: Thursday, April 28, 2016 6:21 AM
To: [email-masked]
Subject: Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-03.txt

Hi Scott:

Inline:

> Thanks for the reference, Gilbert, and I agree that implementation and operational experience are desirable.  But as this text notes, they are not required: the BP spec does not materially affect t…

Right.  I didn't intend to imply they were required (and my apologies if it came across that way).

Instead, I intended to imply that moving forward into proposed standard territory without such prototypes could turn this into an uphill battle.  Even if consensus is achieved within the WG, there are many people beyond the WG (many of them technical experts in their own right) who will be closely examining the items we wish to propose.  As this will be the first deliverable from this IETF WG (of which I am aware), I'd imagine scrutiny will be even closer than it would be otherwise.

If we nail the first deliverable with a minimum of fuss and a solid foundation, it will allow people to focus on other things in the confidence that we seem to know what we're doing.  If our first ever submission does not seem well-prepared and / or to have addressed necessary questions, though, then things could A) take more time, just because back-and-forth at the AD level tends to have much longer turnaround, and B) turn out to be more difficult for us down the road.

> I certainly wouldn't object to including a reference to the CBOR representation specification in the BP spec, so long as it's not a normative reference.  My understanding of the sense of the WG is…

I actually think that we do want *conformant* BP implementations to implement *at least* one common encoding we select as a standard, and implementations may choose to implement support for additional encodings as they see fit.  If nodes that are not outward-facing choose to not strictly conform with that requirement, then that's not really an issue as long as there's not an expectation that one can inter-operate with those nodes without going through some sort of compliant intermediary.

>>	It sounds like you're saying that conformance is meaningful only at gateways, and everybody else gets to do whatever they like, but can't claim to comply with a standard.  In which case the standard isn't really serving any purpose in most of the network, right?

Just to be clear - from my perspective, an IETF proposed standard isn't intended to legislate how someone runs a DTN on their end.  It is only intended to legislate how border agents in DTNs can interface with each other without necessitating any human involvement whatsoever.  For example, Google could have their own version of TCP they wrote to optimize their network traffic at scale, and we mere mortals would neither ever know nor ever care because they don't try to use their custom implementation to talk to anyone else.

Short version: as far as proposed standards and the IETF is concerned, I would argue that the internals don't matter: the *unassisted* inter-operation component *does*, and should be the primary focus of the IETF specification here.

>>	But no inter-operation component is ever "unassisted".  I don't see how this argument can make any sense.  Separation of functionality definitions into different documents -- no one of which ever describes anything that can accomplish communication in isolation, all of which are defined with clear interfaces to other functions "above" and "below" them in the protocol stack -- is at the essence of the "layering" concept.  Are you saying layers are a bad idea?

> This is not an obstacle to interoperability testing, and it's not an obstacle to interoperation on the network so long as the transformation from one representation to another is mechanical.

The issue I see with inter-operation is that, without an understanding that a node can speak an encoding, one has no idea how to start a conversation with a node.  I guess one could take a happy dtn eyeballs approach and just throw everything at the destination to see what sticks, but ... that seems like it could strain the network a bit.

With that said, if we want to add a capability negotiation component spoken in a common language with a common encoding, that might alleviate my concerns to some extent ... but I do think it'd be easier to just pick a common protocol and encoding which we expect border nodes to be able to speak and go with that instead.

At the risk of dooming my inbox to a relatively fast and violent death, what was the motivation for not electing to adopt support for a common encoding and convergence layer?  Note that this question is asked based on the assumption that the common encoding and convergence layer would not necessarily be used within one's own network, only that support for said common encoding and convergence layer would be *required* to exist in any BP-conformant implementation and used as a fallback in the case that the encoding or convergence layer adapter was not otherwise known.

>>	My recollection is that when we came up with the idea of separating representation specifications from the BP specification itself, the intent was -- precisely -- to let a simple Python (say) implementation of BP in a cloud to speak only JSON, without having to include code for a CBOR (or whatever) representation that it would never, ever use, while at the same time letting a C implementation in an embedded system speak only CBOR, without having to include code for a JSON representation that it would never, ever use -- and to enable both of them to be compliant to the standard, interoperating through a simple, mechanical representation translator.  It would open BP up to ready implementation in Internet applications while maintaining its usability in more constrained environments.
>>	I think this idea emerged in conversations at IETF93, and we reached consensus on it in the interim virtual meeting of August 28, 2016 (which you attended, according to the minutes).
>>	If I have got this wrong, and this is not the consensus of the Working Group, then I would appreciate it if someone else would speak up.

> As was pointed out in the early conversations on this topic, CBHE has for many years provided an existence proof of this.

Sorry, I think I missed that conversation - would you mind explaining this again or pointing me to a relevant thread?

>>	There was never an email thread on this; it was just noted in passing.  This is documented in the minutes of that August 28 interim virtual meeting.

> Likewise I wouldn't object to including non-normative references to one or more convergence-layer adapter specifications in the BP spec.  Again, we specifically do *not* want every conformant BP im…

My experience with 5050, though, says that I need to call / e-mail / etc. the people I want to talk to and ask them what convergence layers they're running.  From an implementation perspective, that's not bad - I don't mind.  From an inter-operability perspective, however, I don't think that's so great: the emphasis here should be on how I want to talk to someone I've *never met* without actually having to call them to ask them how to do it, not on how DTN should be designed and deployed in my own network.

>>	Sure, in terms of large-scale operability this is something that needs to be worked out, maybe using something ARP-like.  But ARP is quite separate from the specification for the Internet Protocol.

> Implementations are different from specifications.  Specifications have value in themselves, in isolation.  Implementations only have value if they can be demonstrated, and this is always only poss…

I'm not arguing that the scope of the BP specification is inappropriate by any means: I'm just arguing that other specifications should be included with it in order to tell a complete story.  People should be able to use this specifications to implement a complete version of the protocol.

In the end, though, I'm not necessarily the one who needs to be
convinced: the area directors and others involved in the approval of such a proposed standard are the ones whose opinions matter. Instead, what I'm doing here is trying to lay the groundwork for that
conversation: because based on experiences in other working groups, I'm pretty sure those examining the drafts outside of this WG would have similar types of questions or concerns.

I do feel guilty for being difficult here, but I also feel like we should have our ducks in a row before we start pushing these drafts up the chain for others outside our working group to review.

Cheers,
Gilbert

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Thu, 28 Apr 2016 21:01:24 +0000

Gilbert, I am totally with you on this last point: it would make much more sense (if possible) to publish the CBOR representation spec RFC at the same time as the BP RFC.  It's very brief, and in conversations to date it hasn't seemed especially controversial, so maybe this is doable?  I leave that up to our Chairs, though.

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of gclark mti-systems.com
Sent: Thursday, April 28, 2016 11:35 AM
To: Templin, Fred L <[email-masked]>; dtn <[email-masked]>
Subject: Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-03.txt

Hi Fred:

> > Well, okay, it does actually have protocol in its title ... but is 
> > still something completely different :)
> 
> I am not sure I see the difference. RFC4301 is one example of a 
> precedence that could be followed by other publications.

One difference is that the objectives of an architecture document is different than the objectives of a protocol document.  Normally, an architecture describes a way to do something in the abstract.  A protocol describes the mechanics of achieving an objective laid out in an architecture somewhere.  Thus, I doubt the content of one could reasonably be used as precedent to justify the content of the other.

no doubt correct me if I'm wrong :) was originally published as a companion to
2402 and 2406 (as evidenced by the way the three documents actually cite each other in the references).  As such, while the two are separate documents, they explain something that is part of a more coherent whole - 2401 explains a higher-level architecture, while 2402 and 2406 describe an implementation.
 Thus, the three documents *together* serve to define the standard being
proposed: no one of these three documents would be sufficient to achieve such a definition in and of itself.

Also, as far as I'm aware, the three documents referenced here were published simultaneously.  That is another difference here: we'll only be publishing a single RFC that will serve as an incomplete specification of the minimal pieces necessary to make the bundle protocol work between two different vendors.  We will not be advancing this draft as part of a *coherent collection* of documents necessary for someone to implement the protocol.  The continued existence of a working group is never guaranteed: if the working group (as an example - not asserting this would actually happen) were to be closed before the companion documents were published, there would forever be an RFC publicly available that described a standard which did not yet completely exist.

-Gilbert

---

From: Gilbert Clark <[email-masked]>
Date: Thu, 28 Apr 2016 20:18:27 -0400

Taking a step back from inline for a moment just to try to redirect a 
little bit here.  Also coalescing feedback from Scott's comment in 
another mail into this one.

I'm not opposed to layers.  I'm not opposed to defining different things 
in different places.  I actually like the idea that one would be able to 
swap encodings based on the implementation being constructed - this 
seems like a cool feature.  What I don't like is the idea that, based on 
the item (or items, assuming CBOR went with it) included with this 
submission, I could still think of cases where two conforming 
implementations of the bundle protocol standard documents as they exist 
now would not be able to talk to each other without first getting in 
touch with the other party out-of-band and asking them how their stuff 
is set up.  In my head, that defeats the purpose of having a standard in 
the first place.

For example, when considering IP, the idea is that any two 
implementations of IP that conform to that standard are able to work 
with each other without calling the other guy and asking them how their 
IP is set up.  When considering TCP, the same is true.  Sure, some 
protocols include capability negotiation ... but the negotiation is 
agreed upon and removes the necessity for operator involvement.  The 
lack of human involvement is key, and is something I believe the 
existing proposed standard here lacks in the following areas: the 
definition of *at least* one formally-defined CLA, the definition of *at 
least* one encoding, and the definition of an ability to, within a 
bundle, identify the way that bundle is encoded (*unless* the encoding 
is implemented as part of the CLA level rather than the BP level).

In other words, I don't see our proposed standard here as *only* BP.  
Instead, I see our proposed standard as an entire, coherent mini-stack, 
*including* at least one CLA and at least one encoding.

Which brings us to ...

 > it would make much more sense (if possible) to publish the CBOR 
representation spec RFC at the same time as the BP RFC.  It's very 
brief, and in conversations to date it hasn't seemed especially 
controversial, so maybe this is doable?  I leave that up to our Chairs, 
though.

Right ... but I'm going to go a little beyond that, even.  What I'm 
arguing is that, in order for the bundle protocol draft to qualify as 
part of a coherent proposed standard (where proposed standard in this 
case is a standalone sub-stack required for successful implementation of 
both a CLA and BP), we would need the following additional items to go 
up with it:

* One CLA specification
* One encoding specification (CBOR is fine)

Also, I believe we need EITHER:

* A document to codify a selection of a common encoding to be supported 
by *all* implementations

OR

* A common means to negotiate and / or identify which encoding is being 
used in a specific implementation

Regarding the encoding selection / identification: if said 
identification is just a byte at the beginning of the bundle that's 
mapped to a value we define in a registry somewhere, that's fine. If the 
identification is a MIME string identifying the encoding used by the 
bundle (with the expectation that the thing receiving the bundle will 
understand what MIME types are and how to use them), then that's great, 
too.  If we opt to go with a common encoding that must be supported by 
*everything*, then good.  In the end, the mechanics don't really matter 
(within reason) as long as one can decode a bundle without having to use 
out-of-band information to figure out how that bundle is encoded in the 
first place.

My concern about the CLA is slightly different: BP depends on the 
existence of at least one CLA to function and no CLA has ever been 
formally defined.  If the entire working group were tragically hit by a 
network of alien-controlled buses as part of an elaborate scheme to 
sabotage Earth's plans for the future of DTN, and this event occurred 
the day after we released our proposed standard, it would be nice if 
there weren't any huge gaps that existed in the standard we were proposing.

Having *no* CLA formally defined would constitute a pretty big gap, I 
think, which is why I feel like at least one CLA proposal should go up 
along with the other two as part of an initial, coherent proposed standard.

Hope this helps clarify my thoughts a bit.

Cheers,
Gilbert Clark

---

From: <[email-masked]>
Date: Fri, 29 Apr 2016 01:52:42 +0000 (UTC)

On what constitutes the stack with encodings and convergence
layer adapters, let's look at what was done previously by
DTNWG's predecessor DTNRG for the bundle protocol (v1).
 
RFC5050 was published November 2007. Most (90%+) bundle
traffic and experimentation ran over TCP/IP, because
that's what researchers had on their desks, well-documented,
easy to work with, etc. (which is also what researchers
were using way back when they were writing emails and
sending them via SMTP/TCP/IP claiming ATM was the next
big thing, but I digress.)
 
TCP convergence adapter for the bundle protocol?
A no-brainer.
 
RFC7242, specifying the TCP convergence layer,
was published in June 2014, almost seven years later.
(LTP/UDP was in RFC7122, slightly earlier - despite
LTP being defined in the earlier RFC5326. Very much
a top-down approach here.)
 
On encodings, RFC5050 depends on SDNVs. The formal
specification of that turned up in RFC6256, in May 2011,
three and a half years after RFC5050 was published.

Now, RFC5050 was experimental, and not the product of
an actual IETF WG, so maybe this sloppiness is okay
(and, in fact, it was continually stressed to me that
an RG is not a WG, and hey, sloppiness _was_ okay).
But when you're going for a proposed standard,
different expectations (should) apply.

And indeed they do. Look at BEEP core, which is
standards track, and which was issued with its
TCP mapping (convergence layer) at the same time.
RFC3080 and RFC3081. http://beepcore.org/doc.html
There haven't been any new transport mappings since,
due to lack of interest and/or demand, so rather lucky
they did that, eh?

There are your precedents.

L.

sabotaging the future of DTN has always been best
left to DTN groups. Decades of experience there.

Lloyd Wood [email-masked] http://about.me/lloydwood 

----- Original Message -----
From: Gilbert Clark <[email-masked]>
To: [email-masked]
Sent: Friday, 29 April 2016, 10:18
Subject: Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-03.txt

Which brings us to ...

* One CLA specification

OR

Cheers,

Gilbert Clark

---

From: Gilbert Clark <[email-masked]>
Date: Fri, 29 Apr 2016 09:50:22 -0400

Hi Lloyd:

So, if I read this correctly, we're in violent agreement regarding the 
documents that we believe should be present before we try to advance 
this as a proposed standard?

That does bring up another, more general WG question, though: is there a 
desire to re-use existing CLA specifications to support this updated BP 
draft?  If so, I believe we should select one of those and re-package it 
as a part of this proposed standard: as far as I know, the CLA RFCs were 
all experimental, weren't they?  Generally, I think it would be an issue 
to point people looking at implementing a proposed standard back at an 
*experimental* CLA RFC as part of their implementation.

So, what I'm going to tentatively suggest as a straw-man (chair(s), any 
thoughts here?) is that we (as a WG) target a batch publication of:

* An updated / reworked (as necessary) version of RFC 7122 to cover the 
CLA piece of this.
* The most up-to-date iteration of the bundle protocol draft, updated to 
include a way to identify the encoding used in a bundle
* A formal specification of an encoding (which I believe the existing 
CBOR draft to cover, though is not something I've yet had the time to 
review in any real depth)

... as a coherent proposed standard, in this case.  No single one of 
three items would be able to stand as a proposed standard on their own 
... but when considered *together*, I believe they could act as a 
coherent proposed standard, and would work to address the major concerns 
and / or gaps I was thinking existed in what we was proposed before.

-Gilbert

---

From: Keith Scott <[email-masked]>
Date: Fri, 29 Apr 2016 10:07:40 -0400

Gilbert,

I think I understand your points, and sort of agree with the intent, but I
think that in this case my mental model is slightly different.  You use IP
as an example; with IP you still have to agree 'out of band' on the link
and physical layers you're going to be using.  I view that similarly to the
BP / BeneathBP issue.  Maybe using your argument you wouldn't accept JUST
IP without at least one of (802.3, IP over DWDM, ...).  Yeah, I get that,
but it still seems at odds with allowing flexibility under BP.

I concur that we do need actual specifications for CLAs, but requiring that
there be ONE that everyone implements seems like it imposes what might be
some difficult and unnecessary requirements on implementations.  If I had a
space mission that did NOT use IP, for example, needing to implement say a
UDP CLA would be a burden.  (Not because it's difficult, or because it
would take a lot of resource, but there are concerns about even dead code
for flight software.)  The same kind of concern would come about if I were
designing sensors that used bluetooth or something else directly without IP
(ok, more of a stretch here, admittedly).

The simplest possible CLA would be (I think) one encoded bundle per UDP
datagaram.  Would including that as an example in the BPbis document be
enough?  It doesn't seem like it would warrant its own document and it
would/will probably be the closest thing to a de facto universal CLA.

  --keith

On Thu, Apr 28, 2016 at 8:18 PM, Gilbert Clark <[email-masked]>
wrote:

> little bit here.  Also coalescing feedback from Scott's comment in another
> mail into this one.
>
> swap encodings based on the implementation being constructed - this seems
> like a cool feature.  What I don't like is the idea that, based on the item
> (or items, assuming CBOR went with it) included with this submission, I
> could still think of cases where two conforming implementations of the
> bundle protocol standard documents as they exist now would not be able to
> talk to each other without first getting in touch with the other party
> out-of-band and asking them how their stuff is set up.  In my head, that
> defeats the purpose of having a standard in the first place.
>
> For example, when considering IP, the idea is that any two implementations
> of IP that conform to that standard are able to work with each other
> without calling the other guy and asking them how their IP is set up.  When
> considering TCP, the same is true.  Sure, some protocols include capability
> negotiation ... but the negotiation is agreed upon and removes the
> necessity for operator involvement.  The lack of human involvement is key,
> and is something I believe the existing proposed standard here lacks in the
> following areas: the definition of *at least* one formally-defined CLA, the
> definition of *at least* one encoding, and the definition of an ability to,
> within a bundle, identify the way that bundle is encoded (*unless* the
> encoding is implemented as part of the CLA level rather than the BP level).
>
> representation spec RFC at the same time as the BP RFC.  It's very brief,
> and in conversations to date it hasn't seemed especially controversial, so
> maybe this is doable?  I leave that up to our Chairs, though.
>
> arguing is that, in order for the bundle protocol draft to qualify as part
> of a coherent proposed standard (where proposed standard in this case is a
> standalone sub-stack required for successful implementation of both a CLA
> and BP), we would need the following additional items to go up with it:
>
> * One CLA specification
> * A document to codify a selection of a common encoding to be supported by
> *all* implementations
>
> OR
>
> Regarding the encoding selection / identification: if said identification
> is just a byte at the beginning of the bundle that's mapped to a value we
> define in a registry somewhere, that's fine. If the identification is a
> MIME string identifying the encoding used by the bundle (with the
> expectation that the thing receiving the bundle will understand what MIME
> types are and how to use them), then that's great, too.  If we opt to go
> with a common encoding that must be supported by *everything*, then good.
> In the end, the mechanics don't really matter (within reason) as long as
> one can decode a bundle without having to use out-of-band information to
> figure out how that bundle is encoded in the first place.
>
> existence of at least one CLA to function and no CLA has ever been formally
> defined.  If the entire working group were tragically hit by a network of
> alien-controlled buses as part of an elaborate scheme to sabotage Earth's
> plans for the future of DTN, and this event occurred the day after we
> released our proposed standard, it would be nice if there weren't any huge
> gaps that existed in the standard we were proposing.
>

---

From: Gilbert Clark <[email-masked]>
Date: Fri, 29 Apr 2016 10:50:23 -0400

Hi Keith:

On 04/29/2016 10:07 AM, Keith Scott wrote:
> Gilbert,
>
> I think I understand your points, and sort of agree with the intent, 
> but I think that in this case my mental model is slightly different.  
> You use IP as an example; with IP you still have to agree 'out of 
> band' on the link and physical layers you're going to be using.  I 
> view that similarly to the BP / BeneathBP issue.  Maybe using your 
> argument you wouldn't accept JUST IP without at least one of (802.3, 
> IP over DWDM, ...).  Yeah, I get that, but it still seems at odds with 
> allowing flexibility under BP.
>
> I concur that we do need actual specifications for CLAs, but requiring 
> that there be ONE that everyone implements seems like it imposes what 
> might be some difficult and unnecessary requirements on implementations.

Right.  I hear that, and I think I understand where that's coming from, 
so how about:

* at least one CLA *MUST* be formally specified somewhere, AND
* that in order to be considered to be a compliant implementation of the 
BP standard, said implementation *MUST* support at least one CLA 
specification that has actually been formally defined.

That is subtly different than arguing that there must be a common CLA 
shared by all BP implementations.  I would argue that this does *not* 
remove the need for a formal specification of a CLA to exist (which 
should facilitate inter-operation by interested parties) in order for a 
logical BP stack to be considered standards-compliant, but it *does* 
remove the need for any single *common* CLA to exist.

Is this a reasonable compromise?

> The simplest possible CLA would be (I think) one encoded bundle per 
> UDP datagaram.  Would including that as an example in the BPbis 
> document be enough?

 From a technical standpoint, sure, I think that'd be fine.  The 
important thing is to make sure something is there, as otherwise the 
lack of any specified CLA presents a gap in the standard being proposed.

 From a logical standpoint, I'm not so convinced.  There's a (very 
reasonable) argument that BP and the corresponding CLAs operate at 
completely different layers ... but the practical distinction there has 
always been a little fuzzy in my head.  Thus, it seems like dumping both 
BPbis and a reasonable CLA into a single, shared document could further 
confuse things.

With the above said, since there are already experimental BP CLA RFCs in 
existence (e.g. RFC 7122 and 7242), I'm thinking there's a strong 
argument to just make necessary changes to one of those and present that 
updated version as part of the proposed standard we're building here.

I don't think it's quite sufficient to just point at an experimental 
draft and include that as part of a proposed standard, though.

-Gilbert

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 29 Apr 2016 15:08:39 +0000

Okay.  I don't think this is necessary, but I also don't think it's a mistake, assuming it's feasible with the available resources.

There is one point that I think is a mistake, though: the BP specification must not be "updated to include a way to identify the encoding used in a bundle".  That's because the BP spec is encoding-independent, and any mechanism for identifying the encoding in use necessarily cannot be.  I agree that such a mechanism is needed (as was discussed at that August interim meeting), but it can't be part of BP and therefore it belongs in a separate document.  Fortunately we've got an Internet Draft already in the works that I think could easily be adapted to accomplish this: DTN IP Neighbor Discovery (IPND), draft-irtf-dtnrg-ipnd-03.

So four documents as a batch:
 
*	The current BP draft, already in last call.  (Adding language that says any compliant implementation MUST implement at least one documented CLA and at least one documented representation specification is fine with me.)
*	RFC 7122, with the LTP stuff removed (since we're not trying to standardize LTP at this point).  (I agree with you that having a separate document for this is better than including it in the BP specification.)
*	The CBOR representation specification.
*	The IPND I-D, adapted as necessary to identify encodings.

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Gilbert Clark
Sent: Friday, April 29, 2016 6:50 AM
To: [email-masked]
Subject: Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-03.txt

Hi Lloyd:

So, if I read this correctly, we're in violent agreement regarding the documents that we believe should be present before we try to advance this as a proposed standard?

That does bring up another, more general WG question, though: is there a desire to re-use existing CLA specifications to support this updated BP draft?  If so, I believe we should select one of those and re-package it as a part of this proposed standard: as far as I know, the CLA RFCs were all experimental, weren't they?  Generally, I think it would be an issue to point people looking at implementing a proposed standard back at an
*experimental* CLA RFC as part of their implementation.

So, what I'm going to tentatively suggest as a straw-man (chair(s), any thoughts here?) is that we (as a WG) target a batch publication of:

* An updated / reworked (as necessary) version of RFC 7122 to cover the CLA piece of this.
* The most up-to-date iteration of the bundle protocol draft, updated to include a way to identify the encoding used in a bundle
* A formal specification of an encoding (which I believe the existing CBOR draft to cover, though is not something I've yet had the time to review in any real depth)

... as a coherent proposed standard, in this case.  No single one of three items would be able to stand as a proposed standard on their own ... but when considered *together*, I believe they could act as a coherent proposed standard, and would work to address the major concerns and / or gaps I was thinking existed in what we was proposed before.

-Gilbert

On 04/28/2016 09:52 PM, [email-masked] wrote:
> On what constitutes the stack with encodings and convergence layer 
> adapters, let's look at what was done previously by DTNWG's 
> predecessor DTNRG for the bundle protocol (v1).
>   
> RFC5050 was published November 2007. Most (90%+) bundle traffic and 
> experimentation ran over TCP/IP, because that's what researchers had 
> on their desks, well-documented, easy to work with, etc. (which is 
> also what researchers were using way back when they were writing 
> emails and sending them via SMTP/TCP/IP claiming ATM was the next big 
> thing, but I digress.)
>   
> RFC7242, specifying the TCP convergence layer, was published in June 
> 2014, almost seven years later.
> (LTP/UDP was in RFC7122, slightly earlier - despite LTP being defined 
> in the earlier RFC5326. Very much a top-down approach here.)
>   
> On encodings, RFC5050 depends on SDNVs. The formal specification of 
> that turned up in RFC6256, in May 2011, three and a half years after 
> RFC5050 was published.
>
> Now, RFC5050 was experimental, and not the product of an actual IETF 
> WG, so maybe this sloppiness is okay (and, in fact, it was continually 
> stressed to me that an RG is not a WG, and hey, sloppiness _was_ 
> okay).
> But when you're going for a proposed standard, different expectations 
> (should) apply.
>
> And indeed they do. Look at BEEP core, which is standards track, and 
> which was issued with its TCP mapping (convergence layer) at the same 
> time.
> RFC3080 and RFC3081. http://beepcore.org/doc.html There haven't been 
> any new transport mappings since, due to lack of interest and/or 
> demand, so rather lucky they did that, eh?
>
> sabotaging the future of DTN has always been best left to DTN groups. 
> Decades of experience there.
>
> I'm not opposed to layers.  I'm not opposed to defining different 
> things in different places.  I actually like the idea that one would 
> be able to swap encodings based on the implementation being 
> constructed - this seems like a cool feature.  What I don't like is 
> the idea that, based on the item (or items, assuming CBOR went with 
> it) included with this submission, I could still think of cases where 
> two conforming implementations of the bundle protocol standard 
> documents as they exist now would not be able to talk to each other 
> without first getting in touch with the other party out-of-band and 
> asking them how their stuff is set up.  In my head, that defeats the 
> purpose of having a standard in the first place.
>
> with each other without calling the other guy and asking them how 
> their IP is set up.  When considering TCP, the same is true.  Sure, 
> some protocols include capability negotiation ... but the negotiation 
> is agreed upon and removes the necessity for operator involvement.  
> The lack of human involvement is key, and is something I believe the 
> controversial, so maybe this is doable?  I leave that up to our 
> Chairs, though.
>
> case is a standalone sub-stack required for successful implementation 
> of both a CLA and BP), we would need the following additional items to 
> go up with it:
>
> * One CLA specification
> * A document to codify a selection of a common encoding to be 
> supported by *all* implementations
>
> OR
>
> * A common means to negotiate and / or identify which encoding is 
> being used in a specific implementation
>
> mapped to a value we define in a registry somewhere, that's fine. If 
> the identification is a MIME string identifying the encoding used by 
> the bundle (with the expectation that the thing receiving the bundle 
> will understand what MIME types are and how to use them), then that's 
> great, too.  If we opt to go with a common encoding that must be 
> supported by *everything*, then good.  In the end, the mechanics don't 
> really matter (within reason) as long as one can decode a bundle 
> without having to use out-of-band information to figure out how that 
> bundle is encoded in the first place.
>
> formally defined.  If the entire working group were tragically hit by 
> a network of alien-controlled buses as part of an elaborate scheme to

---

From: Gilbert Clark <[email-masked]>
Date: Fri, 29 Apr 2016 12:08:15 -0400

Sure, I'm happy with this.  Other list folks / chairs - does this seem 
like a reasonable path?

Regarding resources, I'll volunteer to make changes I believe to be 
necessary to 7122 and turn it into an updated draft, since I'm the one 
who proposed we move that forward as part of this logical bundle of 
documents.

Also, Scott / Keith / Lloyd / Fred - thank you for taking the time to 
discuss / work through the concerns I raised.  I may yet find myself 
with a few other technical issues to discuss with respect to bpbis, but 
the lack of an apparent path (in my head) to a *coherent specification* 
was absolutely my biggest concern as this draft entered last call with 
"proposed standard" status attached.

-Gilbert

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 29 Apr 2016 16:37:06 +0000

Hi Gilbert,

> Sent: Friday, April 29, 2016 9:08 AM
> To: [email-masked]

It sounds reasonable, but one thing that would not seem reasonable would
be to delay publications until any and all convergence layers are specified.
That is why RFC0791 was published with ARPAnet as the simple example
link layer but without first including detailed specs of IP over Ethernet,
FDDI, etc. which came later in standalone "IP-over-(foo)" specs for which
new examples are still being published today. It seems like the model
should be similar for the Bundle Protocol.

Thanks - Fred

> > There is one point that I think is a mistake, though: the BP specification must not be "updated to include a way to identify the
> encoding used in a bundle".  That's because the BP spec is encoding-independent, and any mechanism for identifying the encoding in
> use necessarily cannot be.  I agree that such a mechanism is needed (as was discussed at that August interim meeting), but it can't be
> part of BP and therefore it belongs in a separate document.  Fortunately we've got an Internet Draft already in the works that I think
> could easily be adapted to accomplish this: DTN IP Neighbor Discovery (IPND), draft-irtf-dtnrg-ipnd-03.
> >
> > *	The current BP draft, already in last call.  (Adding language that says any compliant implementation MUST implement at least
> one documented CLA and at least one documented representation specification is fine with me.)
> > *	RFC 7122, with the LTP stuff removed (since we're not trying to standardize LTP at this point).  (I agree with you that having a
> separate document for this is better than including it in the BP specification.)
> > That does bring up another, more general WG question, though: is there a desire to re-use existing CLA specifications to support this
> updated BP draft?  If so, I believe we should select one of those and re-package it as a part of this proposed standard: as far as I know,
> the CLA RFCs were all experimental, weren't they?  Generally, I think it would be an issue to point people looking at implementing a
> proposed standard back at an
> > ... as a coherent proposed standard, in this case.  No single one of three items would be able to stand as a proposed standard on
> their own ... but when considered *together*, I believe they could act as a coherent proposed standard, and would work to address
> the major concerns and / or gaps I was thinking existed in what we was proposed before.
> >
> > -Gilbert
> >

---

From: Gilbert Clark <[email-masked]>
Date: Fri, 29 Apr 2016 13:03:49 -0400

Hi Fred:

> be to delay publications until any and all convergence layers are specified.

Before this discussion goes any further, let's be clear about the scope: 
we're not talking about delaying publication until "any and all 
convergence layers" are specified here, we are discussing only delaying 
publication until we just have *one*.

It doesn't really matter which one ... though I'm admittedly a fan of 
the datagram CLA in this instance because I believe it to be the most 
straightforward and easiest to implement, and we already have an 
experimental-stage RFC that exists which effectively does what we want - 
it just needs some editing to slim it down to the pieces we're worried 
about actually trying to standardize.

> should be similar for the Bundle Protocol.

Right.  I'm definitely not arguing we should wait for *all* of them, I'm 
just saying wait for *one*.  The same thing goes for encodings: we 
specify one example encoding to push up the stack, include a reference 
to that in the dtn ipnd draft, include our one example convergence 
layer, and viola: we can trace a path from IP all the way up to our 
shiny new protocol.

-Gilbert

---

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Fri, 29 Apr 2016 17:13:06 +0000

>about actually trying to standardize.

I highly recommend the TCP CLA.  That is the one 90+ percent of any
additional work will use.

‹ Will

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 29 Apr 2016 18:16:10 +0100

> additional work will use.

Tend to agree. I think Lloyd was correct in saying that's what almost
all previous experiments with the BP used. And I think it's also the
CLA that most BP implementations first used for interop.

S.

---

From: Gilbert Clark <[email-masked]>
Date: Fri, 29 Apr 2016 13:16:19 -0400

This also works for me :)

-Gilbert

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 29 Apr 2016 17:23:55 +0000

I disagree: it is certainly true that the TCP CLA will be more useful, but it is also much more complex.  It has several significant errors that need to be fixed (I just spent the last couple of months implementing and debugging it, not a pleasant experience), and as such it will add significant further delay to the publication of any DTN RFCs.  For the purposes we have been discussing, a datagram CLA is sufficient.

That said, I am confident that my opinion will remain in the minority.  I expect we will press ahead with the TCP CLA, slipping publication of anything at all into 2017.  But hey, we've got nothing but time.

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Gilbert Clark
Sent: Friday, April 29, 2016 10:16 AM
To: [email-masked]
Subject: Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-03.txt

-Gilbert

On 04/29/2016 01:13 PM, Ivancic, William D. (GRC-LCA0) wrote:
>> experimental-stage RFC that exists which effectively does what we 
>> want - it just needs some editing to slim it down to the pieces we're 
>> worried about actually trying to standardize.
> < Will

---

From: "Marc Blanchet" <[email-masked]>
Date: Fri, 29 Apr 2016 13:37:43 -0400

On 29 Apr 2016, at 13:23, Burleigh, Scott C (312B) wrote:

> I disagree: it is certainly true that the TCP CLA will be more useful, 
> but it is also much more complex.  It has several significant errors 
> that need to be fixed (I just spent the last couple of months 
> implementing and debugging it, not a pleasant experience), and as such 
> it will add significant further delay to the publication of any DTN 
> RFCs.  For the purposes we have been discussing, a datagram CLA is 
> sufficient.

I somewhat agree with Scott. For DTN, the layer below should be very 
basic as a datagram. This is really what makes sense, what is close to 
reality in any envisioned dtn deployments. So I would vote for UDP 
Convergence layer as the first/mandatory one.

Marc.

>
> That said, I am confident that my opinion will remain in the minority. 
>  I expect we will press ahead with the TCP CLA, slipping publication 
> of anything at all into 2017.  But hey, we've got nothing but time.
>
> Scott
>

---

From: Eric Travis <[email-masked]>
Date: Fri, 29 Apr 2016 13:39:41 -0400

Hi Fred,

Since this is an IETF working group, surely it is reasonable to delay the
publication until *at least* there is defined ONE standard (agreed upon)
way to use RFC5050bis over IP?

The rationale for such a delay is to make sure it happens in a timely
manner.  This should have
been included in the WG charter (it was suggested).

The publication of the TCP and UDP CLA documents (RFC 7242 and 7122) were
pretty much the LAST work items of the DTNRG prior to going unofficially
dormant.  This was six (6) years after the publication of RFC 5050. An
incentive is not a bad idea.

RFC 7242 provides at the very least critical mass for what is required.

This is not a big or unreasonable hurdle.

Eric

On Fri, Apr 29, 2016 at 12:37 PM, Templin, Fred L <[email-masked]

> > > Okay.  I don't think this is necessary, but I also don't think it's a
> mistake, assuming it's feasible with the available resources.
> > >
> > > There is one point that I think is a mistake, though: the BP
> specification must not be "updated to include a way to identify the
> > encoding used in a bundle".  That's because the BP spec is
> encoding-independent, and any mechanism for identifying the encoding in
> > use necessarily cannot be.  I agree that such a mechanism is needed (as
> was discussed at that August interim meeting), but it can't be
> > part of BP and therefore it belongs in a separate document.  Fortunately
> we've got an Internet Draft already in the works that I think
> > > *   The current BP draft, already in last call.  (Adding language that
> says any compliant implementation MUST implement at least
> > > *   RFC 7122, with the LTP stuff removed (since we're not trying to
> standardize LTP at this point).  (I agree with you that having a
> documents that we believe should be present before we try to
> > advance this as a proposed standard?
> > >
> > > That does bring up another, more general WG question, though: is there
> a desire to re-use existing CLA specifications to support this
> > updated BP draft?  If so, I believe we should select one of those and
> re-package it as a part of this proposed standard: as far as I know,
> > the CLA RFCs were all experimental, weren't they?  Generally, I think it
> would be an issue to point people looking at implementing a
> > > So, what I'm going to tentatively suggest as a straw-man (chair(s),
> any thoughts here?) is that we (as a WG) target a batch
> > publication of:
> > >
> > > * The most up-to-date iteration of the bundle protocol draft, updated
> to include a way to identify the encoding used in a bundle
> CBOR draft to cover, though is not something I've yet had the
> > time to review in any real depth)
> > >
> three items would be able to stand as a proposed standard on
> > their own ... but when considered *together*, I believe they could act
> as a coherent proposed standard, and would work to address

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 29 Apr 2016 17:47:57 +0000

I agree with Marc and Scott - datagram convergence layer. It should be
as simple as possible.

Thanks - Fred

From: dtn [mailto:[email-masked]] On Behalf Of Marc Blanchet
Sent: Friday, April 29, 2016 10:38 AM
To: Burleigh, Scott C <[email-masked]>
Cc: Gilbert Clark <[email-masked]>; [email-masked]
Subject: Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-03.txt

I somewhat agree with Scott. For DTN, the layer below should be very basic as a datagram. This is really what makes sense, what is close to reality in any envisioned dtn deployments. So I would vote for UDP Convergence layer as the first/mandatory one.

Marc.

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Gilbert Clark
Sent: Friday, April 29, 2016 10:16 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-03.txt

-Gilbert

< Will

________________________________

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

________________________________

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

________________________________

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

---

From: Gilbert Clark <[email-masked]>
Date: Fri, 29 Apr 2016 13:54:02 -0400

Well ... I'm kind of scared to say this, but another alternative here 
would be to talk about taking both.  Since they both already exist in 
RFC form, but are both flagged as experimental, would it be an excessive 
amount of work to massage them into something we could push up as a pair?

Basically, since I'm the one who started the conversation here, I can 
take the lead on one of them if someone else would like to volunteer to 
take on the other.  We're talking about some pretty quick edits here, I 
think ... get the draft up, take out the bits that don't fit, make sure 
it still makes sense in terms of the new BP, and put a stamp on it if 
so.  There is overhead that will come in the review, but ... since these 
already exist, I don't think it makes sense to radically rewrite them in 
the same way that the actual bundle protocol was. That's not to say, of 
course, someone wouldn't come along and decide to rewrite them later ... 
just that I don't think it makes sense to do that kind of thing now.

New construction is what would take a substantial effort with CLAs, I 
think.  I also agree with Scott that LTP should not be included, and I 
also think we should consider that (if we move 7122 forward) we drop 
DCCP from that draft as well.  It was a good experimental push, but I 
don't think DCCP implementation is widespread enough to justify the 
effort involved with trying to standardize on that at this particular 
moment.

-Gilbert

On 04/29/2016 01:37 PM, Marc Blanchet wrote:
>     I disagree: it is certainly true that the TCP CLA will be more
>     useful, but it is also much more complex. It has several
>     significant errors that need to be fixed (I just spent the last
>     couple of months implementing and debugging it, not a pleasant
>     experience), and as such it will add significant further delay to
>     the publication of any DTN RFCs. For the purposes we have been
>     discussing, a datagram CLA is sufficient.
>
>     That said, I am confident that my opinion will remain in the
>     minority. I expect we will press ahead with the TCP CLA, slipping
>     publication of anything at all into 2017. But hey, we've got
>     nothing but time.
>
>     Scott
>
>     From: dtn [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of Gilbert Clark
>     To: [email-masked] <mailto:[email-masked]>
>         ------------------------------------------------------------------------
>
>         dtn mailing list
>         [email-masked] <mailto:[email-masked]>
>     ------------------------------------------------------------------------
>
>     dtn mailing list
>     [email-masked] <mailto:[email-masked]>
>     ------------------------------------------------------------------------
>
>     dtn mailing list
>     [email-masked] <mailto:[email-masked]>

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 29 Apr 2016 17:57:12 +0000

BP-over-UDP in my opinion is all that is needed for now. BP-over-(foo) for any
other value of (foo) can come later.

Thanks - Fred

From: dtn [mailto:[email-masked]] On Behalf Of Gilbert Clark
Sent: Friday, April 29, 2016 10:54 AM
To: [email-masked]
Subject: Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-03.txt

Well ... I'm kind of scared to say this, but another alternative here would be to talk about taking both.  Since they both already exist in RFC form, but are both flagged as experimental, would it be an excessive amount of work to massage them into something we could push up as a pair?

Basically, since I'm the one who started the conversation here, I can take the lead on one of them if someone else would like to volunteer to take on the other.  We're talking about some pretty quick edits here, I think ... get the draft up, take out the bits that don't fit, make sure it still makes sense in terms of the new BP, and put a stamp on it if so.  There is overhead that will come in the review, but ... since these already exist, I don't think it makes sense to radically rewrite them in the same way that the actual bundle protocol was. That's not to say, of course, someone wouldn't come along and decide to rewrite them later ... just that I don't think it makes sense to do that kind of thing now.

New construction is what would take a substantial effort with CLAs, I think.  I also agree with Scott that LTP should not be included, and I also think we should consider that (if we move 7122 forward) we drop DCCP from that draft as well.  It was a good experimental push, but I don't think DCCP implementation is widespread enough to justify the effort involved with trying to standardize on that at this particular moment.

-Gilbert

Marc.

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Gilbert Clark
Sent: Friday, April 29, 2016 10:16 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-03.txt

-Gilbert

< Will

dtn mailing list

dtn mailing list

dtn mailing list

dtn mailing list

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 29 Apr 2016 18:00:31 +0000

>>           Yes, of course it would.  TCPCL is broken.  It will require repairs, which will require discussion.  It can't simply be transcribed from the existing RFC.

>>           That's fine with me, as long as we don't have to listen to anybody whinging about how BP/UDP can't be operational on the Internet because there's no congestion control.

-Gilbert

Marc.

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Gilbert Clark
Sent: Friday, April 29, 2016 10:16 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-03.txt

-Gilbert

< Will

dtn mailing list

dtn mailing list

dtn mailing list

dtn mailing list

---

From: Gilbert Clark <[email-masked]>
Date: Fri, 29 Apr 2016 14:10:02 -0400

On 04/29/2016 02:00 PM, Burleigh, Scott C (312B) wrote:
>
> *From:*dtn [mailto:[email-masked]] *On Behalf Of *Gilbert Clark
> *Sent:* Friday, April 29, 2016 10:54 AM
> *To:* [email-masked]
> *Subject:* Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-03.txt
>
> RFC form, but are both flagged as experimental, would it be an 
> excessive amount of work to massage them into something we could push 
> up as a pair?
>
> >>Yes, of course it would.  TCPCL is broken.  It will require repairs, 
> which will require discussion.  It can’t simply be transcribed from 
> the existing RFC.
>

Ah, okay.  Honestly, I hadn't read the specification of the TCP CL 
closely enough to understand that - my experience with TCPCL has been 
pretty applied (read: does ION's implementation seem to work well enough 
to pass bundles back and forth).

So, how about this revised idea, then: we *start* down the 
standardization path for both.  The first to make it through last call 
will go up with the other documents, with the expectation that the later 
of the two will be published as soon as the working group can achieve 
consensus on which repairs should be made.

The rationale for this is that BP *can* operate over either a UDP CLA or 
a TCP CLA.  I hear and believe the argument that TCP might have more 
widespread applicability ... but I'd be hesitant to slip too far down 
the other path of waiting too long to get *everything* perfect before we 
published *any* of it.

Realistically, I'm not convinced we have the resources to do that and 
still achieve reasonable milestones, but ... if someone wants to prove 
me wrong, that's perfectly okay too :)

-Gilbert

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 29 Apr 2016 18:13:34 +0000

?  So, how about this revised idea, then: we *start* down the standardization path for both.

Two is one too many - too many moving parts, and too much consumption
of engineering manpower needed to move the other documents forward.

Thanks - Fred

From: dtn [mailto:[email-masked]] On Behalf Of Gilbert Clark
Sent: Friday, April 29, 2016 11:10 AM
To: [email-masked]
Subject: Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-03.txt

>>           Yes, of course it would.  TCPCL is broken.  It will require repairs, which will require discussion.  It can't simply be transcribed from the existing RFC.

Ah, okay.  Honestly, I hadn't read the specification of the TCP CL closely enough to understand that - my experience with TCPCL has been pretty applied (read: does ION's implementation seem to work well enough to pass bundles back and forth).

So, how about this revised idea, then: we *start* down the standardization path for both.  The first to make it through last call will go up with the other documents, with the expectation that the later of the two will be published as soon as the working group can achieve consensus on which repairs should be made.

The rationale for this is that BP *can* operate over either a UDP CLA or a TCP CLA.  I hear and believe the argument that TCP might have more widespread applicability ... but I'd be hesitant to slip too far down the other path of waiting too long to get *everything* perfect before we published *any* of it.

Realistically, I'm not convinced we have the resources to do that and still achieve reasonable milestones, but ... if someone wants to prove me wrong, that's perfectly okay too :)

-Gilbert

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 29 Apr 2016 18:12:46 +0000

Sure, that makes sense.  We should be starting on the standardization path for both CLAs anyway.

Scott

-Gilbert

---

From: "Marc Blanchet" <[email-masked]>
Date: Fri, 29 Apr 2016 14:19:05 -0400

On 29 Apr 2016, at 14:10, Gilbert Clark wrote:

>> >>Yes, of course it would.  TCPCL is broken.  It will require 
>> repairs, which will require discussion.  It can’t simply be 
>> transcribed from the existing RFC.
>>
>
> pretty applied (read: does ION's implementation seem to work well 
> enough to pass bundles back and forth).
>
> will go up with the other documents, with the expectation that the 
> later of the two will be published as soon as the working group can 
> achieve consensus on which repairs should be made.

<co-chair hat>
while pragmatic as it sounds, as a co-chair, I disagree. We are not 
making standards based on racing documents in the pipeline. We need to 
create technical specs and standards based on technical arguments.
</co-chair hat>

<individual>
While we have great many years of experience from DTNRG, we should at 
the same time take that experience into account and sometimes not take 
conclusions, because, again, the DTNRG was a research group.  To me, the 
fact that some CL documents took a long time or not is almost irrelevant 
to the discussion, unless there are technical arguments behind this.

to me, UDP is the real necessary one, because it is the closest to the 
effective dtn deployments but at the same time well identified transport 
and straightforward to implement, interop and technically sound for BP. 
Everything else shall be optional and done as needed.
</individual>

Marc.

>
> The rationale for this is that BP *can* operate over either a UDP CLA 
> or a TCP CLA.  I hear and believe the argument that TCP might have 
> more widespread applicability ... but I'd be hesitant to slip too far 
> down the other path of waiting too long to get *everything* perfect 
> before we published *any* of it.
>

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 29 Apr 2016 18:21:51 +0000

Fred, I hear what you're saying and I agree, but starting down the standardization path is what we've been doing with bpsec and other thrusts all along.  It needs to happen for TCPCL at some point anyway; as long as completion of that work isn't a precondition for moving anything else forward, and as long as we've got enough cycles being devoted to the things that are, I think letting people begin work on TCPCL who are interested in it is a good thing.  As Marc says, "optional and done as needed."

Scott

From: dtn [mailto:[email-masked]] On Behalf Of Templin, Fred L
Sent: Friday, April 29, 2016 11:14 AM
To: Gilbert Clark <[email-masked]>; [email-masked]
Subject: Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-03.txt

Thanks - Fred

-Gilbert

---

From: "gclark mti-systems.com" <[email-masked]>
Date: Fri, 29 Apr 2016 14:43:21 -0400 (EDT)

Addressing the co-chair:

My technical argument here would be that the suitability of each depends on
where you're sitting: UDP, while simple, might be useless to some, whereas TCP
might be just the right mix of complexity and capability to serve as a place to
start.  Thus, I would argue that both are useful, and that both are eventually
needed ... but that only *one* of the two is needed to make this a proposed
spec, per se.  Thus, the selection of which one actually makes it in strikes me
as kind of a wash.

So, let's revise my suggestion: we do UDP unconditionally, and do TCP
conditionally subject to a cutoff.  The rationale here would be that TCP has a
longer way to go and BP can actually work just fine without it ... but it's
applicable to enough people that it would be good to push it up as part of the
basic standard bundle if the WG could rally and get it done.

-Gilbert

> On April 29, 2016 at 2:19 PM Marc Blanchet <[email-masked]> wrote:
> 
> 
> 
>

---

From: Eric Travis <[email-masked]>
Date: Fri, 29 Apr 2016 15:17:41 -0400

Marc,

While we have great many years of experience from DTNRG, we should at the
> same time take that experience into account and sometimes not take
> fact that some CL documents took a long time or not is almost irrelevant to
> the discussion, unless there are technical arguments behind this.
>

As this is email, I am likely misinterpreting your tone, so I offer a
preemptive conditional apology.  Regardless...

The lesson to be learned from the DTNRG relevant to the CLA documents *is*
why they
took so long - BECAUSE they weren't critical path to getting RFC 5050
published.  Everyone
agreed they were important, but cycles were used for more interesting
activities. The DTNRG
was a research group and RFC5050 was an experimental RFC, so is didn't
really matter.

As to going the simple datagram CLA path for this WG, it seems like a
smart/easy move except
as Gilbert pointed out - the lack of congestion avoidance...

Actually, a BIGGER problem is that the underlying assumption of BP has
always been that the bundles are reliably transferred between bundle nodes
(bundle agents?  whatever).  While I happen to believe that relaxing this
assumption would make the BP far more robust and useful it is
really not an option in this group.

Since the TCP CLA documented in RFC 7242 is unimplementable (I trust in
Scott's abilities), perhaps the prudent path is choosing to provide a CLA
that is built upon a TCP-based reliable messaging service?   I
un-ironically suggest considering BEEP over TCP (RFC 3081). Not having
looked at it since the days of the IPNRG, it will probably turn out to be
inappropriate for this WG's needs.

Alternatively, people have seemed to be happy using the TCP implementations
in ION and DTN2
for a decade or so, Creating a document based on those implementations
might be sufficient for the short term need.

Finally, For What It Is Worth: RFC7242 provides another object lesson from
the DTNRG - ensure that an RFC is implementable prior to publishing (even
more so for a proposed standard).  Gilbert raised this as a desirable trait
earlier in this thread,  but it didn't seem to be an attractive idea.

Regards,

Eric

On Fri, Apr 29, 2016 at 2:19 PM, Marc Blanchet <[email-masked]>
wrote:

> *From:*dtn [mailto:[email-masked] <[email-masked]>] *On Behalf
> Of *Gilbert Clark *Sent:* Friday, April 29, 2016 10:54 AM
> *To:* [email-masked]
> would be to talk about taking both. Since they both already exist in RFC
> form, but are both flagged as experimental, would it be an excessive amount
> of work to massage them into something we could push up as a pair?
>
> Yes, of course it would. TCPCL is broken. It will require repairs, which
> will require discussion. It can’t simply be transcribed from the existing
> RFC.
>
> Ah, okay. Honestly, I hadn't read the specification of the TCP CL closely
> enough to understand that - my experience with TCPCL has been pretty
> applied (read: does ION's implementation seem to work well enough to pass
> bundles back and forth).
>
> standardization path for both. The first to make it through last call will
> go up with the other documents, with the expectation that the later of the
> two will be published as soon as the working group can achieve consensus on
> which repairs should be made.
>
> <co-chair hat>
> while pragmatic as it sounds, as a co-chair, I disagree. We are not making
> standards based on racing documents in the pipeline. We need to create
> technical specs and standards based on technical arguments.
> </co-chair hat>
>
> <individual>
> While we have great many years of experience from DTNRG, we should at the
> same time take that experience into account and sometimes not take
> fact that some CL documents took a long time or not is almost irrelevant to
> the discussion, unless there are technical arguments behind this.
>
> widespread applicability ... but I'd be hesitant to slip too far down the
> other path of waiting too long to get *everything* perfect before we
> published *any* of it.
>
> still achieve reasonable milestones, but ... if someone wants to prove me
> wrong, that's perfectly okay too :)
>
> -Gilbert
> ------------------------------
>
> dtn mailing list
> [email-masked]

---

From: Keith Scott <[email-masked]>
Date: Fri, 29 Apr 2016 15:39:15 -0400

Hmmm...  So as far as the CLA question goes, you're saying that in order
for the spec to move forward there has to be *A* CLA definition, and any
(later) BPbis implementation claiming compliance has to include compliance
with *SOME* specified CLA?  Would you accept (for a later BPbis impl.) a
CLA specified by the Consultative Committee for space Data Systems
(CCSDS)?  I'm thinking in particular a CCSDS 'Blue Book' which has roughly
the same longevity / rigor as an RFC.  I'd like for the space community to
be able to use 5050bis in conjunction (possibly) with a CLA adapted to a
space-specific link layer that might not see the light of day in the IETF.

Seems reasonable to me.

It does mix things a bit (IMHO) to conflate CLA and BP in a single
document.  From a quick read I'd concur that at least 7122 seems like it
could be directly applied to 5050bis.  I see your point about 7122 being
experimental from a purist standpoint, but given that 7122 exists, and
given that there will probably be a desire to do a new / better TCPCL (and
probably others), is it worth holding up BP for it?  In my opinion 7122
applied to 5050bis would be sufficient.

    --keith

On Fri, Apr 29, 2016 at 10:50 AM, Gilbert Clark <[email-masked]>
wrote:

>> I think I understand your points, and sort of agree with the intent, but
>> I think that in this case my mental model is slightly different.  You use
>> IP as an example; with IP you still have to agree 'out of band' on the link
>> that there be ONE that everyone implements seems like it imposes what might
>> be some difficult and unnecessary requirements on implementations.
>>
>
> Right.  I hear that, and I think I understand where that's coming from, so
> how about:
>
> remove the need for a formal specification of a CLA to exist (which should
> facilitate inter-operation by interested parties) in order for a logical BP
> stack to be considered standards-compliant, but it *does* remove the need
> for any single *common* CLA to exist.
>
>> enough?
> From a technical standpoint, sure, I think that'd be fine.  The important
> thing is to make sure something is there, as otherwise the lack of any
> specified CLA presents a gap in the standard being proposed.
>
> existence (e.g. RFC 7122 and 7242), I'm thinking there's a strong argument
> to just make necessary changes to one of those and present that updated
> version as part of the proposed standard we're building here.
>
> I don't think it's quite sufficient to just point at an experimental draft
> and include that as part of a proposed standard, though.
>
> -Gilbert
>
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 29 Apr 2016 21:39:52 +0100

> as Gilbert pointed out - the lack of congestion avoidance...

Right. That could be a bit tricky too, depending on what one considers
might happen to the UDP packets, e.g., I don't myself know if simply
saying "use TFRC" would be considered sufficient in a DTN. (It would
be good enough for me, but I'm no transport purist:-) I would bet a
beer though that that question will need to be answered to get a
standards-track UDPCL through the process.

I'd also be interested if Scott could document the issues he found
with the TCPCL. If that assertion is the main basis for picking UDP
over TCP then it seems fair to ask for that. If OTOH the main argument
is that UDP is simpler and sufficient then documenting the problems
with the TCPCL isn't needed now (but would be interesting of course.)

All that said, UDPCL + a good-enough answer about congestion is a
totally reasonable choice for the WG to make, though I'd still argue
that a TCPCL will be used more often so would be more useful.

Doing some initial research on what transport folks might expect is
needed for such a good-enough answer for UDP congestion control in a
DTN would seem prudent though - that could be really simple or it
might be really complex, I'm just not sure. If the latter applies,
then the TCPCL will I bet become more attractive;-)

Cheers,
S.

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 29 Apr 2016 21:31:08 +0000

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Friday, April 29, 2016 1:40 PM
To: Eric Travis; Marc Blanchet
Cc: Gilbert Clark; [email-masked]
Subject: Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-03.txt

>	...
>	I'd also be interested if Scott could document the issues he found with the TCPCL. If that assertion is the main basis for picking UDP over TCP then it seems fair to ask for that. If OTOH the main argument is that UDP is simpler and sufficient then documenting the problems with the TCPCL isn't needed now (but would be interesting of course.)

Of course, absolutely fair.  The context for this is that we were implementing TCPCL specifically to deal with the case of a TCP connection being spontaneously lost -- machine rebooted, cable was cut, whatever -- without TCP having had the opportunity to signal the failure.  Here's what I found.

First, the intended operation of LENGTH messages depends on the implementation of REFUSE_BUNDLE messages (1st paragraph of 5.5), but in the general case it is impossible to implement the REFUSE_BUNDLE feature correctly at the bundle sender.

The reason bundle refusal cannot in general be implemented correctly at the bundle sender is that bundles over the TCPCL connection may be pipelined (6th paragraph of 3.0, 2nd paragraph of 3.2).  Since bundles can be pipelined, it is possible for all segments of bundles X and X+1, and the first N segments of bundle X+2, to have been transmitted by the time the sending node receives a BUNDLE_REFUSAL message for message X.

Suppose the receiving node sent a BUNDLE_REFUSAL upon reception of the first segment of bundle X.  The sending node can keep a record of transmitted bundles that have not yet been fully acknowledged, so it knows the unacknowledged oldest bundle and can properly apply the refusal to that bundle.  It can respond correctly to this refusal message by reforwarding bundle X or whatever, depending on the refusal message’s reason code.  No problem.

However, bundle X might have been transmitted in, say, 3 segments.  The 6th paragraph of section 5.4 says that the receiving node SHOULD (but is not required to) refuse the other two segments of bundle X – which were placed in the pipeline long ago – in the same way.  Suppose it does so.  Now the sending node receives two additional BUNDLE_REFUSAL messages.  However, there is no bundle identifier in the BUNDLE_REFUSAL message; the second refusal message might be a refusal of the second segment of bundle X, or it might alternatively be a refusal of the first segment of bundle X+1.  Both behaviors are conformant.  The sending node has no way of distinguishing between the two, so it might erroneously determine that bundles X+1 and X+2 were refused.

There’s a problem with acknowledgments too.  Again, pipelining is the issue.  When an acknowledgment of a TCPCL data segment message arrives it notes the total bundle length received so far.  Clearly, if this length is less than the length previously reported – and the previous ACK didn’t acknowledge the tail end of a bundle – there has been a transmission failure and the bundle that was previously being acknowledged did not arrive and must be retransmitted; the new acknowledgment is acknowledging the next bundle for which it has received data.  But how many bundles immediately following that lost bundle also didn’t arrive (and were not acknowledged)?  Which of those subsequently transmitted bundles is now being acknowledged?  We have no way of knowing, because there are no bundle identifiers in acknowledgment messages.

A last point, which isn't such a big deal: the “request enabling of reactive fragmentation” flag doesn’t actually do anything.  Reactive fragmentation isn’t defined anywhere; not in RFC 7242, and not in RFC 5050.  There is no formal definition anywhere of how to do it, there is no procedure anywhere in TCPCL that depends on it, and there is no definition in RFC 7242 of what is intended when the two ends of a TCPCL connection agree to enable it.  So the operation of the flag can't actually be implemented from the specification.

Scott

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 29 Apr 2016 22:57:34 +0100

Thanks. That's convinced me that that'll need fixing regardless of
whether the TCPCL is the 1st or last CL done.

Cheers,
S

---

From: Gilbert Clark <[email-masked]>
Date: Fri, 29 Apr 2016 18:07:42 -0400

> might be really complex, I'm just not sure.

The relevant RFC of which I'm aware is 5405 - "Unicast UDP Usage 
Guidelines for Application Designers".  Quoting from 3.1.1 of that:

"Applications that perform bulk transmission of data to a peer over UDP, 
i.e., applications that exchange more than a small number of UDP 
datagrams per RTT, SHOULD implement TCP-Friendly Rate Control (TFRC) 
[RFC5348], window-based, TCP-like congestion control, or otherwise 
ensure that the application complies with the congestion control 
principles."

My thought would be that we use this as a starting point, and establish 
/ work through additional requirements as we encounter them (either 
before or during the review process).  Does this seem sane?

-Gilbert

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 29 Apr 2016 23:27:08 +0100

> before or during the review process).  Does this seem sane?

Yes. Where it might get tricky is if one re-considers the various
formulae in 5348 in the context of various kinds of DTN. Perhaps
there're good-enough ways to side-step having to do that, but if
not, then it could be a bunch of work to know how to tell a sender
to be nice with BP/UDP when the sender doesn't know what kinds of
delay and disruption will be experienced by the packets they send
to the next BPA.

A (not *the*, but just *a*:-) danger here is that we end up saying
that it's only for-sure ok to use the UDPCL where TCP would work,
leading folks to use a TCPCL instead. If the WG want to encourage
use of UDPCL even in situations where TCP doesn't work well, then
that may require tackling the above TFRC-in-a-DTN issues.

Of course, it's possible someone has already done work on that
topic, but I don't recall it. (I didn't go looking though so it
may be there in the literature.)

Cheers,
S.

---

From: "Marc Blanchet" <[email-masked]>
Date: Sat, 30 Apr 2016 10:39:29 -0400

> basic standard bundle if the WG could rally and get it done.

at the end, my opinion (as co-chair) does not count. It is wg consensus. 
So in some ways, we(the wg) needs to reach consensus on what we need to 
do. Some possible choices from the conversation:
a) do not wait for any CL before moving BPbis forward
b) have UDP
c) have TCP
d) have UDP and TCP
e) have CCSDS CL
f) any other possibility

The choice again, and that is my main point (as co-chair), should be 
done on basis of technical ground, not on the basis of a document being 
written faster or slower.

It is up to the wg to decide, at least at this stage.

We could obviously invite more transport colleagues to this discussion.

Marc.