[dtn] rfc5050(bis) proposed revisions
"Templin, Fred L" <Fred.L.Templin@boeing.com> Tue, 17 June 2014 20:21 UTC
Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7E01A0166 for <dtn@ietfa.amsl.com>; Tue, 17 Jun 2014 13:21:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.852
X-Spam-Level:
X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2Tf4CR7FF3T for <dtn@ietfa.amsl.com>; Tue, 17 Jun 2014 13:21:08 -0700 (PDT)
Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E57B31A011C for <dtn@ietf.org>; Tue, 17 Jun 2014 13:21:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s5HKL64V008046; Tue, 17 Jun 2014 15:21:06 -0500
Received: from XCH-PHX-301.sw.nos.boeing.com (xch-phx-301.sw.nos.boeing.com [137.136.239.20]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s5HKKuxv007956 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for <dtn@ietf.org>; Tue, 17 Jun 2014 15:20:56 -0500
Received: from XCH-BLV-512.nw.nos.boeing.com ([169.254.12.74]) by XCH-PHX-301.sw.nos.boeing.com ([169.254.7.208]) with mapi id 14.03.0181.006; Tue, 17 Jun 2014 13:20:56 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: "dtn@ietf.org" <dtn@ietf.org>
Thread-Topic: rfc5050(bis) proposed revisions
Thread-Index: Ac+KaaQhmoUqQpYvQB6T5cZzvSCI/A==
Date: Tue, 17 Jun 2014 20:20:55 +0000
Message-ID: <2134F8430051B64F815C691A62D983183048DDED@XCH-BLV-512.nw.nos.boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [137.136.248.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/vp__jD54yV4zpalzt-nh6A4Inps
Subject: [dtn] rfc5050(bis) proposed revisions
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Jun 2014 20:21:09 -0000
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] rfc5050(bis) proposed revisions Templin, Fred L
- Re: [dtn] rfc5050(bis) proposed revisions Ivancic, William D. (GRC-RHN0)
- Re: [dtn] rfc5050(bis) proposed revisions Templin, Fred L
- Re: [dtn] rfc5050(bis) proposed revisions Ivancic, William D. (GRC-RHN0)
- Re: [dtn] rfc5050(bis) proposed revisions Stephen Farrell
- Re: [dtn] rfc5050(bis) proposed revisions Templin, Fred L
- Re: [dtn] rfc5050(bis) proposed revisions Templin, Fred L
- Re: [dtn] rfc5050(bis) proposed revisions Burleigh, Scott C (312G)
- Re: [dtn] rfc5050(bis) proposed revisions Stephen Farrell
- [dtn] List roster counts [was: Re: rfc5050(bis) p… Elwyn Davies
- Re: [dtn] List roster counts [was: Re: rfc5050(bi… Templin, Fred L