Re: [dtn] rfc5050(bis) proposed revisions

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

Hi Will,

> -----Original Message-----
> From: Ivancic, William D. (GRC-RHN0) [mailto:[e-mail]]
> Sent: Wednesday, June 18, 2014 6:18 AM
> To: Templin, Fred L; [e-mail]
> Subject: Re: [dtn] rfc5050(bis) proposed revisions
> 
> While I appreciate Scott's work and taking time to write bpv7, I think
> this list is not the place to discussion implementations and I think it is
> premature to consider these implementations until a working group is or is
> not formed (at which point we will know where those discussions should
> occur).  For now, IMHO, implementations issues are probably best addressed
> on dtn-interest.

I'm not sure why you say "implementations"; we are talking about
specifications - not implementations. A discussion on the list of
planned changes for RFC 5050(bis) I think is perfectly reasonable
for this distribution.

> Check the lists, there are far more subscribers on
> dtn-interest the the dtn BOF list.

List administrators have access to the list of subscribers and,
while I can't say more, I can tell you that the membership of
this list is not insubstantial.

Thanks - Fred
[e-mail]

> Will
> 
> ******************************
> 
> 
> 
> 
> 
> 
> 
> On 6/17/14 4:20 PM, "Templin, Fred L" <[e-mail]> wrote:
> 
> >Hello,
> >
> >Below is a list of (proposed) revisions for rfc5050(bis) as found in
> >Appendix A of 'draft-burleigh-bpv7'. Please post any comments or
> >suggestions to the list.
> >
> >Thanks - Fred
> >[e-mail]
> >
> >---
> >
> >Appendix A.                  Summary of Revisions
> >
> >   This specification differs from RFC-5050 in a number of ways.  The
> >   revisions that seem to the author to be most significant are listed
> >   below:
> >
> >     . Amplify the discussion of custody transfer.  Move current
> >        custodian to an extension block, of which there can be multiple
> >        occurrences (providing possible support for the MITRE idea of
> >        multiple concurrent custodians, from several years ago); define
> >        that block in this spec.
> >     . Add the notion of "embargoes", i.e., what do you do when a
> >        route unexpectedly goes bad for a while?  This entails adding
> >        another extension block (Forwarding Anomaly) and another
> >        administrative record (Reopen Signal).
> >     . Incorporate the Compressed Bundle Header Encoding [RFC6260]
> >        concepts into the base specification: nodes are explicitly
> >        identified by node numbers, and operations that pertain to
> >        nodes are described in terms of node numbers rather than
> >        endpoint IDs.
> >     . Add basic ("imc") multicast to the BP spec.  This entails
> >        adding another administrative record, Multicast Petition.
> >     . Add Destination EID extension block for destinations that can't
> >        be expressed in "ipn"-scheme and "imc"-scheme URIs.  Define it
> >        in this spec.
> >     . Incorporate the "Extended Class of Service" features into the
> >        base specification.
> >     . Restructure the primary block, making it immutable.  Add CRC.
> >        Remove the dictionary.
> >     . Add optional Payload CRC extension block, defined in this spec.
> >     . Add block ID number to canonical block format (to support
> >        streamlined Bundle Security Protocol).
> >     . Add bundle age extension block, defined in this spec.
> >     . Define two other extension blocks in this spec: previous node
> >        number, hop count.
> >     . Clean up a conflict between fragmentation and custody transfer
> >        that Ed Birrane pointed out.
> >     . Remove "DTN time" values from administrative records.
> >        Nanosecond precision will not be meaningful among nodes whose
> >        clocks are not closely synchronized, and absent that feature
> >        the administrative record's bundle creation time suffices to
> >        indicate the time of occurrence of the reported event.
> >     . Note that CL protocols are supposed to discard data that they
> >        find to have been corrupted.
> >
> >
> >_______________________________________________
> >dtn mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/dtn