Re: [dtn] rfc5050(bis) proposed revisions

["Ivancic, William D. (GRC-RHN0)" <[e-mail]>]

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.  Check the lists, there are far more subscribers on
dtn-interest the the dtn BOF list.

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