Re: [dtn] rfc5050(bis) proposed revisions

Hi Stephen,

> -----Original Message-----
> From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of Stephen Farrell
> Sent: Friday, June 20, 2014 12:23 PM
> To: Templin, Fred L; Ivancic, William D. (GRC-RHN0); dtn@ietf.org
> Subject: Re: [dtn] rfc5050(bis) proposed revisions
> 
> 
> 
> On 20/06/14 20:16, Templin, Fred L wrote:
> > Hi Will,
> >
> >> -----Original Message-----
> >> From: Ivancic, William D. (GRC-RHN0) [mailto:william.d.ivancic@nasa.gov]
> >> Sent: Wednesday, June 18, 2014 6:18 AM
> >> To: Templin, Fred L; dtn@ietf.org
> >> 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.
> 
> Have to agree with Fred on the above. Better to keep
> relevant discussion focussed here in the run up to the
> BoF and if a proposal for a 5050bis isn't relevant then
> I don't know what could be.

OK; I will reboot the discussion.

Thanks - Fred
fred.l.templin@boeing.com

> After the BoF we can figure if something ought be here
> or there, assuming there is a "here".
> 
> >
> >> 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.
> 
> I doubt that that number needs to be kept secret but in
> any case... who cares? :-) The argument above wins and
> size doesn't matter in this case.
> 
> S.
> 
> >
> > Thanks - Fred
> > fred.l.templin@boeing.com
> >
> >> Will
> >>
> >> ******************************
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On 6/17/14 4:20 PM, "Templin, Fred L" <Fred.L.Templin@boeing.com> 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
> >>> fred.l.templin@boeing.com
> >>>
> >>> ---
> >>>
> >>> 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
> >>> dtn@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/dtn
> >
> > _______________________________________________
> > 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