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.

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
> 
> 