Subject: [dtn] BPbis status

From: Rick Taylor <[email-masked]>
Date: Tue, 5 Jul 2016 16:46:28 +0000

All,

As some may have noticed, there have been comments received on the list
which have resulted in Scott updating BPbis, hopefully in time for
Berlin.  Because of these forthcoming changes I have returned the
document to the working group, i.e. removed its 'Last Call' status.
This is not a criticism of the quality/maturity of the draft, it just
reflects the fact that an update is happening.

However, one of the topics Marc and I would like debated on-list and at
the mic during IETF96 is what should happen to BPbis when there is
general consensus that it is 'done' as far as the working group is
concerned.

The document can return to Last Call, if the WG desires, to be passed
up the IETF document chain for AD/IESG review and on to publication.
 However, there has been suggestion on the list that without some of
the other 'moving parts' of a full DTN stack, e.g. TCP-CLA or
interoperable addressing, the document itself only describes part of a
solution.
I have a concern that if the draft continues beyond the WG towards
Proposed Standard before there is more maturity in other drafts
covering the missing pieces, then either: a) The IESG will return it to
the WG, highlighting the abscence of supporting material, or b) The WG
will discover, while producing drafts for the other supporting parts,
that a non-trivial change must be made in BPbis, forcing the creation
of BPbis-bis.

So my debate question is:  Does the WG believe that the benefit of
having BPbis promptly move towards Proposed Standard outweighs the risk
that a breaking change will be required after it has been published?

If the consensus is with the former, then I would suggest Scott
requests a return to WG Last Call status after his current update.  If
consensus is that it is currently too risky, then I suggest placing the
draft in some kind of 'holding pattern', with a deadline, to allow the
other important WG work to catch up.

Of course, we are always open to suggestions of alternative mechanisms,
both from IETF process gurus, and those who can see a 'third way'.

Please do not take this as a criticism of BPbis or the brilliant work
of Scott and all those involved in getting the draft to where it is
now.

Regards,

Rick

---

From: <[email-masked]>
Date: Wed, 6 Jul 2016 04:19:11 +0000 (UTC)

> Does the WG believe that the benefit of 
> that a breaking change will be required after it has been published

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

----- Original Message -----
From: Rick Taylor <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: Wednesday, 6 July 2016, 2:46
Subject: [dtn] BPbis status

All,

Regards,

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

---

From: Brian Sipos <[email-masked]>
Date: Thu, 7 Jul 2016 13:03:17 +0000

My opinion, for what it's worth, is that the bare minimum is to have a single encoding spec along with the protocol spec. Without an encoding to prototype against, it is difficult to attempt to evaluate the BPbis spec in isolation. I think having a long-term CLA to go along with it is helpful, but prototyping can be done with an ad-hoc "in-memory CL" or "filesystem CL" for a particular BPbis encoding.

An updated TCPCL is forthcoming, but I don't think that it is absolutely necessary to prototyping and review of BPbis proper.

________________________________
From: dtn <[email-masked]> on behalf of Rick Taylor <[email-masked]>
Sent: Tuesday, July 5, 2016 12:46:28 PM
To: [email-masked]
Subject: [dtn] BPbis status

All,

Regards,

Rick

---

From: <[email-masked]>
Date: Thu, 7 Jul 2016 13:22:00 +0000

I think that the bare minimum for evaluation would be: bpBis, an encoding spec (Let's say the "standard" SDNV-based model which we all know and love), and an on-the-wire CLA.
As bpBis is a networking protocol, I would aim to avoid a filesystem/in-memory CL. Evaluating against such a CLA is still a fundamentally isolated operation, and doesn't showcase interoperability. However, since we do have the TCPCL, as well as the dtnrg LTP CL, I think that we are (or could be) covered.

Thanks,
Jeremy

From: dtn [mailto:[email-masked]] On Behalf Of Brian Sipos
Sent: Thursday, July 07, 2016 3:03 PM
To: [email-masked]
Subject: Re: [dtn] BPbis status

________________________________
From: dtn <[email-masked]<mailto:[email-masked]>> on behalf of Rick Taylor <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, July 5, 2016 12:46:28 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [dtn] BPbis status

All,

Regards,

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

---

From: Rick Taylor <[email-masked]>
Date: Thu, 7 Jul 2016 15:31:52 +0000

I think I agree that a 'local-storage' CL seems to be a funny concept
that the WG could burn cycles on for no useful outcome, particularly as
TCPCL and LTP CL exist as IRTF documents.

Rick

On Thu, 2016-07-07 at 13:22 +0000, [email-masked] wrote:
> I think that the bare minimum for evaluation would be: bpBis, an
> encoding spec (Let’s say the “standard” SDNV-based model which we all
> know and love), and an on-the-wire CLA.
> As bpBis is a networking protocol, I would aim to avoid a
> filesystem/in-memory CL. Evaluating against such a CLA is still a
> fundamentally isolated operation, and doesn’t showcase
> interoperability. However, since we do have the TCPCL, as well as the
> dtnrg LTP CL, I think that we are (or could be) covered.
>  
> Thanks,
> Jeremy
>  
> My opinion, for what it's worth, is that the bare minimum is to have
> a single encoding spec along with the protocol spec. Without an
> encoding to prototype against, it is difficult to attempt to evaluate
> the BPbis spec in isolation. I think having a long-term CLA to go
> along with it is helpful, but prototyping can be done with an ad-hoc
> "in-memory CL" or "filesystem CL" for a particular BPbis encoding.
>  
> An updated TCPCL is forthcoming, but I don't think that it is
> absolutely necessary to prototyping and review of BPbis proper.

---

From: Brian Sipos <[email-masked]>
Date: Thu, 7 Jul 2016 16:30:27 +0000

I agree fully, and I don't propose an official WG-worked 'local CL'.

All I meant to say was that if I can use a BPbis encoding spec to put together and pull apart an octet-sequence representing "a bundle" then I should be able to exercise 100% of the BPbis specs (protocol+encoding) in my agent by stimulating the agent with "RX bundle received", "TX bundle refused", etc. indications. I don't need an actual CLA, I can just stimulate the BP agent directly with some dummy CL behavior. This certainly does not allow for any interoperability testing, but it is enough to work out any issues with the protocol+encoding layers.

________________________________
From: Rick Taylor <[email-masked]>
Sent: Thursday, July 7, 2016 11:31:52 AM
To: [email-masked]; [email-masked]; Brian Sipos
Subject: Re: [dtn] BPbis status

Rick

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 8 Jul 2016 14:57:14 +0000

Hi, I was under the impression that Scott Burleigh's CBOR encoding
spec satisfies this requirement:

https://datatracker.ietf.org/doc/draft-burleigh-dtn-rs-cbor/

Should we ask for wg adoption?

Thanks - Fred

From: dtn [mailto:[email-masked]] On Behalf Of Brian Sipos
Sent: Thursday, July 07, 2016 9:30 AM
To: Rick Taylor <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [dtn] BPbis status

________________________________
From: Rick Taylor <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, July 7, 2016 11:31:52 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Brian Sipos
Subject: Re: [dtn] BPbis status

Rick

On Thu, 2016-07-07 at 13:22 +0000, [email-masked]<mailto:[email-masked]> wrote:
> encoding spec (Let's say the "standard" SDNV-based model which we all
> fundamentally isolated operation, and doesn't showcase
> From: dtn <[email-masked]<mailto:[email-masked]>> on behalf of Rick Taylor <rick@tropi
> calstormsoftware.com>

---

From: Brian Sipos <[email-masked]>
Date: Fri, 15 Jul 2016 13:00:15 +0000

Yes, I agree that the existing BPbis/CBOR draft does complete the BPbis definition down to the octet-sequence encoding.

I do have some concerns with CBOR draft with respect to required encoding types/forms vs. canonical forms (e.g. definite vs. indefinite form of array/string), but that can be discussed separately.

________________________________
From: Templin, Fred L <[email-masked]>
Sent: Friday, July 8, 2016 10:57:14 AM
To: Brian Sipos; Rick Taylor; [email-masked]; [email-masked]
Subject: RE: [dtn] BPbis status

Hi, I was under the impression that Scott Burleigh’s CBOR encoding

Thanks - Fred

Rick

---

From: Kevin Fall <[email-masked]>
Date: Sat, 16 Jul 2016 18:21:12 -0400

Just a thought-

If we look at something like the IP protocol spec, it doesn't really work
without something else to carry it as well (e.g., encapsulation of IP
packets in Ethernet, or in PPP, or in AAL(5), or in/on avian carriers,
etc).  So, is it really fundamentally different?

regards,
- Kevin

On Tue, Jul 5, 2016 at 12:46 PM, Rick Taylor <[email-masked]
> wrote:

---

From: Gilbert Clark <[email-masked]>
Date: Sun, 17 Jul 2016 16:54:23 -0400

Kevin:

Sure, this makes sense.

Personally, my worry is that dtnwg will end up with a standards-track
bundle protocol that's expected to be run on top of a convergence layer
that hasn't been defined with a similar level of rigor: it's the
metaphorical equivalent of building the protocol's foundation on sand or
the like.  I also think it's difficult to support the case that nontrivial
levels of testing have been done using the updated version of the bundle
protocol when no well-defined mechanisms (read: convergence layers) exist
to support such testing in the general sense: if experimental CLAs are
being used to test, why aren't those CLAs also going through the standards
process along with everything else?

Realistically, I don't know if I think the concerns above are enough to
warrant any significant delay of pushing an updated specification through
the WG (read: I won't spend much time arguing that they are), but ... the
way things are being defined in this case leaves me with the same kind of
uneasiness as I would have upon opening a code file and finding the same
lines copied and pasted a few hundred times.  Sure, writing code that way
will likely still get the job done ... but it's probably going to suck
trying to maintain that code in the long term.

Cheers,
Gilbert

On Sat, Jul 16, 2016 at 6:21 PM, Kevin Fall <[email-masked]> wrote:

> On Tue, Jul 5, 2016 at 12:46 PM, Rick Taylor <
> [email-masked]> wrote:
>
>> All,
>>