Re: [dtn] BPbis status

[Brian Sipos <[e-mail]>]

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 <[e-mail]>
Sent: Friday, July 8, 2016 10:57:14 AM
To: Brian Sipos; Rick Taylor; [e-mail]; [e-mail]
Subject: RE: [dtn] BPbis status


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:[e-mail]] On Behalf Of Brian Sipos
Sent: Thursday, July 07, 2016 9:30 AM
To: Rick Taylor <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [dtn] BPbis status



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 <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, July 7, 2016 11:31:52 AM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Brian Sipos
Subject: Re: [dtn] BPbis status



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, [e-mail]<mailto:[e-mail]> 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
>
> From: dtn [mailto:[e-mail]] On Behalf Of Brian Sipos
> Sent: Thursday, July 07, 2016 3:03 PM
> To: [e-mail]<mailto:[e-mail]>
> Subject: Re: [dtn] BPbis status
>
> 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 <[e-mail]<mailto:[e-mail]>> on behalf of Rick Taylor <rick@tropi
> calstormsoftware.com>
> Sent: Tuesday, July 5, 2016 12:46:28 PM
> To: [e-mail]<mailto:[e-mail]>
> Subject: [dtn] BPbis status
>
> 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
> _______________________________________________
> dtn mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/dtn
> _______________________________________________
> dtn mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/dtn