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

["Templin, Fred L" <[e-mail]>]

Hi Gilbert,

> -----Original Message-----
> From: dtn [mailto:[e-mail]] On Behalf Of Gilbert Clark
> Sent: Friday, April 29, 2016 9:08 AM
> To: [e-mail]
> Subject: Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-03.txt
> 
> Sure, I'm happy with this.  Other list folks / chairs - does this seem
> like a reasonable path?

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
[e-mail]

> 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
> 
> On 04/29/2016 11:08 AM, Burleigh, Scott C (312B) wrote:
> > 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:[e-mail]] On Behalf Of Gilbert Clark
> > Sent: Friday, April 29, 2016 6:50 AM
> > To: [e-mail]
> > 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, [e-mail] 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.)
> >>
> >> 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 [e-mail] http://about.me/lloydwood
> >>
> >>
> >> ----- Original Message -----
> >> From: Gilbert Clark <[e-mail]>
> >> To: [e-mail]
> >> Sent: Friday, 29 April 2016, 10:18
> >> Subject: Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-03.txt
> >>
> >> 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
> >>
> >> _______________________________________________
> >> dtn mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/dtn
> >>
> >> _______________________________________________
> >> dtn mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/dtn
> >>
> >>
> > _______________________________________________
> > dtn mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dtn
> >
> > _______________________________________________
> > dtn mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dtn
> >
> >
> 
> _______________________________________________
> dtn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtn