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, Jeremy.Mayer@dlr.de 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:dtn-bounces@ietf.org] On Behalf Of Brian Sipos
> Sent: Thursday, July 07, 2016 3:03 PM
> To: dtn@ietf.org
> 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 <dtn-bounces@ietf.org> on behalf of Rick Taylor <rick@tropi
> calstormsoftware.com>
> Sent: Tuesday, July 5, 2016 12:46:28 PM
> To: dtn@ietf.org
> 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
> dtn@ietf.org
> https://www.ietf.org/mailman/listinfo/dtn
> _______________________________________________
> dtn mailing list
> dtn@ietf.org
> https://www.ietf.org/mailman/listinfo/dtn