From nobody Mon Jun 2 13:24:21 2014 Return-Path: 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 ADE9F1A03F7 for ; Mon, 2 Jun 2014 13:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 ocWlokHQ_vtW for ; Mon, 2 Jun 2014 13:24:15 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 920851A03A3 for ; Mon, 2 Jun 2014 13:24:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s52KO7Kd027893; Mon, 2 Jun 2014 13:24:07 -0700 Received: from XCH-PHX-211.sw.nos.boeing.com (xch-phx-211.sw.nos.boeing.com [130.247.25.140]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s52KO5hn027720 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Mon, 2 Jun 2014 13:24:05 -0700 Received: from XCH-BLV-308.nw.nos.boeing.com (2002:82f7:19dc::82f7:19dc) by XCH-PHX-211.sw.nos.boeing.com (2002:82f7:198c::82f7:198c) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 2 Jun 2014 13:24:05 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.105]) by XCH-BLV-308.nw.nos.boeing.com ([169.254.8.96]) with mapi id 14.03.0181.006; Mon, 2 Jun 2014 13:24:00 -0700 From: "Templin, Fred L" To: "dtn@ietf.org" Thread-Topic: test Thread-Index: Ac9+oJba10bKUPgNS2mx8yez+weM8Q== Date: Mon, 2 Jun 2014 20:24:01 +0000 Message-ID: <2134F8430051B64F815C691A62D983181B2BC3D5@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: multipart/alternative; boundary="_000_2134F8430051B64F815C691A62D983181B2BC3D5XCHBLV504nwnosb_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/B0WuPCvLLZ6WSXswSm68kOEs4w8 Subject: [dtn] test X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 20:24:17 -0000 --_000_2134F8430051B64F815C691A62D983181B2BC3D5XCHBLV504nwnosb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is a test of the DTN IETF mailing list. --_000_2134F8430051B64F815C691A62D983181B2BC3D5XCHBLV504nwnosb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is a test of the DTN IETF mailing list.

--_000_2134F8430051B64F815C691A62D983181B2BC3D5XCHBLV504nwnosb_-- From nobody Mon Jun 2 14:05:16 2014 Return-Path: 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 DAA2B1A0458; Mon, 2 Jun 2014 14:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 LtBLkZNiHrpp; Mon, 2 Jun 2014 14:05:06 -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 9D3DC1A049E; Mon, 2 Jun 2014 14:04:14 -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 s52L48ND021818; Mon, 2 Jun 2014 16:04:09 -0500 Received: from XCH-PHX-109.sw.nos.boeing.com (xch-phx-109.sw.nos.boeing.com [130.247.25.36]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s52L3xq6021741 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 2 Jun 2014 16:03:59 -0500 Received: from XCH-BLV-408.nw.nos.boeing.com (2002:82f7:19a6::82f7:19a6) by XCH-PHX-109.sw.nos.boeing.com (2002:82f7:1924::82f7:1924) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 2 Jun 2014 14:03:58 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.105]) by XCH-BLV-408.nw.nos.boeing.com ([169.254.8.228]) with mapi id 14.03.0181.006; Mon, 2 Jun 2014 14:03:58 -0700 From: "Templin, Fred L" To: "dtn-interest@irtf.org" Thread-Topic: DTN IETF Mailing List Now Active (was: RE: IETF90 DTN BoF Status) Thread-Index: AQHPfqYrdGw5EMvMJU+0Huy8fChf3Q== Date: Mon, 2 Jun 2014 21:03:57 +0000 Message-ID: <2134F8430051B64F815C691A62D983181B2BC53B@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181B2B2353@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983181B2B2353@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: multipart/alternative; boundary="_000_2134F8430051B64F815C691A62D983181B2BC53BXCHBLV504nwnosb_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/ZUvilKmXuImeyNg_YOnFMP3jOt4 Cc: "dtn@ietf.org" Subject: [dtn] DTN IETF Mailing List Now Active (was: RE: IETF90 DTN BoF Status) X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 21:05:11 -0000 --_000_2134F8430051B64F815C691A62D983181B2BC53BXCHBLV504nwnosb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, The DTN IETF mailing list is now active. All further discussion on organizi= ng a BoF for IETF90 will be conducted on this list: https://www.ietf.org/mailman/listinfo/dtn Please join the list today if you have not already done so. Tomorrow, we wi= ll post an introductory message including the draft working group charter and proposed= BoF agenda for discussion. Thanks - Fred fred.l.templin@boeing.com From: dtn-interest [mailto:dtn-interest-bounces@irtf.org] On Behalf Of Temp= lin, Fred L Sent: Friday, May 23, 2014 7:12 AM To: dtn-interest@irtf.org Subject: [dtn-interest] IETF90 DTN BoF Status Hello, Regarding the proposed DTN BoF for IETF90, I have been in communication wit= h the Transport Area ADs and they are giving serious consideration to the request= . The ADs are aware of the BoF request deadlines, and have indicated that they would = like to form a new mailing list specifically for further discussion regarding the B= oF. I will post again with more information as I receive further updates from the ADs. Thanks - Fred fred.l.templin@boeing.com --_000_2134F8430051B64F815C691A62D983181B2BC53BXCHBLV504nwnosb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

The DTN IETF mailing l= ist is now active. All further discussion on organizing a BoF for

IETF90 will be conduct= ed on this list:

 

https://www.ietf.org/mailman/listinfo/dtn

 

Please join the list t= oday if you have not already done so. Tomorrow, we will post an<= /span>

introductory message i= ncluding the draft working group charter and proposed BoF=

agenda for discussion.=

 

Thanks – Fred

fred.l.templin@boeing.= com

 
--_000_2134F8430051B64F815C691A62D983181B2BC53BXCHBLV504nwnosb_-- From nobody Tue Jun 3 10:43:59 2014 Return-Path: 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 250BD1A031C for ; Tue, 3 Jun 2014 10:43:57 -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 2biOCLmIqWSP for ; Tue, 3 Jun 2014 10:43:54 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 555551A023A for ; Tue, 3 Jun 2014 10:43:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s53HhmqY017475; Tue, 3 Jun 2014 10:43:48 -0700 Received: from XCH-PHX-413.sw.nos.boeing.com (xch-phx-413.sw.nos.boeing.com [10.57.37.45]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s53HhhVm017422 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Tue, 3 Jun 2014 10:43:43 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.105]) by XCH-PHX-413.sw.nos.boeing.com ([169.254.13.24]) with mapi id 14.03.0181.006; Tue, 3 Jun 2014 10:43:42 -0700 From: "Templin, Fred L" To: "dtn@ietf.org" Thread-Topic: DTN BoF Proposal for IETF90 - Consensus Check Thread-Index: Ac9/U1um/Drr22FNTHCpLBNTAMtOrg== Date: Tue, 3 Jun 2014 17:43:41 +0000 Message-ID: <2134F8430051B64F815C691A62D983181B2BD2DE@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.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/aQon9CJ1LRtC3mDW9LVuSJvw4Ow Subject: [dtn] DTN BoF Proposal for IETF90 - Consensus Check X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 17:43:57 -0000 Hello, and welcome to the dtn@ietf.org mailing list. As many of you may recall, on April 25th I posted on dtn-interest@irtf.org to propose a BoF meeting at IETF90 for the purpose of discussing the formation of a DTN working group in the IETF: http://www.ietf.org/mail-archive/web/dtn-interest/current/msg05080.html A great deal of discussion ensued, with many suggestions and insights that were captured in the archives. It is now time to check whether there is consensus to go forward with the BoF through discussion on this new list. While there were many suggestions on changes and additional work items to add to the proposed BoF agenda and working group charter, I will begin by reposting the original proposal below. We can work on revising these as we move closer to the actual BoF, but for now let's focus the discussion on whether there is consensus to move forward. Comments? Fred fred.l.templin@boeing.com=20 --- Draft BoF Agenda (2.5hrs): ************************** 1) Problem statement (IETF wg motivation) - 30min 2) RFC5050(bis) - 30min 3) Streamlined Bundle Security Protocol (SBSP) - 30min 4) Bundle-in-Bundle Encapsulation - 30 min 5) DTN Security Key Management - 30min Proposed working group charter: ******************************* Working group name:=20 Delay/Disruption Tolerant Networking Working Group (DTNWG) Chair(s): TBD Area and Area Director(s): Transport Area: ADs Spencer Dawkins , Martin Stiemerling Responsible Area Director: TBD Mailing list: General Discussion: dtn-interest at irtf.org (note: until wg formed) To Subscribe: https://www.ietf.org/mailman/listinfo/dtn-interest Archive: http://www.ietf.org/mail-archive/web/dtn-interest/current/ma= illist.html Description of Working Group: The Delay/Disruption Tolerant Network Working Group (DTNWG) specifies mechanisms for data communications in the presence of long delays and/or intermittent connectivity. The work is motivated by well known limitations of standard Internet protocols that expect end-to-end connectivity between communicating endpoints, sub-second transmission delays and robust packet delivery ratios. In environments where these favorable conditions do not apply, existing mechanisms such as reliab= le transport protocols and routing protocols can fail to converge result= ing in communication failures. Furthermore, classical end-to-end security associations cannot be coordinated when communicating endpoints canno= t conduct multi-message keying exchanges in a timely fashion. These limitations suggest the need for a new approach.=20 =20 Delay-Tolerant Networking (DTN) protocols have been the subject of extensive research and development in the Delay-Tolerant Networking Research Group of the Internet Research Task Force since 2002. In particular, the DTN Bundle Protocol (RFC 5050) and Licklider Transmission Protocol (RFC 5326) have been shown to address the issues identified above. In 2008, BP/LTP was deployed on the EPOXI spacecraft in deep space and was used to conduct reliable, automated communication for four weeks over a network of 10 nodes in which the bottleneck router in the network (the spacecraft) was up to 100 light seconds from all other nodes and connectivity with the router was subject to periods of disconnection lasting several days. The success of the BP/LTP protocol stack -- the core protocols of the "DTN Architecture" originally described in RFC 4838 -- in this demonstration may be attributed to the following fundamental design principles: - There is never any expectation of contemporaneous end-to-end connectivity between any two network nodes. Where such connectivity is sustained, the protocols leverage it to optimize performance, but the possibility of transient but sustained disconnection at any time, anywhere in the network, is always recognized. - Because end-to-end connectivity can never be assumed, each node on the path between source and destination must be prepared to handle incoming "bundles" of data that cannot immediately be forwarded. Such bundles must either be stored for future trans- mission or discarded; in the latter case, the network must be informed of this data loss so that an alternative path may be selected, to avoid impairing the usability of the network. - Again because end-to-end connectivity can never be assumed, end-to-end conversational data exchange can never be assumed to complete in a timely manner; protocol features that rely on timely conversational data exchange must be excluded from the architecture. This principle makes the DTN architecture suitable not only for network environments characterized by lengthy disconnection but also for those that are characterized by long signal propagation delays (such as underwater communication by acoustic signals or, worse, interplanetary communication) even when connectivity is continuous. The DTNWG believes that protocols adhering to these principles offer opportunities for enhancing the functionality of the Internet - in particular, for facilitating the extension of the Internet into environments such as the ocean floor and deep space in which the core Internet protocols operate sub-optimally for the reasons discussed earlier. We believe that the extensive research, demonstration, and pilot operations performed to date using the DTNRG protocols, both before and after the EPOXI experiment, provides a firm basis for publishing Internet standards derived from that work. Work items related to Delay/Disruption Tolerant Networking include: o A mechanism for the exchange of protocol data units, termed "bundles", that are designed to obviate conversational communications by containing values for all potentially relevant configuration parameters. These protocol data units are typically larger than network-layer packets. We expect to derive this bundle exchange mechanism from the DTN Bundle Protocol (BP) documented in RFC 5050. o A security protocol for ensuring that the network in which bundles are exchanged is secured against unauthorized access and denial of service attacks, and to ensure data integrity and confidentiality in that network where necessary. We expect to derive this security protocol from a "streamlined" adaptation of the DTN Bundle Security Protocol documented in RFC 6257. o An encapsulation protocol for "tunneling" BP traffic within bundles that are secured and/or routed in different way from the encapsulated bundles. o A delay-tolerant security key management scheme for ensuring that public keys are certified by a globally trusted authority to protect the integrity of the infrastructure. =20 The working group will consider extending the current milestones based = on new information and knowledge gained while working on the initial chart= er, as well as to accommodate new work items beyond the scope of the initia= l phase. For example, we expect that transport protocols uniquely suited to the various communication environments that may need to be traversed by a single DTN end-to-end path (operating under BP, at what is termed the DTN "convergence layer") will need to be standardized in a second phase of the working group's charter; LTP and the Saratoga protocol are among the candidates for work in this phase. These adjustments will be accommodated in a working group recharter, assuming the initial chartered activities meet their delivery milestones. Possible new work items must then still fit into the (rechartered) DTNWG charter scope. =20 Goals and Milestones: start+3mos - Submit 'Bundle Protocol Specification (RFC5050bis)' as a working group document. To be Proposed Standard. Start+3mos - Submit 'Streamlined Bundle Security Protocol (SBSP)' as a working group document. To be Proposed Standard. start+6mos - Submit 'Bundle In Bundle Encapsulation (BIBE)' as a working group document. To be Proposed Standard. start+9mos - Submit 'Delay Tolerant Networking Security Key Management' a= s a working group document. To be Proposed Standard. start+9mos - Submit 'Bundle Protocol Specification (RFC5050bis)' to the IESG. To be Proposed Standard. start+9mos - Submit 'Streamlined Bundle Security Protocol (SBSP)' to the IESG. To be Proposed Standard. start+10mos - Submit 'Bundle In Bundle Encapsulation (BIBE)' to the IESG. To be Proposed Standard. start+11mos - Submit 'Delay Tolerant Networking Security Key Management' = to the IESG. To be Proposed Standard. start+12mos - Recharter to accommodate new work items or close Working Gr= oup From nobody Tue Jun 3 12:01:05 2014 Return-Path: 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 8D0881A0320 for ; Tue, 3 Jun 2014 12:01:02 -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 Ln1n4hmOn_Sn for ; Tue, 3 Jun 2014 12:00:58 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFEDF1A03FB for ; Tue, 3 Jun 2014 12:00:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s53J0djl000700; Tue, 3 Jun 2014 12:00:39 -0700 Received: from XCH-PHX-413.sw.nos.boeing.com (xch-phx-413.sw.nos.boeing.com [10.57.37.45]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s53J0TZk032508 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Tue, 3 Jun 2014 12:00:30 -0700 Received: from XCH-BLV-206.nw.nos.boeing.com (10.57.37.16) by XCH-PHX-413.sw.nos.boeing.com (10.57.37.45) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 3 Jun 2014 12:00:29 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.105]) by XCH-BLV-206.nw.nos.boeing.com ([169.254.6.122]) with mapi id 14.03.0181.006; Tue, 3 Jun 2014 12:00:29 -0700 From: "Templin, Fred L" To: "dtn@ietf.org" Thread-Topic: Proposed Working Group Charter Suggestions Thread-Index: AQHPf14VhU9E8DCxB0GnZbvZCyLaCA== Date: Tue, 3 Jun 2014 19:00:28 +0000 Message-ID: <2134F8430051B64F815C691A62D983181B2BD423@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181B2BD2DE@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983181B2BD2DE@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.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/FBsPcBcagiU-QQ7dKB_jGPFQze0 Subject: [dtn] Proposed Working Group Charter Suggestions X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 19:01:02 -0000 > While there were many suggestions on changes and additional work items > to add to the proposed BoF agenda and working group charter, I will > begin by reposting the original proposal below. Based on my read of the archives, there were many suggestions for the proposed working group charter. I know I am not capturing everything, but at least the following items were proposed for consideration: - Consider merging SBSP, Bundle-in-Bundle Encapsulation and RFC5050(bis) into a single document - Convergence Layer(s) - Contact discovery - Routing protocols - Registry for service identifiers - Compressed Bundle Header Encoding - Network management Please let me know what I may be missing or mis-representing. Thanks - Fred fred.l.templin@boeing.com From nobody Tue Jun 3 13:30:01 2014 Return-Path: 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 558371A0362; Tue, 3 Jun 2014 13:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 w1dXJ284p_kt; Tue, 3 Jun 2014 13:20:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D61FA1A035E; Tue, 3 Jun 2014 13:20:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140603202031.32156.5163.idtracker@ietfa.amsl.com> Date: Tue, 03 Jun 2014 13:20:31 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/w1F8hXHyQGlDiEiXbyYlFMseJig X-Mailman-Approved-At: Tue, 03 Jun 2014 13:29:57 -0700 Cc: mls.ietf@gmail.com, Fred.L.Templin@boeing.com, dtn@ietf.org, marc.blanchet@viagenie.ca Subject: [dtn] New Non-WG Mailing List: dtn -- Delay Tolerant Networking (DTN) discussion list at the IETF X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 20:20:33 -0000 A new IETF non-working group email list has been created. List address: dtn@ietf.org Archive: http://www.ietf.org/mail-archive/web/dtn/current/maillist.html To subscribe: https://www.ietf.org/mailman/listinfo/dtn Purpose: -Summary Description: Delay Tolerant Networking (DTN) discussion list at the IETF. -Detailed Description: This list is for discussions related to the formation of a Delay Tolerant Networking (DTN) working group. The IRTF DTNRG research group has worked on the particular protocols and this new activity is targeted towards determining if there is interest in standardizing any output from the DTNRG or other sources. For additional information, please contact the list administrators. From nobody Tue Jun 3 13:54:29 2014 Return-Path: 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 5A0FD1A0348 for ; Tue, 3 Jun 2014 13:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 L1bIizxryApw for ; Tue, 3 Jun 2014 13:54:25 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id ACD891A0363 for ; Tue, 3 Jun 2014 13:54:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E0923BF05; Tue, 3 Jun 2014 21:54:17 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLH8bXxwlcfR; Tue, 3 Jun 2014 21:54:15 +0100 (IST) Received: from [10.87.48.12] (unknown [86.45.59.242]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DDF6BBF01; Tue, 3 Jun 2014 21:54:14 +0100 (IST) Message-ID: <538E35F6.2010702@cs.tcd.ie> Date: Tue, 03 Jun 2014 21:54:14 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Templin, Fred L" , "dtn@ietf.org" References: <2134F8430051B64F815C691A62D983181B2BD2DE@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2BD423@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983181B2BD423@XCH-BLV-504.nw.nos.boeing.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/LA6g-4k_QMGJtrSkHt1XQcezMXY Subject: Re: [dtn] Proposed Working Group Charter Suggestions X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 20:54:28 -0000 Hi Fred, On 03/06/14 20:00, Templin, Fred L wrote: >> While there were many suggestions on changes and additional work items >> to add to the proposed BoF agenda and working group charter, I will >> begin by reposting the original proposal below. > > Based on my read of the archives, there were many suggestions for the > proposed working group charter. I know I am not capturing everything, > but at least the following items were proposed for consideration: > > - Consider merging SBSP, Bundle-in-Bundle Encapsulation and > RFC5050(bis) into a single document > - Convergence Layer(s) > - Contact discovery > - Routing protocols > - Registry for service identifiers > - Compressed Bundle Header Encoding > - Network management I'd be interested in a version of the charter text that includes whatever are the changes related to the above that you (as the BoF proponents) think are reasonable. > > Please let me know what I may be missing or mis-representing. We had a longish discussion of whether or not the proposed WG would be much more of a "5050bis with minimal change" or would attempt to more broadly revisit the BP as an instance of the DTN architecture described in RFC 4838. While I would be in favour of the latter, I don't think the list discussion landed there, (so far anyway) and it seems clear that the BoF proponents are more in favour of the former, i.e. minimal changes to 5050. That still needs to be much more clearly stated in the proposed charter text IMO, as it significantly impacts on the scope of the proposed WG. S. > > Thanks - Fred > fred.l.templin@boeing.com > > _______________________________________________ > dtn mailing list > dtn@ietf.org > https://www.ietf.org/mailman/listinfo/dtn > From nobody Tue Jun 3 14:03:32 2014 Return-Path: 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 9883C1A0363 for ; Tue, 3 Jun 2014 14:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 C1-eQrZXCjpJ for ; Tue, 3 Jun 2014 14:03:27 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7703B1A01A8 for ; Tue, 3 Jun 2014 14:03:27 -0700 (PDT) Received: from [IPv6:2620::230:c000:7021:a657:d697:aa2b] (unknown [IPv6:2620:0:230:c000:7021:a657:d697:aa2b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3C545403EF; Tue, 3 Jun 2014 17:03:21 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_3A699D1F-F97D-486F-B2BE-98A8ACE01085" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Marc Blanchet In-Reply-To: <538E35F6.2010702@cs.tcd.ie> Date: Tue, 3 Jun 2014 17:03:22 -0400 Message-Id: <429A0105-0BB1-44F8-BA2E-8F85A96C2E42@viagenie.ca> References: <2134F8430051B64F815C691A62D983181B2BD2DE@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2BD423@XCH-BLV-504.nw.nos.boeing.com> <538E35F6.2010702@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/eNz0BPTzqvKhHQf6D4qEi9tAo9Q Cc: "Templin, Fred L" , "dtn@ietf.org" Subject: Re: [dtn] Proposed Working Group Charter Suggestions X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 21:03:31 -0000 --Apple-Mail=_3A699D1F-F97D-486F-B2BE-98A8ACE01085 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2014-06-03 =E0 16:54, Stephen Farrell a = =E9crit : >=20 > Hi Fred, >=20 > On 03/06/14 20:00, Templin, Fred L wrote: >>> While there were many suggestions on changes and additional work = items >>> to add to the proposed BoF agenda and working group charter, I will >>> begin by reposting the original proposal below. >>=20 >> Based on my read of the archives, there were many suggestions for the >> proposed working group charter. I know I am not capturing everything, >> but at least the following items were proposed for consideration: >>=20 >> - Consider merging SBSP, Bundle-in-Bundle Encapsulation and >> RFC5050(bis) into a single document >> - Convergence Layer(s) >> - Contact discovery >> - Routing protocols >> - Registry for service identifiers >> - Compressed Bundle Header Encoding >> - Network management >=20 > I'd be interested in a version of the charter text that includes > whatever are the changes related to the above that you (as the > BoF proponents) think are reasonable. >=20 >>=20 >> Please let me know what I may be missing or mis-representing. >=20 > We had a longish discussion of whether or not the proposed WG > would be much more of a "5050bis with minimal change" or would > attempt to more broadly revisit the BP as an instance of the > DTN architecture described in RFC 4838. >=20 > While I would be in favour of the latter, I don't think the list > discussion landed there, (so far anyway) and it seems clear that > the BoF proponents are more in favour of the former, i.e. minimal > changes to 5050. >=20 > That still needs to be much more clearly stated in the proposed > charter text IMO, as it significantly impacts on the scope > of the proposed WG. I agree that the scope needs to be well defined. We could do this in two steps: 1.1 Minimal changes (5050bis, registry, convergence layer, ...) that = does not change the architecture. 1.2 write a problem statement for the "revisit BP and the architecture"=20= then after completing 1.1 and 1.2, either close the wg, move it to the = rg, or recharter, all based on 1.2 outcome Marc. >=20 > S. >=20 >=20 >>=20 >> Thanks - Fred >> fred.l.templin@boeing.com >>=20 >> _______________________________________________ >> dtn mailing list >> dtn@ietf.org >> https://www.ietf.org/mailman/listinfo/dtn >>=20 >=20 > _______________________________________________ > dtn mailing list > dtn@ietf.org > https://www.ietf.org/mailman/listinfo/dtn --Apple-Mail=_3A699D1F-F97D-486F-B2BE-98A8ACE01085 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Le = 2014-06-03 =E0 16:54, Stephen Farrell <stephen.farrell@cs.tcd.ie>= ; a =E9crit :


Hi Fred,

On 03/06/14 = 20:00, Templin, Fred L wrote:
While there were many suggestions on changes and = additional work items
to add to the proposed BoF agenda and working = group charter, I will
begin by reposting the original proposal = below.

Based on my read of the archives, there were = many suggestions for the
proposed working group charter. I know I am = not capturing everything,
but at least the following items were = proposed for consideration:

 - Consider merging SBSP, = Bundle-in-Bundle Encapsulation and
   RFC5050(bis) = into a single document
 - Convergence Layer(s)
 - = Contact discovery
 - Routing protocols
 - Registry for = service identifiers
 - Compressed Bundle Header = Encoding
 - Network management

I'd be = interested in a version of the charter text that includes
whatever = are the changes related to the above that you (as the
BoF proponents) = think are reasonable.


Please let me = know what I may be missing or mis-representing.

We = had a longish discussion of whether or not the proposed WG
would be = much more of a "5050bis with minimal change" or would
attempt to more = broadly revisit the BP as an instance of the
DTN architecture = described in RFC 4838.

While I would be in favour of the latter, = I don't think the list
discussion landed there, (so far anyway) and = it seems clear that
the BoF proponents are more in favour of the = former, i.e. minimal
changes to 5050.

That still needs to be = much more clearly stated in the proposed
charter text IMO, as it = significantly impacts on the scope
of the proposed = WG.

I agree that the scope = needs to be well defined.

We could do this in = two steps:
1.1 Minimal changes (5050bis, registry, convergence = layer, ...) that does not change the architecture.
1.2 write a = problem statement for the "revisit BP and the = architecture" 

then after completing 1.1 = and 1.2, either close the wg, move it to the rg, or recharter, all based = on 1.2 outcome

Marc.


S.



Thanks - Fred
fred.l.templin@boeing.com
_______________________________________________
dtn mailing = list
dtn@ietf.org
https://www.ietf.org/ma= ilman/listinfo/dtn


___________________________= ____________________
dtn mailing list
dtn@ietf.org
https://www.ietf.org/ma= ilman/listinfo/dtn

= --Apple-Mail=_3A699D1F-F97D-486F-B2BE-98A8ACE01085-- From nobody Tue Jun 3 14:08:55 2014 Return-Path: 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 39EC91A036F for ; Tue, 3 Jun 2014 14:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 CM2_KimGyiZC for ; Tue, 3 Jun 2014 14:08:46 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4325C1A01A8 for ; Tue, 3 Jun 2014 14:08:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4865ABF03; Tue, 3 Jun 2014 22:08:40 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1DGfKpv8bFN; Tue, 3 Jun 2014 22:08:39 +0100 (IST) Received: from [10.87.48.12] (unknown [86.45.59.242]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D864FBEF7; Tue, 3 Jun 2014 22:08:38 +0100 (IST) Message-ID: <538E3956.9040001@cs.tcd.ie> Date: Tue, 03 Jun 2014 22:08:38 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Marc Blanchet References: <2134F8430051B64F815C691A62D983181B2BD2DE@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2BD423@XCH-BLV-504.nw.nos.boeing.com> <538E35F6.2010702@cs.tcd.ie> <429A0105-0BB1-44F8-BA2E-8F85A96C2E42@viagenie.ca> In-Reply-To: <429A0105-0BB1-44F8-BA2E-8F85A96C2E42@viagenie.ca> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/wVN7kDSfwTFAeEnVedBRr-isIYI Cc: "Templin, Fred L" , "dtn@ietf.org" Subject: Re: [dtn] Proposed Working Group Charter Suggestions X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 21:08:53 -0000 On 03/06/14 22:03, Marc Blanchet wrote: > > I agree that the scope needs to be well defined. > > We could do this in two steps: 1.1 Minimal changes (5050bis, > registry, convergence layer, ...) that does not change the > architecture. 1.2 write a problem statement for the "revisit BP and > the architecture" > > then after completing 1.1 and 1.2, either close the wg, move it to > the rg, or recharter, all based on 1.2 outcome I'd argue myself that there's no need for a problem statement and that a bigger change than envisaged would likely still conform to the DTN architecture. So I'd not find that plan attractive tbh. I also doubt that there'd be energy for such a plan. Once a 5050bis is done, it'd be sensible to wait a while and see how its deployment goes. S. > > Marc. > >> >> S. >> >> >>> >>> Thanks - Fred fred.l.templin@boeing.com >>> >>> _______________________________________________ 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 > From nobody Tue Jun 3 14:20:02 2014 Return-Path: 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 46D5D1A0372 for ; Tue, 3 Jun 2014 14:20:01 -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 u1u6SBSehshu for ; Tue, 3 Jun 2014 14:19:59 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EB721A02F7 for ; Tue, 3 Jun 2014 14:19:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s53LJr8J025963; Tue, 3 Jun 2014 16:19:53 -0500 Received: from XCH-PHX-509.sw.nos.boeing.com (xch-phx-509.sw.nos.boeing.com [10.57.37.31]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s53LJlVg025895 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 3 Jun 2014 16:19:48 -0500 Received: from XCH-BLV-306.nw.nos.boeing.com (130.247.25.218) by XCH-PHX-509.sw.nos.boeing.com (10.57.37.31) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 3 Jun 2014 14:19:47 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.105]) by XCH-BLV-306.nw.nos.boeing.com ([169.254.6.86]) with mapi id 14.03.0181.006; Tue, 3 Jun 2014 14:19:46 -0700 From: "Templin, Fred L" To: Stephen Farrell , "dtn@ietf.org" Thread-Topic: [dtn] Proposed Working Group Charter Suggestions Thread-Index: AQHPf14VhU9E8DCxB0GnZbvZCyLaCJtgUpAA//+OblA= Date: Tue, 3 Jun 2014 21:19:46 +0000 Message-ID: <2134F8430051B64F815C691A62D983181B2BD713@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181B2BD2DE@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2BD423@XCH-BLV-504.nw.nos.boeing.com> <538E35F6.2010702@cs.tcd.ie> In-Reply-To: <538E35F6.2010702@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.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/djLSFZ7y7e1YxYdEBK0TTwcKXOY Subject: Re: [dtn] Proposed Working Group Charter Suggestions X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 21:20:01 -0000 Hi Stephen, > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Tuesday, June 03, 2014 1:54 PM > To: Templin, Fred L; dtn@ietf.org > Subject: Re: [dtn] Proposed Working Group Charter Suggestions >=20 >=20 > Hi Fred, >=20 > On 03/06/14 20:00, Templin, Fred L wrote: > >> While there were many suggestions on changes and additional work items > >> to add to the proposed BoF agenda and working group charter, I will > >> begin by reposting the original proposal below. > > > > Based on my read of the archives, there were many suggestions for the > > proposed working group charter. I know I am not capturing everything, > > but at least the following items were proposed for consideration: > > > > - Consider merging SBSP, Bundle-in-Bundle Encapsulation and > > RFC5050(bis) into a single document > > - Convergence Layer(s) > > - Contact discovery > > - Routing protocols > > - Registry for service identifiers > > - Compressed Bundle Header Encoding > > - Network management >=20 > I'd be interested in a version of the charter text that includes > whatever are the changes related to the above that you (as the > BoF proponents) think are reasonable. >=20 > > > > Please let me know what I may be missing or mis-representing. >=20 > We had a longish discussion of whether or not the proposed WG > would be much more of a "5050bis with minimal change" or would > attempt to more broadly revisit the BP as an instance of the > DTN architecture described in RFC 4838. >=20 > While I would be in favour of the latter, I don't think the list > discussion landed there, (so far anyway) and it seems clear that > the BoF proponents are more in favour of the former, i.e. minimal > changes to 5050. >=20 > That still needs to be much more clearly stated in the proposed > charter text IMO, as it significantly impacts on the scope > of the proposed WG. I think a large part of this process will be to refine the proposed working group charter, and it will be an iterative process. It may not be fully resolved before the actual BoF is held, but to my understanding having the charter agreed to and approved is not a pre-condition for conducting the BoF. However, it seems that you would like to see a first iteration of the revised proposed charter based on the discussions of the past couple of months on the dtnrg list - is that what you are asking? Thanks - Fred fred.l.templin@boeing.com =20 > S. >=20 >=20 > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > _______________________________________________ > > dtn mailing list > > dtn@ietf.org > > https://www.ietf.org/mailman/listinfo/dtn > > From nobody Tue Jun 3 14:23:13 2014 Return-Path: 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 663971A0375 for ; Tue, 3 Jun 2014 14:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 gBzAGKs0dPO2 for ; Tue, 3 Jun 2014 14:23:10 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 74CBD1A0372 for ; Tue, 3 Jun 2014 14:23:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5E6CFBF05; Tue, 3 Jun 2014 22:23:04 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLewgv39XgZ7; Tue, 3 Jun 2014 22:23:03 +0100 (IST) Received: from [10.87.48.12] (unknown [86.45.59.242]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 576D8BEFC; Tue, 3 Jun 2014 22:23:03 +0100 (IST) Message-ID: <538E3CB7.10500@cs.tcd.ie> Date: Tue, 03 Jun 2014 22:23:03 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Templin, Fred L" , "dtn@ietf.org" References: <2134F8430051B64F815C691A62D983181B2BD2DE@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2BD423@XCH-BLV-504.nw.nos.boeing.com> <538E35F6.2010702@cs.tcd.ie> <2134F8430051B64F815C691A62D983181B2BD713@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983181B2BD713@XCH-BLV-504.nw.nos.boeing.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/HEhn_pYomhKrXPsQv8uhWnhC8uk Subject: Re: [dtn] Proposed Working Group Charter Suggestions X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 21:23:11 -0000 On 03/06/14 22:19, Templin, Fred L wrote: > However, it seems that you would like to see a first iteration of > the revised proposed charter based on the discussions of the past > couple of months on the dtnrg list - is that what you are asking? I think that'd be great, Thanks, S. From nobody Tue Jun 3 14:41:29 2014 Return-Path: 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 2A1F51A037F for ; Tue, 3 Jun 2014 14:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 8yBlkWgQ3bAF for ; Tue, 3 Jun 2014 14:41:26 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F8491A037D for ; Tue, 3 Jun 2014 14:41:26 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp02.jpl.nasa.gov [128.149.137.149]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s53LfKV0018726 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO) for ; Tue, 3 Jun 2014 14:41:20 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.156]) by ap-ehub-sp02.RES.AD.JPL ([fe80::dd85:7b07:1e36:7e3c%15]) with mapi id 14.03.0174.001; Tue, 3 Jun 2014 14:41:18 -0700 From: "Burleigh, Scott C (312G)" To: "dtn@ietf.org" Thread-Topic: [dtn] Proposed Working Group Charter Suggestions Thread-Index: AQHPf14wFB51tdmzXkGmHw0I1w1vMptgUpAA//+VSKA= Date: Tue, 3 Jun 2014 21:41:17 +0000 Message-ID: References: <2134F8430051B64F815C691A62D983181B2BD2DE@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2BD423@XCH-BLV-504.nw.nos.boeing.com> <538E35F6.2010702@cs.tcd.ie> In-Reply-To: <538E35F6.2010702@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.113] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/ZlcTm-qLtbjmcxyUCq12eAnD4Ws Subject: Re: [dtn] Proposed Working Group Charter Suggestions X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 21:41:28 -0000 Hi, Stephen. In my mind those are not necessarily the only two options. I= definitely would not be in favor of starting from a blank sheet of paper. = A number of changes to BP have been proposed, at one time or another, most= of which I think have merit, and some of which might be considered substan= tial. If those changes were made, would the result be considered "5050 wit= h minimal change"? The term "minimal" is slippery here and, I think, gener= ally not helpful. Maybe the charter clarification you're looking for could simply take the fo= rm of a strawman list of proposed changes? Scott -----Original Message----- From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of Stephen Farrell Sent: Tuesday, June 03, 2014 1:54 PM To: Templin, Fred L; dtn@ietf.org Subject: Re: [dtn] Proposed Working Group Charter Suggestions >=20 > Please let me know what I may be missing or mis-representing. We had a longish discussion of whether or not the proposed WG would be much= more of a "5050bis with minimal change" or would attempt to more broadly r= evisit the BP as an instance of the DTN architecture described in RFC 4838. While I would be in favour of the latter, I don't think the list discussion= landed there, (so far anyway) and it seems clear that the BoF proponents a= re more in favour of the former, i.e. minimal changes to 5050. That still needs to be much more clearly stated in the proposed charter tex= t IMO, as it significantly impacts on the scope of the proposed WG. S. From nobody Tue Jun 3 15:04:24 2014 Return-Path: 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 ABBAB1A038A for ; Tue, 3 Jun 2014 15:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 CsmOFUEo4Iww for ; Tue, 3 Jun 2014 15:04:20 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 557991A0386 for ; Tue, 3 Jun 2014 15:04:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4C9C8BF05; Tue, 3 Jun 2014 23:04:14 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GoYtVdZ3etR; Tue, 3 Jun 2014 23:04:12 +0100 (IST) Received: from [10.87.48.12] (unknown [86.45.59.242]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B34ADBF03; Tue, 3 Jun 2014 23:04:12 +0100 (IST) Message-ID: <538E465C.2060404@cs.tcd.ie> Date: Tue, 03 Jun 2014 23:04:12 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Burleigh, Scott C (312G)" , "dtn@ietf.org" References: <2134F8430051B64F815C691A62D983181B2BD2DE@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2BD423@XCH-BLV-504.nw.nos.boeing.com> <538E35F6.2010702@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/OB9MGKYx3WMXhWeeCRH_9ku-O7E Subject: Re: [dtn] Proposed Working Group Charter Suggestions X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 22:04:22 -0000 On 03/06/14 22:41, Burleigh, Scott C (312G) wrote: > Hi, Stephen. In my mind those are not necessarily the only two > options. Sure. Could be the only two feasible options though:-) > I definitely would not be in favor of starting from a blank > sheet of paper. A number of changes to BP have been proposed, at one > time or another, most of which I think have merit, and some of which > might be considered substantial. If those changes were made, would > the result be considered "5050 with minimal change"? The term > "minimal" is slippery here and, I think, generally not helpful. Sorry, didn't mean it as a derogatory term, but I do think it seems to accurately capture the intent as I understand it. And "minimal" is a valid goal, just one with which I'd disagree. To be clear, and as I've said before, if there's enough support for that "minimal" goal, then I'm ok to be in the rough and still want to see the work going ahead. Before and during the BoF is the time for that scoping discussion though. > Maybe the charter clarification you're looking for could simply take > the form of a strawman list of proposed changes? Actually, for me at least, the general characterisation is more useful as a guideline for which of the other fairly well known kinds of change will likely get done. That may be different for others of course, so you're probably right that a TBD list of changes will be useful, maybe in an update to Fred's draft? S. > > Scott > > -----Original Message----- From: dtn [mailto:dtn-bounces@ietf.org] On > Behalf Of Stephen Farrell Sent: Tuesday, June 03, 2014 1:54 PM To: > Templin, Fred L; dtn@ietf.org Subject: Re: [dtn] Proposed Working > Group Charter Suggestions > > >> >> Please let me know what I may be missing or mis-representing. > > We had a longish discussion of whether or not the proposed WG would > be much more of a "5050bis with minimal change" or would attempt to > more broadly revisit the BP as an instance of the DTN architecture > described in RFC 4838. > > While I would be in favour of the latter, I don't think the list > discussion landed there, (so far anyway) and it seems clear that the > BoF proponents are more in favour of the former, i.e. minimal changes > to 5050. > > That still needs to be much more clearly stated in the proposed > charter text IMO, as it significantly impacts on the scope of the > proposed WG. > > S. > > _______________________________________________ dtn mailing list > dtn@ietf.org https://www.ietf.org/mailman/listinfo/dtn > > From nobody Wed Jun 4 08:38:06 2014 Return-Path: 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 1A87C1A02EB for ; Wed, 4 Jun 2014 08:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_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 yAjKQteRE7O6 for ; Wed, 4 Jun 2014 08:38:01 -0700 (PDT) Received: from nomis80.org (nomis80.org [23.92.21.33]) by ietfa.amsl.com (Postfix) with ESMTP id BF3401A02EA for ; Wed, 4 Jun 2014 08:38:01 -0700 (PDT) Received: from [IPv6:2001:470:1d:bc0:98be:bec1:41d1:4c93] (unknown [IPv6:2001:470:1d:bc0:98be:bec1:41d1:4c93]) by nomis80.org (Postfix) with ESMTPSA id 063E010EA6 for ; Wed, 4 Jun 2014 15:39:51 +0000 (UTC) Message-ID: <538F3D53.5060305@per.reau.lt> Date: Wed, 04 Jun 2014 11:37:55 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dtn@ietf.org References: <2134F8430051B64F815C691A62D983181B2BD2DE@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2BD423@XCH-BLV-504.nw.nos.boeing.com> <538E35F6.2010702@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/HUJslQWtul_tdBWYu8TvmG_yfQA Subject: Re: [dtn] Proposed Working Group Charter Suggestions X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 15:38:05 -0000 One clear, objective criteria that I think we should agree on is that 5050bis does not need to be backward compatible with 5050. Simon Le 2014-06-03 17:41, Burleigh, Scott C (312G) a écrit : > Hi, Stephen. In my mind those are not necessarily the only two options. I definitely would not be in favor of starting from a blank sheet of paper. A number of changes to BP have been proposed, at one time or another, most of which I think have merit, and some of which might be considered substantial. If those changes were made, would the result be considered "5050 with minimal change"? The term "minimal" is slippery here and, I think, generally not helpful. > > Maybe the charter clarification you're looking for could simply take the form of a strawman list of proposed changes? > > Scott From nobody Wed Jun 4 09:29:28 2014 Return-Path: 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 5972D1A02E2 for ; Wed, 4 Jun 2014 09:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jCVOM--Ajj1E for ; Wed, 4 Jun 2014 09:29:25 -0700 (PDT) Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [IPv6:2001:4d0:8302:1100::103]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE601A0270 for ; Wed, 4 Jun 2014 09:29:10 -0700 (PDT) Received: from ndjsppt104.ndc.nasa.gov (ndjsppt104.ndc.nasa.gov [198.117.1.198]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id CFB1F2D808F; Wed, 4 Jun 2014 11:29:02 -0500 (CDT) Received: from NDJSCHT116.ndc.nasa.gov (ndjscht116-pub.ndc.nasa.gov [198.117.1.216]) by ndjsppt104.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id s54GT24Q018739; Wed, 4 Jun 2014 11:29:02 -0500 Received: from NDJSMBX203.ndc.nasa.gov ([169.254.2.8]) by NDJSCHT116.ndc.nasa.gov ([198.117.1.216]) with mapi id 14.03.0174.001; Wed, 4 Jun 2014 11:29:02 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: Simon Perreault , "dtn@ietf.org" Thread-Topic: [dtn] Proposed Working Group Charter Suggestions Thread-Index: AQHPf14xoT809BzuHUKQYykab/OBU5tgMQkAgAANJYCAASzPgP//yzgA Date: Wed, 4 Jun 2014 16:29:01 +0000 Message-ID: References: <2134F8430051B64F815C691A62D983181B2BD2DE@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2BD423@XCH-BLV-504.nw.nos.boeing.com> <538E35F6.2010702@cs.tcd.ie> <538F3D53.5060305@per.reau.lt> In-Reply-To: <538F3D53.5060305@per.reau.lt> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [184.56.61.175] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <755751CE56B65D4588169C2CA31E86B3@mail.nasa.gov> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-06-04_03:2014-06-04,2014-06-04,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/8s8uT7atxCF7LThHjHCsiehGreA Subject: Re: [dtn] Proposed Working Group Charter Suggestions X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 16:29:27 -0000 I wouldn't even call it 5050bis as the changes would probably have to be significant. =20 * Need for reliability check at least in the header. * Need for hop count to eliminate routing loops. * Really no need for time. Nobody is using it or knows how to set it. My question is "Who is deploying RFC5050 in any significant way to justify a working group?" I think we have to be able to answer this question if we really expect to proceed. Boeing hasn't indicated any scaled deployment. I think DOD may have dropped it. I've only seen very simple deployments of a few nodes. Epoxy and N4C may be the largest with 10 to perhaps 20? I think early work with DieselNet and others may have been much larger deployments of store, carry and forward technologies. NASA/DARPA SPHERES uses DTN Tunneling and is really a one-hop DTN network. It works because SHPERES uses a publish/subscribe architecture so the application doesn't really care/know if messages are missed or can re-request during acquisition of signal. Here are the latest in NASA's plans that I know of. http://ipnsig.org/wp-content/uploads/2014/02/ISS-DTN-Presentation-IPNSIG.pd f http://www.docstoc.com/docs/158373645/CU-Boulder-ISS-Updatepptx Note, these are very simple deployments with only a few nodes and probably can be accommodated with the current protocol Will ****************************** William D. Ivancic Phone 216-433-3494 Mobile 440-503-4892 http://roland.grc.nasa.gov/~ivancic On 6/4/14 11:37 AM, "Simon Perreault" wrote: >One clear, objective criteria that I think we should agree on is that >5050bis does not need to be backward compatible with 5050. > >Simon > >Le 2014-06-03 17:41, Burleigh, Scott C (312G) a =E9crit : >> Hi, Stephen. In my mind those are not necessarily the only two >>options. I definitely would not be in favor of starting from a blank >>sheet of paper. A number of changes to BP have been proposed, at one >>time or another, most of which I think have merit, and some of which >>might be considered substantial. If those changes were made, would the >>result be considered "5050 with minimal change"? The term "minimal" is >>slippery here and, I think, generally not helpful. >> >> Maybe the charter clarification you're looking for could simply take >>the form of a strawman list of proposed changes? >> >> Scott > >_______________________________________________ >dtn mailing list >dtn@ietf.org >https://www.ietf.org/mailman/listinfo/dtn From nobody Wed Jun 4 10:33:30 2014 Return-Path: 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 C91A01A0141 for ; Wed, 4 Jun 2014 10:33:28 -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 anpoeR0U3Tbg for ; Wed, 4 Jun 2014 10:33:26 -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 1567C1A02EF for ; Wed, 4 Jun 2014 10:33:22 -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 s54HXGwC028601; Wed, 4 Jun 2014 12:33:16 -0500 Received: from XCH-PHX-213.sw.nos.boeing.com (xch-phx-213.sw.nos.boeing.com [130.247.25.142]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s54HX5E4028183 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 4 Jun 2014 12:33:06 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.105]) by XCH-PHX-213.sw.nos.boeing.com ([169.254.13.228]) with mapi id 14.03.0181.006; Wed, 4 Jun 2014 10:33:05 -0700 From: "Templin, Fred L" To: "Ivancic, William D. (GRC-RHN0)" , "Simon Perreault" , "dtn@ietf.org" Thread-Topic: [dtn] Proposed Working Group Charter Suggestions Thread-Index: AQHPf14VhU9E8DCxB0GnZbvZCyLaCJtgMQkAgAANJYCAASzPgP//yzgAgAAAYgA= Date: Wed, 4 Jun 2014 17:33:05 +0000 Message-ID: <2134F8430051B64F815C691A62D983181B2BE16E@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181B2BD2DE@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2BD423@XCH-BLV-504.nw.nos.boeing.com> <538E35F6.2010702@cs.tcd.ie> <538F3D53.5060305@per.reau.lt> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.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/-t4JvUeQysSznIH4Ux8dxEcS-Z8 Subject: Re: [dtn] Proposed Working Group Charter Suggestions X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 17:33:29 -0000 Hi Will, > Boeing hasn't indicated any scaled deployment I don't believe that an indication of scaled deployment is a necessary precondition for holding a BoF. Thanks - Fred fred.l.templin@boeing.com =20 From nobody Wed Jun 4 10:54:02 2014 Return-Path: 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 3144F1A02E1 for ; Wed, 4 Jun 2014 10:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 DyGBK9tFN65w for ; Wed, 4 Jun 2014 10:53:59 -0700 (PDT) Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [IPv6:2001:4d0:a302:1100::102]) by ietfa.amsl.com (Postfix) with ESMTP id E67631A0254 for ; Wed, 4 Jun 2014 10:53:58 -0700 (PDT) Received: from ndjsppt105.ndc.nasa.gov (ndjsppt105.ndc.nasa.gov [198.117.1.199]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id EBA2DA80A9; Wed, 4 Jun 2014 12:53:52 -0500 (CDT) Received: from NDJSCHT108.ndc.nasa.gov (ndjscht108-pub.ndc.nasa.gov [198.117.1.208]) by ndjsppt105.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id s54Hrq10014556; Wed, 4 Jun 2014 12:53:52 -0500 Received: from NDJSMBX203.ndc.nasa.gov ([169.254.2.8]) by NDJSCHT108.ndc.nasa.gov ([198.117.1.208]) with mapi id 14.03.0174.001; Wed, 4 Jun 2014 12:53:53 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: "Templin, Fred L" , Simon Perreault , "dtn@ietf.org" Thread-Topic: [dtn] Proposed Working Group Charter Suggestions Thread-Index: AQHPf14xoT809BzuHUKQYykab/OBU5tgMQkAgAANJYCAASzPgP//yzgAgABU9YD//8LAgA== Date: Wed, 4 Jun 2014 17:53:52 +0000 Message-ID: References: <2134F8430051B64F815C691A62D983181B2BD2DE@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2BD423@XCH-BLV-504.nw.nos.boeing.com> <538E35F6.2010702@cs.tcd.ie> <538F3D53.5060305@per.reau.lt> <2134F8430051B64F815C691A62D983181B2BE16E@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983181B2BE16E@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [184.56.61.175] Content-Type: text/plain; charset="us-ascii" Content-ID: <4D9EC30C4D38F84B85C8EBE5D649DD4C@mail.nasa.gov> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-06-04_04:2014-06-04,2014-06-04,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/TtpkUoCqObcn0BKO5AokVwj5T8E Subject: Re: [dtn] Proposed Working Group Charter Suggestions X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 17:54:00 -0000 Hi Fred, Maybe so, Maybe not. But, many planned deployments and scaled deployments are likely to be necessary to establish a working group. If the best we can come up with is NASA putting DTN on a three node DTN backbone on ISS and a small deployment in a cave in Slovenia, the I think the people in the IESG might not consider this worthy of their time. I'M asking the questions now, because someone is going to ask them later and we better be able to answer if we want to really establish a DTN working group in the IETF and develop a meaningful, widely deployable protocol that can scale. Consider this: Why haven't these topics been adequately addressed in DTNRG? If there is still needed work here and it hasn't been done, why would we consider a better result from an IETF working group? We have to anticipate this question and if we cannot adequately answer it, the chance of establishing an IETF working group on DTN is probably not very good. - Contact discovery - Routing protocols - Registry for service identifiers - Compressed Bundle Header Encoding - Network management Will On 6/4/14 1:33 PM, "Templin, Fred L" wrote: >Hi Will, > >> Boeing hasn't indicated any scaled deployment > >I don't believe that an indication of scaled deployment is a >necessary precondition for holding a BoF. > >Thanks - Fred >fred.l.templin@boeing.com >=20 > From nobody Wed Jun 4 12:34:27 2014 Return-Path: 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 B5F291A02F8 for ; Wed, 4 Jun 2014 12:34:25 -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 kQ0UBID88m36 for ; Wed, 4 Jun 2014 12:34:24 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A9081A02A8 for ; Wed, 4 Jun 2014 12:34:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s54JYH7j017367; Wed, 4 Jun 2014 14:34:17 -0500 Received: from XCH-PHX-313.sw.nos.boeing.com (xch-phx-313.sw.nos.boeing.com [130.247.25.175]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s54JWBxk012220 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 4 Jun 2014 14:32:12 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.105]) by XCH-PHX-313.sw.nos.boeing.com ([169.254.13.83]) with mapi id 14.03.0181.006; Wed, 4 Jun 2014 12:32:11 -0700 From: "Templin, Fred L" To: "Ivancic, William D. (GRC-RHN0)" , "Simon Perreault" , "dtn@ietf.org" Thread-Topic: [dtn] Proposed Working Group Charter Suggestions Thread-Index: AQHPf14VhU9E8DCxB0GnZbvZCyLaCJtgMQkAgAANJYCAASzPgP//yzgAgAAAYgCAAHvpAP//o2ew Date: Wed, 4 Jun 2014 19:32:10 +0000 Message-ID: <2134F8430051B64F815C691A62D983181B2BE38F@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181B2BD2DE@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2BD423@XCH-BLV-504.nw.nos.boeing.com> <538E35F6.2010702@cs.tcd.ie> <538F3D53.5060305@per.reau.lt> <2134F8430051B64F815C691A62D983181B2BE16E@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.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/cYi2SLu9h5RP3Z9LmZEaFzRpdjs Subject: Re: [dtn] Proposed Working Group Charter Suggestions X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 19:34:25 -0000 Hi Will, To me, "at scale" implies dynamic routing protocols, distributed naming services, etc. But, consider that the Internet itself began with static configurations (remember SRI-NIC?) and scalable dynamic services did not come online until much later. That did not stop the Internet from growing up out of nothingness, nor did it stop the IETF from forming. About the other items on your list, I already have many of those on my revised draft wg charter that I will be publishing very soon (should be later today). So, please bear with me while I get that done. Thanks - Fred fred.l.templin@boeing.com From nobody Wed Jun 4 13:56:03 2014 Return-Path: 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 91C0F1A0309 for ; Wed, 4 Jun 2014 13:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 x9ECCkovLnPs for ; Wed, 4 Jun 2014 13:56:01 -0700 (PDT) Received: from mail.jpl.nasa.gov (sentrion3.jpl.nasa.gov [128.149.139.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10D2A1A0024 for ; Wed, 4 Jun 2014 13:55:56 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp02.jpl.nasa.gov [128.149.137.149]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s54Ktmxn026267 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Wed, 4 Jun 2014 13:55:49 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.156]) by ap-ehub-sp02.RES.AD.JPL ([fe80::dd85:7b07:1e36:7e3c%15]) with mapi id 14.03.0174.001; Wed, 4 Jun 2014 13:55:48 -0700 From: "Burleigh, Scott C (312G)" To: "Ivancic, William D. (GRC-RHN0)" , "Simon Perreault" , "dtn@ietf.org" Thread-Topic: [dtn] Proposed Working Group Charter Suggestions Thread-Index: AQHPf14wFB51tdmzXkGmHw0I1w1vMptgUpAA//+VSKCAAaSsgIAADkeA///S38A= Date: Wed, 4 Jun 2014 20:55:47 +0000 Message-ID: References: <2134F8430051B64F815C691A62D983181B2BD2DE@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2BD423@XCH-BLV-504.nw.nos.boeing.com> <538E35F6.2010702@cs.tcd.ie> <538F3D53.5060305@per.reau.lt> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.26] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/65TMMJLyuunqIiUPP325P2KhpZc Subject: Re: [dtn] Proposed Working Group Charter Suggestions X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 20:56:02 -0000 Will, FWIW, the word we're hearing from our NASA sponsors is that DTN will = be baselined for everything that the Advanced Exploration Systems program f= ields. I think this may be a case of not everybody necessarily advertising= everything they've got in the pipeline. As an aside, I have to point out that your observation that "Nobody is usin= g [time] or knows how to set it" is simply, categorically wrong. Scott -----Original Message----- From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of Ivancic, William D. (G= RC-RHN0) Sent: Wednesday, June 04, 2014 9:29 AM To: Simon Perreault; dtn@ietf.org Subject: Re: [dtn] Proposed Working Group Charter Suggestions I wouldn't even call it 5050bis as the changes would probably have to be si= gnificant. =20 * Need for reliability check at least in the header. * Need for hop count to eliminate routing loops. * Really no need for time. Nobody is using it or knows how to set it. My question is "Who is deploying RFC5050 in any significant way to justify = a working group?" I think we have to be able to answer this question if we = really expect to proceed. Boeing hasn't indicated any scaled deployment. I = think DOD may have dropped it. I've only seen very simple deployments of a= few nodes. Epoxy and N4C may be the largest with 10 to perhaps 20? I thi= nk early work with DieselNet and others may have been much larger deploymen= ts of store, carry and forward technologies. NASA/DARPA SPHERES uses DTN Tu= nneling and is really a one-hop DTN network. It works because SHPERES uses= a publish/subscribe architecture so the application doesn't really care/kn= ow if messages are missed or can re-request during acquisition of signal. Here are the latest in NASA's plans that I know of. http://ipnsig.org/wp-content/uploads/2014/02/ISS-DTN-Presentation-IPNSIG.pd f http://www.docstoc.com/docs/158373645/CU-Boulder-ISS-Updatepptx Note, these are very simple deployments with only a few nodes and probably = can be accommodated with the current protocol Will ****************************** William D. Ivancic Phone 216-433-3494 Mobile 440-503-4892 http://roland.grc.nasa.gov/~ivancic On 6/4/14 11:37 AM, "Simon Perreault" wrote: >One clear, objective criteria that I think we should agree on is that=20 >5050bis does not need to be backward compatible with 5050. > >Simon > >Le 2014-06-03 17:41, Burleigh, Scott C (312G) a =E9crit : >> Hi, Stephen. In my mind those are not necessarily the only two=20 >>options. I definitely would not be in favor of starting from a blank=20 >>sheet of paper. A number of changes to BP have been proposed, at one=20 >>time or another, most of which I think have merit, and some of which=20 >>might be considered substantial. If those changes were made, would=20 >>the result be considered "5050 with minimal change"? The term=20 >>"minimal" is slippery here and, I think, generally not helpful. >> >> Maybe the charter clarification you're looking for could simply take=20 >>the form of a strawman list of proposed changes? >> >> Scott > >_______________________________________________ >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 From nobody Wed Jun 4 14:46:16 2014 Return-Path: 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 875161A032B for ; Wed, 4 Jun 2014 14:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 klAk4ZP6m3Tt for ; Wed, 4 Jun 2014 14:46:11 -0700 (PDT) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [IPv6:2001:4d0:a302:1100::101]) by ietfa.amsl.com (Postfix) with ESMTP id 194731A032D for ; Wed, 4 Jun 2014 14:46:11 -0700 (PDT) Received: from ndjsppt103.ndc.nasa.gov (ndjsppt103.ndc.nasa.gov [198.117.1.197]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id C0F71D062D; Wed, 4 Jun 2014 16:40:17 -0500 (CDT) Received: from NDJSCHT104.ndc.nasa.gov (ndjscht104-pub.ndc.nasa.gov [198.117.1.204]) by ndjsppt103.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id s54Lk4go026072; Wed, 4 Jun 2014 16:46:04 -0500 Received: from NDJSMBX203.ndc.nasa.gov ([169.254.2.8]) by NDJSCHT104.ndc.nasa.gov ([198.117.1.204]) with mapi id 14.03.0174.001; Wed, 4 Jun 2014 16:46:04 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: "Burleigh, Scott C (JPL-312G)[Jet Propulsion Laboratory]" , Simon Perreault , "dtn@ietf.org" Thread-Topic: [dtn] Proposed Working Group Charter Suggestions Thread-Index: AQHPf14xoT809BzuHUKQYykab/OBU5tgMQkAgAANJYCAASzPgP//yzgAgACNmID//8r8AA== Date: Wed, 4 Jun 2014 21:46:03 +0000 Message-ID: References: <2134F8430051B64F815C691A62D983181B2BD2DE@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2BD423@XCH-BLV-504.nw.nos.boeing.com> <538E35F6.2010702@cs.tcd.ie> <538F3D53.5060305@per.reau.lt> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [184.56.61.175] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1134BBE6FFB5F64CA58754A62510B7EC@mail.nasa.gov> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-06-04_04:2014-06-04,2014-06-04,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/6tgYkbSC5mo4rPHw7TxqPkNstxw Subject: Re: [dtn] Proposed Working Group Charter Suggestions X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 21:46:14 -0000 Scott, I heard the same regarding AES http://www.nasa.gov/directorates/heo/aes/#.U4-NpSS8LhU But that is not many systems. Really, whatever is done on ISS and maybe an Asteroid Retrieval via Orion (single space craft) around a lunar orbit. And not until 2020 or later will maybe a few node network at best. IMHO, you'll need more than that to justify a IETF working group. There is already a CCSDS working group for space that is doing DTN. If we are only considering small space deployments, perhaps CCSDS is the place to handle this. =20 Regarding time: I had a group in yesterday demonstrating a simple 3 node DTN network using the Soldier Radio Waveform. The first thing required was to manually synchronize the LAN portions of the radio. IMHO, the Time sync requirement (even loose time sync) makes DTN RFC5050 extremely fragile. Yes, time is used to expire bundles, but that could be done via priorities. Response to my question a few years ago about what do people set bundle lifetimes to indicated that generally it is the lifetime of the demonstration or something equivalent like 24 hours if your mining. The DINET deployment is a prime example. http://www.dtnrg.org/wiki/DtnBone Also, if you check the mail list archives, I believe nobody is using bundle lifetimes to make bundle forwarding decisions. Since so many deployments have been a sting of pearls with single source and all bundles set to the same lifetime, it wouldn't have mattered. In this instance, you will end up with a first-in, first-out queue regardless. Will ****************************** William D. Ivancic Phone 216-433-3494 Mobile 440-503-4892 http://roland.grc.nasa.gov/~ivancic On 6/4/14 4:55 PM, "Burleigh, Scott C (312G)" wrote: >Will, FWIW, the word we're hearing from our NASA sponsors is that DTN >will be baselined for everything that the Advanced Exploration Systems >program fields. I think this may be a case of not everybody necessarily >advertising everything they've got in the pipeline. > >As an aside, I have to point out that your observation that "Nobody is >using [time] or knows how to set it" is simply, categorically wrong. > >Scott > >-----Original Message----- >From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of Ivancic, William D. >(GRC-RHN0) >Sent: Wednesday, June 04, 2014 9:29 AM >To: Simon Perreault; dtn@ietf.org >Subject: Re: [dtn] Proposed Working Group Charter Suggestions > >I wouldn't even call it 5050bis as the changes would probably have to be >significant. =20 > >* Need for reliability check at least in the header. >* Need for hop count to eliminate routing loops. >* Really no need for time. Nobody is using it or knows how to set it. > >My question is "Who is deploying RFC5050 in any significant way to >justify a working group?" I think we have to be able to answer this >question if we really expect to proceed. Boeing hasn't indicated any >scaled deployment. I think DOD may have dropped it. I've only seen very >simple deployments of a few nodes. Epoxy and N4C may be the largest with >10 to perhaps 20? I think early work with DieselNet and others may have >been much larger deployments of store, carry and forward technologies. >NASA/DARPA SPHERES uses DTN Tunneling and is really a one-hop DTN >network. It works because SHPERES uses a publish/subscribe architecture >so the application doesn't really care/know if messages are missed or can >re-request during acquisition of signal. > >Here are the latest in NASA's plans that I know of. >http://ipnsig.org/wp-content/uploads/2014/02/ISS-DTN-Presentation-IPNSIG.p >d >f >http://www.docstoc.com/docs/158373645/CU-Boulder-ISS-Updatepptx > >Note, these are very simple deployments with only a few nodes and >probably can be accommodated with the current protocol > >Will >****************************** >William D. Ivancic >Phone 216-433-3494 >Mobile 440-503-4892 >http://roland.grc.nasa.gov/~ivancic > > > > > > >On 6/4/14 11:37 AM, "Simon Perreault" wrote: > >>One clear, objective criteria that I think we should agree on is that >>5050bis does not need to be backward compatible with 5050. >> >>Simon >> >>Le 2014-06-03 17:41, Burleigh, Scott C (312G) a =E9crit : >>> Hi, Stephen. In my mind those are not necessarily the only two >>>options. I definitely would not be in favor of starting from a blank >>>sheet of paper. A number of changes to BP have been proposed, at one >>>time or another, most of which I think have merit, and some of which >>>might be considered substantial. If those changes were made, would >>>the result be considered "5050 with minimal change"? The term >>>"minimal" is slippery here and, I think, generally not helpful. >>> >>> Maybe the charter clarification you're looking for could simply take >>>the form of a strawman list of proposed changes? >>> >>> Scott >> >>_______________________________________________ >>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 From nobody Wed Jun 4 15:10:08 2014 Return-Path: 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 333261A032D for ; Wed, 4 Jun 2014 15:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.841 X-Spam-Level: X-Spam-Status: No, score=-4.841 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] 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 kxdJZZO-9alX for ; Wed, 4 Jun 2014 15:10:01 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1105F1A032B for ; Wed, 4 Jun 2014 15:10:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s54M9sq6008938; Wed, 4 Jun 2014 17:09:54 -0500 Received: from XCH-PHX-312.sw.nos.boeing.com (xch-phx-312.sw.nos.boeing.com [130.247.25.173]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s54M9hxe008864 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Wed, 4 Jun 2014 17:09:51 -0500 Received: from XCH-BLV-405.nw.nos.boeing.com (2002:82f7:199e::82f7:199e) by XCH-PHX-312.sw.nos.boeing.com (2002:82f7:19ad::82f7:19ad) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 4 Jun 2014 15:09:43 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.105]) by XCH-BLV-405.nw.nos.boeing.com ([169.254.5.201]) with mapi id 14.03.0181.006; Wed, 4 Jun 2014 15:09:42 -0700 From: "Templin, Fred L" To: "dtn@ietf.org" Thread-Topic: DTN BoF Proposal for IETF90 Thread-Index: Ac+AQa9Fez/CplZaSwyaLFpzb8tj0w== Date: Wed, 4 Jun 2014 22:09:41 +0000 Message-ID: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: multipart/mixed; boundary="_002_2134F8430051B64F815C691A62D983181B2BE63EXCHBLV504nwnosb_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/25lQ3pFLK2hWh8m3UpGH4ykAwdA Subject: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 22:10:05 -0000 --_002_2134F8430051B64F815C691A62D983181B2BE63EXCHBLV504nwnosb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Based on discussions on the DTNRG list, here is a revised draft charter per the suggestions raised (see also attached diffs). Please respond to this thread for further BoF discussion. Thanks - Fred fred.l.templin@boeing.com --- Draft BoF Agenda (2.5hrs): ************************** 1) Problem statement (IETF wg motivation) - 30min 2) RFC5050(bis) - 30min 3) Streamlined Bundle Security Protocol (SBSP) - 30min 4) Bundle-in-Bundle Encapsulation - 15min 5) Security Key Management - 15min 6) Registry for Service Identifiers - 15min 7) Network Management - 15min Proposed working group charter: ******************************* Working group name:=20 Delay/Disruption Tolerant Networking Working Group (DTNWG) Chair(s): TBD Area and Area Director(s): Transport Area: ADs Spencer Dawkins , Martin Stiemerling Responsible Area Director: TBD Mailing list: General Discussion: dtn at ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dtn Archive: http://www.ietf.org/mail-archive/web/dtn/current/maillist.ht= ml Description of Working Group: The Delay/Disruption Tolerant Network Working Group (DTNWG) specifies mechanisms for data communications in the presence of long delays and/or intermittent connectivity. The work is motivated by well known limitations of standard Internet protocols that expect end-to-end connectivity between communicating endpoints, sub-second transmission delays and robust packet delivery ratios. In environments where these favorable conditions do not apply, existing mechanisms such as reliab= le transport protocols and routing protocols can fail to converge result= ing in communication failures. Furthermore, classical end-to-end security associations cannot be coordinated when communicating endpoints canno= t conduct multi-message keying exchanges in a timely fashion. These limitations suggest the need for a new approach.=20 =20 Delay-Tolerant Networking (DTN) protocols have been the subject of extensive research and development in the Delay-Tolerant Networking Research Group of the Internet Research Task Force since 2002. In particular, the DTN Bundle Protocol (RFC 5050) and Licklider Transmission Protocol (RFC 5326) have been shown to address the issues identified above. In 2008, BP/LTP was deployed on the EPOXI spacecraft in deep space and was used to conduct reliable, automated communication for four weeks over a network of 10 nodes in which the bottleneck router in the network (the spacecraft) was up to 100 light seconds from all other nodes and connectivity with the router was subject to periods of disconnection lasting several days. The success of the BP/LTP protocol stack -- the core protocols of the "DTN Architecture" originally described in RFC 4838 -- in this demonstration may be attributed to the following fundamental design principles: - There is never any expectation of contemporaneous end-to-end connectivity between any two network nodes. Where such connectivity is sustained, the protocols leverage it to optimize performance, but the possibility of transient but sustained disconnection at any time, anywhere in the network, is always recognized. - Because end-to-end connectivity can never be assumed, each node on the path between source and destination must be prepared to handle incoming "bundles" of data that cannot immediately be forwarded. Such bundles must either be stored for future trans- mission or discarded; in the latter case, the network must be informed of this data loss so that an alternative path may be selected, to avoid impairing the usability of the network. - Again because end-to-end connectivity can never be assumed, end-to-end conversational data exchange can never be assumed to complete in a timely manner; protocol features that rely on timely conversational data exchange must be excluded from the architecture. This principle makes the DTN architecture suitable not only for network environments characterized by lengthy disconnection but also for those that are characterized by long signal propagation delays (such as underwater communication by acoustic signals or, worse, interplanetary communication) even when connectivity is continuous. The DTNWG believes that protocols adhering to these principles offer opportunities for enhancing the functionality of the Internet - in particular, for facilitating the extension of the Internet into environments such as the ocean floor and deep space in which the core Internet protocols operate sub-optimally for the reasons discussed earlier. We believe that the extensive research, demonstration, and pilot operations performed to date using the DTNRG protocols, both before and after the EPOXI experiment, provides a firm basis for publishing Internet standards derived from that work. Work items related to Delay/Disruption Tolerant Networking include: o A mechanism for the exchange of protocol data units, termed "bundles", that are designed to obviate conversational communications by containing values for all potentially relevant configuration parameters. These protocol data units are typically larger than network-layer packets. We expect to derive this bundle exchange mechanism from the DTN Bundle Protocol (BP) documented in RFC 5050. Expected changes from RFC 5050 include (but are not necessarily limited to): - a compressed bundle header encoding (derived from RFC6260) - an immutable primary block structure - simplified EID representations (no dictionary) - add block ID to extension blocks (e.g. security blocks) - move custodian to extension block - add simple header and payload integrity checks - add simple contact graph routing specification - add simple neighbor discovery specification=20 o A security protocol for ensuring that the network in which bundles are exchanged is secured against unauthorized access and denial of service attacks, and to ensure data integrity and confidentiality in that network where necessary. We expect to derive this security protocol from a "streamlined" adaptation of the DTN Bundle Security Protocol documented in RFC 6257. o An encapsulation protocol for "tunneling" BP traffic within bundles that are secured and/or routed in different way from the encapsulated bundles. o A delay-tolerant security key management scheme for ensuring that public keys are certified by a globally trusted authority to protect the integrity of the infrastructure. o A simple datagram convergence layer protocol for adaptation of the bundle protocol to underlying internetworks. We expect to derive this convergence layer protocol from the Datagram Convergence protocol documented in RFC7122. o A delay-tolerant network management protocol for management of the infrastructure in the presence of long delays and/or intermittent connectivity. o A registry for DTN Service Identifiers =20 The working group will consider extending the current milestones based = on new information and knowledge gained while working on the initial chart= er, as well as to accommodate new work items beyond the scope of the initia= l phase. For example, we expect that transport protocols uniquely suited to the various communication environments that may need to be traversed by a single DTN end-to-end path (operating under BP, at what is termed the DTN "convergence layer") will need to be standardized in a second phase of the working group's charter; LTP and the Saratoga protocol are among the candidates for work in this phase. These adjustments will be accommodated in a working group recharter, assuming the initial chartered activities meet their delivery milestones. Possible new work items must then still fit into the (rechartered) DTNWG charter scope. =20 Goals and Milestones: start+3mos - Submit 'Bundle Protocol Specification (RFC5050bis)' as a working group document. To be Proposed Standard. Start+3mos - Submit 'Streamlined Bundle Security Protocol (SBSP)' as a working group document. To be Proposed Standard. start+6mos - Submit 'Bundle In Bundle Encapsulation (BIBE)' as a working group document. To be Proposed Standard. start+9mos - Submit 'Delay Tolerant Networking Security Key Management' a= s a working group document. To be Proposed Standard. start+9mos - WG determination for merging RFC5050bis, SBSP, BIBE and/or Key Mgmt into a combined draft or keep as separate drafts. start+12mos - Submit RFC5050bis, SBSP, BIBE and Key Mgmt to the IESG eith= er as a combined draft or as separate drafts. start+12mos - Submit Network Management, Registry and Simple Convergence Layer as working group documents. start+15mos - Survey appropriate forums (e.g., DTNRG) for emerging technologies (e.g., convergence layer protocols, dynamic routing protocols, naming and addressing services, etc.) ready for transition into IETF DTN Working Group. Publish draft on survey results as independent submission related to the WG. start+18mos - Submit Network Management, Registry and Simple Convergence Layer to IESG start+18mos - Recharter to accommodate new work items or close Working Gr= oup --_002_2134F8430051B64F815C691A62D983181B2BE63EXCHBLV504nwnosb_ Content-Type: text/html; name="wdiff 00a_txt 01a_txt.htm" Content-Description: wdiff 00a_txt 01a_txt.htm Content-Disposition: attachment; filename="wdiff 00a_txt 01a_txt.htm"; size=31046; creation-date="Wed, 04 Jun 2014 20:21:40 GMT"; modification-date="Wed, 04 Jun 2014 20:21:40 GMT" Content-Transfer-Encoding: base64 CjxodG1sPjxoZWFkPjx0aXRsZT53ZGlmZiAwMGEudHh0IDAxYS50eHQ8L3RpdGxlPjwvaGVhZD48 Ym9keT4KPHByZT4KRHJhZnQgQm9GIEFnZW5kYSAoMi41aHJzKToKKioqKioqKioqKioqKioqKioq KioqKioqKioKMSkgUHJvYmxlbSBzdGF0ZW1lbnQgKElFVEYgd2cgbW90aXZhdGlvbikgLSAzMG1p bgoKMikgUkZDNTA1MChiaXMpIC0gMzBtaW4KCjMpIFN0cmVhbWxpbmVkIEJ1bmRsZSBTZWN1cml0 eSBQcm90b2NvbCAoU0JTUCkgLSAzMG1pbgoKNCkgQnVuZGxlLWluLUJ1bmRsZSBFbmNhcHN1bGF0 aW9uIC0gPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJyA+MzAgbWluPC9mb250Pjwvc3RyaWtlPiA8 c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicgPjE1bWluPC9mb250Pjwvc3Ryb25nPgoKNSkgPHN0 cmlrZT48Zm9udCBjb2xvcj0ncmVkJyA+RFROPC9mb250Pjwvc3RyaWtlPiBTZWN1cml0eSBLZXkg TWFuYWdlbWVudCAtIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCcgPjMwbWluPC9mb250Pjwvc3Ry aWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicgPjE1bWluCgo2KSBSZWdpc3RyeSBmb3Ig U2VydmljZSBJZGVudGlmaWVycyAtIDE1bWluCgo3KSBOZXR3b3JrIE1hbmFnZW1lbnQgLSAxNW1p bjwvZm9udD48L3N0cm9uZz4KClByb3Bvc2VkIHdvcmtpbmcgZ3JvdXAgY2hhcnRlcjoKKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKgpXb3JraW5nIGdyb3VwIG5hbWU6CgogICAgICBEZWxh eS9EaXNydXB0aW9uIFRvbGVyYW50IE5ldHdvcmtpbmcgV29ya2luZyBHcm91cCAoRFROV0cpCgpD aGFpcihzKToKCiAgICAgIFRCRAoKQXJlYSBhbmQgQXJlYSBEaXJlY3RvcihzKToKCiAgICAgIFRy YW5zcG9ydCBBcmVhOiBBRHMgU3BlbmNlciBEYXdraW5zICZsdDtzcGVuY2VyZGF3a2lucy5pZXRm IGF0IGdtYWlsLmNvbSZndDssCiAgICAgICAgICAgICAgICAgICAgICAgICAgTWFydGluIFN0aWVt ZXJsaW5nICZsdDttbHMuaWV0ZiBhdCBnbWFpbC5jb20mZ3Q7CgpSZXNwb25zaWJsZSBBcmVhIERp cmVjdG9yOgoKICAgICAgVEJECgpNYWlsaW5nIGxpc3Q6CgogICAgICBHZW5lcmFsIERpc2N1c3Np b246IDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCcgPmR0bi1pbnRlcmVzdDwvZm9udD48L3N0cmlr ZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nID5kdG48L2ZvbnQ+PC9zdHJvbmc+IGF0IDxz dHJpa2U+PGZvbnQgY29sb3I9J3JlZCcgPmlydGYub3JnIChub3RlOiB1bnRpbCB3ZyBmb3JtZWQp PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicgPmlldGYub3JnPC9m b250Pjwvc3Ryb25nPgogICAgICBUbyBTdWJzY3JpYmU6IDxzdHJpa2U+PGZvbnQgY29sb3I9J3Jl ZCcgPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZHRuLWludGVyZXN0PC9m b250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicgPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZHRuPC9mb250Pjwvc3Ryb25nPgogICAgICBBcmNoaXZl OiA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnID5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJj aGl2ZS93ZWIvZHRuLWludGVyZXN0L2N1cnJlbnQvbWFpbGxpc3QuaHRtbDwvZm9udD48L3N0cmlr ZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nID5odHRwOi8vd3d3LmlldGYub3JnL21haWwt YXJjaGl2ZS93ZWIvZHRuL2N1cnJlbnQvbWFpbGxpc3QuaHRtbDwvZm9udD48L3N0cm9uZz4KCkRl c2NyaXB0aW9uIG9mIFdvcmtpbmcgR3JvdXA6CgogICAgICBUaGUgRGVsYXkvRGlzcnVwdGlvbiBU b2xlcmFudCBOZXR3b3JrIFdvcmtpbmcgR3JvdXAgKERUTldHKSBzcGVjaWZpZXMKICAgICAgbWVj aGFuaXNtcyBmb3IgZGF0YSBjb21tdW5pY2F0aW9ucyBpbiB0aGUgcHJlc2VuY2Ugb2YgbG9uZyBk ZWxheXMKICAgICAgYW5kL29yIGludGVybWl0dGVudCBjb25uZWN0aXZpdHkuIFRoZSB3b3JrIGlz IG1vdGl2YXRlZCBieSB3ZWxsIGtub3duCiAgICAgIGxpbWl0YXRpb25zIG9mIHN0YW5kYXJkIElu dGVybmV0IHByb3RvY29scyB0aGF0IGV4cGVjdCBlbmQtdG8tZW5kCiAgICAgIGNvbm5lY3Rpdml0 eSBiZXR3ZWVuIGNvbW11bmljYXRpbmcgZW5kcG9pbnRzLCBzdWItc2Vjb25kIHRyYW5zbWlzc2lv bgogICAgICBkZWxheXMgYW5kIHJvYnVzdCBwYWNrZXQgZGVsaXZlcnkgcmF0aW9zLiBJbiBlbnZp cm9ubWVudHMgd2hlcmUgdGhlc2UKICAgICAgZmF2b3JhYmxlIGNvbmRpdGlvbnMgZG8gbm90IGFw cGx5LCBleGlzdGluZyBtZWNoYW5pc21zIHN1Y2ggYXMgcmVsaWFibGUKICAgICAgdHJhbnNwb3J0 IHByb3RvY29scyBhbmQgcm91dGluZyBwcm90b2NvbHMgY2FuIGZhaWwgdG8gY29udmVyZ2UgcmVz dWx0aW5nCiAgICAgIGluIGNvbW11bmljYXRpb24gZmFpbHVyZXMuIEZ1cnRoZXJtb3JlLCBjbGFz c2ljYWwgZW5kLXRvLWVuZCBzZWN1cml0eQogICAgICBhc3NvY2lhdGlvbnMgY2Fubm90IGJlIGNv b3JkaW5hdGVkIHdoZW4gY29tbXVuaWNhdGluZyBlbmRwb2ludHMgY2Fubm90CiAgICAgIGNvbmR1 Y3QgbXVsdGktbWVzc2FnZSBrZXlpbmcgZXhjaGFuZ2VzIGluIGEgdGltZWx5IGZhc2hpb24uIFRo ZXNlCiAgICAgIGxpbWl0YXRpb25zIHN1Z2dlc3QgdGhlIG5lZWQgZm9yIGEgbmV3IGFwcHJvYWNo LgoKICAgICAgRGVsYXktVG9sZXJhbnQgTmV0d29ya2luZyAoRFROKSBwcm90b2NvbHMgaGF2ZSBi ZWVuIHRoZSBzdWJqZWN0IG9mCiAgICAgIGV4dGVuc2l2ZSByZXNlYXJjaCBhbmQgZGV2ZWxvcG1l bnQgaW4gdGhlIERlbGF5LVRvbGVyYW50IE5ldHdvcmtpbmcKICAgICAgUmVzZWFyY2ggR3JvdXAg b2YgdGhlIEludGVybmV0IFJlc2VhcmNoIFRhc2sgRm9yY2Ugc2luY2UgMjAwMi4gIEluCiAgICAg IHBhcnRpY3VsYXIsIHRoZSBEVE4gQnVuZGxlIFByb3RvY29sIChSRkMgNTA1MCkgYW5kIExpY2ts aWRlcgogICAgICBUcmFuc21pc3Npb24gUHJvdG9jb2wgKFJGQyA1MzI2KSBoYXZlIGJlZW4gc2hv d24gdG8gYWRkcmVzcyB0aGUKICAgICAgaXNzdWVzIGlkZW50aWZpZWQgYWJvdmUuICBJbiAyMDA4 LCBCUC9MVFAgd2FzIGRlcGxveWVkIG9uIHRoZSBFUE9YSQogICAgICBzcGFjZWNyYWZ0IGluIGRl ZXAgc3BhY2UgYW5kIHdhcyB1c2VkIHRvIGNvbmR1Y3QgcmVsaWFibGUsIGF1dG9tYXRlZAogICAg ICBjb21tdW5pY2F0aW9uIGZvciBmb3VyIHdlZWtzIG92ZXIgYSBuZXR3b3JrIG9mIDEwIG5vZGVz IGluIHdoaWNoIHRoZQogICAgICBib3R0bGVuZWNrIHJvdXRlciBpbiB0aGUgbmV0d29yayAodGhl IHNwYWNlY3JhZnQpIHdhcyB1cCB0byAxMDAgbGlnaHQKICAgICAgc2Vjb25kcyBmcm9tIGFsbCBv dGhlciBub2RlcyBhbmQgY29ubmVjdGl2aXR5IHdpdGggdGhlIHJvdXRlciB3YXMKICAgICAgc3Vi amVjdCB0byBwZXJpb2RzIG9mIGRpc2Nvbm5lY3Rpb24gbGFzdGluZyBzZXZlcmFsIGRheXMuCgog ICAgICBUaGUgc3VjY2VzcyBvZiB0aGUgQlAvTFRQIHByb3RvY29sIHN0YWNrIC0tIHRoZSBjb3Jl IHByb3RvY29scyBvZiB0aGUKICAgICAgIkRUTiBBcmNoaXRlY3R1cmUiIG9yaWdpbmFsbHkgZGVz Y3JpYmVkIGluIFJGQyA0ODM4IC0tIGluIHRoaXMKICAgICAgZGVtb25zdHJhdGlvbiBtYXkgYmUg YXR0cmlidXRlZCB0byB0aGUgZm9sbG93aW5nIGZ1bmRhbWVudGFsIGRlc2lnbgogICAgICBwcmlu Y2lwbGVzOgoKCS0gVGhlcmUgaXMgbmV2ZXIgYW55IGV4cGVjdGF0aW9uIG9mIGNvbnRlbXBvcmFu ZW91cyBlbmQtdG8tZW5kCiAgICAgICBjb25uZWN0aXZpdHkgYmV0d2VlbiBhbnkgdHdvIG5ldHdv cmsgbm9kZXMuICBXaGVyZSBzdWNoIGNvbm5lY3Rpdml0eQogICAgICAgaXMgc3VzdGFpbmVkLCB0 aGUgcHJvdG9jb2xzIGxldmVyYWdlIGl0IHRvIG9wdGltaXplIHBlcmZvcm1hbmNlLAogICAgICAg YnV0IHRoZSBwb3NzaWJpbGl0eSBvZiB0cmFuc2llbnQgYnV0IHN1c3RhaW5lZCBkaXNjb25uZWN0 aW9uIGF0CiAgICAgICBhbnkgdGltZSwgYW55d2hlcmUgaW4gdGhlIG5ldHdvcmssIGlzIGFsd2F5 cyByZWNvZ25pemVkLgoKCS0gQmVjYXVzZSBlbmQtdG8tZW5kIGNvbm5lY3Rpdml0eSBjYW4gbmV2 ZXIgYmUgYXNzdW1lZCwgZWFjaCBub2RlCgkgIG9uIHRoZSBwYXRoIGJldHdlZW4gc291cmNlIGFu ZCBkZXN0aW5hdGlvbiBtdXN0IGJlIHByZXBhcmVkIHRvCgkgIGhhbmRsZSBpbmNvbWluZyAiYnVu ZGxlcyIgb2YgZGF0YSB0aGF0IGNhbm5vdCBpbW1lZGlhdGVseSBiZQoJICBmb3J3YXJkZWQuICBT dWNoIGJ1bmRsZXMgbXVzdCBlaXRoZXIgYmUgc3RvcmVkIGZvciBmdXR1cmUgdHJhbnMtCgkgIG1p c3Npb24gb3IgZGlzY2FyZGVkOyBpbiB0aGUgbGF0dGVyIGNhc2UsIHRoZSBuZXR3b3JrIG11c3QK CSAgYmUgaW5mb3JtZWQgb2YgdGhpcyBkYXRhIGxvc3Mgc28gdGhhdCBhbiBhbHRlcm5hdGl2ZSBw YXRoIG1heQoJICBiZSBzZWxlY3RlZCwgdG8gYXZvaWQgaW1wYWlyaW5nIHRoZSB1c2FiaWxpdHkg b2YgdGhlIG5ldHdvcmsuCgoJLSBBZ2FpbiBiZWNhdXNlIGVuZC10by1lbmQgY29ubmVjdGl2aXR5 IGNhbiBuZXZlciBiZSBhc3N1bWVkLAoJICBlbmQtdG8tZW5kIGNvbnZlcnNhdGlvbmFsIGRhdGEg ZXhjaGFuZ2UgY2FuIG5ldmVyIGJlIGFzc3VtZWQgdG8KCSAgY29tcGxldGUgaW4gYSB0aW1lbHkg bWFubmVyOyBwcm90b2NvbCBmZWF0dXJlcyB0aGF0IHJlbHkgb24KCSAgdGltZWx5IGNvbnZlcnNh dGlvbmFsIGRhdGEgZXhjaGFuZ2UgbXVzdCBiZSBleGNsdWRlZCBmcm9tIHRoZQoJICBhcmNoaXRl Y3R1cmUuICBUaGlzIHByaW5jaXBsZSBtYWtlcyB0aGUgRFROIGFyY2hpdGVjdHVyZQoJICBzdWl0 YWJsZSBub3Qgb25seSBmb3IgbmV0d29yayBlbnZpcm9ubWVudHMgY2hhcmFjdGVyaXplZCBieQoJ ICBsZW5ndGh5IGRpc2Nvbm5lY3Rpb24gYnV0IGFsc28gZm9yIHRob3NlIHRoYXQgYXJlIGNoYXJh Y3Rlcml6ZWQKCSAgYnkgbG9uZyBzaWduYWwgcHJvcGFnYXRpb24gZGVsYXlzIChzdWNoIGFzIHVu ZGVyd2F0ZXIgY29tbXVuaWNhdGlvbgoJICBieSBhY291c3RpYyBzaWduYWxzIG9yLCB3b3JzZSwg aW50ZXJwbGFuZXRhcnkgY29tbXVuaWNhdGlvbikgZXZlbgoJICB3aGVuIGNvbm5lY3Rpdml0eSBp cyBjb250aW51b3VzLgoKICAgICAgVGhlIERUTldHIGJlbGlldmVzIHRoYXQgcHJvdG9jb2xzIGFk aGVyaW5nIHRvIHRoZXNlIHByaW5jaXBsZXMgb2ZmZXIKICAgICAgb3Bwb3J0dW5pdGllcyBmb3Ig ZW5oYW5jaW5nIHRoZSBmdW5jdGlvbmFsaXR5IG9mIHRoZSBJbnRlcm5ldCAtIGluCiAgICAgIHBh cnRpY3VsYXIsIGZvciBmYWNpbGl0YXRpbmcgdGhlIGV4dGVuc2lvbiBvZiB0aGUgSW50ZXJuZXQg aW50bwogICAgICBlbnZpcm9ubWVudHMgc3VjaCBhcyB0aGUgb2NlYW4gZmxvb3IgYW5kIGRlZXAg c3BhY2UgaW4gd2hpY2ggdGhlIGNvcmUKICAgICAgSW50ZXJuZXQgcHJvdG9jb2xzIG9wZXJhdGUg c3ViLW9wdGltYWxseSBmb3IgdGhlIHJlYXNvbnMgZGlzY3Vzc2VkCiAgICAgIGVhcmxpZXIuICBX ZSBiZWxpZXZlIHRoYXQgdGhlIGV4dGVuc2l2ZSByZXNlYXJjaCwgZGVtb25zdHJhdGlvbiwgYW5k CiAgICAgIHBpbG90IG9wZXJhdGlvbnMgcGVyZm9ybWVkIHRvIGRhdGUgdXNpbmcgdGhlIERUTlJH IHByb3RvY29scywgYm90aAogICAgICBiZWZvcmUgYW5kIGFmdGVyIHRoZSBFUE9YSSBleHBlcmlt ZW50LCBwcm92aWRlcyBhIGZpcm0gYmFzaXMgZm9yCiAgICAgIHB1Ymxpc2hpbmcgSW50ZXJuZXQg c3RhbmRhcmRzIGRlcml2ZWQgZnJvbSB0aGF0IHdvcmsuCgogICAgICBXb3JrIGl0ZW1zIHJlbGF0 ZWQgdG8gRGVsYXkvRGlzcnVwdGlvbiBUb2xlcmFudCBOZXR3b3JraW5nIGluY2x1ZGU6CgogICAg ICBvIEEgbWVjaGFuaXNtIGZvciB0aGUgZXhjaGFuZ2Ugb2YgcHJvdG9jb2wgZGF0YSB1bml0cywg dGVybWVkCgkiYnVuZGxlcyIsIHRoYXQgYXJlIGRlc2lnbmVkIHRvIG9idmlhdGUgY29udmVyc2F0 aW9uYWwgY29tbXVuaWNhdGlvbnMKCWJ5IGNvbnRhaW5pbmcgdmFsdWVzIGZvciBhbGwgcG90ZW50 aWFsbHkgcmVsZXZhbnQgY29uZmlndXJhdGlvbgoJcGFyYW1ldGVycy4gIFRoZXNlIHByb3RvY29s IGRhdGEgdW5pdHMgYXJlIHR5cGljYWxseSBsYXJnZXIgdGhhbgoJbmV0d29yay1sYXllciBwYWNr ZXRzLiAgV2UgZXhwZWN0IHRvIGRlcml2ZSB0aGlzIGJ1bmRsZSBleGNoYW5nZQoJbWVjaGFuaXNt IGZyb20gdGhlIERUTiBCdW5kbGUgUHJvdG9jb2wgKEJQKSBkb2N1bWVudGVkIGluIFJGQyA1MDUw LgogICAgICAgIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJyA+RXhwZWN0ZWQgY2hhbmdlcyBm cm9tIFJGQyA1MDUwIGluY2x1ZGUgKGJ1dCBhcmUgbm90IG5lY2Vzc2FyaWx5CiAgICAgICAgbGlt aXRlZCB0byk6CgogICAgICAgICAgIC0gYSBjb21wcmVzc2VkIGJ1bmRsZSBoZWFkZXIgZW5jb2Rp bmcgKGRlcml2ZWQgZnJvbSBSRkM2MjYwKQogICAgICAgICAgIC0gYW4gaW1tdXRhYmxlIHByaW1h cnkgYmxvY2sgc3RydWN0dXJlCiAgICAgICAgICAgLSBzaW1wbGlmaWVkIEVJRCByZXByZXNlbnRh dGlvbnMgKG5vIGRpY3Rpb25hcnkpCiAgICAgICAgICAgLSBhZGQgYmxvY2sgSUQgdG8gZXh0ZW5z aW9uIGJsb2NrcyAoZS5nLiBzZWN1cml0eSBibG9ja3MpCiAgICAgICAgICAgLSBtb3ZlIGN1c3Rv ZGlhbiB0byBleHRlbnNpb24gYmxvY2sKICAgICAgICAgICAtIGFkZCBzaW1wbGUgaGVhZGVyIGFu ZCBwYXlsb2FkIGludGVncml0eSBjaGVja3MKICAgICAgICAgICAtIGFkZCBzaW1wbGUgY29udGFj dCBncmFwaCByb3V0aW5nIHNwZWNpZmljYXRpb24KICAgICAgICAgICAtIGFkZCBzaW1wbGUgbmVp Z2hib3IgZGlzY292ZXJ5IHNwZWNpZmljYXRpb248L2ZvbnQ+PC9zdHJvbmc+CgogICAgICBvIEEg c2VjdXJpdHkgcHJvdG9jb2wgZm9yIGVuc3VyaW5nIHRoYXQgdGhlIG5ldHdvcmsgaW4gd2hpY2gg YnVuZGxlcwoJYXJlIGV4Y2hhbmdlZCBpcyBzZWN1cmVkIGFnYWluc3QgdW5hdXRob3JpemVkIGFj Y2VzcyBhbmQgZGVuaWFsIG9mCglzZXJ2aWNlIGF0dGFja3MsIGFuZCB0byBlbnN1cmUgZGF0YSBp bnRlZ3JpdHkgYW5kIGNvbmZpZGVudGlhbGl0eQoJaW4gdGhhdCBuZXR3b3JrIHdoZXJlIG5lY2Vz c2FyeS4gIFdlIGV4cGVjdCB0byBkZXJpdmUgdGhpcyBzZWN1cml0eQoJcHJvdG9jb2wgZnJvbSBh ICJzdHJlYW1saW5lZCIgYWRhcHRhdGlvbiBvZiB0aGUgRFROIEJ1bmRsZSBTZWN1cml0eQoJUHJv dG9jb2wgZG9jdW1lbnRlZCBpbiBSRkMgNjI1Ny4KCiAgICAgIG8gQW4gZW5jYXBzdWxhdGlvbiBw cm90b2NvbCBmb3IgInR1bm5lbGluZyIgQlAgdHJhZmZpYyB3aXRoaW4gYnVuZGxlcwoJdGhhdCBh cmUgc2VjdXJlZCBhbmQvb3Igcm91dGVkIGluIGRpZmZlcmVudCB3YXkgZnJvbSB0aGUgZW5jYXBz dWxhdGVkCglidW5kbGVzLgoKICAgICAgbyBBIGRlbGF5LXRvbGVyYW50IHNlY3VyaXR5IGtleSBt YW5hZ2VtZW50IHNjaGVtZSBmb3IgZW5zdXJpbmcgdGhhdAoJcHVibGljIGtleXMgYXJlIGNlcnRp ZmllZCBieSBhIGdsb2JhbGx5IHRydXN0ZWQgYXV0aG9yaXR5IHRvIHByb3RlY3QKCXRoZSBpbnRl Z3JpdHkgb2YgdGhlIGluZnJhc3RydWN0dXJlLgoKICAgICAgPHN0cm9uZz48Zm9udCBjb2xvcj0n Z3JlZW4nID5vIEEgc2ltcGxlIGRhdGFncmFtIGNvbnZlcmdlbmNlIGxheWVyIHByb3RvY29sIGZv ciBhZGFwdGF0aW9uIG9mIHRoZQogICAgICAgIGJ1bmRsZSBwcm90b2NvbCB0byB1bmRlcmx5aW5n IGludGVybmV0d29ya3MuIFdlIGV4cGVjdCB0byBkZXJpdmUKICAgICAgICB0aGlzIGNvbnZlcmdl bmNlIGxheWVyIHByb3RvY29sIGZyb20gdGhlIERhdGFncmFtIENvbnZlcmdlbmNlCiAgICAgICAg cHJvdG9jb2wgZG9jdW1lbnRlZCBpbiBSRkM3MTIyLgoKICAgICAgbyBBIGRlbGF5LXRvbGVyYW50 IG5ldHdvcmsgbWFuYWdlbWVudCBwcm90b2NvbCBmb3IgbWFuYWdlbWVudCBvZiB0aGUKICAgICAg ICBpbmZyYXN0cnVjdHVyZSBpbiB0aGUgcHJlc2VuY2Ugb2YgbG9uZyBkZWxheXMgYW5kL29yIGlu dGVybWl0dGVudAogICAgICAgIGNvbm5lY3Rpdml0eS4KCiAgICAgIG8gQSByZWdpc3RyeSBmb3Ig RFROIFNlcnZpY2UgSWRlbnRpZmllcnM8L2ZvbnQ+PC9zdHJvbmc+CgogICAgVGhlIHdvcmtpbmcg Z3JvdXAgd2lsbCBjb25zaWRlciBleHRlbmRpbmcgdGhlIGN1cnJlbnQgbWlsZXN0b25lcyBiYXNl ZCBvbgogICAgbmV3IGluZm9ybWF0aW9uIGFuZCBrbm93bGVkZ2UgZ2FpbmVkIHdoaWxlIHdvcmtp bmcgb24gdGhlIGluaXRpYWwgY2hhcnRlciwKICAgIGFzIHdlbGwgYXMgdG8gYWNjb21tb2RhdGUg bmV3IHdvcmsgaXRlbXMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGUgaW5pdGlhbAogICAgcGhhc2Uu ICBGb3IgZXhhbXBsZSwgd2UgZXhwZWN0IHRoYXQgdHJhbnNwb3J0IHByb3RvY29scyB1bmlxdWVs eSBzdWl0ZWQKICAgIHRvIHRoZSB2YXJpb3VzIGNvbW11bmljYXRpb24gZW52aXJvbm1lbnRzIHRo YXQgbWF5IG5lZWQgdG8gYmUgdHJhdmVyc2VkCiAgICBieSBhIHNpbmdsZSBEVE4gZW5kLXRvLWVu ZCBwYXRoIChvcGVyYXRpbmcgdW5kZXIgQlAsIGF0IHdoYXQgaXMgdGVybWVkCiAgICB0aGUgRFRO ICJjb252ZXJnZW5jZSBsYXllciIpIHdpbGwgbmVlZCB0byBiZSBzdGFuZGFyZGl6ZWQgaW4gYSBz ZWNvbmQKICAgIHBoYXNlIG9mIHRoZSB3b3JraW5nIGdyb3VwJ3MgY2hhcnRlcjsgTFRQIGFuZCB0 aGUgU2FyYXRvZ2EgcHJvdG9jb2wgYXJlCiAgICBhbW9uZyB0aGUgY2FuZGlkYXRlcyBmb3Igd29y ayBpbiB0aGlzIHBoYXNlLiAgVGhlc2UgYWRqdXN0bWVudHMgd2lsbCBiZQogICAgYWNjb21tb2Rh dGVkIGluIGEgd29ya2luZyBncm91cCByZWNoYXJ0ZXIsIGFzc3VtaW5nIHRoZSBpbml0aWFsCiAg ICBjaGFydGVyZWQgYWN0aXZpdGllcyBtZWV0IHRoZWlyIGRlbGl2ZXJ5IG1pbGVzdG9uZXMuIFBv c3NpYmxlIG5ldyB3b3JrCiAgICBpdGVtcyBtdXN0IHRoZW4gc3RpbGwgZml0IGludG8gdGhlIChy ZWNoYXJ0ZXJlZCkgRFROV0cgY2hhcnRlciBzY29wZS4KCkdvYWxzIGFuZCBNaWxlc3RvbmVzOgog IHN0YXJ0KzNtb3MgLSBTdWJtaXQgJ0J1bmRsZSBQcm90b2NvbCBTcGVjaWZpY2F0aW9uIChSRkM1 MDUwYmlzKScgYXMgYQogICAgICAgICAgICAgICAgICAgICAgd29ya2luZyBncm91cCBkb2N1bWVu dC4gVG8gYmUgUHJvcG9zZWQgU3RhbmRhcmQuCiAgU3RhcnQrM21vcyAtIFN1Ym1pdCAnU3RyZWFt bGluZWQgQnVuZGxlIFNlY3VyaXR5IFByb3RvY29sIChTQlNQKScgYXMgYQogICAgICAgICAgICAg ICAgICAgICAgIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuIFRvIGJlIFByb3Bvc2VkIFN0YW5kYXJk LgogIHN0YXJ0KzZtb3MgLSBTdWJtaXQgJ0J1bmRsZSBJbiBCdW5kbGUgRW5jYXBzdWxhdGlvbiAo QklCRSknIGFzIGEgd29ya2luZwogICAgICAgICAgICAgICAgICAgICAgZ3JvdXAgZG9jdW1lbnQu IFRvIGJlIFByb3Bvc2VkIFN0YW5kYXJkLgogIHN0YXJ0Kzltb3MgLSBTdWJtaXQgJ0RlbGF5IFRv bGVyYW50IE5ldHdvcmtpbmcgU2VjdXJpdHkgS2V5IE1hbmFnZW1lbnQnIGFzCiAgICAgICAgICAg ICAgICAgICAgICBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuIFRvIGJlIFByb3Bvc2VkIFN0YW5k YXJkLgogIHN0YXJ0Kzltb3MgLSA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnID5TdWJtaXQgJ0J1 bmRsZSBQcm90b2NvbCBTcGVjaWZpY2F0aW9uIChSRkM1MDUwYmlzKScgdG8gdGhlCiAgICAgICAg ICAgICAgICAgICAgICBJRVNHLiBUbyBiZSBQcm9wb3NlZCBTdGFuZGFyZC4KICBzdGFydCs5bW9z PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicgPldHIGRldGVybWlu YXRpb24gZm9yIG1lcmdpbmcgUkZDNTA1MGJpcywgU0JTUCwgQklCRSBhbmQvb3IKICAgICAgICAg ICAgICAgS2V5IE1nbXQgaW50byBhIGNvbWJpbmVkIGRyYWZ0IG9yIGtlZXAgYXMgc2VwYXJhdGUg ZHJhZnRzLgogIHN0YXJ0KzEybW9zPC9mb250Pjwvc3Ryb25nPiAtIFN1Ym1pdCA8c3RyaWtlPjxm b250IGNvbG9yPSdyZWQnID4nU3RyZWFtbGluZWQgQnVuZGxlIFNlY3VyaXR5IFByb3RvY29sIChT QlNQKSc8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJyA+UkZDNTA1 MGJpcywgU0JTUCwgQklCRSBhbmQgS2V5IE1nbXQ8L2ZvbnQ+PC9zdHJvbmc+IHRvIHRoZQogICAg ICAgICAgICAgICAgICAgICAgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJyA+SUVTRy4gVG8gYmUg UHJvcG9zZWQgU3RhbmRhcmQuCiAgc3RhcnQrMTBtb3M8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+ PGZvbnQgY29sb3I9J2dyZWVuJyA+SUVTRyBlaXRoZXIKICAgICAgICAgICAgICAgIGFzIGEgY29t YmluZWQgZHJhZnQgb3IgYXMgc2VwYXJhdGUgZHJhZnRzLgogIHN0YXJ0KzEybW9zPC9mb250Pjwv c3Ryb25nPiAtIFN1Ym1pdCA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnID4nQnVuZGxlIEluIEJ1 bmRsZSBFbmNhcHN1bGF0aW9uIChCSUJFKSc8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQg Y29sb3I9J2dyZWVuJyA+TmV0d29yayBNYW5hZ2VtZW50LCBSZWdpc3RyeSBhbmQgU2ltcGxlIENv bnZlcmdlbmNlCiAgICAgICAgICAgICAgICBMYXllciBhcyB3b3JraW5nIGdyb3VwIGRvY3VtZW50 cy4KICBzdGFydCsxNW1vcyAtIFN1cnZleSBhcHByb3ByaWF0ZSBmb3J1bXMgKGUuZy4sIERUTlJH KSBmb3IgZW1lcmdpbmcKICAgICAgICAgICAgICAgIHRlY2hub2xvZ2llcyAoZS5nLiwgY29udmVy Z2VuY2UgbGF5ZXIgcHJvdG9jb2xzLCBkeW5hbWljCiAgICAgICAgICAgICAgICByb3V0aW5nIHBy b3RvY29scywgbmFtaW5nIGFuZCBhZGRyZXNzaW5nIHNlcnZpY2VzLCBldGMuKQogICAgICAgICAg ICAgICAgcmVhZHkgZm9yIHRyYW5zaXRpb24gaW50byBJRVRGIERUTiBXb3JraW5nIEdyb3VwLiBQ dWJsaXNoCiAgICAgICAgICAgICAgICBkcmFmdCBvbiBzdXJ2ZXkgcmVzdWx0cyBhcyBpbmRlcGVu ZGVudCBzdWJtaXNzaW9uIHJlbGF0ZWQ8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICAgICAgICAgICB0 byB0aGUgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJyA+SUVTRy4KICAgICAgICAgICAgICAgICAg ICAgICBUbyBiZSBQcm9wb3NlZCBTdGFuZGFyZC4KICBzdGFydCsxMW1vczwvZm9udD48L3N0cmlr ZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nID5XRy4KICBzdGFydCsxOG1vczwvZm9udD48 L3N0cm9uZz4gLSBTdWJtaXQgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJyA+J0RlbGF5IFRvbGVy YW50IE5ldHdvcmtpbmcgU2VjdXJpdHkgS2V5IE1hbmFnZW1lbnQnPC9mb250Pjwvc3RyaWtlPiA8 c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicgPk5ldHdvcmsgTWFuYWdlbWVudCwgUmVnaXN0cnkg YW5kIFNpbXBsZSBDb252ZXJnZW5jZQogICAgICAgICAgICAgICAgTGF5ZXI8L2ZvbnQ+PC9zdHJv bmc+IHRvCiAgICAgICAgICAgICAgICAgICAgICAgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJyA+ dGhlIElFU0cuIFRvIGJlIFByb3Bvc2VkIFN0YW5kYXJkLgogIHN0YXJ0KzEybW9zPC9mb250Pjwv c3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicgPklFU0cKICBzdGFydCsxOG1vczwv Zm9udD48L3N0cm9uZz4gLSBSZWNoYXJ0ZXIgdG8gYWNjb21tb2RhdGUgbmV3IHdvcmsgaXRlbXMg b3IgY2xvc2UgV29ya2luZyBHcm91cAo8L3ByZT4KPC9ib2R5PjwvaHRtbD4KWC1HZW5lcmF0b3I6 IHB5aHQgMC4zNQoKPCEtLSBhcmdzOiB7Jy0tb2xkY29sb3VyJzogJ3JlZCcsICctLXdpZHRoJzog JycsICdkaWZmdHlwZSc6ICctLWh3ZGlmZicsICdmaWxlbmFtZTInOiAnRHJhZnQgQm9GIEFnZW5k YSAoMi41aHJzKTpcclxuKioqKioqKioqKioqKioqKioqKioqKioqKipcclxuMSkgUHJvYmxlbSBz dGF0ZW1lbnQgKElFVEYgd2cgbW90aXZhdGlvbikgLSAzMG1pblxyXG5cclxuMikgUkZDNTA1MChi aXMpIC0gMzBtaW5cclxuXHJcbjMpIFN0cmVhbWxpbmVkIEJ1bmRsZSBTZWN1cml0eSBQcm90b2Nv bCAoU0JTUCkgLSAzMG1pblxyXG5cclxuNCkgQnVuZGxlLWluLUJ1bmRsZSBFbmNhcHN1bGF0aW9u IC0gMTVtaW5cclxuXHJcbjUpIFNlY3VyaXR5IEtleSBNYW5hZ2VtZW50IC0gMTVtaW5cclxuXHJc bjYpIFJlZ2lzdHJ5IGZvciBTZXJ2aWNlIElkZW50aWZpZXJzIC0gMTVtaW5cclxuXHJcbjcpIE5l dHdvcmsgTWFuYWdlbWVudCAtIDE1bWluXHJcblxyXG5cclxuUHJvcG9zZWQgd29ya2luZyBncm91 cCBjaGFydGVyOlxyXG4qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqXHJcbldvcmtpbmcg Z3JvdXAgbmFtZTogXHJcblxyXG4gICAgICBEZWxheS9EaXNydXB0aW9uIFRvbGVyYW50IE5ldHdv cmtpbmcgV29ya2luZyBHcm91cCAoRFROV0cpXHJcblxyXG5DaGFpcihzKTpcclxuXHJcbiAgICAg IFRCRFxyXG5cclxuQXJlYSBhbmQgQXJlYSBEaXJlY3RvcihzKTpcclxuXHJcbiAgICAgIFRyYW5z cG9ydCBBcmVhOiBBRHMgU3BlbmNlciBEYXdraW5zIF9zcGVuY2VyZGF3a2lucy5pZXRmIGF0IGdt YWlsLmNvbV8sXHJcbiAgICAgICAgICAgICAgICAgICAgICAgICAgTWFydGluIFN0aWVtZXJsaW5n IF9tbHMuaWV0ZiBhdCBnbWFpbC5jb21fXHJcblxyXG5SZXNwb25zaWJsZSBBcmVhIERpcmVjdG9y OlxyXG5cclxuICAgICAgVEJEXHJcblxyXG5NYWlsaW5nIGxpc3Q6XHJcblxyXG4gICAgICBHZW5l cmFsIERpc2N1c3Npb246IGR0biBhdCBpZXRmLm9yZ1xyXG4gICAgICBUbyBTdWJzY3JpYmU6IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZHRuXHJcbiAgICAgIEFyY2hpdmU6 IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9kdG4vY3VycmVudC9tYWlsbGlz dC5odG1sXHJcblxyXG5EZXNjcmlwdGlvbiBvZiBXb3JraW5nIEdyb3VwOlxyXG5cclxuICAgICAg VGhlIERlbGF5L0Rpc3J1cHRpb24gVG9sZXJhbnQgTmV0d29yayBXb3JraW5nIEdyb3VwIChEVE5X Rykgc3BlY2lmaWVzXHJcbiAgICAgIG1lY2hhbmlzbXMgZm9yIGRhdGEgY29tbXVuaWNhdGlvbnMg aW4gdGhlIHByZXNlbmNlIG9mIGxvbmcgZGVsYXlzXHJcbiAgICAgIGFuZC9vciBpbnRlcm1pdHRl bnQgY29ubmVjdGl2aXR5LiBUaGUgd29yayBpcyBtb3RpdmF0ZWQgYnkgd2VsbCBrbm93blxyXG4g ICAgICBsaW1pdGF0aW9ucyBvZiBzdGFuZGFyZCBJbnRlcm5ldCBwcm90b2NvbHMgdGhhdCBleHBl Y3QgZW5kLXRvLWVuZFxyXG4gICAgICBjb25uZWN0aXZpdHkgYmV0d2VlbiBjb21tdW5pY2F0aW5n IGVuZHBvaW50cywgc3ViLXNlY29uZCB0cmFuc21pc3Npb25cclxuICAgICAgZGVsYXlzIGFuZCBy b2J1c3QgcGFja2V0IGRlbGl2ZXJ5IHJhdGlvcy4gSW4gZW52aXJvbm1lbnRzIHdoZXJlIHRoZXNl XHJcbiAgICAgIGZhdm9yYWJsZSBjb25kaXRpb25zIGRvIG5vdCBhcHBseSwgZXhpc3RpbmcgbWVj aGFuaXNtcyBzdWNoIGFzIHJlbGlhYmxlXHJcbiAgICAgIHRyYW5zcG9ydCBwcm90b2NvbHMgYW5k IHJvdXRpbmcgcHJvdG9jb2xzIGNhbiBmYWlsIHRvIGNvbnZlcmdlIHJlc3VsdGluZ1xyXG4gICAg ICBpbiBjb21tdW5pY2F0aW9uIGZhaWx1cmVzLiBGdXJ0aGVybW9yZSwgY2xhc3NpY2FsIGVuZC10 by1lbmQgc2VjdXJpdHlcclxuICAgICAgYXNzb2NpYXRpb25zIGNhbm5vdCBiZSBjb29yZGluYXRl ZCB3aGVuIGNvbW11bmljYXRpbmcgZW5kcG9pbnRzIGNhbm5vdFxyXG4gICAgICBjb25kdWN0IG11 bHRpLW1lc3NhZ2Uga2V5aW5nIGV4Y2hhbmdlcyBpbiBhIHRpbWVseSBmYXNoaW9uLiBUaGVzZVxy XG4gICAgICBsaW1pdGF0aW9ucyBzdWdnZXN0IHRoZSBuZWVkIGZvciBhIG5ldyBhcHByb2FjaC4g XHJcbiAgICAgIFxyXG4gICAgICBEZWxheS1Ub2xlcmFudCBOZXR3b3JraW5nIChEVE4pIHByb3Rv Y29scyBoYXZlIGJlZW4gdGhlIHN1YmplY3Qgb2ZcclxuICAgICAgZXh0ZW5zaXZlIHJlc2VhcmNo IGFuZCBkZXZlbG9wbWVudCBpbiB0aGUgRGVsYXktVG9sZXJhbnQgTmV0d29ya2luZ1xyXG4gICAg ICBSZXNlYXJjaCBHcm91cCBvZiB0aGUgSW50ZXJuZXQgUmVzZWFyY2ggVGFzayBGb3JjZSBzaW5j ZSAyMDAyLiAgSW5cclxuICAgICAgcGFydGljdWxhciwgdGhlIERUTiBCdW5kbGUgUHJvdG9jb2wg KFJGQyA1MDUwKSBhbmQgTGlja2xpZGVyXHJcbiAgICAgIFRyYW5zbWlzc2lvbiBQcm90b2NvbCAo UkZDIDUzMjYpIGhhdmUgYmVlbiBzaG93biB0byBhZGRyZXNzIHRoZVxyXG4gICAgICBpc3N1ZXMg aWRlbnRpZmllZCBhYm92ZS4gIEluIDIwMDgsIEJQL0xUUCB3YXMgZGVwbG95ZWQgb24gdGhlIEVQ T1hJXHJcbiAgICAgIHNwYWNlY3JhZnQgaW4gZGVlcCBzcGFjZSBhbmQgd2FzIHVzZWQgdG8gY29u ZHVjdCByZWxpYWJsZSwgYXV0b21hdGVkXHJcbiAgICAgIGNvbW11bmljYXRpb24gZm9yIGZvdXIg d2Vla3Mgb3ZlciBhIG5ldHdvcmsgb2YgMTAgbm9kZXMgaW4gd2hpY2ggdGhlXHJcbiAgICAgIGJv dHRsZW5lY2sgcm91dGVyIGluIHRoZSBuZXR3b3JrICh0aGUgc3BhY2VjcmFmdCkgd2FzIHVwIHRv IDEwMCBsaWdodFxyXG4gICAgICBzZWNvbmRzIGZyb20gYWxsIG90aGVyIG5vZGVzIGFuZCBjb25u ZWN0aXZpdHkgd2l0aCB0aGUgcm91dGVyIHdhc1xyXG4gICAgICBzdWJqZWN0IHRvIHBlcmlvZHMg b2YgZGlzY29ubmVjdGlvbiBsYXN0aW5nIHNldmVyYWwgZGF5cy5cclxuXHJcbiAgICAgIFRoZSBz dWNjZXNzIG9mIHRoZSBCUC9MVFAgcHJvdG9jb2wgc3RhY2sgLS0gdGhlIGNvcmUgcHJvdG9jb2xz IG9mIHRoZVxyXG4gICAgICAiRFROIEFyY2hpdGVjdHVyZSIgb3JpZ2luYWxseSBkZXNjcmliZWQg aW4gUkZDIDQ4MzggLS0gaW4gdGhpc1xyXG4gICAgICBkZW1vbnN0cmF0aW9uIG1heSBiZSBhdHRy aWJ1dGVkIHRvIHRoZSBmb2xsb3dpbmcgZnVuZGFtZW50YWwgZGVzaWduXHJcbiAgICAgIHByaW5j aXBsZXM6XHJcblxyXG5cdC0gVGhlcmUgaXMgbmV2ZXIgYW55IGV4cGVjdGF0aW9uIG9mIGNvbnRl bXBvcmFuZW91cyBlbmQtdG8tZW5kXHJcbiAgICAgICBjb25uZWN0aXZpdHkgYmV0d2VlbiBhbnkg dHdvIG5ldHdvcmsgbm9kZXMuICBXaGVyZSBzdWNoIGNvbm5lY3Rpdml0eVxyXG4gICAgICAgaXMg c3VzdGFpbmVkLCB0aGUgcHJvdG9jb2xzIGxldmVyYWdlIGl0IHRvIG9wdGltaXplIHBlcmZvcm1h bmNlLFxyXG4gICAgICAgYnV0IHRoZSBwb3NzaWJpbGl0eSBvZiB0cmFuc2llbnQgYnV0IHN1c3Rh aW5lZCBkaXNjb25uZWN0aW9uIGF0XHJcbiAgICAgICBhbnkgdGltZSwgYW55d2hlcmUgaW4gdGhl IG5ldHdvcmssIGlzIGFsd2F5cyByZWNvZ25pemVkLlxyXG5cclxuXHQtIEJlY2F1c2UgZW5kLXRv LWVuZCBjb25uZWN0aXZpdHkgY2FuIG5ldmVyIGJlIGFzc3VtZWQsIGVhY2ggbm9kZVxyXG5cdCAg b24gdGhlIHBhdGggYmV0d2VlbiBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uIG11c3QgYmUgcHJlcGFy ZWQgdG9cclxuXHQgIGhhbmRsZSBpbmNvbWluZyAiYnVuZGxlcyIgb2YgZGF0YSB0aGF0IGNhbm5v dCBpbW1lZGlhdGVseSBiZVxyXG5cdCAgZm9yd2FyZGVkLiAgU3VjaCBidW5kbGVzIG11c3QgZWl0 aGVyIGJlIHN0b3JlZCBmb3IgZnV0dXJlIHRyYW5zLVxyXG5cdCAgbWlzc2lvbiBvciBkaXNjYXJk ZWQ7IGluIHRoZSBsYXR0ZXIgY2FzZSwgdGhlIG5ldHdvcmsgbXVzdFxyXG5cdCAgYmUgaW5mb3Jt ZWQgb2YgdGhpcyBkYXRhIGxvc3Mgc28gdGhhdCBhbiBhbHRlcm5hdGl2ZSBwYXRoIG1heVxyXG5c dCAgYmUgc2VsZWN0ZWQsIHRvIGF2b2lkIGltcGFpcmluZyB0aGUgdXNhYmlsaXR5IG9mIHRoZSBu ZXR3b3JrLlxyXG5cclxuXHQtIEFnYWluIGJlY2F1c2UgZW5kLXRvLWVuZCBjb25uZWN0aXZpdHkg Y2FuIG5ldmVyIGJlIGFzc3VtZWQsXHJcblx0ICBlbmQtdG8tZW5kIGNvbnZlcnNhdGlvbmFsIGRh dGEgZXhjaGFuZ2UgY2FuIG5ldmVyIGJlIGFzc3VtZWQgdG9cclxuXHQgIGNvbXBsZXRlIGluIGEg dGltZWx5IG1hbm5lcjsgcHJvdG9jb2wgZmVhdHVyZXMgdGhhdCByZWx5IG9uXHJcblx0ICB0aW1l bHkgY29udmVyc2F0aW9uYWwgZGF0YSBleGNoYW5nZSBtdXN0IGJlIGV4Y2x1ZGVkIGZyb20gdGhl XHJcblx0ICBhcmNoaXRlY3R1cmUuICBUaGlzIHByaW5jaXBsZSBtYWtlcyB0aGUgRFROIGFyY2hp dGVjdHVyZVxyXG5cdCAgc3VpdGFibGUgbm90IG9ubHkgZm9yIG5ldHdvcmsgZW52aXJvbm1lbnRz IGNoYXJhY3Rlcml6ZWQgYnlcclxuXHQgIGxlbmd0aHkgZGlzY29ubmVjdGlvbiBidXQgYWxzbyBm b3IgdGhvc2UgdGhhdCBhcmUgY2hhcmFjdGVyaXplZFxyXG5cdCAgYnkgbG9uZyBzaWduYWwgcHJv cGFnYXRpb24gZGVsYXlzIChzdWNoIGFzIHVuZGVyd2F0ZXIgY29tbXVuaWNhdGlvblxyXG5cdCAg YnkgYWNvdXN0aWMgc2lnbmFscyBvciwgd29yc2UsIGludGVycGxhbmV0YXJ5IGNvbW11bmljYXRp b24pIGV2ZW5cclxuXHQgIHdoZW4gY29ubmVjdGl2aXR5IGlzIGNvbnRpbnVvdXMuXHJcblxyXG4g ICAgICBUaGUgRFROV0cgYmVsaWV2ZXMgdGhhdCBwcm90b2NvbHMgYWRoZXJpbmcgdG8gdGhlc2Ug cHJpbmNpcGxlcyBvZmZlclxyXG4gICAgICBvcHBvcnR1bml0aWVzIGZvciBlbmhhbmNpbmcgdGhl IGZ1bmN0aW9uYWxpdHkgb2YgdGhlIEludGVybmV0IC0gaW5cclxuICAgICAgcGFydGljdWxhciwg Zm9yIGZhY2lsaXRhdGluZyB0aGUgZXh0ZW5zaW9uIG9mIHRoZSBJbnRlcm5ldCBpbnRvXHJcbiAg ICAgIGVudmlyb25tZW50cyBzdWNoIGFzIHRoZSBvY2VhbiBmbG9vciBhbmQgZGVlcCBzcGFjZSBp biB3aGljaCB0aGUgY29yZVxyXG4gICAgICBJbnRlcm5ldCBwcm90b2NvbHMgb3BlcmF0ZSBzdWIt b3B0aW1hbGx5IGZvciB0aGUgcmVhc29ucyBkaXNjdXNzZWRcclxuICAgICAgZWFybGllci4gIFdl IGJlbGlldmUgdGhhdCB0aGUgZXh0ZW5zaXZlIHJlc2VhcmNoLCBkZW1vbnN0cmF0aW9uLCBhbmRc clxuICAgICAgcGlsb3Qgb3BlcmF0aW9ucyBwZXJmb3JtZWQgdG8gZGF0ZSB1c2luZyB0aGUgRFRO UkcgcHJvdG9jb2xzLCBib3RoXHJcbiAgICAgIGJlZm9yZSBhbmQgYWZ0ZXIgdGhlIEVQT1hJIGV4 cGVyaW1lbnQsIHByb3ZpZGVzIGEgZmlybSBiYXNpcyBmb3JcclxuICAgICAgcHVibGlzaGluZyBJ bnRlcm5ldCBzdGFuZGFyZHMgZGVyaXZlZCBmcm9tIHRoYXQgd29yay5cclxuXHJcbiAgICAgIFdv cmsgaXRlbXMgcmVsYXRlZCB0byBEZWxheS9EaXNydXB0aW9uIFRvbGVyYW50IE5ldHdvcmtpbmcg aW5jbHVkZTpcclxuXHJcbiAgICAgIG8gQSBtZWNoYW5pc20gZm9yIHRoZSBleGNoYW5nZSBvZiBw cm90b2NvbCBkYXRhIHVuaXRzLCB0ZXJtZWRcclxuXHQiYnVuZGxlcyIsIHRoYXQgYXJlIGRlc2ln bmVkIHRvIG9idmlhdGUgY29udmVyc2F0aW9uYWwgY29tbXVuaWNhdGlvbnNcclxuXHRieSBjb250 YWluaW5nIHZhbHVlcyBmb3IgYWxsIHBvdGVudGlhbGx5IHJlbGV2YW50IGNvbmZpZ3VyYXRpb25c clxuXHRwYXJhbWV0ZXJzLiAgVGhlc2UgcHJvdG9jb2wgZGF0YSB1bml0cyBhcmUgdHlwaWNhbGx5 IGxhcmdlciB0aGFuXHJcblx0bmV0d29yay1sYXllciBwYWNrZXRzLiAgV2UgZXhwZWN0IHRvIGRl cml2ZSB0aGlzIGJ1bmRsZSBleGNoYW5nZVxyXG5cdG1lY2hhbmlzbSBmcm9tIHRoZSBEVE4gQnVu ZGxlIFByb3RvY29sIChCUCkgZG9jdW1lbnRlZCBpbiBSRkMgNTA1MC5cclxuICAgICAgICBFeHBl Y3RlZCBjaGFuZ2VzIGZyb20gUkZDIDUwNTAgaW5jbHVkZSAoYnV0IGFyZSBub3QgbmVjZXNzYXJp bHlcclxuICAgICAgICBsaW1pdGVkIHRvKTpcclxuXHJcbiAgICAgICAgICAgLSBhIGNvbXByZXNz ZWQgYnVuZGxlIGhlYWRlciBlbmNvZGluZyAoZGVyaXZlZCBmcm9tIFJGQzYyNjApXHJcbiAgICAg ICAgICAgLSBhbiBpbW11dGFibGUgcHJpbWFyeSBibG9jayBzdHJ1Y3R1cmVcclxuICAgICAgICAg ICAtIHNpbXBsaWZpZWQgRUlEIHJlcHJlc2VudGF0aW9ucyAobm8gZGljdGlvbmFyeSlcclxuICAg ICAgICAgICAtIGFkZCBibG9jayBJRCB0byBleHRlbnNpb24gYmxvY2tzIChlLmcuIHNlY3VyaXR5 IGJsb2NrcylcclxuICAgICAgICAgICAtIG1vdmUgY3VzdG9kaWFuIHRvIGV4dGVuc2lvbiBibG9j a1xyXG4gICAgICAgICAgIC0gYWRkIHNpbXBsZSBoZWFkZXIgYW5kIHBheWxvYWQgaW50ZWdyaXR5 IGNoZWNrc1xyXG4gICAgICAgICAgIC0gYWRkIHNpbXBsZSBjb250YWN0IGdyYXBoIHJvdXRpbmcg c3BlY2lmaWNhdGlvblxyXG4gICAgICAgICAgIC0gYWRkIHNpbXBsZSBuZWlnaGJvciBkaXNjb3Zl cnkgc3BlY2lmaWNhdGlvbiBcclxuXHJcbiAgICAgIG8gQSBzZWN1cml0eSBwcm90b2NvbCBmb3Ig ZW5zdXJpbmcgdGhhdCB0aGUgbmV0d29yayBpbiB3aGljaCBidW5kbGVzXHJcblx0YXJlIGV4Y2hh bmdlZCBpcyBzZWN1cmVkIGFnYWluc3QgdW5hdXRob3JpemVkIGFjY2VzcyBhbmQgZGVuaWFsIG9m XHJcblx0c2VydmljZSBhdHRhY2tzLCBhbmQgdG8gZW5zdXJlIGRhdGEgaW50ZWdyaXR5IGFuZCBj b25maWRlbnRpYWxpdHlcclxuXHRpbiB0aGF0IG5ldHdvcmsgd2hlcmUgbmVjZXNzYXJ5LiAgV2Ug ZXhwZWN0IHRvIGRlcml2ZSB0aGlzIHNlY3VyaXR5XHJcblx0cHJvdG9jb2wgZnJvbSBhICJzdHJl YW1saW5lZCIgYWRhcHRhdGlvbiBvZiB0aGUgRFROIEJ1bmRsZSBTZWN1cml0eVxyXG5cdFByb3Rv Y29sIGRvY3VtZW50ZWQgaW4gUkZDIDYyNTcuXHJcblxyXG4gICAgICBvIEFuIGVuY2Fwc3VsYXRp b24gcHJvdG9jb2wgZm9yICJ0dW5uZWxpbmciIEJQIHRyYWZmaWMgd2l0aGluIGJ1bmRsZXNcclxu XHR0aGF0IGFyZSBzZWN1cmVkIGFuZC9vciByb3V0ZWQgaW4gZGlmZmVyZW50IHdheSBmcm9tIHRo ZSBlbmNhcHN1bGF0ZWRcclxuXHRidW5kbGVzLlxyXG5cclxuICAgICAgbyBBIGRlbGF5LXRvbGVy YW50IHNlY3VyaXR5IGtleSBtYW5hZ2VtZW50IHNjaGVtZSBmb3IgZW5zdXJpbmcgdGhhdFxyXG5c dHB1YmxpYyBrZXlzIGFyZSBjZXJ0aWZpZWQgYnkgYSBnbG9iYWxseSB0cnVzdGVkIGF1dGhvcml0 eSB0byBwcm90ZWN0XHJcblx0dGhlIGludGVncml0eSBvZiB0aGUgaW5mcmFzdHJ1Y3R1cmUuXHJc blxyXG4gICAgICBvIEEgc2ltcGxlIGRhdGFncmFtIGNvbnZlcmdlbmNlIGxheWVyIHByb3RvY29s IGZvciBhZGFwdGF0aW9uIG9mIHRoZVxyXG4gICAgICAgIGJ1bmRsZSBwcm90b2NvbCB0byB1bmRl cmx5aW5nIGludGVybmV0d29ya3MuIFdlIGV4cGVjdCB0byBkZXJpdmVcclxuICAgICAgICB0aGlz IGNvbnZlcmdlbmNlIGxheWVyIHByb3RvY29sIGZyb20gdGhlIERhdGFncmFtIENvbnZlcmdlbmNl XHJcbiAgICAgICAgcHJvdG9jb2wgZG9jdW1lbnRlZCBpbiBSRkM3MTIyLlxyXG5cclxuICAgICAg byBBIGRlbGF5LXRvbGVyYW50IG5ldHdvcmsgbWFuYWdlbWVudCBwcm90b2NvbCBmb3IgbWFuYWdl bWVudCBvZiB0aGVcclxuICAgICAgICBpbmZyYXN0cnVjdHVyZSBpbiB0aGUgcHJlc2VuY2Ugb2Yg bG9uZyBkZWxheXMgYW5kL29yIGludGVybWl0dGVudFxyXG4gICAgICAgIGNvbm5lY3Rpdml0eS5c clxuXHJcbiAgICAgIG8gQSByZWdpc3RyeSBmb3IgRFROIFNlcnZpY2UgSWRlbnRpZmllcnNcclxu ICBcclxuICAgIFRoZSB3b3JraW5nIGdyb3VwIHdpbGwgY29uc2lkZXIgZXh0ZW5kaW5nIHRoZSBj dXJyZW50IG1pbGVzdG9uZXMgYmFzZWQgb25cclxuICAgIG5ldyBpbmZvcm1hdGlvbiBhbmQga25v d2xlZGdlIGdhaW5lZCB3aGlsZSB3b3JraW5nIG9uIHRoZSBpbml0aWFsIGNoYXJ0ZXIsXHJcbiAg ICBhcyB3ZWxsIGFzIHRvIGFjY29tbW9kYXRlIG5ldyB3b3JrIGl0ZW1zIGJleW9uZCB0aGUgc2Nv cGUgb2YgdGhlIGluaXRpYWxcclxuICAgIHBoYXNlLiAgRm9yIGV4YW1wbGUsIHdlIGV4cGVjdCB0 aGF0IHRyYW5zcG9ydCBwcm90b2NvbHMgdW5pcXVlbHkgc3VpdGVkXHJcbiAgICB0byB0aGUgdmFy aW91cyBjb21tdW5pY2F0aW9uIGVudmlyb25tZW50cyB0aGF0IG1heSBuZWVkIHRvIGJlIHRyYXZl cnNlZFxyXG4gICAgYnkgYSBzaW5nbGUgRFROIGVuZC10by1lbmQgcGF0aCAob3BlcmF0aW5nIHVu ZGVyIEJQLCBhdCB3aGF0IGlzIHRlcm1lZFxyXG4gICAgdGhlIERUTiAiY29udmVyZ2VuY2UgbGF5 ZXIiKSB3aWxsIG5lZWQgdG8gYmUgc3RhbmRhcmRpemVkIGluIGEgc2Vjb25kXHJcbiAgICBwaGFz ZSBvZiB0aGUgd29ya2luZyBncm91cFwncyBjaGFydGVyOyBMVFAgYW5kIHRoZSBTYXJhdG9nYSBw cm90b2NvbCBhcmVcclxuICAgIGFtb25nIHRoZSBjYW5kaWRhdGVzIGZvciB3b3JrIGluIHRoaXMg cGhhc2UuICBUaGVzZSBhZGp1c3RtZW50cyB3aWxsIGJlXHJcbiAgICBhY2NvbW1vZGF0ZWQgaW4g YSB3b3JraW5nIGdyb3VwIHJlY2hhcnRlciwgYXNzdW1pbmcgdGhlIGluaXRpYWxcclxuICAgIGNo YXJ0ZXJlZCBhY3Rpdml0aWVzIG1lZXQgdGhlaXIgZGVsaXZlcnkgbWlsZXN0b25lcy4gUG9zc2li bGUgbmV3IHdvcmtcclxuICAgIGl0ZW1zIG11c3QgdGhlbiBzdGlsbCBmaXQgaW50byB0aGUgKHJl Y2hhcnRlcmVkKSBEVE5XRyBjaGFydGVyIHNjb3BlLlxyXG4gICAgXHJcbkdvYWxzIGFuZCBNaWxl c3RvbmVzOlxyXG4gIHN0YXJ0KzNtb3MgLSBTdWJtaXQgXCdCdW5kbGUgUHJvdG9jb2wgU3BlY2lm aWNhdGlvbiAoUkZDNTA1MGJpcylcJyBhcyBhXHJcbiAgICAgICAgICAgICAgICAgICAgICB3b3Jr aW5nIGdyb3VwIGRvY3VtZW50LiBUbyBiZSBQcm9wb3NlZCBTdGFuZGFyZC5cclxuICBTdGFydCsz bW9zIC0gU3VibWl0IFwnU3RyZWFtbGluZWQgQnVuZGxlIFNlY3VyaXR5IFByb3RvY29sIChTQlNQ KVwnIGFzIGFcclxuICAgICAgICAgICAgICAgICAgICAgICB3b3JraW5nIGdyb3VwIGRvY3VtZW50 LiBUbyBiZSBQcm9wb3NlZCBTdGFuZGFyZC5cclxuICBzdGFydCs2bW9zIC0gU3VibWl0IFwnQnVu ZGxlIEluIEJ1bmRsZSBFbmNhcHN1bGF0aW9uIChCSUJFKVwnIGFzIGEgd29ya2luZ1xyXG4gICAg ICAgICAgICAgICAgICAgICAgZ3JvdXAgZG9jdW1lbnQuIFRvIGJlIFByb3Bvc2VkIFN0YW5kYXJk LlxyXG4gIHN0YXJ0Kzltb3MgLSBTdWJtaXQgXCdEZWxheSBUb2xlcmFudCBOZXR3b3JraW5nIFNl Y3VyaXR5IEtleSBNYW5hZ2VtZW50XCcgYXNcclxuICAgICAgICAgICAgICAgICAgICAgIGEgd29y a2luZyBncm91cCBkb2N1bWVudC4gVG8gYmUgUHJvcG9zZWQgU3RhbmRhcmQuXHJcbiAgc3RhcnQr OW1vcyAtIFdHIGRldGVybWluYXRpb24gZm9yIG1lcmdpbmcgUkZDNTA1MGJpcywgU0JTUCwgQklC RSBhbmQvb3JcclxuICAgICAgICAgICAgICAgS2V5IE1nbXQgaW50byBhIGNvbWJpbmVkIGRyYWZ0 IG9yIGtlZXAgYXMgc2VwYXJhdGUgZHJhZnRzLlxyXG4gIHN0YXJ0KzEybW9zIC0gU3VibWl0IFJG QzUwNTBiaXMsIFNCU1AsIEJJQkUgYW5kIEtleSBNZ210IHRvIHRoZSBJRVNHIGVpdGhlclxyXG4g ICAgICAgICAgICAgICAgYXMgYSBjb21iaW5lZCBkcmFmdCBvciBhcyBzZXBhcmF0ZSBkcmFmdHMu XHJcbiAgc3RhcnQrMTJtb3MgLSBTdWJtaXQgTmV0d29yayBNYW5hZ2VtZW50LCBSZWdpc3RyeSBh bmQgU2ltcGxlIENvbnZlcmdlbmNlXHJcbiAgICAgICAgICAgICAgICBMYXllciBhcyB3b3JraW5n IGdyb3VwIGRvY3VtZW50cy5cclxuICBzdGFydCsxNW1vcyAtIFN1cnZleSBhcHByb3ByaWF0ZSBm b3J1bXMgKGUuZy4sIERUTlJHKSBmb3IgZW1lcmdpbmdcclxuICAgICAgICAgICAgICAgIHRlY2hu b2xvZ2llcyAoZS5nLiwgY29udmVyZ2VuY2UgbGF5ZXIgcHJvdG9jb2xzLCBkeW5hbWljXHJcbiAg ICAgICAgICAgICAgICByb3V0aW5nIHByb3RvY29scywgbmFtaW5nIGFuZCBhZGRyZXNzaW5nIHNl cnZpY2VzLCBldGMuKVxyXG4gICAgICAgICAgICAgICAgcmVhZHkgZm9yIHRyYW5zaXRpb24gaW50 byBJRVRGIERUTiBXb3JraW5nIEdyb3VwLiBQdWJsaXNoXHJcbiAgICAgICAgICAgICAgICBkcmFm dCBvbiBzdXJ2ZXkgcmVzdWx0cyBhcyBpbmRlcGVuZGVudCBzdWJtaXNzaW9uIHJlbGF0ZWRcclxu ICAgICAgICAgICAgICAgIHRvIHRoZSBXRy5cclxuICBzdGFydCsxOG1vcyAtIFN1Ym1pdCBOZXR3 b3JrIE1hbmFnZW1lbnQsIFJlZ2lzdHJ5IGFuZCBTaW1wbGUgQ29udmVyZ2VuY2VcclxuICAgICAg ICAgICAgICAgIExheWVyIHRvIElFU0dcclxuICBzdGFydCsxOG1vcyAtIFJlY2hhcnRlciB0byBh Y2NvbW1vZGF0ZSBuZXcgd29yayBpdGVtcyBvciBjbG9zZSBXb3JraW5nIEdyb3VwXHJcbicsICdm aWxlbmFtZTEnOiAnRHJhZnQgQm9GIEFnZW5kYSAoMi41aHJzKTpcclxuKioqKioqKioqKioqKioq KioqKioqKioqKipcclxuMSkgUHJvYmxlbSBzdGF0ZW1lbnQgKElFVEYgd2cgbW90aXZhdGlvbikg LSAzMG1pblxyXG5cclxuMikgUkZDNTA1MChiaXMpIC0gMzBtaW5cclxuXHJcbjMpIFN0cmVhbWxp bmVkIEJ1bmRsZSBTZWN1cml0eSBQcm90b2NvbCAoU0JTUCkgLSAzMG1pblxyXG5cclxuNCkgQnVu ZGxlLWluLUJ1bmRsZSBFbmNhcHN1bGF0aW9uIC0gMzAgbWluXHJcblxyXG41KSBEVE4gU2VjdXJp dHkgS2V5IE1hbmFnZW1lbnQgLSAzMG1pblxyXG5cclxuXHJcblByb3Bvc2VkIHdvcmtpbmcgZ3Jv dXAgY2hhcnRlcjpcclxuKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKlxyXG5Xb3JraW5n IGdyb3VwIG5hbWU6IFxyXG5cclxuICAgICAgRGVsYXkvRGlzcnVwdGlvbiBUb2xlcmFudCBOZXR3 b3JraW5nIFdvcmtpbmcgR3JvdXAgKERUTldHKVxyXG5cclxuQ2hhaXIocyk6XHJcblxyXG4gICAg ICBUQkRcclxuXHJcbkFyZWEgYW5kIEFyZWEgRGlyZWN0b3Iocyk6XHJcblxyXG4gICAgICBUcmFu c3BvcnQgQXJlYTogQURzIFNwZW5jZXIgRGF3a2lucyBfc3BlbmNlcmRhd2tpbnMuaWV0ZiBhdCBn bWFpbC5jb21fLFxyXG4gICAgICAgICAgICAgICAgICAgICAgICAgIE1hcnRpbiBTdGllbWVybGlu ZyBfbWxzLmlldGYgYXQgZ21haWwuY29tX1xyXG5cclxuUmVzcG9uc2libGUgQXJlYSBEaXJlY3Rv cjpcclxuXHJcbiAgICAgIFRCRFxyXG5cclxuTWFpbGluZyBsaXN0OlxyXG5cclxuICAgICAgR2Vu ZXJhbCBEaXNjdXNzaW9uOiBkdG4taW50ZXJlc3QgYXQgaXJ0Zi5vcmcgKG5vdGU6IHVudGlsIHdn IGZvcm1lZClcclxuICAgICAgVG8gU3Vic2NyaWJlOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2R0bi1pbnRlcmVzdFxyXG4gICAgICBBcmNoaXZlOiBodHRwOi8vd3d3Lmll dGYub3JnL21haWwtYXJjaGl2ZS93ZWIvZHRuLWludGVyZXN0L2N1cnJlbnQvbWFpbGxpc3QuaHRt bFxyXG5cclxuRGVzY3JpcHRpb24gb2YgV29ya2luZyBHcm91cDpcclxuXHJcbiAgICAgIFRoZSBE ZWxheS9EaXNydXB0aW9uIFRvbGVyYW50IE5ldHdvcmsgV29ya2luZyBHcm91cCAoRFROV0cpIHNw ZWNpZmllc1xyXG4gICAgICBtZWNoYW5pc21zIGZvciBkYXRhIGNvbW11bmljYXRpb25zIGluIHRo ZSBwcmVzZW5jZSBvZiBsb25nIGRlbGF5c1xyXG4gICAgICBhbmQvb3IgaW50ZXJtaXR0ZW50IGNv bm5lY3Rpdml0eS4gVGhlIHdvcmsgaXMgbW90aXZhdGVkIGJ5IHdlbGwga25vd25cclxuICAgICAg bGltaXRhdGlvbnMgb2Ygc3RhbmRhcmQgSW50ZXJuZXQgcHJvdG9jb2xzIHRoYXQgZXhwZWN0IGVu ZC10by1lbmRcclxuICAgICAgY29ubmVjdGl2aXR5IGJldHdlZW4gY29tbXVuaWNhdGluZyBlbmRw b2ludHMsIHN1Yi1zZWNvbmQgdHJhbnNtaXNzaW9uXHJcbiAgICAgIGRlbGF5cyBhbmQgcm9idXN0 IHBhY2tldCBkZWxpdmVyeSByYXRpb3MuIEluIGVudmlyb25tZW50cyB3aGVyZSB0aGVzZVxyXG4g ICAgICBmYXZvcmFibGUgY29uZGl0aW9ucyBkbyBub3QgYXBwbHksIGV4aXN0aW5nIG1lY2hhbmlz bXMgc3VjaCBhcyByZWxpYWJsZVxyXG4gICAgICB0cmFuc3BvcnQgcHJvdG9jb2xzIGFuZCByb3V0 aW5nIHByb3RvY29scyBjYW4gZmFpbCB0byBjb252ZXJnZSByZXN1bHRpbmdcclxuICAgICAgaW4g Y29tbXVuaWNhdGlvbiBmYWlsdXJlcy4gRnVydGhlcm1vcmUsIGNsYXNzaWNhbCBlbmQtdG8tZW5k IHNlY3VyaXR5XHJcbiAgICAgIGFzc29jaWF0aW9ucyBjYW5ub3QgYmUgY29vcmRpbmF0ZWQgd2hl biBjb21tdW5pY2F0aW5nIGVuZHBvaW50cyBjYW5ub3RcclxuICAgICAgY29uZHVjdCBtdWx0aS1t ZXNzYWdlIGtleWluZyBleGNoYW5nZXMgaW4gYSB0aW1lbHkgZmFzaGlvbi4gVGhlc2VcclxuICAg ICAgbGltaXRhdGlvbnMgc3VnZ2VzdCB0aGUgbmVlZCBmb3IgYSBuZXcgYXBwcm9hY2guIFxyXG4g ICAgICBcclxuICAgICAgRGVsYXktVG9sZXJhbnQgTmV0d29ya2luZyAoRFROKSBwcm90b2NvbHMg aGF2ZSBiZWVuIHRoZSBzdWJqZWN0IG9mXHJcbiAgICAgIGV4dGVuc2l2ZSByZXNlYXJjaCBhbmQg ZGV2ZWxvcG1lbnQgaW4gdGhlIERlbGF5LVRvbGVyYW50IE5ldHdvcmtpbmdcclxuICAgICAgUmVz ZWFyY2ggR3JvdXAgb2YgdGhlIEludGVybmV0IFJlc2VhcmNoIFRhc2sgRm9yY2Ugc2luY2UgMjAw Mi4gIEluXHJcbiAgICAgIHBhcnRpY3VsYXIsIHRoZSBEVE4gQnVuZGxlIFByb3RvY29sIChSRkMg NTA1MCkgYW5kIExpY2tsaWRlclxyXG4gICAgICBUcmFuc21pc3Npb24gUHJvdG9jb2wgKFJGQyA1 MzI2KSBoYXZlIGJlZW4gc2hvd24gdG8gYWRkcmVzcyB0aGVcclxuICAgICAgaXNzdWVzIGlkZW50 aWZpZWQgYWJvdmUuICBJbiAyMDA4LCBCUC9MVFAgd2FzIGRlcGxveWVkIG9uIHRoZSBFUE9YSVxy XG4gICAgICBzcGFjZWNyYWZ0IGluIGRlZXAgc3BhY2UgYW5kIHdhcyB1c2VkIHRvIGNvbmR1Y3Qg cmVsaWFibGUsIGF1dG9tYXRlZFxyXG4gICAgICBjb21tdW5pY2F0aW9uIGZvciBmb3VyIHdlZWtz IG92ZXIgYSBuZXR3b3JrIG9mIDEwIG5vZGVzIGluIHdoaWNoIHRoZVxyXG4gICAgICBib3R0bGVu ZWNrIHJvdXRlciBpbiB0aGUgbmV0d29yayAodGhlIHNwYWNlY3JhZnQpIHdhcyB1cCB0byAxMDAg bGlnaHRcclxuICAgICAgc2Vjb25kcyBmcm9tIGFsbCBvdGhlciBub2RlcyBhbmQgY29ubmVjdGl2 aXR5IHdpdGggdGhlIHJvdXRlciB3YXNcclxuICAgICAgc3ViamVjdCB0byBwZXJpb2RzIG9mIGRp c2Nvbm5lY3Rpb24gbGFzdGluZyBzZXZlcmFsIGRheXMuXHJcblxyXG4gICAgICBUaGUgc3VjY2Vz cyBvZiB0aGUgQlAvTFRQIHByb3RvY29sIHN0YWNrIC0tIHRoZSBjb3JlIHByb3RvY29scyBvZiB0 aGVcclxuICAgICAgIkRUTiBBcmNoaXRlY3R1cmUiIG9yaWdpbmFsbHkgZGVzY3JpYmVkIGluIFJG QyA0ODM4IC0tIGluIHRoaXNcclxuICAgICAgZGVtb25zdHJhdGlvbiBtYXkgYmUgYXR0cmlidXRl ZCB0byB0aGUgZm9sbG93aW5nIGZ1bmRhbWVudGFsIGRlc2lnblxyXG4gICAgICBwcmluY2lwbGVz OlxyXG5cclxuXHQtIFRoZXJlIGlzIG5ldmVyIGFueSBleHBlY3RhdGlvbiBvZiBjb250ZW1wb3Jh bmVvdXMgZW5kLXRvLWVuZFxyXG4gICAgICAgY29ubmVjdGl2aXR5IGJldHdlZW4gYW55IHR3byBu ZXR3b3JrIG5vZGVzLiAgV2hlcmUgc3VjaCBjb25uZWN0aXZpdHlcclxuICAgICAgIGlzIHN1c3Rh aW5lZCwgdGhlIHByb3RvY29scyBsZXZlcmFnZSBpdCB0byBvcHRpbWl6ZSBwZXJmb3JtYW5jZSxc clxuICAgICAgIGJ1dCB0aGUgcG9zc2liaWxpdHkgb2YgdHJhbnNpZW50IGJ1dCBzdXN0YWluZWQg ZGlzY29ubmVjdGlvbiBhdFxyXG4gICAgICAgYW55IHRpbWUsIGFueXdoZXJlIGluIHRoZSBuZXR3 b3JrLCBpcyBhbHdheXMgcmVjb2duaXplZC5cclxuXHJcblx0LSBCZWNhdXNlIGVuZC10by1lbmQg Y29ubmVjdGl2aXR5IGNhbiBuZXZlciBiZSBhc3N1bWVkLCBlYWNoIG5vZGVcclxuXHQgIG9uIHRo ZSBwYXRoIGJldHdlZW4gc291cmNlIGFuZCBkZXN0aW5hdGlvbiBtdXN0IGJlIHByZXBhcmVkIHRv XHJcblx0ICBoYW5kbGUgaW5jb21pbmcgImJ1bmRsZXMiIG9mIGRhdGEgdGhhdCBjYW5ub3QgaW1t ZWRpYXRlbHkgYmVcclxuXHQgIGZvcndhcmRlZC4gIFN1Y2ggYnVuZGxlcyBtdXN0IGVpdGhlciBi ZSBzdG9yZWQgZm9yIGZ1dHVyZSB0cmFucy1cclxuXHQgIG1pc3Npb24gb3IgZGlzY2FyZGVkOyBp biB0aGUgbGF0dGVyIGNhc2UsIHRoZSBuZXR3b3JrIG11c3RcclxuXHQgIGJlIGluZm9ybWVkIG9m IHRoaXMgZGF0YSBsb3NzIHNvIHRoYXQgYW4gYWx0ZXJuYXRpdmUgcGF0aCBtYXlcclxuXHQgIGJl IHNlbGVjdGVkLCB0byBhdm9pZCBpbXBhaXJpbmcgdGhlIHVzYWJpbGl0eSBvZiB0aGUgbmV0d29y ay5cclxuXHJcblx0LSBBZ2FpbiBiZWNhdXNlIGVuZC10by1lbmQgY29ubmVjdGl2aXR5IGNhbiBu ZXZlciBiZSBhc3N1bWVkLFxyXG5cdCAgZW5kLXRvLWVuZCBjb252ZXJzYXRpb25hbCBkYXRhIGV4 Y2hhbmdlIGNhbiBuZXZlciBiZSBhc3N1bWVkIHRvXHJcblx0ICBjb21wbGV0ZSBpbiBhIHRpbWVs eSBtYW5uZXI7IHByb3RvY29sIGZlYXR1cmVzIHRoYXQgcmVseSBvblxyXG5cdCAgdGltZWx5IGNv bnZlcnNhdGlvbmFsIGRhdGEgZXhjaGFuZ2UgbXVzdCBiZSBleGNsdWRlZCBmcm9tIHRoZVxyXG5c dCAgYXJjaGl0ZWN0dXJlLiAgVGhpcyBwcmluY2lwbGUgbWFrZXMgdGhlIERUTiBhcmNoaXRlY3R1 cmVcclxuXHQgIHN1aXRhYmxlIG5vdCBvbmx5IGZvciBuZXR3b3JrIGVudmlyb25tZW50cyBjaGFy YWN0ZXJpemVkIGJ5XHJcblx0ICBsZW5ndGh5IGRpc2Nvbm5lY3Rpb24gYnV0IGFsc28gZm9yIHRo b3NlIHRoYXQgYXJlIGNoYXJhY3Rlcml6ZWRcclxuXHQgIGJ5IGxvbmcgc2lnbmFsIHByb3BhZ2F0 aW9uIGRlbGF5cyAoc3VjaCBhcyB1bmRlcndhdGVyIGNvbW11bmljYXRpb25cclxuXHQgIGJ5IGFj b3VzdGljIHNpZ25hbHMgb3IsIHdvcnNlLCBpbnRlcnBsYW5ldGFyeSBjb21tdW5pY2F0aW9uKSBl dmVuXHJcblx0ICB3aGVuIGNvbm5lY3Rpdml0eSBpcyBjb250aW51b3VzLlxyXG5cclxuICAgICAg VGhlIERUTldHIGJlbGlldmVzIHRoYXQgcHJvdG9jb2xzIGFkaGVyaW5nIHRvIHRoZXNlIHByaW5j aXBsZXMgb2ZmZXJcclxuICAgICAgb3Bwb3J0dW5pdGllcyBmb3IgZW5oYW5jaW5nIHRoZSBmdW5j dGlvbmFsaXR5IG9mIHRoZSBJbnRlcm5ldCAtIGluXHJcbiAgICAgIHBhcnRpY3VsYXIsIGZvciBm YWNpbGl0YXRpbmcgdGhlIGV4dGVuc2lvbiBvZiB0aGUgSW50ZXJuZXQgaW50b1xyXG4gICAgICBl bnZpcm9ubWVudHMgc3VjaCBhcyB0aGUgb2NlYW4gZmxvb3IgYW5kIGRlZXAgc3BhY2UgaW4gd2hp Y2ggdGhlIGNvcmVcclxuICAgICAgSW50ZXJuZXQgcHJvdG9jb2xzIG9wZXJhdGUgc3ViLW9wdGlt YWxseSBmb3IgdGhlIHJlYXNvbnMgZGlzY3Vzc2VkXHJcbiAgICAgIGVhcmxpZXIuICBXZSBiZWxp ZXZlIHRoYXQgdGhlIGV4dGVuc2l2ZSByZXNlYXJjaCwgZGVtb25zdHJhdGlvbiwgYW5kXHJcbiAg ICAgIHBpbG90IG9wZXJhdGlvbnMgcGVyZm9ybWVkIHRvIGRhdGUgdXNpbmcgdGhlIERUTlJHIHBy b3RvY29scywgYm90aFxyXG4gICAgICBiZWZvcmUgYW5kIGFmdGVyIHRoZSBFUE9YSSBleHBlcmlt ZW50LCBwcm92aWRlcyBhIGZpcm0gYmFzaXMgZm9yXHJcbiAgICAgIHB1Ymxpc2hpbmcgSW50ZXJu ZXQgc3RhbmRhcmRzIGRlcml2ZWQgZnJvbSB0aGF0IHdvcmsuXHJcblxyXG4gICAgICBXb3JrIGl0 ZW1zIHJlbGF0ZWQgdG8gRGVsYXkvRGlzcnVwdGlvbiBUb2xlcmFudCBOZXR3b3JraW5nIGluY2x1 ZGU6XHJcblxyXG4gICAgICBvIEEgbWVjaGFuaXNtIGZvciB0aGUgZXhjaGFuZ2Ugb2YgcHJvdG9j b2wgZGF0YSB1bml0cywgdGVybWVkXHJcblx0ImJ1bmRsZXMiLCB0aGF0IGFyZSBkZXNpZ25lZCB0 byBvYnZpYXRlIGNvbnZlcnNhdGlvbmFsIGNvbW11bmljYXRpb25zXHJcblx0YnkgY29udGFpbmlu ZyB2YWx1ZXMgZm9yIGFsbCBwb3RlbnRpYWxseSByZWxldmFudCBjb25maWd1cmF0aW9uXHJcblx0 cGFyYW1ldGVycy4gIFRoZXNlIHByb3RvY29sIGRhdGEgdW5pdHMgYXJlIHR5cGljYWxseSBsYXJn ZXIgdGhhblxyXG5cdG5ldHdvcmstbGF5ZXIgcGFja2V0cy4gIFdlIGV4cGVjdCB0byBkZXJpdmUg dGhpcyBidW5kbGUgZXhjaGFuZ2VcclxuXHRtZWNoYW5pc20gZnJvbSB0aGUgRFROIEJ1bmRsZSBQ cm90b2NvbCAoQlApIGRvY3VtZW50ZWQgaW4gUkZDIDUwNTAuXHJcblxyXG4gICAgICBvIEEgc2Vj dXJpdHkgcHJvdG9jb2wgZm9yIGVuc3VyaW5nIHRoYXQgdGhlIG5ldHdvcmsgaW4gd2hpY2ggYnVu ZGxlc1xyXG5cdGFyZSBleGNoYW5nZWQgaXMgc2VjdXJlZCBhZ2FpbnN0IHVuYXV0aG9yaXplZCBh Y2Nlc3MgYW5kIGRlbmlhbCBvZlxyXG5cdHNlcnZpY2UgYXR0YWNrcywgYW5kIHRvIGVuc3VyZSBk YXRhIGludGVncml0eSBhbmQgY29uZmlkZW50aWFsaXR5XHJcblx0aW4gdGhhdCBuZXR3b3JrIHdo ZXJlIG5lY2Vzc2FyeS4gIFdlIGV4cGVjdCB0byBkZXJpdmUgdGhpcyBzZWN1cml0eVxyXG5cdHBy b3RvY29sIGZyb20gYSAic3RyZWFtbGluZWQiIGFkYXB0YXRpb24gb2YgdGhlIERUTiBCdW5kbGUg U2VjdXJpdHlcclxuXHRQcm90b2NvbCBkb2N1bWVudGVkIGluIFJGQyA2MjU3LlxyXG5cclxuICAg ICAgbyBBbiBlbmNhcHN1bGF0aW9uIHByb3RvY29sIGZvciAidHVubmVsaW5nIiBCUCB0cmFmZmlj IHdpdGhpbiBidW5kbGVzXHJcblx0dGhhdCBhcmUgc2VjdXJlZCBhbmQvb3Igcm91dGVkIGluIGRp ZmZlcmVudCB3YXkgZnJvbSB0aGUgZW5jYXBzdWxhdGVkXHJcblx0YnVuZGxlcy5cclxuXHJcbiAg ICAgIG8gQSBkZWxheS10b2xlcmFudCBzZWN1cml0eSBrZXkgbWFuYWdlbWVudCBzY2hlbWUgZm9y IGVuc3VyaW5nIHRoYXRcclxuXHRwdWJsaWMga2V5cyBhcmUgY2VydGlmaWVkIGJ5IGEgZ2xvYmFs bHkgdHJ1c3RlZCBhdXRob3JpdHkgdG8gcHJvdGVjdFxyXG5cdHRoZSBpbnRlZ3JpdHkgb2YgdGhl IGluZnJhc3RydWN0dXJlLlxyXG4gIFxyXG4gICAgVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBjb25z aWRlciBleHRlbmRpbmcgdGhlIGN1cnJlbnQgbWlsZXN0b25lcyBiYXNlZCBvblxyXG4gICAgbmV3 IGluZm9ybWF0aW9uIGFuZCBrbm93bGVkZ2UgZ2FpbmVkIHdoaWxlIHdvcmtpbmcgb24gdGhlIGlu aXRpYWwgY2hhcnRlcixcclxuICAgIGFzIHdlbGwgYXMgdG8gYWNjb21tb2RhdGUgbmV3IHdvcmsg aXRlbXMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGUgaW5pdGlhbFxyXG4gICAgcGhhc2UuICBGb3Ig ZXhhbXBsZSwgd2UgZXhwZWN0IHRoYXQgdHJhbnNwb3J0IHByb3RvY29scyB1bmlxdWVseSBzdWl0 ZWRcclxuICAgIHRvIHRoZSB2YXJpb3VzIGNvbW11bmljYXRpb24gZW52aXJvbm1lbnRzIHRoYXQg bWF5IG5lZWQgdG8gYmUgdHJhdmVyc2VkXHJcbiAgICBieSBhIHNpbmdsZSBEVE4gZW5kLXRvLWVu ZCBwYXRoIChvcGVyYXRpbmcgdW5kZXIgQlAsIGF0IHdoYXQgaXMgdGVybWVkXHJcbiAgICB0aGUg RFROICJjb252ZXJnZW5jZSBsYXllciIpIHdpbGwgbmVlZCB0byBiZSBzdGFuZGFyZGl6ZWQgaW4g YSBzZWNvbmRcclxuICAgIHBoYXNlIG9mIHRoZSB3b3JraW5nIGdyb3VwXCdzIGNoYXJ0ZXI7IExU UCBhbmQgdGhlIFNhcmF0b2dhIHByb3RvY29sIGFyZVxyXG4gICAgYW1vbmcgdGhlIGNhbmRpZGF0 ZXMgZm9yIHdvcmsgaW4gdGhpcyBwaGFzZS4gIFRoZXNlIGFkanVzdG1lbnRzIHdpbGwgYmVcclxu ICAgIGFjY29tbW9kYXRlZCBpbiBhIHdvcmtpbmcgZ3JvdXAgcmVjaGFydGVyLCBhc3N1bWluZyB0 aGUgaW5pdGlhbFxyXG4gICAgY2hhcnRlcmVkIGFjdGl2aXRpZXMgbWVldCB0aGVpciBkZWxpdmVy eSBtaWxlc3RvbmVzLiBQb3NzaWJsZSBuZXcgd29ya1xyXG4gICAgaXRlbXMgbXVzdCB0aGVuIHN0 aWxsIGZpdCBpbnRvIHRoZSAocmVjaGFydGVyZWQpIERUTldHIGNoYXJ0ZXIgc2NvcGUuXHJcbiAg ICBcclxuR29hbHMgYW5kIE1pbGVzdG9uZXM6XHJcbiAgc3RhcnQrM21vcyAtIFN1Ym1pdCBcJ0J1 bmRsZSBQcm90b2NvbCBTcGVjaWZpY2F0aW9uIChSRkM1MDUwYmlzKVwnIGFzIGFcclxuICAgICAg ICAgICAgICAgICAgICAgIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuIFRvIGJlIFByb3Bvc2VkIFN0 YW5kYXJkLlxyXG4gIFN0YXJ0KzNtb3MgLSBTdWJtaXQgXCdTdHJlYW1saW5lZCBCdW5kbGUgU2Vj dXJpdHkgUHJvdG9jb2wgKFNCU1ApXCcgYXMgYVxyXG4gICAgICAgICAgICAgICAgICAgICAgIHdv cmtpbmcgZ3JvdXAgZG9jdW1lbnQuIFRvIGJlIFByb3Bvc2VkIFN0YW5kYXJkLlxyXG4gIHN0YXJ0 KzZtb3MgLSBTdWJtaXQgXCdCdW5kbGUgSW4gQnVuZGxlIEVuY2Fwc3VsYXRpb24gKEJJQkUpXCcg YXMgYSB3b3JraW5nXHJcbiAgICAgICAgICAgICAgICAgICAgICBncm91cCBkb2N1bWVudC4gVG8g YmUgUHJvcG9zZWQgU3RhbmRhcmQuXHJcbiAgc3RhcnQrOW1vcyAtIFN1Ym1pdCBcJ0RlbGF5IFRv bGVyYW50IE5ldHdvcmtpbmcgU2VjdXJpdHkgS2V5IE1hbmFnZW1lbnRcJyBhc1xyXG4gICAgICAg ICAgICAgICAgICAgICAgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50LiBUbyBiZSBQcm9wb3NlZCBT dGFuZGFyZC5cclxuICBzdGFydCs5bW9zIC0gU3VibWl0IFwnQnVuZGxlIFByb3RvY29sIFNwZWNp ZmljYXRpb24gKFJGQzUwNTBiaXMpXCcgdG8gdGhlXHJcbiAgICAgICAgICAgICAgICAgICAgICBJ RVNHLiBUbyBiZSBQcm9wb3NlZCBTdGFuZGFyZC5cclxuICBzdGFydCs5bW9zIC0gU3VibWl0IFwn U3RyZWFtbGluZWQgQnVuZGxlIFNlY3VyaXR5IFByb3RvY29sIChTQlNQKVwnIHRvIHRoZVxyXG4g ICAgICAgICAgICAgICAgICAgICAgSUVTRy4gVG8gYmUgUHJvcG9zZWQgU3RhbmRhcmQuXHJcbiAg c3RhcnQrMTBtb3MgLSBTdWJtaXQgXCdCdW5kbGUgSW4gQnVuZGxlIEVuY2Fwc3VsYXRpb24gKEJJ QkUpXCcgdG8gdGhlIElFU0cuXHJcbiAgICAgICAgICAgICAgICAgICAgICAgVG8gYmUgUHJvcG9z ZWQgU3RhbmRhcmQuXHJcbiAgc3RhcnQrMTFtb3MgLSBTdWJtaXQgXCdEZWxheSBUb2xlcmFudCBO ZXR3b3JraW5nIFNlY3VyaXR5IEtleSBNYW5hZ2VtZW50XCcgdG9cclxuICAgICAgICAgICAgICAg ICAgICAgICB0aGUgSUVTRy4gVG8gYmUgUHJvcG9zZWQgU3RhbmRhcmQuXHJcbiAgc3RhcnQrMTJt b3MgLSBSZWNoYXJ0ZXIgdG8gYWNjb21tb2RhdGUgbmV3IHdvcmsgaXRlbXMgb3IgY2xvc2UgV29y a2luZyBHcm91cFxyXG4nLCAndXJsMSc6ICcnLCAnc3VibWl0JzogJ0dlbmVyYXRlIGRpZmYnLCAn dXJsMic6ICcnLCAnLS1uZXdjb2xvdXInOiAnZ3JlZW4nfSAtLT4= --_002_2134F8430051B64F815C691A62D983181B2BE63EXCHBLV504nwnosb_-- From nobody Wed Jun 4 15:18:41 2014 Return-Path: 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 3435B1A032B for ; Wed, 4 Jun 2014 15:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.921 X-Spam-Level: X-Spam-Status: No, score=0.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=no 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 bHMQ9QvXcVeP for ; Wed, 4 Jun 2014 15:08:03 -0700 (PDT) Received: from mail.arces.unibo.it (mail.arces.unibo.it [137.204.143.6]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEF961A0309 for ; Wed, 4 Jun 2014 15:08:02 -0700 (PDT) Received: from webmail.arces.unibo.it (web.arces.unibo.it [137.204.143.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.arces.unibo.it (Postfix) with ESMTP id 3EFE74136406; Wed, 4 Jun 2014 20:28:07 +0200 (CEST) MIME-Version: 1.0 Date: Wed, 04 Jun 2014 20:28:07 +0200 From: ccaini To: Stephen Farrell In-Reply-To: <538E465C.2060404@cs.tcd.ie> References: <2134F8430051B64F815C691A62D983181B2BD2DE@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2BD423@XCH-BLV-504.nw.nos.boeing.com> <538E35F6.2010702@cs.tcd.ie> <538E465C.2060404@cs.tcd.ie> Message-ID: X-Sender: ccaini@arces.unibo.it User-Agent: RoundCube Webmail/0.2 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 X-Arces-MailScanner-Information: Please contact the ISP for more information X-Arces-MailScanner-ID: 3EFE74136406.B97CB X-Arces-MailScanner: Found to be clean X-Arces-MailScanner-From: ccaini@arces.unibo.it Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/tB7hRQuOlZy7BWzTSRea93jY3PU X-Mailman-Approved-At: Wed, 04 Jun 2014 15:18:39 -0700 Cc: "Burleigh, Scott C \(312G\)" , dtn@ietf.org Subject: Re: [dtn] Proposed Working Group Charter Suggestions X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 22:08:05 -0000 Dear Stephen and Scott, In my opinion to start from scratch would be a wrong choice, as the present code seems mature enough for writing applications (not just demos), although of course many improvements can and should be added. We must go on, and in my opinion we must go on with an evolutionary path, being the alternative a disruptive path (legitimate as well, of course). I am not in a position, as I am not an English mother tongue speaker, as both of you, to suggest anything. However, "5050 with minimal changes" sounds to me as the proponents are a bit lazy, while "5050 evolution" sounds more suitable. "5050 evo" even better. You can then "decline" the term evolution as you prefer; from almost anything, i.e. the "minimal changes", to something more substantial, as intended by Scott. In both cases it is clear that "evolution" is something different from the disruptive alternative. Yours, Carlo On Tue, 3 Jun 2014 23:04:12 +0100, Stephen Farrell wrote: > On 03/06/14 22:41, Burleigh, Scott C (312G) wrote: >> Hi, Stephen. In my mind those are not necessarily the only two >> options. > > Sure. Could be the only two feasible options though:-) > >> I definitely would not be in favor of starting from a blank >> sheet of paper. A number of changes to BP have been proposed, at one >> time or another, most of which I think have merit, and some of which >> might be considered substantial. If those changes were made, would >> the result be considered "5050 with minimal change"? The term >> "minimal" is slippery here and, I think, generally not helpful. > > Sorry, didn't mean it as a derogatory term, but I do think it > seems to accurately capture the intent as I understand it. And > "minimal" is a valid goal, just one with which I'd disagree. > To be clear, and as I've said before, if there's enough support > for that "minimal" goal, then I'm ok to be in the rough and still > want to see the work going ahead. Before and during the BoF is > the time for that scoping discussion though. > >> Maybe the charter clarification you're looking for could simply take >> the form of a strawman list of proposed changes? > > Actually, for me at least, the general characterisation is > more useful as a guideline for which of the other fairly well > known kinds of change will likely get done. That may be different > for others of course, so you're probably right that a TBD > list of changes will be useful, maybe in an update to Fred's > draft? > > S. > >> >> Scott >> >> -----Original Message----- From: dtn [mailto:dtn-bounces@ietf.org] On >> Behalf Of Stephen Farrell Sent: Tuesday, June 03, 2014 1:54 PM To: >> Templin, Fred L; dtn@ietf.org Subject: Re: [dtn] Proposed Working >> Group Charter Suggestions >> >> >>> >>> Please let me know what I may be missing or mis-representing. >> >> We had a longish discussion of whether or not the proposed WG would >> be much more of a "5050bis with minimal change" or would attempt to >> more broadly revisit the BP as an instance of the DTN architecture >> described in RFC 4838. >> >> While I would be in favour of the latter, I don't think the list >> discussion landed there, (so far anyway) and it seems clear that the >> BoF proponents are more in favour of the former, i.e. minimal changes >> to 5050. >> >> That still needs to be much more clearly stated in the proposed >> charter text IMO, as it significantly impacts on the scope of the >> proposed WG. >> >> S. >> >> _______________________________________________ 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 From nobody Wed Jun 4 15:27:38 2014 Return-Path: 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 2F4301A035D for ; Wed, 4 Jun 2014 15:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 G2MPDjrmR-mX for ; Wed, 4 Jun 2014 15:27:34 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0B80E1A0309 for ; Wed, 4 Jun 2014 15:27:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 91211BF50; Wed, 4 Jun 2014 23:27:26 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jz1lt_kVEOgz; Wed, 4 Jun 2014 23:27:25 +0100 (IST) Received: from [10.87.48.12] (unknown [86.45.54.8]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 78C55BF2D; Wed, 4 Jun 2014 23:27:25 +0100 (IST) Message-ID: <538F9D4D.8020508@cs.tcd.ie> Date: Wed, 04 Jun 2014 23:27:25 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Templin, Fred L" , "Ivancic, William D. (GRC-RHN0)" , Simon Perreault , "dtn@ietf.org" References: <2134F8430051B64F815C691A62D983181B2BD2DE@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2BD423@XCH-BLV-504.nw.nos.boeing.com> <538E35F6.2010702@cs.tcd.ie> <538F3D53.5060305@per.reau.lt> <2134F8430051B64F815C691A62D983181B2BE16E@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983181B2BE16E@XCH-BLV-504.nw.nos.boeing.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/6A058TihuUUctvSE4JUzK0x5QZo Subject: Re: [dtn] Proposed Working Group Charter Suggestions X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 22:27:36 -0000 On 04/06/14 18:33, Templin, Fred L wrote: > I don't believe that an indication of scaled deployment is a > necessary precondition for holding a BoF. Fred is correct here. What Will is asking about isn't even needed for a proposed standard. But the more real interest there is for a BoF topic, the better, clearly. And in response to Carlo and Scott - "minimal" is *not* a bad thing - the idea that an IETF WG will make minimal changes to an experimental track RFC to produce a proposed standard is quite positive actually. From one reasonable perspective, the kind of more extensive change I'd personally like is more risky. (Not that I'm wrong though:-) S. From nobody Wed Jun 4 16:14:08 2014 Return-Path: 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 E3A5D1A03A1 for ; Wed, 4 Jun 2014 16:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 fRv2x8PktEsp for ; Wed, 4 Jun 2014 16:14:03 -0700 (PDT) Received: from mail.jpl.nasa.gov (sentrion3.jpl.nasa.gov [128.149.139.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 500EB1A0394 for ; Wed, 4 Jun 2014 16:14:03 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp02.jpl.nasa.gov [128.149.137.149]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s54NDhri014620 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Wed, 4 Jun 2014 16:13:44 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.156]) by ap-ehub-sp02.RES.AD.JPL ([fe80::dd85:7b07:1e36:7e3c%15]) with mapi id 14.03.0174.001; Wed, 4 Jun 2014 16:13:44 -0700 From: "Burleigh, Scott C (312G)" To: Stephen Farrell , "Templin, Fred L" , "Ivancic, William D. (GRC-RHN0)" , Simon Perreault , "dtn@ietf.org" Thread-Topic: [dtn] Proposed Working Group Charter Suggestions Thread-Index: AQHPf14wFB51tdmzXkGmHw0I1w1vMptgUpAA//+VSKCAAaSsgIAADkeAgAAR5oCAAFI9gP//ldLQ Date: Wed, 4 Jun 2014 23:13:43 +0000 Message-ID: References: <2134F8430051B64F815C691A62D983181B2BD2DE@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2BD423@XCH-BLV-504.nw.nos.boeing.com> <538E35F6.2010702@cs.tcd.ie> <538F3D53.5060305@per.reau.lt> <2134F8430051B64F815C691A62D983181B2BE16E@XCH-BLV-504.nw.nos.boeing.com> <538F9D4D.8020508@cs.tcd.ie> In-Reply-To: <538F9D4D.8020508@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.26] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/GmcwCOMKBLvoW2YyEJWgpWYjvCE Subject: Re: [dtn] Proposed Working Group Charter Suggestions X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 23:14:05 -0000 Thanks, Stephen, and in that context I am perfectly comfortable with callin= g this work plan approach "minimal". I just don't want us to be trapped in= to thinking we can't consider a given modification because it would exceed = some sort of minimal-ness limit. Also, just to clarify, I've got no objection at all to taking a clean-sheet= -of-paper look at the whole DTN problem statement; I think that could be in= teresting and productive. I just think the DTNRG is a better venue for tha= t than the proposed Working Group would be, and I'm happy for us to agree t= o disagree on that point. Scott -----Original Message----- From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of Stephen Farrell Sent: Wednesday, June 04, 2014 3:27 PM To: Templin, Fred L; Ivancic, William D. (GRC-RHN0); Simon Perreault; dtn@i= etf.org Subject: Re: [dtn] Proposed Working Group Charter Suggestions On 04/06/14 18:33, Templin, Fred L wrote: > I don't believe that an indication of scaled deployment is a necessary=20 > precondition for holding a BoF. Fred is correct here. What Will is asking about isn't even needed for a pro= posed standard. But the more real interest there is for a BoF topic, the be= tter, clearly. And in response to Carlo and Scott - "minimal" is *not* a bad thing - the i= dea that an IETF WG will make minimal changes to an experimental track RFC = to produce a proposed standard is quite positive actually. From one reasona= ble perspective, the kind of more extensive change I'd personally like is m= ore risky. (Not that I'm wrong though:-) S. _______________________________________________ dtn mailing list dtn@ietf.org https://www.ietf.org/mailman/listinfo/dtn From nobody Wed Jun 4 16:29:10 2014 Return-Path: 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 AF14A1A03D0 for ; Wed, 4 Jun 2014 16:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 R2VSnbiqETSg for ; Wed, 4 Jun 2014 16:29:01 -0700 (PDT) Received: from mail.jpl.nasa.gov (sentrion2.jpl.nasa.gov [128.149.139.106]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA3571A03A1 for ; Wed, 4 Jun 2014 16:29:01 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp02.jpl.nasa.gov [128.149.137.149]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s54NSs1J016887 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Wed, 4 Jun 2014 16:28:54 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.156]) by ap-ehub-sp02.RES.AD.JPL ([fe80::dd85:7b07:1e36:7e3c%15]) with mapi id 14.03.0174.001; Wed, 4 Jun 2014 16:28:54 -0700 From: "Burleigh, Scott C (312G)" To: "Ivancic, William D. (GRC-RHN0)" , "Simon Perreault" , "dtn@ietf.org" Thread-Topic: [dtn] Proposed Working Group Charter Suggestions Thread-Index: AQHPf14wFB51tdmzXkGmHw0I1w1vMptgUpAA//+VSKCAAaSsgIAADkeA///S38CAAIW1gP//oz9A Date: Wed, 4 Jun 2014 23:28:53 +0000 Message-ID: References: <2134F8430051B64F815C691A62D983181B2BD2DE@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2BD423@XCH-BLV-504.nw.nos.boeing.com> <538E35F6.2010702@cs.tcd.ie> <538F3D53.5060305@per.reau.lt> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.26] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/lGNMuDTp36VBUoP5NiTSgfL-k0s Subject: Re: [dtn] Proposed Working Group Charter Suggestions X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 23:29:08 -0000 You're right, Will, AES alone certainly doesn't constitute a user community= that's large enough to justify forming an IETF working group. But I think= it is large enough to demonstrate that informed interest in operational us= e of technology based on the DTNRG protocols exists, suggesting that the in= terest we're hearing about from Boeing deserves to be taken seriously. Som= etimes most of the growth in the user base comes only after the standards h= ave been nailed down. And you are quite wrong about nobody using bundle lifetimes to make bundle = forwarding decisions: bundle expiration time is a critical parameter in con= tact graph routing. Of course, CGR is not used in most DTN research studie= s, because CGR currently can't be driven by opportunistic contacts. That w= ill be changing over the next few months. Scott -----Original Message----- From: Ivancic, William D. (GRC-RHN0) [mailto:william.d.ivancic@nasa.gov]=20 Sent: Wednesday, June 04, 2014 2:46 PM To: Burleigh, Scott C (312G); Simon Perreault; dtn@ietf.org Subject: Re: [dtn] Proposed Working Group Charter Suggestions Scott, I heard the same regarding AES http://www.nasa.gov/directorates/heo/aes/#.U4-NpSS8LhU But that is not many systems. Really, whatever is done on ISS and maybe an= Asteroid Retrieval via Orion (single space craft) around a lunar orbit. And not until 2020 or later will maybe a few node network at best. IMHO, you'll need more than that to justify a IETF working group. There is= already a CCSDS working group for space that is doing DTN. If we are only = considering small space deployments, perhaps CCSDS is the place to handle t= his. =20 Regarding time: I had a group in yesterday demonstrating a simple 3 node D= TN network using the Soldier Radio Waveform. The first thing required was = to manually synchronize the LAN portions of the radio. IMHO, the Time sync= requirement (even loose time sync) makes DTN RFC5050 extremely fragile. Y= es, time is used to expire bundles, but that could be done via priorities. = Response to my question a few years ago about what do people set bundle li= fetimes to indicated that generally it is the lifetime of the demonstration= or something equivalent like 24 hours if your mining. The DINET deploymen= t is a prime example. http://www.dtnrg.org/wiki/DtnBone Also, if you check the mail list archives, I believe nobody is using bundle= lifetimes to make bundle forwarding decisions. Since so many deployments h= ave been a sting of pearls with single source and all bundles set to the sa= me lifetime, it wouldn't have mattered. In this instance, you will end up = with a first-in, first-out queue regardless. Will ****************************** William D. Ivancic Phone 216-433-3494 Mobile 440-503-4892 http://roland.grc.nasa.gov/~ivancic On 6/4/14 4:55 PM, "Burleigh, Scott C (312G)" wrote: >Will, FWIW, the word we're hearing from our NASA sponsors is that DTN=20 >will be baselined for everything that the Advanced Exploration Systems=20 >program fields. I think this may be a case of not everybody=20 >necessarily advertising everything they've got in the pipeline. > >As an aside, I have to point out that your observation that "Nobody is=20 >using [time] or knows how to set it" is simply, categorically wrong. > >Scott > >-----Original Message----- >From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of Ivancic, William D. >(GRC-RHN0) >Sent: Wednesday, June 04, 2014 9:29 AM >To: Simon Perreault; dtn@ietf.org >Subject: Re: [dtn] Proposed Working Group Charter Suggestions > >I wouldn't even call it 5050bis as the changes would probably have to=20 >be significant. > >* Need for reliability check at least in the header. >* Need for hop count to eliminate routing loops. >* Really no need for time. Nobody is using it or knows how to set it. > >My question is "Who is deploying RFC5050 in any significant way to=20 >justify a working group?" I think we have to be able to answer this=20 >question if we really expect to proceed. Boeing hasn't indicated any=20 >scaled deployment. I think DOD may have dropped it. I've only seen=20 >very simple deployments of a few nodes. Epoxy and N4C may be the=20 >largest with >10 to perhaps 20? I think early work with DieselNet and others may=20 >have been much larger deployments of store, carry and forward technologies= . >NASA/DARPA SPHERES uses DTN Tunneling and is really a one-hop DTN=20 >network. It works because SHPERES uses a publish/subscribe=20 >architecture so the application doesn't really care/know if messages=20 >are missed or can re-request during acquisition of signal. > >Here are the latest in NASA's plans that I know of. >http://ipnsig.org/wp-content/uploads/2014/02/ISS-DTN-Presentation-IPNSI >G.p >d >f >http://www.docstoc.com/docs/158373645/CU-Boulder-ISS-Updatepptx > >Note, these are very simple deployments with only a few nodes and=20 >probably can be accommodated with the current protocol > >Will >****************************** >William D. Ivancic >Phone 216-433-3494 >Mobile 440-503-4892 >http://roland.grc.nasa.gov/~ivancic > > > > > > >On 6/4/14 11:37 AM, "Simon Perreault" wrote: > >>One clear, objective criteria that I think we should agree on is that=20 >>5050bis does not need to be backward compatible with 5050. >> >>Simon >> >>Le 2014-06-03 17:41, Burleigh, Scott C (312G) a =E9crit : >>> Hi, Stephen. In my mind those are not necessarily the only two=20 >>>options. I definitely would not be in favor of starting from a blank=20 >>>sheet of paper. A number of changes to BP have been proposed, at one=20 >>>time or another, most of which I think have merit, and some of which=20 >>>might be considered substantial. If those changes were made, would=20 >>>the result be considered "5050 with minimal change"? The term=20 >>>"minimal" is slippery here and, I think, generally not helpful. >>> >>> Maybe the charter clarification you're looking for could simply take=20 >>>the form of a strawman list of proposed changes? >>> >>> Scott >> >>_______________________________________________ >>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 From nobody Wed Jun 4 21:33:11 2014 Return-Path: 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 161641A0416 for ; Wed, 4 Jun 2014 21:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 B-VceF_o7UIV for ; Wed, 4 Jun 2014 21:33:09 -0700 (PDT) Received: from atl4mhob05.myregisteredsite.com (atl4mhob05.myregisteredsite.com [209.17.115.43]) by ietfa.amsl.com (Postfix) with ESMTP id E09A11A0414 for ; Wed, 4 Jun 2014 21:33:08 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.208]) by atl4mhob05.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s554X18k008940 for ; Thu, 5 Jun 2014 00:33:01 -0400 Received: (qmail 11389 invoked by uid 0); 5 Jun 2014 04:33:00 -0000 X-TCPREMOTEIP: 69.81.143.143 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.108?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 5 Jun 2014 04:33:00 -0000 Message-ID: <538FF2F8.5070605@mti-systems.com> Date: Thu, 05 Jun 2014 00:32:56 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Burleigh, Scott C (312G)" , "Ivancic, William D. (GRC-RHN0)" , "dtn@ietf.org" References: <2134F8430051B64F815C691A62D983181B2BD2DE@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2BD423@XCH-BLV-504.nw.nos.boeing.com> <538E35F6.2010702@cs.tcd.ie> <538F3D53.5060305@per.reau.lt> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/AW2M31eW554b2Tdr9irIzayoEg0 Subject: Re: [dtn] Proposed Working Group Charter Suggestions X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 04:33:10 -0000 On 6/4/2014 7:28 PM, Burleigh, Scott C (312G) wrote: > And you are quite wrong about nobody using bundle lifetimes to make > bundle forwarding decisions: bundle expiration time is a critical > parameter in contact graph routing. I think the point is not that routing algorithms can't use it appropriately, but rather than sending applications so far haven't generally been able to set it with any meaningful granularity so that it would then cause the routing system to be able to do intelligent things. I.e. if all bundles coming through have the same very long lifetime, it will not impact the routing decisions, even if there happens to be logic that incorporates the lifetime. This doesn't exclude the possibility that there's a system somewhere in which the applications can really make use of a whole spectrum of lifetime values, but it doesn't look like the general case so far. -- Wes Eddy MTI Systems From nobody Thu Jun 5 00:33:31 2014 Return-Path: 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 80F071A006B for ; Thu, 5 Jun 2014 00:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 35IzIzcsVJit for ; Thu, 5 Jun 2014 00:33:24 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 911711A00D1 for ; Thu, 5 Jun 2014 00:33:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.98,979,1392192000"; d="asc'?scan'208";a="168390741" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx12-out.netapp.com with ESMTP; 05 Jun 2014 00:33:10 -0700 Received: from HIOEXCMBX03-PRD.hq.netapp.com (10.122.105.36) by vmwexceht02-prd.hq.netapp.com (10.106.76.240) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 5 Jun 2014 00:33:09 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx03-prd.hq.netapp.com (10.122.105.36) with Microsoft SMTP Server (TLS) id 15.0.847.32; Thu, 5 Jun 2014 00:33:08 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::d865:b6fe:275f:ffef%21]) with mapi id 15.00.0847.030; Thu, 5 Jun 2014 00:32:50 -0700 From: "Eggert, Lars" To: "Templin, Fred L" Thread-Topic: [dtn] DTN BoF Proposal for IETF90 Thread-Index: Ac+AQa9Fez/CplZaSwyaLFpzb8tj0wAiVZ0A Date: Thu, 5 Jun 2014 07:32:50 +0000 Message-ID: References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_1F0CFE81-CE02-44A4-B124-E6BB4DF442E6"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/jT7WBKJbBPonjDMFAQEYf1WpZCg Cc: "dtn@ietf.org" Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 07:33:26 -0000 --Apple-Mail=_1F0CFE81-CE02-44A4-B124-E6BB4DF442E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2014-6-5, at 0:09, Templin, Fred L wrote: > Draft BoF Agenda (2.5hrs): > ************************** > 1) Problem statement (IETF wg motivation) - 30min > 2) RFC5050(bis) - 30min > 3) Streamlined Bundle Security Protocol (SBSP) - 30min > 4) Bundle-in-Bundle Encapsulation - 15min > 5) Security Key Management - 15min > 6) Registry for Service Identifiers - 15min > 7) Network Management - 15min that adds up to 2.5h - when were you planning to have charter = discussions, etc.? Suggest to focus on 1, and then summarize the = suggested work items 2-7 in much less time, leaving an hour at least for = discussion. > Description of Working Group: >=20 > The Delay/Disruption Tolerant Network Working Group (DTNWG) = specifies > mechanisms for data communications in the presence of long delays > and/or intermittent connectivity. The work is motivated by well = known > limitations of standard Internet protocols that expect end-to-end > connectivity between communicating endpoints, sub-second = transmission > delays and robust packet delivery ratios. In environments where = these > favorable conditions do not apply, existing mechanisms such as = reliable > transport protocols and routing protocols can fail to converge = resulting > in communication failures. Furthermore, classical end-to-end = security > associations cannot be coordinated when communicating endpoints = cannot > conduct multi-message keying exchanges in a timely fashion. These > limitations suggest the need for a new approach.=20 OK so far. > Delay-Tolerant Networking (DTN) protocols have been the subject = of > extensive research and development in the Delay-Tolerant = Networking > Research Group of the Internet Research Task Force since 2002. = In > particular, the DTN Bundle Protocol (RFC 5050) and Licklider > Transmission Protocol (RFC 5326) have been shown to address the > issues identified above. In 2008, BP/LTP was deployed on the = EPOXI > spacecraft in deep space and was used to conduct reliable, = automated > communication for four weeks over a network of 10 nodes in which = the > bottleneck router in the network (the spacecraft) was up to 100 = light > seconds from all other nodes and connectivity with the router was > subject to periods of disconnection lasting several days. At lest the second half of the paragraph above can be eliminated from = the charter text. You could even cut the whole thing. > The success of the BP/LTP protocol stack -- the core protocols of = the > "DTN Architecture" originally described in RFC 4838 -- in this > demonstration may be attributed to the following fundamental = design > principles: >=20 > - There is never any expectation of contemporaneous end-to-end > connectivity between any two network nodes. Where such = connectivity > is sustained, the protocols leverage it to optimize performance, > but the possibility of transient but sustained disconnection at > any time, anywhere in the network, is always recognized. >=20 > - Because end-to-end connectivity can never be assumed, each = node > on the path between source and destination must be prepared to > handle incoming "bundles" of data that cannot immediately be > forwarded. Such bundles must either be stored for future = trans- > mission or discarded; in the latter case, the network must > be informed of this data loss so that an alternative path may > be selected, to avoid impairing the usability of the network. >=20 > - Again because end-to-end connectivity can never be assumed, > end-to-end conversational data exchange can never be assumed = to > complete in a timely manner; protocol features that rely on > timely conversational data exchange must be excluded from the > architecture. This principle makes the DTN architecture > suitable not only for network environments characterized by > lengthy disconnection but also for those that are = characterized > by long signal propagation delays (such as underwater = communication > by acoustic signals or, worse, interplanetary communication) = even > when connectivity is continuous. >=20 > The DTNWG believes that protocols adhering to these principles = offer > opportunities for enhancing the functionality of the Internet - = in > particular, for facilitating the extension of the Internet into > environments such as the ocean floor and deep space in which the = core > Internet protocols operate sub-optimally for the reasons = discussed > earlier. We believe that the extensive research, demonstration, = and > pilot operations performed to date using the DTNRG protocols, = both > before and after the EPOXI experiment, provides a firm basis for > publishing Internet standards derived from that work. You could significantly shorten the body of text above, incl. the bullet = list, by simply pointing at some relevant DTNRG RFCs and say that you = want to build on what was done before and not go off to reinvent = everything. > Work items related to Delay/Disruption Tolerant Networking = include: Now we're getting to the point where the charter text actually starts to = matter: > o A mechanism for the exchange of protocol data units, termed > "bundles", that are designed to obviate conversational = communications > by containing values for all potentially relevant configuration > parameters. These protocol data units are typically larger than > network-layer packets. We expect to derive this bundle exchange > mechanism from the DTN Bundle Protocol (BP) documented in RFC = 5050. Why "expect to"? It would be good to have agreement whether or not 5050 = is the baseline here. > Expected changes from RFC 5050 include (but are not necessarily > limited to): >=20 > - a compressed bundle header encoding (derived from RFC6260) > - an immutable primary block structure > - simplified EID representations (no dictionary) > - add block ID to extension blocks (e.g. security blocks) > - move custodian to extension block > - add simple header and payload integrity checks > - add simple contact graph routing specification > - add simple neighbor discovery specification=20 List is OK for discussion, but doesn't need to be in the charter. > o A security protocol for ensuring that the network in which = bundles > are exchanged is secured against unauthorized access and denial = of > service attacks, and to ensure data integrity and = confidentiality > in that network where necessary. We expect to derive this = security > protocol from a "streamlined" adaptation of the DTN Bundle = Security > Protocol documented in RFC 6257. Again, why "expect to"? > o An encapsulation protocol for "tunneling" BP traffic within = bundles > that are secured and/or routed in different way from the = encapsulated > bundles. >=20 > o A delay-tolerant security key management scheme for ensuring = that > public keys are certified by a globally trusted authority to = protect > the integrity of the infrastructure. >=20 > o A simple datagram convergence layer protocol for adaptation of = the > bundle protocol to underlying internetworks. We expect to = derive > this convergence layer protocol from the Datagram Convergence > protocol documented in RFC7122. >=20 > o A delay-tolerant network management protocol for management of = the > infrastructure in the presence of long delays and/or = intermittent > connectivity. For all of those bullets above, are there starting points, or will these = be completely new protocol developments? (if the latter, you are setting = yourself up for a LOT of work.) > o A registry for DTN Service Identifiers >=20 > The working group will consider extending the current milestones = based on > new information and knowledge gained while working on the initial = charter, > as well as to accommodate new work items beyond the scope of the = initial > phase. For example, we expect that transport protocols uniquely = suited > to the various communication environments that may need to be = traversed > by a single DTN end-to-end path (operating under BP, at what is = termed > the DTN "convergence layer") will need to be standardized in a = second > phase of the working group's charter; LTP and the Saratoga protocol = are > among the candidates for work in this phase. These adjustments = will be > accommodated in a working group recharter, assuming the initial > chartered activities meet their delivery milestones. Possible new = work > items must then still fit into the (rechartered) DTNWG charter = scope. Paragraph can be cut. Charters can change, everyone knows that. > Goals and Milestones: Based on the current speed of the CTNRG, all these milestone deltas from = start are hugely optimistic. I'd suggest to multiply by a factor of = 2-3x. > start+3mos - Submit 'Bundle Protocol Specification (RFC5050bis)' as a > working group document. To be Proposed Standard. > Start+3mos - Submit 'Streamlined Bundle Security Protocol (SBSP)' as = a > working group document. To be Proposed Standard. > start+6mos - Submit 'Bundle In Bundle Encapsulation (BIBE)' as a = working > group document. To be Proposed Standard. > start+9mos - Submit 'Delay Tolerant Networking Security Key = Management' as > a working group document. To be Proposed = Standard. > start+9mos - WG determination for merging RFC5050bis, SBSP, BIBE = and/or > Key Mgmt into a combined draft or keep as separate = drafts. > start+12mos - Submit RFC5050bis, SBSP, BIBE and Key Mgmt to the IESG = either > as a combined draft or as separate drafts. > start+12mos - Submit Network Management, Registry and Simple = Convergence > Layer as working group documents. > start+15mos - Survey appropriate forums (e.g., DTNRG) for emerging > technologies (e.g., convergence layer protocols, = dynamic > routing protocols, naming and addressing services, = etc.) > ready for transition into IETF DTN Working Group. = Publish > draft on survey results as independent submission = related > to the WG. > start+18mos - Submit Network Management, Registry and Simple = Convergence > Layer to IESG > start+18mos - Recharter to accommodate new work items or close = Working Group Lars --Apple-Mail=_1F0CFE81-CE02-44A4-B124-E6BB4DF442E6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBU5AdIdZcnpRveo1xAQKqEgP/bNmagsqZMJu++0DIgDPt+Bb3fl2Hj7xP 4vnMOXJsEHyn5iMw8lBspiirxnmqpAKzc3R0TsDb6tzVym86mNA7nYFLzAF30lPU eUFruGU4vPNHZDVku8XG803rZBXxII/bIdpjXnWhcQt3R8ArhN+bTUaW19jJvobD Dm61Q5sp8e4= =e441 -----END PGP SIGNATURE----- --Apple-Mail=_1F0CFE81-CE02-44A4-B124-E6BB4DF442E6-- From nobody Thu Jun 5 04:20:38 2014 Return-Path: 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 BB51D1A001B; Thu, 5 Jun 2014 04:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 7ZEKY4vhQzKg; Thu, 5 Jun 2014 04:20:32 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EAD71A000B; Thu, 5 Jun 2014 04:20:31 -0700 (PDT) Received: from [85.158.136.51:55747] by server-9.bemta-5.messagelabs.com id 35/65-04350-77250935; Thu, 05 Jun 2014 11:20:23 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-4.tower-49.messagelabs.com!1401967222!21842871!1 X-Originating-IP: [131.227.200.31] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30533 invoked from network); 5 Jun 2014 11:20:23 -0000 Received: from exht011p.surrey.ac.uk (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-4.tower-49.messagelabs.com with AES128-SHA encrypted SMTP; 5 Jun 2014 11:20:23 -0000 Received: from EXHY021V.surrey.ac.uk (131.227.200.104) by exht011p.surrey.ac.uk (131.227.200.31) with Microsoft SMTP Server (TLS) id 8.3.348.2; Thu, 5 Jun 2014 12:20:22 +0100 Received: from emea01-am1-obe.outbound.protection.outlook.com (131.227.200.4) by email365.surrey.ac.uk (131.227.200.104) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 5 Jun 2014 12:20:22 +0100 Received: from AMSPR06MB439.eurprd06.prod.outlook.com (10.242.23.19) by AMSPR06MB440.eurprd06.prod.outlook.com (10.242.23.24) with Microsoft SMTP Server (TLS) id 15.0.954.9; Thu, 5 Jun 2014 11:20:21 +0000 Received: from AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) by AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) with mapi id 15.00.0954.000; Thu, 5 Jun 2014 11:20:21 +0000 From: To: , Thread-Topic: [dtn] DTN BoF Proposal for IETF90 Thread-Index: Ac+AQa9Fez/CplZaSwyaLFpzb8tj0wAiVZ0A///Hp/A= Date: Thu, 5 Jun 2014 11:20:20 +0000 Message-ID: <1401967219583.26821@surrey.ac.uk> References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com>, In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [124.149.114.231] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 0233768B38 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(199002)(189002)(40154002)(99396002)(19580395003)(76482001)(21056001)(66066001)(64706001)(80022001)(87936001)(79102001)(50986999)(74662001)(15202345003)(76176999)(54356999)(36756003)(92726001)(77096999)(85852003)(15975445006)(2656002)(77982001)(86362001)(20776003)(74482001)(81342001)(74502001)(46102001)(4396001)(83322001)(81542001)(31966008)(83072002)(101416001)(92566001)(536464002); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR06MB440; H:AMSPR06MB439.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: surrey.ac.uk does not designate permitted sender hosts) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: AMSPR06MB440.eurprd06.prod.outlook.com X-OriginatorOrg: surrey.ac.uk X-CrossPremisesHeadersPromoted: EXHY021v.surrey.ac.uk X-CrossPremisesHeadersFiltered: EXHY021v.surrey.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/ZRpvDOjRDQ5UbK3JjsD_qZD_t5Y Cc: iesg@ietf.org, dtn@ietf.org Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 11:20:36 -0000 As previously expressed on DTNRG, I have a number of concerns about=0A= this proposed BOF to create an IETF DTN WG to do work on the=0A= RFC5050 bundle protocol, produced in the IRTF DTNRG, and create=0A= an RFC5050bis. I'll go through those concerns one by one:=0A= =0A= =0A= 1. I don't see how going standards track can be justified, because:=0A= =0A= a. CCSDS is already working on the bundle protocol as one of their=0A= blue book standards, based on RFC5050, and any RFC5050bis=0A= would presumably also be adopted and then modified to make=0A= a CCSDS standard.=0A= It's rather like CCSDS restandardizing TCP/IP as SCPS, back=0A= in the 1990s. That SCPS standardization wasn't used much=0A= either, not least because CCSDS 'improved' on TCP/IP=0A= and went incompatible quite quickly. The same will happen=0A= with the CCSDS bundle protocol, and in adopting RFC5050=0A= CCSDS has reserved the right to make changes - things like=0A= Delay Tolerant Payload Conditioning (DTPC) are but the start.=0A= There's an example of bundle protocol work not requiring=0A= the IETF. Work on altering and extending the bundle protocol=0A= is already ongoing in CCSDS.=0A= Setting up an IETF workgroup to work in parallel would mean=0A= that a CCSDS liaison would be required, to pay attention=0A= to their concerns as they try and convince their member space=0A= agencies to use the bundle protocol, and to prevent their spec=0A= from diverging (further) from the IETF spec. Really, the work=0A= is simply more easily done in CCSDS, given that CCSDS is=0A= pretty much the only customer for bundle protocol, because=0A= NASA has mandated bundle protocol use from on high.=0A= NASA leads CCSDS, NASA Jet Propulsion Lab leads CCSDS design=0A= for NASA's Space Communications and Navigation people.=0A= JPL is really the primary customer for and user of bundle=0A= protocol, responsible for promoting its use by other space=0A= agencies - never an easy task, even with good technologies.=0A= =0A= b. The IETF produces Internet standards. The bundle protocol=0A= has little bearing on or interaction with Internet standards;=0A= it's arguably a way to interoperate with the Internet while=0A= protecting CCSDS from incursion of the Internet, by layering=0A= over both Internet and CCSDS. Each to their own domains.=0A= Using TCP as the most common bundle convergence layer (described=0A= in a draft now seven years old) does not make the bundle protocol=0A= an internet standard. If it did, then CCSDS's Space Link=0A= Extension (basically a TCP tunnel carrying CCSDS frames, with=0A= much added complexity) would also be a candidate for an=0A= IETF internet standard.=0A= But, again, that work is best done in CCSDS, where there=0A= is interest in having it done and there are users. (Some=0A= of those users may even be willing users.)=0A= =0A= c. The bundle protocol is not mature. Deficiencies have been=0A= identified, drafts have been written in DTNRG over the years,=0A= there was little interest, the drafts expired, the bundle=0A= protocol was never improved. And that's just from demonstrations;=0A= there has not been extended operational use to my knowledge.=0A= Attempting to fix the bundle protocol AND push it through as=0A= standards track at the same time seems unwarranted.=0A= It may be politically motivated, but it is=0A= not technically or procedurally justifiable.=0A= There isn't the userbase or demand needed for the bundle=0A= protocol to go standards track, and if the IETF did go=0A= standards track, CCSDS would 'optimize' that standard into=0A= its own standard, just as was done with SCPS, meaning that=0A= the IETF would spend a lot of time working on something with=0A= no benefit to the IETF community or userbase. Extending=0A= the Internet protocols to the DTN network problem space=0A= adds value to the internet protocols. A separate protocol=0A= does not.=0A= Who would benefit, outside the CCSDS community? And CCSDS=0A= is their own standards org - an ISO subgroup - to do work=0A= for that CCSDS community.=0A= =0A= =0A= 2. I don't see why this needs to be done in an IETF WG, because:=0A= =0A= a. going standards track isn't justifiable - see 1.=0A= =0A= b. There's already the IRTF DTNRG, which could clean up its=0A= own work, but ,after many years and some failed drafts,=0A= has not.=0A= Declaring success and saying it is now time to create a=0A= WG based on DTNRG's achievements is not convincing,=0A= because those achievements are not impressive.=0A= (Disclaimer of interest: I authored 'A bundle of problems'=0A= and have spent considerable years trying to explain and=0A= address problems with the bundle protocol, with little=0A= success, after getting it tested in space before NASA's=0A= EXPOXI/Deep Impact tests took place.=0A= Fred Templin's problem statement drafts for this putative=0A= IETF BOF calls on that work.)=0A= RFC5050bis would make more sense as a DTNRG=0A= effort, though it would be time for a changing of the=0A= guard and chairs in DTNRG to infuse some new blood and=0A= technical judgement - or we're in for another five years=0A= of what-does-the-end-to-end-principle-really-mean and=0A= what-about-clocks and rehashing the same old arguments.=0A= Really, DTNRG needs to get its act together, both=0A= organizationally and technically.=0A= =0A= c. There's already CCSDS, which has adopted the DTNRG output,=0A= after pushing for the formation of an Interplanetary=0A= Internet RG in the first place.=0A= =0A= So either CCSDS or DTNRG can do RFC5050 revision work. If=0A= it's to be an RFC, experimental or informational, a revitalised=0A= rechartered DTNRG can do it.=0A= It doesn't need to be an IETF workgroup. It certainly=0A= shouldn't go standards track.=0A= =0A= =0A= 3. The philosophically shaky basis for the bundle protocol:=0A= =0A= a. Delay-tolerant networking is not disruption-tolerant=0A= networking. Space delays of light-minutes with scheduled=0A= contacts are not the same as intermittent ad-hoc=0A= manet-style communications. Different requirements,=0A= different buffering and storage, different conditions,=0A= different handling of fragmentation, etc.=0A= =0A= b. The bundle protocol is not DTN. DTN is the scenario,=0A= in which other approaches (the related CFDP, Haggle,=0A= the MANET and vehicular DTNs efforts that DTN subsumed=0A= and rebranded, etc.) exist.=0A= The bundle protocol is intended to be used in a DTN=0A= scenario. Branding the bundle protocol as DTN has=0A= put back non-bundle DTN research a number of years.=0A= Branding a group only working on the bundle protocol=0A= as 'DTN' is misleading at best.=0A= =0A= c. Extending the bundle protocol from the original=0A= Interplanetary Internet problem (which had its own=0A= IRTF RG which led into a set bundle agenda for=0A= DTNRG) to cover everything else as well simply hasn't=0A= worked very well, because the scenarios and use cases=0A= are different. We design for use cases. To be too=0A= generalised is to engineer for nothing.=0A= =0A= d. Ignoring the ramifications of the end-to-end principle,=0A= which are often more subtle than people seem to think=0A= they are. The bundle protocol's custody transfer=0A= procedure is a good example of this failing.=0A= =0A= e. The bundle protocol is intended for use in the most=0A= difficult noisy disrupted networking conditions we know,=0A= and it can't even sanity check its own headers against=0A= errors. (But hey, it now has a security protocol that=0A= _almost_ does that! But which is too complicated, and=0A= would need to be redone.)=0A= It's intended for the harshest environments we know,=0A= but needs reliable synchronized clocks running at=0A= steady temperatures!=0A= It's intended for embedded systems, but the design=0A= is huge and complex! (CFDP has the same problem;=0A= there's a reason implementers went for a "CFDP lite,"=0A= and Saratoga exists just because CFDP wasn't performing.=0A= Would RFC5050bis be "bundling lite"?) =0A= There are many 'that makes no sense' moments - normally=0A= more immediately visible to outsiders not steeped in=0A= the dogma, politics, and history of DTNRG and CCSDS.=0A= =0A= f. The assumption that a full security suite is desirable=0A= and necessary at all times. This has derailed DTNRG,=0A= as emphasis was placed on security work above all=0A= else, rather than working to the scenario. To be fair=0A= to the security-focused chairs, the charter that=0A= established DTNRG from the interplanetary internet=0A= research group called out security heavily, and they=0A= ran with that mandate. But the focus has decreased=0A= work on non-security matters, which is to say,=0A= everything else.=0A= =0A= RFC5050bis might address the latter three problems, but=0A= the first three are intrinsically unsolvable; any solution=0A= will be unsatisfactory. Perhaps not as unsatisfactory as=0A= RFC5050, but unsatisfactory nonetheless.=0A= =0A= The real philosophical problem here is the political dogma=0A= that, whatever the problem, the bundle protocol is The=0A= One True Solution.=0A= =0A= =0A= 4. The draft BOF charter is bundle-centric. Which is to say,=0A= that it's not awfully relevant to internet standards.=0A= Disclaimer of interest: we've worked on Saratoga and=0A= HTTP-DTN, which have current internet-drafts, and are=0A= squarely in the DTN problem space.=0A= Whenever someone talks about multiple convergence=0A= layers for the bundle protocol - there's more than for BEEP,=0A= which just has TCP, but there aren't many - Saratoga may=0A= be mentioned. But we've found that carrying bundles doesn't=0A= benefit Saratoga - tested it in space, didn't see the=0A= advantages. Saratoga does leverage a few Internet things -=0A= UDP, UDP-Lite, multicast. It does a few scaling things that=0A= nothing else I've seen does (described in our 2011 TSVAREA=0A= presentation to IETF 88 in November.) And it's based on=0A= a decade of operational use in the problem domain.=0A= HTTP-DTN leverages the HTTP suite and MIME, and comes up=0A= whenever wouldn't-it-be-nice-to-try-HTTP-for-DTN discussion=0A= takes place.=0A= (I suspect that all of Stephen Farrell's N4C work could=0A= have been done over hop-by-hop HTTP a la HTTP-DTN, and=0A= would have worked just as well if not better. After all,=0A= it used TCP.)=0A= These and other efforts exist in a gap between DTNRG, which=0A= is aware of the problem space, but thinks the bundle=0A= protocol is the solution despite mounting evidence to the=0A= contrary, and TSVWG, where the few actual transport=0A= experts live, without clout, or funding, or spare time.=0A= Those efforts are interesting enough to have implementations=0A= kicking around too.=0A= And yet, the focus of this putative workgroup and BOF is=0A= solely on bundling, and not on evaluating these or other=0A= things that might exist in the problem space. There=0A= must be other things out there that would be of interest=0A= to such a DTN workgroup. What is proposed is not a DTN=0A= workgroup. The charter is basically a bundle workgroup.=0A= Can an interest in bundling and solely bundling (outside=0A= CCSDS, which is driving the push to use the bundle protocol)=0A= be justified for an IETF workgroup? I really don't think so.=0A= =0A= 5. The bundle protocol work was, I gather, well-funded=0A= by a number of parties.=0A= I can't see a follow-on effort being anywhere near=0A= as well funded.=0A= =0A= a. I have no idea how much money NASA and CCSDS have put=0A= into this - first CFDP, then bundling, which now has=0A= to provide a CFDP-like API to the users who were told=0A= that CFDP was the future, and Licklider (LTP).=0A= Dragging CCSDS into the modern age of networking=0A= seems unlikely to ever happen, thanks to CCSDS having=0A= little in the way of sane layering or separation of=0A= functionality.=0A= I do have the luxury of not needing to work on CCSDS.=0A= But if you want to work on CCSDS protocols, CCSDS is=0A= the place to go. The IETF is not that place.=0A= =0A= b. DARPA poured money into DTN work - at least twenty=0A= million dollars, from the press releases I've seen.=0A= I have no idea what DARPA got out of it in the=0A= years they were involved; haven't seen the reports.=0A= =0A= My point is, all that money and effort and manpower and=0A= over a decade of work and prior experience with CFDP and two=0A= IRTF RGs, we have... RFC5050.=0A= There is nowhere near as much money or effort or manpower=0A= for doing a replacement.=0A= Ergo, it might be suggested that the replacement is unlikely=0A= to be as good as RFC5050, or as good as CFDP; at best,=0A= the usual suspects will have less time and fewer resources=0A= to repeat their original mistakes.=0A= =0A= And transport expertise from TSVWG would be needed.=0A= TSVWG is unfashionable, low-visibility, and has even=0A= previously had trouble finding ADs with relevant expertise.=0A= And TSVWG has a full plate with work on its existing=0A= protocols; there is not a lot of expertise, and what there=0A= is is spread thin.=0A= So an RFC505bis effort is unlikely to get the expert=0A= technical input that it sorely needs, even if an IETF=0A= workgroup is set up. (CCSDS doesn't have that transport=0A= focus.)=0A= =0A= If, on the other hand, you believe good protocol design=0A= can be done more cheaply and leverage actual Internet=0A= standards to get Internet functionality working in=0A= difficult networks where the full TCP/IP suite has=0A= trouble, your options include Saratoga and HTTP-DTN!=0A= http://saratoga.sourceforge.net/=0A= http://sat-net.com/L.Wood/dtn/http-dtn.html=0A= They'll truly extend the Internet to difficult=0A= environments. The bundle protocol won't.=0A= =0A= So, to conclude, there is no justification for going=0A= standards track. There is little justification for an=0A= IETF workgroup. There is more logic in rechartering and=0A= repurposing the IRTF DTNRG, but the work may as well=0A= be left to CCSDS entirely.=0A= =0A= RFC5050bis: half-assed, half-baked, reheated.=0A= But hey, ask me what I _really_ think.=0A= =0A= Lloyd Wood=0A= http://sat-net.com/L.Wood/dtn/=0A= From nobody Thu Jun 5 08:53:56 2014 Return-Path: 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 E0FB71A025E for ; Thu, 5 Jun 2014 08:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 86AUhJg1qcUa for ; Thu, 5 Jun 2014 08:53:53 -0700 (PDT) Received: from mail.jpl.nasa.gov (sentrion1.jpl.nasa.gov [128.149.139.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A3F41A0246 for ; Thu, 5 Jun 2014 08:53:53 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp01.jpl.nasa.gov [128.149.137.148]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s55FrHlZ009413 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO) for ; Thu, 5 Jun 2014 08:53:18 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.156]) by ap-ehub-sp01.RES.AD.JPL ([169.254.3.182]) with mapi id 14.03.0174.001; Thu, 5 Jun 2014 08:53:46 -0700 From: "Burleigh, Scott C (312G)" To: "dtn@ietf.org" Thread-Topic: [dtn] Proposed Working Group Charter Suggestions Thread-Index: AQFSocO/D9uhW69j0yAuOdgV0znNWQHFMXAmASCcbEQBbA2hJAHfUcS+AdrD57cB7vfjCQJo1+2NAbk5oBoBhgwXi5vfSS4w Date: Thu, 5 Jun 2014 15:53:45 +0000 Message-ID: References: <2134F8430051B64F815C691A62D983181B2BD2DE@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2BD423@XCH-BLV-504.nw.nos.boeing.com> <538E35F6.2010702@cs.tcd.ie> <538F3D53.5060305@per.reau.lt> <538FF2F8.5070605@mti-systems.com> In-Reply-To: <538FF2F8.5070605@mti-systems.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.26] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/qaF1eghNQ_GD95jVY_-fPJV92ys Subject: Re: [dtn] Proposed Working Group Charter Suggestions X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 15:53:55 -0000 Wes, thanks! You have brought up an issue that I think has never received = enough research attention. The purpose of the lifetime field in bundles is, essentially, congestion co= ntrol: a way is needed to flush data out of the network that most likely wi= ll never get delivered, so as to resources needed for other traffic. In th= e Internet we can do this with a hop count, because the packets are always = in motion and signal propagation delays are small; any hop count limit will= map to a packet lifetime limit with a small, fairly predictable upper boun= d. In a DTN-based network this is no good: a bundle could make one hop to = a router node that (unknown to it) will never have a path forward to the de= stination. Without an explicit lifetime limit the bundle could occupy stor= age on that node forever, waiting for a forwarding opportunity that will ne= ver come. But you're right, there aren't a lot of guidelines for selecting that lifet= ime limit. Somebody should come up with some. Considering this just in terms of ION (the DTN software that I've got most = experience with), I think one approach might be to pick some lifetime value= at random, do a simulation of CGR-based traffic, and see what percentage o= f bundles are abandoned at the source because CGR discovers that they can't= possibly be delivered prior to bundle expiration time. Then increase or d= ecrease that standard lifetime and repeat until that percentage is low enou= gh to be tolerable. Another approach might be to look at some sample contact plans, compute the= expected delivery times for bundles sent from every node to every other no= de at some given moment, and look for a relationship between the maximum ex= pected delivery times and some characteristics of the corresponding contact= plans. Again, for now this could only be done for flight mission scenarios because= the contact plans used by CGR include only scheduled, relatively certain c= ontacts. Over the next few months we hope to be adding opportunistic and p= robabilistic contacts to those contact plans, which should open CGR up for = use in terrestrial DTN scenarios. Scott -----Original Message----- From: Wesley Eddy [mailto:wes@mti-systems.com]=20 Sent: Wednesday, June 04, 2014 9:33 PM To: Burleigh, Scott C (312G); Ivancic, William D. (GRC-RHN0); dtn@ietf.org Subject: Re: [dtn] Proposed Working Group Charter Suggestions On 6/4/2014 7:28 PM, Burleigh, Scott C (312G) wrote: > And you are quite wrong about nobody using bundle lifetimes to make=20 > bundle forwarding decisions: bundle expiration time is a critical=20 > parameter in contact graph routing. I think the point is not that routing algorithms can't use it appropriately= , but rather than sending applications so far haven't generally been able t= o set it with any meaningful granularity so that it would then cause the ro= uting system to be able to do intelligent things. I.e. if all bundles coming through have the same very long lifetime, it wil= l not impact the routing decisions, even if there happens to be logic that = incorporates the lifetime. This doesn't exclude the possibility that there's a system somewhere in whi= ch the applications can really make use of a whole spectrum of lifetime val= ues, but it doesn't look like the general case so far. -- Wes Eddy MTI Systems From nobody Thu Jun 5 09:12:18 2014 Return-Path: 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 A23751A010B for ; Thu, 5 Jun 2014 09:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 VrejR83SF0fI for ; Thu, 5 Jun 2014 09:12:13 -0700 (PDT) Received: from ndjsnpf03.ndc.nasa.gov (ndjsnpf03.ndc.nasa.gov [IPv6:2001:4d0:a302:1100::103]) by ietfa.amsl.com (Postfix) with ESMTP id 7F21B1A00A6 for ; Thu, 5 Jun 2014 09:12:07 -0700 (PDT) Received: from ndjsppt102.ndc.nasa.gov (ndjsppt102.ndc.nasa.gov [198.117.1.196]) by ndjsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 6047C2D80DF for ; Thu, 5 Jun 2014 11:12:00 -0500 (CDT) Received: from NDJSCHT108.ndc.nasa.gov (ndjscht108-pub.ndc.nasa.gov [198.117.1.208]) by ndjsppt102.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id s55GC0vW022059 for ; Thu, 5 Jun 2014 11:12:00 -0500 Received: from NDJSMBX203.ndc.nasa.gov ([169.254.2.8]) by NDJSCHT108.ndc.nasa.gov ([198.117.1.208]) with mapi id 14.03.0174.001; Thu, 5 Jun 2014 11:12:00 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: "Burleigh, Scott C (JPL-312G)[Jet Propulsion Laboratory]" , "dtn@ietf.org" Thread-Topic: [dtn] Proposed Working Group Charter Suggestions Thread-Index: AQHPf14xoT809BzuHUKQYykab/OBU5tgMQkAgAANJYCAASzPgP//yzgAgACNmID//8r8AIAAX8qAgABU8wCAAL44gP//wgcA Date: Thu, 5 Jun 2014 16:11:59 +0000 Message-ID: References: <2134F8430051B64F815C691A62D983181B2BD2DE@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2BD423@XCH-BLV-504.nw.nos.boeing.com> <538E35F6.2010702@cs.tcd.ie> <538F3D53.5060305@per.reau.lt> <538FF2F8.5070605@mti-systems.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [184.56.61.175] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-06-05_05:2014-06-05,2014-06-05,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/mLvHZ2cnEo_bsZXWGaMBn5lqSNY Subject: Re: [dtn] Proposed Working Group Charter Suggestions X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 16:12:14 -0000 Hmmm. It appears that maybe there should be a document on what lifetime is used for. I never thought of it as congestion control. I always thought of it a how long the information in the bundle is useful for - analogous to expiration dates on the food in your refrigerator. For example: Help, I'M drownding! =3D 1 minute (assuming I have decent lung capacity) Happy Birthday (and your birthday is tomorrow) =3D 24 hours Happy New Year 2015 =3D whatever the math is that works out to that number of days. I think BBN sort of did this the best they could with two code points. Which is why I always thought one would want to consider how much longer a bundle is valid for when making forwarding decisions. I always consider hop count a mechanism to kill traffic stuck in a routing loop and the reason I proposed hop count in the base header of bundling or whatever Store, Carry and Forward mechanism one implements. Will ****************************** On 6/5/14 11:53 AM, "Burleigh, Scott C (312G)" wrote: >Wes, thanks! You have brought up an issue that I think has never >received enough research attention. > >The purpose of the lifetime field in bundles is, essentially, congestion >control: a way is needed to flush data out of the network that most >likely will never get delivered, so as to resources needed for other >traffic. In the Internet we can do this with a hop count, because the >packets are always in motion and signal propagation delays are small; any >hop count limit will map to a packet lifetime limit with a small, fairly >predictable upper bound. In a DTN-based network this is no good: a >bundle could make one hop to a router node that (unknown to it) will >never have a path forward to the destination. Without an explicit >lifetime limit the bundle could occupy storage on that node forever, >waiting for a forwarding opportunity that will never come. > >But you're right, there aren't a lot of guidelines for selecting that >lifetime limit. Somebody should come up with some...... > From nobody Thu Jun 5 09:29:33 2014 Return-Path: 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 0C9F01A030F; Thu, 5 Jun 2014 09:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, 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 m1iSl3z_OgV5; Thu, 5 Jun 2014 09:29:26 -0700 (PDT) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FF2C1A023E; Thu, 5 Jun 2014 09:29:25 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id sa20so1541942veb.27 for ; Thu, 05 Jun 2014 09:29:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ppBdkjvrZ47EwgBaZNyzcfn2zMLM70DRjmv/94lXumo=; b=K2B39WfHFrVFTbqVIIbpw1ZV0kzG8+VYsr6G32isPxwIQTu1C6S+UQ67dC4TlmhJfu +fx4c88Um/Q4sMB89GSyS+914foqZLRSCaitBEWpWgEpRIyhXiGw0rOSJOIoRv+lkaQx dwyJjEBnqb7cZ0amI2eG5kJBetyLC9I6VuA3HkcJreiQoDI0rEjxle3m5t6eeJKn0zzl yMZRcZ3aARm1EvFN5VJ6ieZDI5WXkpXr7DRMuGy5msvrlMH0LKwr4zTzW+2RajOYfLsr zZ18KhNaix5Dp2j2senovZWxiX3NVRwaPWNE9iPqUoAnVJwXc/dNBhs6QYx+d71M6Ngr uxXQ== MIME-Version: 1.0 X-Received: by 10.52.120.75 with SMTP id la11mr8853561vdb.56.1401985758676; Thu, 05 Jun 2014 09:29:18 -0700 (PDT) Received: by 10.52.99.100 with HTTP; Thu, 5 Jun 2014 09:29:18 -0700 (PDT) In-Reply-To: <1401967219583.26821@surrey.ac.uk> References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> <1401967219583.26821@surrey.ac.uk> Date: Thu, 5 Jun 2014 12:29:18 -0400 Message-ID: From: Eric Travis To: "l.wood@surrey.ac.uk" Content-Type: multipart/alternative; boundary=089e013a13c4204c7f04fb193f21 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/a6ZXvOtLe5TiCwd3hvCUVkhwQMA Cc: mls.ietf@gmail.com, spencerdawkins.ietf@gmail.com, dtn@ietf.org, iesg@ietf.org Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 16:29:30 -0000 --089e013a13c4204c7f04fb193f21 Content-Type: text/plain; charset=UTF-8 Lloyd, Embedded in your manifesto are two points worthy of discussion/debate throughout the BoF process: 1) Is the proposed (base) solution - with "minimal" fixes - of sufficient maturity for standardization within the IETF? 2) The existing IRTF DTNRG has not been able to harness sufficient interest/resources to advance the state of RFC-5050, how will a new IETF WG change the dynamic? As for the rest of it, well... RFC5050bis: half-assed, half-baked, reheated. > But hey, ask me what I _really_ think. > Let the rational, well-reasoned discussion begin... Eric eric.dot.travis@gmail.com On Thu, Jun 5, 2014 at 7:20 AM, wrote: > As previously expressed on DTNRG, I have a number of concerns about > this proposed BOF to create an IETF DTN WG to do work on the > RFC5050 bundle protocol, produced in the IRTF DTNRG, and create > an RFC5050bis. I'll go through those concerns one by one: > > > 1. I don't see how going standards track can be justified, because: > > a. CCSDS is already working on the bundle protocol as one of their > blue book standards, based on RFC5050, and any RFC5050bis > would presumably also be adopted and then modified to make > a CCSDS standard. > It's rather like CCSDS restandardizing TCP/IP as SCPS, back > in the 1990s. That SCPS standardization wasn't used much > either, not least because CCSDS 'improved' on TCP/IP > and went incompatible quite quickly. The same will happen > with the CCSDS bundle protocol, and in adopting RFC5050 > CCSDS has reserved the right to make changes - things like > Delay Tolerant Payload Conditioning (DTPC) are but the start. > There's an example of bundle protocol work not requiring > the IETF. Work on altering and extending the bundle protocol > is already ongoing in CCSDS. > Setting up an IETF workgroup to work in parallel would mean > that a CCSDS liaison would be required, to pay attention > to their concerns as they try and convince their member space > agencies to use the bundle protocol, and to prevent their spec > from diverging (further) from the IETF spec. Really, the work > is simply more easily done in CCSDS, given that CCSDS is > pretty much the only customer for bundle protocol, because > NASA has mandated bundle protocol use from on high. > NASA leads CCSDS, NASA Jet Propulsion Lab leads CCSDS design > for NASA's Space Communications and Navigation people. > JPL is really the primary customer for and user of bundle > protocol, responsible for promoting its use by other space > agencies - never an easy task, even with good technologies. > > b. The IETF produces Internet standards. The bundle protocol > has little bearing on or interaction with Internet standards; > it's arguably a way to interoperate with the Internet while > protecting CCSDS from incursion of the Internet, by layering > over both Internet and CCSDS. Each to their own domains. > Using TCP as the most common bundle convergence layer (described > in a draft now seven years old) does not make the bundle protocol > an internet standard. If it did, then CCSDS's Space Link > Extension (basically a TCP tunnel carrying CCSDS frames, with > much added complexity) would also be a candidate for an > IETF internet standard. > But, again, that work is best done in CCSDS, where there > is interest in having it done and there are users. (Some > of those users may even be willing users.) > > c. The bundle protocol is not mature. Deficiencies have been > identified, drafts have been written in DTNRG over the years, > there was little interest, the drafts expired, the bundle > protocol was never improved. And that's just from demonstrations; > there has not been extended operational use to my knowledge. > Attempting to fix the bundle protocol AND push it through as > standards track at the same time seems unwarranted. > It may be politically motivated, but it is > not technically or procedurally justifiable. > There isn't the userbase or demand needed for the bundle > protocol to go standards track, and if the IETF did go > standards track, CCSDS would 'optimize' that standard into > its own standard, just as was done with SCPS, meaning that > the IETF would spend a lot of time working on something with > no benefit to the IETF community or userbase. Extending > the Internet protocols to the DTN network problem space > adds value to the internet protocols. A separate protocol > does not. > Who would benefit, outside the CCSDS community? And CCSDS > is their own standards org - an ISO subgroup - to do work > for that CCSDS community. > > > 2. I don't see why this needs to be done in an IETF WG, because: > > a. going standards track isn't justifiable - see 1. > > b. There's already the IRTF DTNRG, which could clean up its > own work, but ,after many years and some failed drafts, > has not. > Declaring success and saying it is now time to create a > WG based on DTNRG's achievements is not convincing, > because those achievements are not impressive. > (Disclaimer of interest: I authored 'A bundle of problems' > and have spent considerable years trying to explain and > address problems with the bundle protocol, with little > success, after getting it tested in space before NASA's > EXPOXI/Deep Impact tests took place. > Fred Templin's problem statement drafts for this putative > IETF BOF calls on that work.) > RFC5050bis would make more sense as a DTNRG > effort, though it would be time for a changing of the > guard and chairs in DTNRG to infuse some new blood and > technical judgement - or we're in for another five years > of what-does-the-end-to-end-principle-really-mean and > what-about-clocks and rehashing the same old arguments. > Really, DTNRG needs to get its act together, both > organizationally and technically. > > c. There's already CCSDS, which has adopted the DTNRG output, > after pushing for the formation of an Interplanetary > Internet RG in the first place. > > So either CCSDS or DTNRG can do RFC5050 revision work. If > it's to be an RFC, experimental or informational, a revitalised > rechartered DTNRG can do it. > It doesn't need to be an IETF workgroup. It certainly > shouldn't go standards track. > > > 3. The philosophically shaky basis for the bundle protocol: > > a. Delay-tolerant networking is not disruption-tolerant > networking. Space delays of light-minutes with scheduled > contacts are not the same as intermittent ad-hoc > manet-style communications. Different requirements, > different buffering and storage, different conditions, > different handling of fragmentation, etc. > > b. The bundle protocol is not DTN. DTN is the scenario, > in which other approaches (the related CFDP, Haggle, > the MANET and vehicular DTNs efforts that DTN subsumed > and rebranded, etc.) exist. > The bundle protocol is intended to be used in a DTN > scenario. Branding the bundle protocol as DTN has > put back non-bundle DTN research a number of years. > Branding a group only working on the bundle protocol > as 'DTN' is misleading at best. > > c. Extending the bundle protocol from the original > Interplanetary Internet problem (which had its own > IRTF RG which led into a set bundle agenda for > DTNRG) to cover everything else as well simply hasn't > worked very well, because the scenarios and use cases > are different. We design for use cases. To be too > generalised is to engineer for nothing. > > d. Ignoring the ramifications of the end-to-end principle, > which are often more subtle than people seem to think > they are. The bundle protocol's custody transfer > procedure is a good example of this failing. > > e. The bundle protocol is intended for use in the most > difficult noisy disrupted networking conditions we know, > and it can't even sanity check its own headers against > errors. (But hey, it now has a security protocol that > _almost_ does that! But which is too complicated, and > would need to be redone.) > It's intended for the harshest environments we know, > but needs reliable synchronized clocks running at > steady temperatures! > It's intended for embedded systems, but the design > is huge and complex! (CFDP has the same problem; > there's a reason implementers went for a "CFDP lite," > and Saratoga exists just because CFDP wasn't performing. > Would RFC5050bis be "bundling lite"?) > There are many 'that makes no sense' moments - normally > more immediately visible to outsiders not steeped in > the dogma, politics, and history of DTNRG and CCSDS. > > f. The assumption that a full security suite is desirable > and necessary at all times. This has derailed DTNRG, > as emphasis was placed on security work above all > else, rather than working to the scenario. To be fair > to the security-focused chairs, the charter that > established DTNRG from the interplanetary internet > research group called out security heavily, and they > ran with that mandate. But the focus has decreased > work on non-security matters, which is to say, > everything else. > > RFC5050bis might address the latter three problems, but > the first three are intrinsically unsolvable; any solution > will be unsatisfactory. Perhaps not as unsatisfactory as > RFC5050, but unsatisfactory nonetheless. > > The real philosophical problem here is the political dogma > that, whatever the problem, the bundle protocol is The > One True Solution. > > > 4. The draft BOF charter is bundle-centric. Which is to say, > that it's not awfully relevant to internet standards. > Disclaimer of interest: we've worked on Saratoga and > HTTP-DTN, which have current internet-drafts, and are > squarely in the DTN problem space. > Whenever someone talks about multiple convergence > layers for the bundle protocol - there's more than for BEEP, > which just has TCP, but there aren't many - Saratoga may > be mentioned. But we've found that carrying bundles doesn't > benefit Saratoga - tested it in space, didn't see the > advantages. Saratoga does leverage a few Internet things - > UDP, UDP-Lite, multicast. It does a few scaling things that > nothing else I've seen does (described in our 2011 TSVAREA > presentation to IETF 88 in November.) And it's based on > a decade of operational use in the problem domain. > HTTP-DTN leverages the HTTP suite and MIME, and comes up > whenever wouldn't-it-be-nice-to-try-HTTP-for-DTN discussion > takes place. > (I suspect that all of Stephen Farrell's N4C work could > have been done over hop-by-hop HTTP a la HTTP-DTN, and > would have worked just as well if not better. After all, > it used TCP.) > These and other efforts exist in a gap between DTNRG, which > is aware of the problem space, but thinks the bundle > protocol is the solution despite mounting evidence to the > contrary, and TSVWG, where the few actual transport > experts live, without clout, or funding, or spare time. > Those efforts are interesting enough to have implementations > kicking around too. > And yet, the focus of this putative workgroup and BOF is > solely on bundling, and not on evaluating these or other > things that might exist in the problem space. There > must be other things out there that would be of interest > to such a DTN workgroup. What is proposed is not a DTN > workgroup. The charter is basically a bundle workgroup. > Can an interest in bundling and solely bundling (outside > CCSDS, which is driving the push to use the bundle protocol) > be justified for an IETF workgroup? I really don't think so. > > 5. The bundle protocol work was, I gather, well-funded > by a number of parties. > I can't see a follow-on effort being anywhere near > as well funded. > > a. I have no idea how much money NASA and CCSDS have put > into this - first CFDP, then bundling, which now has > to provide a CFDP-like API to the users who were told > that CFDP was the future, and Licklider (LTP). > Dragging CCSDS into the modern age of networking > seems unlikely to ever happen, thanks to CCSDS having > little in the way of sane layering or separation of > functionality. > I do have the luxury of not needing to work on CCSDS. > But if you want to work on CCSDS protocols, CCSDS is > the place to go. The IETF is not that place. > > b. DARPA poured money into DTN work - at least twenty > million dollars, from the press releases I've seen. > I have no idea what DARPA got out of it in the > years they were involved; haven't seen the reports. > > My point is, all that money and effort and manpower and > over a decade of work and prior experience with CFDP and two > IRTF RGs, we have... RFC5050. > There is nowhere near as much money or effort or manpower > for doing a replacement. > Ergo, it might be suggested that the replacement is unlikely > to be as good as RFC5050, or as good as CFDP; at best, > the usual suspects will have less time and fewer resources > to repeat their original mistakes. > > And transport expertise from TSVWG would be needed. > TSVWG is unfashionable, low-visibility, and has even > previously had trouble finding ADs with relevant expertise. > And TSVWG has a full plate with work on its existing > protocols; there is not a lot of expertise, and what there > is is spread thin. > So an RFC505bis effort is unlikely to get the expert > technical input that it sorely needs, even if an IETF > workgroup is set up. (CCSDS doesn't have that transport > focus.) > > If, on the other hand, you believe good protocol design > can be done more cheaply and leverage actual Internet > standards to get Internet functionality working in > difficult networks where the full TCP/IP suite has > trouble, your options include Saratoga and HTTP-DTN! > http://saratoga.sourceforge.net/ > http://sat-net.com/L.Wood/dtn/http-dtn.html > They'll truly extend the Internet to difficult > environments. The bundle protocol won't. > > So, to conclude, there is no justification for going > standards track. There is little justification for an > IETF workgroup. There is more logic in rechartering and > repurposing the IRTF DTNRG, but the work may as well > be left to CCSDS entirely. > > RFC5050bis: half-assed, half-baked, reheated. > But hey, ask me what I _really_ think. > > Lloyd Wood > http://sat-net.com/L.Wood/dtn/ > > _______________________________________________ > dtn mailing list > dtn@ietf.org > https://www.ietf.org/mailman/listinfo/dtn > -- *The problem with the world is that the intelligent people are full of doubts, while the stupid ones are full of confidence.* * - Charles Bukowski* --089e013a13c4204c7f04fb193f21 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Lloyd,

Embedded in your manifesto ar= e two points worthy of discussion/debate throughout the BoF process:
1) Is the proposed (base) solution - with "minimal" fixes - of s= ufficient maturity for standardization within the IETF?

2) The existing IRTF DTNRG has not been able to harness sufficient inte= rest/resources to advance the state of RFC-5050, how will a new IETF WG cha= nge the dynamic?

As for the rest of it, well...

RFC5050bis: half-assed, half-baked, reheated.
But hey, ask me what I _really_ think.

Let the rational, well-reasoned discussion begin...

= Eric
eric.dot.travis@= gmail.com


On Thu, Jun 5, 2014 at 7:20 AM, <l.wood@surrey.ac.uk> wro= te:
As previously expressed on DTNRG, I have a number of concerns about
this proposed BOF to create an IETF DTN WG to do work on the
RFC5050 bundle protocol, produced in the IRTF DTNRG, and create
an RFC5050bis. I'll go through those concerns one by one:


1. I don't see how going standards track can be justified, because:

=C2=A0 =C2=A0a. CCSDS is already working on the bundle protocol as one of t= heir
=C2=A0 =C2=A0 =C2=A0 blue book standards, based on RFC5050, and any RFC5050= bis
=C2=A0 =C2=A0 =C2=A0 would presumably also be adopted and then modified to = make
=C2=A0 =C2=A0 =C2=A0 a CCSDS standard.
=C2=A0 =C2=A0 =C2=A0 It's rather like CCSDS restandardizing TCP/IP as S= CPS, back
=C2=A0 =C2=A0 =C2=A0 in the 1990s. That SCPS standardization wasn't use= d much
=C2=A0 =C2=A0 =C2=A0 either, not least because CCSDS 'improved' on = TCP/IP
=C2=A0 =C2=A0 =C2=A0 and went incompatible quite quickly. The same will hap= pen
=C2=A0 =C2=A0 =C2=A0 with the CCSDS bundle protocol, and in adopting RFC505= 0
=C2=A0 =C2=A0 =C2=A0 CCSDS has reserved the right to make changes - things = like
=C2=A0 =C2=A0 =C2=A0 Delay Tolerant Payload Conditioning (DTPC) are but the= start.
=C2=A0 =C2=A0 =C2=A0 There's an example of bundle protocol work not req= uiring
=C2=A0 =C2=A0 =C2=A0 the IETF. Work on altering and extending the bundle pr= otocol
=C2=A0 =C2=A0 =C2=A0 is already ongoing in CCSDS.
=C2=A0 =C2=A0 =C2=A0 Setting up an IETF workgroup to work in parallel would= mean
=C2=A0 =C2=A0 =C2=A0 that a CCSDS liaison would be required, to pay attenti= on
=C2=A0 =C2=A0 =C2=A0 to their concerns as they try and convince their membe= r space
=C2=A0 =C2=A0 =C2=A0 agencies to use the bundle protocol, and to prevent th= eir spec
=C2=A0 =C2=A0 =C2=A0 from diverging (further) from the IETF spec. Really, t= he work
=C2=A0 =C2=A0 =C2=A0 is simply more easily done in CCSDS, given that CCSDS = is
=C2=A0 =C2=A0 =C2=A0 pretty much the only customer for bundle protocol, bec= ause
=C2=A0 =C2=A0 =C2=A0 NASA has mandated bundle protocol use from on high. =C2=A0 =C2=A0 =C2=A0 NASA leads CCSDS, NASA Jet Propulsion Lab leads CCSDS = design
=C2=A0 =C2=A0 =C2=A0 for NASA's Space Communications and Navigation peo= ple.
=C2=A0 =C2=A0 =C2=A0 JPL is really the primary customer for and user of bun= dle
=C2=A0 =C2=A0 =C2=A0 protocol, responsible for promoting its use by other s= pace
=C2=A0 =C2=A0 =C2=A0 agencies - never an easy task, even with good technolo= gies.

=C2=A0 =C2=A0b. The IETF produces Internet standards. The bundle protocol =C2=A0 =C2=A0 =C2=A0 has little bearing on or interaction with Internet sta= ndards;
=C2=A0 =C2=A0 =C2=A0 it's arguably a way to interoperate with the Inter= net while
=C2=A0 =C2=A0 =C2=A0 protecting CCSDS from incursion of the Internet, by la= yering
=C2=A0 =C2=A0 =C2=A0 over both Internet and CCSDS. Each to their own domain= s.
=C2=A0 =C2=A0 =C2=A0 Using TCP as the most common bundle convergence layer = (described
=C2=A0 =C2=A0 =C2=A0 in a draft now seven years old) does not make the bund= le protocol
=C2=A0 =C2=A0 =C2=A0 an internet standard. If it did, then CCSDS's Spac= e Link
=C2=A0 =C2=A0 =C2=A0 Extension (basically a TCP tunnel carrying CCSDS frame= s, with
=C2=A0 =C2=A0 =C2=A0 much added complexity) would also be a candidate for a= n
=C2=A0 =C2=A0 =C2=A0 IETF internet standard.
=C2=A0 =C2=A0 =C2=A0 But, again, that work is best done in CCSDS, where the= re
=C2=A0 =C2=A0 =C2=A0 is interest in having it done and there are users. (So= me
=C2=A0 =C2=A0 =C2=A0 of those users may even be willing users.)

=C2=A0 =C2=A0c. The bundle protocol is not mature. Deficiencies have been =C2=A0 =C2=A0 =C2=A0 identified, drafts have been written in DTNRG over the= years,
=C2=A0 =C2=A0 =C2=A0 there was little interest, the drafts expired, the bun= dle
=C2=A0 =C2=A0 =C2=A0 protocol was never improved. And that's just from = demonstrations;
=C2=A0 =C2=A0 =C2=A0 there has not been extended operational use to my know= ledge.
=C2=A0 =C2=A0 =C2=A0 Attempting to fix the bundle protocol AND push it thro= ugh as
=C2=A0 =C2=A0 =C2=A0 standards track at the same time seems unwarranted. =C2=A0 =C2=A0 =C2=A0 It may be politically motivated, but it is
=C2=A0 =C2=A0 =C2=A0 not technically or procedurally justifiable.
=C2=A0 =C2=A0 =C2=A0 There isn't the userbase or demand needed for the = bundle
=C2=A0 =C2=A0 =C2=A0 protocol to go standards track, and if the IETF did go=
=C2=A0 =C2=A0 =C2=A0 standards track, CCSDS would 'optimize' that s= tandard into
=C2=A0 =C2=A0 =C2=A0 its own standard, just as was done with SCPS, meaning = that
=C2=A0 =C2=A0 =C2=A0 the IETF would spend a lot of time working on somethin= g with
=C2=A0 =C2=A0 =C2=A0 no benefit to the IETF community or userbase. Extendin= g
=C2=A0 =C2=A0 =C2=A0 the Internet protocols to the DTN network problem spac= e
=C2=A0 =C2=A0 =C2=A0 adds value to the internet protocols. A separate proto= col
=C2=A0 =C2=A0 =C2=A0 does not.
=C2=A0 =C2=A0 =C2=A0 Who would benefit, outside the CCSDS community? And CC= SDS
=C2=A0 =C2=A0 =C2=A0 is their own standards org - an ISO subgroup - to do w= ork
=C2=A0 =C2=A0 =C2=A0 for that CCSDS community.


2. I don't see why this needs to be done in an IETF WG, because:

=C2=A0 =C2=A0a. going standards track isn't justifiable - see 1.

=C2=A0 =C2=A0b. There's already the IRTF DTNRG, which could clean up it= s
=C2=A0 =C2=A0 =C2=A0 own work, but ,after many years and some failed drafts= ,
=C2=A0 =C2=A0 =C2=A0 has not.
=C2=A0 =C2=A0 =C2=A0 Declaring success and saying it is now time to create = a
=C2=A0 =C2=A0 =C2=A0 WG based on DTNRG's achievements is not convincing= ,
=C2=A0 =C2=A0 =C2=A0 because those achievements are not impressive.
=C2=A0 =C2=A0 =C2=A0 (Disclaimer of interest: I authored 'A bundle of p= roblems'
=C2=A0 =C2=A0 =C2=A0 and have spent considerable years trying to explain an= d
=C2=A0 =C2=A0 =C2=A0 address problems with the bundle protocol, with little=
=C2=A0 =C2=A0 =C2=A0 success, after getting it tested in space before NASA&= #39;s
=C2=A0 =C2=A0 =C2=A0 EXPOXI/Deep Impact tests took place.
=C2=A0 =C2=A0 =C2=A0 Fred Templin's problem statement drafts for this p= utative
=C2=A0 =C2=A0 =C2=A0 IETF BOF calls on that work.)
=C2=A0 =C2=A0 =C2=A0 RFC5050bis would make more sense as a DTNRG
=C2=A0 =C2=A0 =C2=A0 effort, though it would be time for a changing of the<= br> =C2=A0 =C2=A0 =C2=A0 guard and chairs in DTNRG to infuse some new blood and=
=C2=A0 =C2=A0 =C2=A0 technical judgement - or we're in for another five= years
=C2=A0 =C2=A0 =C2=A0 of what-does-the-end-to-end-principle-really-mean and<= br> =C2=A0 =C2=A0 =C2=A0 what-about-clocks and rehashing the same old arguments= .
=C2=A0 =C2=A0 =C2=A0 Really, DTNRG needs to get its act together, both
=C2=A0 =C2=A0 =C2=A0 organizationally and technically.

=C2=A0 =C2=A0c. There's already CCSDS, which has adopted the DTNRG outp= ut,
=C2=A0 =C2=A0 =C2=A0 after pushing for the formation of an Interplanetary =C2=A0 =C2=A0 =C2=A0 Internet RG in the first place.

So either CCSDS or DTNRG can do RFC5050 revision work. If
it's to be an RFC, experimental or informational, a revitalised
rechartered DTNRG can do it.
It doesn't need to be an IETF workgroup. It certainly
shouldn't go standards track.


3. The philosophically shaky basis for the bundle protocol:

=C2=A0 =C2=A0a. Delay-tolerant networking is not disruption-tolerant
=C2=A0 =C2=A0 =C2=A0 networking. Space delays of light-minutes with schedul= ed
=C2=A0 =C2=A0 =C2=A0 contacts are not the same as intermittent ad-hoc
=C2=A0 =C2=A0 =C2=A0 manet-style communications. Different requirements, =C2=A0 =C2=A0 =C2=A0 different buffering and storage, different conditions,=
=C2=A0 =C2=A0 =C2=A0 different handling of fragmentation, etc.

=C2=A0 =C2=A0b. The bundle protocol is not DTN. DTN is the scenario,
=C2=A0 =C2=A0 =C2=A0 in which other approaches (the related CFDP, Haggle, =C2=A0 =C2=A0 =C2=A0 the MANET and vehicular DTNs efforts that DTN subsumed=
=C2=A0 =C2=A0 =C2=A0 and rebranded, etc.) exist.
=C2=A0 =C2=A0 =C2=A0 The bundle protocol is intended to be used in a DTN =C2=A0 =C2=A0 =C2=A0 scenario. Branding the bundle protocol as DTN has
=C2=A0 =C2=A0 =C2=A0 put back non-bundle DTN research a number of years. =C2=A0 =C2=A0 =C2=A0 Branding a group only working on the bundle protocol =C2=A0 =C2=A0 =C2=A0 as 'DTN' is misleading at best.

=C2=A0 =C2=A0c. Extending the bundle protocol from the original
=C2=A0 =C2=A0 =C2=A0 Interplanetary Internet problem (which had its own
=C2=A0 =C2=A0 =C2=A0 IRTF RG which led into a set bundle agenda for
=C2=A0 =C2=A0 =C2=A0 DTNRG) to cover everything else as well simply hasn= 9;t
=C2=A0 =C2=A0 =C2=A0 worked very well, because the scenarios and use cases<= br> =C2=A0 =C2=A0 =C2=A0 are different. We design for use cases. To be too
=C2=A0 =C2=A0 =C2=A0 generalised is to engineer for nothing.

=C2=A0 =C2=A0d. Ignoring the ramifications of the end-to-end principle,
=C2=A0 =C2=A0 =C2=A0 which are often more subtle than people seem to think<= br> =C2=A0 =C2=A0 =C2=A0 they are. The bundle protocol's custody transfer =C2=A0 =C2=A0 =C2=A0 procedure is a good example of this failing.

=C2=A0 =C2=A0e. The bundle protocol is intended for use in the most
=C2=A0 =C2=A0 =C2=A0 difficult noisy disrupted networking conditions we kno= w,
=C2=A0 =C2=A0 =C2=A0 and it can't even sanity check its own headers aga= inst
=C2=A0 =C2=A0 =C2=A0 errors. (But hey, it now has a security protocol that<= br> =C2=A0 =C2=A0 =C2=A0 _almost_ does that! But which is too complicated, and<= br> =C2=A0 =C2=A0 =C2=A0 would need to be redone.)
=C2=A0 =C2=A0 =C2=A0 It's intended for the harshest environments we kno= w,
=C2=A0 =C2=A0 =C2=A0 but needs reliable synchronized clocks running at
=C2=A0 =C2=A0 =C2=A0 steady temperatures!
=C2=A0 =C2=A0 =C2=A0 It's intended for embedded systems, but the design=
=C2=A0 =C2=A0 =C2=A0 is huge and complex! (CFDP has the same problem;
=C2=A0 =C2=A0 =C2=A0 there's a reason implementers went for a "CFD= P lite,"
=C2=A0 =C2=A0 =C2=A0 and Saratoga exists just because CFDP wasn't perfo= rming.
=C2=A0 =C2=A0 =C2=A0 Would RFC5050bis be "bundling lite"?)
=C2=A0 =C2=A0 =C2=A0 There are many 'that makes no sense' moments -= normally
=C2=A0 =C2=A0 =C2=A0 more immediately visible to outsiders not steeped in =C2=A0 =C2=A0 =C2=A0 the dogma, politics, and history of DTNRG and CCSDS.
=C2=A0 =C2=A0f. The assumption that a full security suite is desirable
=C2=A0 =C2=A0 =C2=A0 and necessary at all times. This has derailed DTNRG, =C2=A0 =C2=A0 =C2=A0 as emphasis was placed on security work above all
=C2=A0 =C2=A0 =C2=A0 else, rather than working to the scenario. To be fair<= br> =C2=A0 =C2=A0 =C2=A0 to the security-focused chairs, the charter that
=C2=A0 =C2=A0 =C2=A0 established DTNRG from the interplanetary internet
=C2=A0 =C2=A0 =C2=A0 research group called out security heavily, and they =C2=A0 =C2=A0 =C2=A0 ran with that mandate. But the focus has decreased
=C2=A0 =C2=A0 =C2=A0 work on non-security matters, which is to say,
=C2=A0 =C2=A0 =C2=A0 everything else.

RFC5050bis might address the latter three problems, but
the first three are intrinsically unsolvable; any solution
will be unsatisfactory. Perhaps not as unsatisfactory as
RFC5050, but unsatisfactory nonetheless.

The real philosophical problem here is the political dogma
that, whatever the problem, the bundle protocol is The
One True Solution.


4. The draft BOF charter is bundle-centric. Which is to say,
=C2=A0 =C2=A0that it's not awfully relevant to internet standards.
=C2=A0 =C2=A0Disclaimer of interest: we've worked on Saratoga and
=C2=A0 =C2=A0HTTP-DTN, which have current internet-drafts, and are
=C2=A0 =C2=A0squarely in the DTN problem space.
=C2=A0 =C2=A0Whenever someone talks about multiple convergence
=C2=A0 =C2=A0layers for the bundle protocol - there's more than for BEE= P,
=C2=A0 =C2=A0which just has TCP, but there aren't many - Saratoga may =C2=A0 =C2=A0be mentioned. But we've found that carrying bundles doesn&= #39;t
=C2=A0 =C2=A0benefit Saratoga - tested it in space, didn't see the
=C2=A0 =C2=A0advantages. Saratoga does leverage a few Internet things -
=C2=A0 =C2=A0UDP, UDP-Lite, multicast. It does a few scaling things that =C2=A0 =C2=A0nothing else I've seen does (described in our 2011 TSVAREA=
=C2=A0 =C2=A0presentation to IETF 88 in November.) And it's based on =C2=A0 =C2=A0a decade of operational use in the problem domain.
=C2=A0 =C2=A0HTTP-DTN leverages the HTTP suite and MIME, and comes up
=C2=A0 =C2=A0whenever wouldn't-it-be-nice-to-try-HTTP-for-DTN discussio= n
=C2=A0 =C2=A0takes place.
=C2=A0 =C2=A0(I suspect that all of Stephen Farrell's N4C work could =C2=A0 =C2=A0have been done over hop-by-hop HTTP a la HTTP-DTN, and
=C2=A0 =C2=A0would have worked just as well if not better. After all,
=C2=A0 =C2=A0it used TCP.)
=C2=A0 =C2=A0These and other efforts exist in a gap between DTNRG, which =C2=A0 =C2=A0is aware of the problem space, but thinks the bundle
=C2=A0 =C2=A0protocol is the solution despite mounting evidence to the
=C2=A0 =C2=A0contrary, and TSVWG, where the few actual transport
=C2=A0 =C2=A0experts live, without clout, or funding, or spare time.
=C2=A0 =C2=A0Those efforts are interesting enough to have implementations =C2=A0 =C2=A0kicking around too.
=C2=A0 =C2=A0And yet, the focus of this putative workgroup and BOF is
=C2=A0 =C2=A0solely on bundling, and not on evaluating these or other
=C2=A0 =C2=A0things that might exist in the problem space. There
=C2=A0 =C2=A0must be other things out there that would be of interest
=C2=A0 =C2=A0to such a DTN workgroup. What is proposed is not a DTN
=C2=A0 =C2=A0workgroup. The charter is basically a bundle workgroup.
=C2=A0 =C2=A0Can an interest in bundling and solely bundling (outside
=C2=A0 =C2=A0CCSDS, which is driving the push to use the bundle protocol) =C2=A0 =C2=A0be justified for an IETF workgroup? I really don't think s= o.

5. The bundle protocol work was, I gather, well-funded
=C2=A0 =C2=A0by a number of parties.
=C2=A0 =C2=A0I can't see a follow-on effort being anywhere near
=C2=A0 =C2=A0as well funded.

=C2=A0 =C2=A0a. I have no idea how much money NASA and CCSDS have put
=C2=A0 =C2=A0 =C2=A0 into this - first CFDP, then bundling, which now has =C2=A0 =C2=A0 =C2=A0 to provide a CFDP-like API to the users who were told<= br> =C2=A0 =C2=A0 =C2=A0 that CFDP was the future, and Licklider (LTP).
=C2=A0 =C2=A0 =C2=A0 Dragging CCSDS into the modern age of networking
=C2=A0 =C2=A0 =C2=A0 seems unlikely to ever happen, thanks to CCSDS having<= br> =C2=A0 =C2=A0 =C2=A0 little in the way of sane layering or separation of =C2=A0 =C2=A0 =C2=A0 functionality.
=C2=A0 =C2=A0 =C2=A0 I do have the luxury of not needing to work on CCSDS.<= br> =C2=A0 =C2=A0 =C2=A0 But if you want to work on CCSDS protocols, CCSDS is =C2=A0 =C2=A0 =C2=A0 the place to go. The IETF is not that place.

=C2=A0 =C2=A0b. DARPA poured money into DTN work - at least twenty
=C2=A0 =C2=A0 =C2=A0 million dollars, from the press releases I've seen= .
=C2=A0 =C2=A0 =C2=A0 I have no idea what DARPA got out of it in the
=C2=A0 =C2=A0 =C2=A0 years they were involved; haven't seen the reports= .

My point is, all that money and effort and manpower and
over a decade of work and prior experience with CFDP and two
IRTF RGs, we have... RFC5050.
There is nowhere near as much money or effort or manpower
for doing a replacement.
Ergo, it might be suggested that the replacement is unlikely
to be as good as RFC5050, or as good as CFDP; at best,
the usual suspects will have less time and fewer resources
to repeat their original mistakes.

And transport expertise from TSVWG would be needed.
TSVWG is unfashionable, low-visibility, and has even
previously had trouble finding ADs with relevant expertise.
And TSVWG has a full plate with work on its existing
protocols; there is not a lot of expertise, and what there
is is spread thin.
So an RFC505bis effort is unlikely to get the expert
technical input that it sorely needs, even if an IETF
workgroup is set up. (CCSDS doesn't have that transport
focus.)

If, on the other hand, you believe good protocol design
can be done more cheaply and leverage actual Internet
standards to get Internet functionality working in
difficult networks where the full TCP/IP suite has
trouble, your options include Saratoga and HTTP-DTN!
http://sarat= oga.sourceforge.net/
h= ttp://sat-net.com/L.Wood/dtn/http-dtn.html
They'll truly extend the Internet to difficult
environments. The bundle protocol won't.

So, to conclude, there is no justification for going
standards track. There is little justification for an
IETF workgroup. There is more logic in rechartering and
repurposing the IRTF DTNRG, but the work may as well
be left to CCSDS entirely.

RFC5050bis: half-assed, half-baked, reheated.
But hey, ask me what I _really_ think.

Lloyd Wood
http://sat-net= .com/L.Wood/dtn/

_______________________________________________
dtn mailing list
dtn@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dtn



--
<= i>The problem with the world is that the intelligent people are full of = doubts,
while the stupid ones are full of confidence.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Charles Bukowski
--089e013a13c4204c7f04fb193f21-- From nobody Thu Jun 5 09:30:15 2014 Return-Path: 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 9891D1A0337 for ; Thu, 5 Jun 2014 09:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 TJD2gkbYSMQd for ; Thu, 5 Jun 2014 09:30:01 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D11C81A0304 for ; Thu, 5 Jun 2014 09:30:00 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp02.jpl.nasa.gov [128.149.137.149]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s55GTJhB001764 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO) for ; Thu, 5 Jun 2014 09:29:25 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.156]) by ap-ehub-sp02.RES.AD.JPL ([fe80::dd85:7b07:1e36:7e3c%15]) with mapi id 14.03.0174.001; Thu, 5 Jun 2014 09:29:51 -0700 From: "Burleigh, Scott C (312G)" To: "dtn@ietf.org" Thread-Topic: [dtn] Proposed Working Group Charter Suggestions Thread-Index: AQFSocO/D9uhW69j0yAuOdgV0znNWQHFMXAmASCcbEQBbA2hJAHfUcS+AdrD57cB7vfjCQJo1+2NAbk5oBoBhgwXi5vfSS4wgACCL4D//4saYA== Date: Thu, 5 Jun 2014 16:29:50 +0000 Message-ID: References: <2134F8430051B64F815C691A62D983181B2BD2DE@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2BD423@XCH-BLV-504.nw.nos.boeing.com> <538E35F6.2010702@cs.tcd.ie> <538F3D53.5060305@per.reau.lt> <538FF2F8.5070605@mti-systems.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.26] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/tunMx42MQUkpV2bbbBFicxJpTLo Subject: Re: [dtn] Proposed Working Group Charter Suggestions X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 16:30:05 -0000 Will, sure, hop counts are a great way to break routing loops, but (a) it h= as been suggested that routing loops are not always a bad thing in DTN (I h= aven't yet heard the fully-worked out argument for this, so I can't engage = on this point), and (b) I think routing loops are the least of your problem= s in a DTN -- there are plenty of simpler ways to screw up performance in t= hese weird environments. The original argument for the bundle lifetime is lost in the mists of time = (though I think it shows up in some of the emails I've got archived from fi= fteen years ago); I think it eventually just became taken for granted. It'= s still sort of implicit in the design, though. Really, why would you both= er to delete a bundle whose lifetime had expired? Certainly you don't want= to waste any more bandwidth on forwarding it, but you could omit it from f= orwarding without deleting it. The only reason to go to that trouble is th= at you want the storage back. Scott -----Original Message----- From: Ivancic, William D. (GRC-RHN0) [mailto:william.d.ivancic@nasa.gov]=20 Sent: Thursday, June 05, 2014 9:12 AM To: Burleigh, Scott C (312G); dtn@ietf.org Subject: Re: [dtn] Proposed Working Group Charter Suggestions Hmmm. It appears that maybe there should be a document on what lifetime is= used for. I never thought of it as congestion control. I always thought = of it a how long the information in the bundle is useful for - analogous to= expiration dates on the food in your refrigerator. For example: Help, I'M drownding! =3D 1 minute (assuming I have decent lung capacity) H= appy Birthday (and your birthday is tomorrow) =3D 24 hours Happy New Year 2= 015 =3D whatever the math is that works out to that number of days. I think BBN sort of did this the best they could with two code points. Which is why I always thought one would want to consider how much longer a = bundle is valid for when making forwarding decisions. I always consider hop count a mechanism to kill traffic stuck in a routing = loop and the reason I proposed hop count in the base header of bundling or = whatever Store, Carry and Forward mechanism one implements. Will ****************************** On 6/5/14 11:53 AM, "Burleigh, Scott C (312G)" wrote: >Wes, thanks! You have brought up an issue that I think has never=20 >received enough research attention. > >The purpose of the lifetime field in bundles is, essentially,=20 >congestion >control: a way is needed to flush data out of the network that most=20 >likely will never get delivered, so as to resources needed for other=20 >traffic. In the Internet we can do this with a hop count, because the=20 >packets are always in motion and signal propagation delays are small;=20 >any hop count limit will map to a packet lifetime limit with a small,=20 >fairly predictable upper bound. In a DTN-based network this is no=20 >good: a bundle could make one hop to a router node that (unknown to it)=20 >will never have a path forward to the destination. Without an explicit=20 >lifetime limit the bundle could occupy storage on that node forever,=20 >waiting for a forwarding opportunity that will never come. > >But you're right, there aren't a lot of guidelines for selecting that=20 >lifetime limit. Somebody should come up with some...... > From nobody Thu Jun 5 10:05:45 2014 Return-Path: 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 BF3FD1A023E for ; Thu, 5 Jun 2014 10:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Q9bn-axZeJ-a for ; Thu, 5 Jun 2014 10:05:41 -0700 (PDT) Received: from a.painless.aa.net.uk (a.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D77041A027D for ; Thu, 5 Jun 2014 10:05:38 -0700 (PDT) Received: from mightyatom.folly.org.uk ([81.187.254.250]) by a.painless.aa.net.uk with esmtp (Exim 4.77) (envelope-from ) id 1Wsb6T-00034u-Ro; Thu, 05 Jun 2014 18:05:29 +0100 From: Elwyn Davies To: "Burleigh, Scott C (312G)" In-Reply-To: References: <2134F8430051B64F815C691A62D983181B2BD2DE@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2BD423@XCH-BLV-504.nw.nos.boeing.com> <538E35F6.2010702@cs.tcd.ie> <538F3D53.5060305@per.reau.lt> <538FF2F8.5070605@mti-systems.com> Content-Type: text/plain; charset="windows-1251" Organization: Folly Consulting Date: Thu, 05 Jun 2014 18:05:24 +0100 Message-Id: <1401987924.29419.3341.camel@mightyatom> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/4ZmqYduV-flCy5IKB76rMaFFenE Cc: "dtn@ietf.org" Subject: Re: [dtn] Proposed Working Group Charter Suggestions X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 17:05:43 -0000 Hi. I don't think that it's true that there hasn't been much research into this. Just about every opportunistic routing scheme proposal (and there are lots) assumes that the ultimate backstop for storage occupancy is bundle expiry and quite a few of them link some of their parameters to bundle lifetime. This is indeed all about avoiding congestion (or perhaps more accurately storage overload). The difficulty is, as Scott says, that deciding what is a good value for lifetime is mobility model dependent and is not trivial to do. It is (or should be) tied to the expected delay distribution in a network and (in an opportunistic network) what proportion of bundles you are prepared to see undelivered (i.e., where you put the limit on the delay distribution). There is some useful discussion and mathematical analysis in Spyropoulos, T., Psounis, K., and Raghavendra, C. S. Spray and wait: an efficient routing scheme for intermittently connected mobile networks. In Proceedings of the 2005 SIGCOMM Workshops (2005), p. 8. for a simple case, but the general case is non-trivial. It is possible to estimate what is a good value from encounter histories but we haven't done enough practical trials (as opposed to simulations) to see how useful these values might be. Karvo, J., and Ott, J. Time scales and delay-tolerant routing protocols. Proceedings of the third ACM workshop on Challenged networks CHANTS 08 (2008), 33=9640. discusses how timescales affect routing protocol parameters - this is another aspect of the same problem but doesn't explicitly consider bundle lifetimes. In the space case with contact graph routing I would have thought that the contact graph tells you what the expected delivery deadline will be which should enable you to set a lifetime using some safety factor on top of the deadline. But I'm not an expert on CGR. Regards, Elwyn On Thu, 2014-06-05 at 15:53 +0000, Burleigh, Scott C (312G) wrote: > Wes, thanks! You have brought up an issue that I think has never receive= d enough research attention. >=20 > The purpose of the lifetime field in bundles is, essentially, congestion = control: a way is needed to flush data out of the network that most likely = will never get delivered, so as to resources needed for other traffic. In = the Internet we can do this with a hop count, because the packets are alway= s in motion and signal propagation delays are small; any hop count limit wi= ll map to a packet lifetime limit with a small, fairly predictable upper bo= und. In a DTN-based network this is no good: a bundle could make one hop t= o a router node that (unknown to it) will never have a path forward to the = destination. Without an explicit lifetime limit the bundle could occupy st= orage on that node forever, waiting for a forwarding opportunity that will = never come. >=20 > But you're right, there aren't a lot of guidelines for selecting that lif= etime limit. Somebody should come up with some. >=20 > Considering this just in terms of ION (the DTN software that I've got mos= t experience with), I think one approach might be to pick some lifetime val= ue at random, do a simulation of CGR-based traffic, and see what percentage= of bundles are abandoned at the source because CGR discovers that they can= 't possibly be delivered prior to bundle expiration time. Then increase or= decrease that standard lifetime and repeat until that percentage is low en= ough to be tolerable. >=20 > Another approach might be to look at some sample contact plans, compute t= he expected delivery times for bundles sent from every node to every other = node at some given moment, and look for a relationship between the maximum = expected delivery times and some characteristics of the corresponding conta= ct plans. >=20 > Again, for now this could only be done for flight mission scenarios becau= se the contact plans used by CGR include only scheduled, relatively certain= contacts. Over the next few months we hope to be adding opportunistic and= probabilistic contacts to those contact plans, which should open CGR up fo= r use in terrestrial DTN scenarios. >=20 > Scott >=20 > -----Original Message----- > From: Wesley Eddy [mailto:wes@mti-systems.com]=20 > Sent: Wednesday, June 04, 2014 9:33 PM > To: Burleigh, Scott C (312G); Ivancic, William D. (GRC-RHN0); dtn@ietf.or= g > Subject: Re: [dtn] Proposed Working Group Charter Suggestions >=20 > On 6/4/2014 7:28 PM, Burleigh, Scott C (312G) wrote: > > And you are quite wrong about nobody using bundle lifetimes to make=20 > > bundle forwarding decisions: bundle expiration time is a critical=20 > > parameter in contact graph routing. >=20 > I think the point is not that routing algorithms can't use it appropriate= ly, but rather than sending applications so far haven't generally been able= to set it with any meaningful granularity so that it would then cause the = routing system to be able to do intelligent things. >=20 > I.e. if all bundles coming through have the same very long lifetime, it w= ill not impact the routing decisions, even if there happens to be logic tha= t incorporates the lifetime. >=20 > This doesn't exclude the possibility that there's a system somewhere in w= hich the applications can really make use of a whole spectrum of lifetime v= alues, but it doesn't look like the general case so far. >=20 > -- > Wes Eddy > MTI Systems >=20 > _______________________________________________ > dtn mailing list > dtn@ietf.org > https://www.ietf.org/mailman/listinfo/dtn From nobody Thu Jun 5 10:15:17 2014 Return-Path: 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 6C1961A0090 for ; Thu, 5 Jun 2014 10:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 6M5Qz8xBO4yQ for ; Thu, 5 Jun 2014 10:15:13 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB0D91A01A0 for ; Thu, 5 Jun 2014 10:15:12 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp01.jpl.nasa.gov [128.149.137.148]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s55HEZcI032593 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Thu, 5 Jun 2014 10:14:35 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.156]) by ap-ehub-sp01.RES.AD.JPL ([169.254.3.182]) with mapi id 14.03.0174.001; Thu, 5 Jun 2014 10:15:03 -0700 From: "Burleigh, Scott C (312G)" To: Elwyn Davies Thread-Topic: [dtn] Proposed Working Group Charter Suggestions Thread-Index: AQFSocO/D9uhW69j0yAuOdgV0znNWQHFMXAmASCcbEQBbA2hJAHfUcS+AdrD57cB7vfjCQJo1+2NAbk5oBoBhgwXi5vfSS4wgACRHAD//4scUA== Date: Thu, 5 Jun 2014 17:15:03 +0000 Message-ID: References: <2134F8430051B64F815C691A62D983181B2BD2DE@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2BD423@XCH-BLV-504.nw.nos.boeing.com> <538E35F6.2010702@cs.tcd.ie> <538F3D53.5060305@per.reau.lt> <538FF2F8.5070605@mti-systems.com> <1401987924.29419.3341.camel@mightyatom> In-Reply-To: <1401987924.29419.3341.camel@mightyatom> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.26] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/Eh6y5SCwnCIArKZIuJxMGRqlnd4 Cc: "dtn@ietf.org" Subject: Re: [dtn] Proposed Working Group Charter Suggestions X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 17:15:15 -0000 Elwyn, there has indeed been some work on computing expected delivery time = from a contact plan (http://www.spice-center.org/files/publications/TR-Deli= very_Time_Estimation_for_Space_Bundles.pdf), so what you propose might be a= very good solution. The computation is somewhat time-consuming, though, s= o having a handy constant that results in statistically good performance co= uld still be worthwhile. Scott -----Original Message----- From: Elwyn Davies [mailto:elwynd@folly.org.uk]=20 Sent: Thursday, June 05, 2014 10:05 AM To: Burleigh, Scott C (312G) Cc: dtn@ietf.org Subject: Re: [dtn] Proposed Working Group Charter Suggestions Hi. I don't think that it's true that there hasn't been much research into this= . Just about every opportunistic routing scheme proposal (and there are lo= ts) assumes that the ultimate backstop for storage occupancy is bundle expi= ry and quite a few of them link some of their parameters to bundle lifetime= . This is indeed all about avoiding congestion (or perhaps more accurately= storage overload). The difficulty is, as Scott says, that deciding what is a good value for li= fetime is mobility model dependent and is not trivial to do. It is (or sho= uld be) tied to the expected delay distribution in a network and (in an opp= ortunistic network) what proportion of bundles you are prepared to see unde= livered (i.e., where you put the limit on the delay distribution). There i= s some useful discussion and mathematical analysis in Spyropoulos, T., Psou= nis, K., and Raghavendra, C. S. Spray and wait: an efficient routing scheme= for intermittently connected mobile networks. In Proceedings of the 2005 S= IGCOMM Workshops (2005), p. 8. for a simple case, but the general case is non-trivial. It is possible to = estimate what is a good value from encounter histories but we haven't done = enough practical trials (as opposed to simulations) to see how useful these= values might be. Karvo, J., and Ott, J. Time scales and delay-tolerant routing protocols. Proceedings of the third ACM workshop on = Challenged networks CHANTS 08 (2008), 33-40. discusses how timescales affect routing protocol parameters - this is anoth= er aspect of the same problem but doesn't explicitly consider bundle lifeti= mes. In the space case with contact graph routing I would have thought that the = contact graph tells you what the expected delivery deadline will be which s= hould enable you to set a lifetime using some safety factor on top of the d= eadline. But I'm not an expert on CGR. Regards, Elwyn On Thu, 2014-06-05 at 15:53 +0000, Burleigh, Scott C (312G) wrote: > Wes, thanks! You have brought up an issue that I think has never receive= d enough research attention. >=20 > The purpose of the lifetime field in bundles is, essentially, congestion = control: a way is needed to flush data out of the network that most likely = will never get delivered, so as to resources needed for other traffic. In = the Internet we can do this with a hop count, because the packets are alway= s in motion and signal propagation delays are small; any hop count limit wi= ll map to a packet lifetime limit with a small, fairly predictable upper bo= und. In a DTN-based network this is no good: a bundle could make one hop t= o a router node that (unknown to it) will never have a path forward to the = destination. Without an explicit lifetime limit the bundle could occupy st= orage on that node forever, waiting for a forwarding opportunity that will = never come. >=20 > But you're right, there aren't a lot of guidelines for selecting that lif= etime limit. Somebody should come up with some. >=20 > Considering this just in terms of ION (the DTN software that I've got mos= t experience with), I think one approach might be to pick some lifetime val= ue at random, do a simulation of CGR-based traffic, and see what percentage= of bundles are abandoned at the source because CGR discovers that they can= 't possibly be delivered prior to bundle expiration time. Then increase or= decrease that standard lifetime and repeat until that percentage is low en= ough to be tolerable. >=20 > Another approach might be to look at some sample contact plans, compute t= he expected delivery times for bundles sent from every node to every other = node at some given moment, and look for a relationship between the maximum = expected delivery times and some characteristics of the corresponding conta= ct plans. >=20 > Again, for now this could only be done for flight mission scenarios becau= se the contact plans used by CGR include only scheduled, relatively certain= contacts. Over the next few months we hope to be adding opportunistic and= probabilistic contacts to those contact plans, which should open CGR up fo= r use in terrestrial DTN scenarios. >=20 > Scott >=20 > -----Original Message----- > From: Wesley Eddy [mailto:wes@mti-systems.com] > Sent: Wednesday, June 04, 2014 9:33 PM > To: Burleigh, Scott C (312G); Ivancic, William D. (GRC-RHN0);=20 > dtn@ietf.org > Subject: Re: [dtn] Proposed Working Group Charter Suggestions >=20 > On 6/4/2014 7:28 PM, Burleigh, Scott C (312G) wrote: > > And you are quite wrong about nobody using bundle lifetimes to make=20 > > bundle forwarding decisions: bundle expiration time is a critical=20 > > parameter in contact graph routing. >=20 > I think the point is not that routing algorithms can't use it appropriate= ly, but rather than sending applications so far haven't generally been able= to set it with any meaningful granularity so that it would then cause the = routing system to be able to do intelligent things. >=20 > I.e. if all bundles coming through have the same very long lifetime, it w= ill not impact the routing decisions, even if there happens to be logic tha= t incorporates the lifetime. >=20 > This doesn't exclude the possibility that there's a system somewhere in w= hich the applications can really make use of a whole spectrum of lifetime v= alues, but it doesn't look like the general case so far. >=20 > -- > Wes Eddy > MTI Systems >=20 > _______________________________________________ > dtn mailing list > dtn@ietf.org > https://www.ietf.org/mailman/listinfo/dtn From nobody Thu Jun 5 10:31:28 2014 Return-Path: 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 3C3681A021A for ; Thu, 5 Jun 2014 10:31:26 -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 3uft-sjl7VGB for ; Thu, 5 Jun 2014 10:31:24 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FC901A00EA for ; Thu, 5 Jun 2014 10:31:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s55HVHi2030458; Thu, 5 Jun 2014 10:31:17 -0700 Received: from XCH-PHX-410.sw.nos.boeing.com (xch-phx-410.sw.nos.boeing.com [10.57.37.41]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s55HV9oi030360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 5 Jun 2014 10:31:09 -0700 Received: from XCH-BLV-305.nw.nos.boeing.com (130.247.25.217) by XCH-PHX-410.sw.nos.boeing.com (10.57.37.41) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 5 Jun 2014 10:31:09 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.105]) by XCH-BLV-305.nw.nos.boeing.com ([169.254.5.17]) with mapi id 14.03.0181.006; Thu, 5 Jun 2014 10:31:08 -0700 From: "Templin, Fred L" To: "Eggert, Lars" Thread-Topic: [dtn] DTN BoF Proposal for IETF90 Thread-Index: Ac+AQa9Fez/CplZaSwyaLFpzb8tj0wAiVZ0AAAXfQWA= Date: Thu, 5 Jun 2014 17:31:07 +0000 Message-ID: <2134F8430051B64F815C691A62D983181B2BF3F7@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.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/0tWhXFgn_MfHyH8Ebi3RHkx7uhI Cc: "dtn@ietf.org" Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 17:31:26 -0000 Hi Lars, Thanks for your comments on the proposed charter, and see below for follow-up: > -----Original Message----- > From: Eggert, Lars [mailto:lars@netapp.com] > Sent: Thursday, June 05, 2014 12:33 AM > To: Templin, Fred L > Cc: dtn@ietf.org > Subject: Re: [dtn] DTN BoF Proposal for IETF90 >=20 > Hi, >=20 > On 2014-6-5, at 0:09, Templin, Fred L wrote: > > Draft BoF Agenda (2.5hrs): > > ************************** > > 1) Problem statement (IETF wg motivation) - 30min > > 2) RFC5050(bis) - 30min > > 3) Streamlined Bundle Security Protocol (SBSP) - 30min > > 4) Bundle-in-Bundle Encapsulation - 15min > > 5) Security Key Management - 15min > > 6) Registry for Service Identifiers - 15min > > 7) Network Management - 15min >=20 > that adds up to 2.5h - when were you planning to have charter discussions= , etc.? Suggest to focus on > 1, and then summarize the suggested work items 2-7 in much less time, lea= ving an hour at least for > discussion. OK - that seems like a sensible approach. =20 > > Description of Working Group: > > > > The Delay/Disruption Tolerant Network Working Group (DTNWG) specif= ies > > mechanisms for data communications in the presence of long delays > > and/or intermittent connectivity. The work is motivated by well kn= own > > limitations of standard Internet protocols that expect end-to-end > > connectivity between communicating endpoints, sub-second transmiss= ion > > delays and robust packet delivery ratios. In environments where th= ese > > favorable conditions do not apply, existing mechanisms such as rel= iable > > transport protocols and routing protocols can fail to converge res= ulting > > in communication failures. Furthermore, classical end-to-end secur= ity > > associations cannot be coordinated when communicating endpoints ca= nnot > > conduct multi-message keying exchanges in a timely fashion. These > > limitations suggest the need for a new approach. >=20 > OK so far. OK. > > Delay-Tolerant Networking (DTN) protocols have been the subject of > > extensive research and development in the Delay-Tolerant Networkin= g > > Research Group of the Internet Research Task Force since 2002. In > > particular, the DTN Bundle Protocol (RFC 5050) and Licklider > > Transmission Protocol (RFC 5326) have been shown to address the > > issues identified above. In 2008, BP/LTP was deployed on the EPOX= I > > spacecraft in deep space and was used to conduct reliable, automat= ed > > communication for four weeks over a network of 10 nodes in which t= he > > bottleneck router in the network (the spacecraft) was up to 100 li= ght > > seconds from all other nodes and connectivity with the router was > > subject to periods of disconnection lasting several days. >=20 > At lest the second half of the paragraph above can be eliminated from the= charter text. You could even > cut the whole thing. OK. =20 > > The success of the BP/LTP protocol stack -- the core protocols of = the > > "DTN Architecture" originally described in RFC 4838 -- in this > > demonstration may be attributed to the following fundamental desig= n > > principles: > > > > - There is never any expectation of contemporaneous end-to-end > > connectivity between any two network nodes. Where such connectiv= ity > > is sustained, the protocols leverage it to optimize performance, > > but the possibility of transient but sustained disconnection at > > any time, anywhere in the network, is always recognized. > > > > - Because end-to-end connectivity can never be assumed, each node > > on the path between source and destination must be prepared to > > handle incoming "bundles" of data that cannot immediately be > > forwarded. Such bundles must either be stored for future trans- > > mission or discarded; in the latter case, the network must > > be informed of this data loss so that an alternative path may > > be selected, to avoid impairing the usability of the network. > > > > - Again because end-to-end connectivity can never be assumed, > > end-to-end conversational data exchange can never be assumed to > > complete in a timely manner; protocol features that rely on > > timely conversational data exchange must be excluded from the > > architecture. This principle makes the DTN architecture > > suitable not only for network environments characterized by > > lengthy disconnection but also for those that are characterized > > by long signal propagation delays (such as underwater communication > > by acoustic signals or, worse, interplanetary communication) even > > when connectivity is continuous. > > > > The DTNWG believes that protocols adhering to these principles off= er > > opportunities for enhancing the functionality of the Internet - in > > particular, for facilitating the extension of the Internet into > > environments such as the ocean floor and deep space in which the c= ore > > Internet protocols operate sub-optimally for the reasons discussed > > earlier. We believe that the extensive research, demonstration, a= nd > > pilot operations performed to date using the DTNRG protocols, both > > before and after the EPOXI experiment, provides a firm basis for > > publishing Internet standards derived from that work. >=20 > You could significantly shorten the body of text above, incl. the bullet = list, by simply pointing at > some relevant DTNRG RFCs and say that you want to build on what was done = before and not go off to > reinvent everything. OK. > > Work items related to Delay/Disruption Tolerant Networking include= : >=20 > Now we're getting to the point where the charter text actually starts to = matter: OK. > > o A mechanism for the exchange of protocol data units, termed > > "bundles", that are designed to obviate conversational communications > > by containing values for all potentially relevant configuration > > parameters. These protocol data units are typically larger than > > network-layer packets. We expect to derive this bundle exchange > > mechanism from the DTN Bundle Protocol (BP) documented in RFC 5050. >=20 > Why "expect to"? It would be good to have agreement whether or not 5050 i= s the baseline here. We can restate it as: "We will derive...", considering RFC5050 as the baseline. > > Expected changes from RFC 5050 include (but are not necessarily > > limited to): > > > > - a compressed bundle header encoding (derived from RFC6260) > > - an immutable primary block structure > > - simplified EID representations (no dictionary) > > - add block ID to extension blocks (e.g. security blocks) > > - move custodian to extension block > > - add simple header and payload integrity checks > > - add simple contact graph routing specification > > - add simple neighbor discovery specification >=20 > List is OK for discussion, but doesn't need to be in the charter. OK. Would it be OK if such a list appears in a draft, and the charter simply points to the draft? > > o A security protocol for ensuring that the network in which bundl= es > > are exchanged is secured against unauthorized access and denial of > > service attacks, and to ensure data integrity and confidentiality > > in that network where necessary. We expect to derive this security > > protocol from a "streamlined" adaptation of the DTN Bundle Security > > Protocol documented in RFC 6257. >=20 > Again, why "expect to"? "We will derive..." ? > > o An encapsulation protocol for "tunneling" BP traffic within bund= les > > that are secured and/or routed in different way from the encapsulated > > bundles. > > > > o A delay-tolerant security key management scheme for ensuring tha= t > > public keys are certified by a globally trusted authority to protect > > the integrity of the infrastructure. > > > > o A simple datagram convergence layer protocol for adaptation of t= he > > bundle protocol to underlying internetworks. We expect to derive > > this convergence layer protocol from the Datagram Convergence > > protocol documented in RFC7122. > > > > o A delay-tolerant network management protocol for management of t= he > > infrastructure in the presence of long delays and/or intermitten= t > > connectivity. >=20 > For all of those bullets above, are there starting points, or will these = be completely new protocol > developments? (if the latter, you are setting yourself up for a LOT of wo= rk.) The only item for which there is currently no starting point is delay-tolerant security key management. > > o A registry for DTN Service Identifiers > > > > The working group will consider extending the current milestones bas= ed on > > new information and knowledge gained while working on the initial ch= arter, > > as well as to accommodate new work items beyond the scope of the ini= tial > > phase. For example, we expect that transport protocols uniquely sui= ted > > to the various communication environments that may need to be traver= sed > > by a single DTN end-to-end path (operating under BP, at what is term= ed > > the DTN "convergence layer") will need to be standardized in a secon= d > > phase of the working group's charter; LTP and the Saratoga protocol = are > > among the candidates for work in this phase. These adjustments will= be > > accommodated in a working group recharter, assuming the initial > > chartered activities meet their delivery milestones. Possible new wo= rk > > items must then still fit into the (rechartered) DTNWG charter scope= . >=20 > Paragraph can be cut. Charters can change, everyone knows that. OK, but we thought it would be helpful to name some recharter candidates to retain linkage to research activities, i.e., to show that we intend to allow a path forward for new activities. Can the current paragraph be compressed to retain the linkage? =20 > > Goals and Milestones: >=20 > Based on the current speed of the CTNRG, all these milestone deltas from = start are hugely optimistic. > I'd suggest to multiply by a factor of 2-3x. >=20 > > start+3mos - Submit 'Bundle Protocol Specification (RFC5050bis)' as a > > working group document. To be Proposed Standard. > > Start+3mos - Submit 'Streamlined Bundle Security Protocol (SBSP)' as a > > working group document. To be Proposed Standard. > > start+6mos - Submit 'Bundle In Bundle Encapsulation (BIBE)' as a worki= ng > > group document. To be Proposed Standard. > > start+9mos - Submit 'Delay Tolerant Networking Security Key Management= ' as > > a working group document. To be Proposed Standard. > > start+9mos - WG determination for merging RFC5050bis, SBSP, BIBE and/o= r > > Key Mgmt into a combined draft or keep as separate drafts= . > > start+12mos - Submit RFC5050bis, SBSP, BIBE and Key Mgmt to the IESG e= ither > > as a combined draft or as separate drafts. > > start+12mos - Submit Network Management, Registry and Simple Convergen= ce > > Layer as working group documents. > > start+15mos - Survey appropriate forums (e.g., DTNRG) for emerging > > technologies (e.g., convergence layer protocols, dynamic > > routing protocols, naming and addressing services, etc.) > > ready for transition into IETF DTN Working Group. Publis= h > > draft on survey results as independent submission relate= d > > to the WG. > > start+18mos - Submit Network Management, Registry and Simple Convergen= ce > > Layer to IESG > > start+18mos - Recharter to accommodate new work items or close Working= Group Thanks for your comments, Lars. Let me know if you have further follow-up, and I will roll the changes into a new revision soon. Fred fred.l.templin@boeing.com > Lars From nobody Thu Jun 5 10:34:07 2014 Return-Path: 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 C71EB1A00EA for ; Thu, 5 Jun 2014 10:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Q3KlKoBg1tyQ for ; Thu, 5 Jun 2014 10:34:04 -0700 (PDT) Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [IPv6:2001:4d0:8302:1100::103]) by ietfa.amsl.com (Postfix) with ESMTP id 447E01A0123 for ; Thu, 5 Jun 2014 10:34:04 -0700 (PDT) Received: from ndjsppt104.ndc.nasa.gov (ndjsppt104.ndc.nasa.gov [198.117.1.198]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id B9E582D80C1 for ; Thu, 5 Jun 2014 12:33:57 -0500 (CDT) Received: from NDJSCHT116.ndc.nasa.gov (ndjscht116-pub.ndc.nasa.gov [198.117.1.216]) by ndjsppt104.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id s55HXvjs010439 for ; Thu, 5 Jun 2014 12:33:57 -0500 Received: from NDJSMBX203.ndc.nasa.gov ([169.254.2.8]) by NDJSCHT116.ndc.nasa.gov ([198.117.1.216]) with mapi id 14.03.0174.001; Thu, 5 Jun 2014 12:33:57 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: "Burleigh, Scott C (JPL-312G)[Jet Propulsion Laboratory]" , "dtn@ietf.org" Thread-Topic: [dtn] Proposed Working Group Charter Suggestions Thread-Index: AQHPf14xoT809BzuHUKQYykab/OBU5tgMQkAgAANJYCAASzPgP//yzgAgACNmID//8r8AIAAX8qAgABU8wCAAL44gP//wgcAAAkB1AD//87ZgA== Date: Thu, 5 Jun 2014 17:33:56 +0000 Message-ID: References: <2134F8430051B64F815C691A62D983181B2BD2DE@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2BD423@XCH-BLV-504.nw.nos.boeing.com> <538E35F6.2010702@cs.tcd.ie> <538F3D53.5060305@per.reau.lt> <538FF2F8.5070605@mti-systems.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [184.56.61.175] Content-Type: text/plain; charset="us-ascii" Content-ID: <5E3E82851FF7D544B3F039015CADD095@mail.nasa.gov> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-06-05_06:2014-06-05,2014-06-05,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/_dGv5F8Q67PvsxXgULN_uDJBatk Subject: Re: [dtn] Proposed Working Group Charter Suggestions X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 17:34:05 -0000 In Line >Will, sure, hop counts are a great way to break routing loops, but (a) it >has been suggested that routing loops are not always a bad thing in DTN >(I haven't yet heard the fully-worked out argument for this, so I can't >engage on this point), I've heard that, but it was more of an intentional route back once because you may now have a better path or as a temporary storage environment. > and (b) I think routing loops are the least of your problems in a DTN Not really. It is the unintentional misconfiguration that I worry about. CGR is certainly a candidate if the entire system doesn't get updated correctly. But, just plain static routes is the easiest place to demonstrate this. Create a DTN static route between two systems where the both think the next hop route is the other system. A wants to forward bundles for C to B and B wants to forward bundles for C to A. Now create a bundle destined to C with a lifetime of 300 years and leave a note for three generations from now to see if it is still bouncing between systems. This is really bad for wireless systems. You may lock yourself out. And, depending on how the code is implemented, this may happen for a bundle with a 30 second lifetime depending on when and where the implementation checks for expired bundles. Believe me. I've seen similar with static security tunnels and such. Fortunately IP hop count will kill the packet. I've been very careful and triple checked systems and then still screwed up. Hop count is a relief valve for when something unintentionally gets misconfigured. >-- there are plenty of simpler ways to screw up performance in these >weird environments. I'm sure you are correct. Some things are difficult to anticipate and foresee. Others are obvious. The ability for a bundle stuck in a route loop to self-terminate should be one. Will From nobody Thu Jun 5 10:39:12 2014 Return-Path: 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 D08111A0249; Thu, 5 Jun 2014 10:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, 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 9Z4QZlQMShQz; Thu, 5 Jun 2014 10:39:04 -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 659121A0123; Thu, 5 Jun 2014 10:39:04 -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 s55HcvBJ006831; Thu, 5 Jun 2014 12:38:57 -0500 Received: from XCH-PHX-312.sw.nos.boeing.com (xch-phx-312.sw.nos.boeing.com [130.247.25.173]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s55HckK8005612 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 5 Jun 2014 12:38:47 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.105]) by XCH-PHX-312.sw.nos.boeing.com ([169.254.12.71]) with mapi id 14.03.0181.006; Thu, 5 Jun 2014 10:38:46 -0700 From: "Templin, Fred L" To: Eric Travis , "l.wood@surrey.ac.uk" Thread-Topic: [dtn] DTN BoF Proposal for IETF90 Thread-Index: Ac+AQa9Fez/CplZaSwyaLFpzb8tj0wAmbPuTAAIy0LA= Date: Thu, 5 Jun 2014 17:38:45 +0000 Message-ID: <2134F8430051B64F815C691A62D983181B2BF435@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> <1401967219583.26821@surrey.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: multipart/alternative; boundary="_000_2134F8430051B64F815C691A62D983181B2BF435XCHBLV504nwnosb_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/oJcGMGDy0Co_GZzAYjhjSZP5bks Cc: "mls.ietf@gmail.com" , "spencerdawkins.ietf@gmail.com" , "dtn@ietf.org" , "iesg@ietf.org" Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 17:39:09 -0000 --_000_2134F8430051B64F815C691A62D983181B2BF435XCHBLV504nwnosb_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRXJpYywNCg0KVG8gcG9pbnQgMSksIGFkdmFuY2VtZW50IG9mIHdvcmsgaXRlbXMgaW4gdGhl IElFVEYgaXMgdXN1YWxseSBiYXNlZCBvbiDigJxyb3VnaCBjb25zZW5zdXMNCmFuZCBydW5uaW5n IGNvZGXigJ0gYW5kIHRoZXJlIGlzIHBsZW50eSBvZiBpbnRlcm9wZXJhYmxlIHJ1bm5pbmcgY29k ZSB0aGF0IGltcGxlbWVudHMNClJGQzUwNTAgYW5kIGl0cyByZWxhdGVkIHNwZWNpZmljYXRpb25z IOKAkyBtdWNoIG1vcmUgdGhhbiBtb3N0IElFVEYgYWN0aXZpdGllcyBhcmUgYmFzZWQgb24uDQpB cyB0byDigJxyb3VnaCBjb25zZW5zdXPigJ0sIGhvbGRpbmcgYSBCb0YgaXMgdGhlIGZpcnN0IHN0 ZXAgaW4gZGV0ZXJtaW5pbmcgdGhhdC4NCg0KVG8gcG9pbnQgMiksIGFnYWluIHRoZSBCb0Ygd2ls bCBwcm92aWRlIGEgdXNlZnVsIG1lYXN1cmVtZW50IG9mIGludGVyZXN0Lg0KDQpUaGFua3Mg4oCT IEZyZWQNCmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCg0KDQpGcm9tOiBkdG4gW21haWx0bzpk dG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVyaWMgVHJhdmlzDQpTZW50OiBUaHVy c2RheSwgSnVuZSAwNSwgMjAxNCA5OjI5IEFNDQpUbzogbC53b29kQHN1cnJleS5hYy51aw0KQ2M6 IG1scy5pZXRmQGdtYWlsLmNvbTsgc3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb207IGR0bkBp ZXRmLm9yZzsgaWVzZ0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtkdG5dIERUTiBCb0YgUHJvcG9z YWwgZm9yIElFVEY5MA0KDQpMbG95ZCwNCg0KRW1iZWRkZWQgaW4geW91ciBtYW5pZmVzdG8gYXJl IHR3byBwb2ludHMgd29ydGh5IG9mIGRpc2N1c3Npb24vZGViYXRlIHRocm91Z2hvdXQgdGhlIEJv RiBwcm9jZXNzOg0KDQoxKSBJcyB0aGUgcHJvcG9zZWQgKGJhc2UpIHNvbHV0aW9uIC0gd2l0aCAi bWluaW1hbCIgZml4ZXMgLSBvZiBzdWZmaWNpZW50IG1hdHVyaXR5IGZvciBzdGFuZGFyZGl6YXRp b24gd2l0aGluIHRoZSBJRVRGPw0KDQoyKSBUaGUgZXhpc3RpbmcgSVJURiBEVE5SRyBoYXMgbm90 IGJlZW4gYWJsZSB0byBoYXJuZXNzIHN1ZmZpY2llbnQgaW50ZXJlc3QvcmVzb3VyY2VzIHRvIGFk dmFuY2UgdGhlIHN0YXRlIG9mIFJGQy01MDUwLCBob3cgd2lsbCBhIG5ldyBJRVRGIFdHIGNoYW5n ZSB0aGUgZHluYW1pYz8NCg0KQXMgZm9yIHRoZSByZXN0IG9mIGl0LCB3ZWxsLi4uDQpSRkM1MDUw YmlzOiBoYWxmLWFzc2VkLCBoYWxmLWJha2VkLCByZWhlYXRlZC4NCkJ1dCBoZXksIGFzayBtZSB3 aGF0IEkgX3JlYWxseV8gdGhpbmsuDQoNCkxldCB0aGUgcmF0aW9uYWwsIHdlbGwtcmVhc29uZWQg ZGlzY3Vzc2lvbiBiZWdpbi4uLg0KRXJpYw0KZXJpYy5kb3QudHJhdmlzQGdtYWlsLmNvbTxtYWls dG86ZXJpYy5kb3QudHJhdmlzQGdtYWlsLmNvbT4NCg0KT24gVGh1LCBKdW4gNSwgMjAxNCBhdCA3 OjIwIEFNLCA8bC53b29kQHN1cnJleS5hYy51azxtYWlsdG86bC53b29kQHN1cnJleS5hYy51az4+ IHdyb3RlOg0KQXMgcHJldmlvdXNseSBleHByZXNzZWQgb24gRFROUkcsIEkgaGF2ZSBhIG51bWJl ciBvZiBjb25jZXJucyBhYm91dA0KdGhpcyBwcm9wb3NlZCBCT0YgdG8gY3JlYXRlIGFuIElFVEYg RFROIFdHIHRvIGRvIHdvcmsgb24gdGhlDQpSRkM1MDUwIGJ1bmRsZSBwcm90b2NvbCwgcHJvZHVj ZWQgaW4gdGhlIElSVEYgRFROUkcsIGFuZCBjcmVhdGUNCmFuIFJGQzUwNTBiaXMuIEknbGwgZ28g dGhyb3VnaCB0aG9zZSBjb25jZXJucyBvbmUgYnkgb25lOg0KDQoNCjEuIEkgZG9uJ3Qgc2VlIGhv dyBnb2luZyBzdGFuZGFyZHMgdHJhY2sgY2FuIGJlIGp1c3RpZmllZCwgYmVjYXVzZToNCg0KICAg YS4gQ0NTRFMgaXMgYWxyZWFkeSB3b3JraW5nIG9uIHRoZSBidW5kbGUgcHJvdG9jb2wgYXMgb25l IG9mIHRoZWlyDQogICAgICBibHVlIGJvb2sgc3RhbmRhcmRzLCBiYXNlZCBvbiBSRkM1MDUwLCBh bmQgYW55IFJGQzUwNTBiaXMNCiAgICAgIHdvdWxkIHByZXN1bWFibHkgYWxzbyBiZSBhZG9wdGVk IGFuZCB0aGVuIG1vZGlmaWVkIHRvIG1ha2UNCiAgICAgIGEgQ0NTRFMgc3RhbmRhcmQuDQogICAg ICBJdCdzIHJhdGhlciBsaWtlIENDU0RTIHJlc3RhbmRhcmRpemluZyBUQ1AvSVAgYXMgU0NQUywg YmFjaw0KICAgICAgaW4gdGhlIDE5OTBzLiBUaGF0IFNDUFMgc3RhbmRhcmRpemF0aW9uIHdhc24n dCB1c2VkIG11Y2gNCiAgICAgIGVpdGhlciwgbm90IGxlYXN0IGJlY2F1c2UgQ0NTRFMgJ2ltcHJv dmVkJyBvbiBUQ1AvSVANCiAgICAgIGFuZCB3ZW50IGluY29tcGF0aWJsZSBxdWl0ZSBxdWlja2x5 LiBUaGUgc2FtZSB3aWxsIGhhcHBlbg0KICAgICAgd2l0aCB0aGUgQ0NTRFMgYnVuZGxlIHByb3Rv Y29sLCBhbmQgaW4gYWRvcHRpbmcgUkZDNTA1MA0KICAgICAgQ0NTRFMgaGFzIHJlc2VydmVkIHRo ZSByaWdodCB0byBtYWtlIGNoYW5nZXMgLSB0aGluZ3MgbGlrZQ0KICAgICAgRGVsYXkgVG9sZXJh bnQgUGF5bG9hZCBDb25kaXRpb25pbmcgKERUUEMpIGFyZSBidXQgdGhlIHN0YXJ0Lg0KICAgICAg VGhlcmUncyBhbiBleGFtcGxlIG9mIGJ1bmRsZSBwcm90b2NvbCB3b3JrIG5vdCByZXF1aXJpbmcN CiAgICAgIHRoZSBJRVRGLiBXb3JrIG9uIGFsdGVyaW5nIGFuZCBleHRlbmRpbmcgdGhlIGJ1bmRs ZSBwcm90b2NvbA0KICAgICAgaXMgYWxyZWFkeSBvbmdvaW5nIGluIENDU0RTLg0KICAgICAgU2V0 dGluZyB1cCBhbiBJRVRGIHdvcmtncm91cCB0byB3b3JrIGluIHBhcmFsbGVsIHdvdWxkIG1lYW4N CiAgICAgIHRoYXQgYSBDQ1NEUyBsaWFpc29uIHdvdWxkIGJlIHJlcXVpcmVkLCB0byBwYXkgYXR0 ZW50aW9uDQogICAgICB0byB0aGVpciBjb25jZXJucyBhcyB0aGV5IHRyeSBhbmQgY29udmluY2Ug dGhlaXIgbWVtYmVyIHNwYWNlDQogICAgICBhZ2VuY2llcyB0byB1c2UgdGhlIGJ1bmRsZSBwcm90 b2NvbCwgYW5kIHRvIHByZXZlbnQgdGhlaXIgc3BlYw0KICAgICAgZnJvbSBkaXZlcmdpbmcgKGZ1 cnRoZXIpIGZyb20gdGhlIElFVEYgc3BlYy4gUmVhbGx5LCB0aGUgd29yaw0KICAgICAgaXMgc2lt cGx5IG1vcmUgZWFzaWx5IGRvbmUgaW4gQ0NTRFMsIGdpdmVuIHRoYXQgQ0NTRFMgaXMNCiAgICAg IHByZXR0eSBtdWNoIHRoZSBvbmx5IGN1c3RvbWVyIGZvciBidW5kbGUgcHJvdG9jb2wsIGJlY2F1 c2UNCiAgICAgIE5BU0EgaGFzIG1hbmRhdGVkIGJ1bmRsZSBwcm90b2NvbCB1c2UgZnJvbSBvbiBo aWdoLg0KICAgICAgTkFTQSBsZWFkcyBDQ1NEUywgTkFTQSBKZXQgUHJvcHVsc2lvbiBMYWIgbGVh ZHMgQ0NTRFMgZGVzaWduDQogICAgICBmb3IgTkFTQSdzIFNwYWNlIENvbW11bmljYXRpb25zIGFu ZCBOYXZpZ2F0aW9uIHBlb3BsZS4NCiAgICAgIEpQTCBpcyByZWFsbHkgdGhlIHByaW1hcnkgY3Vz dG9tZXIgZm9yIGFuZCB1c2VyIG9mIGJ1bmRsZQ0KICAgICAgcHJvdG9jb2wsIHJlc3BvbnNpYmxl IGZvciBwcm9tb3RpbmcgaXRzIHVzZSBieSBvdGhlciBzcGFjZQ0KICAgICAgYWdlbmNpZXMgLSBu ZXZlciBhbiBlYXN5IHRhc2ssIGV2ZW4gd2l0aCBnb29kIHRlY2hub2xvZ2llcy4NCg0KICAgYi4g VGhlIElFVEYgcHJvZHVjZXMgSW50ZXJuZXQgc3RhbmRhcmRzLiBUaGUgYnVuZGxlIHByb3RvY29s DQogICAgICBoYXMgbGl0dGxlIGJlYXJpbmcgb24gb3IgaW50ZXJhY3Rpb24gd2l0aCBJbnRlcm5l dCBzdGFuZGFyZHM7DQogICAgICBpdCdzIGFyZ3VhYmx5IGEgd2F5IHRvIGludGVyb3BlcmF0ZSB3 aXRoIHRoZSBJbnRlcm5ldCB3aGlsZQ0KICAgICAgcHJvdGVjdGluZyBDQ1NEUyBmcm9tIGluY3Vy c2lvbiBvZiB0aGUgSW50ZXJuZXQsIGJ5IGxheWVyaW5nDQogICAgICBvdmVyIGJvdGggSW50ZXJu ZXQgYW5kIENDU0RTLiBFYWNoIHRvIHRoZWlyIG93biBkb21haW5zLg0KICAgICAgVXNpbmcgVENQ IGFzIHRoZSBtb3N0IGNvbW1vbiBidW5kbGUgY29udmVyZ2VuY2UgbGF5ZXIgKGRlc2NyaWJlZA0K ICAgICAgaW4gYSBkcmFmdCBub3cgc2V2ZW4geWVhcnMgb2xkKSBkb2VzIG5vdCBtYWtlIHRoZSBi dW5kbGUgcHJvdG9jb2wNCiAgICAgIGFuIGludGVybmV0IHN0YW5kYXJkLiBJZiBpdCBkaWQsIHRo ZW4gQ0NTRFMncyBTcGFjZSBMaW5rDQogICAgICBFeHRlbnNpb24gKGJhc2ljYWxseSBhIFRDUCB0 dW5uZWwgY2FycnlpbmcgQ0NTRFMgZnJhbWVzLCB3aXRoDQogICAgICBtdWNoIGFkZGVkIGNvbXBs ZXhpdHkpIHdvdWxkIGFsc28gYmUgYSBjYW5kaWRhdGUgZm9yIGFuDQogICAgICBJRVRGIGludGVy bmV0IHN0YW5kYXJkLg0KICAgICAgQnV0LCBhZ2FpbiwgdGhhdCB3b3JrIGlzIGJlc3QgZG9uZSBp biBDQ1NEUywgd2hlcmUgdGhlcmUNCiAgICAgIGlzIGludGVyZXN0IGluIGhhdmluZyBpdCBkb25l IGFuZCB0aGVyZSBhcmUgdXNlcnMuIChTb21lDQogICAgICBvZiB0aG9zZSB1c2VycyBtYXkgZXZl biBiZSB3aWxsaW5nIHVzZXJzLikNCg0KICAgYy4gVGhlIGJ1bmRsZSBwcm90b2NvbCBpcyBub3Qg bWF0dXJlLiBEZWZpY2llbmNpZXMgaGF2ZSBiZWVuDQogICAgICBpZGVudGlmaWVkLCBkcmFmdHMg aGF2ZSBiZWVuIHdyaXR0ZW4gaW4gRFROUkcgb3ZlciB0aGUgeWVhcnMsDQogICAgICB0aGVyZSB3 YXMgbGl0dGxlIGludGVyZXN0LCB0aGUgZHJhZnRzIGV4cGlyZWQsIHRoZSBidW5kbGUNCiAgICAg IHByb3RvY29sIHdhcyBuZXZlciBpbXByb3ZlZC4gQW5kIHRoYXQncyBqdXN0IGZyb20gZGVtb25z dHJhdGlvbnM7DQogICAgICB0aGVyZSBoYXMgbm90IGJlZW4gZXh0ZW5kZWQgb3BlcmF0aW9uYWwg dXNlIHRvIG15IGtub3dsZWRnZS4NCiAgICAgIEF0dGVtcHRpbmcgdG8gZml4IHRoZSBidW5kbGUg cHJvdG9jb2wgQU5EIHB1c2ggaXQgdGhyb3VnaCBhcw0KICAgICAgc3RhbmRhcmRzIHRyYWNrIGF0 IHRoZSBzYW1lIHRpbWUgc2VlbXMgdW53YXJyYW50ZWQuDQogICAgICBJdCBtYXkgYmUgcG9saXRp Y2FsbHkgbW90aXZhdGVkLCBidXQgaXQgaXMNCiAgICAgIG5vdCB0ZWNobmljYWxseSBvciBwcm9j ZWR1cmFsbHkganVzdGlmaWFibGUuDQogICAgICBUaGVyZSBpc24ndCB0aGUgdXNlcmJhc2Ugb3Ig ZGVtYW5kIG5lZWRlZCBmb3IgdGhlIGJ1bmRsZQ0KICAgICAgcHJvdG9jb2wgdG8gZ28gc3RhbmRh cmRzIHRyYWNrLCBhbmQgaWYgdGhlIElFVEYgZGlkIGdvDQogICAgICBzdGFuZGFyZHMgdHJhY2ss IENDU0RTIHdvdWxkICdvcHRpbWl6ZScgdGhhdCBzdGFuZGFyZCBpbnRvDQogICAgICBpdHMgb3du IHN0YW5kYXJkLCBqdXN0IGFzIHdhcyBkb25lIHdpdGggU0NQUywgbWVhbmluZyB0aGF0DQogICAg ICB0aGUgSUVURiB3b3VsZCBzcGVuZCBhIGxvdCBvZiB0aW1lIHdvcmtpbmcgb24gc29tZXRoaW5n IHdpdGgNCiAgICAgIG5vIGJlbmVmaXQgdG8gdGhlIElFVEYgY29tbXVuaXR5IG9yIHVzZXJiYXNl LiBFeHRlbmRpbmcNCiAgICAgIHRoZSBJbnRlcm5ldCBwcm90b2NvbHMgdG8gdGhlIERUTiBuZXR3 b3JrIHByb2JsZW0gc3BhY2UNCiAgICAgIGFkZHMgdmFsdWUgdG8gdGhlIGludGVybmV0IHByb3Rv Y29scy4gQSBzZXBhcmF0ZSBwcm90b2NvbA0KICAgICAgZG9lcyBub3QuDQogICAgICBXaG8gd291 bGQgYmVuZWZpdCwgb3V0c2lkZSB0aGUgQ0NTRFMgY29tbXVuaXR5PyBBbmQgQ0NTRFMNCiAgICAg IGlzIHRoZWlyIG93biBzdGFuZGFyZHMgb3JnIC0gYW4gSVNPIHN1Ymdyb3VwIC0gdG8gZG8gd29y aw0KICAgICAgZm9yIHRoYXQgQ0NTRFMgY29tbXVuaXR5Lg0KDQoNCjIuIEkgZG9uJ3Qgc2VlIHdo eSB0aGlzIG5lZWRzIHRvIGJlIGRvbmUgaW4gYW4gSUVURiBXRywgYmVjYXVzZToNCg0KICAgYS4g Z29pbmcgc3RhbmRhcmRzIHRyYWNrIGlzbid0IGp1c3RpZmlhYmxlIC0gc2VlIDEuDQoNCiAgIGIu IFRoZXJlJ3MgYWxyZWFkeSB0aGUgSVJURiBEVE5SRywgd2hpY2ggY291bGQgY2xlYW4gdXAgaXRz DQogICAgICBvd24gd29yaywgYnV0ICxhZnRlciBtYW55IHllYXJzIGFuZCBzb21lIGZhaWxlZCBk cmFmdHMsDQogICAgICBoYXMgbm90Lg0KICAgICAgRGVjbGFyaW5nIHN1Y2Nlc3MgYW5kIHNheWlu ZyBpdCBpcyBub3cgdGltZSB0byBjcmVhdGUgYQ0KICAgICAgV0cgYmFzZWQgb24gRFROUkcncyBh Y2hpZXZlbWVudHMgaXMgbm90IGNvbnZpbmNpbmcsDQogICAgICBiZWNhdXNlIHRob3NlIGFjaGll dmVtZW50cyBhcmUgbm90IGltcHJlc3NpdmUuDQogICAgICAoRGlzY2xhaW1lciBvZiBpbnRlcmVz dDogSSBhdXRob3JlZCAnQSBidW5kbGUgb2YgcHJvYmxlbXMnDQogICAgICBhbmQgaGF2ZSBzcGVu dCBjb25zaWRlcmFibGUgeWVhcnMgdHJ5aW5nIHRvIGV4cGxhaW4gYW5kDQogICAgICBhZGRyZXNz IHByb2JsZW1zIHdpdGggdGhlIGJ1bmRsZSBwcm90b2NvbCwgd2l0aCBsaXR0bGUNCiAgICAgIHN1 Y2Nlc3MsIGFmdGVyIGdldHRpbmcgaXQgdGVzdGVkIGluIHNwYWNlIGJlZm9yZSBOQVNBJ3MNCiAg ICAgIEVYUE9YSS9EZWVwIEltcGFjdCB0ZXN0cyB0b29rIHBsYWNlLg0KICAgICAgRnJlZCBUZW1w bGluJ3MgcHJvYmxlbSBzdGF0ZW1lbnQgZHJhZnRzIGZvciB0aGlzIHB1dGF0aXZlDQogICAgICBJ RVRGIEJPRiBjYWxscyBvbiB0aGF0IHdvcmsuKQ0KICAgICAgUkZDNTA1MGJpcyB3b3VsZCBtYWtl IG1vcmUgc2Vuc2UgYXMgYSBEVE5SRw0KICAgICAgZWZmb3J0LCB0aG91Z2ggaXQgd291bGQgYmUg dGltZSBmb3IgYSBjaGFuZ2luZyBvZiB0aGUNCiAgICAgIGd1YXJkIGFuZCBjaGFpcnMgaW4gRFRO UkcgdG8gaW5mdXNlIHNvbWUgbmV3IGJsb29kIGFuZA0KICAgICAgdGVjaG5pY2FsIGp1ZGdlbWVu dCAtIG9yIHdlJ3JlIGluIGZvciBhbm90aGVyIGZpdmUgeWVhcnMNCiAgICAgIG9mIHdoYXQtZG9l cy10aGUtZW5kLXRvLWVuZC1wcmluY2lwbGUtcmVhbGx5LW1lYW4gYW5kDQogICAgICB3aGF0LWFi b3V0LWNsb2NrcyBhbmQgcmVoYXNoaW5nIHRoZSBzYW1lIG9sZCBhcmd1bWVudHMuDQogICAgICBS ZWFsbHksIERUTlJHIG5lZWRzIHRvIGdldCBpdHMgYWN0IHRvZ2V0aGVyLCBib3RoDQogICAgICBv cmdhbml6YXRpb25hbGx5IGFuZCB0ZWNobmljYWxseS4NCg0KICAgYy4gVGhlcmUncyBhbHJlYWR5 IENDU0RTLCB3aGljaCBoYXMgYWRvcHRlZCB0aGUgRFROUkcgb3V0cHV0LA0KICAgICAgYWZ0ZXIg cHVzaGluZyBmb3IgdGhlIGZvcm1hdGlvbiBvZiBhbiBJbnRlcnBsYW5ldGFyeQ0KICAgICAgSW50 ZXJuZXQgUkcgaW4gdGhlIGZpcnN0IHBsYWNlLg0KDQpTbyBlaXRoZXIgQ0NTRFMgb3IgRFROUkcg Y2FuIGRvIFJGQzUwNTAgcmV2aXNpb24gd29yay4gSWYNCml0J3MgdG8gYmUgYW4gUkZDLCBleHBl cmltZW50YWwgb3IgaW5mb3JtYXRpb25hbCwgYSByZXZpdGFsaXNlZA0KcmVjaGFydGVyZWQgRFRO UkcgY2FuIGRvIGl0Lg0KSXQgZG9lc24ndCBuZWVkIHRvIGJlIGFuIElFVEYgd29ya2dyb3VwLiBJ dCBjZXJ0YWlubHkNCnNob3VsZG4ndCBnbyBzdGFuZGFyZHMgdHJhY2suDQoNCg0KMy4gVGhlIHBo aWxvc29waGljYWxseSBzaGFreSBiYXNpcyBmb3IgdGhlIGJ1bmRsZSBwcm90b2NvbDoNCg0KICAg YS4gRGVsYXktdG9sZXJhbnQgbmV0d29ya2luZyBpcyBub3QgZGlzcnVwdGlvbi10b2xlcmFudA0K ICAgICAgbmV0d29ya2luZy4gU3BhY2UgZGVsYXlzIG9mIGxpZ2h0LW1pbnV0ZXMgd2l0aCBzY2hl ZHVsZWQNCiAgICAgIGNvbnRhY3RzIGFyZSBub3QgdGhlIHNhbWUgYXMgaW50ZXJtaXR0ZW50IGFk LWhvYw0KICAgICAgbWFuZXQtc3R5bGUgY29tbXVuaWNhdGlvbnMuIERpZmZlcmVudCByZXF1aXJl bWVudHMsDQogICAgICBkaWZmZXJlbnQgYnVmZmVyaW5nIGFuZCBzdG9yYWdlLCBkaWZmZXJlbnQg Y29uZGl0aW9ucywNCiAgICAgIGRpZmZlcmVudCBoYW5kbGluZyBvZiBmcmFnbWVudGF0aW9uLCBl dGMuDQoNCiAgIGIuIFRoZSBidW5kbGUgcHJvdG9jb2wgaXMgbm90IERUTi4gRFROIGlzIHRoZSBz Y2VuYXJpbywNCiAgICAgIGluIHdoaWNoIG90aGVyIGFwcHJvYWNoZXMgKHRoZSByZWxhdGVkIENG RFAsIEhhZ2dsZSwNCiAgICAgIHRoZSBNQU5FVCBhbmQgdmVoaWN1bGFyIERUTnMgZWZmb3J0cyB0 aGF0IERUTiBzdWJzdW1lZA0KICAgICAgYW5kIHJlYnJhbmRlZCwgZXRjLikgZXhpc3QuDQogICAg ICBUaGUgYnVuZGxlIHByb3RvY29sIGlzIGludGVuZGVkIHRvIGJlIHVzZWQgaW4gYSBEVE4NCiAg ICAgIHNjZW5hcmlvLiBCcmFuZGluZyB0aGUgYnVuZGxlIHByb3RvY29sIGFzIERUTiBoYXMNCiAg ICAgIHB1dCBiYWNrIG5vbi1idW5kbGUgRFROIHJlc2VhcmNoIGEgbnVtYmVyIG9mIHllYXJzLg0K ICAgICAgQnJhbmRpbmcgYSBncm91cCBvbmx5IHdvcmtpbmcgb24gdGhlIGJ1bmRsZSBwcm90b2Nv bA0KICAgICAgYXMgJ0RUTicgaXMgbWlzbGVhZGluZyBhdCBiZXN0Lg0KDQogICBjLiBFeHRlbmRp bmcgdGhlIGJ1bmRsZSBwcm90b2NvbCBmcm9tIHRoZSBvcmlnaW5hbA0KICAgICAgSW50ZXJwbGFu ZXRhcnkgSW50ZXJuZXQgcHJvYmxlbSAod2hpY2ggaGFkIGl0cyBvd24NCiAgICAgIElSVEYgUkcg d2hpY2ggbGVkIGludG8gYSBzZXQgYnVuZGxlIGFnZW5kYSBmb3INCiAgICAgIERUTlJHKSB0byBj b3ZlciBldmVyeXRoaW5nIGVsc2UgYXMgd2VsbCBzaW1wbHkgaGFzbid0DQogICAgICB3b3JrZWQg dmVyeSB3ZWxsLCBiZWNhdXNlIHRoZSBzY2VuYXJpb3MgYW5kIHVzZSBjYXNlcw0KICAgICAgYXJl IGRpZmZlcmVudC4gV2UgZGVzaWduIGZvciB1c2UgY2FzZXMuIFRvIGJlIHRvbw0KICAgICAgZ2Vu ZXJhbGlzZWQgaXMgdG8gZW5naW5lZXIgZm9yIG5vdGhpbmcuDQoNCiAgIGQuIElnbm9yaW5nIHRo ZSByYW1pZmljYXRpb25zIG9mIHRoZSBlbmQtdG8tZW5kIHByaW5jaXBsZSwNCiAgICAgIHdoaWNo IGFyZSBvZnRlbiBtb3JlIHN1YnRsZSB0aGFuIHBlb3BsZSBzZWVtIHRvIHRoaW5rDQogICAgICB0 aGV5IGFyZS4gVGhlIGJ1bmRsZSBwcm90b2NvbCdzIGN1c3RvZHkgdHJhbnNmZXINCiAgICAgIHBy b2NlZHVyZSBpcyBhIGdvb2QgZXhhbXBsZSBvZiB0aGlzIGZhaWxpbmcuDQoNCiAgIGUuIFRoZSBi dW5kbGUgcHJvdG9jb2wgaXMgaW50ZW5kZWQgZm9yIHVzZSBpbiB0aGUgbW9zdA0KICAgICAgZGlm ZmljdWx0IG5vaXN5IGRpc3J1cHRlZCBuZXR3b3JraW5nIGNvbmRpdGlvbnMgd2Uga25vdywNCiAg ICAgIGFuZCBpdCBjYW4ndCBldmVuIHNhbml0eSBjaGVjayBpdHMgb3duIGhlYWRlcnMgYWdhaW5z dA0KICAgICAgZXJyb3JzLiAoQnV0IGhleSwgaXQgbm93IGhhcyBhIHNlY3VyaXR5IHByb3RvY29s IHRoYXQNCiAgICAgIF9hbG1vc3RfIGRvZXMgdGhhdCEgQnV0IHdoaWNoIGlzIHRvbyBjb21wbGlj YXRlZCwgYW5kDQogICAgICB3b3VsZCBuZWVkIHRvIGJlIHJlZG9uZS4pDQogICAgICBJdCdzIGlu dGVuZGVkIGZvciB0aGUgaGFyc2hlc3QgZW52aXJvbm1lbnRzIHdlIGtub3csDQogICAgICBidXQg bmVlZHMgcmVsaWFibGUgc3luY2hyb25pemVkIGNsb2NrcyBydW5uaW5nIGF0DQogICAgICBzdGVh ZHkgdGVtcGVyYXR1cmVzIQ0KICAgICAgSXQncyBpbnRlbmRlZCBmb3IgZW1iZWRkZWQgc3lzdGVt cywgYnV0IHRoZSBkZXNpZ24NCiAgICAgIGlzIGh1Z2UgYW5kIGNvbXBsZXghIChDRkRQIGhhcyB0 aGUgc2FtZSBwcm9ibGVtOw0KICAgICAgdGhlcmUncyBhIHJlYXNvbiBpbXBsZW1lbnRlcnMgd2Vu dCBmb3IgYSAiQ0ZEUCBsaXRlLCINCiAgICAgIGFuZCBTYXJhdG9nYSBleGlzdHMganVzdCBiZWNh dXNlIENGRFAgd2Fzbid0IHBlcmZvcm1pbmcuDQogICAgICBXb3VsZCBSRkM1MDUwYmlzIGJlICJi dW5kbGluZyBsaXRlIj8pDQogICAgICBUaGVyZSBhcmUgbWFueSAndGhhdCBtYWtlcyBubyBzZW5z ZScgbW9tZW50cyAtIG5vcm1hbGx5DQogICAgICBtb3JlIGltbWVkaWF0ZWx5IHZpc2libGUgdG8g b3V0c2lkZXJzIG5vdCBzdGVlcGVkIGluDQogICAgICB0aGUgZG9nbWEsIHBvbGl0aWNzLCBhbmQg aGlzdG9yeSBvZiBEVE5SRyBhbmQgQ0NTRFMuDQoNCiAgIGYuIFRoZSBhc3N1bXB0aW9uIHRoYXQg YSBmdWxsIHNlY3VyaXR5IHN1aXRlIGlzIGRlc2lyYWJsZQ0KICAgICAgYW5kIG5lY2Vzc2FyeSBh dCBhbGwgdGltZXMuIFRoaXMgaGFzIGRlcmFpbGVkIERUTlJHLA0KICAgICAgYXMgZW1waGFzaXMg d2FzIHBsYWNlZCBvbiBzZWN1cml0eSB3b3JrIGFib3ZlIGFsbA0KICAgICAgZWxzZSwgcmF0aGVy IHRoYW4gd29ya2luZyB0byB0aGUgc2NlbmFyaW8uIFRvIGJlIGZhaXINCiAgICAgIHRvIHRoZSBz ZWN1cml0eS1mb2N1c2VkIGNoYWlycywgdGhlIGNoYXJ0ZXIgdGhhdA0KICAgICAgZXN0YWJsaXNo ZWQgRFROUkcgZnJvbSB0aGUgaW50ZXJwbGFuZXRhcnkgaW50ZXJuZXQNCiAgICAgIHJlc2VhcmNo IGdyb3VwIGNhbGxlZCBvdXQgc2VjdXJpdHkgaGVhdmlseSwgYW5kIHRoZXkNCiAgICAgIHJhbiB3 aXRoIHRoYXQgbWFuZGF0ZS4gQnV0IHRoZSBmb2N1cyBoYXMgZGVjcmVhc2VkDQogICAgICB3b3Jr IG9uIG5vbi1zZWN1cml0eSBtYXR0ZXJzLCB3aGljaCBpcyB0byBzYXksDQogICAgICBldmVyeXRo aW5nIGVsc2UuDQoNClJGQzUwNTBiaXMgbWlnaHQgYWRkcmVzcyB0aGUgbGF0dGVyIHRocmVlIHBy b2JsZW1zLCBidXQNCnRoZSBmaXJzdCB0aHJlZSBhcmUgaW50cmluc2ljYWxseSB1bnNvbHZhYmxl OyBhbnkgc29sdXRpb24NCndpbGwgYmUgdW5zYXRpc2ZhY3RvcnkuIFBlcmhhcHMgbm90IGFzIHVu c2F0aXNmYWN0b3J5IGFzDQpSRkM1MDUwLCBidXQgdW5zYXRpc2ZhY3Rvcnkgbm9uZXRoZWxlc3Mu DQoNClRoZSByZWFsIHBoaWxvc29waGljYWwgcHJvYmxlbSBoZXJlIGlzIHRoZSBwb2xpdGljYWwg ZG9nbWENCnRoYXQsIHdoYXRldmVyIHRoZSBwcm9ibGVtLCB0aGUgYnVuZGxlIHByb3RvY29sIGlz IFRoZQ0KT25lIFRydWUgU29sdXRpb24uDQoNCg0KNC4gVGhlIGRyYWZ0IEJPRiBjaGFydGVyIGlz IGJ1bmRsZS1jZW50cmljLiBXaGljaCBpcyB0byBzYXksDQogICB0aGF0IGl0J3Mgbm90IGF3ZnVs bHkgcmVsZXZhbnQgdG8gaW50ZXJuZXQgc3RhbmRhcmRzLg0KICAgRGlzY2xhaW1lciBvZiBpbnRl cmVzdDogd2UndmUgd29ya2VkIG9uIFNhcmF0b2dhIGFuZA0KICAgSFRUUC1EVE4sIHdoaWNoIGhh dmUgY3VycmVudCBpbnRlcm5ldC1kcmFmdHMsIGFuZCBhcmUNCiAgIHNxdWFyZWx5IGluIHRoZSBE VE4gcHJvYmxlbSBzcGFjZS4NCiAgIFdoZW5ldmVyIHNvbWVvbmUgdGFsa3MgYWJvdXQgbXVsdGlw bGUgY29udmVyZ2VuY2UNCiAgIGxheWVycyBmb3IgdGhlIGJ1bmRsZSBwcm90b2NvbCAtIHRoZXJl J3MgbW9yZSB0aGFuIGZvciBCRUVQLA0KICAgd2hpY2gganVzdCBoYXMgVENQLCBidXQgdGhlcmUg YXJlbid0IG1hbnkgLSBTYXJhdG9nYSBtYXkNCiAgIGJlIG1lbnRpb25lZC4gQnV0IHdlJ3ZlIGZv dW5kIHRoYXQgY2FycnlpbmcgYnVuZGxlcyBkb2Vzbid0DQogICBiZW5lZml0IFNhcmF0b2dhIC0g dGVzdGVkIGl0IGluIHNwYWNlLCBkaWRuJ3Qgc2VlIHRoZQ0KICAgYWR2YW50YWdlcy4gU2FyYXRv Z2EgZG9lcyBsZXZlcmFnZSBhIGZldyBJbnRlcm5ldCB0aGluZ3MgLQ0KICAgVURQLCBVRFAtTGl0 ZSwgbXVsdGljYXN0LiBJdCBkb2VzIGEgZmV3IHNjYWxpbmcgdGhpbmdzIHRoYXQNCiAgIG5vdGhp bmcgZWxzZSBJJ3ZlIHNlZW4gZG9lcyAoZGVzY3JpYmVkIGluIG91ciAyMDExIFRTVkFSRUENCiAg IHByZXNlbnRhdGlvbiB0byBJRVRGIDg4IGluIE5vdmVtYmVyLikgQW5kIGl0J3MgYmFzZWQgb24N CiAgIGEgZGVjYWRlIG9mIG9wZXJhdGlvbmFsIHVzZSBpbiB0aGUgcHJvYmxlbSBkb21haW4uDQog ICBIVFRQLURUTiBsZXZlcmFnZXMgdGhlIEhUVFAgc3VpdGUgYW5kIE1JTUUsIGFuZCBjb21lcyB1 cA0KICAgd2hlbmV2ZXIgd291bGRuJ3QtaXQtYmUtbmljZS10by10cnktSFRUUC1mb3ItRFROIGRp c2N1c3Npb24NCiAgIHRha2VzIHBsYWNlLg0KICAgKEkgc3VzcGVjdCB0aGF0IGFsbCBvZiBTdGVw aGVuIEZhcnJlbGwncyBONEMgd29yayBjb3VsZA0KICAgaGF2ZSBiZWVuIGRvbmUgb3ZlciBob3At YnktaG9wIEhUVFAgYSBsYSBIVFRQLURUTiwgYW5kDQogICB3b3VsZCBoYXZlIHdvcmtlZCBqdXN0 IGFzIHdlbGwgaWYgbm90IGJldHRlci4gQWZ0ZXIgYWxsLA0KICAgaXQgdXNlZCBUQ1AuKQ0KICAg VGhlc2UgYW5kIG90aGVyIGVmZm9ydHMgZXhpc3QgaW4gYSBnYXAgYmV0d2VlbiBEVE5SRywgd2hp Y2gNCiAgIGlzIGF3YXJlIG9mIHRoZSBwcm9ibGVtIHNwYWNlLCBidXQgdGhpbmtzIHRoZSBidW5k bGUNCiAgIHByb3RvY29sIGlzIHRoZSBzb2x1dGlvbiBkZXNwaXRlIG1vdW50aW5nIGV2aWRlbmNl IHRvIHRoZQ0KICAgY29udHJhcnksIGFuZCBUU1ZXRywgd2hlcmUgdGhlIGZldyBhY3R1YWwgdHJh bnNwb3J0DQogICBleHBlcnRzIGxpdmUsIHdpdGhvdXQgY2xvdXQsIG9yIGZ1bmRpbmcsIG9yIHNw YXJlIHRpbWUuDQogICBUaG9zZSBlZmZvcnRzIGFyZSBpbnRlcmVzdGluZyBlbm91Z2ggdG8gaGF2 ZSBpbXBsZW1lbnRhdGlvbnMNCiAgIGtpY2tpbmcgYXJvdW5kIHRvby4NCiAgIEFuZCB5ZXQsIHRo ZSBmb2N1cyBvZiB0aGlzIHB1dGF0aXZlIHdvcmtncm91cCBhbmQgQk9GIGlzDQogICBzb2xlbHkg b24gYnVuZGxpbmcsIGFuZCBub3Qgb24gZXZhbHVhdGluZyB0aGVzZSBvciBvdGhlcg0KICAgdGhp bmdzIHRoYXQgbWlnaHQgZXhpc3QgaW4gdGhlIHByb2JsZW0gc3BhY2UuIFRoZXJlDQogICBtdXN0 IGJlIG90aGVyIHRoaW5ncyBvdXQgdGhlcmUgdGhhdCB3b3VsZCBiZSBvZiBpbnRlcmVzdA0KICAg dG8gc3VjaCBhIERUTiB3b3JrZ3JvdXAuIFdoYXQgaXMgcHJvcG9zZWQgaXMgbm90IGEgRFRODQog ICB3b3JrZ3JvdXAuIFRoZSBjaGFydGVyIGlzIGJhc2ljYWxseSBhIGJ1bmRsZSB3b3JrZ3JvdXAu DQogICBDYW4gYW4gaW50ZXJlc3QgaW4gYnVuZGxpbmcgYW5kIHNvbGVseSBidW5kbGluZyAob3V0 c2lkZQ0KICAgQ0NTRFMsIHdoaWNoIGlzIGRyaXZpbmcgdGhlIHB1c2ggdG8gdXNlIHRoZSBidW5k bGUgcHJvdG9jb2wpDQogICBiZSBqdXN0aWZpZWQgZm9yIGFuIElFVEYgd29ya2dyb3VwPyBJIHJl YWxseSBkb24ndCB0aGluayBzby4NCg0KNS4gVGhlIGJ1bmRsZSBwcm90b2NvbCB3b3JrIHdhcywg SSBnYXRoZXIsIHdlbGwtZnVuZGVkDQogICBieSBhIG51bWJlciBvZiBwYXJ0aWVzLg0KICAgSSBj YW4ndCBzZWUgYSBmb2xsb3ctb24gZWZmb3J0IGJlaW5nIGFueXdoZXJlIG5lYXINCiAgIGFzIHdl bGwgZnVuZGVkLg0KDQogICBhLiBJIGhhdmUgbm8gaWRlYSBob3cgbXVjaCBtb25leSBOQVNBIGFu ZCBDQ1NEUyBoYXZlIHB1dA0KICAgICAgaW50byB0aGlzIC0gZmlyc3QgQ0ZEUCwgdGhlbiBidW5k bGluZywgd2hpY2ggbm93IGhhcw0KICAgICAgdG8gcHJvdmlkZSBhIENGRFAtbGlrZSBBUEkgdG8g dGhlIHVzZXJzIHdobyB3ZXJlIHRvbGQNCiAgICAgIHRoYXQgQ0ZEUCB3YXMgdGhlIGZ1dHVyZSwg YW5kIExpY2tsaWRlciAoTFRQKS4NCiAgICAgIERyYWdnaW5nIENDU0RTIGludG8gdGhlIG1vZGVy biBhZ2Ugb2YgbmV0d29ya2luZw0KICAgICAgc2VlbXMgdW5saWtlbHkgdG8gZXZlciBoYXBwZW4s IHRoYW5rcyB0byBDQ1NEUyBoYXZpbmcNCiAgICAgIGxpdHRsZSBpbiB0aGUgd2F5IG9mIHNhbmUg bGF5ZXJpbmcgb3Igc2VwYXJhdGlvbiBvZg0KICAgICAgZnVuY3Rpb25hbGl0eS4NCiAgICAgIEkg ZG8gaGF2ZSB0aGUgbHV4dXJ5IG9mIG5vdCBuZWVkaW5nIHRvIHdvcmsgb24gQ0NTRFMuDQogICAg ICBCdXQgaWYgeW91IHdhbnQgdG8gd29yayBvbiBDQ1NEUyBwcm90b2NvbHMsIENDU0RTIGlzDQog ICAgICB0aGUgcGxhY2UgdG8gZ28uIFRoZSBJRVRGIGlzIG5vdCB0aGF0IHBsYWNlLg0KDQogICBi LiBEQVJQQSBwb3VyZWQgbW9uZXkgaW50byBEVE4gd29yayAtIGF0IGxlYXN0IHR3ZW50eQ0KICAg ICAgbWlsbGlvbiBkb2xsYXJzLCBmcm9tIHRoZSBwcmVzcyByZWxlYXNlcyBJJ3ZlIHNlZW4uDQog ICAgICBJIGhhdmUgbm8gaWRlYSB3aGF0IERBUlBBIGdvdCBvdXQgb2YgaXQgaW4gdGhlDQogICAg ICB5ZWFycyB0aGV5IHdlcmUgaW52b2x2ZWQ7IGhhdmVuJ3Qgc2VlbiB0aGUgcmVwb3J0cy4NCg0K TXkgcG9pbnQgaXMsIGFsbCB0aGF0IG1vbmV5IGFuZCBlZmZvcnQgYW5kIG1hbnBvd2VyIGFuZA0K b3ZlciBhIGRlY2FkZSBvZiB3b3JrIGFuZCBwcmlvciBleHBlcmllbmNlIHdpdGggQ0ZEUCBhbmQg dHdvDQpJUlRGIFJHcywgd2UgaGF2ZS4uLiBSRkM1MDUwLg0KVGhlcmUgaXMgbm93aGVyZSBuZWFy IGFzIG11Y2ggbW9uZXkgb3IgZWZmb3J0IG9yIG1hbnBvd2VyDQpmb3IgZG9pbmcgYSByZXBsYWNl bWVudC4NCkVyZ28sIGl0IG1pZ2h0IGJlIHN1Z2dlc3RlZCB0aGF0IHRoZSByZXBsYWNlbWVudCBp cyB1bmxpa2VseQ0KdG8gYmUgYXMgZ29vZCBhcyBSRkM1MDUwLCBvciBhcyBnb29kIGFzIENGRFA7 IGF0IGJlc3QsDQp0aGUgdXN1YWwgc3VzcGVjdHMgd2lsbCBoYXZlIGxlc3MgdGltZSBhbmQgZmV3 ZXIgcmVzb3VyY2VzDQp0byByZXBlYXQgdGhlaXIgb3JpZ2luYWwgbWlzdGFrZXMuDQoNCkFuZCB0 cmFuc3BvcnQgZXhwZXJ0aXNlIGZyb20gVFNWV0cgd291bGQgYmUgbmVlZGVkLg0KVFNWV0cgaXMg dW5mYXNoaW9uYWJsZSwgbG93LXZpc2liaWxpdHksIGFuZCBoYXMgZXZlbg0KcHJldmlvdXNseSBo YWQgdHJvdWJsZSBmaW5kaW5nIEFEcyB3aXRoIHJlbGV2YW50IGV4cGVydGlzZS4NCkFuZCBUU1ZX RyBoYXMgYSBmdWxsIHBsYXRlIHdpdGggd29yayBvbiBpdHMgZXhpc3RpbmcNCnByb3RvY29sczsg dGhlcmUgaXMgbm90IGEgbG90IG9mIGV4cGVydGlzZSwgYW5kIHdoYXQgdGhlcmUNCmlzIGlzIHNw cmVhZCB0aGluLg0KU28gYW4gUkZDNTA1YmlzIGVmZm9ydCBpcyB1bmxpa2VseSB0byBnZXQgdGhl IGV4cGVydA0KdGVjaG5pY2FsIGlucHV0IHRoYXQgaXQgc29yZWx5IG5lZWRzLCBldmVuIGlmIGFu IElFVEYNCndvcmtncm91cCBpcyBzZXQgdXAuIChDQ1NEUyBkb2Vzbid0IGhhdmUgdGhhdCB0cmFu c3BvcnQNCmZvY3VzLikNCg0KSWYsIG9uIHRoZSBvdGhlciBoYW5kLCB5b3UgYmVsaWV2ZSBnb29k IHByb3RvY29sIGRlc2lnbg0KY2FuIGJlIGRvbmUgbW9yZSBjaGVhcGx5IGFuZCBsZXZlcmFnZSBh Y3R1YWwgSW50ZXJuZXQNCnN0YW5kYXJkcyB0byBnZXQgSW50ZXJuZXQgZnVuY3Rpb25hbGl0eSB3 b3JraW5nIGluDQpkaWZmaWN1bHQgbmV0d29ya3Mgd2hlcmUgdGhlIGZ1bGwgVENQL0lQIHN1aXRl IGhhcw0KdHJvdWJsZSwgeW91ciBvcHRpb25zIGluY2x1ZGUgU2FyYXRvZ2EgYW5kIEhUVFAtRFRO IQ0KaHR0cDovL3NhcmF0b2dhLnNvdXJjZWZvcmdlLm5ldC8NCmh0dHA6Ly9zYXQtbmV0LmNvbS9M Lldvb2QvZHRuL2h0dHAtZHRuLmh0bWwNClRoZXknbGwgdHJ1bHkgZXh0ZW5kIHRoZSBJbnRlcm5l dCB0byBkaWZmaWN1bHQNCmVudmlyb25tZW50cy4gVGhlIGJ1bmRsZSBwcm90b2NvbCB3b24ndC4N Cg0KU28sIHRvIGNvbmNsdWRlLCB0aGVyZSBpcyBubyBqdXN0aWZpY2F0aW9uIGZvciBnb2luZw0K c3RhbmRhcmRzIHRyYWNrLiBUaGVyZSBpcyBsaXR0bGUganVzdGlmaWNhdGlvbiBmb3IgYW4NCklF VEYgd29ya2dyb3VwLiBUaGVyZSBpcyBtb3JlIGxvZ2ljIGluIHJlY2hhcnRlcmluZyBhbmQNCnJl cHVycG9zaW5nIHRoZSBJUlRGIERUTlJHLCBidXQgdGhlIHdvcmsgbWF5IGFzIHdlbGwNCmJlIGxl ZnQgdG8gQ0NTRFMgZW50aXJlbHkuDQoNClJGQzUwNTBiaXM6IGhhbGYtYXNzZWQsIGhhbGYtYmFr ZWQsIHJlaGVhdGVkLg0KQnV0IGhleSwgYXNrIG1lIHdoYXQgSSBfcmVhbGx5XyB0aGluay4NCg0K TGxveWQgV29vZA0KaHR0cDovL3NhdC1uZXQuY29tL0wuV29vZC9kdG4vDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkdG4gbWFpbGluZyBsaXN0DQpk dG5AaWV0Zi5vcmc8bWFpbHRvOmR0bkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZHRuDQoNCg0KDQotLQ0KVGhlIHByb2JsZW0gd2l0aCB0aGUgd29ybGQg aXMgdGhhdCB0aGUgaW50ZWxsaWdlbnQgcGVvcGxlIGFyZSBmdWxsIG9mIGRvdWJ0cywNCndoaWxl IHRoZSBzdHVwaWQgb25lcyBhcmUgZnVsbCBvZiBjb25maWRlbmNlLg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIC0gQ2hhcmxlcyBCdWtvd3NraQ0K --_000_2134F8430051B64F815C691A62D983181B2BF435XCHBLV504nwnosb_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglw YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBs MA0KCXttc28tbGlzdC1pZDoxNzA4OTQzNDQ5Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1z by1saXN0LXRlbXBsYXRlLWlkczotMjAyNTg0MzA1NiAxNTU3NTg3MTkyIDY3Njk4NjkxIDY3Njk4 NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4Njkz O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7 fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MjA3ODgyNDc4OTsNCgltc28tbGlzdC10eXBlOmh5 YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTMyMjc5MTM5MiA5MzAyNDc1MDggNjc2OTg2 OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEg Njc2OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVh c3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIjt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9t OjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIEVyaWMsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5UbyBwb2ludCAxKSwgYWR2YW5jZW1lbnQgb2Ygd29yayBpdGVtcyBpbiB0aGUgSUVU RiBpcyB1c3VhbGx5IGJhc2VkIG9uIOKAnHJvdWdoIGNvbnNlbnN1czxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5hbmQgcnVubmluZyBjb2Rl4oCdIGFuZCB0aGVyZSBpcyBwbGVudHkgb2Yg aW50ZXJvcGVyYWJsZSBydW5uaW5nIGNvZGUgdGhhdCBpbXBsZW1lbnRzPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlJGQzUwNTAgYW5kIGl0cyByZWxhdGVkIHNwZWNpZmljYXRpb25zIOKA kyBtdWNoIG1vcmUgdGhhbiBtb3N0IElFVEYgYWN0aXZpdGllcyBhcmUgYmFzZWQgb24uDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXMgdG8g4oCccm91Z2ggY29uc2Vuc3Vz4oCdLCBo b2xkaW5nIGEgQm9GIGlzIHRoZSBmaXJzdCBzdGVwIGluIGRldGVybWluaW5nIHRoYXQuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5UbyBwb2ludCAyKSwgYWdhaW4gdGhlIEJvRiB3aWxsIHByb3ZpZGUgYSB1c2VmdWwgbWVh c3VyZW1lbnQgb2YgaW50ZXJlc3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3Mg4oCTIEZyZWQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+ZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gZHRuIFttYWlsdG86ZHRuLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBC ZWhhbGYgT2YgPC9iPkVyaWMgVHJhdmlzPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdW5l IDA1LCAyMDE0IDk6MjkgQU08YnI+DQo8Yj5Ubzo8L2I+IGwud29vZEBzdXJyZXkuYWMudWs8YnI+ DQo8Yj5DYzo8L2I+IG1scy5pZXRmQGdtYWlsLmNvbTsgc3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFp bC5jb207IGR0bkBpZXRmLm9yZzsgaWVzZ0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW2R0bl0gRFROIEJvRiBQcm9wb3NhbCBmb3IgSUVURjkwPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+TGxveWQsPGJyPg0KPGJyPg0KRW1iZWRkZWQgaW4g eW91ciBtYW5pZmVzdG8gYXJlIHR3byBwb2ludHMgd29ydGh5IG9mIGRpc2N1c3Npb24vZGViYXRl IHRocm91Z2hvdXQgdGhlIEJvRiBwcm9jZXNzOjxicj4NCjxicj4NCjEpIElzIHRoZSBwcm9wb3Nl ZCAoYmFzZSkgc29sdXRpb24gLSB3aXRoICZxdW90O21pbmltYWwmcXVvdDsgZml4ZXMgLSBvZiBz dWZmaWNpZW50IG1hdHVyaXR5IGZvciBzdGFuZGFyZGl6YXRpb24gd2l0aGluIHRoZSBJRVRGPzxi cj4NCjxicj4NCjIpIFRoZSBleGlzdGluZyBJUlRGIERUTlJHIGhhcyBub3QgYmVlbiBhYmxlIHRv IGhhcm5lc3Mgc3VmZmljaWVudCBpbnRlcmVzdC9yZXNvdXJjZXMgdG8gYWR2YW5jZSB0aGUgc3Rh dGUgb2YgUkZDLTUwNTAsIGhvdyB3aWxsIGEgbmV3IElFVEYgV0cgY2hhbmdlIHRoZSBkeW5hbWlj Pzxicj4NCjxicj4NCkFzIGZvciB0aGUgcmVzdCBvZiBpdCwgd2VsbC4uLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UkZDNTA1MGJpczogaGFsZi1hc3NlZCwgaGFsZi1iYWtl ZCwgcmVoZWF0ZWQuPGJyPg0KQnV0IGhleSwgYXNrIG1lIHdoYXQgSSBfcmVhbGx5XyB0aGluay48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPkxldCB0aGUgcmF0aW9uYWwsIHdlbGwtcmVhc29uZWQgZGlzY3Vzc2lvbiBiZWdpbi4uLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FcmljPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Im1haWx0bzplcmlj LmRvdC50cmF2aXNAZ21haWwuY29tIj5lcmljLmRvdC50cmF2aXNAZ21haWwuY29tPC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBUaHUsIEp1biA1LCAyMDE0IGF0IDc6MjAgQU0sICZsdDs8YSBocmVm PSJtYWlsdG86bC53b29kQHN1cnJleS5hYy51ayIgdGFyZ2V0PSJfYmxhbmsiPmwud29vZEBzdXJy ZXkuYWMudWs8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkFzIHByZXZpb3VzbHkgZXhwcmVzc2VkIG9uIERUTlJHLCBJIGhhdmUgYSBudW1iZXIgb2Yg Y29uY2VybnMgYWJvdXQ8YnI+DQp0aGlzIHByb3Bvc2VkIEJPRiB0byBjcmVhdGUgYW4gSUVURiBE VE4gV0cgdG8gZG8gd29yayBvbiB0aGU8YnI+DQpSRkM1MDUwIGJ1bmRsZSBwcm90b2NvbCwgcHJv ZHVjZWQgaW4gdGhlIElSVEYgRFROUkcsIGFuZCBjcmVhdGU8YnI+DQphbiBSRkM1MDUwYmlzLiBJ J2xsIGdvIHRocm91Z2ggdGhvc2UgY29uY2VybnMgb25lIGJ5IG9uZTo8YnI+DQo8YnI+DQo8YnI+ DQoxLiBJIGRvbid0IHNlZSBob3cgZ29pbmcgc3RhbmRhcmRzIHRyYWNrIGNhbiBiZSBqdXN0aWZp ZWQsIGJlY2F1c2U6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO2EuIENDU0RTIGlzIGFscmVhZHkg d29ya2luZyBvbiB0aGUgYnVuZGxlIHByb3RvY29sIGFzIG9uZSBvZiB0aGVpcjxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7IGJsdWUgYm9vayBzdGFuZGFyZHMsIGJhc2VkIG9uIFJGQzUwNTAsIGFu ZCBhbnkgUkZDNTA1MGJpczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHdvdWxkIHByZXN1bWFi bHkgYWxzbyBiZSBhZG9wdGVkIGFuZCB0aGVuIG1vZGlmaWVkIHRvIG1ha2U8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyBhIENDU0RTIHN0YW5kYXJkLjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 IEl0J3MgcmF0aGVyIGxpa2UgQ0NTRFMgcmVzdGFuZGFyZGl6aW5nIFRDUC9JUCBhcyBTQ1BTLCBi YWNrPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgaW4gdGhlIDE5OTBzLiBUaGF0IFNDUFMgc3Rh bmRhcmRpemF0aW9uIHdhc24ndCB1c2VkIG11Y2g8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBl aXRoZXIsIG5vdCBsZWFzdCBiZWNhdXNlIENDU0RTICdpbXByb3ZlZCcgb24gVENQL0lQPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgYW5kIHdlbnQgaW5jb21wYXRpYmxlIHF1aXRlIHF1aWNrbHku IFRoZSBzYW1lIHdpbGwgaGFwcGVuPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgd2l0aCB0aGUg Q0NTRFMgYnVuZGxlIHByb3RvY29sLCBhbmQgaW4gYWRvcHRpbmcgUkZDNTA1MDxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7IENDU0RTIGhhcyByZXNlcnZlZCB0aGUgcmlnaHQgdG8gbWFrZSBjaGFu Z2VzIC0gdGhpbmdzIGxpa2U8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBEZWxheSBUb2xlcmFu dCBQYXlsb2FkIENvbmRpdGlvbmluZyAoRFRQQykgYXJlIGJ1dCB0aGUgc3RhcnQuPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgVGhlcmUncyBhbiBleGFtcGxlIG9mIGJ1bmRsZSBwcm90b2NvbCB3 b3JrIG5vdCByZXF1aXJpbmc8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyB0aGUgSUVURi4gV29y ayBvbiBhbHRlcmluZyBhbmQgZXh0ZW5kaW5nIHRoZSBidW5kbGUgcHJvdG9jb2w8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyBpcyBhbHJlYWR5IG9uZ29pbmcgaW4gQ0NTRFMuPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgU2V0dGluZyB1cCBhbiBJRVRGIHdvcmtncm91cCB0byB3b3JrIGluIHBh cmFsbGVsIHdvdWxkIG1lYW48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyB0aGF0IGEgQ0NTRFMg bGlhaXNvbiB3b3VsZCBiZSByZXF1aXJlZCwgdG8gcGF5IGF0dGVudGlvbjxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7IHRvIHRoZWlyIGNvbmNlcm5zIGFzIHRoZXkgdHJ5IGFuZCBjb252aW5jZSB0 aGVpciBtZW1iZXIgc3BhY2U8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBhZ2VuY2llcyB0byB1 c2UgdGhlIGJ1bmRsZSBwcm90b2NvbCwgYW5kIHRvIHByZXZlbnQgdGhlaXIgc3BlYzxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7IGZyb20gZGl2ZXJnaW5nIChmdXJ0aGVyKSBmcm9tIHRoZSBJRVRG IHNwZWMuIFJlYWxseSwgdGhlIHdvcms8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBpcyBzaW1w bHkgbW9yZSBlYXNpbHkgZG9uZSBpbiBDQ1NEUywgZ2l2ZW4gdGhhdCBDQ1NEUyBpczxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7IHByZXR0eSBtdWNoIHRoZSBvbmx5IGN1c3RvbWVyIGZvciBidW5k bGUgcHJvdG9jb2wsIGJlY2F1c2U8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBOQVNBIGhhcyBt YW5kYXRlZCBidW5kbGUgcHJvdG9jb2wgdXNlIGZyb20gb24gaGlnaC48YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyBOQVNBIGxlYWRzIENDU0RTLCBOQVNBIEpldCBQcm9wdWxzaW9uIExhYiBsZWFk cyBDQ1NEUyBkZXNpZ248YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBmb3IgTkFTQSdzIFNwYWNl IENvbW11bmljYXRpb25zIGFuZCBOYXZpZ2F0aW9uIHBlb3BsZS48YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyBKUEwgaXMgcmVhbGx5IHRoZSBwcmltYXJ5IGN1c3RvbWVyIGZvciBhbmQgdXNlciBv ZiBidW5kbGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBwcm90b2NvbCwgcmVzcG9uc2libGUg Zm9yIHByb21vdGluZyBpdHMgdXNlIGJ5IG90aGVyIHNwYWNlPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgYWdlbmNpZXMgLSBuZXZlciBhbiBlYXN5IHRhc2ssIGV2ZW4gd2l0aCBnb29kIHRlY2hu b2xvZ2llcy48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7Yi4gVGhlIElFVEYgcHJvZHVjZXMgSW50 ZXJuZXQgc3RhbmRhcmRzLiBUaGUgYnVuZGxlIHByb3RvY29sPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgaGFzIGxpdHRsZSBiZWFyaW5nIG9uIG9yIGludGVyYWN0aW9uIHdpdGggSW50ZXJuZXQg c3RhbmRhcmRzOzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGl0J3MgYXJndWFibHkgYSB3YXkg dG8gaW50ZXJvcGVyYXRlIHdpdGggdGhlIEludGVybmV0IHdoaWxlPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgcHJvdGVjdGluZyBDQ1NEUyBmcm9tIGluY3Vyc2lvbiBvZiB0aGUgSW50ZXJuZXQs IGJ5IGxheWVyaW5nPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgb3ZlciBib3RoIEludGVybmV0 IGFuZCBDQ1NEUy4gRWFjaCB0byB0aGVpciBvd24gZG9tYWlucy48YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyBVc2luZyBUQ1AgYXMgdGhlIG1vc3QgY29tbW9uIGJ1bmRsZSBjb252ZXJnZW5jZSBs YXllciAoZGVzY3JpYmVkPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgaW4gYSBkcmFmdCBub3cg c2V2ZW4geWVhcnMgb2xkKSBkb2VzIG5vdCBtYWtlIHRoZSBidW5kbGUgcHJvdG9jb2w8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyBhbiBpbnRlcm5ldCBzdGFuZGFyZC4gSWYgaXQgZGlkLCB0aGVu IENDU0RTJ3MgU3BhY2UgTGluazxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IEV4dGVuc2lvbiAo YmFzaWNhbGx5IGEgVENQIHR1bm5lbCBjYXJyeWluZyBDQ1NEUyBmcmFtZXMsIHdpdGg8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyBtdWNoIGFkZGVkIGNvbXBsZXhpdHkpIHdvdWxkIGFsc28gYmUg YSBjYW5kaWRhdGUgZm9yIGFuPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgSUVURiBpbnRlcm5l dCBzdGFuZGFyZC48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBCdXQsIGFnYWluLCB0aGF0IHdv cmsgaXMgYmVzdCBkb25lIGluIENDU0RTLCB3aGVyZSB0aGVyZTxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7IGlzIGludGVyZXN0IGluIGhhdmluZyBpdCBkb25lIGFuZCB0aGVyZSBhcmUgdXNlcnMu IChTb21lPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgb2YgdGhvc2UgdXNlcnMgbWF5IGV2ZW4g YmUgd2lsbGluZyB1c2Vycy4pPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO2MuIFRoZSBidW5kbGUg cHJvdG9jb2wgaXMgbm90IG1hdHVyZS4gRGVmaWNpZW5jaWVzIGhhdmUgYmVlbjxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7IGlkZW50aWZpZWQsIGRyYWZ0cyBoYXZlIGJlZW4gd3JpdHRlbiBpbiBE VE5SRyBvdmVyIHRoZSB5ZWFycyw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyB0aGVyZSB3YXMg bGl0dGxlIGludGVyZXN0LCB0aGUgZHJhZnRzIGV4cGlyZWQsIHRoZSBidW5kbGU8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyBwcm90b2NvbCB3YXMgbmV2ZXIgaW1wcm92ZWQuIEFuZCB0aGF0J3Mg anVzdCBmcm9tIGRlbW9uc3RyYXRpb25zOzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoZXJl IGhhcyBub3QgYmVlbiBleHRlbmRlZCBvcGVyYXRpb25hbCB1c2UgdG8gbXkga25vd2xlZGdlLjxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IEF0dGVtcHRpbmcgdG8gZml4IHRoZSBidW5kbGUgcHJv dG9jb2wgQU5EIHB1c2ggaXQgdGhyb3VnaCBhczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHN0 YW5kYXJkcyB0cmFjayBhdCB0aGUgc2FtZSB0aW1lIHNlZW1zIHVud2FycmFudGVkLjxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7IEl0IG1heSBiZSBwb2xpdGljYWxseSBtb3RpdmF0ZWQsIGJ1dCBp dCBpczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IG5vdCB0ZWNobmljYWxseSBvciBwcm9jZWR1 cmFsbHkganVzdGlmaWFibGUuPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgVGhlcmUgaXNuJ3Qg dGhlIHVzZXJiYXNlIG9yIGRlbWFuZCBuZWVkZWQgZm9yIHRoZSBidW5kbGU8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyBwcm90b2NvbCB0byBnbyBzdGFuZGFyZHMgdHJhY2ssIGFuZCBpZiB0aGUg SUVURiBkaWQgZ288YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBzdGFuZGFyZHMgdHJhY2ssIEND U0RTIHdvdWxkICdvcHRpbWl6ZScgdGhhdCBzdGFuZGFyZCBpbnRvPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgaXRzIG93biBzdGFuZGFyZCwganVzdCBhcyB3YXMgZG9uZSB3aXRoIFNDUFMsIG1l YW5pbmcgdGhhdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoZSBJRVRGIHdvdWxkIHNwZW5k IGEgbG90IG9mIHRpbWUgd29ya2luZyBvbiBzb21ldGhpbmcgd2l0aDxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7IG5vIGJlbmVmaXQgdG8gdGhlIElFVEYgY29tbXVuaXR5IG9yIHVzZXJiYXNlLiBF eHRlbmRpbmc8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyB0aGUgSW50ZXJuZXQgcHJvdG9jb2xz IHRvIHRoZSBEVE4gbmV0d29yayBwcm9ibGVtIHNwYWNlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgYWRkcyB2YWx1ZSB0byB0aGUgaW50ZXJuZXQgcHJvdG9jb2xzLiBBIHNlcGFyYXRlIHByb3Rv Y29sPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgZG9lcyBub3QuPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgV2hvIHdvdWxkIGJlbmVmaXQsIG91dHNpZGUgdGhlIENDU0RTIGNvbW11bml0eT8g QW5kIENDU0RTPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgaXMgdGhlaXIgb3duIHN0YW5kYXJk cyBvcmcgLSBhbiBJU08gc3ViZ3JvdXAgLSB0byBkbyB3b3JrPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgZm9yIHRoYXQgQ0NTRFMgY29tbXVuaXR5Ljxicj4NCjxicj4NCjxicj4NCjIuIEkgZG9u J3Qgc2VlIHdoeSB0aGlzIG5lZWRzIHRvIGJlIGRvbmUgaW4gYW4gSUVURiBXRywgYmVjYXVzZTo8 YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7YS4gZ29pbmcgc3RhbmRhcmRzIHRyYWNrIGlzbid0IGp1 c3RpZmlhYmxlIC0gc2VlIDEuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO2IuIFRoZXJlJ3MgYWxy ZWFkeSB0aGUgSVJURiBEVE5SRywgd2hpY2ggY291bGQgY2xlYW4gdXAgaXRzPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgb3duIHdvcmssIGJ1dCAsYWZ0ZXIgbWFueSB5ZWFycyBhbmQgc29tZSBm YWlsZWQgZHJhZnRzLDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGhhcyBub3QuPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgRGVjbGFyaW5nIHN1Y2Nlc3MgYW5kIHNheWluZyBpdCBpcyBub3cg dGltZSB0byBjcmVhdGUgYTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IFdHIGJhc2VkIG9uIERU TlJHJ3MgYWNoaWV2ZW1lbnRzIGlzIG5vdCBjb252aW5jaW5nLDxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7IGJlY2F1c2UgdGhvc2UgYWNoaWV2ZW1lbnRzIGFyZSBub3QgaW1wcmVzc2l2ZS48YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAoRGlzY2xhaW1lciBvZiBpbnRlcmVzdDogSSBhdXRob3Jl ZCAnQSBidW5kbGUgb2YgcHJvYmxlbXMnPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgYW5kIGhh dmUgc3BlbnQgY29uc2lkZXJhYmxlIHllYXJzIHRyeWluZyB0byBleHBsYWluIGFuZDxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7IGFkZHJlc3MgcHJvYmxlbXMgd2l0aCB0aGUgYnVuZGxlIHByb3Rv Y29sLCB3aXRoIGxpdHRsZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHN1Y2Nlc3MsIGFmdGVy IGdldHRpbmcgaXQgdGVzdGVkIGluIHNwYWNlIGJlZm9yZSBOQVNBJ3M8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyBFWFBPWEkvRGVlcCBJbXBhY3QgdGVzdHMgdG9vayBwbGFjZS48YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyBGcmVkIFRlbXBsaW4ncyBwcm9ibGVtIHN0YXRlbWVudCBkcmFmdHMg Zm9yIHRoaXMgcHV0YXRpdmU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBJRVRGIEJPRiBjYWxs cyBvbiB0aGF0IHdvcmsuKTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IFJGQzUwNTBiaXMgd291 bGQgbWFrZSBtb3JlIHNlbnNlIGFzIGEgRFROUkc8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBl ZmZvcnQsIHRob3VnaCBpdCB3b3VsZCBiZSB0aW1lIGZvciBhIGNoYW5naW5nIG9mIHRoZTxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7IGd1YXJkIGFuZCBjaGFpcnMgaW4gRFROUkcgdG8gaW5mdXNl IHNvbWUgbmV3IGJsb29kIGFuZDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHRlY2huaWNhbCBq dWRnZW1lbnQgLSBvciB3ZSdyZSBpbiBmb3IgYW5vdGhlciBmaXZlIHllYXJzPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgb2Ygd2hhdC1kb2VzLXRoZS1lbmQtdG8tZW5kLXByaW5jaXBsZS1yZWFs bHktbWVhbiBhbmQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyB3aGF0LWFib3V0LWNsb2NrcyBh bmQgcmVoYXNoaW5nIHRoZSBzYW1lIG9sZCBhcmd1bWVudHMuPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgUmVhbGx5LCBEVE5SRyBuZWVkcyB0byBnZXQgaXRzIGFjdCB0b2dldGhlciwgYm90aDxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IG9yZ2FuaXphdGlvbmFsbHkgYW5kIHRlY2huaWNhbGx5 Ljxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtjLiBUaGVyZSdzIGFscmVhZHkgQ0NTRFMsIHdoaWNo IGhhcyBhZG9wdGVkIHRoZSBEVE5SRyBvdXRwdXQsPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg YWZ0ZXIgcHVzaGluZyBmb3IgdGhlIGZvcm1hdGlvbiBvZiBhbiBJbnRlcnBsYW5ldGFyeTxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7IEludGVybmV0IFJHIGluIHRoZSBmaXJzdCBwbGFjZS48YnI+ DQo8YnI+DQpTbyBlaXRoZXIgQ0NTRFMgb3IgRFROUkcgY2FuIGRvIFJGQzUwNTAgcmV2aXNpb24g d29yay4gSWY8YnI+DQppdCdzIHRvIGJlIGFuIFJGQywgZXhwZXJpbWVudGFsIG9yIGluZm9ybWF0 aW9uYWwsIGEgcmV2aXRhbGlzZWQ8YnI+DQpyZWNoYXJ0ZXJlZCBEVE5SRyBjYW4gZG8gaXQuPGJy Pg0KSXQgZG9lc24ndCBuZWVkIHRvIGJlIGFuIElFVEYgd29ya2dyb3VwLiBJdCBjZXJ0YWlubHk8 YnI+DQpzaG91bGRuJ3QgZ28gc3RhbmRhcmRzIHRyYWNrLjxicj4NCjxicj4NCjxicj4NCjMuIFRo ZSBwaGlsb3NvcGhpY2FsbHkgc2hha3kgYmFzaXMgZm9yIHRoZSBidW5kbGUgcHJvdG9jb2w6PGJy Pg0KPGJyPg0KJm5ic3A7ICZuYnNwO2EuIERlbGF5LXRvbGVyYW50IG5ldHdvcmtpbmcgaXMgbm90 IGRpc3J1cHRpb24tdG9sZXJhbnQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBuZXR3b3JraW5n LiBTcGFjZSBkZWxheXMgb2YgbGlnaHQtbWludXRlcyB3aXRoIHNjaGVkdWxlZDxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7IGNvbnRhY3RzIGFyZSBub3QgdGhlIHNhbWUgYXMgaW50ZXJtaXR0ZW50 IGFkLWhvYzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IG1hbmV0LXN0eWxlIGNvbW11bmljYXRp b25zLiBEaWZmZXJlbnQgcmVxdWlyZW1lbnRzLDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGRp ZmZlcmVudCBidWZmZXJpbmcgYW5kIHN0b3JhZ2UsIGRpZmZlcmVudCBjb25kaXRpb25zLDxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7IGRpZmZlcmVudCBoYW5kbGluZyBvZiBmcmFnbWVudGF0aW9u LCBldGMuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO2IuIFRoZSBidW5kbGUgcHJvdG9jb2wgaXMg bm90IERUTi4gRFROIGlzIHRoZSBzY2VuYXJpbyw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBp biB3aGljaCBvdGhlciBhcHByb2FjaGVzICh0aGUgcmVsYXRlZCBDRkRQLCBIYWdnbGUsPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhlIE1BTkVUIGFuZCB2ZWhpY3VsYXIgRFROcyBlZmZvcnRz IHRoYXQgRFROIHN1YnN1bWVkPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgYW5kIHJlYnJhbmRl ZCwgZXRjLikgZXhpc3QuPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgVGhlIGJ1bmRsZSBwcm90 b2NvbCBpcyBpbnRlbmRlZCB0byBiZSB1c2VkIGluIGEgRFROPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgc2NlbmFyaW8uIEJyYW5kaW5nIHRoZSBidW5kbGUgcHJvdG9jb2wgYXMgRFROIGhhczxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHB1dCBiYWNrIG5vbi1idW5kbGUgRFROIHJlc2VhcmNo IGEgbnVtYmVyIG9mIHllYXJzLjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IEJyYW5kaW5nIGEg Z3JvdXAgb25seSB3b3JraW5nIG9uIHRoZSBidW5kbGUgcHJvdG9jb2w8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyBhcyAnRFROJyBpcyBtaXNsZWFkaW5nIGF0IGJlc3QuPGJyPg0KPGJyPg0KJm5i c3A7ICZuYnNwO2MuIEV4dGVuZGluZyB0aGUgYnVuZGxlIHByb3RvY29sIGZyb20gdGhlIG9yaWdp bmFsPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgSW50ZXJwbGFuZXRhcnkgSW50ZXJuZXQgcHJv YmxlbSAod2hpY2ggaGFkIGl0cyBvd248YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBJUlRGIFJH IHdoaWNoIGxlZCBpbnRvIGEgc2V0IGJ1bmRsZSBhZ2VuZGEgZm9yPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgRFROUkcpIHRvIGNvdmVyIGV2ZXJ5dGhpbmcgZWxzZSBhcyB3ZWxsIHNpbXBseSBo YXNuJ3Q8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyB3b3JrZWQgdmVyeSB3ZWxsLCBiZWNhdXNl IHRoZSBzY2VuYXJpb3MgYW5kIHVzZSBjYXNlczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGFy ZSBkaWZmZXJlbnQuIFdlIGRlc2lnbiBmb3IgdXNlIGNhc2VzLiBUbyBiZSB0b288YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyBnZW5lcmFsaXNlZCBpcyB0byBlbmdpbmVlciBmb3Igbm90aGluZy48 YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ZC4gSWdub3JpbmcgdGhlIHJhbWlmaWNhdGlvbnMgb2Yg dGhlIGVuZC10by1lbmQgcHJpbmNpcGxlLDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHdoaWNo IGFyZSBvZnRlbiBtb3JlIHN1YnRsZSB0aGFuIHBlb3BsZSBzZWVtIHRvIHRoaW5rPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgdGhleSBhcmUuIFRoZSBidW5kbGUgcHJvdG9jb2wncyBjdXN0b2R5 IHRyYW5zZmVyPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgcHJvY2VkdXJlIGlzIGEgZ29vZCBl eGFtcGxlIG9mIHRoaXMgZmFpbGluZy48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ZS4gVGhlIGJ1 bmRsZSBwcm90b2NvbCBpcyBpbnRlbmRlZCBmb3IgdXNlIGluIHRoZSBtb3N0PGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgZGlmZmljdWx0IG5vaXN5IGRpc3J1cHRlZCBuZXR3b3JraW5nIGNvbmRp dGlvbnMgd2Uga25vdyw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBhbmQgaXQgY2FuJ3QgZXZl biBzYW5pdHkgY2hlY2sgaXRzIG93biBoZWFkZXJzIGFnYWluc3Q8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyBlcnJvcnMuIChCdXQgaGV5LCBpdCBub3cgaGFzIGEgc2VjdXJpdHkgcHJvdG9jb2wg dGhhdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IF9hbG1vc3RfIGRvZXMgdGhhdCEgQnV0IHdo aWNoIGlzIHRvbyBjb21wbGljYXRlZCwgYW5kPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgd291 bGQgbmVlZCB0byBiZSByZWRvbmUuKTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IEl0J3MgaW50 ZW5kZWQgZm9yIHRoZSBoYXJzaGVzdCBlbnZpcm9ubWVudHMgd2Uga25vdyw8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyBidXQgbmVlZHMgcmVsaWFibGUgc3luY2hyb25pemVkIGNsb2NrcyBydW5u aW5nIGF0PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgc3RlYWR5IHRlbXBlcmF0dXJlcyE8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyBJdCdzIGludGVuZGVkIGZvciBlbWJlZGRlZCBzeXN0ZW1z LCBidXQgdGhlIGRlc2lnbjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGlzIGh1Z2UgYW5kIGNv bXBsZXghIChDRkRQIGhhcyB0aGUgc2FtZSBwcm9ibGVtOzxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7IHRoZXJlJ3MgYSByZWFzb24gaW1wbGVtZW50ZXJzIHdlbnQgZm9yIGEgJnF1b3Q7Q0ZEUCBs aXRlLCZxdW90Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGFuZCBTYXJhdG9nYSBleGlzdHMg anVzdCBiZWNhdXNlIENGRFAgd2Fzbid0IHBlcmZvcm1pbmcuPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgV291bGQgUkZDNTA1MGJpcyBiZSAmcXVvdDtidW5kbGluZyBsaXRlJnF1b3Q7Pyk8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyBUaGVyZSBhcmUgbWFueSAndGhhdCBtYWtlcyBubyBzZW5z ZScgbW9tZW50cyAtIG5vcm1hbGx5PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgbW9yZSBpbW1l ZGlhdGVseSB2aXNpYmxlIHRvIG91dHNpZGVycyBub3Qgc3RlZXBlZCBpbjxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7IHRoZSBkb2dtYSwgcG9saXRpY3MsIGFuZCBoaXN0b3J5IG9mIERUTlJHIGFu ZCBDQ1NEUy48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7Zi4gVGhlIGFzc3VtcHRpb24gdGhhdCBh IGZ1bGwgc2VjdXJpdHkgc3VpdGUgaXMgZGVzaXJhYmxlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgYW5kIG5lY2Vzc2FyeSBhdCBhbGwgdGltZXMuIFRoaXMgaGFzIGRlcmFpbGVkIERUTlJHLDxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGFzIGVtcGhhc2lzIHdhcyBwbGFjZWQgb24gc2VjdXJp dHkgd29yayBhYm92ZSBhbGw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBlbHNlLCByYXRoZXIg dGhhbiB3b3JraW5nIHRvIHRoZSBzY2VuYXJpby4gVG8gYmUgZmFpcjxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7IHRvIHRoZSBzZWN1cml0eS1mb2N1c2VkIGNoYWlycywgdGhlIGNoYXJ0ZXIgdGhh dDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGVzdGFibGlzaGVkIERUTlJHIGZyb20gdGhlIGlu dGVycGxhbmV0YXJ5IGludGVybmV0PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgcmVzZWFyY2gg Z3JvdXAgY2FsbGVkIG91dCBzZWN1cml0eSBoZWF2aWx5LCBhbmQgdGhleTxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7IHJhbiB3aXRoIHRoYXQgbWFuZGF0ZS4gQnV0IHRoZSBmb2N1cyBoYXMgZGVj cmVhc2VkPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgd29yayBvbiBub24tc2VjdXJpdHkgbWF0 dGVycywgd2hpY2ggaXMgdG8gc2F5LDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGV2ZXJ5dGhp bmcgZWxzZS48YnI+DQo8YnI+DQpSRkM1MDUwYmlzIG1pZ2h0IGFkZHJlc3MgdGhlIGxhdHRlciB0 aHJlZSBwcm9ibGVtcywgYnV0PGJyPg0KdGhlIGZpcnN0IHRocmVlIGFyZSBpbnRyaW5zaWNhbGx5 IHVuc29sdmFibGU7IGFueSBzb2x1dGlvbjxicj4NCndpbGwgYmUgdW5zYXRpc2ZhY3RvcnkuIFBl cmhhcHMgbm90IGFzIHVuc2F0aXNmYWN0b3J5IGFzPGJyPg0KUkZDNTA1MCwgYnV0IHVuc2F0aXNm YWN0b3J5IG5vbmV0aGVsZXNzLjxicj4NCjxicj4NClRoZSByZWFsIHBoaWxvc29waGljYWwgcHJv YmxlbSBoZXJlIGlzIHRoZSBwb2xpdGljYWwgZG9nbWE8YnI+DQp0aGF0LCB3aGF0ZXZlciB0aGUg cHJvYmxlbSwgdGhlIGJ1bmRsZSBwcm90b2NvbCBpcyBUaGU8YnI+DQpPbmUgVHJ1ZSBTb2x1dGlv bi48YnI+DQo8YnI+DQo8YnI+DQo0LiBUaGUgZHJhZnQgQk9GIGNoYXJ0ZXIgaXMgYnVuZGxlLWNl bnRyaWMuIFdoaWNoIGlzIHRvIHNheSw8YnI+DQombmJzcDsgJm5ic3A7dGhhdCBpdCdzIG5vdCBh d2Z1bGx5IHJlbGV2YW50IHRvIGludGVybmV0IHN0YW5kYXJkcy48YnI+DQombmJzcDsgJm5ic3A7 RGlzY2xhaW1lciBvZiBpbnRlcmVzdDogd2UndmUgd29ya2VkIG9uIFNhcmF0b2dhIGFuZDxicj4N CiZuYnNwOyAmbmJzcDtIVFRQLURUTiwgd2hpY2ggaGF2ZSBjdXJyZW50IGludGVybmV0LWRyYWZ0 cywgYW5kIGFyZTxicj4NCiZuYnNwOyAmbmJzcDtzcXVhcmVseSBpbiB0aGUgRFROIHByb2JsZW0g c3BhY2UuPGJyPg0KJm5ic3A7ICZuYnNwO1doZW5ldmVyIHNvbWVvbmUgdGFsa3MgYWJvdXQgbXVs dGlwbGUgY29udmVyZ2VuY2U8YnI+DQombmJzcDsgJm5ic3A7bGF5ZXJzIGZvciB0aGUgYnVuZGxl IHByb3RvY29sIC0gdGhlcmUncyBtb3JlIHRoYW4gZm9yIEJFRVAsPGJyPg0KJm5ic3A7ICZuYnNw O3doaWNoIGp1c3QgaGFzIFRDUCwgYnV0IHRoZXJlIGFyZW4ndCBtYW55IC0gU2FyYXRvZ2EgbWF5 PGJyPg0KJm5ic3A7ICZuYnNwO2JlIG1lbnRpb25lZC4gQnV0IHdlJ3ZlIGZvdW5kIHRoYXQgY2Fy cnlpbmcgYnVuZGxlcyBkb2Vzbid0PGJyPg0KJm5ic3A7ICZuYnNwO2JlbmVmaXQgU2FyYXRvZ2Eg LSB0ZXN0ZWQgaXQgaW4gc3BhY2UsIGRpZG4ndCBzZWUgdGhlPGJyPg0KJm5ic3A7ICZuYnNwO2Fk dmFudGFnZXMuIFNhcmF0b2dhIGRvZXMgbGV2ZXJhZ2UgYSBmZXcgSW50ZXJuZXQgdGhpbmdzIC08 YnI+DQombmJzcDsgJm5ic3A7VURQLCBVRFAtTGl0ZSwgbXVsdGljYXN0LiBJdCBkb2VzIGEgZmV3 IHNjYWxpbmcgdGhpbmdzIHRoYXQ8YnI+DQombmJzcDsgJm5ic3A7bm90aGluZyBlbHNlIEkndmUg c2VlbiBkb2VzIChkZXNjcmliZWQgaW4gb3VyIDIwMTEgVFNWQVJFQTxicj4NCiZuYnNwOyAmbmJz cDtwcmVzZW50YXRpb24gdG8gSUVURiA4OCBpbiBOb3ZlbWJlci4pIEFuZCBpdCdzIGJhc2VkIG9u PGJyPg0KJm5ic3A7ICZuYnNwO2EgZGVjYWRlIG9mIG9wZXJhdGlvbmFsIHVzZSBpbiB0aGUgcHJv YmxlbSBkb21haW4uPGJyPg0KJm5ic3A7ICZuYnNwO0hUVFAtRFROIGxldmVyYWdlcyB0aGUgSFRU UCBzdWl0ZSBhbmQgTUlNRSwgYW5kIGNvbWVzIHVwPGJyPg0KJm5ic3A7ICZuYnNwO3doZW5ldmVy IHdvdWxkbid0LWl0LWJlLW5pY2UtdG8tdHJ5LUhUVFAtZm9yLURUTiBkaXNjdXNzaW9uPGJyPg0K Jm5ic3A7ICZuYnNwO3Rha2VzIHBsYWNlLjxicj4NCiZuYnNwOyAmbmJzcDsoSSBzdXNwZWN0IHRo YXQgYWxsIG9mIFN0ZXBoZW4gRmFycmVsbCdzIE40QyB3b3JrIGNvdWxkPGJyPg0KJm5ic3A7ICZu YnNwO2hhdmUgYmVlbiBkb25lIG92ZXIgaG9wLWJ5LWhvcCBIVFRQIGEgbGEgSFRUUC1EVE4sIGFu ZDxicj4NCiZuYnNwOyAmbmJzcDt3b3VsZCBoYXZlIHdvcmtlZCBqdXN0IGFzIHdlbGwgaWYgbm90 IGJldHRlci4gQWZ0ZXIgYWxsLDxicj4NCiZuYnNwOyAmbmJzcDtpdCB1c2VkIFRDUC4pPGJyPg0K Jm5ic3A7ICZuYnNwO1RoZXNlIGFuZCBvdGhlciBlZmZvcnRzIGV4aXN0IGluIGEgZ2FwIGJldHdl ZW4gRFROUkcsIHdoaWNoPGJyPg0KJm5ic3A7ICZuYnNwO2lzIGF3YXJlIG9mIHRoZSBwcm9ibGVt IHNwYWNlLCBidXQgdGhpbmtzIHRoZSBidW5kbGU8YnI+DQombmJzcDsgJm5ic3A7cHJvdG9jb2wg aXMgdGhlIHNvbHV0aW9uIGRlc3BpdGUgbW91bnRpbmcgZXZpZGVuY2UgdG8gdGhlPGJyPg0KJm5i c3A7ICZuYnNwO2NvbnRyYXJ5LCBhbmQgVFNWV0csIHdoZXJlIHRoZSBmZXcgYWN0dWFsIHRyYW5z cG9ydDxicj4NCiZuYnNwOyAmbmJzcDtleHBlcnRzIGxpdmUsIHdpdGhvdXQgY2xvdXQsIG9yIGZ1 bmRpbmcsIG9yIHNwYXJlIHRpbWUuPGJyPg0KJm5ic3A7ICZuYnNwO1Rob3NlIGVmZm9ydHMgYXJl IGludGVyZXN0aW5nIGVub3VnaCB0byBoYXZlIGltcGxlbWVudGF0aW9uczxicj4NCiZuYnNwOyAm bmJzcDtraWNraW5nIGFyb3VuZCB0b28uPGJyPg0KJm5ic3A7ICZuYnNwO0FuZCB5ZXQsIHRoZSBm b2N1cyBvZiB0aGlzIHB1dGF0aXZlIHdvcmtncm91cCBhbmQgQk9GIGlzPGJyPg0KJm5ic3A7ICZu YnNwO3NvbGVseSBvbiBidW5kbGluZywgYW5kIG5vdCBvbiBldmFsdWF0aW5nIHRoZXNlIG9yIG90 aGVyPGJyPg0KJm5ic3A7ICZuYnNwO3RoaW5ncyB0aGF0IG1pZ2h0IGV4aXN0IGluIHRoZSBwcm9i bGVtIHNwYWNlLiBUaGVyZTxicj4NCiZuYnNwOyAmbmJzcDttdXN0IGJlIG90aGVyIHRoaW5ncyBv dXQgdGhlcmUgdGhhdCB3b3VsZCBiZSBvZiBpbnRlcmVzdDxicj4NCiZuYnNwOyAmbmJzcDt0byBz dWNoIGEgRFROIHdvcmtncm91cC4gV2hhdCBpcyBwcm9wb3NlZCBpcyBub3QgYSBEVE48YnI+DQom bmJzcDsgJm5ic3A7d29ya2dyb3VwLiBUaGUgY2hhcnRlciBpcyBiYXNpY2FsbHkgYSBidW5kbGUg d29ya2dyb3VwLjxicj4NCiZuYnNwOyAmbmJzcDtDYW4gYW4gaW50ZXJlc3QgaW4gYnVuZGxpbmcg YW5kIHNvbGVseSBidW5kbGluZyAob3V0c2lkZTxicj4NCiZuYnNwOyAmbmJzcDtDQ1NEUywgd2hp Y2ggaXMgZHJpdmluZyB0aGUgcHVzaCB0byB1c2UgdGhlIGJ1bmRsZSBwcm90b2NvbCk8YnI+DQom bmJzcDsgJm5ic3A7YmUganVzdGlmaWVkIGZvciBhbiBJRVRGIHdvcmtncm91cD8gSSByZWFsbHkg ZG9uJ3QgdGhpbmsgc28uPGJyPg0KPGJyPg0KNS4gVGhlIGJ1bmRsZSBwcm90b2NvbCB3b3JrIHdh cywgSSBnYXRoZXIsIHdlbGwtZnVuZGVkPGJyPg0KJm5ic3A7ICZuYnNwO2J5IGEgbnVtYmVyIG9m IHBhcnRpZXMuPGJyPg0KJm5ic3A7ICZuYnNwO0kgY2FuJ3Qgc2VlIGEgZm9sbG93LW9uIGVmZm9y dCBiZWluZyBhbnl3aGVyZSBuZWFyPGJyPg0KJm5ic3A7ICZuYnNwO2FzIHdlbGwgZnVuZGVkLjxi cj4NCjxicj4NCiZuYnNwOyAmbmJzcDthLiBJIGhhdmUgbm8gaWRlYSBob3cgbXVjaCBtb25leSBO QVNBIGFuZCBDQ1NEUyBoYXZlIHB1dDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGludG8gdGhp cyAtIGZpcnN0IENGRFAsIHRoZW4gYnVuZGxpbmcsIHdoaWNoIG5vdyBoYXM8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyB0byBwcm92aWRlIGEgQ0ZEUC1saWtlIEFQSSB0byB0aGUgdXNlcnMgd2hv IHdlcmUgdG9sZDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoYXQgQ0ZEUCB3YXMgdGhlIGZ1 dHVyZSwgYW5kIExpY2tsaWRlciAoTFRQKS48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBEcmFn Z2luZyBDQ1NEUyBpbnRvIHRoZSBtb2Rlcm4gYWdlIG9mIG5ldHdvcmtpbmc8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyBzZWVtcyB1bmxpa2VseSB0byBldmVyIGhhcHBlbiwgdGhhbmtzIHRvIEND U0RTIGhhdmluZzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGxpdHRsZSBpbiB0aGUgd2F5IG9m IHNhbmUgbGF5ZXJpbmcgb3Igc2VwYXJhdGlvbiBvZjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 IGZ1bmN0aW9uYWxpdHkuPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgSSBkbyBoYXZlIHRoZSBs dXh1cnkgb2Ygbm90IG5lZWRpbmcgdG8gd29yayBvbiBDQ1NEUy48YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyBCdXQgaWYgeW91IHdhbnQgdG8gd29yayBvbiBDQ1NEUyBwcm90b2NvbHMsIENDU0RT IGlzPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhlIHBsYWNlIHRvIGdvLiBUaGUgSUVURiBp cyBub3QgdGhhdCBwbGFjZS48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7Yi4gREFSUEEgcG91cmVk IG1vbmV5IGludG8gRFROIHdvcmsgLSBhdCBsZWFzdCB0d2VudHk8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyBtaWxsaW9uIGRvbGxhcnMsIGZyb20gdGhlIHByZXNzIHJlbGVhc2VzIEkndmUgc2Vl bi48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBJIGhhdmUgbm8gaWRlYSB3aGF0IERBUlBBIGdv dCBvdXQgb2YgaXQgaW4gdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgeWVhcnMgdGhleSB3 ZXJlIGludm9sdmVkOyBoYXZlbid0IHNlZW4gdGhlIHJlcG9ydHMuPGJyPg0KPGJyPg0KTXkgcG9p bnQgaXMsIGFsbCB0aGF0IG1vbmV5IGFuZCBlZmZvcnQgYW5kIG1hbnBvd2VyIGFuZDxicj4NCm92 ZXIgYSBkZWNhZGUgb2Ygd29yayBhbmQgcHJpb3IgZXhwZXJpZW5jZSB3aXRoIENGRFAgYW5kIHR3 bzxicj4NCklSVEYgUkdzLCB3ZSBoYXZlLi4uIFJGQzUwNTAuPGJyPg0KVGhlcmUgaXMgbm93aGVy ZSBuZWFyIGFzIG11Y2ggbW9uZXkgb3IgZWZmb3J0IG9yIG1hbnBvd2VyPGJyPg0KZm9yIGRvaW5n IGEgcmVwbGFjZW1lbnQuPGJyPg0KRXJnbywgaXQgbWlnaHQgYmUgc3VnZ2VzdGVkIHRoYXQgdGhl IHJlcGxhY2VtZW50IGlzIHVubGlrZWx5PGJyPg0KdG8gYmUgYXMgZ29vZCBhcyBSRkM1MDUwLCBv ciBhcyBnb29kIGFzIENGRFA7IGF0IGJlc3QsPGJyPg0KdGhlIHVzdWFsIHN1c3BlY3RzIHdpbGwg aGF2ZSBsZXNzIHRpbWUgYW5kIGZld2VyIHJlc291cmNlczxicj4NCnRvIHJlcGVhdCB0aGVpciBv cmlnaW5hbCBtaXN0YWtlcy48YnI+DQo8YnI+DQpBbmQgdHJhbnNwb3J0IGV4cGVydGlzZSBmcm9t IFRTVldHIHdvdWxkIGJlIG5lZWRlZC48YnI+DQpUU1ZXRyBpcyB1bmZhc2hpb25hYmxlLCBsb3ct dmlzaWJpbGl0eSwgYW5kIGhhcyBldmVuPGJyPg0KcHJldmlvdXNseSBoYWQgdHJvdWJsZSBmaW5k aW5nIEFEcyB3aXRoIHJlbGV2YW50IGV4cGVydGlzZS48YnI+DQpBbmQgVFNWV0cgaGFzIGEgZnVs bCBwbGF0ZSB3aXRoIHdvcmsgb24gaXRzIGV4aXN0aW5nPGJyPg0KcHJvdG9jb2xzOyB0aGVyZSBp cyBub3QgYSBsb3Qgb2YgZXhwZXJ0aXNlLCBhbmQgd2hhdCB0aGVyZTxicj4NCmlzIGlzIHNwcmVh ZCB0aGluLjxicj4NClNvIGFuIFJGQzUwNWJpcyBlZmZvcnQgaXMgdW5saWtlbHkgdG8gZ2V0IHRo ZSBleHBlcnQ8YnI+DQp0ZWNobmljYWwgaW5wdXQgdGhhdCBpdCBzb3JlbHkgbmVlZHMsIGV2ZW4g aWYgYW4gSUVURjxicj4NCndvcmtncm91cCBpcyBzZXQgdXAuIChDQ1NEUyBkb2Vzbid0IGhhdmUg dGhhdCB0cmFuc3BvcnQ8YnI+DQpmb2N1cy4pPGJyPg0KPGJyPg0KSWYsIG9uIHRoZSBvdGhlciBo YW5kLCB5b3UgYmVsaWV2ZSBnb29kIHByb3RvY29sIGRlc2lnbjxicj4NCmNhbiBiZSBkb25lIG1v cmUgY2hlYXBseSBhbmQgbGV2ZXJhZ2UgYWN0dWFsIEludGVybmV0PGJyPg0Kc3RhbmRhcmRzIHRv IGdldCBJbnRlcm5ldCBmdW5jdGlvbmFsaXR5IHdvcmtpbmcgaW48YnI+DQpkaWZmaWN1bHQgbmV0 d29ya3Mgd2hlcmUgdGhlIGZ1bGwgVENQL0lQIHN1aXRlIGhhczxicj4NCnRyb3VibGUsIHlvdXIg b3B0aW9ucyBpbmNsdWRlIFNhcmF0b2dhIGFuZCBIVFRQLURUTiE8YnI+DQo8YSBocmVmPSJodHRw Oi8vc2FyYXRvZ2Euc291cmNlZm9yZ2UubmV0LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9zYXJh dG9nYS5zb3VyY2Vmb3JnZS5uZXQvPC9hPjxicj4NCjxhIGhyZWY9Imh0dHA6Ly9zYXQtbmV0LmNv bS9MLldvb2QvZHRuL2h0dHAtZHRuLmh0bWwiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vc2F0LW5l dC5jb20vTC5Xb29kL2R0bi9odHRwLWR0bi5odG1sPC9hPjxicj4NClRoZXknbGwgdHJ1bHkgZXh0 ZW5kIHRoZSBJbnRlcm5ldCB0byBkaWZmaWN1bHQ8YnI+DQplbnZpcm9ubWVudHMuIFRoZSBidW5k bGUgcHJvdG9jb2wgd29uJ3QuPGJyPg0KPGJyPg0KU28sIHRvIGNvbmNsdWRlLCB0aGVyZSBpcyBu byBqdXN0aWZpY2F0aW9uIGZvciBnb2luZzxicj4NCnN0YW5kYXJkcyB0cmFjay4gVGhlcmUgaXMg bGl0dGxlIGp1c3RpZmljYXRpb24gZm9yIGFuPGJyPg0KSUVURiB3b3JrZ3JvdXAuIFRoZXJlIGlz IG1vcmUgbG9naWMgaW4gcmVjaGFydGVyaW5nIGFuZDxicj4NCnJlcHVycG9zaW5nIHRoZSBJUlRG IERUTlJHLCBidXQgdGhlIHdvcmsgbWF5IGFzIHdlbGw8YnI+DQpiZSBsZWZ0IHRvIENDU0RTIGVu dGlyZWx5Ljxicj4NCjxicj4NClJGQzUwNTBiaXM6IGhhbGYtYXNzZWQsIGhhbGYtYmFrZWQsIHJl aGVhdGVkLjxicj4NCkJ1dCBoZXksIGFzayBtZSB3aGF0IEkgX3JlYWxseV8gdGhpbmsuPGJyPg0K PGJyPg0KTGxveWQgV29vZDxicj4NCjxhIGhyZWY9Imh0dHA6Ly9zYXQtbmV0LmNvbS9MLldvb2Qv ZHRuLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9zYXQtbmV0LmNvbS9MLldvb2QvZHRuLzwvYT48 YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCmR0biBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86ZHRuQGlldGYub3Jn Ij5kdG5AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9kdG4iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2R0bjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPGJyPg0KLS0gPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPlRoZSBwcm9ibGVt IHdpdGggdGhlIHdvcmxkIGlzIHRoYXQgdGhlIGludGVsbGlnZW50IHBlb3BsZSBhcmUgZnVsbCBv ZiBkb3VidHMsDQo8YnI+DQp3aGlsZSB0aGUgc3R1cGlkIG9uZXMgYXJlIGZ1bGwgb2YgY29uZmlk ZW5jZS48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48aT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjxiPi0gQ2hhcmxlcyBCdWtvd3Nr aTwvYj48L2k+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2134F8430051B64F815C691A62D983181B2BF435XCHBLV504nwnosb_-- From nobody Thu Jun 5 10:42:54 2014 Return-Path: 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 5269D1A0123 for ; Thu, 5 Jun 2014 10:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 Vl2DUf-1XCuW for ; Thu, 5 Jun 2014 10:42:50 -0700 (PDT) Received: from mail.jpl.nasa.gov (sentrion1.jpl.nasa.gov [128.149.139.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3C0E1A011F for ; Thu, 5 Jun 2014 10:42:50 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp02.jpl.nasa.gov [128.149.137.149]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s55HgFA2020723 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO) for ; Thu, 5 Jun 2014 10:42:15 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.156]) by ap-ehub-sp02.RES.AD.JPL ([fe80::dd85:7b07:1e36:7e3c%15]) with mapi id 14.03.0174.001; Thu, 5 Jun 2014 10:42:44 -0700 From: "Burleigh, Scott C (312G)" To: "dtn@ietf.org" Thread-Topic: [dtn] Proposed Working Group Charter Suggestions Thread-Index: AQFSocO/D9uhW69j0yAuOdgV0znNWQHFMXAmASCcbEQBbA2hJAHfUcS+AdrD57cB7vfjCQJo1+2NAbk5oBoBhgwXi5vfSS4wgACCL4D//4saYIAAi8sA//+MW8A= Date: Thu, 5 Jun 2014 17:42:43 +0000 Message-ID: References: <2134F8430051B64F815C691A62D983181B2BD2DE@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2BD423@XCH-BLV-504.nw.nos.boeing.com> <538E35F6.2010702@cs.tcd.ie> <538F3D53.5060305@per.reau.lt> <538FF2F8.5070605@mti-systems.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.26] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/zooe_mYnEIPoWPKc95lz50LstoE Subject: Re: [dtn] Proposed Working Group Charter Suggestions X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 17:42:52 -0000 Okay, fair enough; in a properly configured network it shouldn't be needed,= but providing a defense against network misconfiguration is a good idea. = I'm fine with adding a hop count block. Scott -----Original Message----- From: Ivancic, William D. (GRC-RHN0) [mailto:william.d.ivancic@nasa.gov]=20 Sent: Thursday, June 05, 2014 10:34 AM To: Burleigh, Scott C (312G); dtn@ietf.org Subject: Re: [dtn] Proposed Working Group Charter Suggestions In Line >Will, sure, hop counts are a great way to break routing loops, but (a)=20 >it has been suggested that routing loops are not always a bad thing in=20 >DTN (I haven't yet heard the fully-worked out argument for this, so I=20 >can't engage on this point), I've heard that, but it was more of an intentional route back once because = you may now have a better path or as a temporary storage environment. > and (b) I think routing loops are the least of your problems in a DTN Not really. It is the unintentional misconfiguration that I worry about. CGR is certainly a candidate if the entire system doesn't get updated corre= ctly. But, just plain static routes is the easiest place to demonstrate th= is. Create a DTN static route between two systems where the both think the= next hop route is the other system. A wants to forward bundles for C to B= and B wants to forward bundles for C to A. Now create a bundle destined t= o C with a lifetime of 300 years and leave a note for three generations fro= m now to see if it is still bouncing between systems. This is really bad for wireless systems. You may lock yourself out. And, depending on how the code is implemented, this may happen for a bundle= with a 30 second lifetime depending on when and where the implementation c= hecks for expired bundles. Believe me. I've seen similar with static security tunnels and such. Fortunately IP hop count will kill the packet. I've been very careful and triple checked systems and then still screwed up= . Hop count is a relief valve for when something unintentionally gets mis= configured. >-- there are plenty of simpler ways to screw up performance in these=20 >weird environments. I'm sure you are correct. Some things are difficult to anticipate and fore= see. Others are obvious. The ability for a bundle stuck in a route loop = to self-terminate should be one. Will From nobody Thu Jun 5 11:02:34 2014 Return-Path: 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 BCEE81A017F; Thu, 5 Jun 2014 11:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, 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 aSKVI-vSA4Bu; Thu, 5 Jun 2014 11:02:20 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 784A81A0144; Thu, 5 Jun 2014 11:02:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s55I25Ah018739; Thu, 5 Jun 2014 11:02:05 -0700 Received: from XCH-PHX-313.sw.nos.boeing.com (xch-phx-313.sw.nos.boeing.com [130.247.25.175]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s55I22tv018718 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 5 Jun 2014 11:02:02 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.105]) by XCH-PHX-313.sw.nos.boeing.com ([169.254.13.83]) with mapi id 14.03.0181.006; Thu, 5 Jun 2014 11:02:01 -0700 From: "Templin, Fred L" To: "l.wood@surrey.ac.uk" , "spencerdawkins.ietf@gmail.com" , "mls.ietf@gmail.com" Thread-Topic: [dtn] DTN BoF Proposal for IETF90 Thread-Index: Ac+AQa9Fez/CplZaSwyaLFpzb8tj0wAiVZ0A///Hp/D//5OnYA== Date: Thu, 5 Jun 2014 18:02:00 +0000 Message-ID: <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com>, <1401967219583.26821@surrey.ac.uk> In-Reply-To: <1401967219583.26821@surrey.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.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/2z9bWFL-L0fJszeq7Er-EEcsfZ4 Cc: "iesg@ietf.org" , "dtn@ietf.org" Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 18:02:29 -0000 Hi Lloyd, Wading through your points, you seem to be concerned that standardizing the Bundle Protocol in the IETF will somehow block other approaches from going forward in the future, but that would not be consistent with my understanding of the way the IETF operates. There are many examples where multiple solutions for roughly the same problem space have gone forward to standards track and have all found widespread application - sometimes based on the best-fit solution for the particular problem and sometimes based on market forces. The purpose of having a standard is so that vendors can independently create interoperable implementations, and the IETF is the correct forum for developing internetworking standards. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of l.wood@surrey.ac.uk > Sent: Thursday, June 05, 2014 4:20 AM > To: spencerdawkins.ietf@gmail.com; mls.ietf@gmail.com > Cc: iesg@ietf.org; dtn@ietf.org > Subject: Re: [dtn] DTN BoF Proposal for IETF90 >=20 > As previously expressed on DTNRG, I have a number of concerns about > this proposed BOF to create an IETF DTN WG to do work on the > RFC5050 bundle protocol, produced in the IRTF DTNRG, and create > an RFC5050bis. I'll go through those concerns one by one: >=20 >=20 > 1. I don't see how going standards track can be justified, because: >=20 > a. CCSDS is already working on the bundle protocol as one of their > blue book standards, based on RFC5050, and any RFC5050bis > would presumably also be adopted and then modified to make > a CCSDS standard. > It's rather like CCSDS restandardizing TCP/IP as SCPS, back > in the 1990s. That SCPS standardization wasn't used much > either, not least because CCSDS 'improved' on TCP/IP > and went incompatible quite quickly. The same will happen > with the CCSDS bundle protocol, and in adopting RFC5050 > CCSDS has reserved the right to make changes - things like > Delay Tolerant Payload Conditioning (DTPC) are but the start. > There's an example of bundle protocol work not requiring > the IETF. Work on altering and extending the bundle protocol > is already ongoing in CCSDS. > Setting up an IETF workgroup to work in parallel would mean > that a CCSDS liaison would be required, to pay attention > to their concerns as they try and convince their member space > agencies to use the bundle protocol, and to prevent their spec > from diverging (further) from the IETF spec. Really, the work > is simply more easily done in CCSDS, given that CCSDS is > pretty much the only customer for bundle protocol, because > NASA has mandated bundle protocol use from on high. > NASA leads CCSDS, NASA Jet Propulsion Lab leads CCSDS design > for NASA's Space Communications and Navigation people. > JPL is really the primary customer for and user of bundle > protocol, responsible for promoting its use by other space > agencies - never an easy task, even with good technologies. >=20 > b. The IETF produces Internet standards. The bundle protocol > has little bearing on or interaction with Internet standards; > it's arguably a way to interoperate with the Internet while > protecting CCSDS from incursion of the Internet, by layering > over both Internet and CCSDS. Each to their own domains. > Using TCP as the most common bundle convergence layer (described > in a draft now seven years old) does not make the bundle protocol > an internet standard. If it did, then CCSDS's Space Link > Extension (basically a TCP tunnel carrying CCSDS frames, with > much added complexity) would also be a candidate for an > IETF internet standard. > But, again, that work is best done in CCSDS, where there > is interest in having it done and there are users. (Some > of those users may even be willing users.) >=20 > c. The bundle protocol is not mature. Deficiencies have been > identified, drafts have been written in DTNRG over the years, > there was little interest, the drafts expired, the bundle > protocol was never improved. And that's just from demonstrations; > there has not been extended operational use to my knowledge. > Attempting to fix the bundle protocol AND push it through as > standards track at the same time seems unwarranted. > It may be politically motivated, but it is > not technically or procedurally justifiable. > There isn't the userbase or demand needed for the bundle > protocol to go standards track, and if the IETF did go > standards track, CCSDS would 'optimize' that standard into > its own standard, just as was done with SCPS, meaning that > the IETF would spend a lot of time working on something with > no benefit to the IETF community or userbase. Extending > the Internet protocols to the DTN network problem space > adds value to the internet protocols. A separate protocol > does not. > Who would benefit, outside the CCSDS community? And CCSDS > is their own standards org - an ISO subgroup - to do work > for that CCSDS community. >=20 >=20 > 2. I don't see why this needs to be done in an IETF WG, because: >=20 > a. going standards track isn't justifiable - see 1. >=20 > b. There's already the IRTF DTNRG, which could clean up its > own work, but ,after many years and some failed drafts, > has not. > Declaring success and saying it is now time to create a > WG based on DTNRG's achievements is not convincing, > because those achievements are not impressive. > (Disclaimer of interest: I authored 'A bundle of problems' > and have spent considerable years trying to explain and > address problems with the bundle protocol, with little > success, after getting it tested in space before NASA's > EXPOXI/Deep Impact tests took place. > Fred Templin's problem statement drafts for this putative > IETF BOF calls on that work.) > RFC5050bis would make more sense as a DTNRG > effort, though it would be time for a changing of the > guard and chairs in DTNRG to infuse some new blood and > technical judgement - or we're in for another five years > of what-does-the-end-to-end-principle-really-mean and > what-about-clocks and rehashing the same old arguments. > Really, DTNRG needs to get its act together, both > organizationally and technically. >=20 > c. There's already CCSDS, which has adopted the DTNRG output, > after pushing for the formation of an Interplanetary > Internet RG in the first place. >=20 > So either CCSDS or DTNRG can do RFC5050 revision work. If > it's to be an RFC, experimental or informational, a revitalised > rechartered DTNRG can do it. > It doesn't need to be an IETF workgroup. It certainly > shouldn't go standards track. >=20 >=20 > 3. The philosophically shaky basis for the bundle protocol: >=20 > a. Delay-tolerant networking is not disruption-tolerant > networking. Space delays of light-minutes with scheduled > contacts are not the same as intermittent ad-hoc > manet-style communications. Different requirements, > different buffering and storage, different conditions, > different handling of fragmentation, etc. >=20 > b. The bundle protocol is not DTN. DTN is the scenario, > in which other approaches (the related CFDP, Haggle, > the MANET and vehicular DTNs efforts that DTN subsumed > and rebranded, etc.) exist. > The bundle protocol is intended to be used in a DTN > scenario. Branding the bundle protocol as DTN has > put back non-bundle DTN research a number of years. > Branding a group only working on the bundle protocol > as 'DTN' is misleading at best. >=20 > c. Extending the bundle protocol from the original > Interplanetary Internet problem (which had its own > IRTF RG which led into a set bundle agenda for > DTNRG) to cover everything else as well simply hasn't > worked very well, because the scenarios and use cases > are different. We design for use cases. To be too > generalised is to engineer for nothing. >=20 > d. Ignoring the ramifications of the end-to-end principle, > which are often more subtle than people seem to think > they are. The bundle protocol's custody transfer > procedure is a good example of this failing. >=20 > e. The bundle protocol is intended for use in the most > difficult noisy disrupted networking conditions we know, > and it can't even sanity check its own headers against > errors. (But hey, it now has a security protocol that > _almost_ does that! But which is too complicated, and > would need to be redone.) > It's intended for the harshest environments we know, > but needs reliable synchronized clocks running at > steady temperatures! > It's intended for embedded systems, but the design > is huge and complex! (CFDP has the same problem; > there's a reason implementers went for a "CFDP lite," > and Saratoga exists just because CFDP wasn't performing. > Would RFC5050bis be "bundling lite"?) > There are many 'that makes no sense' moments - normally > more immediately visible to outsiders not steeped in > the dogma, politics, and history of DTNRG and CCSDS. >=20 > f. The assumption that a full security suite is desirable > and necessary at all times. This has derailed DTNRG, > as emphasis was placed on security work above all > else, rather than working to the scenario. To be fair > to the security-focused chairs, the charter that > established DTNRG from the interplanetary internet > research group called out security heavily, and they > ran with that mandate. But the focus has decreased > work on non-security matters, which is to say, > everything else. >=20 > RFC5050bis might address the latter three problems, but > the first three are intrinsically unsolvable; any solution > will be unsatisfactory. Perhaps not as unsatisfactory as > RFC5050, but unsatisfactory nonetheless. >=20 > The real philosophical problem here is the political dogma > that, whatever the problem, the bundle protocol is The > One True Solution. >=20 >=20 > 4. The draft BOF charter is bundle-centric. Which is to say, > that it's not awfully relevant to internet standards. > Disclaimer of interest: we've worked on Saratoga and > HTTP-DTN, which have current internet-drafts, and are > squarely in the DTN problem space. > Whenever someone talks about multiple convergence > layers for the bundle protocol - there's more than for BEEP, > which just has TCP, but there aren't many - Saratoga may > be mentioned. But we've found that carrying bundles doesn't > benefit Saratoga - tested it in space, didn't see the > advantages. Saratoga does leverage a few Internet things - > UDP, UDP-Lite, multicast. It does a few scaling things that > nothing else I've seen does (described in our 2011 TSVAREA > presentation to IETF 88 in November.) And it's based on > a decade of operational use in the problem domain. > HTTP-DTN leverages the HTTP suite and MIME, and comes up > whenever wouldn't-it-be-nice-to-try-HTTP-for-DTN discussion > takes place. > (I suspect that all of Stephen Farrell's N4C work could > have been done over hop-by-hop HTTP a la HTTP-DTN, and > would have worked just as well if not better. After all, > it used TCP.) > These and other efforts exist in a gap between DTNRG, which > is aware of the problem space, but thinks the bundle > protocol is the solution despite mounting evidence to the > contrary, and TSVWG, where the few actual transport > experts live, without clout, or funding, or spare time. > Those efforts are interesting enough to have implementations > kicking around too. > And yet, the focus of this putative workgroup and BOF is > solely on bundling, and not on evaluating these or other > things that might exist in the problem space. There > must be other things out there that would be of interest > to such a DTN workgroup. What is proposed is not a DTN > workgroup. The charter is basically a bundle workgroup. > Can an interest in bundling and solely bundling (outside > CCSDS, which is driving the push to use the bundle protocol) > be justified for an IETF workgroup? I really don't think so. >=20 > 5. The bundle protocol work was, I gather, well-funded > by a number of parties. > I can't see a follow-on effort being anywhere near > as well funded. >=20 > a. I have no idea how much money NASA and CCSDS have put > into this - first CFDP, then bundling, which now has > to provide a CFDP-like API to the users who were told > that CFDP was the future, and Licklider (LTP). > Dragging CCSDS into the modern age of networking > seems unlikely to ever happen, thanks to CCSDS having > little in the way of sane layering or separation of > functionality. > I do have the luxury of not needing to work on CCSDS. > But if you want to work on CCSDS protocols, CCSDS is > the place to go. The IETF is not that place. >=20 > b. DARPA poured money into DTN work - at least twenty > million dollars, from the press releases I've seen. > I have no idea what DARPA got out of it in the > years they were involved; haven't seen the reports. >=20 > My point is, all that money and effort and manpower and > over a decade of work and prior experience with CFDP and two > IRTF RGs, we have... RFC5050. > There is nowhere near as much money or effort or manpower > for doing a replacement. > Ergo, it might be suggested that the replacement is unlikely > to be as good as RFC5050, or as good as CFDP; at best, > the usual suspects will have less time and fewer resources > to repeat their original mistakes. >=20 > And transport expertise from TSVWG would be needed. > TSVWG is unfashionable, low-visibility, and has even > previously had trouble finding ADs with relevant expertise. > And TSVWG has a full plate with work on its existing > protocols; there is not a lot of expertise, and what there > is is spread thin. > So an RFC505bis effort is unlikely to get the expert > technical input that it sorely needs, even if an IETF > workgroup is set up. (CCSDS doesn't have that transport > focus.) >=20 > If, on the other hand, you believe good protocol design > can be done more cheaply and leverage actual Internet > standards to get Internet functionality working in > difficult networks where the full TCP/IP suite has > trouble, your options include Saratoga and HTTP-DTN! > http://saratoga.sourceforge.net/ > http://sat-net.com/L.Wood/dtn/http-dtn.html > They'll truly extend the Internet to difficult > environments. The bundle protocol won't. >=20 > So, to conclude, there is no justification for going > standards track. There is little justification for an > IETF workgroup. There is more logic in rechartering and > repurposing the IRTF DTNRG, but the work may as well > be left to CCSDS entirely. >=20 > RFC5050bis: half-assed, half-baked, reheated. > But hey, ask me what I _really_ think. >=20 > Lloyd Wood > http://sat-net.com/L.Wood/dtn/ >=20 > _______________________________________________ > dtn mailing list > dtn@ietf.org > https://www.ietf.org/mailman/listinfo/dtn From nobody Thu Jun 5 11:24:11 2014 Return-Path: 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 3BC091A02F9; Thu, 5 Jun 2014 11:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, 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 8uPnSIc1fUHI; Thu, 5 Jun 2014 11:23:59 -0700 (PDT) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC3671A024D; Thu, 5 Jun 2014 11:23:58 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id ik5so1606070vcb.5 for ; Thu, 05 Jun 2014 11:23:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=x2ALsu7sRbJBZoU6jc6NWdyktH72ZhbWE5mm99FR/mI=; b=G1OsHFVUA0XvzP7ViujvoJjZgHciQnhozYuG9xuxHUU2dLKrMeZClA3RzBHGvBTW7p 98lDBdQk03cONfqMcH874eBZcHiBnZZ4w6TZKZMZ+i0J09m1zWfwf2z+AMx9TUIF90x/ id1rxErZz0hJXb4diP4g97+VHdAq431JyBp7QwQEDLdqf/GCywZRoGDzc63bQ02d0kQM ox3/EFTtYYSeT2fteSSJDM3yLkugWuiuICA16WJYgG9TyyeXJ7wYcoiColNd0jxaZpOy AJs6MrGi5pPpvr+4fa0XAkcEwL1t/MWlvQPi7BOodf8kpj6CJL7KYR13E7Jz7jzHaxCz y9sg== MIME-Version: 1.0 X-Received: by 10.220.137.145 with SMTP id w17mr4513685vct.47.1401992631819; Thu, 05 Jun 2014 11:23:51 -0700 (PDT) Received: by 10.52.99.100 with HTTP; Thu, 5 Jun 2014 11:23:51 -0700 (PDT) In-Reply-To: <2134F8430051B64F815C691A62D983181B2BF435@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> <1401967219583.26821@surrey.ac.uk> <2134F8430051B64F815C691A62D983181B2BF435@XCH-BLV-504.nw.nos.boeing.com> Date: Thu, 5 Jun 2014 14:23:51 -0400 Message-ID: From: Eric Travis To: "Templin, Fred L" Content-Type: multipart/alternative; boundary=047d7b343394cc244004fb1ad891 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/0AnCsV81gX6HUij1FtK-VLVa2fI Cc: "iesg@ietf.org" , "mls.ietf@gmail.com" , "spencerdawkins.ietf@gmail.com" , "l.wood@surrey.ac.uk" , "dtn@ietf.org" Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 18:24:06 -0000 --047d7b343394cc244004fb1ad891 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Fred, While I wasn't intending to advocate either way on the items: To point 1), advancement of work items in the IETF is usually based on > =E2=80=9Crough consensus > > and running code=E2=80=9D and there is plenty of interoperable running co= de that > implements > > RFC5050 and its related specifications =E2=80=93 much more than most IETF > activities are based on. > My "points worthy of discussion/debate throughout the BoF process" seems to be compatible with your > As to =E2=80=9Crough consensus=E2=80=9D, holding a BoF is the first step = in determining > that. > I'd contend that the *DTNRG* was the start of that discussion. The *BoF* is a continuation of a 7+ year community discussion. There is an experimental RFC that has achieved interoperability between multiple independent implementations. That, however, isn't necessarily a referendum on the maturity of the protocol(s) themselves. For those entities whose needs are satisfied with RFC-5050, a standards-track document is not necessary for deployment. Actually, a standards-track document is never *really* necessary. There are many middleware/application level "things" deployed that are not based on IETF standards. The presumption of the BoF seems to be that RFC-5050 is NOT "there yet". So, the question is how close to maturity is close enough to go into a standards trajectory. >From the discussions on the list, there has been a lot of very promising dialog of the nature of "Yeah, it would be useful to *explore* Foo and/or Bar", from some people that - frankly - pleasantly surprised me. This leads to the question - has the solution space been adequately explored to have confidence that the result is a mature (NOT perfect)? If not, will the WG be able to take it further than the RG was capable (and why is that true)? That's a question, not a statement on my part. To point 2), again the BoF will provide a useful measurement of interest. I think the level of interest is relatively high within the DTNRG - and will likely be so for a DTN WG. The question really is if/how will that translate into measurable progress (fixing the - some long acknowledged - nits in the protocol specification. The original idea of a RFC5050.Bis was floated two (three?) years ago as part of the most recent Google meeting. It failed to gain traction, despite what seemed to be a fair amount of community interest. Is the lack of movement within the DTNRG simply because of the (lack of) path to a standards track RFC? The question for the BoF is, what caused the evolutionary pause, and how will a WG prevent it from stalling again. Just to be clear, I'm in favor of a BoF and currently undecided/agnostic on support of a WG, these types of discussions would be useful to me (at the very least). Regards, Eric eric.dot.travis@gmail.com On Thu, Jun 5, 2014 at 1:38 PM, Templin, Fred L wrote: > Hi Eric, > > > > To point 1), advancement of work items in the IETF is usually based on > =E2=80=9Crough consensus > > and running code=E2=80=9D and there is plenty of interoperable running co= de that > implements > > RFC5050 and its related specifications =E2=80=93 much more than most IETF > activities are based on. > > As to =E2=80=9Crough consensus=E2=80=9D, holding a BoF is the first step = in determining > that. > > > > To point 2), again the BoF will provide a useful measurement of interest. > > > > Thanks =E2=80=93 Fred > > fred.l.templin@boeing.com > > > > > > *From:* dtn [mailto:dtn-bounces@ietf.org] *On Behalf Of *Eric Travis > *Sent:* Thursday, June 05, 2014 9:29 AM > *To:* l.wood@surrey.ac.uk > *Cc:* mls.ietf@gmail.com; spencerdawkins.ietf@gmail.com; dtn@ietf.org; > iesg@ietf.org > > *Subject:* Re: [dtn] DTN BoF Proposal for IETF90 > > > > Lloyd, > > > Embedded in your manifesto are two points worthy of discussion/debate > throughout the BoF process: > > 1) Is the proposed (base) solution - with "minimal" fixes - of sufficient > maturity for standardization within the IETF? > > 2) The existing IRTF DTNRG has not been able to harness sufficient > interest/resources to advance the state of RFC-5050, how will a new IETF = WG > change the dynamic? > > As for the rest of it, well... > > RFC5050bis: half-assed, half-baked, reheated. > But hey, ask me what I _really_ think. > > > > Let the rational, well-reasoned discussion begin... > > Eric > > eric.dot.travis@gmail.com > > > > On Thu, Jun 5, 2014 at 7:20 AM, wrote: > > As previously expressed on DTNRG, I have a number of concerns about > this proposed BOF to create an IETF DTN WG to do work on the > RFC5050 bundle protocol, produced in the IRTF DTNRG, and create > an RFC5050bis. I'll go through those concerns one by one: > > > 1. I don't see how going standards track can be justified, because: > > a. CCSDS is already working on the bundle protocol as one of their > blue book standards, based on RFC5050, and any RFC5050bis > would presumably also be adopted and then modified to make > a CCSDS standard. > It's rather like CCSDS restandardizing TCP/IP as SCPS, back > in the 1990s. That SCPS standardization wasn't used much > either, not least because CCSDS 'improved' on TCP/IP > and went incompatible quite quickly. The same will happen > with the CCSDS bundle protocol, and in adopting RFC5050 > CCSDS has reserved the right to make changes - things like > Delay Tolerant Payload Conditioning (DTPC) are but the start. > There's an example of bundle protocol work not requiring > the IETF. Work on altering and extending the bundle protocol > is already ongoing in CCSDS. > Setting up an IETF workgroup to work in parallel would mean > that a CCSDS liaison would be required, to pay attention > to their concerns as they try and convince their member space > agencies to use the bundle protocol, and to prevent their spec > from diverging (further) from the IETF spec. Really, the work > is simply more easily done in CCSDS, given that CCSDS is > pretty much the only customer for bundle protocol, because > NASA has mandated bundle protocol use from on high. > NASA leads CCSDS, NASA Jet Propulsion Lab leads CCSDS design > for NASA's Space Communications and Navigation people. > JPL is really the primary customer for and user of bundle > protocol, responsible for promoting its use by other space > agencies - never an easy task, even with good technologies. > > b. The IETF produces Internet standards. The bundle protocol > has little bearing on or interaction with Internet standards; > it's arguably a way to interoperate with the Internet while > protecting CCSDS from incursion of the Internet, by layering > over both Internet and CCSDS. Each to their own domains. > Using TCP as the most common bundle convergence layer (described > in a draft now seven years old) does not make the bundle protocol > an internet standard. If it did, then CCSDS's Space Link > Extension (basically a TCP tunnel carrying CCSDS frames, with > much added complexity) would also be a candidate for an > IETF internet standard. > But, again, that work is best done in CCSDS, where there > is interest in having it done and there are users. (Some > of those users may even be willing users.) > > c. The bundle protocol is not mature. Deficiencies have been > identified, drafts have been written in DTNRG over the years, > there was little interest, the drafts expired, the bundle > protocol was never improved. And that's just from demonstrations; > there has not been extended operational use to my knowledge. > Attempting to fix the bundle protocol AND push it through as > standards track at the same time seems unwarranted. > It may be politically motivated, but it is > not technically or procedurally justifiable. > There isn't the userbase or demand needed for the bundle > protocol to go standards track, and if the IETF did go > standards track, CCSDS would 'optimize' that standard into > its own standard, just as was done with SCPS, meaning that > the IETF would spend a lot of time working on something with > no benefit to the IETF community or userbase. Extending > the Internet protocols to the DTN network problem space > adds value to the internet protocols. A separate protocol > does not. > Who would benefit, outside the CCSDS community? And CCSDS > is their own standards org - an ISO subgroup - to do work > for that CCSDS community. > > > 2. I don't see why this needs to be done in an IETF WG, because: > > a. going standards track isn't justifiable - see 1. > > b. There's already the IRTF DTNRG, which could clean up its > own work, but ,after many years and some failed drafts, > has not. > Declaring success and saying it is now time to create a > WG based on DTNRG's achievements is not convincing, > because those achievements are not impressive. > (Disclaimer of interest: I authored 'A bundle of problems' > and have spent considerable years trying to explain and > address problems with the bundle protocol, with little > success, after getting it tested in space before NASA's > EXPOXI/Deep Impact tests took place. > Fred Templin's problem statement drafts for this putative > IETF BOF calls on that work.) > RFC5050bis would make more sense as a DTNRG > effort, though it would be time for a changing of the > guard and chairs in DTNRG to infuse some new blood and > technical judgement - or we're in for another five years > of what-does-the-end-to-end-principle-really-mean and > what-about-clocks and rehashing the same old arguments. > Really, DTNRG needs to get its act together, both > organizationally and technically. > > c. There's already CCSDS, which has adopted the DTNRG output, > after pushing for the formation of an Interplanetary > Internet RG in the first place. > > So either CCSDS or DTNRG can do RFC5050 revision work. If > it's to be an RFC, experimental or informational, a revitalised > rechartered DTNRG can do it. > It doesn't need to be an IETF workgroup. It certainly > shouldn't go standards track. > > > 3. The philosophically shaky basis for the bundle protocol: > > a. Delay-tolerant networking is not disruption-tolerant > networking. Space delays of light-minutes with scheduled > contacts are not the same as intermittent ad-hoc > manet-style communications. Different requirements, > different buffering and storage, different conditions, > different handling of fragmentation, etc. > > b. The bundle protocol is not DTN. DTN is the scenario, > in which other approaches (the related CFDP, Haggle, > the MANET and vehicular DTNs efforts that DTN subsumed > and rebranded, etc.) exist. > The bundle protocol is intended to be used in a DTN > scenario. Branding the bundle protocol as DTN has > put back non-bundle DTN research a number of years. > Branding a group only working on the bundle protocol > as 'DTN' is misleading at best. > > c. Extending the bundle protocol from the original > Interplanetary Internet problem (which had its own > IRTF RG which led into a set bundle agenda for > DTNRG) to cover everything else as well simply hasn't > worked very well, because the scenarios and use cases > are different. We design for use cases. To be too > generalised is to engineer for nothing. > > d. Ignoring the ramifications of the end-to-end principle, > which are often more subtle than people seem to think > they are. The bundle protocol's custody transfer > procedure is a good example of this failing. > > e. The bundle protocol is intended for use in the most > difficult noisy disrupted networking conditions we know, > and it can't even sanity check its own headers against > errors. (But hey, it now has a security protocol that > _almost_ does that! But which is too complicated, and > would need to be redone.) > It's intended for the harshest environments we know, > but needs reliable synchronized clocks running at > steady temperatures! > It's intended for embedded systems, but the design > is huge and complex! (CFDP has the same problem; > there's a reason implementers went for a "CFDP lite," > and Saratoga exists just because CFDP wasn't performing. > Would RFC5050bis be "bundling lite"?) > There are many 'that makes no sense' moments - normally > more immediately visible to outsiders not steeped in > the dogma, politics, and history of DTNRG and CCSDS. > > f. The assumption that a full security suite is desirable > and necessary at all times. This has derailed DTNRG, > as emphasis was placed on security work above all > else, rather than working to the scenario. To be fair > to the security-focused chairs, the charter that > established DTNRG from the interplanetary internet > research group called out security heavily, and they > ran with that mandate. But the focus has decreased > work on non-security matters, which is to say, > everything else. > > RFC5050bis might address the latter three problems, but > the first three are intrinsically unsolvable; any solution > will be unsatisfactory. Perhaps not as unsatisfactory as > RFC5050, but unsatisfactory nonetheless. > > The real philosophical problem here is the political dogma > that, whatever the problem, the bundle protocol is The > One True Solution. > > > 4. The draft BOF charter is bundle-centric. Which is to say, > that it's not awfully relevant to internet standards. > Disclaimer of interest: we've worked on Saratoga and > HTTP-DTN, which have current internet-drafts, and are > squarely in the DTN problem space. > Whenever someone talks about multiple convergence > layers for the bundle protocol - there's more than for BEEP, > which just has TCP, but there aren't many - Saratoga may > be mentioned. But we've found that carrying bundles doesn't > benefit Saratoga - tested it in space, didn't see the > advantages. Saratoga does leverage a few Internet things - > UDP, UDP-Lite, multicast. It does a few scaling things that > nothing else I've seen does (described in our 2011 TSVAREA > presentation to IETF 88 in November.) And it's based on > a decade of operational use in the problem domain. > HTTP-DTN leverages the HTTP suite and MIME, and comes up > whenever wouldn't-it-be-nice-to-try-HTTP-for-DTN discussion > takes place. > (I suspect that all of Stephen Farrell's N4C work could > have been done over hop-by-hop HTTP a la HTTP-DTN, and > would have worked just as well if not better. After all, > it used TCP.) > These and other efforts exist in a gap between DTNRG, which > is aware of the problem space, but thinks the bundle > protocol is the solution despite mounting evidence to the > contrary, and TSVWG, where the few actual transport > experts live, without clout, or funding, or spare time. > Those efforts are interesting enough to have implementations > kicking around too. > And yet, the focus of this putative workgroup and BOF is > solely on bundling, and not on evaluating these or other > things that might exist in the problem space. There > must be other things out there that would be of interest > to such a DTN workgroup. What is proposed is not a DTN > workgroup. The charter is basically a bundle workgroup. > Can an interest in bundling and solely bundling (outside > CCSDS, which is driving the push to use the bundle protocol) > be justified for an IETF workgroup? I really don't think so. > > 5. The bundle protocol work was, I gather, well-funded > by a number of parties. > I can't see a follow-on effort being anywhere near > as well funded. > > a. I have no idea how much money NASA and CCSDS have put > into this - first CFDP, then bundling, which now has > to provide a CFDP-like API to the users who were told > that CFDP was the future, and Licklider (LTP). > Dragging CCSDS into the modern age of networking > seems unlikely to ever happen, thanks to CCSDS having > little in the way of sane layering or separation of > functionality. > I do have the luxury of not needing to work on CCSDS. > But if you want to work on CCSDS protocols, CCSDS is > the place to go. The IETF is not that place. > > b. DARPA poured money into DTN work - at least twenty > million dollars, from the press releases I've seen. > I have no idea what DARPA got out of it in the > years they were involved; haven't seen the reports. > > My point is, all that money and effort and manpower and > over a decade of work and prior experience with CFDP and two > IRTF RGs, we have... RFC5050. > There is nowhere near as much money or effort or manpower > for doing a replacement. > Ergo, it might be suggested that the replacement is unlikely > to be as good as RFC5050, or as good as CFDP; at best, > the usual suspects will have less time and fewer resources > to repeat their original mistakes. > > And transport expertise from TSVWG would be needed. > TSVWG is unfashionable, low-visibility, and has even > previously had trouble finding ADs with relevant expertise. > And TSVWG has a full plate with work on its existing > protocols; there is not a lot of expertise, and what there > is is spread thin. > So an RFC505bis effort is unlikely to get the expert > technical input that it sorely needs, even if an IETF > workgroup is set up. (CCSDS doesn't have that transport > focus.) > > If, on the other hand, you believe good protocol design > can be done more cheaply and leverage actual Internet > standards to get Internet functionality working in > difficult networks where the full TCP/IP suite has > trouble, your options include Saratoga and HTTP-DTN! > http://saratoga.sourceforge.net/ > http://sat-net.com/L.Wood/dtn/http-dtn.html > They'll truly extend the Internet to difficult > environments. The bundle protocol won't. > > So, to conclude, there is no justification for going > standards track. There is little justification for an > IETF workgroup. There is more logic in rechartering and > repurposing the IRTF DTNRG, but the work may as well > be left to CCSDS entirely. > > RFC5050bis: half-assed, half-baked, reheated. > But hey, ask me what I _really_ think. > > Lloyd Wood > http://sat-net.com/L.Wood/dtn/ > > _______________________________________________ > dtn mailing list > dtn@ietf.org > https://www.ietf.org/mailman/listinfo/dtn > > > > > -- > > > *The problem with the world is that the intelligent people are full of > doubts, while the stupid ones are full of confidence.* > > * > - Charles Bukowski* > --=20 *The problem with the world is that the intelligent people are full of doubts, while the stupid ones are full of confidence.* * - Charles Bukowski* --047d7b343394cc244004fb1ad891 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Fred,

While I wasn't intending to= advocate either way on the items:


To point 1), advancement of work i= tems in the IETF is usually based on =E2=80=9Crough consensus

and running code=E2= =80=9D and there is plenty of interoperable running code that implements

RFC5050 and its rela= ted specifications =E2=80=93 much more than most IETF activities are based = on.


My=C2=A0 "points worthy of= discussion/debate throughout the BoF process" seems to be compatible = with your
As to =E2=80=9Crough consensus=E2=80=9D, ho= lding a BoF is the first step in determining that.
<= div>
I'd contend that the *DTNRG* was the start of that discussion.= =C2=A0 The *BoF* is a continuation of a 7+ year community discussion.


There is an experimental RFC that has achieve= d interoperability between multiple independent implementations.
<= div>That, however, isn't necessarily a referendum on the maturity of th= e protocol(s) themselves.=C2=A0

For those entities whose needs are satisfied with RFC-5050, = a standards-track document is not necessary for deployment.
A= ctually, a standards-track document is never *really* necessary.=C2=A0 Ther= e are many middleware/application level "things" deployed
that are not based on IETF standards.=C2=A0 The presumption of the BoF seem= s to be that RFC-5050 is NOT "there yet".=C2=A0 So, the
questi= on is how close to maturity is close enough to go into a standards trajecto= ry.

From the discussions on the list, there has been a lot of ve= ry promising dialog of the nature of
"Yeah, it would be useful to = *explore* Foo and/or Bar", from some people that - frankly - pleasantl= y surprised me.=C2=A0

This leads to the question - has the solution space been ade= quately explored to have confidence that the result is
a matu= re (NOT perfect)?=C2=A0 If not, will the WG be able to take it further than= the RG was capable (and why is that true)?

That's a question, not a statement on my part.


=C2=A0To point 2), again the BoF will provide a use= ful measurement of interest.

I think the level of interest is relatively high within= the DTNRG - and will likely be so for a DTN WG.=C2=A0 The question
really is if/how will that translate into measurable progress (fixin= g the - some long acknowledged - nits in the protocol
specification.

The original idea of a RFC5050.= Bis was floated two (three?) years ago as part of the most recent Google me= eting.=C2=A0 It failed to gain
traction, despite what seemed to be a fai= r amount of community interest.

Is the lack of movement within the DTNRG simply because of t= he (lack of) path to a standards track RFC?

The question = for the BoF is, what caused the evolutionary pause, and how will a WG preve= nt it from stalling again.



Just to be clear,=C2=A0 I'm in favor of a BoF an= d currently undecided/agnostic on support of a WG, these types of discussio= ns would
be useful to me (at the very least).

Regards= ,

Eric


On Thu, Jun 5, 2014 at 1:38 PM, T= emplin, Fred L <Fred.L.Templin@boeing.com> wrote:

Hi Eric,

=C2=A0

To point 1), advancement = of work items in the IETF is usually based on =E2=80=9Crough consensus

and running code=E2=80=9D= and there is plenty of interoperable running code that implements

RFC5050 and its related s= pecifications =E2=80=93 much more than most IETF activities are based on.

As to =E2=80=9Crough cons= ensus=E2=80=9D, holding a BoF is the first step in determining that.=

=C2=A0

To point 2), again the Bo= F will provide a useful measurement of interest.

=C2=A0

Thanks =E2=80=93 Fred<= /u>

fred.l.templin@boeing.com<= u>

=C2=A0

=C2=A0

From: dtn [mai= lto:dtn-bounces@i= etf.org] On Behalf Of Eric Travis
Sent: Thursday, June 05, 2014 9:29 AM
To: l.wood@= surrey.ac.uk
Cc: mls.ietf= @gmail.com; spencerdawkins.ietf@gmail.com; dtn@ietf.org; iesg@ietf.org


Subject: Re: [dtn] DTN BoF Proposal for IETF90

=C2=A0

Lloyd,



Embedded in your manifesto are two points worthy of discussion/debate throu= ghout the BoF process:

1) Is the proposed (base) solution - with "minimal" fixes - of su= fficient maturity for standardization within the IETF?

2) The existing IRTF DTNRG has not been able to harness sufficient interest= /resources to advance the state of RFC-5050, how will a new IETF WG change = the dynamic?

As for the rest of it, well...

RFC5050bis: half-assed, half-baked, reheated.
But hey, ask me what I _really_ think.

=C2=A0

Let the rational, wel= l-reasoned discussion begin...

Eric

eric.dot.travis@gmail.com

=C2=A0<= /p>

On Thu, Jun 5, 2014 at 7:20 AM, <l.wood@surrey.ac.uk> wrote:=

As previously expressed on DTNRG, I have a number of= concerns about
this proposed BOF to create an IETF DTN WG to do work on the
RFC5050 bundle protocol, produced in the IRTF DTNRG, and create
an RFC5050bis. I'll go through those concerns one by one:


1. I don't see how going standards track can be justified, because:

=C2=A0 =C2=A0a. CCSDS is already working on the bundle protocol as one of t= heir
=C2=A0 =C2=A0 =C2=A0 blue book standards, based on RFC5050, and any RFC5050= bis
=C2=A0 =C2=A0 =C2=A0 would presumably also be adopted and then modified to = make
=C2=A0 =C2=A0 =C2=A0 a CCSDS standard.
=C2=A0 =C2=A0 =C2=A0 It's rather like CCSDS restandardizing TCP/IP as S= CPS, back
=C2=A0 =C2=A0 =C2=A0 in the 1990s. That SCPS standardization wasn't use= d much
=C2=A0 =C2=A0 =C2=A0 either, not least because CCSDS 'improved' on = TCP/IP
=C2=A0 =C2=A0 =C2=A0 and went incompatible quite quickly. The same will hap= pen
=C2=A0 =C2=A0 =C2=A0 with the CCSDS bundle protocol, and in adopting RFC505= 0
=C2=A0 =C2=A0 =C2=A0 CCSDS has reserved the right to make changes - things = like
=C2=A0 =C2=A0 =C2=A0 Delay Tolerant Payload Conditioning (DTPC) are but the= start.
=C2=A0 =C2=A0 =C2=A0 There's an example of bundle protocol work not req= uiring
=C2=A0 =C2=A0 =C2=A0 the IETF. Work on altering and extending the bundle pr= otocol
=C2=A0 =C2=A0 =C2=A0 is already ongoing in CCSDS.
=C2=A0 =C2=A0 =C2=A0 Setting up an IETF workgroup to work in parallel would= mean
=C2=A0 =C2=A0 =C2=A0 that a CCSDS liaison would be required, to pay attenti= on
=C2=A0 =C2=A0 =C2=A0 to their concerns as they try and convince their membe= r space
=C2=A0 =C2=A0 =C2=A0 agencies to use the bundle protocol, and to prevent th= eir spec
=C2=A0 =C2=A0 =C2=A0 from diverging (further) from the IETF spec. Really, t= he work
=C2=A0 =C2=A0 =C2=A0 is simply more easily done in CCSDS, given that CCSDS = is
=C2=A0 =C2=A0 =C2=A0 pretty much the only customer for bundle protocol, bec= ause
=C2=A0 =C2=A0 =C2=A0 NASA has mandated bundle protocol use from on high. =C2=A0 =C2=A0 =C2=A0 NASA leads CCSDS, NASA Jet Propulsion Lab leads CCSDS = design
=C2=A0 =C2=A0 =C2=A0 for NASA's Space Communications and Navigation peo= ple.
=C2=A0 =C2=A0 =C2=A0 JPL is really the primary customer for and user of bun= dle
=C2=A0 =C2=A0 =C2=A0 protocol, responsible for promoting its use by other s= pace
=C2=A0 =C2=A0 =C2=A0 agencies - never an easy task, even with good technolo= gies.

=C2=A0 =C2=A0b. The IETF produces Internet standards. The bundle protocol =C2=A0 =C2=A0 =C2=A0 has little bearing on or interaction with Internet sta= ndards;
=C2=A0 =C2=A0 =C2=A0 it's arguably a way to interoperate with the Inter= net while
=C2=A0 =C2=A0 =C2=A0 protecting CCSDS from incursion of the Internet, by la= yering
=C2=A0 =C2=A0 =C2=A0 over both Internet and CCSDS. Each to their own domain= s.
=C2=A0 =C2=A0 =C2=A0 Using TCP as the most common bundle convergence layer = (described
=C2=A0 =C2=A0 =C2=A0 in a draft now seven years old) does not make the bund= le protocol
=C2=A0 =C2=A0 =C2=A0 an internet standard. If it did, then CCSDS's Spac= e Link
=C2=A0 =C2=A0 =C2=A0 Extension (basically a TCP tunnel carrying CCSDS frame= s, with
=C2=A0 =C2=A0 =C2=A0 much added complexity) would also be a candidate for a= n
=C2=A0 =C2=A0 =C2=A0 IETF internet standard.
=C2=A0 =C2=A0 =C2=A0 But, again, that work is best done in CCSDS, where the= re
=C2=A0 =C2=A0 =C2=A0 is interest in having it done and there are users. (So= me
=C2=A0 =C2=A0 =C2=A0 of those users may even be willing users.)

=C2=A0 =C2=A0c. The bundle protocol is not mature. Deficiencies have been =C2=A0 =C2=A0 =C2=A0 identified, drafts have been written in DTNRG over the= years,
=C2=A0 =C2=A0 =C2=A0 there was little interest, the drafts expired, the bun= dle
=C2=A0 =C2=A0 =C2=A0 protocol was never improved. And that's just from = demonstrations;
=C2=A0 =C2=A0 =C2=A0 there has not been extended operational use to my know= ledge.
=C2=A0 =C2=A0 =C2=A0 Attempting to fix the bundle protocol AND push it thro= ugh as
=C2=A0 =C2=A0 =C2=A0 standards track at the same time seems unwarranted. =C2=A0 =C2=A0 =C2=A0 It may be politically motivated, but it is
=C2=A0 =C2=A0 =C2=A0 not technically or procedurally justifiable.
=C2=A0 =C2=A0 =C2=A0 There isn't the userbase or demand needed for the = bundle
=C2=A0 =C2=A0 =C2=A0 protocol to go standards track, and if the IETF did go=
=C2=A0 =C2=A0 =C2=A0 standards track, CCSDS would 'optimize' that s= tandard into
=C2=A0 =C2=A0 =C2=A0 its own standard, just as was done with SCPS, meaning = that
=C2=A0 =C2=A0 =C2=A0 the IETF would spend a lot of time working on somethin= g with
=C2=A0 =C2=A0 =C2=A0 no benefit to the IETF community or userbase. Extendin= g
=C2=A0 =C2=A0 =C2=A0 the Internet protocols to the DTN network problem spac= e
=C2=A0 =C2=A0 =C2=A0 adds value to the internet protocols. A separate proto= col
=C2=A0 =C2=A0 =C2=A0 does not.
=C2=A0 =C2=A0 =C2=A0 Who would benefit, outside the CCSDS community? And CC= SDS
=C2=A0 =C2=A0 =C2=A0 is their own standards org - an ISO subgroup - to do w= ork
=C2=A0 =C2=A0 =C2=A0 for that CCSDS community.


2. I don't see why this needs to be done in an IETF WG, because:

=C2=A0 =C2=A0a. going standards track isn't justifiable - see 1.

=C2=A0 =C2=A0b. There's already the IRTF DTNRG, which could clean up it= s
=C2=A0 =C2=A0 =C2=A0 own work, but ,after many years and some failed drafts= ,
=C2=A0 =C2=A0 =C2=A0 has not.
=C2=A0 =C2=A0 =C2=A0 Declaring success and saying it is now time to create = a
=C2=A0 =C2=A0 =C2=A0 WG based on DTNRG's achievements is not convincing= ,
=C2=A0 =C2=A0 =C2=A0 because those achievements are not impressive.
=C2=A0 =C2=A0 =C2=A0 (Disclaimer of interest: I authored 'A bundle of p= roblems'
=C2=A0 =C2=A0 =C2=A0 and have spent considerable years trying to explain an= d
=C2=A0 =C2=A0 =C2=A0 address problems with the bundle protocol, with little=
=C2=A0 =C2=A0 =C2=A0 success, after getting it tested in space before NASA&= #39;s
=C2=A0 =C2=A0 =C2=A0 EXPOXI/Deep Impact tests took place.
=C2=A0 =C2=A0 =C2=A0 Fred Templin's problem statement drafts for this p= utative
=C2=A0 =C2=A0 =C2=A0 IETF BOF calls on that work.)
=C2=A0 =C2=A0 =C2=A0 RFC5050bis would make more sense as a DTNRG
=C2=A0 =C2=A0 =C2=A0 effort, though it would be time for a changing of the<= br> =C2=A0 =C2=A0 =C2=A0 guard and chairs in DTNRG to infuse some new blood and=
=C2=A0 =C2=A0 =C2=A0 technical judgement - or we're in for another five= years
=C2=A0 =C2=A0 =C2=A0 of what-does-the-end-to-end-principle-really-mean and<= br> =C2=A0 =C2=A0 =C2=A0 what-about-clocks and rehashing the same old arguments= .
=C2=A0 =C2=A0 =C2=A0 Really, DTNRG needs to get its act together, both
=C2=A0 =C2=A0 =C2=A0 organizationally and technically.

=C2=A0 =C2=A0c. There's already CCSDS, which has adopted the DTNRG outp= ut,
=C2=A0 =C2=A0 =C2=A0 after pushing for the formation of an Interplanetary =C2=A0 =C2=A0 =C2=A0 Internet RG in the first place.

So either CCSDS or DTNRG can do RFC5050 revision work. If
it's to be an RFC, experimental or informational, a revitalised
rechartered DTNRG can do it.
It doesn't need to be an IETF workgroup. It certainly
shouldn't go standards track.


3. The philosophically shaky basis for the bundle protocol:

=C2=A0 =C2=A0a. Delay-tolerant networking is not disruption-tolerant
=C2=A0 =C2=A0 =C2=A0 networking. Space delays of light-minutes with schedul= ed
=C2=A0 =C2=A0 =C2=A0 contacts are not the same as intermittent ad-hoc
=C2=A0 =C2=A0 =C2=A0 manet-style communications. Different requirements, =C2=A0 =C2=A0 =C2=A0 different buffering and storage, different conditions,=
=C2=A0 =C2=A0 =C2=A0 different handling of fragmentation, etc.

=C2=A0 =C2=A0b. The bundle protocol is not DTN. DTN is the scenario,
=C2=A0 =C2=A0 =C2=A0 in which other approaches (the related CFDP, Haggle, =C2=A0 =C2=A0 =C2=A0 the MANET and vehicular DTNs efforts that DTN subsumed=
=C2=A0 =C2=A0 =C2=A0 and rebranded, etc.) exist.
=C2=A0 =C2=A0 =C2=A0 The bundle protocol is intended to be used in a DTN =C2=A0 =C2=A0 =C2=A0 scenario. Branding the bundle protocol as DTN has
=C2=A0 =C2=A0 =C2=A0 put back non-bundle DTN research a number of years. =C2=A0 =C2=A0 =C2=A0 Branding a group only working on the bundle protocol =C2=A0 =C2=A0 =C2=A0 as 'DTN' is misleading at best.

=C2=A0 =C2=A0c. Extending the bundle protocol from the original
=C2=A0 =C2=A0 =C2=A0 Interplanetary Internet problem (which had its own
=C2=A0 =C2=A0 =C2=A0 IRTF RG which led into a set bundle agenda for
=C2=A0 =C2=A0 =C2=A0 DTNRG) to cover everything else as well simply hasn= 9;t
=C2=A0 =C2=A0 =C2=A0 worked very well, because the scenarios and use cases<= br> =C2=A0 =C2=A0 =C2=A0 are different. We design for use cases. To be too
=C2=A0 =C2=A0 =C2=A0 generalised is to engineer for nothing.

=C2=A0 =C2=A0d. Ignoring the ramifications of the end-to-end principle,
=C2=A0 =C2=A0 =C2=A0 which are often more subtle than people seem to think<= br> =C2=A0 =C2=A0 =C2=A0 they are. The bundle protocol's custody transfer =C2=A0 =C2=A0 =C2=A0 procedure is a good example of this failing.

=C2=A0 =C2=A0e. The bundle protocol is intended for use in the most
=C2=A0 =C2=A0 =C2=A0 difficult noisy disrupted networking conditions we kno= w,
=C2=A0 =C2=A0 =C2=A0 and it can't even sanity check its own headers aga= inst
=C2=A0 =C2=A0 =C2=A0 errors. (But hey, it now has a security protocol that<= br> =C2=A0 =C2=A0 =C2=A0 _almost_ does that! But which is too complicated, and<= br> =C2=A0 =C2=A0 =C2=A0 would need to be redone.)
=C2=A0 =C2=A0 =C2=A0 It's intended for the harshest environments we kno= w,
=C2=A0 =C2=A0 =C2=A0 but needs reliable synchronized clocks running at
=C2=A0 =C2=A0 =C2=A0 steady temperatures!
=C2=A0 =C2=A0 =C2=A0 It's intended for embedded systems, but the design=
=C2=A0 =C2=A0 =C2=A0 is huge and complex! (CFDP has the same problem;
=C2=A0 =C2=A0 =C2=A0 there's a reason implementers went for a "CFD= P lite,"
=C2=A0 =C2=A0 =C2=A0 and Saratoga exists just because CFDP wasn't perfo= rming.
=C2=A0 =C2=A0 =C2=A0 Would RFC5050bis be "bundling lite"?)
=C2=A0 =C2=A0 =C2=A0 There are many 'that makes no sense' moments -= normally
=C2=A0 =C2=A0 =C2=A0 more immediately visible to outsiders not steeped in =C2=A0 =C2=A0 =C2=A0 the dogma, politics, and history of DTNRG and CCSDS.
=C2=A0 =C2=A0f. The assumption that a full security suite is desirable
=C2=A0 =C2=A0 =C2=A0 and necessary at all times. This has derailed DTNRG, =C2=A0 =C2=A0 =C2=A0 as emphasis was placed on security work above all
=C2=A0 =C2=A0 =C2=A0 else, rather than working to the scenario. To be fair<= br> =C2=A0 =C2=A0 =C2=A0 to the security-focused chairs, the charter that
=C2=A0 =C2=A0 =C2=A0 established DTNRG from the interplanetary internet
=C2=A0 =C2=A0 =C2=A0 research group called out security heavily, and they =C2=A0 =C2=A0 =C2=A0 ran with that mandate. But the focus has decreased
=C2=A0 =C2=A0 =C2=A0 work on non-security matters, which is to say,
=C2=A0 =C2=A0 =C2=A0 everything else.

RFC5050bis might address the latter three problems, but
the first three are intrinsically unsolvable; any solution
will be unsatisfactory. Perhaps not as unsatisfactory as
RFC5050, but unsatisfactory nonetheless.

The real philosophical problem here is the political dogma
that, whatever the problem, the bundle protocol is The
One True Solution.


4. The draft BOF charter is bundle-centric. Which is to say,
=C2=A0 =C2=A0that it's not awfully relevant to internet standards.
=C2=A0 =C2=A0Disclaimer of interest: we've worked on Saratoga and
=C2=A0 =C2=A0HTTP-DTN, which have current internet-drafts, and are
=C2=A0 =C2=A0squarely in the DTN problem space.
=C2=A0 =C2=A0Whenever someone talks about multiple convergence
=C2=A0 =C2=A0layers for the bundle protocol - there's more than for BEE= P,
=C2=A0 =C2=A0which just has TCP, but there aren't many - Saratoga may =C2=A0 =C2=A0be mentioned. But we've found that carrying bundles doesn&= #39;t
=C2=A0 =C2=A0benefit Saratoga - tested it in space, didn't see the
=C2=A0 =C2=A0advantages. Saratoga does leverage a few Internet things -
=C2=A0 =C2=A0UDP, UDP-Lite, multicast. It does a few scaling things that =C2=A0 =C2=A0nothing else I've seen does (described in our 2011 TSVAREA=
=C2=A0 =C2=A0presentation to IETF 88 in November.) And it's based on =C2=A0 =C2=A0a decade of operational use in the problem domain.
=C2=A0 =C2=A0HTTP-DTN leverages the HTTP suite and MIME, and comes up
=C2=A0 =C2=A0whenever wouldn't-it-be-nice-to-try-HTTP-for-DTN discussio= n
=C2=A0 =C2=A0takes place.
=C2=A0 =C2=A0(I suspect that all of Stephen Farrell's N4C work could =C2=A0 =C2=A0have been done over hop-by-hop HTTP a la HTTP-DTN, and
=C2=A0 =C2=A0would have worked just as well if not better. After all,
=C2=A0 =C2=A0it used TCP.)
=C2=A0 =C2=A0These and other efforts exist in a gap between DTNRG, which =C2=A0 =C2=A0is aware of the problem space, but thinks the bundle
=C2=A0 =C2=A0protocol is the solution despite mounting evidence to the
=C2=A0 =C2=A0contrary, and TSVWG, where the few actual transport
=C2=A0 =C2=A0experts live, without clout, or funding, or spare time.
=C2=A0 =C2=A0Those efforts are interesting enough to have implementations =C2=A0 =C2=A0kicking around too.
=C2=A0 =C2=A0And yet, the focus of this putative workgroup and BOF is
=C2=A0 =C2=A0solely on bundling, and not on evaluating these or other
=C2=A0 =C2=A0things that might exist in the problem space. There
=C2=A0 =C2=A0must be other things out there that would be of interest
=C2=A0 =C2=A0to such a DTN workgroup. What is proposed is not a DTN
=C2=A0 =C2=A0workgroup. The charter is basically a bundle workgroup.
=C2=A0 =C2=A0Can an interest in bundling and solely bundling (outside
=C2=A0 =C2=A0CCSDS, which is driving the push to use the bundle protocol) =C2=A0 =C2=A0be justified for an IETF workgroup? I really don't think s= o.

5. The bundle protocol work was, I gather, well-funded
=C2=A0 =C2=A0by a number of parties.
=C2=A0 =C2=A0I can't see a follow-on effort being anywhere near
=C2=A0 =C2=A0as well funded.

=C2=A0 =C2=A0a. I have no idea how much money NASA and CCSDS have put
=C2=A0 =C2=A0 =C2=A0 into this - first CFDP, then bundling, which now has =C2=A0 =C2=A0 =C2=A0 to provide a CFDP-like API to the users who were told<= br> =C2=A0 =C2=A0 =C2=A0 that CFDP was the future, and Licklider (LTP).
=C2=A0 =C2=A0 =C2=A0 Dragging CCSDS into the modern age of networking
=C2=A0 =C2=A0 =C2=A0 seems unlikely to ever happen, thanks to CCSDS having<= br> =C2=A0 =C2=A0 =C2=A0 little in the way of sane layering or separation of =C2=A0 =C2=A0 =C2=A0 functionality.
=C2=A0 =C2=A0 =C2=A0 I do have the luxury of not needing to work on CCSDS.<= br> =C2=A0 =C2=A0 =C2=A0 But if you want to work on CCSDS protocols, CCSDS is =C2=A0 =C2=A0 =C2=A0 the place to go. The IETF is not that place.

=C2=A0 =C2=A0b. DARPA poured money into DTN work - at least twenty
=C2=A0 =C2=A0 =C2=A0 million dollars, from the press releases I've seen= .
=C2=A0 =C2=A0 =C2=A0 I have no idea what DARPA got out of it in the
=C2=A0 =C2=A0 =C2=A0 years they were involved; haven't seen the reports= .

My point is, all that money and effort and manpower and
over a decade of work and prior experience with CFDP and two
IRTF RGs, we have... RFC5050.
There is nowhere near as much money or effort or manpower
for doing a replacement.
Ergo, it might be suggested that the replacement is unlikely
to be as good as RFC5050, or as good as CFDP; at best,
the usual suspects will have less time and fewer resources
to repeat their original mistakes.

And transport expertise from TSVWG would be needed.
TSVWG is unfashionable, low-visibility, and has even
previously had trouble finding ADs with relevant expertise.
And TSVWG has a full plate with work on its existing
protocols; there is not a lot of expertise, and what there
is is spread thin.
So an RFC505bis effort is unlikely to get the expert
technical input that it sorely needs, even if an IETF
workgroup is set up. (CCSDS doesn't have that transport
focus.)

If, on the other hand, you believe good protocol design
can be done more cheaply and leverage actual Internet
standards to get Internet functionality working in
difficult networks where the full TCP/IP suite has
trouble, your options include Saratoga and HTTP-DTN!
http://sarat= oga.sourceforge.net/
h= ttp://sat-net.com/L.Wood/dtn/http-dtn.html
They'll truly extend the Internet to difficult
environments. The bundle protocol won't.

So, to conclude, there is no justification for going
standards track. There is little justification for an
IETF workgroup. There is more logic in rechartering and
repurposing the IRTF DTNRG, but the work may as well
be left to CCSDS entirely.

RFC5050bis: half-assed, half-baked, reheated.
But hey, ask me what I _really_ think.

Lloyd Wood
http://sat-net= .com/L.Wood/dtn/

_______________________________________________
dtn mailing list
dtn@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dtn




--

The problem with the world is that the intelli= gent people are full of doubts,
while the stupid ones are full of confidence.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Charles Bukowski




--
<= i>The problem with the world is that the intelligent people are full of = doubts,
while the stupid ones are full of confidence.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Charles Bukowski
--047d7b343394cc244004fb1ad891-- From nobody Thu Jun 5 11:43:12 2014 Return-Path: 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 C53B31A01DF; Thu, 5 Jun 2014 11:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, 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 cbsIEblck1TC; Thu, 5 Jun 2014 11:43:04 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21BBB1A0126; Thu, 5 Jun 2014 11:43:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s55Igvpg032171; Thu, 5 Jun 2014 11:42:57 -0700 Received: from XCH-PHX-510.sw.nos.boeing.com (xch-phx-510.sw.nos.boeing.com [10.57.37.27]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s55Igo47032073 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 5 Jun 2014 11:42:50 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.105]) by XCH-PHX-510.sw.nos.boeing.com ([169.254.10.141]) with mapi id 14.03.0181.006; Thu, 5 Jun 2014 11:42:49 -0700 From: "Templin, Fred L" To: Eric Travis Thread-Topic: [dtn] DTN BoF Proposal for IETF90 Thread-Index: Ac+AQa9Fez/CplZaSwyaLFpzb8tj0wAmbPuTAAIy0LAAEHKqgAAOXElQ Date: Thu, 5 Jun 2014 18:42:49 +0000 Message-ID: <2134F8430051B64F815C691A62D983181B2BF56C@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> <1401967219583.26821@surrey.ac.uk> <2134F8430051B64F815C691A62D983181B2BF435@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: multipart/alternative; boundary="_000_2134F8430051B64F815C691A62D983181B2BF56CXCHBLV504nwnosb_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/RuOpzpTttAVsjzgGRM08tWqBDiA Cc: "iesg@ietf.org" , "mls.ietf@gmail.com" , "spencerdawkins.ietf@gmail.com" , "l.wood@surrey.ac.uk" , "dtn@ietf.org" Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 18:43:10 -0000 --_000_2134F8430051B64F815C691A62D983181B2BF56CXCHBLV504nwnosb_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRXJpYywNCg0KSXQgaXMgdHJ1ZSB0aGF0IGhhdmluZyBhbiBvZmZpY2lhbCBJRVRGIHN0YW5k YXJkIGlzIG5vdCBhIG5lY2Vzc2FyeSBwcmVjb25kaXRpb24gZm9yIG9uZQ0Kb3IgbW9yZSAgdmVu ZG9ycyB0byBtb3ZlIGZvcndhcmQgd2l0aCB3aWRlbHktZGVwbG95ZWQgaW1wbGVtZW50YXRpb25z LiBJIHNob3VsZA0Ka25vdzsgSSB3cm90ZSBvbmU6DQoNCmh0dHA6Ly93d3cucmZjLWVkaXRvci5v cmcvcmZjL3JmYzUyMTQudHh0DQoNCkJ1dCwgaGF2aW5nIGFuIElFVEYgc3RhbmRhcmQgaXMgYSBk ZW1vbnN0cmF0aW9uIHRoYXQgcm91Z2ggY29uc2Vuc3VzIGhhcyBkZWVtZWQNCnRoZSB3b3JrIGFz IHN0YW5kYXJkcy13b3J0aHkg4oCTIGEgY29tbXVuaXR5IHN0YW1wIG9mIGFwcHJvdmFsLCBvciBh dCBsZWFzdCDigJxubw0Kb2JqZWN0aW9u4oCdLg0KDQpBYm91dCBsZXZlbCBvZiBpbnRlcmVzdCwg IEkgYmVsaWV2ZSB0aGVyZSBpcyBzdGlsbCBlbmVyZ3kgaW4gRFROUkcgYW5kIGF0IGxlYXN0IHNv bWUgb2YNCnRoYXQgZW5lcmd5IGlzIHNwaWxsaW5nIG92ZXIgaW50byB0aGVzZSBkaXNjdXNzaW9u cy4NCg0KVGhhbmtzIC0gRnJlZA0KDQoNCg0KRnJvbTogRXJpYyBUcmF2aXMgW21haWx0bzplcmlj LmRvdC50cmF2aXNAZ21haWwuY29tXQ0KU2VudDogVGh1cnNkYXksIEp1bmUgMDUsIDIwMTQgMTE6 MjQgQU0NClRvOiBUZW1wbGluLCBGcmVkIEwNCkNjOiBsLndvb2RAc3VycmV5LmFjLnVrOyBtbHMu aWV0ZkBnbWFpbC5jb207IHNwZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29tOyBkdG5AaWV0Zi5v cmc7IGllc2dAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbZHRuXSBEVE4gQm9GIFByb3Bvc2FsIGZv ciBJRVRGOTANCg0KSGkgRnJlZCwNCldoaWxlIEkgd2Fzbid0IGludGVuZGluZyB0byBhZHZvY2F0 ZSBlaXRoZXIgd2F5IG9uIHRoZSBpdGVtczoNCg0KVG8gcG9pbnQgMSksIGFkdmFuY2VtZW50IG9m IHdvcmsgaXRlbXMgaW4gdGhlIElFVEYgaXMgdXN1YWxseSBiYXNlZCBvbiDigJxyb3VnaCBjb25z ZW5zdXMNCmFuZCBydW5uaW5nIGNvZGXigJ0gYW5kIHRoZXJlIGlzIHBsZW50eSBvZiBpbnRlcm9w ZXJhYmxlIHJ1bm5pbmcgY29kZSB0aGF0IGltcGxlbWVudHMNClJGQzUwNTAgYW5kIGl0cyByZWxh dGVkIHNwZWNpZmljYXRpb25zIOKAkyBtdWNoIG1vcmUgdGhhbiBtb3N0IElFVEYgYWN0aXZpdGll cyBhcmUgYmFzZWQgb24uDQoNCk15ICAicG9pbnRzIHdvcnRoeSBvZiBkaXNjdXNzaW9uL2RlYmF0 ZSB0aHJvdWdob3V0IHRoZSBCb0YgcHJvY2VzcyIgc2VlbXMgdG8gYmUgY29tcGF0aWJsZSB3aXRo IHlvdXINCkFzIHRvIOKAnHJvdWdoIGNvbnNlbnN1c+KAnSwgaG9sZGluZyBhIEJvRiBpcyB0aGUg Zmlyc3Qgc3RlcCBpbiBkZXRlcm1pbmluZyB0aGF0Lg0KDQpJJ2QgY29udGVuZCB0aGF0IHRoZSAq RFROUkcqIHdhcyB0aGUgc3RhcnQgb2YgdGhhdCBkaXNjdXNzaW9uLiAgVGhlICpCb0YqIGlzIGEg Y29udGludWF0aW9uIG9mIGEgNysgeWVhciBjb21tdW5pdHkgZGlzY3Vzc2lvbi4NCg0KDQpUaGVy ZSBpcyBhbiBleHBlcmltZW50YWwgUkZDIHRoYXQgaGFzIGFjaGlldmVkIGludGVyb3BlcmFiaWxp dHkgYmV0d2VlbiBtdWx0aXBsZSBpbmRlcGVuZGVudCBpbXBsZW1lbnRhdGlvbnMuDQpUaGF0LCBo b3dldmVyLCBpc24ndCBuZWNlc3NhcmlseSBhIHJlZmVyZW5kdW0gb24gdGhlIG1hdHVyaXR5IG9m IHRoZSBwcm90b2NvbChzKSB0aGVtc2VsdmVzLg0KRm9yIHRob3NlIGVudGl0aWVzIHdob3NlIG5l ZWRzIGFyZSBzYXRpc2ZpZWQgd2l0aCBSRkMtNTA1MCwgYSBzdGFuZGFyZHMtdHJhY2sgZG9jdW1l bnQgaXMgbm90IG5lY2Vzc2FyeSBmb3IgZGVwbG95bWVudC4NCkFjdHVhbGx5LCBhIHN0YW5kYXJk cy10cmFjayBkb2N1bWVudCBpcyBuZXZlciAqcmVhbGx5KiBuZWNlc3NhcnkuICBUaGVyZSBhcmUg bWFueSBtaWRkbGV3YXJlL2FwcGxpY2F0aW9uIGxldmVsICJ0aGluZ3MiIGRlcGxveWVkDQp0aGF0 IGFyZSBub3QgYmFzZWQgb24gSUVURiBzdGFuZGFyZHMuICBUaGUgcHJlc3VtcHRpb24gb2YgdGhl IEJvRiBzZWVtcyB0byBiZSB0aGF0IFJGQy01MDUwIGlzIE5PVCAidGhlcmUgeWV0Ii4gIFNvLCB0 aGUNCnF1ZXN0aW9uIGlzIGhvdyBjbG9zZSB0byBtYXR1cml0eSBpcyBjbG9zZSBlbm91Z2ggdG8g Z28gaW50byBhIHN0YW5kYXJkcyB0cmFqZWN0b3J5Lg0KDQpGcm9tIHRoZSBkaXNjdXNzaW9ucyBv biB0aGUgbGlzdCwgdGhlcmUgaGFzIGJlZW4gYSBsb3Qgb2YgdmVyeSBwcm9taXNpbmcgZGlhbG9n IG9mIHRoZSBuYXR1cmUgb2YNCiJZZWFoLCBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gKmV4cGxvcmUq IEZvbyBhbmQvb3IgQmFyIiwgZnJvbSBzb21lIHBlb3BsZSB0aGF0IC0gZnJhbmtseSAtIHBsZWFz YW50bHkgc3VycHJpc2VkIG1lLg0KVGhpcyBsZWFkcyB0byB0aGUgcXVlc3Rpb24gLSBoYXMgdGhl IHNvbHV0aW9uIHNwYWNlIGJlZW4gYWRlcXVhdGVseSBleHBsb3JlZCB0byBoYXZlIGNvbmZpZGVu Y2UgdGhhdCB0aGUgcmVzdWx0IGlzDQphIG1hdHVyZSAoTk9UIHBlcmZlY3QpPyAgSWYgbm90LCB3 aWxsIHRoZSBXRyBiZSBhYmxlIHRvIHRha2UgaXQgZnVydGhlciB0aGFuIHRoZSBSRyB3YXMgY2Fw YWJsZSAoYW5kIHdoeSBpcyB0aGF0IHRydWUpPw0KDQpUaGF0J3MgYSBxdWVzdGlvbiwgbm90IGEg c3RhdGVtZW50IG9uIG15IHBhcnQuDQoNCg0KIFRvIHBvaW50IDIpLCBhZ2FpbiB0aGUgQm9GIHdp bGwgcHJvdmlkZSBhIHVzZWZ1bCBtZWFzdXJlbWVudCBvZiBpbnRlcmVzdC4NCg0KSSB0aGluayB0 aGUgbGV2ZWwgb2YgaW50ZXJlc3QgaXMgcmVsYXRpdmVseSBoaWdoIHdpdGhpbiB0aGUgRFROUkcg LSBhbmQgd2lsbCBsaWtlbHkgYmUgc28gZm9yIGEgRFROIFdHLiAgVGhlIHF1ZXN0aW9uDQpyZWFs bHkgaXMgaWYvaG93IHdpbGwgdGhhdCB0cmFuc2xhdGUgaW50byBtZWFzdXJhYmxlIHByb2dyZXNz IChmaXhpbmcgdGhlIC0gc29tZSBsb25nIGFja25vd2xlZGdlZCAtIG5pdHMgaW4gdGhlIHByb3Rv Y29sDQpzcGVjaWZpY2F0aW9uLg0KVGhlIG9yaWdpbmFsIGlkZWEgb2YgYSBSRkM1MDUwLkJpcyB3 YXMgZmxvYXRlZCB0d28gKHRocmVlPykgeWVhcnMgYWdvIGFzIHBhcnQgb2YgdGhlIG1vc3QgcmVj ZW50IEdvb2dsZSBtZWV0aW5nLiAgSXQgZmFpbGVkIHRvIGdhaW4NCnRyYWN0aW9uLCBkZXNwaXRl IHdoYXQgc2VlbWVkIHRvIGJlIGEgZmFpciBhbW91bnQgb2YgY29tbXVuaXR5IGludGVyZXN0Lg0K SXMgdGhlIGxhY2sgb2YgbW92ZW1lbnQgd2l0aGluIHRoZSBEVE5SRyBzaW1wbHkgYmVjYXVzZSBv ZiB0aGUgKGxhY2sgb2YpIHBhdGggdG8gYSBzdGFuZGFyZHMgdHJhY2sgUkZDPw0KVGhlIHF1ZXN0 aW9uIGZvciB0aGUgQm9GIGlzLCB3aGF0IGNhdXNlZCB0aGUgZXZvbHV0aW9uYXJ5IHBhdXNlLCBh bmQgaG93IHdpbGwgYSBXRyBwcmV2ZW50IGl0IGZyb20gc3RhbGxpbmcgYWdhaW4uDQoNCg0KSnVz dCB0byBiZSBjbGVhciwgIEknbSBpbiBmYXZvciBvZiBhIEJvRiBhbmQgY3VycmVudGx5IHVuZGVj aWRlZC9hZ25vc3RpYyBvbiBzdXBwb3J0IG9mIGEgV0csIHRoZXNlIHR5cGVzIG9mIGRpc2N1c3Np b25zIHdvdWxkDQpiZSB1c2VmdWwgdG8gbWUgKGF0IHRoZSB2ZXJ5IGxlYXN0KS4NClJlZ2FyZHMs DQpFcmljDQplcmljLmRvdC50cmF2aXNAZ21haWwuY29tPG1haWx0bzplcmljLmRvdC50cmF2aXNA Z21haWwuY29tPg0KDQpPbiBUaHUsIEp1biA1LCAyMDE0IGF0IDE6MzggUE0sIFRlbXBsaW4sIEZy ZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTxtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9l aW5nLmNvbT4+IHdyb3RlOg0KSGkgRXJpYywNCg0KVG8gcG9pbnQgMSksIGFkdmFuY2VtZW50IG9m IHdvcmsgaXRlbXMgaW4gdGhlIElFVEYgaXMgdXN1YWxseSBiYXNlZCBvbiDigJxyb3VnaCBjb25z ZW5zdXMNCmFuZCBydW5uaW5nIGNvZGXigJ0gYW5kIHRoZXJlIGlzIHBsZW50eSBvZiBpbnRlcm9w ZXJhYmxlIHJ1bm5pbmcgY29kZSB0aGF0IGltcGxlbWVudHMNClJGQzUwNTAgYW5kIGl0cyByZWxh dGVkIHNwZWNpZmljYXRpb25zIOKAkyBtdWNoIG1vcmUgdGhhbiBtb3N0IElFVEYgYWN0aXZpdGll cyBhcmUgYmFzZWQgb24uDQpBcyB0byDigJxyb3VnaCBjb25zZW5zdXPigJ0sIGhvbGRpbmcgYSBC b0YgaXMgdGhlIGZpcnN0IHN0ZXAgaW4gZGV0ZXJtaW5pbmcgdGhhdC4NCg0KVG8gcG9pbnQgMiks IGFnYWluIHRoZSBCb0Ygd2lsbCBwcm92aWRlIGEgdXNlZnVsIG1lYXN1cmVtZW50IG9mIGludGVy ZXN0Lg0KDQpUaGFua3Mg4oCTIEZyZWQNCmZyZWQubC50ZW1wbGluQGJvZWluZy5jb208bWFpbHRv OmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20+DQoNCg0KRnJvbTogZHRuIFttYWlsdG86ZHRuLWJv dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmR0bi1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9m IEVyaWMgVHJhdmlzDQpTZW50OiBUaHVyc2RheSwgSnVuZSAwNSwgMjAxNCA5OjI5IEFNDQpUbzog bC53b29kQHN1cnJleS5hYy51azxtYWlsdG86bC53b29kQHN1cnJleS5hYy51az4NCkNjOiBtbHMu aWV0ZkBnbWFpbC5jb208bWFpbHRvOm1scy5pZXRmQGdtYWlsLmNvbT47IHNwZW5jZXJkYXdraW5z LmlldGZAZ21haWwuY29tPG1haWx0bzpzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbT47IGR0 bkBpZXRmLm9yZzxtYWlsdG86ZHRuQGlldGYub3JnPjsgaWVzZ0BpZXRmLm9yZzxtYWlsdG86aWVz Z0BpZXRmLm9yZz4NCg0KU3ViamVjdDogUmU6IFtkdG5dIERUTiBCb0YgUHJvcG9zYWwgZm9yIElF VEY5MA0KDQpMbG95ZCwNCg0KDQpFbWJlZGRlZCBpbiB5b3VyIG1hbmlmZXN0byBhcmUgdHdvIHBv aW50cyB3b3J0aHkgb2YgZGlzY3Vzc2lvbi9kZWJhdGUgdGhyb3VnaG91dCB0aGUgQm9GIHByb2Nl c3M6DQoNCjEpIElzIHRoZSBwcm9wb3NlZCAoYmFzZSkgc29sdXRpb24gLSB3aXRoICJtaW5pbWFs IiBmaXhlcyAtIG9mIHN1ZmZpY2llbnQgbWF0dXJpdHkgZm9yIHN0YW5kYXJkaXphdGlvbiB3aXRo aW4gdGhlIElFVEY/DQoNCjIpIFRoZSBleGlzdGluZyBJUlRGIERUTlJHIGhhcyBub3QgYmVlbiBh YmxlIHRvIGhhcm5lc3Mgc3VmZmljaWVudCBpbnRlcmVzdC9yZXNvdXJjZXMgdG8gYWR2YW5jZSB0 aGUgc3RhdGUgb2YgUkZDLTUwNTAsIGhvdyB3aWxsIGEgbmV3IElFVEYgV0cgY2hhbmdlIHRoZSBk eW5hbWljPw0KDQpBcyBmb3IgdGhlIHJlc3Qgb2YgaXQsIHdlbGwuLi4NClJGQzUwNTBiaXM6IGhh bGYtYXNzZWQsIGhhbGYtYmFrZWQsIHJlaGVhdGVkLg0KQnV0IGhleSwgYXNrIG1lIHdoYXQgSSBf cmVhbGx5XyB0aGluay4NCg0KTGV0IHRoZSByYXRpb25hbCwgd2VsbC1yZWFzb25lZCBkaXNjdXNz aW9uIGJlZ2luLi4uDQpFcmljDQplcmljLmRvdC50cmF2aXNAZ21haWwuY29tPG1haWx0bzplcmlj LmRvdC50cmF2aXNAZ21haWwuY29tPg0KDQpPbiBUaHUsIEp1biA1LCAyMDE0IGF0IDc6MjAgQU0s IDxsLndvb2RAc3VycmV5LmFjLnVrPG1haWx0bzpsLndvb2RAc3VycmV5LmFjLnVrPj4gd3JvdGU6 DQpBcyBwcmV2aW91c2x5IGV4cHJlc3NlZCBvbiBEVE5SRywgSSBoYXZlIGEgbnVtYmVyIG9mIGNv bmNlcm5zIGFib3V0DQp0aGlzIHByb3Bvc2VkIEJPRiB0byBjcmVhdGUgYW4gSUVURiBEVE4gV0cg dG8gZG8gd29yayBvbiB0aGUNClJGQzUwNTAgYnVuZGxlIHByb3RvY29sLCBwcm9kdWNlZCBpbiB0 aGUgSVJURiBEVE5SRywgYW5kIGNyZWF0ZQ0KYW4gUkZDNTA1MGJpcy4gSSdsbCBnbyB0aHJvdWdo IHRob3NlIGNvbmNlcm5zIG9uZSBieSBvbmU6DQoNCg0KMS4gSSBkb24ndCBzZWUgaG93IGdvaW5n IHN0YW5kYXJkcyB0cmFjayBjYW4gYmUganVzdGlmaWVkLCBiZWNhdXNlOg0KDQogICBhLiBDQ1NE UyBpcyBhbHJlYWR5IHdvcmtpbmcgb24gdGhlIGJ1bmRsZSBwcm90b2NvbCBhcyBvbmUgb2YgdGhl aXINCiAgICAgIGJsdWUgYm9vayBzdGFuZGFyZHMsIGJhc2VkIG9uIFJGQzUwNTAsIGFuZCBhbnkg UkZDNTA1MGJpcw0KICAgICAgd291bGQgcHJlc3VtYWJseSBhbHNvIGJlIGFkb3B0ZWQgYW5kIHRo ZW4gbW9kaWZpZWQgdG8gbWFrZQ0KICAgICAgYSBDQ1NEUyBzdGFuZGFyZC4NCiAgICAgIEl0J3Mg cmF0aGVyIGxpa2UgQ0NTRFMgcmVzdGFuZGFyZGl6aW5nIFRDUC9JUCBhcyBTQ1BTLCBiYWNrDQog ICAgICBpbiB0aGUgMTk5MHMuIFRoYXQgU0NQUyBzdGFuZGFyZGl6YXRpb24gd2Fzbid0IHVzZWQg bXVjaA0KICAgICAgZWl0aGVyLCBub3QgbGVhc3QgYmVjYXVzZSBDQ1NEUyAnaW1wcm92ZWQnIG9u IFRDUC9JUA0KICAgICAgYW5kIHdlbnQgaW5jb21wYXRpYmxlIHF1aXRlIHF1aWNrbHkuIFRoZSBz YW1lIHdpbGwgaGFwcGVuDQogICAgICB3aXRoIHRoZSBDQ1NEUyBidW5kbGUgcHJvdG9jb2wsIGFu ZCBpbiBhZG9wdGluZyBSRkM1MDUwDQogICAgICBDQ1NEUyBoYXMgcmVzZXJ2ZWQgdGhlIHJpZ2h0 IHRvIG1ha2UgY2hhbmdlcyAtIHRoaW5ncyBsaWtlDQogICAgICBEZWxheSBUb2xlcmFudCBQYXls b2FkIENvbmRpdGlvbmluZyAoRFRQQykgYXJlIGJ1dCB0aGUgc3RhcnQuDQogICAgICBUaGVyZSdz IGFuIGV4YW1wbGUgb2YgYnVuZGxlIHByb3RvY29sIHdvcmsgbm90IHJlcXVpcmluZw0KICAgICAg dGhlIElFVEYuIFdvcmsgb24gYWx0ZXJpbmcgYW5kIGV4dGVuZGluZyB0aGUgYnVuZGxlIHByb3Rv Y29sDQogICAgICBpcyBhbHJlYWR5IG9uZ29pbmcgaW4gQ0NTRFMuDQogICAgICBTZXR0aW5nIHVw IGFuIElFVEYgd29ya2dyb3VwIHRvIHdvcmsgaW4gcGFyYWxsZWwgd291bGQgbWVhbg0KICAgICAg dGhhdCBhIENDU0RTIGxpYWlzb24gd291bGQgYmUgcmVxdWlyZWQsIHRvIHBheSBhdHRlbnRpb24N CiAgICAgIHRvIHRoZWlyIGNvbmNlcm5zIGFzIHRoZXkgdHJ5IGFuZCBjb252aW5jZSB0aGVpciBt ZW1iZXIgc3BhY2UNCiAgICAgIGFnZW5jaWVzIHRvIHVzZSB0aGUgYnVuZGxlIHByb3RvY29sLCBh bmQgdG8gcHJldmVudCB0aGVpciBzcGVjDQogICAgICBmcm9tIGRpdmVyZ2luZyAoZnVydGhlcikg ZnJvbSB0aGUgSUVURiBzcGVjLiBSZWFsbHksIHRoZSB3b3JrDQogICAgICBpcyBzaW1wbHkgbW9y ZSBlYXNpbHkgZG9uZSBpbiBDQ1NEUywgZ2l2ZW4gdGhhdCBDQ1NEUyBpcw0KICAgICAgcHJldHR5 IG11Y2ggdGhlIG9ubHkgY3VzdG9tZXIgZm9yIGJ1bmRsZSBwcm90b2NvbCwgYmVjYXVzZQ0KICAg ICAgTkFTQSBoYXMgbWFuZGF0ZWQgYnVuZGxlIHByb3RvY29sIHVzZSBmcm9tIG9uIGhpZ2guDQog ICAgICBOQVNBIGxlYWRzIENDU0RTLCBOQVNBIEpldCBQcm9wdWxzaW9uIExhYiBsZWFkcyBDQ1NE UyBkZXNpZ24NCiAgICAgIGZvciBOQVNBJ3MgU3BhY2UgQ29tbXVuaWNhdGlvbnMgYW5kIE5hdmln YXRpb24gcGVvcGxlLg0KICAgICAgSlBMIGlzIHJlYWxseSB0aGUgcHJpbWFyeSBjdXN0b21lciBm b3IgYW5kIHVzZXIgb2YgYnVuZGxlDQogICAgICBwcm90b2NvbCwgcmVzcG9uc2libGUgZm9yIHBy b21vdGluZyBpdHMgdXNlIGJ5IG90aGVyIHNwYWNlDQogICAgICBhZ2VuY2llcyAtIG5ldmVyIGFu IGVhc3kgdGFzaywgZXZlbiB3aXRoIGdvb2QgdGVjaG5vbG9naWVzLg0KDQogICBiLiBUaGUgSUVU RiBwcm9kdWNlcyBJbnRlcm5ldCBzdGFuZGFyZHMuIFRoZSBidW5kbGUgcHJvdG9jb2wNCiAgICAg IGhhcyBsaXR0bGUgYmVhcmluZyBvbiBvciBpbnRlcmFjdGlvbiB3aXRoIEludGVybmV0IHN0YW5k YXJkczsNCiAgICAgIGl0J3MgYXJndWFibHkgYSB3YXkgdG8gaW50ZXJvcGVyYXRlIHdpdGggdGhl IEludGVybmV0IHdoaWxlDQogICAgICBwcm90ZWN0aW5nIENDU0RTIGZyb20gaW5jdXJzaW9uIG9m IHRoZSBJbnRlcm5ldCwgYnkgbGF5ZXJpbmcNCiAgICAgIG92ZXIgYm90aCBJbnRlcm5ldCBhbmQg Q0NTRFMuIEVhY2ggdG8gdGhlaXIgb3duIGRvbWFpbnMuDQogICAgICBVc2luZyBUQ1AgYXMgdGhl IG1vc3QgY29tbW9uIGJ1bmRsZSBjb252ZXJnZW5jZSBsYXllciAoZGVzY3JpYmVkDQogICAgICBp biBhIGRyYWZ0IG5vdyBzZXZlbiB5ZWFycyBvbGQpIGRvZXMgbm90IG1ha2UgdGhlIGJ1bmRsZSBw cm90b2NvbA0KICAgICAgYW4gaW50ZXJuZXQgc3RhbmRhcmQuIElmIGl0IGRpZCwgdGhlbiBDQ1NE UydzIFNwYWNlIExpbmsNCiAgICAgIEV4dGVuc2lvbiAoYmFzaWNhbGx5IGEgVENQIHR1bm5lbCBj YXJyeWluZyBDQ1NEUyBmcmFtZXMsIHdpdGgNCiAgICAgIG11Y2ggYWRkZWQgY29tcGxleGl0eSkg d291bGQgYWxzbyBiZSBhIGNhbmRpZGF0ZSBmb3IgYW4NCiAgICAgIElFVEYgaW50ZXJuZXQgc3Rh bmRhcmQuDQogICAgICBCdXQsIGFnYWluLCB0aGF0IHdvcmsgaXMgYmVzdCBkb25lIGluIENDU0RT LCB3aGVyZSB0aGVyZQ0KICAgICAgaXMgaW50ZXJlc3QgaW4gaGF2aW5nIGl0IGRvbmUgYW5kIHRo ZXJlIGFyZSB1c2Vycy4gKFNvbWUNCiAgICAgIG9mIHRob3NlIHVzZXJzIG1heSBldmVuIGJlIHdp bGxpbmcgdXNlcnMuKQ0KDQogICBjLiBUaGUgYnVuZGxlIHByb3RvY29sIGlzIG5vdCBtYXR1cmUu IERlZmljaWVuY2llcyBoYXZlIGJlZW4NCiAgICAgIGlkZW50aWZpZWQsIGRyYWZ0cyBoYXZlIGJl ZW4gd3JpdHRlbiBpbiBEVE5SRyBvdmVyIHRoZSB5ZWFycywNCiAgICAgIHRoZXJlIHdhcyBsaXR0 bGUgaW50ZXJlc3QsIHRoZSBkcmFmdHMgZXhwaXJlZCwgdGhlIGJ1bmRsZQ0KICAgICAgcHJvdG9j b2wgd2FzIG5ldmVyIGltcHJvdmVkLiBBbmQgdGhhdCdzIGp1c3QgZnJvbSBkZW1vbnN0cmF0aW9u czsNCiAgICAgIHRoZXJlIGhhcyBub3QgYmVlbiBleHRlbmRlZCBvcGVyYXRpb25hbCB1c2UgdG8g bXkga25vd2xlZGdlLg0KICAgICAgQXR0ZW1wdGluZyB0byBmaXggdGhlIGJ1bmRsZSBwcm90b2Nv bCBBTkQgcHVzaCBpdCB0aHJvdWdoIGFzDQogICAgICBzdGFuZGFyZHMgdHJhY2sgYXQgdGhlIHNh bWUgdGltZSBzZWVtcyB1bndhcnJhbnRlZC4NCiAgICAgIEl0IG1heSBiZSBwb2xpdGljYWxseSBt b3RpdmF0ZWQsIGJ1dCBpdCBpcw0KICAgICAgbm90IHRlY2huaWNhbGx5IG9yIHByb2NlZHVyYWxs eSBqdXN0aWZpYWJsZS4NCiAgICAgIFRoZXJlIGlzbid0IHRoZSB1c2VyYmFzZSBvciBkZW1hbmQg bmVlZGVkIGZvciB0aGUgYnVuZGxlDQogICAgICBwcm90b2NvbCB0byBnbyBzdGFuZGFyZHMgdHJh Y2ssIGFuZCBpZiB0aGUgSUVURiBkaWQgZ28NCiAgICAgIHN0YW5kYXJkcyB0cmFjaywgQ0NTRFMg d291bGQgJ29wdGltaXplJyB0aGF0IHN0YW5kYXJkIGludG8NCiAgICAgIGl0cyBvd24gc3RhbmRh cmQsIGp1c3QgYXMgd2FzIGRvbmUgd2l0aCBTQ1BTLCBtZWFuaW5nIHRoYXQNCiAgICAgIHRoZSBJ RVRGIHdvdWxkIHNwZW5kIGEgbG90IG9mIHRpbWUgd29ya2luZyBvbiBzb21ldGhpbmcgd2l0aA0K ICAgICAgbm8gYmVuZWZpdCB0byB0aGUgSUVURiBjb21tdW5pdHkgb3IgdXNlcmJhc2UuIEV4dGVu ZGluZw0KICAgICAgdGhlIEludGVybmV0IHByb3RvY29scyB0byB0aGUgRFROIG5ldHdvcmsgcHJv YmxlbSBzcGFjZQ0KICAgICAgYWRkcyB2YWx1ZSB0byB0aGUgaW50ZXJuZXQgcHJvdG9jb2xzLiBB IHNlcGFyYXRlIHByb3RvY29sDQogICAgICBkb2VzIG5vdC4NCiAgICAgIFdobyB3b3VsZCBiZW5l Zml0LCBvdXRzaWRlIHRoZSBDQ1NEUyBjb21tdW5pdHk/IEFuZCBDQ1NEUw0KICAgICAgaXMgdGhl aXIgb3duIHN0YW5kYXJkcyBvcmcgLSBhbiBJU08gc3ViZ3JvdXAgLSB0byBkbyB3b3JrDQogICAg ICBmb3IgdGhhdCBDQ1NEUyBjb21tdW5pdHkuDQoNCg0KMi4gSSBkb24ndCBzZWUgd2h5IHRoaXMg bmVlZHMgdG8gYmUgZG9uZSBpbiBhbiBJRVRGIFdHLCBiZWNhdXNlOg0KDQogICBhLiBnb2luZyBz dGFuZGFyZHMgdHJhY2sgaXNuJ3QganVzdGlmaWFibGUgLSBzZWUgMS4NCg0KICAgYi4gVGhlcmUn cyBhbHJlYWR5IHRoZSBJUlRGIERUTlJHLCB3aGljaCBjb3VsZCBjbGVhbiB1cCBpdHMNCiAgICAg IG93biB3b3JrLCBidXQgLGFmdGVyIG1hbnkgeWVhcnMgYW5kIHNvbWUgZmFpbGVkIGRyYWZ0cywN CiAgICAgIGhhcyBub3QuDQogICAgICBEZWNsYXJpbmcgc3VjY2VzcyBhbmQgc2F5aW5nIGl0IGlz IG5vdyB0aW1lIHRvIGNyZWF0ZSBhDQogICAgICBXRyBiYXNlZCBvbiBEVE5SRydzIGFjaGlldmVt ZW50cyBpcyBub3QgY29udmluY2luZywNCiAgICAgIGJlY2F1c2UgdGhvc2UgYWNoaWV2ZW1lbnRz IGFyZSBub3QgaW1wcmVzc2l2ZS4NCiAgICAgIChEaXNjbGFpbWVyIG9mIGludGVyZXN0OiBJIGF1 dGhvcmVkICdBIGJ1bmRsZSBvZiBwcm9ibGVtcycNCiAgICAgIGFuZCBoYXZlIHNwZW50IGNvbnNp ZGVyYWJsZSB5ZWFycyB0cnlpbmcgdG8gZXhwbGFpbiBhbmQNCiAgICAgIGFkZHJlc3MgcHJvYmxl bXMgd2l0aCB0aGUgYnVuZGxlIHByb3RvY29sLCB3aXRoIGxpdHRsZQ0KICAgICAgc3VjY2Vzcywg YWZ0ZXIgZ2V0dGluZyBpdCB0ZXN0ZWQgaW4gc3BhY2UgYmVmb3JlIE5BU0Encw0KICAgICAgRVhQ T1hJL0RlZXAgSW1wYWN0IHRlc3RzIHRvb2sgcGxhY2UuDQogICAgICBGcmVkIFRlbXBsaW4ncyBw cm9ibGVtIHN0YXRlbWVudCBkcmFmdHMgZm9yIHRoaXMgcHV0YXRpdmUNCiAgICAgIElFVEYgQk9G IGNhbGxzIG9uIHRoYXQgd29yay4pDQogICAgICBSRkM1MDUwYmlzIHdvdWxkIG1ha2UgbW9yZSBz ZW5zZSBhcyBhIERUTlJHDQogICAgICBlZmZvcnQsIHRob3VnaCBpdCB3b3VsZCBiZSB0aW1lIGZv ciBhIGNoYW5naW5nIG9mIHRoZQ0KICAgICAgZ3VhcmQgYW5kIGNoYWlycyBpbiBEVE5SRyB0byBp bmZ1c2Ugc29tZSBuZXcgYmxvb2QgYW5kDQogICAgICB0ZWNobmljYWwganVkZ2VtZW50IC0gb3Ig d2UncmUgaW4gZm9yIGFub3RoZXIgZml2ZSB5ZWFycw0KICAgICAgb2Ygd2hhdC1kb2VzLXRoZS1l bmQtdG8tZW5kLXByaW5jaXBsZS1yZWFsbHktbWVhbiBhbmQNCiAgICAgIHdoYXQtYWJvdXQtY2xv Y2tzIGFuZCByZWhhc2hpbmcgdGhlIHNhbWUgb2xkIGFyZ3VtZW50cy4NCiAgICAgIFJlYWxseSwg RFROUkcgbmVlZHMgdG8gZ2V0IGl0cyBhY3QgdG9nZXRoZXIsIGJvdGgNCiAgICAgIG9yZ2FuaXph dGlvbmFsbHkgYW5kIHRlY2huaWNhbGx5Lg0KDQogICBjLiBUaGVyZSdzIGFscmVhZHkgQ0NTRFMs IHdoaWNoIGhhcyBhZG9wdGVkIHRoZSBEVE5SRyBvdXRwdXQsDQogICAgICBhZnRlciBwdXNoaW5n IGZvciB0aGUgZm9ybWF0aW9uIG9mIGFuIEludGVycGxhbmV0YXJ5DQogICAgICBJbnRlcm5ldCBS RyBpbiB0aGUgZmlyc3QgcGxhY2UuDQoNClNvIGVpdGhlciBDQ1NEUyBvciBEVE5SRyBjYW4gZG8g UkZDNTA1MCByZXZpc2lvbiB3b3JrLiBJZg0KaXQncyB0byBiZSBhbiBSRkMsIGV4cGVyaW1lbnRh bCBvciBpbmZvcm1hdGlvbmFsLCBhIHJldml0YWxpc2VkDQpyZWNoYXJ0ZXJlZCBEVE5SRyBjYW4g ZG8gaXQuDQpJdCBkb2Vzbid0IG5lZWQgdG8gYmUgYW4gSUVURiB3b3JrZ3JvdXAuIEl0IGNlcnRh aW5seQ0Kc2hvdWxkbid0IGdvIHN0YW5kYXJkcyB0cmFjay4NCg0KDQozLiBUaGUgcGhpbG9zb3Bo aWNhbGx5IHNoYWt5IGJhc2lzIGZvciB0aGUgYnVuZGxlIHByb3RvY29sOg0KDQogICBhLiBEZWxh eS10b2xlcmFudCBuZXR3b3JraW5nIGlzIG5vdCBkaXNydXB0aW9uLXRvbGVyYW50DQogICAgICBu ZXR3b3JraW5nLiBTcGFjZSBkZWxheXMgb2YgbGlnaHQtbWludXRlcyB3aXRoIHNjaGVkdWxlZA0K ICAgICAgY29udGFjdHMgYXJlIG5vdCB0aGUgc2FtZSBhcyBpbnRlcm1pdHRlbnQgYWQtaG9jDQog ICAgICBtYW5ldC1zdHlsZSBjb21tdW5pY2F0aW9ucy4gRGlmZmVyZW50IHJlcXVpcmVtZW50cywN CiAgICAgIGRpZmZlcmVudCBidWZmZXJpbmcgYW5kIHN0b3JhZ2UsIGRpZmZlcmVudCBjb25kaXRp b25zLA0KICAgICAgZGlmZmVyZW50IGhhbmRsaW5nIG9mIGZyYWdtZW50YXRpb24sIGV0Yy4NCg0K ICAgYi4gVGhlIGJ1bmRsZSBwcm90b2NvbCBpcyBub3QgRFROLiBEVE4gaXMgdGhlIHNjZW5hcmlv LA0KICAgICAgaW4gd2hpY2ggb3RoZXIgYXBwcm9hY2hlcyAodGhlIHJlbGF0ZWQgQ0ZEUCwgSGFn Z2xlLA0KICAgICAgdGhlIE1BTkVUIGFuZCB2ZWhpY3VsYXIgRFROcyBlZmZvcnRzIHRoYXQgRFRO IHN1YnN1bWVkDQogICAgICBhbmQgcmVicmFuZGVkLCBldGMuKSBleGlzdC4NCiAgICAgIFRoZSBi dW5kbGUgcHJvdG9jb2wgaXMgaW50ZW5kZWQgdG8gYmUgdXNlZCBpbiBhIERUTg0KICAgICAgc2Nl bmFyaW8uIEJyYW5kaW5nIHRoZSBidW5kbGUgcHJvdG9jb2wgYXMgRFROIGhhcw0KICAgICAgcHV0 IGJhY2sgbm9uLWJ1bmRsZSBEVE4gcmVzZWFyY2ggYSBudW1iZXIgb2YgeWVhcnMuDQogICAgICBC cmFuZGluZyBhIGdyb3VwIG9ubHkgd29ya2luZyBvbiB0aGUgYnVuZGxlIHByb3RvY29sDQogICAg ICBhcyAnRFROJyBpcyBtaXNsZWFkaW5nIGF0IGJlc3QuDQoNCiAgIGMuIEV4dGVuZGluZyB0aGUg YnVuZGxlIHByb3RvY29sIGZyb20gdGhlIG9yaWdpbmFsDQogICAgICBJbnRlcnBsYW5ldGFyeSBJ bnRlcm5ldCBwcm9ibGVtICh3aGljaCBoYWQgaXRzIG93bg0KICAgICAgSVJURiBSRyB3aGljaCBs ZWQgaW50byBhIHNldCBidW5kbGUgYWdlbmRhIGZvcg0KICAgICAgRFROUkcpIHRvIGNvdmVyIGV2 ZXJ5dGhpbmcgZWxzZSBhcyB3ZWxsIHNpbXBseSBoYXNuJ3QNCiAgICAgIHdvcmtlZCB2ZXJ5IHdl bGwsIGJlY2F1c2UgdGhlIHNjZW5hcmlvcyBhbmQgdXNlIGNhc2VzDQogICAgICBhcmUgZGlmZmVy ZW50LiBXZSBkZXNpZ24gZm9yIHVzZSBjYXNlcy4gVG8gYmUgdG9vDQogICAgICBnZW5lcmFsaXNl ZCBpcyB0byBlbmdpbmVlciBmb3Igbm90aGluZy4NCg0KICAgZC4gSWdub3JpbmcgdGhlIHJhbWlm aWNhdGlvbnMgb2YgdGhlIGVuZC10by1lbmQgcHJpbmNpcGxlLA0KICAgICAgd2hpY2ggYXJlIG9m dGVuIG1vcmUgc3VidGxlIHRoYW4gcGVvcGxlIHNlZW0gdG8gdGhpbmsNCiAgICAgIHRoZXkgYXJl LiBUaGUgYnVuZGxlIHByb3RvY29sJ3MgY3VzdG9keSB0cmFuc2Zlcg0KICAgICAgcHJvY2VkdXJl IGlzIGEgZ29vZCBleGFtcGxlIG9mIHRoaXMgZmFpbGluZy4NCg0KICAgZS4gVGhlIGJ1bmRsZSBw cm90b2NvbCBpcyBpbnRlbmRlZCBmb3IgdXNlIGluIHRoZSBtb3N0DQogICAgICBkaWZmaWN1bHQg bm9pc3kgZGlzcnVwdGVkIG5ldHdvcmtpbmcgY29uZGl0aW9ucyB3ZSBrbm93LA0KICAgICAgYW5k IGl0IGNhbid0IGV2ZW4gc2FuaXR5IGNoZWNrIGl0cyBvd24gaGVhZGVycyBhZ2FpbnN0DQogICAg ICBlcnJvcnMuIChCdXQgaGV5LCBpdCBub3cgaGFzIGEgc2VjdXJpdHkgcHJvdG9jb2wgdGhhdA0K ICAgICAgX2FsbW9zdF8gZG9lcyB0aGF0ISBCdXQgd2hpY2ggaXMgdG9vIGNvbXBsaWNhdGVkLCBh bmQNCiAgICAgIHdvdWxkIG5lZWQgdG8gYmUgcmVkb25lLikNCiAgICAgIEl0J3MgaW50ZW5kZWQg Zm9yIHRoZSBoYXJzaGVzdCBlbnZpcm9ubWVudHMgd2Uga25vdywNCiAgICAgIGJ1dCBuZWVkcyBy ZWxpYWJsZSBzeW5jaHJvbml6ZWQgY2xvY2tzIHJ1bm5pbmcgYXQNCiAgICAgIHN0ZWFkeSB0ZW1w ZXJhdHVyZXMhDQogICAgICBJdCdzIGludGVuZGVkIGZvciBlbWJlZGRlZCBzeXN0ZW1zLCBidXQg dGhlIGRlc2lnbg0KICAgICAgaXMgaHVnZSBhbmQgY29tcGxleCEgKENGRFAgaGFzIHRoZSBzYW1l IHByb2JsZW07DQogICAgICB0aGVyZSdzIGEgcmVhc29uIGltcGxlbWVudGVycyB3ZW50IGZvciBh ICJDRkRQIGxpdGUsIg0KICAgICAgYW5kIFNhcmF0b2dhIGV4aXN0cyBqdXN0IGJlY2F1c2UgQ0ZE UCB3YXNuJ3QgcGVyZm9ybWluZy4NCiAgICAgIFdvdWxkIFJGQzUwNTBiaXMgYmUgImJ1bmRsaW5n IGxpdGUiPykNCiAgICAgIFRoZXJlIGFyZSBtYW55ICd0aGF0IG1ha2VzIG5vIHNlbnNlJyBtb21l bnRzIC0gbm9ybWFsbHkNCiAgICAgIG1vcmUgaW1tZWRpYXRlbHkgdmlzaWJsZSB0byBvdXRzaWRl cnMgbm90IHN0ZWVwZWQgaW4NCiAgICAgIHRoZSBkb2dtYSwgcG9saXRpY3MsIGFuZCBoaXN0b3J5 IG9mIERUTlJHIGFuZCBDQ1NEUy4NCg0KICAgZi4gVGhlIGFzc3VtcHRpb24gdGhhdCBhIGZ1bGwg c2VjdXJpdHkgc3VpdGUgaXMgZGVzaXJhYmxlDQogICAgICBhbmQgbmVjZXNzYXJ5IGF0IGFsbCB0 aW1lcy4gVGhpcyBoYXMgZGVyYWlsZWQgRFROUkcsDQogICAgICBhcyBlbXBoYXNpcyB3YXMgcGxh Y2VkIG9uIHNlY3VyaXR5IHdvcmsgYWJvdmUgYWxsDQogICAgICBlbHNlLCByYXRoZXIgdGhhbiB3 b3JraW5nIHRvIHRoZSBzY2VuYXJpby4gVG8gYmUgZmFpcg0KICAgICAgdG8gdGhlIHNlY3VyaXR5 LWZvY3VzZWQgY2hhaXJzLCB0aGUgY2hhcnRlciB0aGF0DQogICAgICBlc3RhYmxpc2hlZCBEVE5S RyBmcm9tIHRoZSBpbnRlcnBsYW5ldGFyeSBpbnRlcm5ldA0KICAgICAgcmVzZWFyY2ggZ3JvdXAg Y2FsbGVkIG91dCBzZWN1cml0eSBoZWF2aWx5LCBhbmQgdGhleQ0KICAgICAgcmFuIHdpdGggdGhh dCBtYW5kYXRlLiBCdXQgdGhlIGZvY3VzIGhhcyBkZWNyZWFzZWQNCiAgICAgIHdvcmsgb24gbm9u LXNlY3VyaXR5IG1hdHRlcnMsIHdoaWNoIGlzIHRvIHNheSwNCiAgICAgIGV2ZXJ5dGhpbmcgZWxz ZS4NCg0KUkZDNTA1MGJpcyBtaWdodCBhZGRyZXNzIHRoZSBsYXR0ZXIgdGhyZWUgcHJvYmxlbXMs IGJ1dA0KdGhlIGZpcnN0IHRocmVlIGFyZSBpbnRyaW5zaWNhbGx5IHVuc29sdmFibGU7IGFueSBz b2x1dGlvbg0Kd2lsbCBiZSB1bnNhdGlzZmFjdG9yeS4gUGVyaGFwcyBub3QgYXMgdW5zYXRpc2Zh Y3RvcnkgYXMNClJGQzUwNTAsIGJ1dCB1bnNhdGlzZmFjdG9yeSBub25ldGhlbGVzcy4NCg0KVGhl IHJlYWwgcGhpbG9zb3BoaWNhbCBwcm9ibGVtIGhlcmUgaXMgdGhlIHBvbGl0aWNhbCBkb2dtYQ0K dGhhdCwgd2hhdGV2ZXIgdGhlIHByb2JsZW0sIHRoZSBidW5kbGUgcHJvdG9jb2wgaXMgVGhlDQpP bmUgVHJ1ZSBTb2x1dGlvbi4NCg0KDQo0LiBUaGUgZHJhZnQgQk9GIGNoYXJ0ZXIgaXMgYnVuZGxl LWNlbnRyaWMuIFdoaWNoIGlzIHRvIHNheSwNCiAgIHRoYXQgaXQncyBub3QgYXdmdWxseSByZWxl dmFudCB0byBpbnRlcm5ldCBzdGFuZGFyZHMuDQogICBEaXNjbGFpbWVyIG9mIGludGVyZXN0OiB3 ZSd2ZSB3b3JrZWQgb24gU2FyYXRvZ2EgYW5kDQogICBIVFRQLURUTiwgd2hpY2ggaGF2ZSBjdXJy ZW50IGludGVybmV0LWRyYWZ0cywgYW5kIGFyZQ0KICAgc3F1YXJlbHkgaW4gdGhlIERUTiBwcm9i bGVtIHNwYWNlLg0KICAgV2hlbmV2ZXIgc29tZW9uZSB0YWxrcyBhYm91dCBtdWx0aXBsZSBjb252 ZXJnZW5jZQ0KICAgbGF5ZXJzIGZvciB0aGUgYnVuZGxlIHByb3RvY29sIC0gdGhlcmUncyBtb3Jl IHRoYW4gZm9yIEJFRVAsDQogICB3aGljaCBqdXN0IGhhcyBUQ1AsIGJ1dCB0aGVyZSBhcmVuJ3Qg bWFueSAtIFNhcmF0b2dhIG1heQ0KICAgYmUgbWVudGlvbmVkLiBCdXQgd2UndmUgZm91bmQgdGhh dCBjYXJyeWluZyBidW5kbGVzIGRvZXNuJ3QNCiAgIGJlbmVmaXQgU2FyYXRvZ2EgLSB0ZXN0ZWQg aXQgaW4gc3BhY2UsIGRpZG4ndCBzZWUgdGhlDQogICBhZHZhbnRhZ2VzLiBTYXJhdG9nYSBkb2Vz IGxldmVyYWdlIGEgZmV3IEludGVybmV0IHRoaW5ncyAtDQogICBVRFAsIFVEUC1MaXRlLCBtdWx0 aWNhc3QuIEl0IGRvZXMgYSBmZXcgc2NhbGluZyB0aGluZ3MgdGhhdA0KICAgbm90aGluZyBlbHNl IEkndmUgc2VlbiBkb2VzIChkZXNjcmliZWQgaW4gb3VyIDIwMTEgVFNWQVJFQQ0KICAgcHJlc2Vu dGF0aW9uIHRvIElFVEYgODggaW4gTm92ZW1iZXIuKSBBbmQgaXQncyBiYXNlZCBvbg0KICAgYSBk ZWNhZGUgb2Ygb3BlcmF0aW9uYWwgdXNlIGluIHRoZSBwcm9ibGVtIGRvbWFpbi4NCiAgIEhUVFAt RFROIGxldmVyYWdlcyB0aGUgSFRUUCBzdWl0ZSBhbmQgTUlNRSwgYW5kIGNvbWVzIHVwDQogICB3 aGVuZXZlciB3b3VsZG4ndC1pdC1iZS1uaWNlLXRvLXRyeS1IVFRQLWZvci1EVE4gZGlzY3Vzc2lv bg0KICAgdGFrZXMgcGxhY2UuDQogICAoSSBzdXNwZWN0IHRoYXQgYWxsIG9mIFN0ZXBoZW4gRmFy cmVsbCdzIE40QyB3b3JrIGNvdWxkDQogICBoYXZlIGJlZW4gZG9uZSBvdmVyIGhvcC1ieS1ob3Ag SFRUUCBhIGxhIEhUVFAtRFROLCBhbmQNCiAgIHdvdWxkIGhhdmUgd29ya2VkIGp1c3QgYXMgd2Vs bCBpZiBub3QgYmV0dGVyLiBBZnRlciBhbGwsDQogICBpdCB1c2VkIFRDUC4pDQogICBUaGVzZSBh bmQgb3RoZXIgZWZmb3J0cyBleGlzdCBpbiBhIGdhcCBiZXR3ZWVuIERUTlJHLCB3aGljaA0KICAg aXMgYXdhcmUgb2YgdGhlIHByb2JsZW0gc3BhY2UsIGJ1dCB0aGlua3MgdGhlIGJ1bmRsZQ0KICAg cHJvdG9jb2wgaXMgdGhlIHNvbHV0aW9uIGRlc3BpdGUgbW91bnRpbmcgZXZpZGVuY2UgdG8gdGhl DQogICBjb250cmFyeSwgYW5kIFRTVldHLCB3aGVyZSB0aGUgZmV3IGFjdHVhbCB0cmFuc3BvcnQN CiAgIGV4cGVydHMgbGl2ZSwgd2l0aG91dCBjbG91dCwgb3IgZnVuZGluZywgb3Igc3BhcmUgdGlt ZS4NCiAgIFRob3NlIGVmZm9ydHMgYXJlIGludGVyZXN0aW5nIGVub3VnaCB0byBoYXZlIGltcGxl bWVudGF0aW9ucw0KICAga2lja2luZyBhcm91bmQgdG9vLg0KICAgQW5kIHlldCwgdGhlIGZvY3Vz IG9mIHRoaXMgcHV0YXRpdmUgd29ya2dyb3VwIGFuZCBCT0YgaXMNCiAgIHNvbGVseSBvbiBidW5k bGluZywgYW5kIG5vdCBvbiBldmFsdWF0aW5nIHRoZXNlIG9yIG90aGVyDQogICB0aGluZ3MgdGhh dCBtaWdodCBleGlzdCBpbiB0aGUgcHJvYmxlbSBzcGFjZS4gVGhlcmUNCiAgIG11c3QgYmUgb3Ro ZXIgdGhpbmdzIG91dCB0aGVyZSB0aGF0IHdvdWxkIGJlIG9mIGludGVyZXN0DQogICB0byBzdWNo IGEgRFROIHdvcmtncm91cC4gV2hhdCBpcyBwcm9wb3NlZCBpcyBub3QgYSBEVE4NCiAgIHdvcmtn cm91cC4gVGhlIGNoYXJ0ZXIgaXMgYmFzaWNhbGx5IGEgYnVuZGxlIHdvcmtncm91cC4NCiAgIENh biBhbiBpbnRlcmVzdCBpbiBidW5kbGluZyBhbmQgc29sZWx5IGJ1bmRsaW5nIChvdXRzaWRlDQog ICBDQ1NEUywgd2hpY2ggaXMgZHJpdmluZyB0aGUgcHVzaCB0byB1c2UgdGhlIGJ1bmRsZSBwcm90 b2NvbCkNCiAgIGJlIGp1c3RpZmllZCBmb3IgYW4gSUVURiB3b3JrZ3JvdXA/IEkgcmVhbGx5IGRv bid0IHRoaW5rIHNvLg0KDQo1LiBUaGUgYnVuZGxlIHByb3RvY29sIHdvcmsgd2FzLCBJIGdhdGhl ciwgd2VsbC1mdW5kZWQNCiAgIGJ5IGEgbnVtYmVyIG9mIHBhcnRpZXMuDQogICBJIGNhbid0IHNl ZSBhIGZvbGxvdy1vbiBlZmZvcnQgYmVpbmcgYW55d2hlcmUgbmVhcg0KICAgYXMgd2VsbCBmdW5k ZWQuDQoNCiAgIGEuIEkgaGF2ZSBubyBpZGVhIGhvdyBtdWNoIG1vbmV5IE5BU0EgYW5kIENDU0RT IGhhdmUgcHV0DQogICAgICBpbnRvIHRoaXMgLSBmaXJzdCBDRkRQLCB0aGVuIGJ1bmRsaW5nLCB3 aGljaCBub3cgaGFzDQogICAgICB0byBwcm92aWRlIGEgQ0ZEUC1saWtlIEFQSSB0byB0aGUgdXNl cnMgd2hvIHdlcmUgdG9sZA0KICAgICAgdGhhdCBDRkRQIHdhcyB0aGUgZnV0dXJlLCBhbmQgTGlj a2xpZGVyIChMVFApLg0KICAgICAgRHJhZ2dpbmcgQ0NTRFMgaW50byB0aGUgbW9kZXJuIGFnZSBv ZiBuZXR3b3JraW5nDQogICAgICBzZWVtcyB1bmxpa2VseSB0byBldmVyIGhhcHBlbiwgdGhhbmtz IHRvIENDU0RTIGhhdmluZw0KICAgICAgbGl0dGxlIGluIHRoZSB3YXkgb2Ygc2FuZSBsYXllcmlu ZyBvciBzZXBhcmF0aW9uIG9mDQogICAgICBmdW5jdGlvbmFsaXR5Lg0KICAgICAgSSBkbyBoYXZl IHRoZSBsdXh1cnkgb2Ygbm90IG5lZWRpbmcgdG8gd29yayBvbiBDQ1NEUy4NCiAgICAgIEJ1dCBp ZiB5b3Ugd2FudCB0byB3b3JrIG9uIENDU0RTIHByb3RvY29scywgQ0NTRFMgaXMNCiAgICAgIHRo ZSBwbGFjZSB0byBnby4gVGhlIElFVEYgaXMgbm90IHRoYXQgcGxhY2UuDQoNCiAgIGIuIERBUlBB IHBvdXJlZCBtb25leSBpbnRvIERUTiB3b3JrIC0gYXQgbGVhc3QgdHdlbnR5DQogICAgICBtaWxs aW9uIGRvbGxhcnMsIGZyb20gdGhlIHByZXNzIHJlbGVhc2VzIEkndmUgc2Vlbi4NCiAgICAgIEkg aGF2ZSBubyBpZGVhIHdoYXQgREFSUEEgZ290IG91dCBvZiBpdCBpbiB0aGUNCiAgICAgIHllYXJz IHRoZXkgd2VyZSBpbnZvbHZlZDsgaGF2ZW4ndCBzZWVuIHRoZSByZXBvcnRzLg0KDQpNeSBwb2lu dCBpcywgYWxsIHRoYXQgbW9uZXkgYW5kIGVmZm9ydCBhbmQgbWFucG93ZXIgYW5kDQpvdmVyIGEg ZGVjYWRlIG9mIHdvcmsgYW5kIHByaW9yIGV4cGVyaWVuY2Ugd2l0aCBDRkRQIGFuZCB0d28NCklS VEYgUkdzLCB3ZSBoYXZlLi4uIFJGQzUwNTAuDQpUaGVyZSBpcyBub3doZXJlIG5lYXIgYXMgbXVj aCBtb25leSBvciBlZmZvcnQgb3IgbWFucG93ZXINCmZvciBkb2luZyBhIHJlcGxhY2VtZW50Lg0K RXJnbywgaXQgbWlnaHQgYmUgc3VnZ2VzdGVkIHRoYXQgdGhlIHJlcGxhY2VtZW50IGlzIHVubGlr ZWx5DQp0byBiZSBhcyBnb29kIGFzIFJGQzUwNTAsIG9yIGFzIGdvb2QgYXMgQ0ZEUDsgYXQgYmVz dCwNCnRoZSB1c3VhbCBzdXNwZWN0cyB3aWxsIGhhdmUgbGVzcyB0aW1lIGFuZCBmZXdlciByZXNv dXJjZXMNCnRvIHJlcGVhdCB0aGVpciBvcmlnaW5hbCBtaXN0YWtlcy4NCg0KQW5kIHRyYW5zcG9y dCBleHBlcnRpc2UgZnJvbSBUU1ZXRyB3b3VsZCBiZSBuZWVkZWQuDQpUU1ZXRyBpcyB1bmZhc2hp b25hYmxlLCBsb3ctdmlzaWJpbGl0eSwgYW5kIGhhcyBldmVuDQpwcmV2aW91c2x5IGhhZCB0cm91 YmxlIGZpbmRpbmcgQURzIHdpdGggcmVsZXZhbnQgZXhwZXJ0aXNlLg0KQW5kIFRTVldHIGhhcyBh IGZ1bGwgcGxhdGUgd2l0aCB3b3JrIG9uIGl0cyBleGlzdGluZw0KcHJvdG9jb2xzOyB0aGVyZSBp cyBub3QgYSBsb3Qgb2YgZXhwZXJ0aXNlLCBhbmQgd2hhdCB0aGVyZQ0KaXMgaXMgc3ByZWFkIHRo aW4uDQpTbyBhbiBSRkM1MDViaXMgZWZmb3J0IGlzIHVubGlrZWx5IHRvIGdldCB0aGUgZXhwZXJ0 DQp0ZWNobmljYWwgaW5wdXQgdGhhdCBpdCBzb3JlbHkgbmVlZHMsIGV2ZW4gaWYgYW4gSUVURg0K d29ya2dyb3VwIGlzIHNldCB1cC4gKENDU0RTIGRvZXNuJ3QgaGF2ZSB0aGF0IHRyYW5zcG9ydA0K Zm9jdXMuKQ0KDQpJZiwgb24gdGhlIG90aGVyIGhhbmQsIHlvdSBiZWxpZXZlIGdvb2QgcHJvdG9j b2wgZGVzaWduDQpjYW4gYmUgZG9uZSBtb3JlIGNoZWFwbHkgYW5kIGxldmVyYWdlIGFjdHVhbCBJ bnRlcm5ldA0Kc3RhbmRhcmRzIHRvIGdldCBJbnRlcm5ldCBmdW5jdGlvbmFsaXR5IHdvcmtpbmcg aW4NCmRpZmZpY3VsdCBuZXR3b3JrcyB3aGVyZSB0aGUgZnVsbCBUQ1AvSVAgc3VpdGUgaGFzDQp0 cm91YmxlLCB5b3VyIG9wdGlvbnMgaW5jbHVkZSBTYXJhdG9nYSBhbmQgSFRUUC1EVE4hDQpodHRw Oi8vc2FyYXRvZ2Euc291cmNlZm9yZ2UubmV0Lw0KaHR0cDovL3NhdC1uZXQuY29tL0wuV29vZC9k dG4vaHR0cC1kdG4uaHRtbA0KVGhleSdsbCB0cnVseSBleHRlbmQgdGhlIEludGVybmV0IHRvIGRp ZmZpY3VsdA0KZW52aXJvbm1lbnRzLiBUaGUgYnVuZGxlIHByb3RvY29sIHdvbid0Lg0KDQpTbywg dG8gY29uY2x1ZGUsIHRoZXJlIGlzIG5vIGp1c3RpZmljYXRpb24gZm9yIGdvaW5nDQpzdGFuZGFy ZHMgdHJhY2suIFRoZXJlIGlzIGxpdHRsZSBqdXN0aWZpY2F0aW9uIGZvciBhbg0KSUVURiB3b3Jr Z3JvdXAuIFRoZXJlIGlzIG1vcmUgbG9naWMgaW4gcmVjaGFydGVyaW5nIGFuZA0KcmVwdXJwb3Np bmcgdGhlIElSVEYgRFROUkcsIGJ1dCB0aGUgd29yayBtYXkgYXMgd2VsbA0KYmUgbGVmdCB0byBD Q1NEUyBlbnRpcmVseS4NCg0KUkZDNTA1MGJpczogaGFsZi1hc3NlZCwgaGFsZi1iYWtlZCwgcmVo ZWF0ZWQuDQpCdXQgaGV5LCBhc2sgbWUgd2hhdCBJIF9yZWFsbHlfIHRoaW5rLg0KDQpMbG95ZCBX b29kDQpodHRwOi8vc2F0LW5ldC5jb20vTC5Xb29kL2R0bi8NCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmR0biBtYWlsaW5nIGxpc3QNCmR0bkBpZXRm Lm9yZzxtYWlsdG86ZHRuQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9kdG4NCg0KDQoNCi0tDQpUaGUgcHJvYmxlbSB3aXRoIHRoZSB3b3JsZCBpcyB0aGF0 IHRoZSBpbnRlbGxpZ2VudCBwZW9wbGUgYXJlIGZ1bGwgb2YgZG91YnRzLA0Kd2hpbGUgdGhlIHN0 dXBpZCBvbmVzIGFyZSBmdWxsIG9mIGNvbmZpZGVuY2UuDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgLSBDaGFybGVzIEJ1a293c2tpDQoNCg0KDQotLQ0KVGhlIHByb2JsZW0gd2l0aCB0aGUgd29y bGQgaXMgdGhhdCB0aGUgaW50ZWxsaWdlbnQgcGVvcGxlIGFyZSBmdWxsIG9mIGRvdWJ0cywNCndo aWxlIHRoZSBzdHVwaWQgb25lcyBhcmUgZnVsbCBvZiBjb25maWRlbmNlLg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIC0gQ2hhcmxlcyBCdWtvd3NraQ0K --_000_2134F8430051B64F815C691A62D983181B2BF56CXCHBLV504nwnosb_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENo YXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4 LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5IaSBFcmljLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SXQgaXMgdHJ1ZSB0aGF0IGhhdmluZyBhbiBvZmZpY2lhbCBJ RVRGIHN0YW5kYXJkIGlzIG5vdCBhIG5lY2Vzc2FyeSBwcmVjb25kaXRpb24gZm9yIG9uZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5vciBtb3JlICZuYnNwO3ZlbmRvcnMgdG8gbW92ZSBm b3J3YXJkIHdpdGggd2lkZWx5LWRlcGxveWVkIGltcGxlbWVudGF0aW9ucy4gSSBzaG91bGQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+a25vdzsgSSB3cm90ZSBvbmU6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 YSBocmVmPSJodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM1MjE0LnR4dCI+aHR0cDov L3d3dy5yZmMtZWRpdG9yLm9yZy9yZmMvcmZjNTIxNC50eHQ8L2E+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CdXQsIGhh dmluZyBhbiBJRVRGIHN0YW5kYXJkIGlzIGEgZGVtb25zdHJhdGlvbiB0aGF0IHJvdWdoIGNvbnNl bnN1cyBoYXMgZGVlbWVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPnRoZSB3b3JrIGFz IHN0YW5kYXJkcy13b3J0aHkg4oCTIGEgY29tbXVuaXR5IHN0YW1wIG9mIGFwcHJvdmFsLCBvciBh dCBsZWFzdCDigJxubzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5vYmplY3Rpb27igJ0u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5BYm91dCBsZXZlbCBvZiBpbnRlcmVzdCwgJm5ic3A7SSBiZWxpZXZlIHRoZXJl IGlzIHN0aWxsIGVuZXJneSBpbiBEVE5SRyBhbmQgYXQgbGVhc3Qgc29tZSBvZjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj50aGF0IGVuZXJneSBpcyBzcGlsbGluZyBvdmVyIGludG8gdGhl c2UgZGlzY3Vzc2lvbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MgLSBGcmVkPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gRXJpYyBUcmF2aXMg W21haWx0bzplcmljLmRvdC50cmF2aXNAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRo dXJzZGF5LCBKdW5lIDA1LCAyMDE0IDExOjI0IEFNPGJyPg0KPGI+VG86PC9iPiBUZW1wbGluLCBG cmVkIEw8YnI+DQo8Yj5DYzo8L2I+IGwud29vZEBzdXJyZXkuYWMudWs7IG1scy5pZXRmQGdtYWls LmNvbTsgc3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb207IGR0bkBpZXRmLm9yZzsgaWVzZ0Bp ZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2R0bl0gRFROIEJvRiBQcm9wb3NhbCBm b3IgSUVURjkwPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkhpIEZyZWQsPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoaWxlIEkgd2Fzbid0IGlu dGVuZGluZyB0byBhZHZvY2F0ZSBlaXRoZXIgd2F5IG9uIHRoZSBpdGVtczo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+VG8gcG9pbnQgMSksIGFkdmFuY2VtZW50IG9mIHdvcmsgaXRlbXMgaW4g dGhlIElFVEYgaXMgdXN1YWxseSBiYXNlZCBvbiDigJxyb3VnaCBjb25zZW5zdXM8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5hbmQgcnVubmluZyBjb2Rl4oCdIGFuZCB0aGVyZSBpcyBw bGVudHkgb2YgaW50ZXJvcGVyYWJsZSBydW5uaW5nIGNvZGUgdGhhdCBpbXBsZW1lbnRzPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UkZDNTA1MCBhbmQgaXRzIHJlbGF0ZWQgc3BlY2lm aWNhdGlvbnMg4oCTIG11Y2ggbW9yZSB0aGFuIG1vc3QgSUVURiBhY3Rpdml0aWVzIGFyZSBiYXNl ZCBvbi4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk15Jm5ic3A7ICZxdW90O3BvaW50cyB3b3J0aHkgb2YgZGlzY3Vz c2lvbi9kZWJhdGUgdGhyb3VnaG91dCB0aGUgQm9GIHByb2Nlc3MmcXVvdDsgc2VlbXMgdG8gYmUg Y29tcGF0aWJsZSB3aXRoIHlvdXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5BcyB0byDigJxyb3VnaCBjb25zZW5zdXPigJ0sIGhvbGRpbmcgYSBCb0YgaXMgdGhl IGZpcnN0IHN0ZXAgaW4gZGV0ZXJtaW5pbmcgdGhhdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KSSdkIGNvbnRl bmQgdGhhdCB0aGUgKkRUTlJHKiB3YXMgdGhlIHN0YXJ0IG9mIHRoYXQgZGlzY3Vzc2lvbi4mbmJz cDsgVGhlICpCb0YqIGlzIGEgY29udGludWF0aW9uIG9mIGEgNyYjNDM7IHllYXIgY29tbXVuaXR5 IGRpc2N1c3Npb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NClRoZXJlIGlzIGFuIGV4cGVyaW1lbnRhbCBSRkMgdGhhdCBoYXMgYWNo aWV2ZWQgaW50ZXJvcGVyYWJpbGl0eSBiZXR3ZWVuIG11bHRpcGxlIGluZGVwZW5kZW50IGltcGxl bWVudGF0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+VGhhdCwgaG93ZXZlciwgaXNuJ3Qg bmVjZXNzYXJpbHkgYSByZWZlcmVuZHVtIG9uIHRoZSBtYXR1cml0eSBvZiB0aGUgcHJvdG9jb2wo cykgdGhlbXNlbHZlcy4mbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Rm9yIHRob3NlIGVudGl0aWVzIHdob3NlIG5lZWRzIGFyZSBzYXRp c2ZpZWQgd2l0aCBSRkMtNTA1MCwgYSBzdGFuZGFyZHMtdHJhY2sgZG9jdW1lbnQgaXMgbm90IG5l Y2Vzc2FyeSBmb3IgZGVwbG95bWVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkFjdHVhbGx5LCBhIHN0YW5kYXJkcy10cmFjayBkb2N1bWVudCBp cyBuZXZlciAqcmVhbGx5KiBuZWNlc3NhcnkuJm5ic3A7IFRoZXJlIGFyZSBtYW55IG1pZGRsZXdh cmUvYXBwbGljYXRpb24gbGV2ZWwgJnF1b3Q7dGhpbmdzJnF1b3Q7IGRlcGxveWVkDQo8YnI+DQp0 aGF0IGFyZSBub3QgYmFzZWQgb24gSUVURiBzdGFuZGFyZHMuJm5ic3A7IFRoZSBwcmVzdW1wdGlv biBvZiB0aGUgQm9GIHNlZW1zIHRvIGJlIHRoYXQgUkZDLTUwNTAgaXMgTk9UICZxdW90O3RoZXJl IHlldCZxdW90Oy4mbmJzcDsgU28sIHRoZTxicj4NCnF1ZXN0aW9uIGlzIGhvdyBjbG9zZSB0byBt YXR1cml0eSBpcyBjbG9zZSBlbm91Z2ggdG8gZ28gaW50byBhIHN0YW5kYXJkcyB0cmFqZWN0b3J5 LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpGcm9tIHRoZSBkaXNjdXNzaW9ucyBvbiB0 aGUgbGlzdCwgdGhlcmUgaGFzIGJlZW4gYSBsb3Qgb2YgdmVyeSBwcm9taXNpbmcgZGlhbG9nIG9m IHRoZSBuYXR1cmUgb2YNCjxicj4NCiZxdW90O1llYWgsIGl0IHdvdWxkIGJlIHVzZWZ1bCB0byAq ZXhwbG9yZSogRm9vIGFuZC9vciBCYXImcXVvdDssIGZyb20gc29tZSBwZW9wbGUgdGhhdCAtIGZy YW5rbHkgLSBwbGVhc2FudGx5IHN1cnByaXNlZCBtZS4mbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBsZWFkcyB0byB0aGUgcXVl c3Rpb24gLSBoYXMgdGhlIHNvbHV0aW9uIHNwYWNlIGJlZW4gYWRlcXVhdGVseSBleHBsb3JlZCB0 byBoYXZlIGNvbmZpZGVuY2UgdGhhdCB0aGUgcmVzdWx0IGlzPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPmEgbWF0dXJlIChOT1QgcGVyZmVjdCk/Jm5ic3A7IElmIG5vdCwgd2lsbCB0aGUgV0cgYmUg YWJsZSB0byB0YWtlIGl0IGZ1cnRoZXIgdGhhbiB0aGUgUkcgd2FzIGNhcGFibGUgKGFuZCB3aHkg aXMgdGhhdCB0cnVlKT88YnI+DQo8YnI+DQpUaGF0J3MgYSBxdWVzdGlvbiwgbm90IGEgc3RhdGVt ZW50IG9uIG15IHBhcnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5UbyBwb2ludCAyKSwgYWdhaW4gdGhlIEJvRiB3aWxsIHByb3ZpZGUgYSB1c2VmdWwgbWVh c3VyZW1lbnQgb2YgaW50ZXJlc3QuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGUgbGV2ZWwgb2YgaW50 ZXJlc3QgaXMgcmVsYXRpdmVseSBoaWdoIHdpdGhpbiB0aGUgRFROUkcgLSBhbmQgd2lsbCBsaWtl bHkgYmUgc28gZm9yIGEgRFROIFdHLiZuYnNwOyBUaGUgcXVlc3Rpb248bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnJlYWxseSBpcyBpZi9ob3cgd2ls bCB0aGF0IHRyYW5zbGF0ZSBpbnRvIG1lYXN1cmFibGUgcHJvZ3Jlc3MgKGZpeGluZyB0aGUgLSBz b21lIGxvbmcgYWNrbm93bGVkZ2VkIC0gbml0cyBpbiB0aGUgcHJvdG9jb2w8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+c3BlY2lmaWNhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+VGhlIG9y aWdpbmFsIGlkZWEgb2YgYSBSRkM1MDUwLkJpcyB3YXMgZmxvYXRlZCB0d28gKHRocmVlPykgeWVh cnMgYWdvIGFzIHBhcnQgb2YgdGhlIG1vc3QgcmVjZW50IEdvb2dsZSBtZWV0aW5nLiZuYnNwOyBJ dCBmYWlsZWQgdG8gZ2Fpbjxicj4NCnRyYWN0aW9uLCBkZXNwaXRlIHdoYXQgc2VlbWVkIHRvIGJl IGEgZmFpciBhbW91bnQgb2YgY29tbXVuaXR5IGludGVyZXN0LjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij5JcyB0aGUgbGFjayBvZiBtb3ZlbWVudCB3aXRoaW4gdGhlIERUTlJHIHNpbXBseSBiZWNh dXNlIG9mIHRoZSAobGFjayBvZikgcGF0aCB0byBhIHN0YW5kYXJkcyB0cmFjayBSRkM/PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPlRoZSBxdWVzdGlvbiBmb3IgdGhlIEJvRiBpcywgd2hhdCBjYXVz ZWQgdGhlIGV2b2x1dGlvbmFyeSBwYXVzZSwgYW5kIGhvdyB3aWxsIGEgV0cgcHJldmVudCBpdCBm cm9tIHN0YWxsaW5nIGFnYWluLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8YnI+DQpK dXN0IHRvIGJlIGNsZWFyLCZuYnNwOyBJJ20gaW4gZmF2b3Igb2YgYSBCb0YgYW5kIGN1cnJlbnRs eSB1bmRlY2lkZWQvYWdub3N0aWMgb24gc3VwcG9ydCBvZiBhIFdHLCB0aGVzZSB0eXBlcyBvZiBk aXNjdXNzaW9ucyB3b3VsZA0KPGJyPg0KYmUgdXNlZnVsIHRvIG1lIChhdCB0aGUgdmVyeSBsZWFz dCkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FcmljPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJtYWlsdG86ZXJpYy5kb3Qu dHJhdmlzQGdtYWlsLmNvbSI+ZXJpYy5kb3QudHJhdmlzQGdtYWlsLmNvbTwvYT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgSnVuIDUsIDIwMTQgYXQgMTozOCBQTSwg VGVtcGxpbiwgRnJlZCBMICZsdDs8YSBocmVmPSJtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5n LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgRXJpYyw8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5UbyBwb2ludCAxKSwgYWR2YW5jZW1lbnQgb2Ygd29yayBpdGVtcyBpbiB0aGUg SUVURiBpcyB1c3VhbGx5IGJhc2VkIG9uIOKAnHJvdWdoIGNvbnNlbnN1czwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPmFuZCBydW5uaW5nIGNvZGXigJ0gYW5kIHRoZXJlIGlzIHBsZW50 eSBvZiBpbnRlcm9wZXJhYmxlIHJ1bm5pbmcgY29kZSB0aGF0IGltcGxlbWVudHM8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SRkM1MDUwIGFuZCBpdHMgcmVsYXRlZCBzcGVjaWZpY2F0 aW9ucyDigJMgbXVjaCBtb3JlIHRoYW4gbW9zdCBJRVRGIGFjdGl2aXRpZXMgYXJlIGJhc2VkIG9u Lg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXMgdG8g4oCccm91Z2ggY29uc2Vu c3Vz4oCdLCBob2xkaW5nIGEgQm9GIGlzIHRoZSBmaXJzdCBzdGVwIGluIGRldGVybWluaW5nIHRo YXQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+VG8gcG9pbnQgMiksIGFnYWluIHRoZSBCb0Ygd2lsbCBwcm92aWRl IGEgdXNlZnVsIG1lYXN1cmVtZW50IG9mIGludGVyZXN0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyDi gJMgRnJlZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Im1haWx0bzpm cmVkLmwudGVtcGxpbkBib2VpbmcuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZnJlZC5sLnRlbXBsaW5A Ym9laW5nLmNvbTwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGR0biBbbWFpbHRv OjxhIGhyZWY9Im1haWx0bzpkdG4tYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmR0 bi1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RXJpYyBUcmF2aXM8 YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bmUgMDUsIDIwMTQgOToyOSBBTTxicj4NCjxi PlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmwud29vZEBzdXJyZXkuYWMudWsiIHRhcmdldD0iX2Js YW5rIj5sLndvb2RAc3VycmV5LmFjLnVrPC9hPjxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFp bHRvOm1scy5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1scy5pZXRmQGdtYWlsLmNv bTwvYT47DQo8YSBocmVmPSJtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20iIHRh cmdldD0iX2JsYW5rIj5zcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbTwvYT47DQo8YSBocmVm PSJtYWlsdG86ZHRuQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZHRuQGlldGYub3JnPC9hPjsg PGEgaHJlZj0ibWFpbHRvOmllc2dAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCmllc2dAaWV0 Zi5vcmc8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2R0bl0gRFROIEJvRiBQcm9wb3NhbCBmb3Ig SUVURjkwPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+TGxveWQsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCkVtYmVkZGVkIGluIHlvdXIgbWFu aWZlc3RvIGFyZSB0d28gcG9pbnRzIHdvcnRoeSBvZiBkaXNjdXNzaW9uL2RlYmF0ZSB0aHJvdWdo b3V0IHRoZSBCb0YgcHJvY2Vzczo8YnI+DQo8YnI+DQoxKSBJcyB0aGUgcHJvcG9zZWQgKGJhc2Up IHNvbHV0aW9uIC0gd2l0aCAmcXVvdDttaW5pbWFsJnF1b3Q7IGZpeGVzIC0gb2Ygc3VmZmljaWVu dCBtYXR1cml0eSBmb3Igc3RhbmRhcmRpemF0aW9uIHdpdGhpbiB0aGUgSUVURj88YnI+DQo8YnI+ DQoyKSBUaGUgZXhpc3RpbmcgSVJURiBEVE5SRyBoYXMgbm90IGJlZW4gYWJsZSB0byBoYXJuZXNz IHN1ZmZpY2llbnQgaW50ZXJlc3QvcmVzb3VyY2VzIHRvIGFkdmFuY2UgdGhlIHN0YXRlIG9mIFJG Qy01MDUwLCBob3cgd2lsbCBhIG5ldyBJRVRGIFdHIGNoYW5nZSB0aGUgZHluYW1pYz88YnI+DQo8 YnI+DQpBcyBmb3IgdGhlIHJlc3Qgb2YgaXQsIHdlbGwuLi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UkZDNTA1MGJp czogaGFsZi1hc3NlZCwgaGFsZi1iYWtlZCwgcmVoZWF0ZWQuPGJyPg0KQnV0IGhleSwgYXNrIG1l IHdoYXQgSSBfcmVhbGx5XyB0aGluay48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+TGV0IHRoZSByYXRpb25hbCwgd2VsbC1yZWFzb25l ZCBkaXNjdXNzaW9uIGJlZ2luLi4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkVyaWM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBocmVmPSJtYWlsdG86ZXJpYy5kb3QudHJhdmlzQGdt YWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmVyaWMuZG90LnRyYXZpc0BnbWFpbC5jb208L2E+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBw dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5P biBUaHUsIEp1biA1LCAyMDE0IGF0IDc6MjAgQU0sICZsdDs8YSBocmVmPSJtYWlsdG86bC53b29k QHN1cnJleS5hYy51ayIgdGFyZ2V0PSJfYmxhbmsiPmwud29vZEBzdXJyZXkuYWMudWs8L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QXMgcHJldmlv dXNseSBleHByZXNzZWQgb24gRFROUkcsIEkgaGF2ZSBhIG51bWJlciBvZiBjb25jZXJucyBhYm91 dDxicj4NCnRoaXMgcHJvcG9zZWQgQk9GIHRvIGNyZWF0ZSBhbiBJRVRGIERUTiBXRyB0byBkbyB3 b3JrIG9uIHRoZTxicj4NClJGQzUwNTAgYnVuZGxlIHByb3RvY29sLCBwcm9kdWNlZCBpbiB0aGUg SVJURiBEVE5SRywgYW5kIGNyZWF0ZTxicj4NCmFuIFJGQzUwNTBiaXMuIEknbGwgZ28gdGhyb3Vn aCB0aG9zZSBjb25jZXJucyBvbmUgYnkgb25lOjxicj4NCjxicj4NCjxicj4NCjEuIEkgZG9uJ3Qg c2VlIGhvdyBnb2luZyBzdGFuZGFyZHMgdHJhY2sgY2FuIGJlIGp1c3RpZmllZCwgYmVjYXVzZTo8 YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7YS4gQ0NTRFMgaXMgYWxyZWFkeSB3b3JraW5nIG9uIHRo ZSBidW5kbGUgcHJvdG9jb2wgYXMgb25lIG9mIHRoZWlyPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgYmx1ZSBib29rIHN0YW5kYXJkcywgYmFzZWQgb24gUkZDNTA1MCwgYW5kIGFueSBSRkM1MDUw YmlzPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgd291bGQgcHJlc3VtYWJseSBhbHNvIGJlIGFk b3B0ZWQgYW5kIHRoZW4gbW9kaWZpZWQgdG8gbWFrZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 IGEgQ0NTRFMgc3RhbmRhcmQuPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgSXQncyByYXRoZXIg bGlrZSBDQ1NEUyByZXN0YW5kYXJkaXppbmcgVENQL0lQIGFzIFNDUFMsIGJhY2s8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyBpbiB0aGUgMTk5MHMuIFRoYXQgU0NQUyBzdGFuZGFyZGl6YXRpb24g d2Fzbid0IHVzZWQgbXVjaDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGVpdGhlciwgbm90IGxl YXN0IGJlY2F1c2UgQ0NTRFMgJ2ltcHJvdmVkJyBvbiBUQ1AvSVA8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyBhbmQgd2VudCBpbmNvbXBhdGlibGUgcXVpdGUgcXVpY2tseS4gVGhlIHNhbWUgd2ls bCBoYXBwZW48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyB3aXRoIHRoZSBDQ1NEUyBidW5kbGUg cHJvdG9jb2wsIGFuZCBpbiBhZG9wdGluZyBSRkM1MDUwPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgQ0NTRFMgaGFzIHJlc2VydmVkIHRoZSByaWdodCB0byBtYWtlIGNoYW5nZXMgLSB0aGluZ3Mg bGlrZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IERlbGF5IFRvbGVyYW50IFBheWxvYWQgQ29u ZGl0aW9uaW5nIChEVFBDKSBhcmUgYnV0IHRoZSBzdGFydC48YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyBUaGVyZSdzIGFuIGV4YW1wbGUgb2YgYnVuZGxlIHByb3RvY29sIHdvcmsgbm90IHJlcXVp cmluZzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoZSBJRVRGLiBXb3JrIG9uIGFsdGVyaW5n IGFuZCBleHRlbmRpbmcgdGhlIGJ1bmRsZSBwcm90b2NvbDxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7IGlzIGFscmVhZHkgb25nb2luZyBpbiBDQ1NEUy48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyBTZXR0aW5nIHVwIGFuIElFVEYgd29ya2dyb3VwIHRvIHdvcmsgaW4gcGFyYWxsZWwgd291bGQg bWVhbjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoYXQgYSBDQ1NEUyBsaWFpc29uIHdvdWxk IGJlIHJlcXVpcmVkLCB0byBwYXkgYXR0ZW50aW9uPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg dG8gdGhlaXIgY29uY2VybnMgYXMgdGhleSB0cnkgYW5kIGNvbnZpbmNlIHRoZWlyIG1lbWJlciBz cGFjZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGFnZW5jaWVzIHRvIHVzZSB0aGUgYnVuZGxl IHByb3RvY29sLCBhbmQgdG8gcHJldmVudCB0aGVpciBzcGVjPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgZnJvbSBkaXZlcmdpbmcgKGZ1cnRoZXIpIGZyb20gdGhlIElFVEYgc3BlYy4gUmVhbGx5 LCB0aGUgd29yazxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGlzIHNpbXBseSBtb3JlIGVhc2ls eSBkb25lIGluIENDU0RTLCBnaXZlbiB0aGF0IENDU0RTIGlzPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgcHJldHR5IG11Y2ggdGhlIG9ubHkgY3VzdG9tZXIgZm9yIGJ1bmRsZSBwcm90b2NvbCwg YmVjYXVzZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IE5BU0EgaGFzIG1hbmRhdGVkIGJ1bmRs ZSBwcm90b2NvbCB1c2UgZnJvbSBvbiBoaWdoLjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IE5B U0EgbGVhZHMgQ0NTRFMsIE5BU0EgSmV0IFByb3B1bHNpb24gTGFiIGxlYWRzIENDU0RTIGRlc2ln bjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGZvciBOQVNBJ3MgU3BhY2UgQ29tbXVuaWNhdGlv bnMgYW5kIE5hdmlnYXRpb24gcGVvcGxlLjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IEpQTCBp cyByZWFsbHkgdGhlIHByaW1hcnkgY3VzdG9tZXIgZm9yIGFuZCB1c2VyIG9mIGJ1bmRsZTxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7IHByb3RvY29sLCByZXNwb25zaWJsZSBmb3IgcHJvbW90aW5n IGl0cyB1c2UgYnkgb3RoZXIgc3BhY2U8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBhZ2VuY2ll cyAtIG5ldmVyIGFuIGVhc3kgdGFzaywgZXZlbiB3aXRoIGdvb2QgdGVjaG5vbG9naWVzLjxicj4N Cjxicj4NCiZuYnNwOyAmbmJzcDtiLiBUaGUgSUVURiBwcm9kdWNlcyBJbnRlcm5ldCBzdGFuZGFy ZHMuIFRoZSBidW5kbGUgcHJvdG9jb2w8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBoYXMgbGl0 dGxlIGJlYXJpbmcgb24gb3IgaW50ZXJhY3Rpb24gd2l0aCBJbnRlcm5ldCBzdGFuZGFyZHM7PGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgaXQncyBhcmd1YWJseSBhIHdheSB0byBpbnRlcm9wZXJh dGUgd2l0aCB0aGUgSW50ZXJuZXQgd2hpbGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBwcm90 ZWN0aW5nIENDU0RTIGZyb20gaW5jdXJzaW9uIG9mIHRoZSBJbnRlcm5ldCwgYnkgbGF5ZXJpbmc8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBvdmVyIGJvdGggSW50ZXJuZXQgYW5kIENDU0RTLiBF YWNoIHRvIHRoZWlyIG93biBkb21haW5zLjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IFVzaW5n IFRDUCBhcyB0aGUgbW9zdCBjb21tb24gYnVuZGxlIGNvbnZlcmdlbmNlIGxheWVyIChkZXNjcmli ZWQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBpbiBhIGRyYWZ0IG5vdyBzZXZlbiB5ZWFycyBv bGQpIGRvZXMgbm90IG1ha2UgdGhlIGJ1bmRsZSBwcm90b2NvbDxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7IGFuIGludGVybmV0IHN0YW5kYXJkLiBJZiBpdCBkaWQsIHRoZW4gQ0NTRFMncyBTcGFj ZSBMaW5rPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgRXh0ZW5zaW9uIChiYXNpY2FsbHkgYSBU Q1AgdHVubmVsIGNhcnJ5aW5nIENDU0RTIGZyYW1lcywgd2l0aDxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7IG11Y2ggYWRkZWQgY29tcGxleGl0eSkgd291bGQgYWxzbyBiZSBhIGNhbmRpZGF0ZSBm b3IgYW48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBJRVRGIGludGVybmV0IHN0YW5kYXJkLjxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IEJ1dCwgYWdhaW4sIHRoYXQgd29yayBpcyBiZXN0IGRv bmUgaW4gQ0NTRFMsIHdoZXJlIHRoZXJlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgaXMgaW50 ZXJlc3QgaW4gaGF2aW5nIGl0IGRvbmUgYW5kIHRoZXJlIGFyZSB1c2Vycy4gKFNvbWU8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyBvZiB0aG9zZSB1c2VycyBtYXkgZXZlbiBiZSB3aWxsaW5nIHVz ZXJzLik8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7Yy4gVGhlIGJ1bmRsZSBwcm90b2NvbCBpcyBu b3QgbWF0dXJlLiBEZWZpY2llbmNpZXMgaGF2ZSBiZWVuPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgaWRlbnRpZmllZCwgZHJhZnRzIGhhdmUgYmVlbiB3cml0dGVuIGluIERUTlJHIG92ZXIgdGhl IHllYXJzLDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoZXJlIHdhcyBsaXR0bGUgaW50ZXJl c3QsIHRoZSBkcmFmdHMgZXhwaXJlZCwgdGhlIGJ1bmRsZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7IHByb3RvY29sIHdhcyBuZXZlciBpbXByb3ZlZC4gQW5kIHRoYXQncyBqdXN0IGZyb20gZGVt b25zdHJhdGlvbnM7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhlcmUgaGFzIG5vdCBiZWVu IGV4dGVuZGVkIG9wZXJhdGlvbmFsIHVzZSB0byBteSBrbm93bGVkZ2UuPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgQXR0ZW1wdGluZyB0byBmaXggdGhlIGJ1bmRsZSBwcm90b2NvbCBBTkQgcHVz aCBpdCB0aHJvdWdoIGFzPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgc3RhbmRhcmRzIHRyYWNr IGF0IHRoZSBzYW1lIHRpbWUgc2VlbXMgdW53YXJyYW50ZWQuPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgSXQgbWF5IGJlIHBvbGl0aWNhbGx5IG1vdGl2YXRlZCwgYnV0IGl0IGlzPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgbm90IHRlY2huaWNhbGx5IG9yIHByb2NlZHVyYWxseSBqdXN0aWZp YWJsZS48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBUaGVyZSBpc24ndCB0aGUgdXNlcmJhc2Ug b3IgZGVtYW5kIG5lZWRlZCBmb3IgdGhlIGJ1bmRsZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 IHByb3RvY29sIHRvIGdvIHN0YW5kYXJkcyB0cmFjaywgYW5kIGlmIHRoZSBJRVRGIGRpZCBnbzxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHN0YW5kYXJkcyB0cmFjaywgQ0NTRFMgd291bGQgJ29w dGltaXplJyB0aGF0IHN0YW5kYXJkIGludG88YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBpdHMg b3duIHN0YW5kYXJkLCBqdXN0IGFzIHdhcyBkb25lIHdpdGggU0NQUywgbWVhbmluZyB0aGF0PGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhlIElFVEYgd291bGQgc3BlbmQgYSBsb3Qgb2YgdGlt ZSB3b3JraW5nIG9uIHNvbWV0aGluZyB3aXRoPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgbm8g YmVuZWZpdCB0byB0aGUgSUVURiBjb21tdW5pdHkgb3IgdXNlcmJhc2UuIEV4dGVuZGluZzxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoZSBJbnRlcm5ldCBwcm90b2NvbHMgdG8gdGhlIERUTiBu ZXR3b3JrIHByb2JsZW0gc3BhY2U8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBhZGRzIHZhbHVl IHRvIHRoZSBpbnRlcm5ldCBwcm90b2NvbHMuIEEgc2VwYXJhdGUgcHJvdG9jb2w8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyBkb2VzIG5vdC48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBXaG8g d291bGQgYmVuZWZpdCwgb3V0c2lkZSB0aGUgQ0NTRFMgY29tbXVuaXR5PyBBbmQgQ0NTRFM8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyBpcyB0aGVpciBvd24gc3RhbmRhcmRzIG9yZyAtIGFuIElT TyBzdWJncm91cCAtIHRvIGRvIHdvcms8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBmb3IgdGhh dCBDQ1NEUyBjb21tdW5pdHkuPGJyPg0KPGJyPg0KPGJyPg0KMi4gSSBkb24ndCBzZWUgd2h5IHRo aXMgbmVlZHMgdG8gYmUgZG9uZSBpbiBhbiBJRVRGIFdHLCBiZWNhdXNlOjxicj4NCjxicj4NCiZu YnNwOyAmbmJzcDthLiBnb2luZyBzdGFuZGFyZHMgdHJhY2sgaXNuJ3QganVzdGlmaWFibGUgLSBz ZWUgMS48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7Yi4gVGhlcmUncyBhbHJlYWR5IHRoZSBJUlRG IERUTlJHLCB3aGljaCBjb3VsZCBjbGVhbiB1cCBpdHM8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyBvd24gd29yaywgYnV0ICxhZnRlciBtYW55IHllYXJzIGFuZCBzb21lIGZhaWxlZCBkcmFmdHMs PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgaGFzIG5vdC48YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyBEZWNsYXJpbmcgc3VjY2VzcyBhbmQgc2F5aW5nIGl0IGlzIG5vdyB0aW1lIHRvIGNyZWF0 ZSBhPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgV0cgYmFzZWQgb24gRFROUkcncyBhY2hpZXZl bWVudHMgaXMgbm90IGNvbnZpbmNpbmcsPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgYmVjYXVz ZSB0aG9zZSBhY2hpZXZlbWVudHMgYXJlIG5vdCBpbXByZXNzaXZlLjxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7IChEaXNjbGFpbWVyIG9mIGludGVyZXN0OiBJIGF1dGhvcmVkICdBIGJ1bmRsZSBv ZiBwcm9ibGVtcyc8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBhbmQgaGF2ZSBzcGVudCBjb25z aWRlcmFibGUgeWVhcnMgdHJ5aW5nIHRvIGV4cGxhaW4gYW5kPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgYWRkcmVzcyBwcm9ibGVtcyB3aXRoIHRoZSBidW5kbGUgcHJvdG9jb2wsIHdpdGggbGl0 dGxlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgc3VjY2VzcywgYWZ0ZXIgZ2V0dGluZyBpdCB0 ZXN0ZWQgaW4gc3BhY2UgYmVmb3JlIE5BU0Enczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IEVY UE9YSS9EZWVwIEltcGFjdCB0ZXN0cyB0b29rIHBsYWNlLjxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7IEZyZWQgVGVtcGxpbidzIHByb2JsZW0gc3RhdGVtZW50IGRyYWZ0cyBmb3IgdGhpcyBwdXRh dGl2ZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IElFVEYgQk9GIGNhbGxzIG9uIHRoYXQgd29y ay4pPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgUkZDNTA1MGJpcyB3b3VsZCBtYWtlIG1vcmUg c2Vuc2UgYXMgYSBEVE5SRzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGVmZm9ydCwgdGhvdWdo IGl0IHdvdWxkIGJlIHRpbWUgZm9yIGEgY2hhbmdpbmcgb2YgdGhlPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgZ3VhcmQgYW5kIGNoYWlycyBpbiBEVE5SRyB0byBpbmZ1c2Ugc29tZSBuZXcgYmxv b2QgYW5kPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgdGVjaG5pY2FsIGp1ZGdlbWVudCAtIG9y IHdlJ3JlIGluIGZvciBhbm90aGVyIGZpdmUgeWVhcnM8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyBvZiB3aGF0LWRvZXMtdGhlLWVuZC10by1lbmQtcHJpbmNpcGxlLXJlYWxseS1tZWFuIGFuZDxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHdoYXQtYWJvdXQtY2xvY2tzIGFuZCByZWhhc2hpbmcg dGhlIHNhbWUgb2xkIGFyZ3VtZW50cy48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBSZWFsbHks IERUTlJHIG5lZWRzIHRvIGdldCBpdHMgYWN0IHRvZ2V0aGVyLCBib3RoPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgb3JnYW5pemF0aW9uYWxseSBhbmQgdGVjaG5pY2FsbHkuPGJyPg0KPGJyPg0K Jm5ic3A7ICZuYnNwO2MuIFRoZXJlJ3MgYWxyZWFkeSBDQ1NEUywgd2hpY2ggaGFzIGFkb3B0ZWQg dGhlIERUTlJHIG91dHB1dCw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBhZnRlciBwdXNoaW5n IGZvciB0aGUgZm9ybWF0aW9uIG9mIGFuIEludGVycGxhbmV0YXJ5PGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgSW50ZXJuZXQgUkcgaW4gdGhlIGZpcnN0IHBsYWNlLjxicj4NCjxicj4NClNvIGVp dGhlciBDQ1NEUyBvciBEVE5SRyBjYW4gZG8gUkZDNTA1MCByZXZpc2lvbiB3b3JrLiBJZjxicj4N Cml0J3MgdG8gYmUgYW4gUkZDLCBleHBlcmltZW50YWwgb3IgaW5mb3JtYXRpb25hbCwgYSByZXZp dGFsaXNlZDxicj4NCnJlY2hhcnRlcmVkIERUTlJHIGNhbiBkbyBpdC48YnI+DQpJdCBkb2Vzbid0 IG5lZWQgdG8gYmUgYW4gSUVURiB3b3JrZ3JvdXAuIEl0IGNlcnRhaW5seTxicj4NCnNob3VsZG4n dCBnbyBzdGFuZGFyZHMgdHJhY2suPGJyPg0KPGJyPg0KPGJyPg0KMy4gVGhlIHBoaWxvc29waGlj YWxseSBzaGFreSBiYXNpcyBmb3IgdGhlIGJ1bmRsZSBwcm90b2NvbDo8YnI+DQo8YnI+DQombmJz cDsgJm5ic3A7YS4gRGVsYXktdG9sZXJhbnQgbmV0d29ya2luZyBpcyBub3QgZGlzcnVwdGlvbi10 b2xlcmFudDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IG5ldHdvcmtpbmcuIFNwYWNlIGRlbGF5 cyBvZiBsaWdodC1taW51dGVzIHdpdGggc2NoZWR1bGVkPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgY29udGFjdHMgYXJlIG5vdCB0aGUgc2FtZSBhcyBpbnRlcm1pdHRlbnQgYWQtaG9jPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgbWFuZXQtc3R5bGUgY29tbXVuaWNhdGlvbnMuIERpZmZlcmVu dCByZXF1aXJlbWVudHMsPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgZGlmZmVyZW50IGJ1ZmZl cmluZyBhbmQgc3RvcmFnZSwgZGlmZmVyZW50IGNvbmRpdGlvbnMsPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgZGlmZmVyZW50IGhhbmRsaW5nIG9mIGZyYWdtZW50YXRpb24sIGV0Yy48YnI+DQo8 YnI+DQombmJzcDsgJm5ic3A7Yi4gVGhlIGJ1bmRsZSBwcm90b2NvbCBpcyBub3QgRFROLiBEVE4g aXMgdGhlIHNjZW5hcmlvLDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGluIHdoaWNoIG90aGVy IGFwcHJvYWNoZXMgKHRoZSByZWxhdGVkIENGRFAsIEhhZ2dsZSw8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyB0aGUgTUFORVQgYW5kIHZlaGljdWxhciBEVE5zIGVmZm9ydHMgdGhhdCBEVE4gc3Vi c3VtZWQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBhbmQgcmVicmFuZGVkLCBldGMuKSBleGlz dC48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBUaGUgYnVuZGxlIHByb3RvY29sIGlzIGludGVu ZGVkIHRvIGJlIHVzZWQgaW4gYSBEVE48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBzY2VuYXJp by4gQnJhbmRpbmcgdGhlIGJ1bmRsZSBwcm90b2NvbCBhcyBEVE4gaGFzPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgcHV0IGJhY2sgbm9uLWJ1bmRsZSBEVE4gcmVzZWFyY2ggYSBudW1iZXIgb2Yg eWVhcnMuPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgQnJhbmRpbmcgYSBncm91cCBvbmx5IHdv cmtpbmcgb24gdGhlIGJ1bmRsZSBwcm90b2NvbDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGFz ICdEVE4nIGlzIG1pc2xlYWRpbmcgYXQgYmVzdC48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7Yy4g RXh0ZW5kaW5nIHRoZSBidW5kbGUgcHJvdG9jb2wgZnJvbSB0aGUgb3JpZ2luYWw8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyBJbnRlcnBsYW5ldGFyeSBJbnRlcm5ldCBwcm9ibGVtICh3aGljaCBo YWQgaXRzIG93bjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IElSVEYgUkcgd2hpY2ggbGVkIGlu dG8gYSBzZXQgYnVuZGxlIGFnZW5kYSBmb3I8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBEVE5S RykgdG8gY292ZXIgZXZlcnl0aGluZyBlbHNlIGFzIHdlbGwgc2ltcGx5IGhhc24ndDxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7IHdvcmtlZCB2ZXJ5IHdlbGwsIGJlY2F1c2UgdGhlIHNjZW5hcmlv cyBhbmQgdXNlIGNhc2VzPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgYXJlIGRpZmZlcmVudC4g V2UgZGVzaWduIGZvciB1c2UgY2FzZXMuIFRvIGJlIHRvbzxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7IGdlbmVyYWxpc2VkIGlzIHRvIGVuZ2luZWVyIGZvciBub3RoaW5nLjxicj4NCjxicj4NCiZu YnNwOyAmbmJzcDtkLiBJZ25vcmluZyB0aGUgcmFtaWZpY2F0aW9ucyBvZiB0aGUgZW5kLXRvLWVu ZCBwcmluY2lwbGUsPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgd2hpY2ggYXJlIG9mdGVuIG1v cmUgc3VidGxlIHRoYW4gcGVvcGxlIHNlZW0gdG8gdGhpbms8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyB0aGV5IGFyZS4gVGhlIGJ1bmRsZSBwcm90b2NvbCdzIGN1c3RvZHkgdHJhbnNmZXI8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyBwcm9jZWR1cmUgaXMgYSBnb29kIGV4YW1wbGUgb2YgdGhp cyBmYWlsaW5nLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtlLiBUaGUgYnVuZGxlIHByb3RvY29s IGlzIGludGVuZGVkIGZvciB1c2UgaW4gdGhlIG1vc3Q8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyBkaWZmaWN1bHQgbm9pc3kgZGlzcnVwdGVkIG5ldHdvcmtpbmcgY29uZGl0aW9ucyB3ZSBrbm93 LDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGFuZCBpdCBjYW4ndCBldmVuIHNhbml0eSBjaGVj ayBpdHMgb3duIGhlYWRlcnMgYWdhaW5zdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGVycm9y cy4gKEJ1dCBoZXksIGl0IG5vdyBoYXMgYSBzZWN1cml0eSBwcm90b2NvbCB0aGF0PGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgX2FsbW9zdF8gZG9lcyB0aGF0ISBCdXQgd2hpY2ggaXMgdG9vIGNv bXBsaWNhdGVkLCBhbmQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyB3b3VsZCBuZWVkIHRvIGJl IHJlZG9uZS4pPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgSXQncyBpbnRlbmRlZCBmb3IgdGhl IGhhcnNoZXN0IGVudmlyb25tZW50cyB3ZSBrbm93LDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 IGJ1dCBuZWVkcyByZWxpYWJsZSBzeW5jaHJvbml6ZWQgY2xvY2tzIHJ1bm5pbmcgYXQ8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyBzdGVhZHkgdGVtcGVyYXR1cmVzITxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7IEl0J3MgaW50ZW5kZWQgZm9yIGVtYmVkZGVkIHN5c3RlbXMsIGJ1dCB0aGUgZGVz aWduPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgaXMgaHVnZSBhbmQgY29tcGxleCEgKENGRFAg aGFzIHRoZSBzYW1lIHByb2JsZW07PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhlcmUncyBh IHJlYXNvbiBpbXBsZW1lbnRlcnMgd2VudCBmb3IgYSAmcXVvdDtDRkRQIGxpdGUsJnF1b3Q7PGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgYW5kIFNhcmF0b2dhIGV4aXN0cyBqdXN0IGJlY2F1c2Ug Q0ZEUCB3YXNuJ3QgcGVyZm9ybWluZy48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBXb3VsZCBS RkM1MDUwYmlzIGJlICZxdW90O2J1bmRsaW5nIGxpdGUmcXVvdDs/KTxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7IFRoZXJlIGFyZSBtYW55ICd0aGF0IG1ha2VzIG5vIHNlbnNlJyBtb21lbnRzIC0g bm9ybWFsbHk8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBtb3JlIGltbWVkaWF0ZWx5IHZpc2li bGUgdG8gb3V0c2lkZXJzIG5vdCBzdGVlcGVkIGluPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg dGhlIGRvZ21hLCBwb2xpdGljcywgYW5kIGhpc3Rvcnkgb2YgRFROUkcgYW5kIENDU0RTLjxicj4N Cjxicj4NCiZuYnNwOyAmbmJzcDtmLiBUaGUgYXNzdW1wdGlvbiB0aGF0IGEgZnVsbCBzZWN1cml0 eSBzdWl0ZSBpcyBkZXNpcmFibGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBhbmQgbmVjZXNz YXJ5IGF0IGFsbCB0aW1lcy4gVGhpcyBoYXMgZGVyYWlsZWQgRFROUkcsPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgYXMgZW1waGFzaXMgd2FzIHBsYWNlZCBvbiBzZWN1cml0eSB3b3JrIGFib3Zl IGFsbDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGVsc2UsIHJhdGhlciB0aGFuIHdvcmtpbmcg dG8gdGhlIHNjZW5hcmlvLiBUbyBiZSBmYWlyPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgdG8g dGhlIHNlY3VyaXR5LWZvY3VzZWQgY2hhaXJzLCB0aGUgY2hhcnRlciB0aGF0PGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgZXN0YWJsaXNoZWQgRFROUkcgZnJvbSB0aGUgaW50ZXJwbGFuZXRhcnkg aW50ZXJuZXQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyByZXNlYXJjaCBncm91cCBjYWxsZWQg b3V0IHNlY3VyaXR5IGhlYXZpbHksIGFuZCB0aGV5PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg cmFuIHdpdGggdGhhdCBtYW5kYXRlLiBCdXQgdGhlIGZvY3VzIGhhcyBkZWNyZWFzZWQ8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyB3b3JrIG9uIG5vbi1zZWN1cml0eSBtYXR0ZXJzLCB3aGljaCBp cyB0byBzYXksPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgZXZlcnl0aGluZyBlbHNlLjxicj4N Cjxicj4NClJGQzUwNTBiaXMgbWlnaHQgYWRkcmVzcyB0aGUgbGF0dGVyIHRocmVlIHByb2JsZW1z LCBidXQ8YnI+DQp0aGUgZmlyc3QgdGhyZWUgYXJlIGludHJpbnNpY2FsbHkgdW5zb2x2YWJsZTsg YW55IHNvbHV0aW9uPGJyPg0Kd2lsbCBiZSB1bnNhdGlzZmFjdG9yeS4gUGVyaGFwcyBub3QgYXMg dW5zYXRpc2ZhY3RvcnkgYXM8YnI+DQpSRkM1MDUwLCBidXQgdW5zYXRpc2ZhY3Rvcnkgbm9uZXRo ZWxlc3MuPGJyPg0KPGJyPg0KVGhlIHJlYWwgcGhpbG9zb3BoaWNhbCBwcm9ibGVtIGhlcmUgaXMg dGhlIHBvbGl0aWNhbCBkb2dtYTxicj4NCnRoYXQsIHdoYXRldmVyIHRoZSBwcm9ibGVtLCB0aGUg YnVuZGxlIHByb3RvY29sIGlzIFRoZTxicj4NCk9uZSBUcnVlIFNvbHV0aW9uLjxicj4NCjxicj4N Cjxicj4NCjQuIFRoZSBkcmFmdCBCT0YgY2hhcnRlciBpcyBidW5kbGUtY2VudHJpYy4gV2hpY2gg aXMgdG8gc2F5LDxicj4NCiZuYnNwOyAmbmJzcDt0aGF0IGl0J3Mgbm90IGF3ZnVsbHkgcmVsZXZh bnQgdG8gaW50ZXJuZXQgc3RhbmRhcmRzLjxicj4NCiZuYnNwOyAmbmJzcDtEaXNjbGFpbWVyIG9m IGludGVyZXN0OiB3ZSd2ZSB3b3JrZWQgb24gU2FyYXRvZ2EgYW5kPGJyPg0KJm5ic3A7ICZuYnNw O0hUVFAtRFROLCB3aGljaCBoYXZlIGN1cnJlbnQgaW50ZXJuZXQtZHJhZnRzLCBhbmQgYXJlPGJy Pg0KJm5ic3A7ICZuYnNwO3NxdWFyZWx5IGluIHRoZSBEVE4gcHJvYmxlbSBzcGFjZS48YnI+DQom bmJzcDsgJm5ic3A7V2hlbmV2ZXIgc29tZW9uZSB0YWxrcyBhYm91dCBtdWx0aXBsZSBjb252ZXJn ZW5jZTxicj4NCiZuYnNwOyAmbmJzcDtsYXllcnMgZm9yIHRoZSBidW5kbGUgcHJvdG9jb2wgLSB0 aGVyZSdzIG1vcmUgdGhhbiBmb3IgQkVFUCw8YnI+DQombmJzcDsgJm5ic3A7d2hpY2gganVzdCBo YXMgVENQLCBidXQgdGhlcmUgYXJlbid0IG1hbnkgLSBTYXJhdG9nYSBtYXk8YnI+DQombmJzcDsg Jm5ic3A7YmUgbWVudGlvbmVkLiBCdXQgd2UndmUgZm91bmQgdGhhdCBjYXJyeWluZyBidW5kbGVz IGRvZXNuJ3Q8YnI+DQombmJzcDsgJm5ic3A7YmVuZWZpdCBTYXJhdG9nYSAtIHRlc3RlZCBpdCBp biBzcGFjZSwgZGlkbid0IHNlZSB0aGU8YnI+DQombmJzcDsgJm5ic3A7YWR2YW50YWdlcy4gU2Fy YXRvZ2EgZG9lcyBsZXZlcmFnZSBhIGZldyBJbnRlcm5ldCB0aGluZ3MgLTxicj4NCiZuYnNwOyAm bmJzcDtVRFAsIFVEUC1MaXRlLCBtdWx0aWNhc3QuIEl0IGRvZXMgYSBmZXcgc2NhbGluZyB0aGlu Z3MgdGhhdDxicj4NCiZuYnNwOyAmbmJzcDtub3RoaW5nIGVsc2UgSSd2ZSBzZWVuIGRvZXMgKGRl c2NyaWJlZCBpbiBvdXIgMjAxMSBUU1ZBUkVBPGJyPg0KJm5ic3A7ICZuYnNwO3ByZXNlbnRhdGlv biB0byBJRVRGIDg4IGluIE5vdmVtYmVyLikgQW5kIGl0J3MgYmFzZWQgb248YnI+DQombmJzcDsg Jm5ic3A7YSBkZWNhZGUgb2Ygb3BlcmF0aW9uYWwgdXNlIGluIHRoZSBwcm9ibGVtIGRvbWFpbi48 YnI+DQombmJzcDsgJm5ic3A7SFRUUC1EVE4gbGV2ZXJhZ2VzIHRoZSBIVFRQIHN1aXRlIGFuZCBN SU1FLCBhbmQgY29tZXMgdXA8YnI+DQombmJzcDsgJm5ic3A7d2hlbmV2ZXIgd291bGRuJ3QtaXQt YmUtbmljZS10by10cnktSFRUUC1mb3ItRFROIGRpc2N1c3Npb248YnI+DQombmJzcDsgJm5ic3A7 dGFrZXMgcGxhY2UuPGJyPg0KJm5ic3A7ICZuYnNwOyhJIHN1c3BlY3QgdGhhdCBhbGwgb2YgU3Rl cGhlbiBGYXJyZWxsJ3MgTjRDIHdvcmsgY291bGQ8YnI+DQombmJzcDsgJm5ic3A7aGF2ZSBiZWVu IGRvbmUgb3ZlciBob3AtYnktaG9wIEhUVFAgYSBsYSBIVFRQLURUTiwgYW5kPGJyPg0KJm5ic3A7 ICZuYnNwO3dvdWxkIGhhdmUgd29ya2VkIGp1c3QgYXMgd2VsbCBpZiBub3QgYmV0dGVyLiBBZnRl ciBhbGwsPGJyPg0KJm5ic3A7ICZuYnNwO2l0IHVzZWQgVENQLik8YnI+DQombmJzcDsgJm5ic3A7 VGhlc2UgYW5kIG90aGVyIGVmZm9ydHMgZXhpc3QgaW4gYSBnYXAgYmV0d2VlbiBEVE5SRywgd2hp Y2g8YnI+DQombmJzcDsgJm5ic3A7aXMgYXdhcmUgb2YgdGhlIHByb2JsZW0gc3BhY2UsIGJ1dCB0 aGlua3MgdGhlIGJ1bmRsZTxicj4NCiZuYnNwOyAmbmJzcDtwcm90b2NvbCBpcyB0aGUgc29sdXRp b24gZGVzcGl0ZSBtb3VudGluZyBldmlkZW5jZSB0byB0aGU8YnI+DQombmJzcDsgJm5ic3A7Y29u dHJhcnksIGFuZCBUU1ZXRywgd2hlcmUgdGhlIGZldyBhY3R1YWwgdHJhbnNwb3J0PGJyPg0KJm5i c3A7ICZuYnNwO2V4cGVydHMgbGl2ZSwgd2l0aG91dCBjbG91dCwgb3IgZnVuZGluZywgb3Igc3Bh cmUgdGltZS48YnI+DQombmJzcDsgJm5ic3A7VGhvc2UgZWZmb3J0cyBhcmUgaW50ZXJlc3Rpbmcg ZW5vdWdoIHRvIGhhdmUgaW1wbGVtZW50YXRpb25zPGJyPg0KJm5ic3A7ICZuYnNwO2tpY2tpbmcg YXJvdW5kIHRvby48YnI+DQombmJzcDsgJm5ic3A7QW5kIHlldCwgdGhlIGZvY3VzIG9mIHRoaXMg cHV0YXRpdmUgd29ya2dyb3VwIGFuZCBCT0YgaXM8YnI+DQombmJzcDsgJm5ic3A7c29sZWx5IG9u IGJ1bmRsaW5nLCBhbmQgbm90IG9uIGV2YWx1YXRpbmcgdGhlc2Ugb3Igb3RoZXI8YnI+DQombmJz cDsgJm5ic3A7dGhpbmdzIHRoYXQgbWlnaHQgZXhpc3QgaW4gdGhlIHByb2JsZW0gc3BhY2UuIFRo ZXJlPGJyPg0KJm5ic3A7ICZuYnNwO211c3QgYmUgb3RoZXIgdGhpbmdzIG91dCB0aGVyZSB0aGF0 IHdvdWxkIGJlIG9mIGludGVyZXN0PGJyPg0KJm5ic3A7ICZuYnNwO3RvIHN1Y2ggYSBEVE4gd29y a2dyb3VwLiBXaGF0IGlzIHByb3Bvc2VkIGlzIG5vdCBhIERUTjxicj4NCiZuYnNwOyAmbmJzcDt3 b3JrZ3JvdXAuIFRoZSBjaGFydGVyIGlzIGJhc2ljYWxseSBhIGJ1bmRsZSB3b3JrZ3JvdXAuPGJy Pg0KJm5ic3A7ICZuYnNwO0NhbiBhbiBpbnRlcmVzdCBpbiBidW5kbGluZyBhbmQgc29sZWx5IGJ1 bmRsaW5nIChvdXRzaWRlPGJyPg0KJm5ic3A7ICZuYnNwO0NDU0RTLCB3aGljaCBpcyBkcml2aW5n IHRoZSBwdXNoIHRvIHVzZSB0aGUgYnVuZGxlIHByb3RvY29sKTxicj4NCiZuYnNwOyAmbmJzcDti ZSBqdXN0aWZpZWQgZm9yIGFuIElFVEYgd29ya2dyb3VwPyBJIHJlYWxseSBkb24ndCB0aGluayBz by48YnI+DQo8YnI+DQo1LiBUaGUgYnVuZGxlIHByb3RvY29sIHdvcmsgd2FzLCBJIGdhdGhlciwg d2VsbC1mdW5kZWQ8YnI+DQombmJzcDsgJm5ic3A7YnkgYSBudW1iZXIgb2YgcGFydGllcy48YnI+ DQombmJzcDsgJm5ic3A7SSBjYW4ndCBzZWUgYSBmb2xsb3ctb24gZWZmb3J0IGJlaW5nIGFueXdo ZXJlIG5lYXI8YnI+DQombmJzcDsgJm5ic3A7YXMgd2VsbCBmdW5kZWQuPGJyPg0KPGJyPg0KJm5i c3A7ICZuYnNwO2EuIEkgaGF2ZSBubyBpZGVhIGhvdyBtdWNoIG1vbmV5IE5BU0EgYW5kIENDU0RT IGhhdmUgcHV0PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgaW50byB0aGlzIC0gZmlyc3QgQ0ZE UCwgdGhlbiBidW5kbGluZywgd2hpY2ggbm93IGhhczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 IHRvIHByb3ZpZGUgYSBDRkRQLWxpa2UgQVBJIHRvIHRoZSB1c2VycyB3aG8gd2VyZSB0b2xkPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhhdCBDRkRQIHdhcyB0aGUgZnV0dXJlLCBhbmQgTGlj a2xpZGVyIChMVFApLjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IERyYWdnaW5nIENDU0RTIGlu dG8gdGhlIG1vZGVybiBhZ2Ugb2YgbmV0d29ya2luZzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 IHNlZW1zIHVubGlrZWx5IHRvIGV2ZXIgaGFwcGVuLCB0aGFua3MgdG8gQ0NTRFMgaGF2aW5nPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgbGl0dGxlIGluIHRoZSB3YXkgb2Ygc2FuZSBsYXllcmlu ZyBvciBzZXBhcmF0aW9uIG9mPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgZnVuY3Rpb25hbGl0 eS48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBJIGRvIGhhdmUgdGhlIGx1eHVyeSBvZiBub3Qg bmVlZGluZyB0byB3b3JrIG9uIENDU0RTLjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IEJ1dCBp ZiB5b3Ugd2FudCB0byB3b3JrIG9uIENDU0RTIHByb3RvY29scywgQ0NTRFMgaXM8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyB0aGUgcGxhY2UgdG8gZ28uIFRoZSBJRVRGIGlzIG5vdCB0aGF0IHBs YWNlLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtiLiBEQVJQQSBwb3VyZWQgbW9uZXkgaW50byBE VE4gd29yayAtIGF0IGxlYXN0IHR3ZW50eTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IG1pbGxp b24gZG9sbGFycywgZnJvbSB0aGUgcHJlc3MgcmVsZWFzZXMgSSd2ZSBzZWVuLjxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7IEkgaGF2ZSBubyBpZGVhIHdoYXQgREFSUEEgZ290IG91dCBvZiBpdCBp biB0aGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyB5ZWFycyB0aGV5IHdlcmUgaW52b2x2ZWQ7 IGhhdmVuJ3Qgc2VlbiB0aGUgcmVwb3J0cy48YnI+DQo8YnI+DQpNeSBwb2ludCBpcywgYWxsIHRo YXQgbW9uZXkgYW5kIGVmZm9ydCBhbmQgbWFucG93ZXIgYW5kPGJyPg0Kb3ZlciBhIGRlY2FkZSBv ZiB3b3JrIGFuZCBwcmlvciBleHBlcmllbmNlIHdpdGggQ0ZEUCBhbmQgdHdvPGJyPg0KSVJURiBS R3MsIHdlIGhhdmUuLi4gUkZDNTA1MC48YnI+DQpUaGVyZSBpcyBub3doZXJlIG5lYXIgYXMgbXVj aCBtb25leSBvciBlZmZvcnQgb3IgbWFucG93ZXI8YnI+DQpmb3IgZG9pbmcgYSByZXBsYWNlbWVu dC48YnI+DQpFcmdvLCBpdCBtaWdodCBiZSBzdWdnZXN0ZWQgdGhhdCB0aGUgcmVwbGFjZW1lbnQg aXMgdW5saWtlbHk8YnI+DQp0byBiZSBhcyBnb29kIGFzIFJGQzUwNTAsIG9yIGFzIGdvb2QgYXMg Q0ZEUDsgYXQgYmVzdCw8YnI+DQp0aGUgdXN1YWwgc3VzcGVjdHMgd2lsbCBoYXZlIGxlc3MgdGlt ZSBhbmQgZmV3ZXIgcmVzb3VyY2VzPGJyPg0KdG8gcmVwZWF0IHRoZWlyIG9yaWdpbmFsIG1pc3Rh a2VzLjxicj4NCjxicj4NCkFuZCB0cmFuc3BvcnQgZXhwZXJ0aXNlIGZyb20gVFNWV0cgd291bGQg YmUgbmVlZGVkLjxicj4NClRTVldHIGlzIHVuZmFzaGlvbmFibGUsIGxvdy12aXNpYmlsaXR5LCBh bmQgaGFzIGV2ZW48YnI+DQpwcmV2aW91c2x5IGhhZCB0cm91YmxlIGZpbmRpbmcgQURzIHdpdGgg cmVsZXZhbnQgZXhwZXJ0aXNlLjxicj4NCkFuZCBUU1ZXRyBoYXMgYSBmdWxsIHBsYXRlIHdpdGgg d29yayBvbiBpdHMgZXhpc3Rpbmc8YnI+DQpwcm90b2NvbHM7IHRoZXJlIGlzIG5vdCBhIGxvdCBv ZiBleHBlcnRpc2UsIGFuZCB3aGF0IHRoZXJlPGJyPg0KaXMgaXMgc3ByZWFkIHRoaW4uPGJyPg0K U28gYW4gUkZDNTA1YmlzIGVmZm9ydCBpcyB1bmxpa2VseSB0byBnZXQgdGhlIGV4cGVydDxicj4N CnRlY2huaWNhbCBpbnB1dCB0aGF0IGl0IHNvcmVseSBuZWVkcywgZXZlbiBpZiBhbiBJRVRGPGJy Pg0Kd29ya2dyb3VwIGlzIHNldCB1cC4gKENDU0RTIGRvZXNuJ3QgaGF2ZSB0aGF0IHRyYW5zcG9y dDxicj4NCmZvY3VzLik8YnI+DQo8YnI+DQpJZiwgb24gdGhlIG90aGVyIGhhbmQsIHlvdSBiZWxp ZXZlIGdvb2QgcHJvdG9jb2wgZGVzaWduPGJyPg0KY2FuIGJlIGRvbmUgbW9yZSBjaGVhcGx5IGFu ZCBsZXZlcmFnZSBhY3R1YWwgSW50ZXJuZXQ8YnI+DQpzdGFuZGFyZHMgdG8gZ2V0IEludGVybmV0 IGZ1bmN0aW9uYWxpdHkgd29ya2luZyBpbjxicj4NCmRpZmZpY3VsdCBuZXR3b3JrcyB3aGVyZSB0 aGUgZnVsbCBUQ1AvSVAgc3VpdGUgaGFzPGJyPg0KdHJvdWJsZSwgeW91ciBvcHRpb25zIGluY2x1 ZGUgU2FyYXRvZ2EgYW5kIEhUVFAtRFROITxicj4NCjxhIGhyZWY9Imh0dHA6Ly9zYXJhdG9nYS5z b3VyY2Vmb3JnZS5uZXQvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3NhcmF0b2dhLnNvdXJjZWZv cmdlLm5ldC88L2E+PGJyPg0KPGEgaHJlZj0iaHR0cDovL3NhdC1uZXQuY29tL0wuV29vZC9kdG4v aHR0cC1kdG4uaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9zYXQtbmV0LmNvbS9MLldvb2Qv ZHRuL2h0dHAtZHRuLmh0bWw8L2E+PGJyPg0KVGhleSdsbCB0cnVseSBleHRlbmQgdGhlIEludGVy bmV0IHRvIGRpZmZpY3VsdDxicj4NCmVudmlyb25tZW50cy4gVGhlIGJ1bmRsZSBwcm90b2NvbCB3 b24ndC48YnI+DQo8YnI+DQpTbywgdG8gY29uY2x1ZGUsIHRoZXJlIGlzIG5vIGp1c3RpZmljYXRp b24gZm9yIGdvaW5nPGJyPg0Kc3RhbmRhcmRzIHRyYWNrLiBUaGVyZSBpcyBsaXR0bGUganVzdGlm aWNhdGlvbiBmb3IgYW48YnI+DQpJRVRGIHdvcmtncm91cC4gVGhlcmUgaXMgbW9yZSBsb2dpYyBp biByZWNoYXJ0ZXJpbmcgYW5kPGJyPg0KcmVwdXJwb3NpbmcgdGhlIElSVEYgRFROUkcsIGJ1dCB0 aGUgd29yayBtYXkgYXMgd2VsbDxicj4NCmJlIGxlZnQgdG8gQ0NTRFMgZW50aXJlbHkuPGJyPg0K PGJyPg0KUkZDNTA1MGJpczogaGFsZi1hc3NlZCwgaGFsZi1iYWtlZCwgcmVoZWF0ZWQuPGJyPg0K QnV0IGhleSwgYXNrIG1lIHdoYXQgSSBfcmVhbGx5XyB0aGluay48YnI+DQo8YnI+DQpMbG95ZCBX b29kPGJyPg0KPGEgaHJlZj0iaHR0cDovL3NhdC1uZXQuY29tL0wuV29vZC9kdG4vIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cDovL3NhdC1uZXQuY29tL0wuV29vZC9kdG4vPC9hPjxicj4NCjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KZHRuIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpkdG5AaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5kdG5AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9kdG4iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2R0bjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8YnI+DQotLSA8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT5UaGUg cHJvYmxlbSB3aXRoIHRoZSB3b3JsZCBpcyB0aGF0IHRoZSBpbnRlbGxpZ2VudCBwZW9wbGUgYXJl IGZ1bGwgb2YgZG91YnRzLA0KPGJyPg0Kd2hpbGUgdGhlIHN0dXBpZCBvbmVzIGFyZSBmdWxsIG9m IGNvbmZpZGVuY2UuPC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48aT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjxiPi0gQ2hhcmxl cyBCdWtvd3NraTwvYj48L2k+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPGJyPg0KLS0gPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPlRoZSBwcm9ibGVtIHdpdGgg dGhlIHdvcmxkIGlzIHRoYXQgdGhlIGludGVsbGlnZW50IHBlb3BsZSBhcmUgZnVsbCBvZiBkb3Vi dHMsDQo8YnI+DQp3aGlsZSB0aGUgc3R1cGlkIG9uZXMgYXJlIGZ1bGwgb2YgY29uZmlkZW5jZS48 L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjxiPi0gQ2hhcmxlcyBCdWtvd3NraTwvYj48 L2k+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_2134F8430051B64F815C691A62D983181B2BF56CXCHBLV504nwnosb_-- From nobody Thu Jun 5 16:06:14 2014 Return-Path: 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 B65C11A0347 for ; Thu, 5 Jun 2014 16:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 ihNnk6Od2G2l for ; Thu, 5 Jun 2014 16:06:04 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74A861A032D for ; Thu, 5 Jun 2014 16:06:03 -0700 (PDT) Received: from [85.158.137.99:20424] by server-13.bemta-3.messagelabs.com id 9A/F1-18692-3D7F0935; Thu, 05 Jun 2014 23:05:55 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-16.tower-217.messagelabs.com!1402009553!20994840!1 X-Originating-IP: [131.227.200.35] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3985 invoked from network); 5 Jun 2014 23:05:54 -0000 Received: from exht021p.surrey.ac.uk (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-16.tower-217.messagelabs.com with AES128-SHA encrypted SMTP; 5 Jun 2014 23:05:54 -0000 Received: from EXHY011V.surrey.ac.uk (131.227.200.103) by EXHT021P.surrey.ac.uk (131.227.200.35) with Microsoft SMTP Server (TLS) id 8.3.348.2; Fri, 6 Jun 2014 00:05:53 +0100 Received: from emea01-am1-obe.outbound.protection.outlook.com (131.227.200.4) by email365.surrey.ac.uk (131.227.200.103) with Microsoft SMTP Server (TLS) id 14.3.174.1; Fri, 6 Jun 2014 00:05:52 +0100 Received: from AMSPR06MB439.eurprd06.prod.outlook.com (10.242.23.19) by AMSPR06MB439.eurprd06.prod.outlook.com (10.242.23.19) with Microsoft SMTP Server (TLS) id 15.0.954.9; Thu, 5 Jun 2014 23:05:51 +0000 Received: from AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) by AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) with mapi id 15.00.0954.000; Thu, 5 Jun 2014 23:05:51 +0000 From: To: , Thread-Topic: [dtn] DTN BoF Proposal for IETF90 Thread-Index: Ac+AQa9Fez/CplZaSwyaLFpzb8tj0wAiVZ0A///Hp/CAAFjlAIAAE2iAgAAMmoCAAAVMgIAAPnzF Date: Thu, 5 Jun 2014 23:05:50 +0000 Message-ID: <1402009549911.23163@surrey.ac.uk> References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> <1401967219583.26821@surrey.ac.uk> <2134F8430051B64F815C691A62D983181B2BF435@XCH-BLV-504.nw.nos.boeing.com> , <2134F8430051B64F815C691A62D983181B2BF56C@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983181B2BF56C@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-AU, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [124.149.114.231] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 0233768B38 x-forefront-antispam-report: SFV:NSPM; SFS:(428001)(199002)(189002)(40154002)(377454003)(101416001)(99396002)(4396001)(87936001)(83322001)(19580405001)(19580395003)(2656002)(16236675004)(15202345003)(15188155005)(16799955002)(19300405004)(93886002)(66066001)(80022001)(36756003)(76482001)(92726001)(92566001)(86362001)(79102001)(64706001)(20776003)(81342001)(83072002)(85852003)(76176999)(81542001)(50986999)(54356999)(77096999)(19625215002)(21056001)(77982001)(15975445006)(74662001)(74502001)(74482001)(31966008)(46102001)(536464002)(562404015)(579004)(19607625010); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR06MB439; H:AMSPR06MB439.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: surrey.ac.uk does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_140200954991123163surreyacuk_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: AMSPR06MB439.eurprd06.prod.outlook.com X-OriginatorOrg: surrey.ac.uk X-CrossPremisesHeadersPromoted: EXHY011v.surrey.ac.uk X-CrossPremisesHeadersFiltered: EXHY011v.surrey.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/59gBm-CwU0mDxZ_Bvai3i_nNO4g Cc: mls.ietf@gmail.com, spencerdawkins.ietf@gmail.com, dtn@ietf.org Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 23:06:10 -0000 --_000_140200954991123163surreyacuk_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable (snipping IESG, who know this stuff, from cc) Fred, RFC5214, which you wrote, is NOT an "official IETF standard". It's informational for the community - see the 'Category: Informational' at top left. Being published as an RFC is NOT at all the same as being a standards-track candidate or being evaluated as an IETF standard. http://www.rfc-editor.org/search/rfc_search_detail.php?rfc=3D2026 See RFC2026 and whatever updates it these days - there are about a dozen later RFCs on nuances of how this standards process actually works, though the distinction is lost on outsiders (and, come to think of it, on some of = my coauthors, who just see a technical specification). Laymen often have troub= le telling the difference between an internet-draft and a published RFC; the nuances of the categories are beyond that. http://en.wikipedia.org/wiki/Internet_Standard has a layman introduction of sorts. Do you actually understand what you are asking for in proposing a BOF and W= G to produce a standards document, and why the IETF draws a difference betwee= n "experimental RFC" or "informational RFC" and "standards-track document"? "Category: Standards Track" has a far higher bar. > But, having an IETF standard is a demonstration that rough consensus has = deemed > the work as standards-worthy =96 a community stamp of approval, or at lea= st =93no > objection=94. In brief, no. The RFCs that are IETF standards and standards-track document= s get more scrutiny than mere rough consensus. RFCs can be published with objections and warnings documented in them; see, for example, the warning on the informational RFC4938, where the IESG and the workgroup threw up their hands in horror at the whole thing, but since this PPPoE hack was already shipping, better to have it documented than not. Oh, and "I should know, I wrote one" is also an ad-hominem argument, which is to say, a logical fallacy - but at least it's not alone there. Goo= d job. So, now that you know this, do you want to re-evaluate your request for an IETF WG to produce a standards document? The bundle protocol was ready for an experimental RFC. But it's nowhere near mature enough for standards track. Lloyd Wood http://sat-net.com/L.Wood/dtn ________________________________ From: Templin, Fred L Sent: Friday, 6 June 2014 4:42 AM To: Eric Travis Cc: Wood L Dr (Electronic Eng); mls.ietf@gmail.com; spencerdawkins.ietf@gma= il.com; dtn@ietf.org; iesg@ietf.org Subject: RE: [dtn] DTN BoF Proposal for IETF90 Hi Eric, It is true that having an official IETF standard is not a necessary precond= ition for one or more vendors to move forward with widely-deployed implementations. I sh= ould know; I wrote one: http://www.rfc-editor.org/rfc/rfc5214.txt But, having an IETF standard is a demonstration that rough consensus has de= emed the work as standards-worthy =96 a community stamp of approval, or at least= =93no objection=94. About level of interest, I believe there is still energy in DTNRG and at l= east some of that energy is spilling over into these discussions. Thanks - Fred From: Eric Travis [mailto:eric.dot.travis@gmail.com] Sent: Thursday, June 05, 2014 11:24 AM To: Templin, Fred L Cc: l.wood@surrey.ac.uk; mls.ietf@gmail.com; spencerdawkins.ietf@gmail.com;= dtn@ietf.org; iesg@ietf.org Subject: Re: [dtn] DTN BoF Proposal for IETF90 Hi Fred, While I wasn't intending to advocate either way on the items: To point 1), advancement of work items in the IETF is usually based on =93r= ough consensus and running code=94 and there is plenty of interoperable running code that = implements RFC5050 and its related specifications =96 much more than most IETF activit= ies are based on. My "points worthy of discussion/debate throughout the BoF process" seems t= o be compatible with your As to =93rough consensus=94, holding a BoF is the first step in determining= that. I'd contend that the *DTNRG* was the start of that discussion. The *BoF* i= s a continuation of a 7+ year community discussion. There is an experimental RFC that has achieved interoperability between mul= tiple independent implementations. That, however, isn't necessarily a referendum on the maturity of the protoc= ol(s) themselves. For those entities whose needs are satisfied with RFC-5050, a standards-tra= ck document is not necessary for deployment. Actually, a standards-track document is never *really* necessary. There ar= e many middleware/application level "things" deployed that are not based on IETF standards. The presumption of the BoF seems to = be that RFC-5050 is NOT "there yet". So, the question is how close to maturity is close enough to go into a standards tr= ajectory. >From the discussions on the list, there has been a lot of very promising di= alog of the nature of "Yeah, it would be useful to *explore* Foo and/or Bar", from some people th= at - frankly - pleasantly surprised me. This leads to the question - has the solution space been adequately explore= d to have confidence that the result is a mature (NOT perfect)? If not, will the WG be able to take it further tha= n the RG was capable (and why is that true)? That's a question, not a statement on my part. To point 2), again the BoF will provide a useful measurement of interest. I think the level of interest is relatively high within the DTNRG - and wil= l likely be so for a DTN WG. The question really is if/how will that translate into measurable progress (fixing the -= some long acknowledged - nits in the protocol specification. The original idea of a RFC5050.Bis was floated two (three?) years ago as pa= rt of the most recent Google meeting. It failed to gain traction, despite what seemed to be a fair amount of community interest. Is the lack of movement within the DTNRG simply because of the (lack of) pa= th to a standards track RFC? The question for the BoF is, what caused the evolutionary pause, and how wi= ll a WG prevent it from stalling again. Just to be clear, I'm in favor of a BoF and currently undecided/agnostic o= n support of a WG, these types of discussions would be useful to me (at the very least). Regards, Eric eric.dot.travis@gmail.com On Thu, Jun 5, 2014 at 1:38 PM, Templin, Fred L > wrote: Hi Eric, To point 1), advancement of work items in the IETF is usually based on =93r= ough consensus and running code=94 and there is plenty of interoperable running code that = implements RFC5050 and its related specifications =96 much more than most IETF activit= ies are based on. As to =93rough consensus=94, holding a BoF is the first step in determining= that. To point 2), again the BoF will provide a useful measurement of interest. Thanks =96 Fred fred.l.templin@boeing.com From: dtn [mailto:dtn-bounces@ietf.org] On Beh= alf Of Eric Travis Sent: Thursday, June 05, 2014 9:29 AM To: l.wood@surrey.ac.uk Cc: mls.ietf@gmail.com; spencerdawkins.ietf@gmai= l.com; dtn@ietf.org; iesg@ietf.org Subject: Re: [dtn] DTN BoF Proposal for IETF90 Lloyd, Embedded in your manifesto are two points worthy of discussion/debate throu= ghout the BoF process: 1) Is the proposed (base) solution - with "minimal" fixes - of sufficient m= aturity for standardization within the IETF? 2) The existing IRTF DTNRG has not been able to harness sufficient interest= /resources to advance the state of RFC-5050, how will a new IETF WG change = the dynamic? As for the rest of it, well... RFC5050bis: half-assed, half-baked, reheated. But hey, ask me what I _really_ think. Let the rational, well-reasoned discussion begin... Eric eric.dot.travis@gmail.com On Thu, Jun 5, 2014 at 7:20 AM, > wrote: As previously expressed on DTNRG, I have a number of concerns about this proposed BOF to create an IETF DTN WG to do work on the RFC5050 bundle protocol, produced in the IRTF DTNRG, and create an RFC5050bis. I'll go through those concerns one by one: 1. I don't see how going standards track can be justified, because: a. CCSDS is already working on the bundle protocol as one of their blue book standards, based on RFC5050, and any RFC5050bis would presumably also be adopted and then modified to make a CCSDS standard. It's rather like CCSDS restandardizing TCP/IP as SCPS, back in the 1990s. That SCPS standardization wasn't used much either, not least because CCSDS 'improved' on TCP/IP and went incompatible quite quickly. The same will happen with the CCSDS bundle protocol, and in adopting RFC5050 CCSDS has reserved the right to make changes - things like Delay Tolerant Payload Conditioning (DTPC) are but the start. There's an example of bundle protocol work not requiring the IETF. Work on altering and extending the bundle protocol is already ongoing in CCSDS. Setting up an IETF workgroup to work in parallel would mean that a CCSDS liaison would be required, to pay attention to their concerns as they try and convince their member space agencies to use the bundle protocol, and to prevent their spec from diverging (further) from the IETF spec. Really, the work is simply more easily done in CCSDS, given that CCSDS is pretty much the only customer for bundle protocol, because NASA has mandated bundle protocol use from on high. NASA leads CCSDS, NASA Jet Propulsion Lab leads CCSDS design for NASA's Space Communications and Navigation people. JPL is really the primary customer for and user of bundle protocol, responsible for promoting its use by other space agencies - never an easy task, even with good technologies. b. The IETF produces Internet standards. The bundle protocol has little bearing on or interaction with Internet standards; it's arguably a way to interoperate with the Internet while protecting CCSDS from incursion of the Internet, by layering over both Internet and CCSDS. Each to their own domains. Using TCP as the most common bundle convergence layer (described in a draft now seven years old) does not make the bundle protocol an internet standard. If it did, then CCSDS's Space Link Extension (basically a TCP tunnel carrying CCSDS frames, with much added complexity) would also be a candidate for an IETF internet standard. But, again, that work is best done in CCSDS, where there is interest in having it done and there are users. (Some of those users may even be willing users.) c. The bundle protocol is not mature. Deficiencies have been identified, drafts have been written in DTNRG over the years, there was little interest, the drafts expired, the bundle protocol was never improved. And that's just from demonstrations; there has not been extended operational use to my knowledge. Attempting to fix the bundle protocol AND push it through as standards track at the same time seems unwarranted. It may be politically motivated, but it is not technically or procedurally justifiable. There isn't the userbase or demand needed for the bundle protocol to go standards track, and if the IETF did go standards track, CCSDS would 'optimize' that standard into its own standard, just as was done with SCPS, meaning that the IETF would spend a lot of time working on something with no benefit to the IETF community or userbase. Extending the Internet protocols to the DTN network problem space adds value to the internet protocols. A separate protocol does not. Who would benefit, outside the CCSDS community? And CCSDS is their own standards org - an ISO subgroup - to do work for that CCSDS community. 2. I don't see why this needs to be done in an IETF WG, because: a. going standards track isn't justifiable - see 1. b. There's already the IRTF DTNRG, which could clean up its own work, but ,after many years and some failed drafts, has not. Declaring success and saying it is now time to create a WG based on DTNRG's achievements is not convincing, because those achievements are not impressive. (Disclaimer of interest: I authored 'A bundle of problems' and have spent considerable years trying to explain and address problems with the bundle protocol, with little success, after getting it tested in space before NASA's EXPOXI/Deep Impact tests took place. Fred Templin's problem statement drafts for this putative IETF BOF calls on that work.) RFC5050bis would make more sense as a DTNRG effort, though it would be time for a changing of the guard and chairs in DTNRG to infuse some new blood and technical judgement - or we're in for another five years of what-does-the-end-to-end-principle-really-mean and what-about-clocks and rehashing the same old arguments. Really, DTNRG needs to get its act together, both organizationally and technically. c. There's already CCSDS, which has adopted the DTNRG output, after pushing for the formation of an Interplanetary Internet RG in the first place. So either CCSDS or DTNRG can do RFC5050 revision work. If it's to be an RFC, experimental or informational, a revitalised rechartered DTNRG can do it. It doesn't need to be an IETF workgroup. It certainly shouldn't go standards track. 3. The philosophically shaky basis for the bundle protocol: a. Delay-tolerant networking is not disruption-tolerant networking. Space delays of light-minutes with scheduled contacts are not the same as intermittent ad-hoc manet-style communications. Different requirements, different buffering and storage, different conditions, different handling of fragmentation, etc. b. The bundle protocol is not DTN. DTN is the scenario, in which other approaches (the related CFDP, Haggle, the MANET and vehicular DTNs efforts that DTN subsumed and rebranded, etc.) exist. The bundle protocol is intended to be used in a DTN scenario. Branding the bundle protocol as DTN has put back non-bundle DTN research a number of years. Branding a group only working on the bundle protocol as 'DTN' is misleading at best. c. Extending the bundle protocol from the original Interplanetary Internet problem (which had its own IRTF RG which led into a set bundle agenda for DTNRG) to cover everything else as well simply hasn't worked very well, because the scenarios and use cases are different. We design for use cases. To be too generalised is to engineer for nothing. d. Ignoring the ramifications of the end-to-end principle, which are often more subtle than people seem to think they are. The bundle protocol's custody transfer procedure is a good example of this failing. e. The bundle protocol is intended for use in the most difficult noisy disrupted networking conditions we know, and it can't even sanity check its own headers against errors. (But hey, it now has a security protocol that _almost_ does that! But which is too complicated, and would need to be redone.) It's intended for the harshest environments we know, but needs reliable synchronized clocks running at steady temperatures! It's intended for embedded systems, but the design is huge and complex! (CFDP has the same problem; there's a reason implementers went for a "CFDP lite," and Saratoga exists just because CFDP wasn't performing. Would RFC5050bis be "bundling lite"?) There are many 'that makes no sense' moments - normally more immediately visible to outsiders not steeped in the dogma, politics, and history of DTNRG and CCSDS. f. The assumption that a full security suite is desirable and necessary at all times. This has derailed DTNRG, as emphasis was placed on security work above all else, rather than working to the scenario. To be fair to the security-focused chairs, the charter that established DTNRG from the interplanetary internet research group called out security heavily, and they ran with that mandate. But the focus has decreased work on non-security matters, which is to say, everything else. RFC5050bis might address the latter three problems, but the first three are intrinsically unsolvable; any solution will be unsatisfactory. Perhaps not as unsatisfactory as RFC5050, but unsatisfactory nonetheless. The real philosophical problem here is the political dogma that, whatever the problem, the bundle protocol is The One True Solution. 4. The draft BOF charter is bundle-centric. Which is to say, that it's not awfully relevant to internet standards. Disclaimer of interest: we've worked on Saratoga and HTTP-DTN, which have current internet-drafts, and are squarely in the DTN problem space. Whenever someone talks about multiple convergence layers for the bundle protocol - there's more than for BEEP, which just has TCP, but there aren't many - Saratoga may be mentioned. But we've found that carrying bundles doesn't benefit Saratoga - tested it in space, didn't see the advantages. Saratoga does leverage a few Internet things - UDP, UDP-Lite, multicast. It does a few scaling things that nothing else I've seen does (described in our 2011 TSVAREA presentation to IETF 88 in November.) And it's based on a decade of operational use in the problem domain. HTTP-DTN leverages the HTTP suite and MIME, and comes up whenever wouldn't-it-be-nice-to-try-HTTP-for-DTN discussion takes place. (I suspect that all of Stephen Farrell's N4C work could have been done over hop-by-hop HTTP a la HTTP-DTN, and would have worked just as well if not better. After all, it used TCP.) These and other efforts exist in a gap between DTNRG, which is aware of the problem space, but thinks the bundle protocol is the solution despite mounting evidence to the contrary, and TSVWG, where the few actual transport experts live, without clout, or funding, or spare time. Those efforts are interesting enough to have implementations kicking around too. And yet, the focus of this putative workgroup and BOF is solely on bundling, and not on evaluating these or other things that might exist in the problem space. There must be other things out there that would be of interest to such a DTN workgroup. What is proposed is not a DTN workgroup. The charter is basically a bundle workgroup. Can an interest in bundling and solely bundling (outside CCSDS, which is driving the push to use the bundle protocol) be justified for an IETF workgroup? I really don't think so. 5. The bundle protocol work was, I gather, well-funded by a number of parties. I can't see a follow-on effort being anywhere near as well funded. a. I have no idea how much money NASA and CCSDS have put into this - first CFDP, then bundling, which now has to provide a CFDP-like API to the users who were told that CFDP was the future, and Licklider (LTP). Dragging CCSDS into the modern age of networking seems unlikely to ever happen, thanks to CCSDS having little in the way of sane layering or separation of functionality. I do have the luxury of not needing to work on CCSDS. But if you want to work on CCSDS protocols, CCSDS is the place to go. The IETF is not that place. b. DARPA poured money into DTN work - at least twenty million dollars, from the press releases I've seen. I have no idea what DARPA got out of it in the years they were involved; haven't seen the reports. My point is, all that money and effort and manpower and over a decade of work and prior experience with CFDP and two IRTF RGs, we have... RFC5050. There is nowhere near as much money or effort or manpower for doing a replacement. Ergo, it might be suggested that the replacement is unlikely to be as good as RFC5050, or as good as CFDP; at best, the usual suspects will have less time and fewer resources to repeat their original mistakes. And transport expertise from TSVWG would be needed. TSVWG is unfashionable, low-visibility, and has even previously had trouble finding ADs with relevant expertise. And TSVWG has a full plate with work on its existing protocols; there is not a lot of expertise, and what there is is spread thin. So an RFC505bis effort is unlikely to get the expert technical input that it sorely needs, even if an IETF workgroup is set up. (CCSDS doesn't have that transport focus.) If, on the other hand, you believe good protocol design can be done more cheaply and leverage actual Internet standards to get Internet functionality working in difficult networks where the full TCP/IP suite has trouble, your options include Saratoga and HTTP-DTN! http://saratoga.sourceforge.net/ http://sat-net.com/L.Wood/dtn/http-dtn.html They'll truly extend the Internet to difficult environments. The bundle protocol won't. So, to conclude, there is no justification for going standards track. There is little justification for an IETF workgroup. There is more logic in rechartering and repurposing the IRTF DTNRG, but the work may as well be left to CCSDS entirely. RFC5050bis: half-assed, half-baked, reheated. But hey, ask me what I _really_ think. Lloyd Wood http://sat-net.com/L.Wood/dtn/ _______________________________________________ dtn mailing list dtn@ietf.org https://www.ietf.org/mailman/listinfo/dtn -- The problem with the world is that the intelligent people are full of doubt= s, while the stupid ones are full of confidence. = - Charles Bukowski -- The problem with the world is that the intelligent people are full of doubt= s, while the stupid ones are full of confidence. = - Charles Bukowski --_000_140200954991123163surreyacuk_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

(snipping IESG, who know this stuff, from cc)


Fred,


RFC5214, which you wrote, is NOT an "official IETF standard".<= /p>

It's informational for the community - see the 'Category: Informational'=

at top left.


Being published as an RFC is NOT at all the same as being a standards-tr= ack

candidate or being evaluated as an IETF standard.


http://www.rfc-editor.org/search/rfc_search_detail.p= hp?rfc=3D2026


See RFC2026 and whatever updates it these days - there are about a = dozen

later RFCs on nuances of how this standards process actually works, thou= gh

the distinction is lost on outsiders (and, come to think of it, on some = of my

coauthors, who just see a technical specification). Laymen often have tr= ouble
telling the difference between an internet-draft and a published RFC;<= /p>

the nuances of the categories are beyond that.


h= ttp://en.wikipedia.org/wiki/Internet_Standard

has a layman introduction of sorts.


Do you actually understand what you are asking for in proposing a BOF an= d WG

to produce a standards document, and why the IETF draws a difference bet= ween

"experimental RFC" or "informational RFC" and &= quot;standards-track document"?

"Category: Standards Track" has a far higher bar.



> But, having an IETF standard is a demonst= ration that rough consensus has deemed

> the work as standa= rds-worthy =96 a community stamp of approval, or at least =93no

> objection=94.


In brief, no. The RFCs that are IETF standards and standards-track docum= ents

get more scrutiny than mere rough consensus. RFCs can be published with<= /p>

objections and warnings documented in them; see, for example, the w= arning

on the informational RFC4938, where the IESG and the workgroup threw up<= /p>

their hands in horror at the whole thing, but since this PPPoE hack= was

already shipping, better to have it documented than not.


Oh, and "I should know, I wrote one" is also an ad-hominem arg= ument,

which is to say, a logical fallacy - but at least it's not alone there. = Good job.


So, now that you know this, do you want to re-evaluate your request

for an IETF WG to produce a standards document? The bundle protocol

was ready for an experimental RFC. But it's nowhere near mature

enough for standards track.


Lloyd Wood
http://sat-net.com/L.Wood/dtn
From: Templin, Fred L <= Fred.L.Templin@boeing.com>
Sent: Friday, 6 June 2014 4:42 AM
To: Eric Travis
Cc: Wood L Dr (Electronic Eng); mls.ietf@gmail.com; spencerdawkins.i= etf@gmail.com; dtn@ietf.org; iesg@ietf.org
Subject: RE: [dtn] DTN BoF Proposal for IETF90
 

Hi Eric,

 

It is true that having = an official IETF standard is not a necessary precondition for one

or more  vendors t= o move forward with widely-deployed implementations. I should

know; I wrote one:

 

http://www.rfc-editor.org/rfc/rfc5214.txt

 

But, having an IETF sta= ndard is a demonstration that rough consensus has deemed

the work as standards-w= orthy =96 a community stamp of approval, or at least =93no

objection=94.

 

About level of interest= ,  I believe there is still energy in DTNRG and at least some of

that energy is spilling= over into these discussions.

 

Thanks - Fred

 

 

 

From: Eric T= ravis [mailto:eric.dot.travis@gmail.com]
Sent: Thursday, June 05, 2014 11:24 AM
To: Templin, Fred L
Cc: l.wood@surrey.ac.uk; mls.ietf@gmail.com; spencerdawkins.ietf@gma= il.com; dtn@ietf.org; iesg@ietf.org
Subject: Re: [dtn] DTN BoF Proposal for IETF90

 

Hi Fred,

While I wasn't intending to advocate either way on t= he items:

 

To point 1),= advancement of work items in the IETF is usually based on =93rough consens= us

and running = code=94 and there is plenty of interoperable running code that implements

RFC5050 and = its related specifications =96 much more than most IETF activities are base= d on.

 

My  "points worthy of discussion/debate th= roughout the BoF process" seems to be compatible with your

As to =93rough consensu= s=94, holding a BoF is the first step in determining that.


I'd contend that the *DTNRG* was the start of that discussion.  The *B= oF* is a continuation of a 7+ year community discussion.

 


There is an experimental RFC that has achieved interoperability between mul= tiple independent implementations.

That, however, isn't = necessarily a referendum on the maturity of the protocol(s) themselves.&nbs= p;

For those entities whose needs are satisfied with RF= C-5050, a standards-track document is not necessary for deployment.

Actually, a standards-track document is never *reall= y* necessary.  There are many middleware/application level "thing= s" deployed
that are not based on IETF standards.  The presumption of the BoF seem= s to be that RFC-5050 is NOT "there yet".  So, the
question is how close to maturity is close enough to go into a standards tr= ajectory.


>From the discussions on the list, there has been a lot of very promising di= alog of the nature of
"Yeah, it would be useful to *explore* Foo and/or Bar", from some= people that - frankly - pleasantly surprised me. 

This leads to the question - has the solution space = been adequately explored to have confidence that the result is

a mature (NOT perfect= )?  If not, will the WG be able to take it further than the RG was cap= able (and why is that true)?

That's a question, not a statement on my part.

 

 

 To point 2), agai= n the BoF will provide a useful measurement of interest.

 

I think the level of interest is relatively high wit= hin the DTNRG - and will likely be so for a DTN WG.  The question

really is if/how will that translate into measurable= progress (fixing the - some long acknowledged - nits in the protocol

specification.

The original idea of = a RFC5050.Bis was floated two (three?) years ago as part of the most recent= Google meeting.  It failed to gain
traction, despite what seemed to be a fair amount of community interest.

Is the lack of moveme= nt within the DTNRG simply because of the (lack of) path to a standards tra= ck RFC?

The question for the = BoF is, what caused the evolutionary pause, and how will a WG prevent it fr= om stalling again.



Just to be clear,  I'm in favor of a BoF and currently undecided/agnos= tic on support of a WG, these types of discussions would
be useful to me (at the very least).

Regards,

Eric

 

On Thu, Jun 5, 2014 at 1:38 PM, Templin, Fred L <= Fred.L.Templ= in@boeing.com> wrote:

Hi Eric,

 

To point 1),= advancement of work items in the IETF is usually based on =93rough consens= us

and running = code=94 and there is plenty of interoperable running code that implements

RFC5050 and = its related specifications =96 much more than most IETF activities are base= d on.

As to =93rou= gh consensus=94, holding a BoF is the first step in determining that.

 

To point 2),= again the BoF will provide a useful measurement of interest.

 

Thanks =96 F= red

fred.l.templin@boeing.co= m

 

 

From: dtn [mailto:= dtn-bounces@ietf.org] On Behalf Of Eric Travis
Sent: Thursday, June 05, 2014 9:29 AM
To: l.wood@= surrey.ac.uk
Cc: mls.ietf= @gmail.com; spencerd= awkins.ietf@gmail.com; dtn@ietf.org; iesg@ietf.org


Subject: Re: [dtn] DTN BoF Proposal for IETF90

 

Lloyd,



Embedded in your manifesto are two points worthy of discussion/debate throu= ghout the BoF process:

1) Is the proposed (base) solution - with "minimal" fixes - of su= fficient maturity for standardization within the IETF?

2) The existing IRTF DTNRG has not been able to harness sufficient interest= /resources to advance the state of RFC-5050, how will a new IETF WG change = the dynamic?

As for the rest of it, well...

RFC5050bis: half-assed, half-baked, rehea= ted.
But hey, ask me what I _really_ think.

 

Let the rational, wel= l-reasoned discussion begin...

Eric

eric.dot.travis@gmail.com

 

On Thu, Jun 5, 2014 at 7:20 AM, <l.wood@surrey.ac.uk= > wrote:

As previously expressed on DTNRG, I have = a number of concerns about
this proposed BOF to create an IETF DTN WG to do work on the
RFC5050 bundle protocol, produced in the IRTF DTNRG, and create
an RFC5050bis. I'll go through those concerns one by one:


1. I don't see how going standards track can be justified, because:

   a. CCSDS is already working on the bundle protocol as one of t= heir
      blue book standards, based on RFC5050, and any RFC5050= bis
      would presumably also be adopted and then modified to = make
      a CCSDS standard.
      It's rather like CCSDS restandardizing TCP/IP as SCPS,= back
      in the 1990s. That SCPS standardization wasn't used mu= ch
      either, not least because CCSDS 'improved' on TCP/IP       and went incompatible quite quickly. The same will hap= pen
      with the CCSDS bundle protocol, and in adopting RFC505= 0
      CCSDS has reserved the right to make changes - things = like
      Delay Tolerant Payload Conditioning (DTPC) are but the= start.
      There's an example of bundle protocol work not requiri= ng
      the IETF. Work on altering and extending the bundle pr= otocol
      is already ongoing in CCSDS.
      Setting up an IETF workgroup to work in parallel would= mean
      that a CCSDS liaison would be required, to pay attenti= on
      to their concerns as they try and convince their membe= r space
      agencies to use the bundle protocol, and to prevent th= eir spec
      from diverging (further) from the IETF spec. Really, t= he work
      is simply more easily done in CCSDS, given that CCSDS = is
      pretty much the only customer for bundle protocol, bec= ause
      NASA has mandated bundle protocol use from on high.       NASA leads CCSDS, NASA Jet Propulsion Lab leads CCSDS = design
      for NASA's Space Communications and Navigation people.=
      JPL is really the primary customer for and user of bun= dle
      protocol, responsible for promoting its use by other s= pace
      agencies - never an easy task, even with good technolo= gies.

   b. The IETF produces Internet standards. The bundle protocol       has little bearing on or interaction with Internet sta= ndards;
      it's arguably a way to interoperate with the Internet = while
      protecting CCSDS from incursion of the Internet, by la= yering
      over both Internet and CCSDS. Each to their own domain= s.
      Using TCP as the most common bundle convergence layer = (described
      in a draft now seven years old) does not make the bund= le protocol
      an internet standard. If it did, then CCSDS's Space Li= nk
      Extension (basically a TCP tunnel carrying CCSDS frame= s, with
      much added complexity) would also be a candidate for a= n
      IETF internet standard.
      But, again, that work is best done in CCSDS, where the= re
      is interest in having it done and there are users. (So= me
      of those users may even be willing users.)

   c. The bundle protocol is not mature. Deficiencies have been       identified, drafts have been written in DTNRG over the= years,
      there was little interest, the drafts expired, the bun= dle
      protocol was never improved. And that's just from demo= nstrations;
      there has not been extended operational use to my know= ledge.
      Attempting to fix the bundle protocol AND push it thro= ugh as
      standards track at the same time seems unwarranted.       It may be politically motivated, but it is
      not technically or procedurally justifiable.
      There isn't the userbase or demand needed for the bund= le
      protocol to go standards track, and if the IETF did go=
      standards track, CCSDS would 'optimize' that standard = into
      its own standard, just as was done with SCPS, meaning = that
      the IETF would spend a lot of time working on somethin= g with
      no benefit to the IETF community or userbase. Extendin= g
      the Internet protocols to the DTN network problem spac= e
      adds value to the internet protocols. A separate proto= col
      does not.
      Who would benefit, outside the CCSDS community? And CC= SDS
      is their own standards org - an ISO subgroup - to do w= ork
      for that CCSDS community.


2. I don't see why this needs to be done in an IETF WG, because:

   a. going standards track isn't justifiable - see 1.

   b. There's already the IRTF DTNRG, which could clean up its       own work, but ,after many years and some failed drafts= ,
      has not.
      Declaring success and saying it is now time to create = a
      WG based on DTNRG's achievements is not convincing,       because those achievements are not impressive.
      (Disclaimer of interest: I authored 'A bundle of probl= ems'
      and have spent considerable years trying to explain an= d
      address problems with the bundle protocol, with little=
      success, after getting it tested in space before NASA'= s
      EXPOXI/Deep Impact tests took place.
      Fred Templin's problem statement drafts for this putat= ive
      IETF BOF calls on that work.)
      RFC5050bis would make more sense as a DTNRG
      effort, though it would be time for a changing of the<= br>       guard and chairs in DTNRG to infuse some new blood and=
      technical judgement - or we're in for another five yea= rs
      of what-does-the-end-to-end-principle-really-mean and<= br>       what-about-clocks and rehashing the same old arguments= .
      Really, DTNRG needs to get its act together, both
      organizationally and technically.

   c. There's already CCSDS, which has adopted the DTNRG output,<= br>       after pushing for the formation of an Interplanetary       Internet RG in the first place.

So either CCSDS or DTNRG can do RFC5050 revision work. If
it's to be an RFC, experimental or informational, a revitalised
rechartered DTNRG can do it.
It doesn't need to be an IETF workgroup. It certainly
shouldn't go standards track.


3. The philosophically shaky basis for the bundle protocol:

   a. Delay-tolerant networking is not disruption-tolerant
      networking. Space delays of light-minutes with schedul= ed
      contacts are not the same as intermittent ad-hoc
      manet-style communications. Different requirements,       different buffering and storage, different conditions,=
      different handling of fragmentation, etc.

   b. The bundle protocol is not DTN. DTN is the scenario,
      in which other approaches (the related CFDP, Haggle,       the MANET and vehicular DTNs efforts that DTN subsumed=
      and rebranded, etc.) exist.
      The bundle protocol is intended to be used in a DTN       scenario. Branding the bundle protocol as DTN has
      put back non-bundle DTN research a number of years.       Branding a group only working on the bundle protocol       as 'DTN' is misleading at best.

   c. Extending the bundle protocol from the original
      Interplanetary Internet problem (which had its own
      IRTF RG which led into a set bundle agenda for
      DTNRG) to cover everything else as well simply hasn't<= br>       worked very well, because the scenarios and use cases<= br>       are different. We design for use cases. To be too
      generalised is to engineer for nothing.

   d. Ignoring the ramifications of the end-to-end principle,
      which are often more subtle than people seem to think<= br>       they are. The bundle protocol's custody transfer
      procedure is a good example of this failing.

   e. The bundle protocol is intended for use in the most
      difficult noisy disrupted networking conditions we kno= w,
      and it can't even sanity check its own headers against=
      errors. (But hey, it now has a security protocol that<= br>       _almost_ does that! But which is too complicated, and<= br>       would need to be redone.)
      It's intended for the harshest environments we know,       but needs reliable synchronized clocks running at
      steady temperatures!
      It's intended for embedded systems, but the design
      is huge and complex! (CFDP has the same problem;
      there's a reason implementers went for a "CFDP li= te,"
      and Saratoga exists just because CFDP wasn't performin= g.
      Would RFC5050bis be "bundling lite"?)
      There are many 'that makes no sense' moments - normall= y
      more immediately visible to outsiders not steeped in       the dogma, politics, and history of DTNRG and CCSDS.
   f. The assumption that a full security suite is desirable
      and necessary at all times. This has derailed DTNRG,       as emphasis was placed on security work above all
      else, rather than working to the scenario. To be fair<= br>       to the security-focused chairs, the charter that
      established DTNRG from the interplanetary internet
      research group called out security heavily, and they       ran with that mandate. But the focus has decreased
      work on non-security matters, which is to say,
      everything else.

RFC5050bis might address the latter three problems, but
the first three are intrinsically unsolvable; any solution
will be unsatisfactory. Perhaps not as unsatisfactory as
RFC5050, but unsatisfactory nonetheless.

The real philosophical problem here is the political dogma
that, whatever the problem, the bundle protocol is The
One True Solution.


4. The draft BOF charter is bundle-centric. Which is to say,
   that it's not awfully relevant to internet standards.
   Disclaimer of interest: we've worked on Saratoga and
   HTTP-DTN, which have current internet-drafts, and are
   squarely in the DTN problem space.
   Whenever someone talks about multiple convergence
   layers for the bundle protocol - there's more than for BEEP,    which just has TCP, but there aren't many - Saratoga may
   be mentioned. But we've found that carrying bundles doesn't    benefit Saratoga - tested it in space, didn't see the
   advantages. Saratoga does leverage a few Internet things -
   UDP, UDP-Lite, multicast. It does a few scaling things that    nothing else I've seen does (described in our 2011 TSVAREA
   presentation to IETF 88 in November.) And it's based on
   a decade of operational use in the problem domain.
   HTTP-DTN leverages the HTTP suite and MIME, and comes up
   whenever wouldn't-it-be-nice-to-try-HTTP-for-DTN discussion    takes place.
   (I suspect that all of Stephen Farrell's N4C work could
   have been done over hop-by-hop HTTP a la HTTP-DTN, and
   would have worked just as well if not better. After all,
   it used TCP.)
   These and other efforts exist in a gap between DTNRG, which    is aware of the problem space, but thinks the bundle
   protocol is the solution despite mounting evidence to the
   contrary, and TSVWG, where the few actual transport
   experts live, without clout, or funding, or spare time.
   Those efforts are interesting enough to have implementations    kicking around too.
   And yet, the focus of this putative workgroup and BOF is
   solely on bundling, and not on evaluating these or other
   things that might exist in the problem space. There
   must be other things out there that would be of interest
   to such a DTN workgroup. What is proposed is not a DTN
   workgroup. The charter is basically a bundle workgroup.
   Can an interest in bundling and solely bundling (outside
   CCSDS, which is driving the push to use the bundle protocol)    be justified for an IETF workgroup? I really don't think so.
5. The bundle protocol work was, I gather, well-funded
   by a number of parties.
   I can't see a follow-on effort being anywhere near
   as well funded.

   a. I have no idea how much money NASA and CCSDS have put
      into this - first CFDP, then bundling, which now has       to provide a CFDP-like API to the users who were told<= br>       that CFDP was the future, and Licklider (LTP).
      Dragging CCSDS into the modern age of networking
      seems unlikely to ever happen, thanks to CCSDS having<= br>       little in the way of sane layering or separation of       functionality.
      I do have the luxury of not needing to work on CCSDS.<= br>       But if you want to work on CCSDS protocols, CCSDS is       the place to go. The IETF is not that place.

   b. DARPA poured money into DTN work - at least twenty
      million dollars, from the press releases I've seen.       I have no idea what DARPA got out of it in the
      years they were involved; haven't seen the reports.
My point is, all that money and effort and manpower and
over a decade of work and prior experience with CFDP and two
IRTF RGs, we have... RFC5050.
There is nowhere near as much money or effort or manpower
for doing a replacement.
Ergo, it might be suggested that the replacement is unlikely
to be as good as RFC5050, or as good as CFDP; at best,
the usual suspects will have less time and fewer resources
to repeat their original mistakes.

And transport expertise from TSVWG would be needed.
TSVWG is unfashionable, low-visibility, and has even
previously had trouble finding ADs with relevant expertise.
And TSVWG has a full plate with work on its existing
protocols; there is not a lot of expertise, and what there
is is spread thin.
So an RFC505bis effort is unlikely to get the expert
technical input that it sorely needs, even if an IETF
workgroup is set up. (CCSDS doesn't have that transport
focus.)

If, on the other hand, you believe good protocol design
can be done more cheaply and leverage actual Internet
standards to get Internet functionality working in
difficult networks where the full TCP/IP suite has
trouble, your options include Saratoga and HTTP-DTN!
http://sarat= oga.sourceforge.net/
h= ttp://sat-net.com/L.Wood/dtn/http-dtn.html
They'll truly extend the Internet to difficult
environments. The bundle protocol won't.

So, to conclude, there is no justification for going
standards track. There is little justification for an
IETF workgroup. There is more logic in rechartering and
repurposing the IRTF DTNRG, but the work may as well
be left to CCSDS entirely.

RFC5050bis: half-assed, half-baked, reheated.
But hey, ask me what I _really_ think.

Lloyd Wood
http://sat-net= .com/L.Wood/dtn/

_______________________________________________
dtn mailing list
dtn@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dtn




--

The problem with the world is that = the intelligent people are full of doubts,
while the stupid ones are full of confidence.

      &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;             - Charles Bukowski




--

The problem with the world is that the intelli= gent people are full of doubts,
while the stupid ones are full of confidence.

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;           - Charles Bukowski

--_000_140200954991123163surreyacuk_-- From nobody Thu Jun 5 16:15:59 2014 Return-Path: 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 EC04E1A0307 for ; Thu, 5 Jun 2014 16:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.684 X-Spam-Level: X-Spam-Status: No, score=-2.684 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, 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 awgxwVrqLWpJ for ; Thu, 5 Jun 2014 16:15:48 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C8C81A025B for ; Thu, 5 Jun 2014 16:15:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s55NFfJC006139; Thu, 5 Jun 2014 16:15:41 -0700 Received: from XCH-PHX-312.sw.nos.boeing.com (xch-phx-312.sw.nos.boeing.com [130.247.25.173]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s55NFWRQ005971 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 5 Jun 2014 16:15:33 -0700 Received: from XCH-BLV-302.nw.nos.boeing.com (2002:82f7:19d6::82f7:19d6) by XCH-PHX-312.sw.nos.boeing.com (2002:82f7:19ad::82f7:19ad) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 5 Jun 2014 16:15:32 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.105]) by XCH-BLV-302.nw.nos.boeing.com ([169.254.2.75]) with mapi id 14.03.0181.006; Thu, 5 Jun 2014 16:15:30 -0700 From: "Templin, Fred L" To: "l.wood@surrey.ac.uk" , "eric.dot.travis@gmail.com" Thread-Topic: [dtn] DTN BoF Proposal for IETF90 Thread-Index: Ac+AQa9Fez/CplZaSwyaLFpzb8tj0wAmbPuTAAIy0LAAEHKqgAAOXElQ///b5gCAAHUk8A== Date: Thu, 5 Jun 2014 23:15:30 +0000 Message-ID: <2134F8430051B64F815C691A62D983181B2BF8F4@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> <1401967219583.26821@surrey.ac.uk> <2134F8430051B64F815C691A62D983181B2BF435@XCH-BLV-504.nw.nos.boeing.com> , <2134F8430051B64F815C691A62D983181B2BF56C@XCH-BLV-504.nw.nos.boeing.com> <1402009549911.23163@surrey.ac.uk> In-Reply-To: <1402009549911.23163@surrey.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: multipart/alternative; boundary="_000_2134F8430051B64F815C691A62D983181B2BF8F4XCHBLV504nwnosb_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/sFaZClhciiG7338q12UnGZFQpf0 Cc: "mls.ietf@gmail.com" , "spencerdawkins.ietf@gmail.com" , "dtn@ietf.org" Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 23:15:57 -0000 --_000_2134F8430051B64F815C691A62D983181B2BF8F4XCHBLV504nwnosb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Lloyd, I realized after I posted that my language was ambiguous - my point is exac= tly that RFC5214 IS NOT an "official IETF standard", yet it is widely deployed in co= mmon systems. I did not at all intend to make any claim that it was a standard = - only to concur with Eric's point that: "Actually, a standards-track document is never *really* necessary." I apologize that I cited one of my own publications; I'm sure no one in the= se discussions has ever done that before. Thanks - Fred From: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk] Sent: Thursday, June 05, 2014 4:06 PM To: Templin, Fred L; eric.dot.travis@gmail.com Cc: mls.ietf@gmail.com; spencerdawkins.ietf@gmail.com; dtn@ietf.org Subject: RE: [dtn] DTN BoF Proposal for IETF90 (snipping IESG, who know this stuff, from cc) Fred, RFC5214, which you wrote, is NOT an "official IETF standard". It's informational for the community - see the 'Category: Informational' at top left. Being published as an RFC is NOT at all the same as being a standards-track candidate or being evaluated as an IETF standard. http://www.rfc-editor.org/search/rfc_search_detail.php?rfc=3D2026 See RFC2026 and whatever updates it these days - there are about a dozen later RFCs on nuances of how this standards process actually works, though the distinction is lost on outsiders (and, come to think of it, on some of = my coauthors, who just see a technical specification). Laymen often have troub= le telling the difference between an internet-draft and a published RFC; the nuances of the categories are beyond that. http://en.wikipedia.org/wiki/Internet_Standard has a layman introduction of sorts. Do you actually understand what you are asking for in proposing a BOF and W= G to produce a standards document, and why the IETF draws a difference betwee= n "experimental RFC" or "informational RFC" and "standards-track document"? "Category: Standards Track" has a far higher bar. > But, having an IETF standard is a demonstration that rough consensus has = deemed > the work as standards-worthy - a community stamp of approval, or at least= "no > objection". In brief, no. The RFCs that are IETF standards and standards-track document= s get more scrutiny than mere rough consensus. RFCs can be published with objections and warnings documented in them; see, for example, the warning on the informational RFC4938, where the IESG and the workgroup threw up their hands in horror at the whole thing, but since this PPPoE hack was already shipping, better to have it documented than not. Oh, and "I should know, I wrote one" is also an ad-hominem argument, which is to say, a logical fallacy - but at least it's not alone there. Goo= d job. So, now that you know this, do you want to re-evaluate your request for an IETF WG to produce a standards document? The bundle protocol was ready for an experimental RFC. But it's nowhere near mature enough for standards track. Lloyd Wood http://sat-net.com/L.Wood/dtn ________________________________ From: Templin, Fred L > Sent: Friday, 6 June 2014 4:42 AM To: Eric Travis Cc: Wood L Dr (Electronic Eng); mls.ietf@gmail.com; spencerdawkins.ietf@gmail.com; dt= n@ietf.org; iesg@ietf.org Subject: RE: [dtn] DTN BoF Proposal for IETF90 Hi Eric, It is true that having an official IETF standard is not a necessary precond= ition for one or more vendors to move forward with widely-deployed implementations. I sh= ould know; I wrote one: http://www.rfc-editor.org/rfc/rfc5214.txt But, having an IETF standard is a demonstration that rough consensus has de= emed the work as standards-worthy - a community stamp of approval, or at least "= no objection". About level of interest, I believe there is still energy in DTNRG and at l= east some of that energy is spilling over into these discussions. Thanks - Fred From: Eric Travis [mailto:eric.dot.travis@gmail.com] Sent: Thursday, June 05, 2014 11:24 AM To: Templin, Fred L Cc: l.wood@surrey.ac.uk; mls.ietf@gmail.com; spencerdawkins.ietf@gmail.com; dtn@ietf.org; iesg@ietf.org Subject: Re: [dtn] DTN BoF Proposal for IETF90 Hi Fred, While I wasn't intending to advocate either way on the items: To point 1), advancement of work items in the IETF is usually based on "rou= gh consensus and running code" and there is plenty of interoperable running code that im= plements RFC5050 and its related specifications - much more than most IETF activitie= s are based on. My "points worthy of discussion/debate throughout the BoF process" seems t= o be compatible with your As to "rough consensus", holding a BoF is the first step in determining tha= t. I'd contend that the *DTNRG* was the start of that discussion. The *BoF* i= s a continuation of a 7+ year community discussion. There is an experimental RFC that has achieved interoperability between mul= tiple independent implementations. That, however, isn't necessarily a referendum on the maturity of the protoc= ol(s) themselves. For those entities whose needs are satisfied with RFC-5050, a standards-tra= ck document is not necessary for deployment. Actually, a standards-track document is never *really* necessary. There ar= e many middleware/application level "things" deployed that are not based on IETF standards. The presumption of the BoF seems to = be that RFC-5050 is NOT "there yet". So, the question is how close to maturity is close enough to go into a standards tr= ajectory. >From the discussions on the list, there has been a lot of very promising di= alog of the nature of "Yeah, it would be useful to *explore* Foo and/or Bar", from some people th= at - frankly - pleasantly surprised me. This leads to the question - has the solution space been adequately explore= d to have confidence that the result is a mature (NOT perfect)? If not, will the WG be able to take it further tha= n the RG was capable (and why is that true)? That's a question, not a statement on my part. To point 2), again the BoF will provide a useful measurement of interest. I think the level of interest is relatively high within the DTNRG - and wil= l likely be so for a DTN WG. The question really is if/how will that translate into measurable progress (fixing the -= some long acknowledged - nits in the protocol specification. The original idea of a RFC5050.Bis was floated two (three?) years ago as pa= rt of the most recent Google meeting. It failed to gain traction, despite what seemed to be a fair amount of community interest. Is the lack of movement within the DTNRG simply because of the (lack of) pa= th to a standards track RFC? The question for the BoF is, what caused the evolutionary pause, and how wi= ll a WG prevent it from stalling again. Just to be clear, I'm in favor of a BoF and currently undecided/agnostic o= n support of a WG, these types of discussions would be useful to me (at the very least). Regards, Eric eric.dot.travis@gmail.com On Thu, Jun 5, 2014 at 1:38 PM, Templin, Fred L > wrote: Hi Eric, To point 1), advancement of work items in the IETF is usually based on "rou= gh consensus and running code" and there is plenty of interoperable running code that im= plements RFC5050 and its related specifications - much more than most IETF activitie= s are based on. As to "rough consensus", holding a BoF is the first step in determining tha= t. To point 2), again the BoF will provide a useful measurement of interest. Thanks - Fred fred.l.templin@boeing.com From: dtn [mailto:dtn-bounces@ietf.org] On Beh= alf Of Eric Travis Sent: Thursday, June 05, 2014 9:29 AM To: l.wood@surrey.ac.uk Cc: mls.ietf@gmail.com; spencerdawkins.ietf@gmai= l.com; dtn@ietf.org; iesg@ietf.org Subject: Re: [dtn] DTN BoF Proposal for IETF90 Lloyd, Embedded in your manifesto are two points worthy of discussion/debate throu= ghout the BoF process: 1) Is the proposed (base) solution - with "minimal" fixes - of sufficient m= aturity for standardization within the IETF? 2) The existing IRTF DTNRG has not been able to harness sufficient interest= /resources to advance the state of RFC-5050, how will a new IETF WG change = the dynamic? As for the rest of it, well... RFC5050bis: half-assed, half-baked, reheated. But hey, ask me what I _really_ think. Let the rational, well-reasoned discussion begin... Eric eric.dot.travis@gmail.com On Thu, Jun 5, 2014 at 7:20 AM, > wrote: As previously expressed on DTNRG, I have a number of concerns about this proposed BOF to create an IETF DTN WG to do work on the RFC5050 bundle protocol, produced in the IRTF DTNRG, and create an RFC5050bis. I'll go through those concerns one by one: 1. I don't see how going standards track can be justified, because: a. CCSDS is already working on the bundle protocol as one of their blue book standards, based on RFC5050, and any RFC5050bis would presumably also be adopted and then modified to make a CCSDS standard. It's rather like CCSDS restandardizing TCP/IP as SCPS, back in the 1990s. That SCPS standardization wasn't used much either, not least because CCSDS 'improved' on TCP/IP and went incompatible quite quickly. The same will happen with the CCSDS bundle protocol, and in adopting RFC5050 CCSDS has reserved the right to make changes - things like Delay Tolerant Payload Conditioning (DTPC) are but the start. There's an example of bundle protocol work not requiring the IETF. Work on altering and extending the bundle protocol is already ongoing in CCSDS. Setting up an IETF workgroup to work in parallel would mean that a CCSDS liaison would be required, to pay attention to their concerns as they try and convince their member space agencies to use the bundle protocol, and to prevent their spec from diverging (further) from the IETF spec. Really, the work is simply more easily done in CCSDS, given that CCSDS is pretty much the only customer for bundle protocol, because NASA has mandated bundle protocol use from on high. NASA leads CCSDS, NASA Jet Propulsion Lab leads CCSDS design for NASA's Space Communications and Navigation people. JPL is really the primary customer for and user of bundle protocol, responsible for promoting its use by other space agencies - never an easy task, even with good technologies. b. The IETF produces Internet standards. The bundle protocol has little bearing on or interaction with Internet standards; it's arguably a way to interoperate with the Internet while protecting CCSDS from incursion of the Internet, by layering over both Internet and CCSDS. Each to their own domains. Using TCP as the most common bundle convergence layer (described in a draft now seven years old) does not make the bundle protocol an internet standard. If it did, then CCSDS's Space Link Extension (basically a TCP tunnel carrying CCSDS frames, with much added complexity) would also be a candidate for an IETF internet standard. But, again, that work is best done in CCSDS, where there is interest in having it done and there are users. (Some of those users may even be willing users.) c. The bundle protocol is not mature. Deficiencies have been identified, drafts have been written in DTNRG over the years, there was little interest, the drafts expired, the bundle protocol was never improved. And that's just from demonstrations; there has not been extended operational use to my knowledge. Attempting to fix the bundle protocol AND push it through as standards track at the same time seems unwarranted. It may be politically motivated, but it is not technically or procedurally justifiable. There isn't the userbase or demand needed for the bundle protocol to go standards track, and if the IETF did go standards track, CCSDS would 'optimize' that standard into its own standard, just as was done with SCPS, meaning that the IETF would spend a lot of time working on something with no benefit to the IETF community or userbase. Extending the Internet protocols to the DTN network problem space adds value to the internet protocols. A separate protocol does not. Who would benefit, outside the CCSDS community? And CCSDS is their own standards org - an ISO subgroup - to do work for that CCSDS community. 2. I don't see why this needs to be done in an IETF WG, because: a. going standards track isn't justifiable - see 1. b. There's already the IRTF DTNRG, which could clean up its own work, but ,after many years and some failed drafts, has not. Declaring success and saying it is now time to create a WG based on DTNRG's achievements is not convincing, because those achievements are not impressive. (Disclaimer of interest: I authored 'A bundle of problems' and have spent considerable years trying to explain and address problems with the bundle protocol, with little success, after getting it tested in space before NASA's EXPOXI/Deep Impact tests took place. Fred Templin's problem statement drafts for this putative IETF BOF calls on that work.) RFC5050bis would make more sense as a DTNRG effort, though it would be time for a changing of the guard and chairs in DTNRG to infuse some new blood and technical judgement - or we're in for another five years of what-does-the-end-to-end-principle-really-mean and what-about-clocks and rehashing the same old arguments. Really, DTNRG needs to get its act together, both organizationally and technically. c. There's already CCSDS, which has adopted the DTNRG output, after pushing for the formation of an Interplanetary Internet RG in the first place. So either CCSDS or DTNRG can do RFC5050 revision work. If it's to be an RFC, experimental or informational, a revitalised rechartered DTNRG can do it. It doesn't need to be an IETF workgroup. It certainly shouldn't go standards track. 3. The philosophically shaky basis for the bundle protocol: a. Delay-tolerant networking is not disruption-tolerant networking. Space delays of light-minutes with scheduled contacts are not the same as intermittent ad-hoc manet-style communications. Different requirements, different buffering and storage, different conditions, different handling of fragmentation, etc. b. The bundle protocol is not DTN. DTN is the scenario, in which other approaches (the related CFDP, Haggle, the MANET and vehicular DTNs efforts that DTN subsumed and rebranded, etc.) exist. The bundle protocol is intended to be used in a DTN scenario. Branding the bundle protocol as DTN has put back non-bundle DTN research a number of years. Branding a group only working on the bundle protocol as 'DTN' is misleading at best. c. Extending the bundle protocol from the original Interplanetary Internet problem (which had its own IRTF RG which led into a set bundle agenda for DTNRG) to cover everything else as well simply hasn't worked very well, because the scenarios and use cases are different. We design for use cases. To be too generalised is to engineer for nothing. d. Ignoring the ramifications of the end-to-end principle, which are often more subtle than people seem to think they are. The bundle protocol's custody transfer procedure is a good example of this failing. e. The bundle protocol is intended for use in the most difficult noisy disrupted networking conditions we know, and it can't even sanity check its own headers against errors. (But hey, it now has a security protocol that _almost_ does that! But which is too complicated, and would need to be redone.) It's intended for the harshest environments we know, but needs reliable synchronized clocks running at steady temperatures! It's intended for embedded systems, but the design is huge and complex! (CFDP has the same problem; there's a reason implementers went for a "CFDP lite," and Saratoga exists just because CFDP wasn't performing. Would RFC5050bis be "bundling lite"?) There are many 'that makes no sense' moments - normally more immediately visible to outsiders not steeped in the dogma, politics, and history of DTNRG and CCSDS. f. The assumption that a full security suite is desirable and necessary at all times. This has derailed DTNRG, as emphasis was placed on security work above all else, rather than working to the scenario. To be fair to the security-focused chairs, the charter that established DTNRG from the interplanetary internet research group called out security heavily, and they ran with that mandate. But the focus has decreased work on non-security matters, which is to say, everything else. RFC5050bis might address the latter three problems, but the first three are intrinsically unsolvable; any solution will be unsatisfactory. Perhaps not as unsatisfactory as RFC5050, but unsatisfactory nonetheless. The real philosophical problem here is the political dogma that, whatever the problem, the bundle protocol is The One True Solution. 4. The draft BOF charter is bundle-centric. Which is to say, that it's not awfully relevant to internet standards. Disclaimer of interest: we've worked on Saratoga and HTTP-DTN, which have current internet-drafts, and are squarely in the DTN problem space. Whenever someone talks about multiple convergence layers for the bundle protocol - there's more than for BEEP, which just has TCP, but there aren't many - Saratoga may be mentioned. But we've found that carrying bundles doesn't benefit Saratoga - tested it in space, didn't see the advantages. Saratoga does leverage a few Internet things - UDP, UDP-Lite, multicast. It does a few scaling things that nothing else I've seen does (described in our 2011 TSVAREA presentation to IETF 88 in November.) And it's based on a decade of operational use in the problem domain. HTTP-DTN leverages the HTTP suite and MIME, and comes up whenever wouldn't-it-be-nice-to-try-HTTP-for-DTN discussion takes place. (I suspect that all of Stephen Farrell's N4C work could have been done over hop-by-hop HTTP a la HTTP-DTN, and would have worked just as well if not better. After all, it used TCP.) These and other efforts exist in a gap between DTNRG, which is aware of the problem space, but thinks the bundle protocol is the solution despite mounting evidence to the contrary, and TSVWG, where the few actual transport experts live, without clout, or funding, or spare time. Those efforts are interesting enough to have implementations kicking around too. And yet, the focus of this putative workgroup and BOF is solely on bundling, and not on evaluating these or other things that might exist in the problem space. There must be other things out there that would be of interest to such a DTN workgroup. What is proposed is not a DTN workgroup. The charter is basically a bundle workgroup. Can an interest in bundling and solely bundling (outside CCSDS, which is driving the push to use the bundle protocol) be justified for an IETF workgroup? I really don't think so. 5. The bundle protocol work was, I gather, well-funded by a number of parties. I can't see a follow-on effort being anywhere near as well funded. a. I have no idea how much money NASA and CCSDS have put into this - first CFDP, then bundling, which now has to provide a CFDP-like API to the users who were told that CFDP was the future, and Licklider (LTP). Dragging CCSDS into the modern age of networking seems unlikely to ever happen, thanks to CCSDS having little in the way of sane layering or separation of functionality. I do have the luxury of not needing to work on CCSDS. But if you want to work on CCSDS protocols, CCSDS is the place to go. The IETF is not that place. b. DARPA poured money into DTN work - at least twenty million dollars, from the press releases I've seen. I have no idea what DARPA got out of it in the years they were involved; haven't seen the reports. My point is, all that money and effort and manpower and over a decade of work and prior experience with CFDP and two IRTF RGs, we have... RFC5050. There is nowhere near as much money or effort or manpower for doing a replacement. Ergo, it might be suggested that the replacement is unlikely to be as good as RFC5050, or as good as CFDP; at best, the usual suspects will have less time and fewer resources to repeat their original mistakes. And transport expertise from TSVWG would be needed. TSVWG is unfashionable, low-visibility, and has even previously had trouble finding ADs with relevant expertise. And TSVWG has a full plate with work on its existing protocols; there is not a lot of expertise, and what there is is spread thin. So an RFC505bis effort is unlikely to get the expert technical input that it sorely needs, even if an IETF workgroup is set up. (CCSDS doesn't have that transport focus.) If, on the other hand, you believe good protocol design can be done more cheaply and leverage actual Internet standards to get Internet functionality working in difficult networks where the full TCP/IP suite has trouble, your options include Saratoga and HTTP-DTN! http://saratoga.sourceforge.net/ http://sat-net.com/L.Wood/dtn/http-dtn.html They'll truly extend the Internet to difficult environments. The bundle protocol won't. So, to conclude, there is no justification for going standards track. There is little justification for an IETF workgroup. There is more logic in rechartering and repurposing the IRTF DTNRG, but the work may as well be left to CCSDS entirely. RFC5050bis: half-assed, half-baked, reheated. But hey, ask me what I _really_ think. Lloyd Wood http://sat-net.com/L.Wood/dtn/ _______________________________________________ dtn mailing list dtn@ietf.org https://www.ietf.org/mailman/listinfo/dtn -- The problem with the world is that the intelligent people are full of doubt= s, while the stupid ones are full of confidence. = - Charles Bukowski -- The problem with the world is that the intelligent people are full of doubt= s, while the stupid ones are full of confidence. = - Charles Bukowski --_000_2134F8430051B64F815C691A62D983181B2BF8F4XCHBLV504nwnosb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Lloyd,

 <= /p>

I realized after I posted= that my language was ambiguous – my point is exactly that=

RFC5214 IS NOT an “= official IETF standard”, yet it is widely deployed in common

systems.  I did not = at all intend to make any claim that it was a standard – only to=

concur with Eric’s = point that:

 <= /p>

“Actually, a standa= rds-track document is never *really* necessary.”

 <= /p>

I apologize that I cited = one of my own publications; I’m sure no one in these

discussions has ever done= that before.

 <= /p>

Thanks - Fred<= /span>

 <= /p>

From: l.wood@s= urrey.ac.uk [mailto:l.wood@surrey.ac.uk]
Sent: Thursday, June 05, 2014 4:06 PM
To: Templin, Fred L; eric.dot.travis@gmail.com
Cc: mls.ietf@gmail.com; spencerdawkins.ietf@gmail.com; dtn@ietf.org<= br> Subject: RE: [dtn] DTN BoF Proposal for IETF90

 

(snipping IESG, who know this stuff, = from cc)

 

Fred,

 

RFC5214, which you wrote, is NOT an &= quot;official IETF standard".

It's informational for the community = - see the 'Category: Informational'

at top left.

 

Being published as an RFC is NOT at a= ll the same as being a standards-track

candidate or being evaluated as an IE= TF standard.

 

http://www.rfc-ed= itor.org/search/rfc_search_detail.php?rfc=3D2026

 

See RFC2026 and whatever updates= it these days - there are about a dozen

later RFCs on nuances of how this sta= ndards process actually works, though

the distinction is lost on outsiders = (and, come to think of it, on some of my

coauthors, who just see a technical s= pecification). Laymen often have trouble
telling the difference between an internet-draft and a published RFC;<= o:p>

the nuances of the categories are bey= ond that.

 

http://en.wikipedia.org/wiki/Internet_Sta= ndard

has a layman introduction of sorts.

 

Do you actually understand what you a= re asking for in proposing a BOF and WG

to produce a standards document, and = why the IETF draws a difference between

"experimental RFC" or = "informational RFC" and "standards-track document"?

"Category: Standards Track"= has a far higher bar.

 

 

<= /p>

 

In brief, no. The RFCs that are IETF = standards and standards-track documents

get more scrutiny than mere rough con= sensus. RFCs can be published with

objections and warnings document= ed in them; see, for example, the warning

on the informational RFC4938, where t= he IESG and the workgroup threw up

their hands in horror at the whole th= ing, but since this PPPoE hack was

already shipping, better to have it d= ocumented than not.

 

Oh, and "I should know, I wrote = one" is also an ad-hominem argument,

which is to say, a logical fallacy - = but at least it's not alone there. Good job.

 

So, now that you know this, do you wa= nt to re-evaluate your request

for an IETF WG to produce a standards= document? The bundle protocol

was ready for an experimental RFC. Bu= t it's nowhere near mature

enough for standards track.

From: Templin, Fred L <Fred.L.Templin@boeing.com>
Sent: Friday, 6 June 2014 4:42 AM
To: Eric Travis
Cc: Wood L Dr (Electronic Eng); mls.ietf@gmail.com; spencerdawkins.ietf@gmail.= com; dtn@ietf.org; iesg@ietf.org
Subject: RE: [dtn] DTN BoF Proposal for IETF90

 

=

http://www.rfc-edit= or.org/rfc/rfc5214.txt<= /span>

<= /p>

<= /p>

From: Eric Travis [mailto:eric.dot.travis@gmail.com]
Sent: Thursday, June 05, 2014 11:24 AM
To: Templin, Fred L
Cc: l.wood@surrey.ac.uk; = mls.ietf@gmail.com; sp= encerdawkins.ietf@gmail.com; dtn@ietf.org; iesg@ietf.org
Subject: Re: [dtn] DTN BoF Proposal for IETF90

 

Hi Fred,

While I wasn't intending to advocate either way on the items:

 

=

 

My  "points worthy of discussion/debate throughout the BoF p= rocess" seems to be compatible with your


I'd contend that the *DTNRG* was the start of that discussion.  The *B= oF* is a continuation of a 7+ year community discussion.

 


There is an experimental RFC that has achieved interoperability between mul= tiple independent implementations.

That, however, isn't necessarily a referendum on = the maturity of the protocol(s) themselves. 

For those entities whose needs are satisfied with RFC-5050, a standard= s-track document is not necessary for deployment.

Actually, a standards-track document is never *really* necessary. = ; There are many middleware/application level "things" deployed
that are not based on IETF standards.  The presumption of the BoF seem= s to be that RFC-5050 is NOT "there yet".  So, the
question is how close to maturity is close enough to go into a standards tr= ajectory.


>From the discussions on the list, there has been a lot of very promising di= alog of the nature of
"Yeah, it would be useful to *explore* Foo and/or Bar", from some= people that - frankly - pleasantly surprised me. 

This leads to the question - has the solution space been adequately ex= plored to have confidence that the result is

a mature (NOT perfect)?  If not, will the WG= be able to take it further than the RG was capable (and why is that true)?=

That's a question, not a statement on my part.

 

 

 To point 2), again the BoF wil= l provide a useful measurement of interest.

 

I think the level of interest is relatively high within the DTNRG - an= d will likely be so for a DTN WG.  The question

really is if/how will that translate into measurable progress (fixing = the - some long acknowledged - nits in the protocol

specification.

The original idea of a RFC5050.Bis was floated tw= o (three?) years ago as part of the most recent Google meeting.  It fa= iled to gain
traction, despite what seemed to be a fair amount of community interest.

Is the lack of movement within the DTNRG simply b= ecause of the (lack of) path to a standards track RFC?

The question for the BoF is, what caused the evol= utionary pause, and how will a WG prevent it from stalling again.



Just to be clear,  I'm in favor of a BoF and currently undecided/agnos= tic on support of a WG, these types of discussions would
be useful to me (at the very least).

Regards,

Eric

 

On Thu, Jun 5, 2014 at 1:38 PM, Templin, Fred L <Fred.L.Templin@boeing.com&= gt; wrote:

=

fred.l.tem= plin@boeing.com<= /p>

From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of Eric Travis
Sent: Thursday, June 05, 2014 9:29 AM
To: l.wood@= surrey.ac.uk
Cc: mls.ietf= @gmail.com; spencerd= awkins.ietf@gmail.com; dtn@ietf.org; iesg@ietf.org


Subject: Re: [dtn] DTN BoF Proposal for IETF90

 

Lloyd,



Embedded in your manifesto are two points worthy of discussion/debate throu= ghout the BoF process:

1) Is the proposed (base) solution - with "minimal" fixes - of su= fficient maturity for standardization within the IETF?

2) The existing IRTF DTNRG has not been able to harness sufficient interest= /resources to advance the state of RFC-5050, how will a new IETF WG change = the dynamic?

As for the rest of it, well...

RFC5050bis: half-assed, half-baked, reheated.
But hey, ask me what I _really_ think.

 

Let the rational, well-reasoned discussion begin.= ..

Eric

eric.do= t.travis@gmail.com

 

On Thu, Jun 5, 2014 at 7:20 AM, <l.wood@surrey.ac.uk> wrote:=

As previously expressed on DTNRG, I have a number of concerns about this proposed BOF to create an IETF DTN WG to do work on the
RFC5050 bundle protocol, produced in the IRTF DTNRG, and create
an RFC5050bis. I'll go through those concerns one by one:


1. I don't see how going standards track can be justified, because:

   a. CCSDS is already working on the bundle protocol as one of t= heir
      blue book standards, based on RFC5050, and any RFC5050= bis
      would presumably also be adopted and then modified to = make
      a CCSDS standard.
      It's rather like CCSDS restandardizing TCP/IP as SCPS,= back
      in the 1990s. That SCPS standardization wasn't used mu= ch
      either, not least because CCSDS 'improved' on TCP/IP       and went incompatible quite quickly. The same will hap= pen
      with the CCSDS bundle protocol, and in adopting RFC505= 0
      CCSDS has reserved the right to make changes - things = like
      Delay Tolerant Payload Conditioning (DTPC) are but the= start.
      There's an example of bundle protocol work not requiri= ng
      the IETF. Work on altering and extending the bundle pr= otocol
      is already ongoing in CCSDS.
      Setting up an IETF workgroup to work in parallel would= mean
      that a CCSDS liaison would be required, to pay attenti= on
      to their concerns as they try and convince their membe= r space
      agencies to use the bundle protocol, and to prevent th= eir spec
      from diverging (further) from the IETF spec. Really, t= he work
      is simply more easily done in CCSDS, given that CCSDS = is
      pretty much the only customer for bundle protocol, bec= ause
      NASA has mandated bundle protocol use from on high.       NASA leads CCSDS, NASA Jet Propulsion Lab leads CCSDS = design
      for NASA's Space Communications and Navigation people.=
      JPL is really the primary customer for and user of bun= dle
      protocol, responsible for promoting its use by other s= pace
      agencies - never an easy task, even with good technolo= gies.

   b. The IETF produces Internet standards. The bundle protocol       has little bearing on or interaction with Internet sta= ndards;
      it's arguably a way to interoperate with the Internet = while
      protecting CCSDS from incursion of the Internet, by la= yering
      over both Internet and CCSDS. Each to their own domain= s.
      Using TCP as the most common bundle convergence layer = (described
      in a draft now seven years old) does not make the bund= le protocol
      an internet standard. If it did, then CCSDS's Space Li= nk
      Extension (basically a TCP tunnel carrying CCSDS frame= s, with
      much added complexity) would also be a candidate for a= n
      IETF internet standard.
      But, again, that work is best done in CCSDS, where the= re
      is interest in having it done and there are users. (So= me
      of those users may even be willing users.)

   c. The bundle protocol is not mature. Deficiencies have been       identified, drafts have been written in DTNRG over the= years,
      there was little interest, the drafts expired, the bun= dle
      protocol was never improved. And that's just from demo= nstrations;
      there has not been extended operational use to my know= ledge.
      Attempting to fix the bundle protocol AND push it thro= ugh as
      standards track at the same time seems unwarranted.       It may be politically motivated, but it is
      not technically or procedurally justifiable.
      There isn't the userbase or demand needed for the bund= le
      protocol to go standards track, and if the IETF did go=
      standards track, CCSDS would 'optimize' that standard = into
      its own standard, just as was done with SCPS, meaning = that
      the IETF would spend a lot of time working on somethin= g with
      no benefit to the IETF community or userbase. Extendin= g
      the Internet protocols to the DTN network problem spac= e
      adds value to the internet protocols. A separate proto= col
      does not.
      Who would benefit, outside the CCSDS community? And CC= SDS
      is their own standards org - an ISO subgroup - to do w= ork
      for that CCSDS community.


2. I don't see why this needs to be done in an IETF WG, because:

   a. going standards track isn't justifiable - see 1.

   b. There's already the IRTF DTNRG, which could clean up its       own work, but ,after many years and some failed drafts= ,
      has not.
      Declaring success and saying it is now time to create = a
      WG based on DTNRG's achievements is not convincing,       because those achievements are not impressive.
      (Disclaimer of interest: I authored 'A bundle of probl= ems'
      and have spent considerable years trying to explain an= d
      address problems with the bundle protocol, with little=
      success, after getting it tested in space before NASA'= s
      EXPOXI/Deep Impact tests took place.
      Fred Templin's problem statement drafts for this putat= ive
      IETF BOF calls on that work.)
      RFC5050bis would make more sense as a DTNRG
      effort, though it would be time for a changing of the<= br>       guard and chairs in DTNRG to infuse some new blood and=
      technical judgement - or we're in for another five yea= rs
      of what-does-the-end-to-end-principle-really-mean and<= br>       what-about-clocks and rehashing the same old arguments= .
      Really, DTNRG needs to get its act together, both
      organizationally and technically.

   c. There's already CCSDS, which has adopted the DTNRG output,<= br>       after pushing for the formation of an Interplanetary       Internet RG in the first place.

So either CCSDS or DTNRG can do RFC5050 revision work. If
it's to be an RFC, experimental or informational, a revitalised
rechartered DTNRG can do it.
It doesn't need to be an IETF workgroup. It certainly
shouldn't go standards track.


3. The philosophically shaky basis for the bundle protocol:

   a. Delay-tolerant networking is not disruption-tolerant
      networking. Space delays of light-minutes with schedul= ed
      contacts are not the same as intermittent ad-hoc
      manet-style communications. Different requirements,       different buffering and storage, different conditions,=
      different handling of fragmentation, etc.

   b. The bundle protocol is not DTN. DTN is the scenario,
      in which other approaches (the related CFDP, Haggle,       the MANET and vehicular DTNs efforts that DTN subsumed=
      and rebranded, etc.) exist.
      The bundle protocol is intended to be used in a DTN       scenario. Branding the bundle protocol as DTN has
      put back non-bundle DTN research a number of years.       Branding a group only working on the bundle protocol       as 'DTN' is misleading at best.

   c. Extending the bundle protocol from the original
      Interplanetary Internet problem (which had its own
      IRTF RG which led into a set bundle agenda for
      DTNRG) to cover everything else as well simply hasn't<= br>       worked very well, because the scenarios and use cases<= br>       are different. We design for use cases. To be too
      generalised is to engineer for nothing.

   d. Ignoring the ramifications of the end-to-end principle,
      which are often more subtle than people seem to think<= br>       they are. The bundle protocol's custody transfer
      procedure is a good example of this failing.

   e. The bundle protocol is intended for use in the most
      difficult noisy disrupted networking conditions we kno= w,
      and it can't even sanity check its own headers against=
      errors. (But hey, it now has a security protocol that<= br>       _almost_ does that! But which is too complicated, and<= br>       would need to be redone.)
      It's intended for the harshest environments we know,       but needs reliable synchronized clocks running at
      steady temperatures!
      It's intended for embedded systems, but the design
      is huge and complex! (CFDP has the same problem;
      there's a reason implementers went for a "CFDP li= te,"
      and Saratoga exists just because CFDP wasn't performin= g.
      Would RFC5050bis be "bundling lite"?)
      There are many 'that makes no sense' moments - normall= y
      more immediately visible to outsiders not steeped in       the dogma, politics, and history of DTNRG and CCSDS.
   f. The assumption that a full security suite is desirable
      and necessary at all times. This has derailed DTNRG,       as emphasis was placed on security work above all
      else, rather than working to the scenario. To be fair<= br>       to the security-focused chairs, the charter that
      established DTNRG from the interplanetary internet
      research group called out security heavily, and they       ran with that mandate. But the focus has decreased
      work on non-security matters, which is to say,
      everything else.

RFC5050bis might address the latter three problems, but
the first three are intrinsically unsolvable; any solution
will be unsatisfactory. Perhaps not as unsatisfactory as
RFC5050, but unsatisfactory nonetheless.

The real philosophical problem here is the political dogma
that, whatever the problem, the bundle protocol is The
One True Solution.


4. The draft BOF charter is bundle-centric. Which is to say,
   that it's not awfully relevant to internet standards.
   Disclaimer of interest: we've worked on Saratoga and
   HTTP-DTN, which have current internet-drafts, and are
   squarely in the DTN problem space.
   Whenever someone talks about multiple convergence
   layers for the bundle protocol - there's more than for BEEP,    which just has TCP, but there aren't many - Saratoga may
   be mentioned. But we've found that carrying bundles doesn't    benefit Saratoga - tested it in space, didn't see the
   advantages. Saratoga does leverage a few Internet things -
   UDP, UDP-Lite, multicast. It does a few scaling things that    nothing else I've seen does (described in our 2011 TSVAREA
   presentation to IETF 88 in November.) And it's based on
   a decade of operational use in the problem domain.
   HTTP-DTN leverages the HTTP suite and MIME, and comes up
   whenever wouldn't-it-be-nice-to-try-HTTP-for-DTN discussion    takes place.
   (I suspect that all of Stephen Farrell's N4C work could
   have been done over hop-by-hop HTTP a la HTTP-DTN, and
   would have worked just as well if not better. After all,
   it used TCP.)
   These and other efforts exist in a gap between DTNRG, which    is aware of the problem space, but thinks the bundle
   protocol is the solution despite mounting evidence to the
   contrary, and TSVWG, where the few actual transport
   experts live, without clout, or funding, or spare time.
   Those efforts are interesting enough to have implementations    kicking around too.
   And yet, the focus of this putative workgroup and BOF is
   solely on bundling, and not on evaluating these or other
   things that might exist in the problem space. There
   must be other things out there that would be of interest
   to such a DTN workgroup. What is proposed is not a DTN
   workgroup. The charter is basically a bundle workgroup.
   Can an interest in bundling and solely bundling (outside
   CCSDS, which is driving the push to use the bundle protocol)    be justified for an IETF workgroup? I really don't think so.
5. The bundle protocol work was, I gather, well-funded
   by a number of parties.
   I can't see a follow-on effort being anywhere near
   as well funded.

   a. I have no idea how much money NASA and CCSDS have put
      into this - first CFDP, then bundling, which now has       to provide a CFDP-like API to the users who were told<= br>       that CFDP was the future, and Licklider (LTP).
      Dragging CCSDS into the modern age of networking
      seems unlikely to ever happen, thanks to CCSDS having<= br>       little in the way of sane layering or separation of       functionality.
      I do have the luxury of not needing to work on CCSDS.<= br>       But if you want to work on CCSDS protocols, CCSDS is       the place to go. The IETF is not that place.

   b. DARPA poured money into DTN work - at least twenty
      million dollars, from the press releases I've seen.       I have no idea what DARPA got out of it in the
      years they were involved; haven't seen the reports.
My point is, all that money and effort and manpower and
over a decade of work and prior experience with CFDP and two
IRTF RGs, we have... RFC5050.
There is nowhere near as much money or effort or manpower
for doing a replacement.
Ergo, it might be suggested that the replacement is unlikely
to be as good as RFC5050, or as good as CFDP; at best,
the usual suspects will have less time and fewer resources
to repeat their original mistakes.

And transport expertise from TSVWG would be needed.
TSVWG is unfashionable, low-visibility, and has even
previously had trouble finding ADs with relevant expertise.
And TSVWG has a full plate with work on its existing
protocols; there is not a lot of expertise, and what there
is is spread thin.
So an RFC505bis effort is unlikely to get the expert
technical input that it sorely needs, even if an IETF
workgroup is set up. (CCSDS doesn't have that transport
focus.)

If, on the other hand, you believe good protocol design
can be done more cheaply and leverage actual Internet
standards to get Internet functionality working in
difficult networks where the full TCP/IP suite has
trouble, your options include Saratoga and HTTP-DTN!
http://sarat= oga.sourceforge.net/
h= ttp://sat-net.com/L.Wood/dtn/http-dtn.html
They'll truly extend the Internet to difficult
environments. The bundle protocol won't.

So, to conclude, there is no justification for going
standards track. There is little justification for an
IETF workgroup. There is more logic in rechartering and
repurposing the IRTF DTNRG, but the work may as well
be left to CCSDS entirely.

RFC5050bis: half-assed, half-baked, reheated.
But hey, ask me what I _really_ think.

Lloyd Wood
http://sat-net= .com/L.Wood/dtn/

_______________________________________________
dtn mailing list
dtn@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dtn




--

The problem with the world is that the intelligent people are fu= ll of doubts,
while the stupid ones are full of confidence.

           &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;        - Charles Bukowski




--

The problem with the world is that the intelligent people are fu= ll of doubts,
while the stupid ones are full of confidence.

           &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;        - Charles Bukowski

--_000_2134F8430051B64F815C691A62D983181B2BF8F4XCHBLV504nwnosb_-- From nobody Thu Jun 5 17:00:30 2014 Return-Path: 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 E9B4C1A0356 for ; Thu, 5 Jun 2014 17:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.841 X-Spam-Level: X-Spam-Status: No, score=-4.841 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] 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 B6MPJUCw8OMz for ; Thu, 5 Jun 2014 17:00:23 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10ADD1A0307 for ; Thu, 5 Jun 2014 17:00:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s5600Gn0012792; Thu, 5 Jun 2014 17:00:16 -0700 Received: from XCH-PHX-511.sw.nos.boeing.com (xch-phx-511.sw.nos.boeing.com [10.57.37.28]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s5600CMp012727 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 5 Jun 2014 17:00:12 -0700 Received: from XCH-BLV-206.nw.nos.boeing.com (10.57.37.16) by XCH-PHX-511.sw.nos.boeing.com (10.57.37.28) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 5 Jun 2014 17:00:11 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.105]) by XCH-BLV-206.nw.nos.boeing.com ([169.254.6.122]) with mapi id 14.03.0181.006; Thu, 5 Jun 2014 17:00:11 -0700 From: "Templin, Fred L" To: "Eggert, Lars" Thread-Topic: [dtn] DTN BoF Proposal for IETF90 Thread-Index: Ac+AQa9Fez/CplZaSwyaLFpzb8tj0wAiVZ0AAAXfQWAADdLFAA== Date: Fri, 6 Jun 2014 00:00:10 +0000 Message-ID: <2134F8430051B64F815C691A62D983181B2BF96C@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2BF3F7@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983181B2BF3F7@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: multipart/mixed; boundary="_002_2134F8430051B64F815C691A62D983181B2BF96CXCHBLV504nwnosb_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/Y5xW9xmT42_D7oVKgJydo5pbqkY Cc: "dtn@ietf.org" Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 00:00:27 -0000 --_002_2134F8430051B64F815C691A62D983181B2BF96CXCHBLV504nwnosb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Lars, Here is an update to the proposed charter based on your suggestions (see also attached diffs). Thanks - Fred fred.l.templin@boeing.com --- Draft BoF Agenda (2.5hrs): ************************** 1) Problem statement (IETF wg motivation) - 30min 2) RFC5050(bis) - 15min 3) Streamlined Bundle Security Protocol (SBSP) - 15min 4) Bundle-in-Bundle Encapsulation - 10min 5) Security Key Management - 10min 6) Registry for Service Identifiers - 10min 7) Network Management - 10min 8) Open Discussion - 50min Proposed working group charter: ******************************* Working group name:=20 Delay/Disruption Tolerant Networking Working Group (DTNWG) Chair(s): TBD Area and Area Director(s): Transport Area: ADs Spencer Dawkins , Martin Stiemerling Responsible Area Director: TBD Mailing list: General Discussion: dtn at ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dtn Archive: http://www.ietf.org/mail-archive/web/dtn/current/maillist.ht= ml Description of Working Group: The Delay/Disruption Tolerant Network Working Group (DTNWG) specifies mechanisms for data communications in the presence of long delays and/or intermittent connectivity. The work is motivated by well known limitations of standard Internet protocols that expect end-to-end connectivity between communicating endpoints, sub-second transmission delays and robust packet delivery ratios. In environments where these favorable conditions do not apply, existing mechanisms such as reliab= le transport protocols and routing protocols can fail to converge result= ing in communication failures. Furthermore, classical end-to-end security associations cannot be coordinated when communicating endpoints canno= t conduct multi-message keying exchanges in a timely fashion. These limitations suggest the need for a new approach.=20 =20 Delay-Tolerant Networking (DTN) protocols have been the subject of extensive research and development in the Delay-Tolerant Networking Research Group of the Internet Research Task Force since 2002. In particular, the DTN Bundle Protocol (RFC 5050) and Licklider Transmission Protocol (RFC 5326) have been shown to address the issues identified above in substantial fielded deployments [1]. The success of the BP/LTP protocol stack -- the core protocols of the "DTN Architecture" originally described in RFC 4838 -- may be attribu= ted to the following fundamental design principles: - There is never any expectation of contemporaneous end-to-end connectivity between any two network nodes. - Because end-to-end connectivity can never be assumed, each node on the path between source and destination must be prepared to handle incoming "bundles" of data that cannot immediately be forwarded. - Again because end-to-end connectivity can never be assumed, end-to-end conversational data exchange can never be assumed to complete in a timely manner; protocol features that rely on timely conversational data exchange must be excluded from the architecture. The DTNWG believes that protocols adhering to these principles offer opportunities for enhancing the functionality of the Internet - in particular, for facilitating the extension of the Internet into environments such as the ocean floor and deep space in which the core Internet protocols operate sub-optimally for the reasons discussed earlier. We believe that the extensive research, demonstration, and pilot operations performed to date using the DTNRG protocols provides a firm basis for publishing Internet standards derived from that work= . Work items related to Delay/Disruption Tolerant Networking include: o A mechanism for the exchange of protocol data units, termed "bundles", that are designed to obviate conversational communications by containing values for all potentially relevant configuration parameters. These protocol data units are typically larger than network-layer packets. We will derive this bundle exchange mechanism from the DTN Bundle Protocol (BP) documented in RFC 5050. Changes f= rom RFC 5050 will appear in a soon-to-be-published RFC 5050(bis). o A security protocol for ensuring that the network in which bundles are exchanged is secured against unauthorized access and denial of service attacks, and to ensure data integrity and confidentiality in that network where necessary. We will derive this security protocol from a "streamlined" adaptation of the DTN Bundle Security Protocol documented in RFC 6257. o An encapsulation protocol for "tunneling" BP traffic within bundles that are secured and/or routed in different way from the encapsulated bundles. o A delay-tolerant security key management scheme for ensuring that public keys are certified by a globally trusted authority to protect the integrity of the infrastructure. o A simple datagram convergence layer protocol for adaptation of the bundle protocol to underlying internetworks. We expect to derive this convergence layer protocol from the Datagram Convergence protocol documented in RFC 7122. o A delay-tolerant network management protocol for management of the infrastructure in the presence of long delays and/or intermittent connectivity. o A registry for DTN Service Identifiers =20 The working group will consider extending the current milestones based = on new information and knowledge gained while working on the initial chart= er, as well as to accommodate new work items beyond the scope of the initia= l phase. For example, we expect that transport protocols such as LTP and the Saratoga protocol are among the candidates for work in this phase. =20 Goals and Milestones: start+3mos - Submit 'Bundle Protocol Specification (RFC5050bis)' as a working group document. To be Proposed Standard. Start+3mos - Submit 'Streamlined Bundle Security Protocol (SBSP)' as a working group document. To be Proposed Standard. start+6mos - Submit 'Bundle In Bundle Encapsulation (BIBE)' as a working group document. To be Proposed Standard. start+12mos - Submit 'Delay Tolerant Networking Security Key Management' = as a working group document. To be Proposed Standard. start+18mos - WG determination for merging RFC5050bis, SBSP, BIBE and/or Key Mgmt into a combined draft or keep as separate drafts. start+18mos - Submit RFC5050bis, SBSP, BIBE and Key Mgmt to the IESG eith= er as a combined draft or as separate drafts. start+18mos - Submit Network Management, Registry and Simple Convergence Layer as working group documents. start+20mos - Survey appropriate forums (e.g., DTNRG) for emerging technologies (e.g., convergence layer protocols, dynamic routing protocols, naming and addressing services, etc.) ready for transition into IETF DTN Working Group. Publish draft on survey results as independent submission related to the WG. start+24mos - Submit Network Management, Registry and Simple Convergence Layer to IESG start+24mos - Recharter to accommodate new work items or close Working Gr= oup [1] BP/LTP deployment on EPOXI spacecraft [2008] --_002_2134F8430051B64F815C691A62D983181B2BF96CXCHBLV504nwnosb_ Content-Type: text/html; name="wdiff 01a_txt 02a_txt.htm" Content-Description: wdiff 01a_txt 02a_txt.htm Content-Disposition: attachment; filename="wdiff 01a_txt 02a_txt.htm"; size=30964; creation-date="Thu, 05 Jun 2014 23:54:09 GMT"; modification-date="Thu, 05 Jun 2014 23:54:09 GMT" Content-Transfer-Encoding: base64 CjxodG1sPjxoZWFkPjx0aXRsZT53ZGlmZiAwMWEudHh0IDAyYS50eHQ8L3RpdGxlPjwvaGVhZD48 Ym9keT4KPHByZT4KRHJhZnQgQm9GIEFnZW5kYSAoMi41aHJzKToKKioqKioqKioqKioqKioqKioq KioqKioqKioKMSkgUHJvYmxlbSBzdGF0ZW1lbnQgKElFVEYgd2cgbW90aXZhdGlvbikgLSAzMG1p bgoKMikgUkZDNTA1MChiaXMpIC0gPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJyA+MzBtaW48L2Zv bnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJyA+MTVtaW48L2ZvbnQ+PC9z dHJvbmc+CgozKSBTdHJlYW1saW5lZCBCdW5kbGUgU2VjdXJpdHkgUHJvdG9jb2wgKFNCU1ApIC0g PHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJyA+MzBtaW48L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+ PGZvbnQgY29sb3I9J2dyZWVuJyA+MTVtaW48L2ZvbnQ+PC9zdHJvbmc+Cgo0KSBCdW5kbGUtaW4t QnVuZGxlIEVuY2Fwc3VsYXRpb24gLSA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnID4xNW1pbjwv Zm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nID4xMG1pbjwvZm9udD48 L3N0cm9uZz4KCjUpIFNlY3VyaXR5IEtleSBNYW5hZ2VtZW50IC0gPHN0cmlrZT48Zm9udCBjb2xv cj0ncmVkJyA+MTVtaW48L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVu JyA+MTBtaW48L2ZvbnQ+PC9zdHJvbmc+Cgo2KSBSZWdpc3RyeSBmb3IgU2VydmljZSBJZGVudGlm aWVycyAtIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCcgPjE1bWluPC9mb250Pjwvc3RyaWtlPiA8 c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicgPjEwbWluPC9mb250Pjwvc3Ryb25nPgoKNykgTmV0 d29yayBNYW5hZ2VtZW50IC0gPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJyA+MTVtaW48L2ZvbnQ+ PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJyA+MTBtaW4KCjgpIE9wZW4gRGlz Y3Vzc2lvbiAtIDUwbWluPC9mb250Pjwvc3Ryb25nPgoKUHJvcG9zZWQgd29ya2luZyBncm91cCBj aGFydGVyOgoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCldvcmtpbmcgZ3JvdXAgbmFt ZToKCiAgICAgIERlbGF5L0Rpc3J1cHRpb24gVG9sZXJhbnQgTmV0d29ya2luZyBXb3JraW5nIEdy b3VwIChEVE5XRykKCkNoYWlyKHMpOgoKICAgICAgVEJECgpBcmVhIGFuZCBBcmVhIERpcmVjdG9y KHMpOgoKICAgICAgVHJhbnNwb3J0IEFyZWE6IEFEcyBTcGVuY2VyIERhd2tpbnMgJmx0O3NwZW5j ZXJkYXdraW5zLmlldGYgYXQgZ21haWwuY29tJmd0OywKICAgICAgICAgICAgICAgICAgICAgICAg ICBNYXJ0aW4gU3RpZW1lcmxpbmcgJmx0O21scy5pZXRmIGF0IGdtYWlsLmNvbSZndDsKClJlc3Bv bnNpYmxlIEFyZWEgRGlyZWN0b3I6CgogICAgICBUQkQKCk1haWxpbmcgbGlzdDoKCiAgICAgIEdl bmVyYWwgRGlzY3Vzc2lvbjogZHRuIGF0IGlldGYub3JnCiAgICAgIFRvIFN1YnNjcmliZTogaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kdG4KICAgICAgQXJjaGl2ZTogaHR0 cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2R0bi9jdXJyZW50L21haWxsaXN0Lmh0 bWwKCkRlc2NyaXB0aW9uIG9mIFdvcmtpbmcgR3JvdXA6CgogICAgICBUaGUgRGVsYXkvRGlzcnVw dGlvbiBUb2xlcmFudCBOZXR3b3JrIFdvcmtpbmcgR3JvdXAgKERUTldHKSBzcGVjaWZpZXMKICAg ICAgbWVjaGFuaXNtcyBmb3IgZGF0YSBjb21tdW5pY2F0aW9ucyBpbiB0aGUgcHJlc2VuY2Ugb2Yg bG9uZyBkZWxheXMKICAgICAgYW5kL29yIGludGVybWl0dGVudCBjb25uZWN0aXZpdHkuIFRoZSB3 b3JrIGlzIG1vdGl2YXRlZCBieSB3ZWxsIGtub3duCiAgICAgIGxpbWl0YXRpb25zIG9mIHN0YW5k YXJkIEludGVybmV0IHByb3RvY29scyB0aGF0IGV4cGVjdCBlbmQtdG8tZW5kCiAgICAgIGNvbm5l Y3Rpdml0eSBiZXR3ZWVuIGNvbW11bmljYXRpbmcgZW5kcG9pbnRzLCBzdWItc2Vjb25kIHRyYW5z bWlzc2lvbgogICAgICBkZWxheXMgYW5kIHJvYnVzdCBwYWNrZXQgZGVsaXZlcnkgcmF0aW9zLiBJ biBlbnZpcm9ubWVudHMgd2hlcmUgdGhlc2UKICAgICAgZmF2b3JhYmxlIGNvbmRpdGlvbnMgZG8g bm90IGFwcGx5LCBleGlzdGluZyBtZWNoYW5pc21zIHN1Y2ggYXMgcmVsaWFibGUKICAgICAgdHJh bnNwb3J0IHByb3RvY29scyBhbmQgcm91dGluZyBwcm90b2NvbHMgY2FuIGZhaWwgdG8gY29udmVy Z2UgcmVzdWx0aW5nCiAgICAgIGluIGNvbW11bmljYXRpb24gZmFpbHVyZXMuIEZ1cnRoZXJtb3Jl LCBjbGFzc2ljYWwgZW5kLXRvLWVuZCBzZWN1cml0eQogICAgICBhc3NvY2lhdGlvbnMgY2Fubm90 IGJlIGNvb3JkaW5hdGVkIHdoZW4gY29tbXVuaWNhdGluZyBlbmRwb2ludHMgY2Fubm90CiAgICAg IGNvbmR1Y3QgbXVsdGktbWVzc2FnZSBrZXlpbmcgZXhjaGFuZ2VzIGluIGEgdGltZWx5IGZhc2hp b24uIFRoZXNlCiAgICAgIGxpbWl0YXRpb25zIHN1Z2dlc3QgdGhlIG5lZWQgZm9yIGEgbmV3IGFw cHJvYWNoLgoKICAgICAgRGVsYXktVG9sZXJhbnQgTmV0d29ya2luZyAoRFROKSBwcm90b2NvbHMg aGF2ZSBiZWVuIHRoZSBzdWJqZWN0IG9mCiAgICAgIGV4dGVuc2l2ZSByZXNlYXJjaCBhbmQgZGV2 ZWxvcG1lbnQgaW4gdGhlIERlbGF5LVRvbGVyYW50IE5ldHdvcmtpbmcKICAgICAgUmVzZWFyY2gg R3JvdXAgb2YgdGhlIEludGVybmV0IFJlc2VhcmNoIFRhc2sgRm9yY2Ugc2luY2UgMjAwMi4gIElu CiAgICAgIHBhcnRpY3VsYXIsIHRoZSBEVE4gQnVuZGxlIFByb3RvY29sIChSRkMgNTA1MCkgYW5k IExpY2tsaWRlcgogICAgICBUcmFuc21pc3Npb24gUHJvdG9jb2wgKFJGQyA1MzI2KSBoYXZlIGJl ZW4gc2hvd24gdG8gYWRkcmVzcyB0aGUKICAgICAgaXNzdWVzIGlkZW50aWZpZWQgPHN0cmlrZT48 Zm9udCBjb2xvcj0ncmVkJyA+YWJvdmUuICBJbiAyMDA4LCBCUC9MVFAgd2FzIGRlcGxveWVkIG9u IHRoZSBFUE9YSQogICAgICBzcGFjZWNyYWZ0IGluIGRlZXAgc3BhY2UgYW5kIHdhcyB1c2VkIHRv IGNvbmR1Y3QgcmVsaWFibGUsIGF1dG9tYXRlZAogICAgICBjb21tdW5pY2F0aW9uIGZvciBmb3Vy IHdlZWtzIG92ZXIgYSBuZXR3b3JrIG9mIDEwIG5vZGVzPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25n Pjxmb250IGNvbG9yPSdncmVlbicgPmFib3ZlPC9mb250Pjwvc3Ryb25nPiBpbiA8c3RyaWtlPjxm b250IGNvbG9yPSdyZWQnID53aGljaCB0aGUKICAgICAgYm90dGxlbmVjayByb3V0ZXIgaW4gdGhl IG5ldHdvcmsgKHRoZSBzcGFjZWNyYWZ0KSB3YXMgdXAgdG8gMTAwIGxpZ2h0CiAgICAgIHNlY29u ZHMgZnJvbSBhbGwgb3RoZXIgbm9kZXMgYW5kIGNvbm5lY3Rpdml0eSB3aXRoIHRoZSByb3V0ZXIg d2FzCiAgICAgIHN1YmplY3QgdG8gcGVyaW9kcyBvZiBkaXNjb25uZWN0aW9uIGxhc3Rpbmcgc2V2 ZXJhbCBkYXlzLjwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nID5z dWJzdGFudGlhbCBmaWVsZGVkIGRlcGxveW1lbnRzIFsxXS48L2ZvbnQ+PC9zdHJvbmc+CgogICAg ICBUaGUgc3VjY2VzcyBvZiB0aGUgQlAvTFRQIHByb3RvY29sIHN0YWNrIC0tIHRoZSBjb3JlIHBy b3RvY29scyBvZiB0aGUKICAgICAgIkRUTiBBcmNoaXRlY3R1cmUiIG9yaWdpbmFsbHkgZGVzY3Jp YmVkIGluIFJGQyA0ODM4IC0tIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCcgPmluIHRoaXMKICAg ICAgZGVtb25zdHJhdGlvbjwvZm9udD48L3N0cmlrZT4gbWF5IGJlIGF0dHJpYnV0ZWQKICAgICAg dG8gdGhlIGZvbGxvd2luZyBmdW5kYW1lbnRhbCBkZXNpZ24gcHJpbmNpcGxlczoKCgktIFRoZXJl IGlzIG5ldmVyIGFueSBleHBlY3RhdGlvbiBvZiBjb250ZW1wb3JhbmVvdXMgZW5kLXRvLWVuZAog ICAgICAgICAgY29ubmVjdGl2aXR5IGJldHdlZW4gYW55IHR3byBuZXR3b3JrIG5vZGVzLiAgPHN0 cmlrZT48Zm9udCBjb2xvcj0ncmVkJyA+V2hlcmUgc3VjaCBjb25uZWN0aXZpdHkKICAgICAgIGlz IHN1c3RhaW5lZCwgdGhlIHByb3RvY29scyBsZXZlcmFnZSBpdCB0byBvcHRpbWl6ZSBwZXJmb3Jt YW5jZSwKICAgICAgIGJ1dCB0aGUgcG9zc2liaWxpdHkgb2YgdHJhbnNpZW50IGJ1dCBzdXN0YWlu ZWQgZGlzY29ubmVjdGlvbiBhdAogICAgICAgYW55IHRpbWUsIGFueXdoZXJlIGluIHRoZSBuZXR3 b3JrLCBpcyBhbHdheXMgcmVjb2duaXplZC48L2ZvbnQ+PC9zdHJpa2U+CgoJLSBCZWNhdXNlIGVu ZC10by1lbmQgY29ubmVjdGl2aXR5IGNhbiBuZXZlciBiZSBhc3N1bWVkLCBlYWNoIG5vZGUKCSAg b24gdGhlIHBhdGggYmV0d2VlbiBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uIG11c3QgYmUgcHJlcGFy ZWQgdG8KCSAgaGFuZGxlIGluY29taW5nICJidW5kbGVzIiBvZiBkYXRhIHRoYXQgY2Fubm90IGlt bWVkaWF0ZWx5IGJlCgkgIGZvcndhcmRlZC4gIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCcgPlN1 Y2ggYnVuZGxlcyBtdXN0IGVpdGhlciBiZSBzdG9yZWQgZm9yIGZ1dHVyZSB0cmFucy0KCSAgbWlz c2lvbiBvciBkaXNjYXJkZWQ7IGluIHRoZSBsYXR0ZXIgY2FzZSwgdGhlIG5ldHdvcmsgbXVzdAoJ ICBiZSBpbmZvcm1lZCBvZiB0aGlzIGRhdGEgbG9zcyBzbyB0aGF0IGFuIGFsdGVybmF0aXZlIHBh dGggbWF5CgkgIGJlIHNlbGVjdGVkLCB0byBhdm9pZCBpbXBhaXJpbmcgdGhlIHVzYWJpbGl0eSBv ZiB0aGUgbmV0d29yay48L2ZvbnQ+PC9zdHJpa2U+CgoJLSBBZ2FpbiBiZWNhdXNlIGVuZC10by1l bmQgY29ubmVjdGl2aXR5IGNhbiBuZXZlciBiZSBhc3N1bWVkLAoJICBlbmQtdG8tZW5kIGNvbnZl cnNhdGlvbmFsIGRhdGEgZXhjaGFuZ2UgY2FuIG5ldmVyIGJlIGFzc3VtZWQgdG8KCSAgY29tcGxl dGUgaW4gYSB0aW1lbHkgbWFubmVyOyBwcm90b2NvbCBmZWF0dXJlcyB0aGF0IHJlbHkgb24KCSAg dGltZWx5IGNvbnZlcnNhdGlvbmFsIGRhdGEgZXhjaGFuZ2UgbXVzdCBiZSBleGNsdWRlZCBmcm9t IHRoZQoJICBhcmNoaXRlY3R1cmUuICA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnID5UaGlzIHBy aW5jaXBsZSBtYWtlcyB0aGUgRFROIGFyY2hpdGVjdHVyZQoJICBzdWl0YWJsZSBub3Qgb25seSBm b3IgbmV0d29yayBlbnZpcm9ubWVudHMgY2hhcmFjdGVyaXplZCBieQoJICBsZW5ndGh5IGRpc2Nv bm5lY3Rpb24gYnV0IGFsc28gZm9yIHRob3NlIHRoYXQgYXJlIGNoYXJhY3Rlcml6ZWQKCSAgYnkg bG9uZyBzaWduYWwgcHJvcGFnYXRpb24gZGVsYXlzIChzdWNoIGFzIHVuZGVyd2F0ZXIgY29tbXVu aWNhdGlvbgoJICBieSBhY291c3RpYyBzaWduYWxzIG9yLCB3b3JzZSwgaW50ZXJwbGFuZXRhcnkg Y29tbXVuaWNhdGlvbikgZXZlbgoJICB3aGVuIGNvbm5lY3Rpdml0eSBpcyBjb250aW51b3VzLjwv Zm9udD48L3N0cmlrZT4KCiAgICAgIFRoZSBEVE5XRyBiZWxpZXZlcyB0aGF0IHByb3RvY29scyBh ZGhlcmluZyB0byB0aGVzZSBwcmluY2lwbGVzIG9mZmVyCiAgICAgIG9wcG9ydHVuaXRpZXMgZm9y IGVuaGFuY2luZyB0aGUgZnVuY3Rpb25hbGl0eSBvZiB0aGUgSW50ZXJuZXQgLSBpbgogICAgICBw YXJ0aWN1bGFyLCBmb3IgZmFjaWxpdGF0aW5nIHRoZSBleHRlbnNpb24gb2YgdGhlIEludGVybmV0 IGludG8KICAgICAgZW52aXJvbm1lbnRzIHN1Y2ggYXMgdGhlIG9jZWFuIGZsb29yIGFuZCBkZWVw IHNwYWNlIGluIHdoaWNoIHRoZSBjb3JlCiAgICAgIEludGVybmV0IHByb3RvY29scyBvcGVyYXRl IHN1Yi1vcHRpbWFsbHkgZm9yIHRoZSByZWFzb25zIGRpc2N1c3NlZAogICAgICBlYXJsaWVyLiAg V2UgYmVsaWV2ZSB0aGF0IHRoZSBleHRlbnNpdmUgcmVzZWFyY2gsIGRlbW9uc3RyYXRpb24sIGFu ZAogICAgICBwaWxvdCBvcGVyYXRpb25zIHBlcmZvcm1lZCB0byBkYXRlIHVzaW5nIHRoZSBEVE5S RyA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnID5wcm90b2NvbHMsIGJvdGgKICAgICAgYmVmb3Jl IGFuZCBhZnRlciB0aGUgRVBPWEkgZXhwZXJpbWVudCw8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+ PGZvbnQgY29sb3I9J2dyZWVuJyA+cHJvdG9jb2xzPC9mb250Pjwvc3Ryb25nPiBwcm92aWRlcwog ICAgICBhIGZpcm0gYmFzaXMgZm9yIHB1Ymxpc2hpbmcgSW50ZXJuZXQgc3RhbmRhcmRzIGRlcml2 ZWQgZnJvbSB0aGF0IHdvcmsuCgogICAgICBXb3JrIGl0ZW1zIHJlbGF0ZWQgdG8gRGVsYXkvRGlz cnVwdGlvbiBUb2xlcmFudCBOZXR3b3JraW5nIGluY2x1ZGU6CgogICAgICBvIEEgbWVjaGFuaXNt IGZvciB0aGUgZXhjaGFuZ2Ugb2YgcHJvdG9jb2wgZGF0YSB1bml0cywgdGVybWVkCgkiYnVuZGxl cyIsIHRoYXQgYXJlIGRlc2lnbmVkIHRvIG9idmlhdGUgY29udmVyc2F0aW9uYWwgY29tbXVuaWNh dGlvbnMKCWJ5IGNvbnRhaW5pbmcgdmFsdWVzIGZvciBhbGwgcG90ZW50aWFsbHkgcmVsZXZhbnQg Y29uZmlndXJhdGlvbgoJcGFyYW1ldGVycy4gIFRoZXNlIHByb3RvY29sIGRhdGEgdW5pdHMgYXJl IHR5cGljYWxseSBsYXJnZXIgdGhhbgoJbmV0d29yay1sYXllciBwYWNrZXRzLiAgV2UgPHN0cmlr ZT48Zm9udCBjb2xvcj0ncmVkJyA+ZXhwZWN0IHRvPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxm b250IGNvbG9yPSdncmVlbicgPndpbGw8L2ZvbnQ+PC9zdHJvbmc+IGRlcml2ZSB0aGlzIGJ1bmRs ZSBleGNoYW5nZSBtZWNoYW5pc20KICAgICAgICBmcm9tIHRoZSBEVE4gQnVuZGxlIFByb3RvY29s IChCUCkgZG9jdW1lbnRlZCBpbiBSRkMgNTA1MC4KICAgICAgICA8c3RyaWtlPjxmb250IGNvbG9y PSdyZWQnID5FeHBlY3RlZCBjaGFuZ2VzPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNv bG9yPSdncmVlbicgPkNoYW5nZXM8L2ZvbnQ+PC9zdHJvbmc+IGZyb20KICAgICAgICBSRkMgNTA1 MCA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnID5pbmNsdWRlIChidXQgYXJlIG5vdCBuZWNlc3Nh cmlseQogICAgICAgIGxpbWl0ZWQgdG8pOgoKICAgICAgICAgICAtPC9mb250Pjwvc3RyaWtlPiA8 c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicgPndpbGwgYXBwZWFyIGluPC9mb250Pjwvc3Ryb25n PiBhIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCcgPmNvbXByZXNzZWQgYnVuZGxlIGhlYWRlciBl bmNvZGluZyAoZGVyaXZlZCBmcm9tIFJGQzYyNjApCiAgICAgICAgICAgLSBhbiBpbW11dGFibGUg cHJpbWFyeSBibG9jayBzdHJ1Y3R1cmUKICAgICAgICAgICAtIHNpbXBsaWZpZWQgRUlEIHJlcHJl c2VudGF0aW9ucyAobm8gZGljdGlvbmFyeSkKICAgICAgICAgICAtIGFkZCBibG9jayBJRCB0byBl eHRlbnNpb24gYmxvY2tzIChlLmcuIHNlY3VyaXR5IGJsb2NrcykKICAgICAgICAgICAtIG1vdmUg Y3VzdG9kaWFuIHRvIGV4dGVuc2lvbiBibG9jawogICAgICAgICAgIC0gYWRkIHNpbXBsZSBoZWFk ZXIgYW5kIHBheWxvYWQgaW50ZWdyaXR5IGNoZWNrcwogICAgICAgICAgIC0gYWRkIHNpbXBsZSBj b250YWN0IGdyYXBoIHJvdXRpbmcgc3BlY2lmaWNhdGlvbgogICAgICAgICAgIC0gYWRkIHNpbXBs ZSBuZWlnaGJvciBkaXNjb3Zlcnkgc3BlY2lmaWNhdGlvbjwvZm9udD48L3N0cmlrZT4gPHN0cm9u Zz48Zm9udCBjb2xvcj0nZ3JlZW4nID5zb29uLXRvLWJlLXB1Ymxpc2hlZCBSRkMgNTA1MChiaXMp LjwvZm9udD48L3N0cm9uZz4KCiAgICAgIG8gQSBzZWN1cml0eSBwcm90b2NvbCBmb3IgZW5zdXJp bmcgdGhhdCB0aGUgbmV0d29yayBpbiB3aGljaCBidW5kbGVzCglhcmUgZXhjaGFuZ2VkIGlzIHNl Y3VyZWQgYWdhaW5zdCB1bmF1dGhvcml6ZWQgYWNjZXNzIGFuZCBkZW5pYWwgb2YKCXNlcnZpY2Ug YXR0YWNrcywgYW5kIHRvIGVuc3VyZSBkYXRhIGludGVncml0eSBhbmQgY29uZmlkZW50aWFsaXR5 CglpbiB0aGF0IG5ldHdvcmsgd2hlcmUgbmVjZXNzYXJ5LiAgV2UgPHN0cmlrZT48Zm9udCBjb2xv cj0ncmVkJyA+ZXhwZWN0IHRvPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdn cmVlbicgPndpbGw8L2ZvbnQ+PC9zdHJvbmc+IGRlcml2ZSB0aGlzIHNlY3VyaXR5Cglwcm90b2Nv bCBmcm9tIGEgInN0cmVhbWxpbmVkIiBhZGFwdGF0aW9uIG9mIHRoZSBEVE4gQnVuZGxlIFNlY3Vy aXR5CglQcm90b2NvbCBkb2N1bWVudGVkIGluIFJGQyA2MjU3LgoKICAgICAgbyBBbiBlbmNhcHN1 bGF0aW9uIHByb3RvY29sIGZvciAidHVubmVsaW5nIiBCUCB0cmFmZmljIHdpdGhpbiBidW5kbGVz Cgl0aGF0IGFyZSBzZWN1cmVkIGFuZC9vciByb3V0ZWQgaW4gZGlmZmVyZW50IHdheSBmcm9tIHRo ZSBlbmNhcHN1bGF0ZWQKCWJ1bmRsZXMuCgogICAgICBvIEEgZGVsYXktdG9sZXJhbnQgc2VjdXJp dHkga2V5IG1hbmFnZW1lbnQgc2NoZW1lIGZvciBlbnN1cmluZyB0aGF0CglwdWJsaWMga2V5cyBh cmUgY2VydGlmaWVkIGJ5IGEgZ2xvYmFsbHkgdHJ1c3RlZCBhdXRob3JpdHkgdG8gcHJvdGVjdAoJ dGhlIGludGVncml0eSBvZiB0aGUgaW5mcmFzdHJ1Y3R1cmUuCgogICAgICBvIEEgc2ltcGxlIGRh dGFncmFtIGNvbnZlcmdlbmNlIGxheWVyIHByb3RvY29sIGZvciBhZGFwdGF0aW9uIG9mIHRoZQog ICAgICAgIGJ1bmRsZSBwcm90b2NvbCB0byB1bmRlcmx5aW5nIGludGVybmV0d29ya3MuIFdlIGV4 cGVjdCB0byBkZXJpdmUKICAgICAgICB0aGlzIGNvbnZlcmdlbmNlIGxheWVyIHByb3RvY29sIGZy b20gdGhlIERhdGFncmFtIENvbnZlcmdlbmNlCiAgICAgICAgcHJvdG9jb2wgZG9jdW1lbnRlZCBp biA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnID5SRkM3MTIyLjwvZm9udD48L3N0cmlrZT4gPHN0 cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nID5SRkMgNzEyMi48L2ZvbnQ+PC9zdHJvbmc+CgogICAg ICBvIEEgZGVsYXktdG9sZXJhbnQgbmV0d29yayBtYW5hZ2VtZW50IHByb3RvY29sIGZvciBtYW5h Z2VtZW50IG9mIHRoZQogICAgICAgIGluZnJhc3RydWN0dXJlIGluIHRoZSBwcmVzZW5jZSBvZiBs b25nIGRlbGF5cyBhbmQvb3IgaW50ZXJtaXR0ZW50CiAgICAgICAgY29ubmVjdGl2aXR5LgoKICAg ICAgbyBBIHJlZ2lzdHJ5IGZvciBEVE4gU2VydmljZSBJZGVudGlmaWVycwoKICAgIFRoZSB3b3Jr aW5nIGdyb3VwIHdpbGwgY29uc2lkZXIgZXh0ZW5kaW5nIHRoZSBjdXJyZW50IG1pbGVzdG9uZXMg YmFzZWQgb24KICAgIG5ldyBpbmZvcm1hdGlvbiBhbmQga25vd2xlZGdlIGdhaW5lZCB3aGlsZSB3 b3JraW5nIG9uIHRoZSBpbml0aWFsIGNoYXJ0ZXIsCiAgICBhcyB3ZWxsIGFzIHRvIGFjY29tbW9k YXRlIG5ldyB3b3JrIGl0ZW1zIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhlIGluaXRpYWwKICAgIHBo YXNlLiAgRm9yIGV4YW1wbGUsIHdlIGV4cGVjdCB0aGF0IHRyYW5zcG9ydCBwcm90b2NvbHMgPHN0 cmlrZT48Zm9udCBjb2xvcj0ncmVkJyA+dW5pcXVlbHkgc3VpdGVkCiAgICB0byB0aGUgdmFyaW91 cyBjb21tdW5pY2F0aW9uIGVudmlyb25tZW50cyB0aGF0IG1heSBuZWVkIHRvIGJlIHRyYXZlcnNl ZAogICAgYnkgYSBzaW5nbGUgRFROIGVuZC10by1lbmQgcGF0aCAob3BlcmF0aW5nIHVuZGVyIEJQ LCBhdCB3aGF0IGlzIHRlcm1lZAogICAgdGhlIERUTiAiY29udmVyZ2VuY2UgbGF5ZXIiKSB3aWxs IG5lZWQgdG8gYmUgc3RhbmRhcmRpemVkIGluIGEgc2Vjb25kCiAgICBwaGFzZSBvZiB0aGUgd29y a2luZyBncm91cCdzIGNoYXJ0ZXI7PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9y PSdncmVlbicgPnN1Y2ggYXM8L2ZvbnQ+PC9zdHJvbmc+IExUUCBhbmQKICAgIHRoZSBTYXJhdG9n YSBwcm90b2NvbCBhcmUgYW1vbmcgdGhlIGNhbmRpZGF0ZXMgZm9yIHdvcmsgaW4gdGhpcyBwaGFz ZS4gIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCcgPlRoZXNlIGFkanVzdG1lbnRzIHdpbGwgYmUK ICAgIGFjY29tbW9kYXRlZCBpbiBhIHdvcmtpbmcgZ3JvdXAgcmVjaGFydGVyLCBhc3N1bWluZyB0 aGUgaW5pdGlhbAogICAgY2hhcnRlcmVkIGFjdGl2aXRpZXMgbWVldCB0aGVpciBkZWxpdmVyeSBt aWxlc3RvbmVzLiBQb3NzaWJsZSBuZXcgd29yawogICAgaXRlbXMgbXVzdCB0aGVuIHN0aWxsIGZp dCBpbnRvIHRoZSAocmVjaGFydGVyZWQpIERUTldHIGNoYXJ0ZXIgc2NvcGUuPC9mb250Pjwvc3Ry aWtlPgoKR29hbHMgYW5kIE1pbGVzdG9uZXM6CiAgc3RhcnQrM21vcyAtIFN1Ym1pdCAnQnVuZGxl IFByb3RvY29sIFNwZWNpZmljYXRpb24gKFJGQzUwNTBiaXMpJyBhcyBhCiAgICAgICAgICAgICAg IHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuIFRvIGJlIFByb3Bvc2VkIFN0YW5kYXJkLgogIFN0YXJ0 KzNtb3MgLSBTdWJtaXQgJ1N0cmVhbWxpbmVkIEJ1bmRsZSBTZWN1cml0eSBQcm90b2NvbCAoU0JT UCknIGFzIGEKICAgICAgICAgICAgICAgd29ya2luZyBncm91cCBkb2N1bWVudC4gVG8gYmUgUHJv cG9zZWQgU3RhbmRhcmQuCiAgc3RhcnQrNm1vcyAtIFN1Ym1pdCAnQnVuZGxlIEluIEJ1bmRsZSBF bmNhcHN1bGF0aW9uIChCSUJFKScgYXMgYSB3b3JraW5nCiAgICAgICAgICAgICAgIGdyb3VwIGRv Y3VtZW50LiBUbyBiZSBQcm9wb3NlZCBTdGFuZGFyZC4KICA8c3RyaWtlPjxmb250IGNvbG9yPSdy ZWQnID5zdGFydCs5bW9zPC9mb250Pjwvc3RyaWtlPgogIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dy ZWVuJyA+c3RhcnQrMTJtb3M8L2ZvbnQ+PC9zdHJvbmc+IC0gU3VibWl0ICdEZWxheSBUb2xlcmFu dCBOZXR3b3JraW5nIFNlY3VyaXR5IEtleSBNYW5hZ2VtZW50JyBhcwogICAgICAgICAgICAgICAg YSB3b3JraW5nIGdyb3VwIGRvY3VtZW50LiBUbyBiZSBQcm9wb3NlZCBTdGFuZGFyZC4KICA8c3Ry aWtlPjxmb250IGNvbG9yPSdyZWQnID5zdGFydCs5bW9zPC9mb250Pjwvc3RyaWtlPgogIDxzdHJv bmc+PGZvbnQgY29sb3I9J2dyZWVuJyA+c3RhcnQrMThtb3M8L2ZvbnQ+PC9zdHJvbmc+IC0gV0cg ZGV0ZXJtaW5hdGlvbiBmb3IgbWVyZ2luZyBSRkM1MDUwYmlzLCBTQlNQLCBCSUJFIGFuZC9vcgog ICAgICAgICAgICAgICAgS2V5IE1nbXQgaW50byBhIGNvbWJpbmVkIGRyYWZ0IG9yIGtlZXAgYXMg c2VwYXJhdGUgZHJhZnRzLgogIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCcgPnN0YXJ0KzEybW9z PC9mb250Pjwvc3RyaWtlPgogIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJyA+c3RhcnQrMTht b3M8L2ZvbnQ+PC9zdHJvbmc+IC0gU3VibWl0IFJGQzUwNTBiaXMsIFNCU1AsIEJJQkUgYW5kIEtl eSBNZ210IHRvIHRoZSBJRVNHIGVpdGhlcgogICAgICAgICAgICAgICAgYXMgYSBjb21iaW5lZCBk cmFmdCBvciBhcyBzZXBhcmF0ZSBkcmFmdHMuCiAgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJyA+ c3RhcnQrMTJtb3M8L2ZvbnQ+PC9zdHJpa2U+CiAgPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4n ID5zdGFydCsxOG1vczwvZm9udD48L3N0cm9uZz4gLSBTdWJtaXQgTmV0d29yayBNYW5hZ2VtZW50 LCBSZWdpc3RyeSBhbmQgU2ltcGxlIENvbnZlcmdlbmNlCiAgICAgICAgICAgICAgICBMYXllciBh cyB3b3JraW5nIGdyb3VwIGRvY3VtZW50cy4KICA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnID5z dGFydCsxNW1vczwvZm9udD48L3N0cmlrZT4KICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicg PnN0YXJ0KzIwbW9zPC9mb250Pjwvc3Ryb25nPiAtIFN1cnZleSBhcHByb3ByaWF0ZSBmb3J1bXMg KGUuZy4sIERUTlJHKSBmb3IgZW1lcmdpbmcKICAgICAgICAgICAgICAgIHRlY2hub2xvZ2llcyAo ZS5nLiwgY29udmVyZ2VuY2UgbGF5ZXIgcHJvdG9jb2xzLCBkeW5hbWljCiAgICAgICAgICAgICAg ICByb3V0aW5nIHByb3RvY29scywgbmFtaW5nIGFuZCBhZGRyZXNzaW5nIHNlcnZpY2VzLCBldGMu KQogICAgICAgICAgICAgICAgcmVhZHkgZm9yIHRyYW5zaXRpb24gaW50byBJRVRGIERUTiBXb3Jr aW5nIEdyb3VwLiBQdWJsaXNoCiAgICAgICAgICAgICAgICBkcmFmdCBvbiBzdXJ2ZXkgcmVzdWx0 cyBhcyBpbmRlcGVuZGVudCBzdWJtaXNzaW9uIHJlbGF0ZWQKICAgICAgICAgICAgICAgIHRvIHRo ZSBXRy4KICA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnID5zdGFydCsxOG1vczwvZm9udD48L3N0 cmlrZT4KICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicgPnN0YXJ0KzI0bW9zPC9mb250Pjwv c3Ryb25nPiAtIFN1Ym1pdCBOZXR3b3JrIE1hbmFnZW1lbnQsIFJlZ2lzdHJ5IGFuZCBTaW1wbGUg Q29udmVyZ2VuY2UKICAgICAgICAgICAgICAgIExheWVyIHRvIElFU0cKICA8c3RyaWtlPjxmb250 IGNvbG9yPSdyZWQnID5zdGFydCsxOG1vczwvZm9udD48L3N0cmlrZT4KICA8c3Ryb25nPjxmb250 IGNvbG9yPSdncmVlbicgPnN0YXJ0KzI0bW9zPC9mb250Pjwvc3Ryb25nPiAtIFJlY2hhcnRlciB0 byBhY2NvbW1vZGF0ZSBuZXcgd29yayBpdGVtcyBvciBjbG9zZSBXb3JraW5nIEdyb3VwCgo8c3Ry b25nPjxmb250IGNvbG9yPSdncmVlbicgPlsxXSBCUC9MVFAgZGVwbG95bWVudCBvbiBFUE9YSSBz cGFjZWNyYWZ0IFsyMDA4XTwvZm9udD48L3N0cm9uZz4KPC9wcmU+CjwvYm9keT48L2h0bWw+Clgt R2VuZXJhdG9yOiBweWh0IDAuMzUKCjwhLS0gYXJnczogeyctLW9sZGNvbG91cic6ICdyZWQnLCAn LS13aWR0aCc6ICcnLCAnZGlmZnR5cGUnOiAnLS1od2RpZmYnLCAnZmlsZW5hbWUyJzogJ0RyYWZ0 IEJvRiBBZ2VuZGEgKDIuNWhycyk6XHJcbioqKioqKioqKioqKioqKioqKioqKioqKioqXHJcbjEp IFByb2JsZW0gc3RhdGVtZW50IChJRVRGIHdnIG1vdGl2YXRpb24pIC0gMzBtaW5cclxuXHJcbjIp IFJGQzUwNTAoYmlzKSAtIDE1bWluXHJcblxyXG4zKSBTdHJlYW1saW5lZCBCdW5kbGUgU2VjdXJp dHkgUHJvdG9jb2wgKFNCU1ApIC0gMTVtaW5cclxuXHJcbjQpIEJ1bmRsZS1pbi1CdW5kbGUgRW5j YXBzdWxhdGlvbiAtIDEwbWluXHJcblxyXG41KSBTZWN1cml0eSBLZXkgTWFuYWdlbWVudCAtIDEw bWluXHJcblxyXG42KSBSZWdpc3RyeSBmb3IgU2VydmljZSBJZGVudGlmaWVycyAtIDEwbWluXHJc blxyXG43KSBOZXR3b3JrIE1hbmFnZW1lbnQgLSAxMG1pblxyXG5cclxuOCkgT3BlbiBEaXNjdXNz aW9uIC0gNTBtaW5cclxuXHJcblxyXG5Qcm9wb3NlZCB3b3JraW5nIGdyb3VwIGNoYXJ0ZXI6XHJc bioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKipcclxuV29ya2luZyBncm91cCBuYW1lOiBc clxuXHJcbiAgICAgIERlbGF5L0Rpc3J1cHRpb24gVG9sZXJhbnQgTmV0d29ya2luZyBXb3JraW5n IEdyb3VwIChEVE5XRylcclxuXHJcbkNoYWlyKHMpOlxyXG5cclxuICAgICAgVEJEXHJcblxyXG5B cmVhIGFuZCBBcmVhIERpcmVjdG9yKHMpOlxyXG5cclxuICAgICAgVHJhbnNwb3J0IEFyZWE6IEFE cyBTcGVuY2VyIERhd2tpbnMgX3NwZW5jZXJkYXdraW5zLmlldGYgYXQgZ21haWwuY29tXyxcclxu ICAgICAgICAgICAgICAgICAgICAgICAgICBNYXJ0aW4gU3RpZW1lcmxpbmcgX21scy5pZXRmIGF0 IGdtYWlsLmNvbV9cclxuXHJcblJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3I6XHJcblxyXG4gICAg ICBUQkRcclxuXHJcbk1haWxpbmcgbGlzdDpcclxuXHJcbiAgICAgIEdlbmVyYWwgRGlzY3Vzc2lv bjogZHRuIGF0IGlldGYub3JnXHJcbiAgICAgIFRvIFN1YnNjcmliZTogaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kdG5cclxuICAgICAgQXJjaGl2ZTogaHR0cDovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2R0bi9jdXJyZW50L21haWxsaXN0Lmh0bWxcclxuXHJc bkRlc2NyaXB0aW9uIG9mIFdvcmtpbmcgR3JvdXA6XHJcblxyXG4gICAgICBUaGUgRGVsYXkvRGlz cnVwdGlvbiBUb2xlcmFudCBOZXR3b3JrIFdvcmtpbmcgR3JvdXAgKERUTldHKSBzcGVjaWZpZXNc clxuICAgICAgbWVjaGFuaXNtcyBmb3IgZGF0YSBjb21tdW5pY2F0aW9ucyBpbiB0aGUgcHJlc2Vu Y2Ugb2YgbG9uZyBkZWxheXNcclxuICAgICAgYW5kL29yIGludGVybWl0dGVudCBjb25uZWN0aXZp dHkuIFRoZSB3b3JrIGlzIG1vdGl2YXRlZCBieSB3ZWxsIGtub3duXHJcbiAgICAgIGxpbWl0YXRp b25zIG9mIHN0YW5kYXJkIEludGVybmV0IHByb3RvY29scyB0aGF0IGV4cGVjdCBlbmQtdG8tZW5k XHJcbiAgICAgIGNvbm5lY3Rpdml0eSBiZXR3ZWVuIGNvbW11bmljYXRpbmcgZW5kcG9pbnRzLCBz dWItc2Vjb25kIHRyYW5zbWlzc2lvblxyXG4gICAgICBkZWxheXMgYW5kIHJvYnVzdCBwYWNrZXQg ZGVsaXZlcnkgcmF0aW9zLiBJbiBlbnZpcm9ubWVudHMgd2hlcmUgdGhlc2VcclxuICAgICAgZmF2 b3JhYmxlIGNvbmRpdGlvbnMgZG8gbm90IGFwcGx5LCBleGlzdGluZyBtZWNoYW5pc21zIHN1Y2gg YXMgcmVsaWFibGVcclxuICAgICAgdHJhbnNwb3J0IHByb3RvY29scyBhbmQgcm91dGluZyBwcm90 b2NvbHMgY2FuIGZhaWwgdG8gY29udmVyZ2UgcmVzdWx0aW5nXHJcbiAgICAgIGluIGNvbW11bmlj YXRpb24gZmFpbHVyZXMuIEZ1cnRoZXJtb3JlLCBjbGFzc2ljYWwgZW5kLXRvLWVuZCBzZWN1cml0 eVxyXG4gICAgICBhc3NvY2lhdGlvbnMgY2Fubm90IGJlIGNvb3JkaW5hdGVkIHdoZW4gY29tbXVu aWNhdGluZyBlbmRwb2ludHMgY2Fubm90XHJcbiAgICAgIGNvbmR1Y3QgbXVsdGktbWVzc2FnZSBr ZXlpbmcgZXhjaGFuZ2VzIGluIGEgdGltZWx5IGZhc2hpb24uIFRoZXNlXHJcbiAgICAgIGxpbWl0 YXRpb25zIHN1Z2dlc3QgdGhlIG5lZWQgZm9yIGEgbmV3IGFwcHJvYWNoLiBcclxuICAgICAgXHJc biAgICAgIERlbGF5LVRvbGVyYW50IE5ldHdvcmtpbmcgKERUTikgcHJvdG9jb2xzIGhhdmUgYmVl biB0aGUgc3ViamVjdCBvZlxyXG4gICAgICBleHRlbnNpdmUgcmVzZWFyY2ggYW5kIGRldmVsb3Bt ZW50IGluIHRoZSBEZWxheS1Ub2xlcmFudCBOZXR3b3JraW5nXHJcbiAgICAgIFJlc2VhcmNoIEdy b3VwIG9mIHRoZSBJbnRlcm5ldCBSZXNlYXJjaCBUYXNrIEZvcmNlIHNpbmNlIDIwMDIuICBJblxy XG4gICAgICBwYXJ0aWN1bGFyLCB0aGUgRFROIEJ1bmRsZSBQcm90b2NvbCAoUkZDIDUwNTApIGFu ZCBMaWNrbGlkZXJcclxuICAgICAgVHJhbnNtaXNzaW9uIFByb3RvY29sIChSRkMgNTMyNikgaGF2 ZSBiZWVuIHNob3duIHRvIGFkZHJlc3MgdGhlXHJcbiAgICAgIGlzc3VlcyBpZGVudGlmaWVkIGFi b3ZlIGluIHN1YnN0YW50aWFsIGZpZWxkZWQgZGVwbG95bWVudHMgWzFdLlxyXG5cclxuICAgICAg VGhlIHN1Y2Nlc3Mgb2YgdGhlIEJQL0xUUCBwcm90b2NvbCBzdGFjayAtLSB0aGUgY29yZSBwcm90 b2NvbHMgb2YgdGhlXHJcbiAgICAgICJEVE4gQXJjaGl0ZWN0dXJlIiBvcmlnaW5hbGx5IGRlc2Ny aWJlZCBpbiBSRkMgNDgzOCAtLSBtYXkgYmUgYXR0cmlidXRlZFxyXG4gICAgICB0byB0aGUgZm9s bG93aW5nIGZ1bmRhbWVudGFsIGRlc2lnbiBwcmluY2lwbGVzOlxyXG5cclxuXHQtIFRoZXJlIGlz IG5ldmVyIGFueSBleHBlY3RhdGlvbiBvZiBjb250ZW1wb3JhbmVvdXMgZW5kLXRvLWVuZFxyXG4g ICAgICAgICAgY29ubmVjdGl2aXR5IGJldHdlZW4gYW55IHR3byBuZXR3b3JrIG5vZGVzLlxyXG5c clxuXHQtIEJlY2F1c2UgZW5kLXRvLWVuZCBjb25uZWN0aXZpdHkgY2FuIG5ldmVyIGJlIGFzc3Vt ZWQsIGVhY2ggbm9kZVxyXG5cdCAgb24gdGhlIHBhdGggYmV0d2VlbiBzb3VyY2UgYW5kIGRlc3Rp bmF0aW9uIG11c3QgYmUgcHJlcGFyZWQgdG9cclxuXHQgIGhhbmRsZSBpbmNvbWluZyAiYnVuZGxl cyIgb2YgZGF0YSB0aGF0IGNhbm5vdCBpbW1lZGlhdGVseSBiZVxyXG5cdCAgZm9yd2FyZGVkLlxy XG5cclxuXHQtIEFnYWluIGJlY2F1c2UgZW5kLXRvLWVuZCBjb25uZWN0aXZpdHkgY2FuIG5ldmVy IGJlIGFzc3VtZWQsXHJcblx0ICBlbmQtdG8tZW5kIGNvbnZlcnNhdGlvbmFsIGRhdGEgZXhjaGFu Z2UgY2FuIG5ldmVyIGJlIGFzc3VtZWQgdG9cclxuXHQgIGNvbXBsZXRlIGluIGEgdGltZWx5IG1h bm5lcjsgcHJvdG9jb2wgZmVhdHVyZXMgdGhhdCByZWx5IG9uXHJcblx0ICB0aW1lbHkgY29udmVy c2F0aW9uYWwgZGF0YSBleGNoYW5nZSBtdXN0IGJlIGV4Y2x1ZGVkIGZyb20gdGhlXHJcblx0ICBh cmNoaXRlY3R1cmUuXHJcblxyXG4gICAgICBUaGUgRFROV0cgYmVsaWV2ZXMgdGhhdCBwcm90b2Nv bHMgYWRoZXJpbmcgdG8gdGhlc2UgcHJpbmNpcGxlcyBvZmZlclxyXG4gICAgICBvcHBvcnR1bml0 aWVzIGZvciBlbmhhbmNpbmcgdGhlIGZ1bmN0aW9uYWxpdHkgb2YgdGhlIEludGVybmV0IC0gaW5c clxuICAgICAgcGFydGljdWxhciwgZm9yIGZhY2lsaXRhdGluZyB0aGUgZXh0ZW5zaW9uIG9mIHRo ZSBJbnRlcm5ldCBpbnRvXHJcbiAgICAgIGVudmlyb25tZW50cyBzdWNoIGFzIHRoZSBvY2VhbiBm bG9vciBhbmQgZGVlcCBzcGFjZSBpbiB3aGljaCB0aGUgY29yZVxyXG4gICAgICBJbnRlcm5ldCBw cm90b2NvbHMgb3BlcmF0ZSBzdWItb3B0aW1hbGx5IGZvciB0aGUgcmVhc29ucyBkaXNjdXNzZWRc clxuICAgICAgZWFybGllci4gIFdlIGJlbGlldmUgdGhhdCB0aGUgZXh0ZW5zaXZlIHJlc2VhcmNo LCBkZW1vbnN0cmF0aW9uLCBhbmRcclxuICAgICAgcGlsb3Qgb3BlcmF0aW9ucyBwZXJmb3JtZWQg dG8gZGF0ZSB1c2luZyB0aGUgRFROUkcgcHJvdG9jb2xzIHByb3ZpZGVzXHJcbiAgICAgIGEgZmly bSBiYXNpcyBmb3IgcHVibGlzaGluZyBJbnRlcm5ldCBzdGFuZGFyZHMgZGVyaXZlZCBmcm9tIHRo YXQgd29yay5cclxuXHJcbiAgICAgIFdvcmsgaXRlbXMgcmVsYXRlZCB0byBEZWxheS9EaXNydXB0 aW9uIFRvbGVyYW50IE5ldHdvcmtpbmcgaW5jbHVkZTpcclxuXHJcbiAgICAgIG8gQSBtZWNoYW5p c20gZm9yIHRoZSBleGNoYW5nZSBvZiBwcm90b2NvbCBkYXRhIHVuaXRzLCB0ZXJtZWRcclxuXHQi YnVuZGxlcyIsIHRoYXQgYXJlIGRlc2lnbmVkIHRvIG9idmlhdGUgY29udmVyc2F0aW9uYWwgY29t bXVuaWNhdGlvbnNcclxuXHRieSBjb250YWluaW5nIHZhbHVlcyBmb3IgYWxsIHBvdGVudGlhbGx5 IHJlbGV2YW50IGNvbmZpZ3VyYXRpb25cclxuXHRwYXJhbWV0ZXJzLiAgVGhlc2UgcHJvdG9jb2wg ZGF0YSB1bml0cyBhcmUgdHlwaWNhbGx5IGxhcmdlciB0aGFuXHJcblx0bmV0d29yay1sYXllciBw YWNrZXRzLiAgV2Ugd2lsbCBkZXJpdmUgdGhpcyBidW5kbGUgZXhjaGFuZ2UgbWVjaGFuaXNtXHJc biAgICAgICAgZnJvbSB0aGUgRFROIEJ1bmRsZSBQcm90b2NvbCAoQlApIGRvY3VtZW50ZWQgaW4g UkZDIDUwNTAuIENoYW5nZXMgZnJvbVxyXG4gICAgICAgIFJGQyA1MDUwIHdpbGwgYXBwZWFyIGlu IGEgc29vbi10by1iZS1wdWJsaXNoZWQgUkZDIDUwNTAoYmlzKS5cclxuXHJcbiAgICAgIG8gQSBz ZWN1cml0eSBwcm90b2NvbCBmb3IgZW5zdXJpbmcgdGhhdCB0aGUgbmV0d29yayBpbiB3aGljaCBi dW5kbGVzXHJcblx0YXJlIGV4Y2hhbmdlZCBpcyBzZWN1cmVkIGFnYWluc3QgdW5hdXRob3JpemVk IGFjY2VzcyBhbmQgZGVuaWFsIG9mXHJcblx0c2VydmljZSBhdHRhY2tzLCBhbmQgdG8gZW5zdXJl IGRhdGEgaW50ZWdyaXR5IGFuZCBjb25maWRlbnRpYWxpdHlcclxuXHRpbiB0aGF0IG5ldHdvcmsg d2hlcmUgbmVjZXNzYXJ5LiAgV2Ugd2lsbCBkZXJpdmUgdGhpcyBzZWN1cml0eVxyXG5cdHByb3Rv Y29sIGZyb20gYSAic3RyZWFtbGluZWQiIGFkYXB0YXRpb24gb2YgdGhlIERUTiBCdW5kbGUgU2Vj dXJpdHlcclxuXHRQcm90b2NvbCBkb2N1bWVudGVkIGluIFJGQyA2MjU3LlxyXG5cclxuICAgICAg byBBbiBlbmNhcHN1bGF0aW9uIHByb3RvY29sIGZvciAidHVubmVsaW5nIiBCUCB0cmFmZmljIHdp dGhpbiBidW5kbGVzXHJcblx0dGhhdCBhcmUgc2VjdXJlZCBhbmQvb3Igcm91dGVkIGluIGRpZmZl cmVudCB3YXkgZnJvbSB0aGUgZW5jYXBzdWxhdGVkXHJcblx0YnVuZGxlcy5cclxuXHJcbiAgICAg IG8gQSBkZWxheS10b2xlcmFudCBzZWN1cml0eSBrZXkgbWFuYWdlbWVudCBzY2hlbWUgZm9yIGVu c3VyaW5nIHRoYXRcclxuXHRwdWJsaWMga2V5cyBhcmUgY2VydGlmaWVkIGJ5IGEgZ2xvYmFsbHkg dHJ1c3RlZCBhdXRob3JpdHkgdG8gcHJvdGVjdFxyXG5cdHRoZSBpbnRlZ3JpdHkgb2YgdGhlIGlu ZnJhc3RydWN0dXJlLlxyXG5cclxuICAgICAgbyBBIHNpbXBsZSBkYXRhZ3JhbSBjb252ZXJnZW5j ZSBsYXllciBwcm90b2NvbCBmb3IgYWRhcHRhdGlvbiBvZiB0aGVcclxuICAgICAgICBidW5kbGUg cHJvdG9jb2wgdG8gdW5kZXJseWluZyBpbnRlcm5ldHdvcmtzLiBXZSBleHBlY3QgdG8gZGVyaXZl XHJcbiAgICAgICAgdGhpcyBjb252ZXJnZW5jZSBsYXllciBwcm90b2NvbCBmcm9tIHRoZSBEYXRh Z3JhbSBDb252ZXJnZW5jZVxyXG4gICAgICAgIHByb3RvY29sIGRvY3VtZW50ZWQgaW4gUkZDIDcx MjIuXHJcblxyXG4gICAgICBvIEEgZGVsYXktdG9sZXJhbnQgbmV0d29yayBtYW5hZ2VtZW50IHBy b3RvY29sIGZvciBtYW5hZ2VtZW50IG9mIHRoZVxyXG4gICAgICAgIGluZnJhc3RydWN0dXJlIGlu IHRoZSBwcmVzZW5jZSBvZiBsb25nIGRlbGF5cyBhbmQvb3IgaW50ZXJtaXR0ZW50XHJcbiAgICAg ICAgY29ubmVjdGl2aXR5LlxyXG5cclxuICAgICAgbyBBIHJlZ2lzdHJ5IGZvciBEVE4gU2Vydmlj ZSBJZGVudGlmaWVyc1xyXG4gIFxyXG4gICAgVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBjb25zaWRl ciBleHRlbmRpbmcgdGhlIGN1cnJlbnQgbWlsZXN0b25lcyBiYXNlZCBvblxyXG4gICAgbmV3IGlu Zm9ybWF0aW9uIGFuZCBrbm93bGVkZ2UgZ2FpbmVkIHdoaWxlIHdvcmtpbmcgb24gdGhlIGluaXRp YWwgY2hhcnRlcixcclxuICAgIGFzIHdlbGwgYXMgdG8gYWNjb21tb2RhdGUgbmV3IHdvcmsgaXRl bXMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGUgaW5pdGlhbFxyXG4gICAgcGhhc2UuICBGb3IgZXhh bXBsZSwgd2UgZXhwZWN0IHRoYXQgdHJhbnNwb3J0IHByb3RvY29scyBzdWNoIGFzIExUUCBhbmRc clxuICAgIHRoZSBTYXJhdG9nYSBwcm90b2NvbCBhcmUgYW1vbmcgdGhlIGNhbmRpZGF0ZXMgZm9y IHdvcmsgaW4gdGhpcyBwaGFzZS5cclxuICAgIFxyXG5Hb2FscyBhbmQgTWlsZXN0b25lczpcclxu ICBzdGFydCszbW9zIC0gU3VibWl0IFwnQnVuZGxlIFByb3RvY29sIFNwZWNpZmljYXRpb24gKFJG QzUwNTBiaXMpXCcgYXMgYVxyXG4gICAgICAgICAgICAgICB3b3JraW5nIGdyb3VwIGRvY3VtZW50 LiBUbyBiZSBQcm9wb3NlZCBTdGFuZGFyZC5cclxuICBTdGFydCszbW9zIC0gU3VibWl0IFwnU3Ry ZWFtbGluZWQgQnVuZGxlIFNlY3VyaXR5IFByb3RvY29sIChTQlNQKVwnIGFzIGFcclxuICAgICAg ICAgICAgICAgd29ya2luZyBncm91cCBkb2N1bWVudC4gVG8gYmUgUHJvcG9zZWQgU3RhbmRhcmQu XHJcbiAgc3RhcnQrNm1vcyAtIFN1Ym1pdCBcJ0J1bmRsZSBJbiBCdW5kbGUgRW5jYXBzdWxhdGlv biAoQklCRSlcJyBhcyBhIHdvcmtpbmdcclxuICAgICAgICAgICAgICAgZ3JvdXAgZG9jdW1lbnQu IFRvIGJlIFByb3Bvc2VkIFN0YW5kYXJkLlxyXG4gIHN0YXJ0KzEybW9zIC0gU3VibWl0IFwnRGVs YXkgVG9sZXJhbnQgTmV0d29ya2luZyBTZWN1cml0eSBLZXkgTWFuYWdlbWVudFwnIGFzXHJcbiAg ICAgICAgICAgICAgICBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuIFRvIGJlIFByb3Bvc2VkIFN0 YW5kYXJkLlxyXG4gIHN0YXJ0KzE4bW9zIC0gV0cgZGV0ZXJtaW5hdGlvbiBmb3IgbWVyZ2luZyBS RkM1MDUwYmlzLCBTQlNQLCBCSUJFIGFuZC9vclxyXG4gICAgICAgICAgICAgICAgS2V5IE1nbXQg aW50byBhIGNvbWJpbmVkIGRyYWZ0IG9yIGtlZXAgYXMgc2VwYXJhdGUgZHJhZnRzLlxyXG4gIHN0 YXJ0KzE4bW9zIC0gU3VibWl0IFJGQzUwNTBiaXMsIFNCU1AsIEJJQkUgYW5kIEtleSBNZ210IHRv IHRoZSBJRVNHIGVpdGhlclxyXG4gICAgICAgICAgICAgICAgYXMgYSBjb21iaW5lZCBkcmFmdCBv ciBhcyBzZXBhcmF0ZSBkcmFmdHMuXHJcbiAgc3RhcnQrMThtb3MgLSBTdWJtaXQgTmV0d29yayBN YW5hZ2VtZW50LCBSZWdpc3RyeSBhbmQgU2ltcGxlIENvbnZlcmdlbmNlXHJcbiAgICAgICAgICAg ICAgICBMYXllciBhcyB3b3JraW5nIGdyb3VwIGRvY3VtZW50cy5cclxuICBzdGFydCsyMG1vcyAt IFN1cnZleSBhcHByb3ByaWF0ZSBmb3J1bXMgKGUuZy4sIERUTlJHKSBmb3IgZW1lcmdpbmdcclxu ICAgICAgICAgICAgICAgIHRlY2hub2xvZ2llcyAoZS5nLiwgY29udmVyZ2VuY2UgbGF5ZXIgcHJv dG9jb2xzLCBkeW5hbWljXHJcbiAgICAgICAgICAgICAgICByb3V0aW5nIHByb3RvY29scywgbmFt aW5nIGFuZCBhZGRyZXNzaW5nIHNlcnZpY2VzLCBldGMuKVxyXG4gICAgICAgICAgICAgICAgcmVh ZHkgZm9yIHRyYW5zaXRpb24gaW50byBJRVRGIERUTiBXb3JraW5nIEdyb3VwLiBQdWJsaXNoXHJc biAgICAgICAgICAgICAgICBkcmFmdCBvbiBzdXJ2ZXkgcmVzdWx0cyBhcyBpbmRlcGVuZGVudCBz dWJtaXNzaW9uIHJlbGF0ZWRcclxuICAgICAgICAgICAgICAgIHRvIHRoZSBXRy5cclxuICBzdGFy dCsyNG1vcyAtIFN1Ym1pdCBOZXR3b3JrIE1hbmFnZW1lbnQsIFJlZ2lzdHJ5IGFuZCBTaW1wbGUg Q29udmVyZ2VuY2VcclxuICAgICAgICAgICAgICAgIExheWVyIHRvIElFU0dcclxuICBzdGFydCsy NG1vcyAtIFJlY2hhcnRlciB0byBhY2NvbW1vZGF0ZSBuZXcgd29yayBpdGVtcyBvciBjbG9zZSBX b3JraW5nIEdyb3VwXHJcblxyXG5cclxuWzFdIEJQL0xUUCBkZXBsb3ltZW50IG9uIEVQT1hJIHNw YWNlY3JhZnQgWzIwMDhdXHJcbicsICdmaWxlbmFtZTEnOiAnRHJhZnQgQm9GIEFnZW5kYSAoMi41 aHJzKTpcclxuKioqKioqKioqKioqKioqKioqKioqKioqKipcclxuMSkgUHJvYmxlbSBzdGF0ZW1l bnQgKElFVEYgd2cgbW90aXZhdGlvbikgLSAzMG1pblxyXG5cclxuMikgUkZDNTA1MChiaXMpIC0g MzBtaW5cclxuXHJcbjMpIFN0cmVhbWxpbmVkIEJ1bmRsZSBTZWN1cml0eSBQcm90b2NvbCAoU0JT UCkgLSAzMG1pblxyXG5cclxuNCkgQnVuZGxlLWluLUJ1bmRsZSBFbmNhcHN1bGF0aW9uIC0gMTVt aW5cclxuXHJcbjUpIFNlY3VyaXR5IEtleSBNYW5hZ2VtZW50IC0gMTVtaW5cclxuXHJcbjYpIFJl Z2lzdHJ5IGZvciBTZXJ2aWNlIElkZW50aWZpZXJzIC0gMTVtaW5cclxuXHJcbjcpIE5ldHdvcmsg TWFuYWdlbWVudCAtIDE1bWluXHJcblxyXG5cclxuUHJvcG9zZWQgd29ya2luZyBncm91cCBjaGFy dGVyOlxyXG4qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqXHJcbldvcmtpbmcgZ3JvdXAg bmFtZTogXHJcblxyXG4gICAgICBEZWxheS9EaXNydXB0aW9uIFRvbGVyYW50IE5ldHdvcmtpbmcg V29ya2luZyBHcm91cCAoRFROV0cpXHJcblxyXG5DaGFpcihzKTpcclxuXHJcbiAgICAgIFRCRFxy XG5cclxuQXJlYSBhbmQgQXJlYSBEaXJlY3RvcihzKTpcclxuXHJcbiAgICAgIFRyYW5zcG9ydCBB cmVhOiBBRHMgU3BlbmNlciBEYXdraW5zIF9zcGVuY2VyZGF3a2lucy5pZXRmIGF0IGdtYWlsLmNv bV8sXHJcbiAgICAgICAgICAgICAgICAgICAgICAgICAgTWFydGluIFN0aWVtZXJsaW5nIF9tbHMu aWV0ZiBhdCBnbWFpbC5jb21fXHJcblxyXG5SZXNwb25zaWJsZSBBcmVhIERpcmVjdG9yOlxyXG5c clxuICAgICAgVEJEXHJcblxyXG5NYWlsaW5nIGxpc3Q6XHJcblxyXG4gICAgICBHZW5lcmFsIERp c2N1c3Npb246IGR0biBhdCBpZXRmLm9yZ1xyXG4gICAgICBUbyBTdWJzY3JpYmU6IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZHRuXHJcbiAgICAgIEFyY2hpdmU6IGh0dHA6 Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9kdG4vY3VycmVudC9tYWlsbGlzdC5odG1s XHJcblxyXG5EZXNjcmlwdGlvbiBvZiBXb3JraW5nIEdyb3VwOlxyXG5cclxuICAgICAgVGhlIERl bGF5L0Rpc3J1cHRpb24gVG9sZXJhbnQgTmV0d29yayBXb3JraW5nIEdyb3VwIChEVE5XRykgc3Bl Y2lmaWVzXHJcbiAgICAgIG1lY2hhbmlzbXMgZm9yIGRhdGEgY29tbXVuaWNhdGlvbnMgaW4gdGhl IHByZXNlbmNlIG9mIGxvbmcgZGVsYXlzXHJcbiAgICAgIGFuZC9vciBpbnRlcm1pdHRlbnQgY29u bmVjdGl2aXR5LiBUaGUgd29yayBpcyBtb3RpdmF0ZWQgYnkgd2VsbCBrbm93blxyXG4gICAgICBs aW1pdGF0aW9ucyBvZiBzdGFuZGFyZCBJbnRlcm5ldCBwcm90b2NvbHMgdGhhdCBleHBlY3QgZW5k LXRvLWVuZFxyXG4gICAgICBjb25uZWN0aXZpdHkgYmV0d2VlbiBjb21tdW5pY2F0aW5nIGVuZHBv aW50cywgc3ViLXNlY29uZCB0cmFuc21pc3Npb25cclxuICAgICAgZGVsYXlzIGFuZCByb2J1c3Qg cGFja2V0IGRlbGl2ZXJ5IHJhdGlvcy4gSW4gZW52aXJvbm1lbnRzIHdoZXJlIHRoZXNlXHJcbiAg ICAgIGZhdm9yYWJsZSBjb25kaXRpb25zIGRvIG5vdCBhcHBseSwgZXhpc3RpbmcgbWVjaGFuaXNt cyBzdWNoIGFzIHJlbGlhYmxlXHJcbiAgICAgIHRyYW5zcG9ydCBwcm90b2NvbHMgYW5kIHJvdXRp bmcgcHJvdG9jb2xzIGNhbiBmYWlsIHRvIGNvbnZlcmdlIHJlc3VsdGluZ1xyXG4gICAgICBpbiBj b21tdW5pY2F0aW9uIGZhaWx1cmVzLiBGdXJ0aGVybW9yZSwgY2xhc3NpY2FsIGVuZC10by1lbmQg c2VjdXJpdHlcclxuICAgICAgYXNzb2NpYXRpb25zIGNhbm5vdCBiZSBjb29yZGluYXRlZCB3aGVu IGNvbW11bmljYXRpbmcgZW5kcG9pbnRzIGNhbm5vdFxyXG4gICAgICBjb25kdWN0IG11bHRpLW1l c3NhZ2Uga2V5aW5nIGV4Y2hhbmdlcyBpbiBhIHRpbWVseSBmYXNoaW9uLiBUaGVzZVxyXG4gICAg ICBsaW1pdGF0aW9ucyBzdWdnZXN0IHRoZSBuZWVkIGZvciBhIG5ldyBhcHByb2FjaC4gXHJcbiAg ICAgIFxyXG4gICAgICBEZWxheS1Ub2xlcmFudCBOZXR3b3JraW5nIChEVE4pIHByb3RvY29scyBo YXZlIGJlZW4gdGhlIHN1YmplY3Qgb2ZcclxuICAgICAgZXh0ZW5zaXZlIHJlc2VhcmNoIGFuZCBk ZXZlbG9wbWVudCBpbiB0aGUgRGVsYXktVG9sZXJhbnQgTmV0d29ya2luZ1xyXG4gICAgICBSZXNl YXJjaCBHcm91cCBvZiB0aGUgSW50ZXJuZXQgUmVzZWFyY2ggVGFzayBGb3JjZSBzaW5jZSAyMDAy LiAgSW5cclxuICAgICAgcGFydGljdWxhciwgdGhlIERUTiBCdW5kbGUgUHJvdG9jb2wgKFJGQyA1 MDUwKSBhbmQgTGlja2xpZGVyXHJcbiAgICAgIFRyYW5zbWlzc2lvbiBQcm90b2NvbCAoUkZDIDUz MjYpIGhhdmUgYmVlbiBzaG93biB0byBhZGRyZXNzIHRoZVxyXG4gICAgICBpc3N1ZXMgaWRlbnRp ZmllZCBhYm92ZS4gIEluIDIwMDgsIEJQL0xUUCB3YXMgZGVwbG95ZWQgb24gdGhlIEVQT1hJXHJc biAgICAgIHNwYWNlY3JhZnQgaW4gZGVlcCBzcGFjZSBhbmQgd2FzIHVzZWQgdG8gY29uZHVjdCBy ZWxpYWJsZSwgYXV0b21hdGVkXHJcbiAgICAgIGNvbW11bmljYXRpb24gZm9yIGZvdXIgd2Vla3Mg b3ZlciBhIG5ldHdvcmsgb2YgMTAgbm9kZXMgaW4gd2hpY2ggdGhlXHJcbiAgICAgIGJvdHRsZW5l Y2sgcm91dGVyIGluIHRoZSBuZXR3b3JrICh0aGUgc3BhY2VjcmFmdCkgd2FzIHVwIHRvIDEwMCBs aWdodFxyXG4gICAgICBzZWNvbmRzIGZyb20gYWxsIG90aGVyIG5vZGVzIGFuZCBjb25uZWN0aXZp dHkgd2l0aCB0aGUgcm91dGVyIHdhc1xyXG4gICAgICBzdWJqZWN0IHRvIHBlcmlvZHMgb2YgZGlz Y29ubmVjdGlvbiBsYXN0aW5nIHNldmVyYWwgZGF5cy5cclxuXHJcbiAgICAgIFRoZSBzdWNjZXNz IG9mIHRoZSBCUC9MVFAgcHJvdG9jb2wgc3RhY2sgLS0gdGhlIGNvcmUgcHJvdG9jb2xzIG9mIHRo ZVxyXG4gICAgICAiRFROIEFyY2hpdGVjdHVyZSIgb3JpZ2luYWxseSBkZXNjcmliZWQgaW4gUkZD IDQ4MzggLS0gaW4gdGhpc1xyXG4gICAgICBkZW1vbnN0cmF0aW9uIG1heSBiZSBhdHRyaWJ1dGVk IHRvIHRoZSBmb2xsb3dpbmcgZnVuZGFtZW50YWwgZGVzaWduXHJcbiAgICAgIHByaW5jaXBsZXM6 XHJcblxyXG5cdC0gVGhlcmUgaXMgbmV2ZXIgYW55IGV4cGVjdGF0aW9uIG9mIGNvbnRlbXBvcmFu ZW91cyBlbmQtdG8tZW5kXHJcbiAgICAgICBjb25uZWN0aXZpdHkgYmV0d2VlbiBhbnkgdHdvIG5l dHdvcmsgbm9kZXMuICBXaGVyZSBzdWNoIGNvbm5lY3Rpdml0eVxyXG4gICAgICAgaXMgc3VzdGFp bmVkLCB0aGUgcHJvdG9jb2xzIGxldmVyYWdlIGl0IHRvIG9wdGltaXplIHBlcmZvcm1hbmNlLFxy XG4gICAgICAgYnV0IHRoZSBwb3NzaWJpbGl0eSBvZiB0cmFuc2llbnQgYnV0IHN1c3RhaW5lZCBk aXNjb25uZWN0aW9uIGF0XHJcbiAgICAgICBhbnkgdGltZSwgYW55d2hlcmUgaW4gdGhlIG5ldHdv cmssIGlzIGFsd2F5cyByZWNvZ25pemVkLlxyXG5cclxuXHQtIEJlY2F1c2UgZW5kLXRvLWVuZCBj b25uZWN0aXZpdHkgY2FuIG5ldmVyIGJlIGFzc3VtZWQsIGVhY2ggbm9kZVxyXG5cdCAgb24gdGhl IHBhdGggYmV0d2VlbiBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uIG11c3QgYmUgcHJlcGFyZWQgdG9c clxuXHQgIGhhbmRsZSBpbmNvbWluZyAiYnVuZGxlcyIgb2YgZGF0YSB0aGF0IGNhbm5vdCBpbW1l ZGlhdGVseSBiZVxyXG5cdCAgZm9yd2FyZGVkLiAgU3VjaCBidW5kbGVzIG11c3QgZWl0aGVyIGJl IHN0b3JlZCBmb3IgZnV0dXJlIHRyYW5zLVxyXG5cdCAgbWlzc2lvbiBvciBkaXNjYXJkZWQ7IGlu IHRoZSBsYXR0ZXIgY2FzZSwgdGhlIG5ldHdvcmsgbXVzdFxyXG5cdCAgYmUgaW5mb3JtZWQgb2Yg dGhpcyBkYXRhIGxvc3Mgc28gdGhhdCBhbiBhbHRlcm5hdGl2ZSBwYXRoIG1heVxyXG5cdCAgYmUg c2VsZWN0ZWQsIHRvIGF2b2lkIGltcGFpcmluZyB0aGUgdXNhYmlsaXR5IG9mIHRoZSBuZXR3b3Jr LlxyXG5cclxuXHQtIEFnYWluIGJlY2F1c2UgZW5kLXRvLWVuZCBjb25uZWN0aXZpdHkgY2FuIG5l dmVyIGJlIGFzc3VtZWQsXHJcblx0ICBlbmQtdG8tZW5kIGNvbnZlcnNhdGlvbmFsIGRhdGEgZXhj aGFuZ2UgY2FuIG5ldmVyIGJlIGFzc3VtZWQgdG9cclxuXHQgIGNvbXBsZXRlIGluIGEgdGltZWx5 IG1hbm5lcjsgcHJvdG9jb2wgZmVhdHVyZXMgdGhhdCByZWx5IG9uXHJcblx0ICB0aW1lbHkgY29u dmVyc2F0aW9uYWwgZGF0YSBleGNoYW5nZSBtdXN0IGJlIGV4Y2x1ZGVkIGZyb20gdGhlXHJcblx0 ICBhcmNoaXRlY3R1cmUuICBUaGlzIHByaW5jaXBsZSBtYWtlcyB0aGUgRFROIGFyY2hpdGVjdHVy ZVxyXG5cdCAgc3VpdGFibGUgbm90IG9ubHkgZm9yIG5ldHdvcmsgZW52aXJvbm1lbnRzIGNoYXJh Y3Rlcml6ZWQgYnlcclxuXHQgIGxlbmd0aHkgZGlzY29ubmVjdGlvbiBidXQgYWxzbyBmb3IgdGhv c2UgdGhhdCBhcmUgY2hhcmFjdGVyaXplZFxyXG5cdCAgYnkgbG9uZyBzaWduYWwgcHJvcGFnYXRp b24gZGVsYXlzIChzdWNoIGFzIHVuZGVyd2F0ZXIgY29tbXVuaWNhdGlvblxyXG5cdCAgYnkgYWNv dXN0aWMgc2lnbmFscyBvciwgd29yc2UsIGludGVycGxhbmV0YXJ5IGNvbW11bmljYXRpb24pIGV2 ZW5cclxuXHQgIHdoZW4gY29ubmVjdGl2aXR5IGlzIGNvbnRpbnVvdXMuXHJcblxyXG4gICAgICBU aGUgRFROV0cgYmVsaWV2ZXMgdGhhdCBwcm90b2NvbHMgYWRoZXJpbmcgdG8gdGhlc2UgcHJpbmNp cGxlcyBvZmZlclxyXG4gICAgICBvcHBvcnR1bml0aWVzIGZvciBlbmhhbmNpbmcgdGhlIGZ1bmN0 aW9uYWxpdHkgb2YgdGhlIEludGVybmV0IC0gaW5cclxuICAgICAgcGFydGljdWxhciwgZm9yIGZh Y2lsaXRhdGluZyB0aGUgZXh0ZW5zaW9uIG9mIHRoZSBJbnRlcm5ldCBpbnRvXHJcbiAgICAgIGVu dmlyb25tZW50cyBzdWNoIGFzIHRoZSBvY2VhbiBmbG9vciBhbmQgZGVlcCBzcGFjZSBpbiB3aGlj aCB0aGUgY29yZVxyXG4gICAgICBJbnRlcm5ldCBwcm90b2NvbHMgb3BlcmF0ZSBzdWItb3B0aW1h bGx5IGZvciB0aGUgcmVhc29ucyBkaXNjdXNzZWRcclxuICAgICAgZWFybGllci4gIFdlIGJlbGll dmUgdGhhdCB0aGUgZXh0ZW5zaXZlIHJlc2VhcmNoLCBkZW1vbnN0cmF0aW9uLCBhbmRcclxuICAg ICAgcGlsb3Qgb3BlcmF0aW9ucyBwZXJmb3JtZWQgdG8gZGF0ZSB1c2luZyB0aGUgRFROUkcgcHJv dG9jb2xzLCBib3RoXHJcbiAgICAgIGJlZm9yZSBhbmQgYWZ0ZXIgdGhlIEVQT1hJIGV4cGVyaW1l bnQsIHByb3ZpZGVzIGEgZmlybSBiYXNpcyBmb3JcclxuICAgICAgcHVibGlzaGluZyBJbnRlcm5l dCBzdGFuZGFyZHMgZGVyaXZlZCBmcm9tIHRoYXQgd29yay5cclxuXHJcbiAgICAgIFdvcmsgaXRl bXMgcmVsYXRlZCB0byBEZWxheS9EaXNydXB0aW9uIFRvbGVyYW50IE5ldHdvcmtpbmcgaW5jbHVk ZTpcclxuXHJcbiAgICAgIG8gQSBtZWNoYW5pc20gZm9yIHRoZSBleGNoYW5nZSBvZiBwcm90b2Nv bCBkYXRhIHVuaXRzLCB0ZXJtZWRcclxuXHQiYnVuZGxlcyIsIHRoYXQgYXJlIGRlc2lnbmVkIHRv IG9idmlhdGUgY29udmVyc2F0aW9uYWwgY29tbXVuaWNhdGlvbnNcclxuXHRieSBjb250YWluaW5n IHZhbHVlcyBmb3IgYWxsIHBvdGVudGlhbGx5IHJlbGV2YW50IGNvbmZpZ3VyYXRpb25cclxuXHRw YXJhbWV0ZXJzLiAgVGhlc2UgcHJvdG9jb2wgZGF0YSB1bml0cyBhcmUgdHlwaWNhbGx5IGxhcmdl ciB0aGFuXHJcblx0bmV0d29yay1sYXllciBwYWNrZXRzLiAgV2UgZXhwZWN0IHRvIGRlcml2ZSB0 aGlzIGJ1bmRsZSBleGNoYW5nZVxyXG5cdG1lY2hhbmlzbSBmcm9tIHRoZSBEVE4gQnVuZGxlIFBy b3RvY29sIChCUCkgZG9jdW1lbnRlZCBpbiBSRkMgNTA1MC5cclxuICAgICAgICBFeHBlY3RlZCBj aGFuZ2VzIGZyb20gUkZDIDUwNTAgaW5jbHVkZSAoYnV0IGFyZSBub3QgbmVjZXNzYXJpbHlcclxu ICAgICAgICBsaW1pdGVkIHRvKTpcclxuXHJcbiAgICAgICAgICAgLSBhIGNvbXByZXNzZWQgYnVu ZGxlIGhlYWRlciBlbmNvZGluZyAoZGVyaXZlZCBmcm9tIFJGQzYyNjApXHJcbiAgICAgICAgICAg LSBhbiBpbW11dGFibGUgcHJpbWFyeSBibG9jayBzdHJ1Y3R1cmVcclxuICAgICAgICAgICAtIHNp bXBsaWZpZWQgRUlEIHJlcHJlc2VudGF0aW9ucyAobm8gZGljdGlvbmFyeSlcclxuICAgICAgICAg ICAtIGFkZCBibG9jayBJRCB0byBleHRlbnNpb24gYmxvY2tzIChlLmcuIHNlY3VyaXR5IGJsb2Nr cylcclxuICAgICAgICAgICAtIG1vdmUgY3VzdG9kaWFuIHRvIGV4dGVuc2lvbiBibG9ja1xyXG4g ICAgICAgICAgIC0gYWRkIHNpbXBsZSBoZWFkZXIgYW5kIHBheWxvYWQgaW50ZWdyaXR5IGNoZWNr c1xyXG4gICAgICAgICAgIC0gYWRkIHNpbXBsZSBjb250YWN0IGdyYXBoIHJvdXRpbmcgc3BlY2lm aWNhdGlvblxyXG4gICAgICAgICAgIC0gYWRkIHNpbXBsZSBuZWlnaGJvciBkaXNjb3Zlcnkgc3Bl Y2lmaWNhdGlvbiBcclxuXHJcbiAgICAgIG8gQSBzZWN1cml0eSBwcm90b2NvbCBmb3IgZW5zdXJp bmcgdGhhdCB0aGUgbmV0d29yayBpbiB3aGljaCBidW5kbGVzXHJcblx0YXJlIGV4Y2hhbmdlZCBp cyBzZWN1cmVkIGFnYWluc3QgdW5hdXRob3JpemVkIGFjY2VzcyBhbmQgZGVuaWFsIG9mXHJcblx0 c2VydmljZSBhdHRhY2tzLCBhbmQgdG8gZW5zdXJlIGRhdGEgaW50ZWdyaXR5IGFuZCBjb25maWRl bnRpYWxpdHlcclxuXHRpbiB0aGF0IG5ldHdvcmsgd2hlcmUgbmVjZXNzYXJ5LiAgV2UgZXhwZWN0 IHRvIGRlcml2ZSB0aGlzIHNlY3VyaXR5XHJcblx0cHJvdG9jb2wgZnJvbSBhICJzdHJlYW1saW5l ZCIgYWRhcHRhdGlvbiBvZiB0aGUgRFROIEJ1bmRsZSBTZWN1cml0eVxyXG5cdFByb3RvY29sIGRv Y3VtZW50ZWQgaW4gUkZDIDYyNTcuXHJcblxyXG4gICAgICBvIEFuIGVuY2Fwc3VsYXRpb24gcHJv dG9jb2wgZm9yICJ0dW5uZWxpbmciIEJQIHRyYWZmaWMgd2l0aGluIGJ1bmRsZXNcclxuXHR0aGF0 IGFyZSBzZWN1cmVkIGFuZC9vciByb3V0ZWQgaW4gZGlmZmVyZW50IHdheSBmcm9tIHRoZSBlbmNh cHN1bGF0ZWRcclxuXHRidW5kbGVzLlxyXG5cclxuICAgICAgbyBBIGRlbGF5LXRvbGVyYW50IHNl Y3VyaXR5IGtleSBtYW5hZ2VtZW50IHNjaGVtZSBmb3IgZW5zdXJpbmcgdGhhdFxyXG5cdHB1Ymxp YyBrZXlzIGFyZSBjZXJ0aWZpZWQgYnkgYSBnbG9iYWxseSB0cnVzdGVkIGF1dGhvcml0eSB0byBw cm90ZWN0XHJcblx0dGhlIGludGVncml0eSBvZiB0aGUgaW5mcmFzdHJ1Y3R1cmUuXHJcblxyXG4g ICAgICBvIEEgc2ltcGxlIGRhdGFncmFtIGNvbnZlcmdlbmNlIGxheWVyIHByb3RvY29sIGZvciBh ZGFwdGF0aW9uIG9mIHRoZVxyXG4gICAgICAgIGJ1bmRsZSBwcm90b2NvbCB0byB1bmRlcmx5aW5n IGludGVybmV0d29ya3MuIFdlIGV4cGVjdCB0byBkZXJpdmVcclxuICAgICAgICB0aGlzIGNvbnZl cmdlbmNlIGxheWVyIHByb3RvY29sIGZyb20gdGhlIERhdGFncmFtIENvbnZlcmdlbmNlXHJcbiAg ICAgICAgcHJvdG9jb2wgZG9jdW1lbnRlZCBpbiBSRkM3MTIyLlxyXG5cclxuICAgICAgbyBBIGRl bGF5LXRvbGVyYW50IG5ldHdvcmsgbWFuYWdlbWVudCBwcm90b2NvbCBmb3IgbWFuYWdlbWVudCBv ZiB0aGVcclxuICAgICAgICBpbmZyYXN0cnVjdHVyZSBpbiB0aGUgcHJlc2VuY2Ugb2YgbG9uZyBk ZWxheXMgYW5kL29yIGludGVybWl0dGVudFxyXG4gICAgICAgIGNvbm5lY3Rpdml0eS5cclxuXHJc biAgICAgIG8gQSByZWdpc3RyeSBmb3IgRFROIFNlcnZpY2UgSWRlbnRpZmllcnNcclxuICBcclxu ICAgIFRoZSB3b3JraW5nIGdyb3VwIHdpbGwgY29uc2lkZXIgZXh0ZW5kaW5nIHRoZSBjdXJyZW50 IG1pbGVzdG9uZXMgYmFzZWQgb25cclxuICAgIG5ldyBpbmZvcm1hdGlvbiBhbmQga25vd2xlZGdl IGdhaW5lZCB3aGlsZSB3b3JraW5nIG9uIHRoZSBpbml0aWFsIGNoYXJ0ZXIsXHJcbiAgICBhcyB3 ZWxsIGFzIHRvIGFjY29tbW9kYXRlIG5ldyB3b3JrIGl0ZW1zIGJleW9uZCB0aGUgc2NvcGUgb2Yg dGhlIGluaXRpYWxcclxuICAgIHBoYXNlLiAgRm9yIGV4YW1wbGUsIHdlIGV4cGVjdCB0aGF0IHRy YW5zcG9ydCBwcm90b2NvbHMgdW5pcXVlbHkgc3VpdGVkXHJcbiAgICB0byB0aGUgdmFyaW91cyBj b21tdW5pY2F0aW9uIGVudmlyb25tZW50cyB0aGF0IG1heSBuZWVkIHRvIGJlIHRyYXZlcnNlZFxy XG4gICAgYnkgYSBzaW5nbGUgRFROIGVuZC10by1lbmQgcGF0aCAob3BlcmF0aW5nIHVuZGVyIEJQ LCBhdCB3aGF0IGlzIHRlcm1lZFxyXG4gICAgdGhlIERUTiAiY29udmVyZ2VuY2UgbGF5ZXIiKSB3 aWxsIG5lZWQgdG8gYmUgc3RhbmRhcmRpemVkIGluIGEgc2Vjb25kXHJcbiAgICBwaGFzZSBvZiB0 aGUgd29ya2luZyBncm91cFwncyBjaGFydGVyOyBMVFAgYW5kIHRoZSBTYXJhdG9nYSBwcm90b2Nv bCBhcmVcclxuICAgIGFtb25nIHRoZSBjYW5kaWRhdGVzIGZvciB3b3JrIGluIHRoaXMgcGhhc2Uu ICBUaGVzZSBhZGp1c3RtZW50cyB3aWxsIGJlXHJcbiAgICBhY2NvbW1vZGF0ZWQgaW4gYSB3b3Jr aW5nIGdyb3VwIHJlY2hhcnRlciwgYXNzdW1pbmcgdGhlIGluaXRpYWxcclxuICAgIGNoYXJ0ZXJl ZCBhY3Rpdml0aWVzIG1lZXQgdGhlaXIgZGVsaXZlcnkgbWlsZXN0b25lcy4gUG9zc2libGUgbmV3 IHdvcmtcclxuICAgIGl0ZW1zIG11c3QgdGhlbiBzdGlsbCBmaXQgaW50byB0aGUgKHJlY2hhcnRl cmVkKSBEVE5XRyBjaGFydGVyIHNjb3BlLlxyXG4gICAgXHJcbkdvYWxzIGFuZCBNaWxlc3RvbmVz OlxyXG4gIHN0YXJ0KzNtb3MgLSBTdWJtaXQgXCdCdW5kbGUgUHJvdG9jb2wgU3BlY2lmaWNhdGlv biAoUkZDNTA1MGJpcylcJyBhcyBhXHJcbiAgICAgICAgICAgICAgICAgICAgICB3b3JraW5nIGdy b3VwIGRvY3VtZW50LiBUbyBiZSBQcm9wb3NlZCBTdGFuZGFyZC5cclxuICBTdGFydCszbW9zIC0g U3VibWl0IFwnU3RyZWFtbGluZWQgQnVuZGxlIFNlY3VyaXR5IFByb3RvY29sIChTQlNQKVwnIGFz IGFcclxuICAgICAgICAgICAgICAgICAgICAgICB3b3JraW5nIGdyb3VwIGRvY3VtZW50LiBUbyBi ZSBQcm9wb3NlZCBTdGFuZGFyZC5cclxuICBzdGFydCs2bW9zIC0gU3VibWl0IFwnQnVuZGxlIElu IEJ1bmRsZSBFbmNhcHN1bGF0aW9uIChCSUJFKVwnIGFzIGEgd29ya2luZ1xyXG4gICAgICAgICAg ICAgICAgICAgICAgZ3JvdXAgZG9jdW1lbnQuIFRvIGJlIFByb3Bvc2VkIFN0YW5kYXJkLlxyXG4g IHN0YXJ0Kzltb3MgLSBTdWJtaXQgXCdEZWxheSBUb2xlcmFudCBOZXR3b3JraW5nIFNlY3VyaXR5 IEtleSBNYW5hZ2VtZW50XCcgYXNcclxuICAgICAgICAgICAgICAgICAgICAgIGEgd29ya2luZyBn cm91cCBkb2N1bWVudC4gVG8gYmUgUHJvcG9zZWQgU3RhbmRhcmQuXHJcbiAgc3RhcnQrOW1vcyAt IFdHIGRldGVybWluYXRpb24gZm9yIG1lcmdpbmcgUkZDNTA1MGJpcywgU0JTUCwgQklCRSBhbmQv b3JcclxuICAgICAgICAgICAgICAgS2V5IE1nbXQgaW50byBhIGNvbWJpbmVkIGRyYWZ0IG9yIGtl ZXAgYXMgc2VwYXJhdGUgZHJhZnRzLlxyXG4gIHN0YXJ0KzEybW9zIC0gU3VibWl0IFJGQzUwNTBi aXMsIFNCU1AsIEJJQkUgYW5kIEtleSBNZ210IHRvIHRoZSBJRVNHIGVpdGhlclxyXG4gICAgICAg ICAgICAgICAgYXMgYSBjb21iaW5lZCBkcmFmdCBvciBhcyBzZXBhcmF0ZSBkcmFmdHMuXHJcbiAg c3RhcnQrMTJtb3MgLSBTdWJtaXQgTmV0d29yayBNYW5hZ2VtZW50LCBSZWdpc3RyeSBhbmQgU2lt cGxlIENvbnZlcmdlbmNlXHJcbiAgICAgICAgICAgICAgICBMYXllciBhcyB3b3JraW5nIGdyb3Vw IGRvY3VtZW50cy5cclxuICBzdGFydCsxNW1vcyAtIFN1cnZleSBhcHByb3ByaWF0ZSBmb3J1bXMg KGUuZy4sIERUTlJHKSBmb3IgZW1lcmdpbmdcclxuICAgICAgICAgICAgICAgIHRlY2hub2xvZ2ll cyAoZS5nLiwgY29udmVyZ2VuY2UgbGF5ZXIgcHJvdG9jb2xzLCBkeW5hbWljXHJcbiAgICAgICAg ICAgICAgICByb3V0aW5nIHByb3RvY29scywgbmFtaW5nIGFuZCBhZGRyZXNzaW5nIHNlcnZpY2Vz LCBldGMuKVxyXG4gICAgICAgICAgICAgICAgcmVhZHkgZm9yIHRyYW5zaXRpb24gaW50byBJRVRG IERUTiBXb3JraW5nIEdyb3VwLiBQdWJsaXNoXHJcbiAgICAgICAgICAgICAgICBkcmFmdCBvbiBz dXJ2ZXkgcmVzdWx0cyBhcyBpbmRlcGVuZGVudCBzdWJtaXNzaW9uIHJlbGF0ZWRcclxuICAgICAg ICAgICAgICAgIHRvIHRoZSBXRy5cclxuICBzdGFydCsxOG1vcyAtIFN1Ym1pdCBOZXR3b3JrIE1h bmFnZW1lbnQsIFJlZ2lzdHJ5IGFuZCBTaW1wbGUgQ29udmVyZ2VuY2VcclxuICAgICAgICAgICAg ICAgIExheWVyIHRvIElFU0dcclxuICBzdGFydCsxOG1vcyAtIFJlY2hhcnRlciB0byBhY2NvbW1v ZGF0ZSBuZXcgd29yayBpdGVtcyBvciBjbG9zZSBXb3JraW5nIEdyb3VwXHJcbicsICd1cmwxJzog JycsICdzdWJtaXQnOiAnR2VuZXJhdGUgZGlmZicsICd1cmwyJzogJycsICctLW5ld2NvbG91cic6 ICdncmVlbid9IC0tPg== --_002_2134F8430051B64F815C691A62D983181B2BF96CXCHBLV504nwnosb_-- From nobody Thu Jun 5 21:24:40 2014 Return-Path: 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 2C2601A0140; Thu, 5 Jun 2014 21:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 F9LLbg8ugGQi; Thu, 5 Jun 2014 21:24:35 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.153]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DB3E1A0016; Thu, 5 Jun 2014 21:24:33 -0700 (PDT) Received: from [85.158.136.51:5463] by server-17.bemta-5.messagelabs.com id AB/62-09046-A7241935; Fri, 06 Jun 2014 04:24:26 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-5.tower-49.messagelabs.com!1402028665!23463229!1 X-Originating-IP: [131.227.200.39] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19806 invoked from network); 6 Jun 2014 04:24:25 -0000 Received: from exht012p.surrey.ac.uk (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-5.tower-49.messagelabs.com with AES128-SHA encrypted SMTP; 6 Jun 2014 04:24:25 -0000 Received: from EXHY022V.surrey.ac.uk (131.227.201.104) by EXHT012P.surrey.ac.uk (131.227.200.39) with Microsoft SMTP Server (TLS) id 8.3.348.2; Fri, 6 Jun 2014 05:24:25 +0100 Received: from emea01-db3-obe.outbound.protection.outlook.com (131.227.201.241) by EXHY022v.surrey.ac.uk (131.227.201.104) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 6 Jun 2014 05:24:24 +0100 Received: from AMSPR06MB439.eurprd06.prod.outlook.com (10.242.23.19) by AMSPR06MB437.eurprd06.prod.outlook.com (10.242.23.11) with Microsoft SMTP Server (TLS) id 15.0.954.9; Fri, 6 Jun 2014 04:24:23 +0000 Received: from AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) by AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) with mapi id 15.00.0954.000; Fri, 6 Jun 2014 04:24:23 +0000 From: To: , , Thread-Topic: [dtn] DTN BoF Proposal for IETF90 Thread-Index: Ac+AQa9Fez/CplZaSwyaLFpzb8tj0wAiVZ0A///Hp/D//5OnYIABipvO Date: Fri, 6 Jun 2014 04:24:23 +0000 Message-ID: <1402028661896.54716@surrey.ac.uk> References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com>, <1401967219583.26821@surrey.ac.uk>, <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-AU, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [122.200.59.30] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 023495660C x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(40154002)(377454003)(199002)(189002)(13464003)(51704005)(93886002)(64706001)(15975445006)(66066001)(15202345003)(15198665003)(87936001)(81542001)(46102001)(2656002)(80022001)(79102001)(76482001)(20776003)(101416001)(561944003)(83072002)(85852003)(99396002)(92726001)(2201001)(92566001)(15395725005)(31966008)(54356999)(4396001)(77982001)(19580405001)(74662001)(74482001)(83322001)(74502001)(86362001)(50986999)(21056001)(36756003)(77096999)(76176999)(19580395003)(536464002); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR06MB437; H:AMSPR06MB439.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: surrey.ac.uk does not designate permitted sender hosts) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: AMSPR06MB437.eurprd06.prod.outlook.com X-CrossPremisesHeadersFiltered: EXHY022v.surrey.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/ijskD3-cdtsJhQ7CcNtYC2nbsnE Cc: iesg@ietf.org, dtn@ietf.org Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 04:24:39 -0000 Fred,=0A= =0A= CCSDS exerts lockin on space agencies. It's very resistant to market forces= (like, you know, TCP/IP), and utterly resistant to multiple competing solu= tions - which is why the bundle protocol was developed and pushed. It's rat= her analogous to the telcos developing ATM in the 1990s to meet their needs= , and then doing that development in the ATM Forum. The IETF sat happily by= , shaking its head for the most part.=0A= =0A= The question is, why should the IETF spend further time and effort for CCSD= S on the bundle protocol to preserve the CCSDS bulwark against IP, where th= ere are other things its experts could be doing that benefit actual IETF pr= otocols? The bundle protocol is politically favoured by CCSDS, but is not t= echnically good.=0A= =0A= (Also, it's unclear, from this discussion, that when you say 'a standard' w= hether you mean 'a published RFC' or 'a standards-track RFC' or 'a standard= '. Those are progressively higher bars.)=0A= =0A= Lloyd Wood=0A= http://about.me/lloydwood=0A= ________________________________________=0A= From: Templin, Fred L =0A= Sent: Friday, 6 June 2014 4:02 AM=0A= To: Wood L Dr (Electronic Eng); spencerdawkins.ietf@gmail.com; mls.ietf@gm= ail.com=0A= Cc: iesg@ietf.org; dtn@ietf.org=0A= Subject: RE: [dtn] DTN BoF Proposal for IETF90=0A= =0A= Hi Lloyd,=0A= =0A= Wading through your points, you seem to be concerned that standardizing=0A= the Bundle Protocol in the IETF will somehow block other approaches from=0A= going forward in the future, but that would not be consistent with my=0A= understanding of the way the IETF operates. There are many examples where= =0A= multiple solutions for roughly the same problem space have gone forward=0A= to standards track and have all found widespread application - sometimes=0A= based on the best-fit solution for the particular problem and sometimes=0A= based on market forces.=0A= =0A= The purpose of having a standard is so that vendors can independently=0A= create interoperable implementations, and the IETF is the correct forum=0A= for developing internetworking standards.=0A= =0A= Thanks - Fred=0A= fred.l.templin@boeing.com=0A= =0A= > -----Original Message-----=0A= > From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of l.wood@surrey.ac.uk= =0A= > Sent: Thursday, June 05, 2014 4:20 AM=0A= > To: spencerdawkins.ietf@gmail.com; mls.ietf@gmail.com=0A= > Cc: iesg@ietf.org; dtn@ietf.org=0A= > Subject: Re: [dtn] DTN BoF Proposal for IETF90=0A= >=0A= > As previously expressed on DTNRG, I have a number of concerns about=0A= > this proposed BOF to create an IETF DTN WG to do work on the=0A= > RFC5050 bundle protocol, produced in the IRTF DTNRG, and create=0A= > an RFC5050bis. I'll go through those concerns one by one:=0A= >=0A= >=0A= > 1. I don't see how going standards track can be justified, because:=0A= >=0A= > a. CCSDS is already working on the bundle protocol as one of their=0A= > blue book standards, based on RFC5050, and any RFC5050bis=0A= > would presumably also be adopted and then modified to make=0A= > a CCSDS standard.=0A= > It's rather like CCSDS restandardizing TCP/IP as SCPS, back=0A= > in the 1990s. That SCPS standardization wasn't used much=0A= > either, not least because CCSDS 'improved' on TCP/IP=0A= > and went incompatible quite quickly. The same will happen=0A= > with the CCSDS bundle protocol, and in adopting RFC5050=0A= > CCSDS has reserved the right to make changes - things like=0A= > Delay Tolerant Payload Conditioning (DTPC) are but the start.=0A= > There's an example of bundle protocol work not requiring=0A= > the IETF. Work on altering and extending the bundle protocol=0A= > is already ongoing in CCSDS.=0A= > Setting up an IETF workgroup to work in parallel would mean=0A= > that a CCSDS liaison would be required, to pay attention=0A= > to their concerns as they try and convince their member space=0A= > agencies to use the bundle protocol, and to prevent their spec=0A= > from diverging (further) from the IETF spec. Really, the work=0A= > is simply more easily done in CCSDS, given that CCSDS is=0A= > pretty much the only customer for bundle protocol, because=0A= > NASA has mandated bundle protocol use from on high.=0A= > NASA leads CCSDS, NASA Jet Propulsion Lab leads CCSDS design=0A= > for NASA's Space Communications and Navigation people.=0A= > JPL is really the primary customer for and user of bundle=0A= > protocol, responsible for promoting its use by other space=0A= > agencies - never an easy task, even with good technologies.=0A= >=0A= > b. The IETF produces Internet standards. The bundle protocol=0A= > has little bearing on or interaction with Internet standards;=0A= > it's arguably a way to interoperate with the Internet while=0A= > protecting CCSDS from incursion of the Internet, by layering=0A= > over both Internet and CCSDS. Each to their own domains.=0A= > Using TCP as the most common bundle convergence layer (described=0A= > in a draft now seven years old) does not make the bundle protocol= =0A= > an internet standard. If it did, then CCSDS's Space Link=0A= > Extension (basically a TCP tunnel carrying CCSDS frames, with=0A= > much added complexity) would also be a candidate for an=0A= > IETF internet standard.=0A= > But, again, that work is best done in CCSDS, where there=0A= > is interest in having it done and there are users. (Some=0A= > of those users may even be willing users.)=0A= >=0A= > c. The bundle protocol is not mature. Deficiencies have been=0A= > identified, drafts have been written in DTNRG over the years,=0A= > there was little interest, the drafts expired, the bundle=0A= > protocol was never improved. And that's just from demonstrations;= =0A= > there has not been extended operational use to my knowledge.=0A= > Attempting to fix the bundle protocol AND push it through as=0A= > standards track at the same time seems unwarranted.=0A= > It may be politically motivated, but it is=0A= > not technically or procedurally justifiable.=0A= > There isn't the userbase or demand needed for the bundle=0A= > protocol to go standards track, and if the IETF did go=0A= > standards track, CCSDS would 'optimize' that standard into=0A= > its own standard, just as was done with SCPS, meaning that=0A= > the IETF would spend a lot of time working on something with=0A= > no benefit to the IETF community or userbase. Extending=0A= > the Internet protocols to the DTN network problem space=0A= > adds value to the internet protocols. A separate protocol=0A= > does not.=0A= > Who would benefit, outside the CCSDS community? And CCSDS=0A= > is their own standards org - an ISO subgroup - to do work=0A= > for that CCSDS community.=0A= >=0A= >=0A= > 2. I don't see why this needs to be done in an IETF WG, because:=0A= >=0A= > a. going standards track isn't justifiable - see 1.=0A= >=0A= > b. There's already the IRTF DTNRG, which could clean up its=0A= > own work, but ,after many years and some failed drafts,=0A= > has not.=0A= > Declaring success and saying it is now time to create a=0A= > WG based on DTNRG's achievements is not convincing,=0A= > because those achievements are not impressive.=0A= > (Disclaimer of interest: I authored 'A bundle of problems'=0A= > and have spent considerable years trying to explain and=0A= > address problems with the bundle protocol, with little=0A= > success, after getting it tested in space before NASA's=0A= > EXPOXI/Deep Impact tests took place.=0A= > Fred Templin's problem statement drafts for this putative=0A= > IETF BOF calls on that work.)=0A= > RFC5050bis would make more sense as a DTNRG=0A= > effort, though it would be time for a changing of the=0A= > guard and chairs in DTNRG to infuse some new blood and=0A= > technical judgement - or we're in for another five years=0A= > of what-does-the-end-to-end-principle-really-mean and=0A= > what-about-clocks and rehashing the same old arguments.=0A= > Really, DTNRG needs to get its act together, both=0A= > organizationally and technically.=0A= >=0A= > c. There's already CCSDS, which has adopted the DTNRG output,=0A= > after pushing for the formation of an Interplanetary=0A= > Internet RG in the first place.=0A= >=0A= > So either CCSDS or DTNRG can do RFC5050 revision work. If=0A= > it's to be an RFC, experimental or informational, a revitalised=0A= > rechartered DTNRG can do it.=0A= > It doesn't need to be an IETF workgroup. It certainly=0A= > shouldn't go standards track.=0A= >=0A= >=0A= > 3. The philosophically shaky basis for the bundle protocol:=0A= >=0A= > a. Delay-tolerant networking is not disruption-tolerant=0A= > networking. Space delays of light-minutes with scheduled=0A= > contacts are not the same as intermittent ad-hoc=0A= > manet-style communications. Different requirements,=0A= > different buffering and storage, different conditions,=0A= > different handling of fragmentation, etc.=0A= >=0A= > b. The bundle protocol is not DTN. DTN is the scenario,=0A= > in which other approaches (the related CFDP, Haggle,=0A= > the MANET and vehicular DTNs efforts that DTN subsumed=0A= > and rebranded, etc.) exist.=0A= > The bundle protocol is intended to be used in a DTN=0A= > scenario. Branding the bundle protocol as DTN has=0A= > put back non-bundle DTN research a number of years.=0A= > Branding a group only working on the bundle protocol=0A= > as 'DTN' is misleading at best.=0A= >=0A= > c. Extending the bundle protocol from the original=0A= > Interplanetary Internet problem (which had its own=0A= > IRTF RG which led into a set bundle agenda for=0A= > DTNRG) to cover everything else as well simply hasn't=0A= > worked very well, because the scenarios and use cases=0A= > are different. We design for use cases. To be too=0A= > generalised is to engineer for nothing.=0A= >=0A= > d. Ignoring the ramifications of the end-to-end principle,=0A= > which are often more subtle than people seem to think=0A= > they are. The bundle protocol's custody transfer=0A= > procedure is a good example of this failing.=0A= >=0A= > e. The bundle protocol is intended for use in the most=0A= > difficult noisy disrupted networking conditions we know,=0A= > and it can't even sanity check its own headers against=0A= > errors. (But hey, it now has a security protocol that=0A= > _almost_ does that! But which is too complicated, and=0A= > would need to be redone.)=0A= > It's intended for the harshest environments we know,=0A= > but needs reliable synchronized clocks running at=0A= > steady temperatures!=0A= > It's intended for embedded systems, but the design=0A= > is huge and complex! (CFDP has the same problem;=0A= > there's a reason implementers went for a "CFDP lite,"=0A= > and Saratoga exists just because CFDP wasn't performing.=0A= > Would RFC5050bis be "bundling lite"?)=0A= > There are many 'that makes no sense' moments - normally=0A= > more immediately visible to outsiders not steeped in=0A= > the dogma, politics, and history of DTNRG and CCSDS.=0A= >=0A= > f. The assumption that a full security suite is desirable=0A= > and necessary at all times. This has derailed DTNRG,=0A= > as emphasis was placed on security work above all=0A= > else, rather than working to the scenario. To be fair=0A= > to the security-focused chairs, the charter that=0A= > established DTNRG from the interplanetary internet=0A= > research group called out security heavily, and they=0A= > ran with that mandate. But the focus has decreased=0A= > work on non-security matters, which is to say,=0A= > everything else.=0A= >=0A= > RFC5050bis might address the latter three problems, but=0A= > the first three are intrinsically unsolvable; any solution=0A= > will be unsatisfactory. Perhaps not as unsatisfactory as=0A= > RFC5050, but unsatisfactory nonetheless.=0A= >=0A= > The real philosophical problem here is the political dogma=0A= > that, whatever the problem, the bundle protocol is The=0A= > One True Solution.=0A= >=0A= >=0A= > 4. The draft BOF charter is bundle-centric. Which is to say,=0A= > that it's not awfully relevant to internet standards.=0A= > Disclaimer of interest: we've worked on Saratoga and=0A= > HTTP-DTN, which have current internet-drafts, and are=0A= > squarely in the DTN problem space.=0A= > Whenever someone talks about multiple convergence=0A= > layers for the bundle protocol - there's more than for BEEP,=0A= > which just has TCP, but there aren't many - Saratoga may=0A= > be mentioned. But we've found that carrying bundles doesn't=0A= > benefit Saratoga - tested it in space, didn't see the=0A= > advantages. Saratoga does leverage a few Internet things -=0A= > UDP, UDP-Lite, multicast. It does a few scaling things that=0A= > nothing else I've seen does (described in our 2011 TSVAREA=0A= > presentation to IETF 88 in November.) And it's based on=0A= > a decade of operational use in the problem domain.=0A= > HTTP-DTN leverages the HTTP suite and MIME, and comes up=0A= > whenever wouldn't-it-be-nice-to-try-HTTP-for-DTN discussion=0A= > takes place.=0A= > (I suspect that all of Stephen Farrell's N4C work could=0A= > have been done over hop-by-hop HTTP a la HTTP-DTN, and=0A= > would have worked just as well if not better. After all,=0A= > it used TCP.)=0A= > These and other efforts exist in a gap between DTNRG, which=0A= > is aware of the problem space, but thinks the bundle=0A= > protocol is the solution despite mounting evidence to the=0A= > contrary, and TSVWG, where the few actual transport=0A= > experts live, without clout, or funding, or spare time.=0A= > Those efforts are interesting enough to have implementations=0A= > kicking around too.=0A= > And yet, the focus of this putative workgroup and BOF is=0A= > solely on bundling, and not on evaluating these or other=0A= > things that might exist in the problem space. There=0A= > must be other things out there that would be of interest=0A= > to such a DTN workgroup. What is proposed is not a DTN=0A= > workgroup. The charter is basically a bundle workgroup.=0A= > Can an interest in bundling and solely bundling (outside=0A= > CCSDS, which is driving the push to use the bundle protocol)=0A= > be justified for an IETF workgroup? I really don't think so.=0A= >=0A= > 5. The bundle protocol work was, I gather, well-funded=0A= > by a number of parties.=0A= > I can't see a follow-on effort being anywhere near=0A= > as well funded.=0A= >=0A= > a. I have no idea how much money NASA and CCSDS have put=0A= > into this - first CFDP, then bundling, which now has=0A= > to provide a CFDP-like API to the users who were told=0A= > that CFDP was the future, and Licklider (LTP).=0A= > Dragging CCSDS into the modern age of networking=0A= > seems unlikely to ever happen, thanks to CCSDS having=0A= > little in the way of sane layering or separation of=0A= > functionality.=0A= > I do have the luxury of not needing to work on CCSDS.=0A= > But if you want to work on CCSDS protocols, CCSDS is=0A= > the place to go. The IETF is not that place.=0A= >=0A= > b. DARPA poured money into DTN work - at least twenty=0A= > million dollars, from the press releases I've seen.=0A= > I have no idea what DARPA got out of it in the=0A= > years they were involved; haven't seen the reports.=0A= >=0A= > My point is, all that money and effort and manpower and=0A= > over a decade of work and prior experience with CFDP and two=0A= > IRTF RGs, we have... RFC5050.=0A= > There is nowhere near as much money or effort or manpower=0A= > for doing a replacement.=0A= > Ergo, it might be suggested that the replacement is unlikely=0A= > to be as good as RFC5050, or as good as CFDP; at best,=0A= > the usual suspects will have less time and fewer resources=0A= > to repeat their original mistakes.=0A= >=0A= > And transport expertise from TSVWG would be needed.=0A= > TSVWG is unfashionable, low-visibility, and has even=0A= > previously had trouble finding ADs with relevant expertise.=0A= > And TSVWG has a full plate with work on its existing=0A= > protocols; there is not a lot of expertise, and what there=0A= > is is spread thin.=0A= > So an RFC505bis effort is unlikely to get the expert=0A= > technical input that it sorely needs, even if an IETF=0A= > workgroup is set up. (CCSDS doesn't have that transport=0A= > focus.)=0A= >=0A= > If, on the other hand, you believe good protocol design=0A= > can be done more cheaply and leverage actual Internet=0A= > standards to get Internet functionality working in=0A= > difficult networks where the full TCP/IP suite has=0A= > trouble, your options include Saratoga and HTTP-DTN!=0A= > http://saratoga.sourceforge.net/=0A= > http://sat-net.com/L.Wood/dtn/http-dtn.html=0A= > They'll truly extend the Internet to difficult=0A= > environments. The bundle protocol won't.=0A= >=0A= > So, to conclude, there is no justification for going=0A= > standards track. There is little justification for an=0A= > IETF workgroup. There is more logic in rechartering and=0A= > repurposing the IRTF DTNRG, but the work may as well=0A= > be left to CCSDS entirely.=0A= >=0A= > RFC5050bis: half-assed, half-baked, reheated.=0A= > But hey, ask me what I _really_ think.=0A= >=0A= > Lloyd Wood=0A= > http://sat-net.com/L.Wood/dtn/=0A= >=0A= > _______________________________________________=0A= > dtn mailing list=0A= > dtn@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/dtn=0A= From nobody Fri Jun 6 08:45:42 2014 Return-Path: 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 4D1F81A022F; Fri, 6 Jun 2014 08:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, 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 4gAFsHrO12PL; Fri, 6 Jun 2014 08:45:31 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29A141A01F2; Fri, 6 Jun 2014 08:45:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s56FjOD1018087; Fri, 6 Jun 2014 08:45:24 -0700 Received: from XCH-PHX-210.sw.nos.boeing.com (xch-phx-210.sw.nos.boeing.com [130.247.25.65]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s56FjECr017536 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 6 Jun 2014 08:45:15 -0700 Received: from XCH-BLV-105.nw.nos.boeing.com (2002:82f7:1979::82f7:1979) by XCH-PHX-210.sw.nos.boeing.com (2002:82f7:1941::82f7:1941) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 6 Jun 2014 08:45:14 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.105]) by XCH-BLV-105.nw.nos.boeing.com ([169.254.5.96]) with mapi id 14.03.0181.006; Fri, 6 Jun 2014 08:45:13 -0700 From: "Templin, Fred L" To: "l.wood@surrey.ac.uk" , "spencerdawkins.ietf@gmail.com" , "mls.ietf@gmail.com" Thread-Topic: [dtn] DTN BoF Proposal for IETF90 Thread-Index: Ac+AQa9Fez/CplZaSwyaLFpzb8tj0wAiVZ0A///Hp/D//5OnYIABipvO//9CD7A= Date: Fri, 6 Jun 2014 15:45:12 +0000 Message-ID: <2134F8430051B64F815C691A62D983181B2C0238@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com>, <1401967219583.26821@surrey.ac.uk>, <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk> In-Reply-To: <1402028661896.54716@surrey.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.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/5RzNFwOVqgGbXSV6bBSA3V-_atQ Cc: "iesg@ietf.org" , "dtn@ietf.org" Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 15:45:35 -0000 Hi Lloyd, Independent submissions can be submitted directly to the ISE editor as either Experimental or Informational category without AD sponsorship. These documents are reviewed by the IESG for conflicts with existing working groups, but are not necessarily reviewed for technical content. Individual submissions can be submitted via AD sponsorship for Experimental, Informational or even Proposed Standard. These documents receive a technical review from the IESG and (if approved) are published by the RFC Editor. Working groups are chartered to publish Experimental, Informational or Proposed Standards. The intended outcome of the BoF is the formation of an IETF working group chartered to produce Proposed Standards. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk] > Sent: Thursday, June 05, 2014 9:24 PM > To: Templin, Fred L; spencerdawkins.ietf@gmail.com; mls.ietf@gmail.com > Cc: iesg@ietf.org; dtn@ietf.org > Subject: RE: [dtn] DTN BoF Proposal for IETF90 >=20 > Fred, >=20 > CCSDS exerts lockin on space agencies. It's very resistant to market forc= es (like, you know, TCP/IP), > and utterly resistant to multiple competing solutions - which is why the = bundle protocol was developed > and pushed. It's rather analogous to the telcos developing ATM in the 199= 0s to meet their needs, and > then doing that development in the ATM Forum. The IETF sat happily by, sh= aking its head for the most > part. >=20 > The question is, why should the IETF spend further time and effort for CC= SDS on the bundle protocol to > preserve the CCSDS bulwark against IP, where there are other things its e= xperts could be doing that > benefit actual IETF protocols? The bundle protocol is politically favoure= d by CCSDS, but is not > technically good. >=20 > (Also, it's unclear, from this discussion, that when you say 'a standard'= whether you mean 'a > published RFC' or 'a standards-track RFC' or 'a standard'. Those are prog= ressively higher bars.) >=20 > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Templin, Fred L > Sent: Friday, 6 June 2014 4:02 AM > To: Wood L Dr (Electronic Eng); spencerdawkins.ietf@gmail.com; mls.ietf@= gmail.com > Cc: iesg@ietf.org; dtn@ietf.org > Subject: RE: [dtn] DTN BoF Proposal for IETF90 >=20 > Hi Lloyd, >=20 > Wading through your points, you seem to be concerned that standardizing > the Bundle Protocol in the IETF will somehow block other approaches from > going forward in the future, but that would not be consistent with my > understanding of the way the IETF operates. There are many examples where > multiple solutions for roughly the same problem space have gone forward > to standards track and have all found widespread application - sometimes > based on the best-fit solution for the particular problem and sometimes > based on market forces. >=20 > The purpose of having a standard is so that vendors can independently > create interoperable implementations, and the IETF is the correct forum > for developing internetworking standards. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > > -----Original Message----- > > From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of l.wood@surrey.ac.u= k > > Sent: Thursday, June 05, 2014 4:20 AM > > To: spencerdawkins.ietf@gmail.com; mls.ietf@gmail.com > > Cc: iesg@ietf.org; dtn@ietf.org > > Subject: Re: [dtn] DTN BoF Proposal for IETF90 > > > > As previously expressed on DTNRG, I have a number of concerns about > > this proposed BOF to create an IETF DTN WG to do work on the > > RFC5050 bundle protocol, produced in the IRTF DTNRG, and create > > an RFC5050bis. I'll go through those concerns one by one: > > > > > > 1. I don't see how going standards track can be justified, because: > > > > a. CCSDS is already working on the bundle protocol as one of their > > blue book standards, based on RFC5050, and any RFC5050bis > > would presumably also be adopted and then modified to make > > a CCSDS standard. > > It's rather like CCSDS restandardizing TCP/IP as SCPS, back > > in the 1990s. That SCPS standardization wasn't used much > > either, not least because CCSDS 'improved' on TCP/IP > > and went incompatible quite quickly. The same will happen > > with the CCSDS bundle protocol, and in adopting RFC5050 > > CCSDS has reserved the right to make changes - things like > > Delay Tolerant Payload Conditioning (DTPC) are but the start. > > There's an example of bundle protocol work not requiring > > the IETF. Work on altering and extending the bundle protocol > > is already ongoing in CCSDS. > > Setting up an IETF workgroup to work in parallel would mean > > that a CCSDS liaison would be required, to pay attention > > to their concerns as they try and convince their member space > > agencies to use the bundle protocol, and to prevent their spec > > from diverging (further) from the IETF spec. Really, the work > > is simply more easily done in CCSDS, given that CCSDS is > > pretty much the only customer for bundle protocol, because > > NASA has mandated bundle protocol use from on high. > > NASA leads CCSDS, NASA Jet Propulsion Lab leads CCSDS design > > for NASA's Space Communications and Navigation people. > > JPL is really the primary customer for and user of bundle > > protocol, responsible for promoting its use by other space > > agencies - never an easy task, even with good technologies. > > > > b. The IETF produces Internet standards. The bundle protocol > > has little bearing on or interaction with Internet standards; > > it's arguably a way to interoperate with the Internet while > > protecting CCSDS from incursion of the Internet, by layering > > over both Internet and CCSDS. Each to their own domains. > > Using TCP as the most common bundle convergence layer (described > > in a draft now seven years old) does not make the bundle protocol > > an internet standard. If it did, then CCSDS's Space Link > > Extension (basically a TCP tunnel carrying CCSDS frames, with > > much added complexity) would also be a candidate for an > > IETF internet standard. > > But, again, that work is best done in CCSDS, where there > > is interest in having it done and there are users. (Some > > of those users may even be willing users.) > > > > c. The bundle protocol is not mature. Deficiencies have been > > identified, drafts have been written in DTNRG over the years, > > there was little interest, the drafts expired, the bundle > > protocol was never improved. And that's just from demonstrations; > > there has not been extended operational use to my knowledge. > > Attempting to fix the bundle protocol AND push it through as > > standards track at the same time seems unwarranted. > > It may be politically motivated, but it is > > not technically or procedurally justifiable. > > There isn't the userbase or demand needed for the bundle > > protocol to go standards track, and if the IETF did go > > standards track, CCSDS would 'optimize' that standard into > > its own standard, just as was done with SCPS, meaning that > > the IETF would spend a lot of time working on something with > > no benefit to the IETF community or userbase. Extending > > the Internet protocols to the DTN network problem space > > adds value to the internet protocols. A separate protocol > > does not. > > Who would benefit, outside the CCSDS community? And CCSDS > > is their own standards org - an ISO subgroup - to do work > > for that CCSDS community. > > > > > > 2. I don't see why this needs to be done in an IETF WG, because: > > > > a. going standards track isn't justifiable - see 1. > > > > b. There's already the IRTF DTNRG, which could clean up its > > own work, but ,after many years and some failed drafts, > > has not. > > Declaring success and saying it is now time to create a > > WG based on DTNRG's achievements is not convincing, > > because those achievements are not impressive. > > (Disclaimer of interest: I authored 'A bundle of problems' > > and have spent considerable years trying to explain and > > address problems with the bundle protocol, with little > > success, after getting it tested in space before NASA's > > EXPOXI/Deep Impact tests took place. > > Fred Templin's problem statement drafts for this putative > > IETF BOF calls on that work.) > > RFC5050bis would make more sense as a DTNRG > > effort, though it would be time for a changing of the > > guard and chairs in DTNRG to infuse some new blood and > > technical judgement - or we're in for another five years > > of what-does-the-end-to-end-principle-really-mean and > > what-about-clocks and rehashing the same old arguments. > > Really, DTNRG needs to get its act together, both > > organizationally and technically. > > > > c. There's already CCSDS, which has adopted the DTNRG output, > > after pushing for the formation of an Interplanetary > > Internet RG in the first place. > > > > So either CCSDS or DTNRG can do RFC5050 revision work. If > > it's to be an RFC, experimental or informational, a revitalised > > rechartered DTNRG can do it. > > It doesn't need to be an IETF workgroup. It certainly > > shouldn't go standards track. > > > > > > 3. The philosophically shaky basis for the bundle protocol: > > > > a. Delay-tolerant networking is not disruption-tolerant > > networking. Space delays of light-minutes with scheduled > > contacts are not the same as intermittent ad-hoc > > manet-style communications. Different requirements, > > different buffering and storage, different conditions, > > different handling of fragmentation, etc. > > > > b. The bundle protocol is not DTN. DTN is the scenario, > > in which other approaches (the related CFDP, Haggle, > > the MANET and vehicular DTNs efforts that DTN subsumed > > and rebranded, etc.) exist. > > The bundle protocol is intended to be used in a DTN > > scenario. Branding the bundle protocol as DTN has > > put back non-bundle DTN research a number of years. > > Branding a group only working on the bundle protocol > > as 'DTN' is misleading at best. > > > > c. Extending the bundle protocol from the original > > Interplanetary Internet problem (which had its own > > IRTF RG which led into a set bundle agenda for > > DTNRG) to cover everything else as well simply hasn't > > worked very well, because the scenarios and use cases > > are different. We design for use cases. To be too > > generalised is to engineer for nothing. > > > > d. Ignoring the ramifications of the end-to-end principle, > > which are often more subtle than people seem to think > > they are. The bundle protocol's custody transfer > > procedure is a good example of this failing. > > > > e. The bundle protocol is intended for use in the most > > difficult noisy disrupted networking conditions we know, > > and it can't even sanity check its own headers against > > errors. (But hey, it now has a security protocol that > > _almost_ does that! But which is too complicated, and > > would need to be redone.) > > It's intended for the harshest environments we know, > > but needs reliable synchronized clocks running at > > steady temperatures! > > It's intended for embedded systems, but the design > > is huge and complex! (CFDP has the same problem; > > there's a reason implementers went for a "CFDP lite," > > and Saratoga exists just because CFDP wasn't performing. > > Would RFC5050bis be "bundling lite"?) > > There are many 'that makes no sense' moments - normally > > more immediately visible to outsiders not steeped in > > the dogma, politics, and history of DTNRG and CCSDS. > > > > f. The assumption that a full security suite is desirable > > and necessary at all times. This has derailed DTNRG, > > as emphasis was placed on security work above all > > else, rather than working to the scenario. To be fair > > to the security-focused chairs, the charter that > > established DTNRG from the interplanetary internet > > research group called out security heavily, and they > > ran with that mandate. But the focus has decreased > > work on non-security matters, which is to say, > > everything else. > > > > RFC5050bis might address the latter three problems, but > > the first three are intrinsically unsolvable; any solution > > will be unsatisfactory. Perhaps not as unsatisfactory as > > RFC5050, but unsatisfactory nonetheless. > > > > The real philosophical problem here is the political dogma > > that, whatever the problem, the bundle protocol is The > > One True Solution. > > > > > > 4. The draft BOF charter is bundle-centric. Which is to say, > > that it's not awfully relevant to internet standards. > > Disclaimer of interest: we've worked on Saratoga and > > HTTP-DTN, which have current internet-drafts, and are > > squarely in the DTN problem space. > > Whenever someone talks about multiple convergence > > layers for the bundle protocol - there's more than for BEEP, > > which just has TCP, but there aren't many - Saratoga may > > be mentioned. But we've found that carrying bundles doesn't > > benefit Saratoga - tested it in space, didn't see the > > advantages. Saratoga does leverage a few Internet things - > > UDP, UDP-Lite, multicast. It does a few scaling things that > > nothing else I've seen does (described in our 2011 TSVAREA > > presentation to IETF 88 in November.) And it's based on > > a decade of operational use in the problem domain. > > HTTP-DTN leverages the HTTP suite and MIME, and comes up > > whenever wouldn't-it-be-nice-to-try-HTTP-for-DTN discussion > > takes place. > > (I suspect that all of Stephen Farrell's N4C work could > > have been done over hop-by-hop HTTP a la HTTP-DTN, and > > would have worked just as well if not better. After all, > > it used TCP.) > > These and other efforts exist in a gap between DTNRG, which > > is aware of the problem space, but thinks the bundle > > protocol is the solution despite mounting evidence to the > > contrary, and TSVWG, where the few actual transport > > experts live, without clout, or funding, or spare time. > > Those efforts are interesting enough to have implementations > > kicking around too. > > And yet, the focus of this putative workgroup and BOF is > > solely on bundling, and not on evaluating these or other > > things that might exist in the problem space. There > > must be other things out there that would be of interest > > to such a DTN workgroup. What is proposed is not a DTN > > workgroup. The charter is basically a bundle workgroup. > > Can an interest in bundling and solely bundling (outside > > CCSDS, which is driving the push to use the bundle protocol) > > be justified for an IETF workgroup? I really don't think so. > > > > 5. The bundle protocol work was, I gather, well-funded > > by a number of parties. > > I can't see a follow-on effort being anywhere near > > as well funded. > > > > a. I have no idea how much money NASA and CCSDS have put > > into this - first CFDP, then bundling, which now has > > to provide a CFDP-like API to the users who were told > > that CFDP was the future, and Licklider (LTP). > > Dragging CCSDS into the modern age of networking > > seems unlikely to ever happen, thanks to CCSDS having > > little in the way of sane layering or separation of > > functionality. > > I do have the luxury of not needing to work on CCSDS. > > But if you want to work on CCSDS protocols, CCSDS is > > the place to go. The IETF is not that place. > > > > b. DARPA poured money into DTN work - at least twenty > > million dollars, from the press releases I've seen. > > I have no idea what DARPA got out of it in the > > years they were involved; haven't seen the reports. > > > > My point is, all that money and effort and manpower and > > over a decade of work and prior experience with CFDP and two > > IRTF RGs, we have... RFC5050. > > There is nowhere near as much money or effort or manpower > > for doing a replacement. > > Ergo, it might be suggested that the replacement is unlikely > > to be as good as RFC5050, or as good as CFDP; at best, > > the usual suspects will have less time and fewer resources > > to repeat their original mistakes. > > > > And transport expertise from TSVWG would be needed. > > TSVWG is unfashionable, low-visibility, and has even > > previously had trouble finding ADs with relevant expertise. > > And TSVWG has a full plate with work on its existing > > protocols; there is not a lot of expertise, and what there > > is is spread thin. > > So an RFC505bis effort is unlikely to get the expert > > technical input that it sorely needs, even if an IETF > > workgroup is set up. (CCSDS doesn't have that transport > > focus.) > > > > If, on the other hand, you believe good protocol design > > can be done more cheaply and leverage actual Internet > > standards to get Internet functionality working in > > difficult networks where the full TCP/IP suite has > > trouble, your options include Saratoga and HTTP-DTN! > > http://saratoga.sourceforge.net/ > > http://sat-net.com/L.Wood/dtn/http-dtn.html > > They'll truly extend the Internet to difficult > > environments. The bundle protocol won't. > > > > So, to conclude, there is no justification for going > > standards track. There is little justification for an > > IETF workgroup. There is more logic in rechartering and > > repurposing the IRTF DTNRG, but the work may as well > > be left to CCSDS entirely. > > > > RFC5050bis: half-assed, half-baked, reheated. > > But hey, ask me what I _really_ think. > > > > Lloyd Wood > > http://sat-net.com/L.Wood/dtn/ > > > > _______________________________________________ > > dtn mailing list > > dtn@ietf.org > > https://www.ietf.org/mailman/listinfo/dtn From nobody Fri Jun 6 11:39:14 2014 Return-Path: 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 948B31A0156 for ; Fri, 6 Jun 2014 11:39:06 -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 oTngFsAXG3Av for ; Fri, 6 Jun 2014 11:39:05 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FDF41A0217 for ; Fri, 6 Jun 2014 11:39:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s56Icwa5019165; Fri, 6 Jun 2014 11:38:58 -0700 Received: from XCH-PHX-409.sw.nos.boeing.com (xch-phx-409.sw.nos.boeing.com [10.57.37.40]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s56Icsse019115 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Fri, 6 Jun 2014 11:38:54 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.105]) by XCH-PHX-409.sw.nos.boeing.com ([169.254.9.38]) with mapi id 14.03.0181.006; Fri, 6 Jun 2014 11:38:53 -0700 From: "Templin, Fred L" To: "dtn@ietf.org" Thread-Topic: I-D Action: draft-burleigh-bpv7-00.txt Thread-Index: AQHPga4bTjk+x95AqU2HJKW+VTwca5tkZHdA Date: Fri, 6 Jun 2014 18:38:52 +0000 Message-ID: <2134F8430051B64F815C691A62D983181B2C0587@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.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/z2hb7srDG2bJphu-0rSQtPPFado Subject: [dtn] FW: I-D Action: draft-burleigh-bpv7-00.txt X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 18:39:06 -0000 FYI, see below for a first draft of RFC5050bis (Appendix A has a summary of differences from RFC5050). Comments to dtn@ietf.org. -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Friday, June 06, 2014 10:38 AM To: i-d-announce@ietf.org Subject: I-D Action: draft-burleigh-bpv7-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Proposed Revised Bundle Protocol Author : Scott Burleigh Filename : draft-burleigh-bpv7-00.txt Pages : 64 Date : 2014-06-06 Abstract: This Internet Draft presents a proposed modification to the Bundle Protocol Specification, including notes on the rationale underlying some of the proposed changes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-burleigh-bpv7/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-burleigh-bpv7-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Fri Jun 6 11:44:33 2014 Return-Path: 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 8E60B1A021C for ; Fri, 6 Jun 2014 11:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.841 X-Spam-Level: X-Spam-Status: No, score=-4.841 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] 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 eG3F9p8sK7OQ for ; Fri, 6 Jun 2014 11:44:30 -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 D39411A021E for ; Fri, 6 Jun 2014 11:44:29 -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 s56IiMbf009204; Fri, 6 Jun 2014 13:44:22 -0500 Received: from XCH-PHX-310.sw.nos.boeing.com (xch-phx-310.sw.nos.boeing.com [130.247.25.169]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s56IiJZF008918 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Fri, 6 Jun 2014 13:44:20 -0500 Received: from XCH-BLV-502.nw.nos.boeing.com (2002:82f7:19bf::82f7:19bf) by XCH-PHX-310.sw.nos.boeing.com (2002:82f7:19a9::82f7:19a9) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 6 Jun 2014 11:44:19 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.105]) by XCH-BLV-502.nw.nos.boeing.com ([169.254.2.16]) with mapi id 14.03.0181.006; Fri, 6 Jun 2014 11:44:18 -0700 From: "Templin, Fred L" To: "dtn@ietf.org" Thread-Topic: [dtn] DTN BoF Proposal for IETF90 Thread-Index: Ac+AQa9Fez/CplZaSwyaLFpzb8tj0wAiVZ0AAAXfQWAADdLFAAAnSnyg Date: Fri, 6 Jun 2014 18:44:17 +0000 Message-ID: <2134F8430051B64F815C691A62D983181B2C05A4@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2BF3F7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2BF96C@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983181B2BF96C@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: multipart/mixed; boundary="_002_2134F8430051B64F815C691A62D983181B2C05A4XCHBLV504nwnosb_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/690whLDGZS0WzIhSDZHEOcoa9_E Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 18:44:32 -0000 --_002_2134F8430051B64F815C691A62D983181B2C05A4XCHBLV504nwnosb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable See below for updated charter with pointer to new doc (diffs attached). Thanks - Fred --- Draft BoF Agenda (2.5hrs): ************************** 1) Problem statement (IETF wg motivation) - 30min 2) RFC5050(bis) - 15min 3) Streamlined Bundle Security Protocol (SBSP) - 15min 4) Bundle-in-Bundle Encapsulation - 10min 5) Security Key Management - 10min 6) Registry for Service Identifiers - 10min 7) Network Management - 10min 8) Open Discussion - 50min Proposed working group charter: ******************************* Working group name:=20 Delay/Disruption Tolerant Networking Working Group (DTNWG) Chair(s): TBD Area and Area Director(s): Transport Area: ADs Spencer Dawkins , Martin Stiemerling Responsible Area Director: TBD Mailing list: General Discussion: dtn at ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dtn Archive: http://www.ietf.org/mail-archive/web/dtn/current/maillist.ht= ml Description of Working Group: The Delay/Disruption Tolerant Network Working Group (DTNWG) specifies mechanisms for data communications in the presence of long delays and/or intermittent connectivity. The work is motivated by well known limitations of standard Internet protocols that expect end-to-end connectivity between communicating endpoints, sub-second transmission delays and robust packet delivery ratios. In environments where these favorable conditions do not apply, existing mechanisms such as reliab= le transport protocols and routing protocols can fail to converge result= ing in communication failures. Furthermore, classical end-to-end security associations cannot be coordinated when communicating endpoints canno= t conduct multi-message keying exchanges in a timely fashion. These limitations suggest the need for a new approach.=20 =20 Delay-Tolerant Networking (DTN) protocols have been the subject of extensive research and development in the Delay-Tolerant Networking Research Group of the Internet Research Task Force since 2002. In particular, the DTN Bundle Protocol (RFC 5050) and Licklider Transmission Protocol (RFC 5326) have been shown to address the issues identified above in substantial fielded deployments [1]. The success of the BP/LTP protocol stack -- the core protocols of the "DTN Architecture" originally described in RFC 4838 -- may be attribu= ted to the following fundamental design principles: - There is never any expectation of contemporaneous end-to-end connectivity between any two network nodes. - Because end-to-end connectivity can never be assumed, each node on the path between source and destination must be prepared to handle incoming "bundles" of data that cannot immediately be forwarded. - Again because end-to-end connectivity can never be assumed, end-to-end conversational data exchange can never be assumed to complete in a timely manner; protocol features that rely on timely conversational data exchange must be excluded from the architecture. The DTNWG believes that protocols adhering to these principles offer opportunities for enhancing the functionality of the Internet - in particular, for facilitating the extension of the Internet into environments such as the ocean floor and deep space in which the core Internet protocols operate sub-optimally for the reasons discussed earlier. We believe that the extensive research, demonstration, and pilot operations performed to date using the DTNRG protocols provides a firm basis for publishing Internet standards derived from that work= . Work items related to Delay/Disruption Tolerant Networking include: o A mechanism for the exchange of protocol data units, termed "bundles", that are designed to obviate conversational communications by containing values for all potentially relevant configuration parameters. These protocol data units are typically larger than network-layer packets. We will derive this bundle exchange mechanism from the DTN Bundle Protocol (BP) documented in RFC 5050 by publish= ing a new document [2], where appendix A and B provide an update summar= y. o A security protocol for ensuring that the network in which bundles are exchanged is secured against unauthorized access and denial of service attacks, and to ensure data integrity and confidentiality in that network where necessary. We will derive this security protocol from a "streamlined" adaptation of the DTN Bundle Security Protocol documented in RFC 6257. o An encapsulation protocol for "tunneling" BP traffic within bundles that are secured and/or routed in different way from the encapsulated bundles. o A delay-tolerant security key management scheme for ensuring that public keys are certified by a globally trusted authority to protect the integrity of the infrastructure. o A simple datagram convergence layer protocol for adaptation of the bundle protocol to underlying internetworks. We expect to derive this convergence layer protocol from the Datagram Convergence protocol documented in RFC 7122. o A delay-tolerant network management protocol for management of the infrastructure in the presence of long delays and/or intermittent connectivity. o A registry for DTN Service Identifiers =20 The working group will consider extending the current milestones based = on new information and knowledge gained while working on the initial chart= er, as well as to accommodate new work items beyond the scope of the initia= l phase. For example, we expect that transport protocols such as LTP and the Saratoga protocol are among the candidates for work in this phase. =20 Goals and Milestones: start+3mos - Submit 'Bundle Protocol Specification (RFC5050bis)' as a working group document. To be Proposed Standard. Start+3mos - Submit 'Streamlined Bundle Security Protocol (SBSP)' as a working group document. To be Proposed Standard. start+6mos - Submit 'Bundle In Bundle Encapsulation (BIBE)' as a working group document. To be Proposed Standard. start+12mos - Submit 'Delay Tolerant Networking Security Key Management' = as a working group document. To be Proposed Standard. start+18mos - WG determination for merging RFC5050bis, SBSP, BIBE and/or Key Mgmt into a combined draft or keep as separate drafts. start+18mos - Submit RFC5050bis, SBSP, BIBE and Key Mgmt to the IESG eith= er as a combined draft or as separate drafts. start+18mos - Submit Network Management, Registry and Simple Convergence Layer as working group documents. start+20mos - Survey appropriate forums (e.g., DTNRG) for emerging technologies (e.g., convergence layer protocols, dynamic routing protocols, naming and addressing services, etc.) ready for transition into IETF DTN Working Group. Publish draft on survey results as independent submission related to the WG. start+24mos - Submit Network Management, Registry and Simple Convergence Layer to IESG start+24mos - Recharter to accommodate new work items or close Working Gr= oup [1] "BP/LTP deployment on EPOXI spacecraft" [2008] [2] "Proposed Revised Bundle Protocol" [2014], https://datatracker.ietf.org/doc/draft-burleigh-bpv7/ --_002_2134F8430051B64F815C691A62D983181B2C05A4XCHBLV504nwnosb_ Content-Type: text/html; name="wdiff 02a_txt 03a_txt.htm" Content-Description: wdiff 02a_txt 03a_txt.htm Content-Disposition: attachment; filename="wdiff 02a_txt 03a_txt.htm"; size=24565; creation-date="Fri, 06 Jun 2014 18:40:57 GMT"; modification-date="Fri, 06 Jun 2014 18:40:57 GMT" Content-Transfer-Encoding: base64 CjxodG1sPjxoZWFkPjx0aXRsZT53ZGlmZiAwMmEudHh0IDAzYS50eHQ8L3RpdGxlPjwvaGVhZD48 Ym9keT4KPHByZT4KRHJhZnQgQm9GIEFnZW5kYSAoMi41aHJzKToKKioqKioqKioqKioqKioqKioq KioqKioqKioKMSkgUHJvYmxlbSBzdGF0ZW1lbnQgKElFVEYgd2cgbW90aXZhdGlvbikgLSAzMG1p bgoKMikgUkZDNTA1MChiaXMpIC0gMTVtaW4KCjMpIFN0cmVhbWxpbmVkIEJ1bmRsZSBTZWN1cml0 eSBQcm90b2NvbCAoU0JTUCkgLSAxNW1pbgoKNCkgQnVuZGxlLWluLUJ1bmRsZSBFbmNhcHN1bGF0 aW9uIC0gMTBtaW4KCjUpIFNlY3VyaXR5IEtleSBNYW5hZ2VtZW50IC0gMTBtaW4KCjYpIFJlZ2lz dHJ5IGZvciBTZXJ2aWNlIElkZW50aWZpZXJzIC0gMTBtaW4KCjcpIE5ldHdvcmsgTWFuYWdlbWVu dCAtIDEwbWluCgo4KSBPcGVuIERpc2N1c3Npb24gLSA1MG1pbgoKUHJvcG9zZWQgd29ya2luZyBn cm91cCBjaGFydGVyOgoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCldvcmtpbmcgZ3Jv dXAgbmFtZToKCiAgICAgIERlbGF5L0Rpc3J1cHRpb24gVG9sZXJhbnQgTmV0d29ya2luZyBXb3Jr aW5nIEdyb3VwIChEVE5XRykKCkNoYWlyKHMpOgoKICAgICAgVEJECgpBcmVhIGFuZCBBcmVhIERp cmVjdG9yKHMpOgoKICAgICAgVHJhbnNwb3J0IEFyZWE6IEFEcyBTcGVuY2VyIERhd2tpbnMgJmx0 O3NwZW5jZXJkYXdraW5zLmlldGYgYXQgZ21haWwuY29tJmd0OywKICAgICAgICAgICAgICAgICAg ICAgICAgICBNYXJ0aW4gU3RpZW1lcmxpbmcgJmx0O21scy5pZXRmIGF0IGdtYWlsLmNvbSZndDsK ClJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3I6CgogICAgICBUQkQKCk1haWxpbmcgbGlzdDoKCiAg ICAgIEdlbmVyYWwgRGlzY3Vzc2lvbjogZHRuIGF0IGlldGYub3JnCiAgICAgIFRvIFN1YnNjcmli ZTogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kdG4KICAgICAgQXJjaGl2 ZTogaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2R0bi9jdXJyZW50L21haWxs aXN0Lmh0bWwKCkRlc2NyaXB0aW9uIG9mIFdvcmtpbmcgR3JvdXA6CgogICAgICBUaGUgRGVsYXkv RGlzcnVwdGlvbiBUb2xlcmFudCBOZXR3b3JrIFdvcmtpbmcgR3JvdXAgKERUTldHKSBzcGVjaWZp ZXMKICAgICAgbWVjaGFuaXNtcyBmb3IgZGF0YSBjb21tdW5pY2F0aW9ucyBpbiB0aGUgcHJlc2Vu Y2Ugb2YgbG9uZyBkZWxheXMKICAgICAgYW5kL29yIGludGVybWl0dGVudCBjb25uZWN0aXZpdHku IFRoZSB3b3JrIGlzIG1vdGl2YXRlZCBieSB3ZWxsIGtub3duCiAgICAgIGxpbWl0YXRpb25zIG9m IHN0YW5kYXJkIEludGVybmV0IHByb3RvY29scyB0aGF0IGV4cGVjdCBlbmQtdG8tZW5kCiAgICAg IGNvbm5lY3Rpdml0eSBiZXR3ZWVuIGNvbW11bmljYXRpbmcgZW5kcG9pbnRzLCBzdWItc2Vjb25k IHRyYW5zbWlzc2lvbgogICAgICBkZWxheXMgYW5kIHJvYnVzdCBwYWNrZXQgZGVsaXZlcnkgcmF0 aW9zLiBJbiBlbnZpcm9ubWVudHMgd2hlcmUgdGhlc2UKICAgICAgZmF2b3JhYmxlIGNvbmRpdGlv bnMgZG8gbm90IGFwcGx5LCBleGlzdGluZyBtZWNoYW5pc21zIHN1Y2ggYXMgcmVsaWFibGUKICAg ICAgdHJhbnNwb3J0IHByb3RvY29scyBhbmQgcm91dGluZyBwcm90b2NvbHMgY2FuIGZhaWwgdG8g Y29udmVyZ2UgcmVzdWx0aW5nCiAgICAgIGluIGNvbW11bmljYXRpb24gZmFpbHVyZXMuIEZ1cnRo ZXJtb3JlLCBjbGFzc2ljYWwgZW5kLXRvLWVuZCBzZWN1cml0eQogICAgICBhc3NvY2lhdGlvbnMg Y2Fubm90IGJlIGNvb3JkaW5hdGVkIHdoZW4gY29tbXVuaWNhdGluZyBlbmRwb2ludHMgY2Fubm90 CiAgICAgIGNvbmR1Y3QgbXVsdGktbWVzc2FnZSBrZXlpbmcgZXhjaGFuZ2VzIGluIGEgdGltZWx5 IGZhc2hpb24uIFRoZXNlCiAgICAgIGxpbWl0YXRpb25zIHN1Z2dlc3QgdGhlIG5lZWQgZm9yIGEg bmV3IGFwcHJvYWNoLgoKICAgICAgRGVsYXktVG9sZXJhbnQgTmV0d29ya2luZyAoRFROKSBwcm90 b2NvbHMgaGF2ZSBiZWVuIHRoZSBzdWJqZWN0IG9mCiAgICAgIGV4dGVuc2l2ZSByZXNlYXJjaCBh bmQgZGV2ZWxvcG1lbnQgaW4gdGhlIERlbGF5LVRvbGVyYW50IE5ldHdvcmtpbmcKICAgICAgUmVz ZWFyY2ggR3JvdXAgb2YgdGhlIEludGVybmV0IFJlc2VhcmNoIFRhc2sgRm9yY2Ugc2luY2UgMjAw Mi4gIEluCiAgICAgIHBhcnRpY3VsYXIsIHRoZSBEVE4gQnVuZGxlIFByb3RvY29sIChSRkMgNTA1 MCkgYW5kIExpY2tsaWRlcgogICAgICBUcmFuc21pc3Npb24gUHJvdG9jb2wgKFJGQyA1MzI2KSBo YXZlIGJlZW4gc2hvd24gdG8gYWRkcmVzcyB0aGUKICAgICAgaXNzdWVzIGlkZW50aWZpZWQgYWJv dmUgaW4gc3Vic3RhbnRpYWwgZmllbGRlZCBkZXBsb3ltZW50cyBbMV0uCgogICAgICBUaGUgc3Vj Y2VzcyBvZiB0aGUgQlAvTFRQIHByb3RvY29sIHN0YWNrIC0tIHRoZSBjb3JlIHByb3RvY29scyBv ZiB0aGUKICAgICAgIkRUTiBBcmNoaXRlY3R1cmUiIG9yaWdpbmFsbHkgZGVzY3JpYmVkIGluIFJG QyA0ODM4IC0tIG1heSBiZSBhdHRyaWJ1dGVkCiAgICAgIHRvIHRoZSBmb2xsb3dpbmcgZnVuZGFt ZW50YWwgZGVzaWduIHByaW5jaXBsZXM6CgoJLSBUaGVyZSBpcyBuZXZlciBhbnkgZXhwZWN0YXRp b24gb2YgY29udGVtcG9yYW5lb3VzIGVuZC10by1lbmQKICAgICAgICAgIGNvbm5lY3Rpdml0eSBi ZXR3ZWVuIGFueSB0d28gbmV0d29yayBub2Rlcy4KCgktIEJlY2F1c2UgZW5kLXRvLWVuZCBjb25u ZWN0aXZpdHkgY2FuIG5ldmVyIGJlIGFzc3VtZWQsIGVhY2ggbm9kZQoJICBvbiB0aGUgcGF0aCBi ZXR3ZWVuIHNvdXJjZSBhbmQgZGVzdGluYXRpb24gbXVzdCBiZSBwcmVwYXJlZCB0bwoJICBoYW5k bGUgaW5jb21pbmcgImJ1bmRsZXMiIG9mIGRhdGEgdGhhdCBjYW5ub3QgaW1tZWRpYXRlbHkgYmUK CSAgZm9yd2FyZGVkLgoKCS0gQWdhaW4gYmVjYXVzZSBlbmQtdG8tZW5kIGNvbm5lY3Rpdml0eSBj YW4gbmV2ZXIgYmUgYXNzdW1lZCwKCSAgZW5kLXRvLWVuZCBjb252ZXJzYXRpb25hbCBkYXRhIGV4 Y2hhbmdlIGNhbiBuZXZlciBiZSBhc3N1bWVkIHRvCgkgIGNvbXBsZXRlIGluIGEgdGltZWx5IG1h bm5lcjsgcHJvdG9jb2wgZmVhdHVyZXMgdGhhdCByZWx5IG9uCgkgIHRpbWVseSBjb252ZXJzYXRp b25hbCBkYXRhIGV4Y2hhbmdlIG11c3QgYmUgZXhjbHVkZWQgZnJvbSB0aGUKCSAgYXJjaGl0ZWN0 dXJlLgoKICAgICAgVGhlIERUTldHIGJlbGlldmVzIHRoYXQgcHJvdG9jb2xzIGFkaGVyaW5nIHRv IHRoZXNlIHByaW5jaXBsZXMgb2ZmZXIKICAgICAgb3Bwb3J0dW5pdGllcyBmb3IgZW5oYW5jaW5n IHRoZSBmdW5jdGlvbmFsaXR5IG9mIHRoZSBJbnRlcm5ldCAtIGluCiAgICAgIHBhcnRpY3VsYXIs IGZvciBmYWNpbGl0YXRpbmcgdGhlIGV4dGVuc2lvbiBvZiB0aGUgSW50ZXJuZXQgaW50bwogICAg ICBlbnZpcm9ubWVudHMgc3VjaCBhcyB0aGUgb2NlYW4gZmxvb3IgYW5kIGRlZXAgc3BhY2UgaW4g d2hpY2ggdGhlIGNvcmUKICAgICAgSW50ZXJuZXQgcHJvdG9jb2xzIG9wZXJhdGUgc3ViLW9wdGlt YWxseSBmb3IgdGhlIHJlYXNvbnMgZGlzY3Vzc2VkCiAgICAgIGVhcmxpZXIuICBXZSBiZWxpZXZl IHRoYXQgdGhlIGV4dGVuc2l2ZSByZXNlYXJjaCwgZGVtb25zdHJhdGlvbiwgYW5kCiAgICAgIHBp bG90IG9wZXJhdGlvbnMgcGVyZm9ybWVkIHRvIGRhdGUgdXNpbmcgdGhlIERUTlJHIHByb3RvY29s cyBwcm92aWRlcwogICAgICBhIGZpcm0gYmFzaXMgZm9yIHB1Ymxpc2hpbmcgSW50ZXJuZXQgc3Rh bmRhcmRzIGRlcml2ZWQgZnJvbSB0aGF0IHdvcmsuCgogICAgICBXb3JrIGl0ZW1zIHJlbGF0ZWQg dG8gRGVsYXkvRGlzcnVwdGlvbiBUb2xlcmFudCBOZXR3b3JraW5nIGluY2x1ZGU6CgogICAgICBv IEEgbWVjaGFuaXNtIGZvciB0aGUgZXhjaGFuZ2Ugb2YgcHJvdG9jb2wgZGF0YSB1bml0cywgdGVy bWVkCgkiYnVuZGxlcyIsIHRoYXQgYXJlIGRlc2lnbmVkIHRvIG9idmlhdGUgY29udmVyc2F0aW9u YWwgY29tbXVuaWNhdGlvbnMKCWJ5IGNvbnRhaW5pbmcgdmFsdWVzIGZvciBhbGwgcG90ZW50aWFs bHkgcmVsZXZhbnQgY29uZmlndXJhdGlvbgoJcGFyYW1ldGVycy4gIFRoZXNlIHByb3RvY29sIGRh dGEgdW5pdHMgYXJlIHR5cGljYWxseSBsYXJnZXIgdGhhbgoJbmV0d29yay1sYXllciBwYWNrZXRz LiBXZSB3aWxsIGRlcml2ZSB0aGlzIGJ1bmRsZSBleGNoYW5nZSBtZWNoYW5pc20KICAgICAgICBm cm9tIHRoZSBEVE4gQnVuZGxlIFByb3RvY29sIChCUCkgZG9jdW1lbnRlZCBpbiBSRkMgPHN0cmlr ZT48Zm9udCBjb2xvcj0ncmVkJyA+NTA1MC4gQ2hhbmdlcyBmcm9tCiAgICAgICAgUkZDPC9mb250 Pjwvc3RyaWtlPiA1MDUwIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCcgPndpbGwgYXBwZWFyIGlu PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicgPmJ5IHB1Ymxpc2hp bmc8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICAgYSA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnID5z b29uLXRvLWJlLXB1Ymxpc2hlZCBSRkMgNTA1MChiaXMpLjwvZm9udD48L3N0cmlrZT4gPHN0cm9u Zz48Zm9udCBjb2xvcj0nZ3JlZW4nID5uZXcgZG9jdW1lbnQgWzJdLCB3aGVyZSBhcHBlbmRpeCBB IGFuZCBCIHByb3ZpZGUgYW4gdXBkYXRlIHN1bW1hcnkuPC9mb250Pjwvc3Ryb25nPgoKICAgICAg byBBIHNlY3VyaXR5IHByb3RvY29sIGZvciBlbnN1cmluZyB0aGF0IHRoZSBuZXR3b3JrIGluIHdo aWNoIGJ1bmRsZXMKCWFyZSBleGNoYW5nZWQgaXMgc2VjdXJlZCBhZ2FpbnN0IHVuYXV0aG9yaXpl ZCBhY2Nlc3MgYW5kIGRlbmlhbCBvZgoJc2VydmljZSBhdHRhY2tzLCBhbmQgdG8gZW5zdXJlIGRh dGEgaW50ZWdyaXR5IGFuZCBjb25maWRlbnRpYWxpdHkKCWluIHRoYXQgbmV0d29yayB3aGVyZSBu ZWNlc3NhcnkuICBXZSB3aWxsIGRlcml2ZSB0aGlzIHNlY3VyaXR5Cglwcm90b2NvbCBmcm9tIGEg InN0cmVhbWxpbmVkIiBhZGFwdGF0aW9uIG9mIHRoZSBEVE4gQnVuZGxlIFNlY3VyaXR5CglQcm90 b2NvbCBkb2N1bWVudGVkIGluIFJGQyA2MjU3LgoKICAgICAgbyBBbiBlbmNhcHN1bGF0aW9uIHBy b3RvY29sIGZvciAidHVubmVsaW5nIiBCUCB0cmFmZmljIHdpdGhpbiBidW5kbGVzCgl0aGF0IGFy ZSBzZWN1cmVkIGFuZC9vciByb3V0ZWQgaW4gZGlmZmVyZW50IHdheSBmcm9tIHRoZSBlbmNhcHN1 bGF0ZWQKCWJ1bmRsZXMuCgogICAgICBvIEEgZGVsYXktdG9sZXJhbnQgc2VjdXJpdHkga2V5IG1h bmFnZW1lbnQgc2NoZW1lIGZvciBlbnN1cmluZyB0aGF0CglwdWJsaWMga2V5cyBhcmUgY2VydGlm aWVkIGJ5IGEgZ2xvYmFsbHkgdHJ1c3RlZCBhdXRob3JpdHkgdG8gcHJvdGVjdAoJdGhlIGludGVn cml0eSBvZiB0aGUgaW5mcmFzdHJ1Y3R1cmUuCgogICAgICBvIEEgc2ltcGxlIGRhdGFncmFtIGNv bnZlcmdlbmNlIGxheWVyIHByb3RvY29sIGZvciBhZGFwdGF0aW9uIG9mIHRoZQogICAgICAgIGJ1 bmRsZSBwcm90b2NvbCB0byB1bmRlcmx5aW5nIGludGVybmV0d29ya3MuIFdlIGV4cGVjdCB0byBk ZXJpdmUKICAgICAgICB0aGlzIGNvbnZlcmdlbmNlIGxheWVyIHByb3RvY29sIGZyb20gdGhlIERh dGFncmFtIENvbnZlcmdlbmNlCiAgICAgICAgcHJvdG9jb2wgZG9jdW1lbnRlZCBpbiBSRkMgNzEy Mi4KCiAgICAgIG8gQSBkZWxheS10b2xlcmFudCBuZXR3b3JrIG1hbmFnZW1lbnQgcHJvdG9jb2wg Zm9yIG1hbmFnZW1lbnQgb2YgdGhlCiAgICAgICAgaW5mcmFzdHJ1Y3R1cmUgaW4gdGhlIHByZXNl bmNlIG9mIGxvbmcgZGVsYXlzIGFuZC9vciBpbnRlcm1pdHRlbnQKICAgICAgICBjb25uZWN0aXZp dHkuCgogICAgICBvIEEgcmVnaXN0cnkgZm9yIERUTiBTZXJ2aWNlIElkZW50aWZpZXJzCgogICAg VGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBjb25zaWRlciBleHRlbmRpbmcgdGhlIGN1cnJlbnQgbWls ZXN0b25lcyBiYXNlZCBvbgogICAgbmV3IGluZm9ybWF0aW9uIGFuZCBrbm93bGVkZ2UgZ2FpbmVk IHdoaWxlIHdvcmtpbmcgb24gdGhlIGluaXRpYWwgY2hhcnRlciwKICAgIGFzIHdlbGwgYXMgdG8g YWNjb21tb2RhdGUgbmV3IHdvcmsgaXRlbXMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGUgaW5pdGlh bAogICAgcGhhc2UuICBGb3IgZXhhbXBsZSwgd2UgZXhwZWN0IHRoYXQgdHJhbnNwb3J0IHByb3Rv Y29scyBzdWNoIGFzIExUUCBhbmQKICAgIHRoZSBTYXJhdG9nYSBwcm90b2NvbCBhcmUgYW1vbmcg dGhlIGNhbmRpZGF0ZXMgZm9yIHdvcmsgaW4gdGhpcyBwaGFzZS4KCkdvYWxzIGFuZCBNaWxlc3Rv bmVzOgogIHN0YXJ0KzNtb3MgLSBTdWJtaXQgJ0J1bmRsZSBQcm90b2NvbCBTcGVjaWZpY2F0aW9u IChSRkM1MDUwYmlzKScgYXMgYQogICAgICAgICAgICAgICB3b3JraW5nIGdyb3VwIGRvY3VtZW50 LiBUbyBiZSBQcm9wb3NlZCBTdGFuZGFyZC4KICBTdGFydCszbW9zIC0gU3VibWl0ICdTdHJlYW1s aW5lZCBCdW5kbGUgU2VjdXJpdHkgUHJvdG9jb2wgKFNCU1ApJyBhcyBhCiAgICAgICAgICAgICAg IHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuIFRvIGJlIFByb3Bvc2VkIFN0YW5kYXJkLgogIHN0YXJ0 KzZtb3MgLSBTdWJtaXQgJ0J1bmRsZSBJbiBCdW5kbGUgRW5jYXBzdWxhdGlvbiAoQklCRSknIGFz IGEgd29ya2luZwogICAgICAgICAgICAgICBncm91cCBkb2N1bWVudC4gVG8gYmUgUHJvcG9zZWQg U3RhbmRhcmQuCiAgc3RhcnQrMTJtb3MgLSBTdWJtaXQgJ0RlbGF5IFRvbGVyYW50IE5ldHdvcmtp bmcgU2VjdXJpdHkgS2V5IE1hbmFnZW1lbnQnIGFzCiAgICAgICAgICAgICAgICBhIHdvcmtpbmcg Z3JvdXAgZG9jdW1lbnQuIFRvIGJlIFByb3Bvc2VkIFN0YW5kYXJkLgogIHN0YXJ0KzE4bW9zIC0g V0cgZGV0ZXJtaW5hdGlvbiBmb3IgbWVyZ2luZyBSRkM1MDUwYmlzLCBTQlNQLCBCSUJFIGFuZC9v cgogICAgICAgICAgICAgICAgS2V5IE1nbXQgaW50byBhIGNvbWJpbmVkIGRyYWZ0IG9yIGtlZXAg YXMgc2VwYXJhdGUgZHJhZnRzLgogIHN0YXJ0KzE4bW9zIC0gU3VibWl0IFJGQzUwNTBiaXMsIFNC U1AsIEJJQkUgYW5kIEtleSBNZ210IHRvIHRoZSBJRVNHIGVpdGhlcgogICAgICAgICAgICAgICAg YXMgYSBjb21iaW5lZCBkcmFmdCBvciBhcyBzZXBhcmF0ZSBkcmFmdHMuCiAgc3RhcnQrMThtb3Mg LSBTdWJtaXQgTmV0d29yayBNYW5hZ2VtZW50LCBSZWdpc3RyeSBhbmQgU2ltcGxlIENvbnZlcmdl bmNlCiAgICAgICAgICAgICAgICBMYXllciBhcyB3b3JraW5nIGdyb3VwIGRvY3VtZW50cy4KICBz dGFydCsyMG1vcyAtIFN1cnZleSBhcHByb3ByaWF0ZSBmb3J1bXMgKGUuZy4sIERUTlJHKSBmb3Ig ZW1lcmdpbmcKICAgICAgICAgICAgICAgIHRlY2hub2xvZ2llcyAoZS5nLiwgY29udmVyZ2VuY2Ug bGF5ZXIgcHJvdG9jb2xzLCBkeW5hbWljCiAgICAgICAgICAgICAgICByb3V0aW5nIHByb3RvY29s cywgbmFtaW5nIGFuZCBhZGRyZXNzaW5nIHNlcnZpY2VzLCBldGMuKQogICAgICAgICAgICAgICAg cmVhZHkgZm9yIHRyYW5zaXRpb24gaW50byBJRVRGIERUTiBXb3JraW5nIEdyb3VwLiBQdWJsaXNo CiAgICAgICAgICAgICAgICBkcmFmdCBvbiBzdXJ2ZXkgcmVzdWx0cyBhcyBpbmRlcGVuZGVudCBz dWJtaXNzaW9uIHJlbGF0ZWQKICAgICAgICAgICAgICAgIHRvIHRoZSBXRy4KICBzdGFydCsyNG1v cyAtIFN1Ym1pdCBOZXR3b3JrIE1hbmFnZW1lbnQsIFJlZ2lzdHJ5IGFuZCBTaW1wbGUgQ29udmVy Z2VuY2UKICAgICAgICAgICAgICAgIExheWVyIHRvIElFU0cKICBzdGFydCsyNG1vcyAtIFJlY2hh cnRlciB0byBhY2NvbW1vZGF0ZSBuZXcgd29yayBpdGVtcyBvciBjbG9zZSBXb3JraW5nIEdyb3Vw CgpbMV0gPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJyA+QlAvTFRQPC9mb250Pjwvc3RyaWtlPiA8 c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicgPiJCUC9MVFA8L2ZvbnQ+PC9zdHJvbmc+IGRlcGxv eW1lbnQgb24gRVBPWEkgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJyA+c3BhY2VjcmFmdDwvZm9u dD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nID5zcGFjZWNyYWZ0IjwvZm9u dD48L3N0cm9uZz4gWzIwMDhdCjxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJyA+WzJdICJQcm9w b3NlZCBSZXZpc2VkIEJ1bmRsZSBQcm90b2NvbCIgWzIwMTRdLAogICAgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYnVybGVpZ2gtYnB2Ny88L2ZvbnQ+PC9zdHJvbmc+Cjwv cHJlPgo8L2JvZHk+PC9odG1sPgpYLUdlbmVyYXRvcjogcHlodCAwLjM1Cgo8IS0tIGFyZ3M6IHsn LS1vbGRjb2xvdXInOiAncmVkJywgJy0td2lkdGgnOiAnJywgJ2RpZmZ0eXBlJzogJy0taHdkaWZm JywgJ2ZpbGVuYW1lMic6ICdEcmFmdCBCb0YgQWdlbmRhICgyLjVocnMpOlxyXG4qKioqKioqKioq KioqKioqKioqKioqKioqKlxyXG4xKSBQcm9ibGVtIHN0YXRlbWVudCAoSUVURiB3ZyBtb3RpdmF0 aW9uKSAtIDMwbWluXHJcblxyXG4yKSBSRkM1MDUwKGJpcykgLSAxNW1pblxyXG5cclxuMykgU3Ry ZWFtbGluZWQgQnVuZGxlIFNlY3VyaXR5IFByb3RvY29sIChTQlNQKSAtIDE1bWluXHJcblxyXG40 KSBCdW5kbGUtaW4tQnVuZGxlIEVuY2Fwc3VsYXRpb24gLSAxMG1pblxyXG5cclxuNSkgU2VjdXJp dHkgS2V5IE1hbmFnZW1lbnQgLSAxMG1pblxyXG5cclxuNikgUmVnaXN0cnkgZm9yIFNlcnZpY2Ug SWRlbnRpZmllcnMgLSAxMG1pblxyXG5cclxuNykgTmV0d29yayBNYW5hZ2VtZW50IC0gMTBtaW5c clxuXHJcbjgpIE9wZW4gRGlzY3Vzc2lvbiAtIDUwbWluXHJcblxyXG5cclxuUHJvcG9zZWQgd29y a2luZyBncm91cCBjaGFydGVyOlxyXG4qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqXHJc bldvcmtpbmcgZ3JvdXAgbmFtZTogXHJcblxyXG4gICAgICBEZWxheS9EaXNydXB0aW9uIFRvbGVy YW50IE5ldHdvcmtpbmcgV29ya2luZyBHcm91cCAoRFROV0cpXHJcblxyXG5DaGFpcihzKTpcclxu XHJcbiAgICAgIFRCRFxyXG5cclxuQXJlYSBhbmQgQXJlYSBEaXJlY3RvcihzKTpcclxuXHJcbiAg ICAgIFRyYW5zcG9ydCBBcmVhOiBBRHMgU3BlbmNlciBEYXdraW5zIF9zcGVuY2VyZGF3a2lucy5p ZXRmIGF0IGdtYWlsLmNvbV8sXHJcbiAgICAgICAgICAgICAgICAgICAgICAgICAgTWFydGluIFN0 aWVtZXJsaW5nIF9tbHMuaWV0ZiBhdCBnbWFpbC5jb21fXHJcblxyXG5SZXNwb25zaWJsZSBBcmVh IERpcmVjdG9yOlxyXG5cclxuICAgICAgVEJEXHJcblxyXG5NYWlsaW5nIGxpc3Q6XHJcblxyXG4g ICAgICBHZW5lcmFsIERpc2N1c3Npb246IGR0biBhdCBpZXRmLm9yZ1xyXG4gICAgICBUbyBTdWJz Y3JpYmU6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZHRuXHJcbiAgICAg IEFyY2hpdmU6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9kdG4vY3VycmVu dC9tYWlsbGlzdC5odG1sXHJcblxyXG5EZXNjcmlwdGlvbiBvZiBXb3JraW5nIEdyb3VwOlxyXG5c clxuICAgICAgVGhlIERlbGF5L0Rpc3J1cHRpb24gVG9sZXJhbnQgTmV0d29yayBXb3JraW5nIEdy b3VwIChEVE5XRykgc3BlY2lmaWVzXHJcbiAgICAgIG1lY2hhbmlzbXMgZm9yIGRhdGEgY29tbXVu aWNhdGlvbnMgaW4gdGhlIHByZXNlbmNlIG9mIGxvbmcgZGVsYXlzXHJcbiAgICAgIGFuZC9vciBp bnRlcm1pdHRlbnQgY29ubmVjdGl2aXR5LiBUaGUgd29yayBpcyBtb3RpdmF0ZWQgYnkgd2VsbCBr bm93blxyXG4gICAgICBsaW1pdGF0aW9ucyBvZiBzdGFuZGFyZCBJbnRlcm5ldCBwcm90b2NvbHMg dGhhdCBleHBlY3QgZW5kLXRvLWVuZFxyXG4gICAgICBjb25uZWN0aXZpdHkgYmV0d2VlbiBjb21t dW5pY2F0aW5nIGVuZHBvaW50cywgc3ViLXNlY29uZCB0cmFuc21pc3Npb25cclxuICAgICAgZGVs YXlzIGFuZCByb2J1c3QgcGFja2V0IGRlbGl2ZXJ5IHJhdGlvcy4gSW4gZW52aXJvbm1lbnRzIHdo ZXJlIHRoZXNlXHJcbiAgICAgIGZhdm9yYWJsZSBjb25kaXRpb25zIGRvIG5vdCBhcHBseSwgZXhp c3RpbmcgbWVjaGFuaXNtcyBzdWNoIGFzIHJlbGlhYmxlXHJcbiAgICAgIHRyYW5zcG9ydCBwcm90 b2NvbHMgYW5kIHJvdXRpbmcgcHJvdG9jb2xzIGNhbiBmYWlsIHRvIGNvbnZlcmdlIHJlc3VsdGlu Z1xyXG4gICAgICBpbiBjb21tdW5pY2F0aW9uIGZhaWx1cmVzLiBGdXJ0aGVybW9yZSwgY2xhc3Np Y2FsIGVuZC10by1lbmQgc2VjdXJpdHlcclxuICAgICAgYXNzb2NpYXRpb25zIGNhbm5vdCBiZSBj b29yZGluYXRlZCB3aGVuIGNvbW11bmljYXRpbmcgZW5kcG9pbnRzIGNhbm5vdFxyXG4gICAgICBj b25kdWN0IG11bHRpLW1lc3NhZ2Uga2V5aW5nIGV4Y2hhbmdlcyBpbiBhIHRpbWVseSBmYXNoaW9u LiBUaGVzZVxyXG4gICAgICBsaW1pdGF0aW9ucyBzdWdnZXN0IHRoZSBuZWVkIGZvciBhIG5ldyBh cHByb2FjaC4gXHJcbiAgICAgIFxyXG4gICAgICBEZWxheS1Ub2xlcmFudCBOZXR3b3JraW5nIChE VE4pIHByb3RvY29scyBoYXZlIGJlZW4gdGhlIHN1YmplY3Qgb2ZcclxuICAgICAgZXh0ZW5zaXZl IHJlc2VhcmNoIGFuZCBkZXZlbG9wbWVudCBpbiB0aGUgRGVsYXktVG9sZXJhbnQgTmV0d29ya2lu Z1xyXG4gICAgICBSZXNlYXJjaCBHcm91cCBvZiB0aGUgSW50ZXJuZXQgUmVzZWFyY2ggVGFzayBG b3JjZSBzaW5jZSAyMDAyLiAgSW5cclxuICAgICAgcGFydGljdWxhciwgdGhlIERUTiBCdW5kbGUg UHJvdG9jb2wgKFJGQyA1MDUwKSBhbmQgTGlja2xpZGVyXHJcbiAgICAgIFRyYW5zbWlzc2lvbiBQ cm90b2NvbCAoUkZDIDUzMjYpIGhhdmUgYmVlbiBzaG93biB0byBhZGRyZXNzIHRoZVxyXG4gICAg ICBpc3N1ZXMgaWRlbnRpZmllZCBhYm92ZSBpbiBzdWJzdGFudGlhbCBmaWVsZGVkIGRlcGxveW1l bnRzIFsxXS5cclxuXHJcbiAgICAgIFRoZSBzdWNjZXNzIG9mIHRoZSBCUC9MVFAgcHJvdG9jb2wg c3RhY2sgLS0gdGhlIGNvcmUgcHJvdG9jb2xzIG9mIHRoZVxyXG4gICAgICAiRFROIEFyY2hpdGVj dHVyZSIgb3JpZ2luYWxseSBkZXNjcmliZWQgaW4gUkZDIDQ4MzggLS0gbWF5IGJlIGF0dHJpYnV0 ZWRcclxuICAgICAgdG8gdGhlIGZvbGxvd2luZyBmdW5kYW1lbnRhbCBkZXNpZ24gcHJpbmNpcGxl czpcclxuXHJcblx0LSBUaGVyZSBpcyBuZXZlciBhbnkgZXhwZWN0YXRpb24gb2YgY29udGVtcG9y YW5lb3VzIGVuZC10by1lbmRcclxuICAgICAgICAgIGNvbm5lY3Rpdml0eSBiZXR3ZWVuIGFueSB0 d28gbmV0d29yayBub2Rlcy5cclxuXHJcblx0LSBCZWNhdXNlIGVuZC10by1lbmQgY29ubmVjdGl2 aXR5IGNhbiBuZXZlciBiZSBhc3N1bWVkLCBlYWNoIG5vZGVcclxuXHQgIG9uIHRoZSBwYXRoIGJl dHdlZW4gc291cmNlIGFuZCBkZXN0aW5hdGlvbiBtdXN0IGJlIHByZXBhcmVkIHRvXHJcblx0ICBo YW5kbGUgaW5jb21pbmcgImJ1bmRsZXMiIG9mIGRhdGEgdGhhdCBjYW5ub3QgaW1tZWRpYXRlbHkg YmVcclxuXHQgIGZvcndhcmRlZC5cclxuXHJcblx0LSBBZ2FpbiBiZWNhdXNlIGVuZC10by1lbmQg Y29ubmVjdGl2aXR5IGNhbiBuZXZlciBiZSBhc3N1bWVkLFxyXG5cdCAgZW5kLXRvLWVuZCBjb252 ZXJzYXRpb25hbCBkYXRhIGV4Y2hhbmdlIGNhbiBuZXZlciBiZSBhc3N1bWVkIHRvXHJcblx0ICBj b21wbGV0ZSBpbiBhIHRpbWVseSBtYW5uZXI7IHByb3RvY29sIGZlYXR1cmVzIHRoYXQgcmVseSBv blxyXG5cdCAgdGltZWx5IGNvbnZlcnNhdGlvbmFsIGRhdGEgZXhjaGFuZ2UgbXVzdCBiZSBleGNs dWRlZCBmcm9tIHRoZVxyXG5cdCAgYXJjaGl0ZWN0dXJlLlxyXG5cclxuICAgICAgVGhlIERUTldH IGJlbGlldmVzIHRoYXQgcHJvdG9jb2xzIGFkaGVyaW5nIHRvIHRoZXNlIHByaW5jaXBsZXMgb2Zm ZXJcclxuICAgICAgb3Bwb3J0dW5pdGllcyBmb3IgZW5oYW5jaW5nIHRoZSBmdW5jdGlvbmFsaXR5 IG9mIHRoZSBJbnRlcm5ldCAtIGluXHJcbiAgICAgIHBhcnRpY3VsYXIsIGZvciBmYWNpbGl0YXRp bmcgdGhlIGV4dGVuc2lvbiBvZiB0aGUgSW50ZXJuZXQgaW50b1xyXG4gICAgICBlbnZpcm9ubWVu dHMgc3VjaCBhcyB0aGUgb2NlYW4gZmxvb3IgYW5kIGRlZXAgc3BhY2UgaW4gd2hpY2ggdGhlIGNv cmVcclxuICAgICAgSW50ZXJuZXQgcHJvdG9jb2xzIG9wZXJhdGUgc3ViLW9wdGltYWxseSBmb3Ig dGhlIHJlYXNvbnMgZGlzY3Vzc2VkXHJcbiAgICAgIGVhcmxpZXIuICBXZSBiZWxpZXZlIHRoYXQg dGhlIGV4dGVuc2l2ZSByZXNlYXJjaCwgZGVtb25zdHJhdGlvbiwgYW5kXHJcbiAgICAgIHBpbG90 IG9wZXJhdGlvbnMgcGVyZm9ybWVkIHRvIGRhdGUgdXNpbmcgdGhlIERUTlJHIHByb3RvY29scyBw cm92aWRlc1xyXG4gICAgICBhIGZpcm0gYmFzaXMgZm9yIHB1Ymxpc2hpbmcgSW50ZXJuZXQgc3Rh bmRhcmRzIGRlcml2ZWQgZnJvbSB0aGF0IHdvcmsuXHJcblxyXG4gICAgICBXb3JrIGl0ZW1zIHJl bGF0ZWQgdG8gRGVsYXkvRGlzcnVwdGlvbiBUb2xlcmFudCBOZXR3b3JraW5nIGluY2x1ZGU6XHJc blxyXG4gICAgICBvIEEgbWVjaGFuaXNtIGZvciB0aGUgZXhjaGFuZ2Ugb2YgcHJvdG9jb2wgZGF0 YSB1bml0cywgdGVybWVkXHJcblx0ImJ1bmRsZXMiLCB0aGF0IGFyZSBkZXNpZ25lZCB0byBvYnZp YXRlIGNvbnZlcnNhdGlvbmFsIGNvbW11bmljYXRpb25zXHJcblx0YnkgY29udGFpbmluZyB2YWx1 ZXMgZm9yIGFsbCBwb3RlbnRpYWxseSByZWxldmFudCBjb25maWd1cmF0aW9uXHJcblx0cGFyYW1l dGVycy4gIFRoZXNlIHByb3RvY29sIGRhdGEgdW5pdHMgYXJlIHR5cGljYWxseSBsYXJnZXIgdGhh blxyXG5cdG5ldHdvcmstbGF5ZXIgcGFja2V0cy4gV2Ugd2lsbCBkZXJpdmUgdGhpcyBidW5kbGUg ZXhjaGFuZ2UgbWVjaGFuaXNtXHJcbiAgICAgICAgZnJvbSB0aGUgRFROIEJ1bmRsZSBQcm90b2Nv bCAoQlApIGRvY3VtZW50ZWQgaW4gUkZDIDUwNTAgYnkgcHVibGlzaGluZ1xyXG4gICAgICAgIGEg bmV3IGRvY3VtZW50IFsyXSwgd2hlcmUgYXBwZW5kaXggQSBhbmQgQiBwcm92aWRlIGFuIHVwZGF0 ZSBzdW1tYXJ5LlxyXG5cclxuICAgICAgbyBBIHNlY3VyaXR5IHByb3RvY29sIGZvciBlbnN1cmlu ZyB0aGF0IHRoZSBuZXR3b3JrIGluIHdoaWNoIGJ1bmRsZXNcclxuXHRhcmUgZXhjaGFuZ2VkIGlz IHNlY3VyZWQgYWdhaW5zdCB1bmF1dGhvcml6ZWQgYWNjZXNzIGFuZCBkZW5pYWwgb2ZcclxuXHRz ZXJ2aWNlIGF0dGFja3MsIGFuZCB0byBlbnN1cmUgZGF0YSBpbnRlZ3JpdHkgYW5kIGNvbmZpZGVu dGlhbGl0eVxyXG5cdGluIHRoYXQgbmV0d29yayB3aGVyZSBuZWNlc3NhcnkuICBXZSB3aWxsIGRl cml2ZSB0aGlzIHNlY3VyaXR5XHJcblx0cHJvdG9jb2wgZnJvbSBhICJzdHJlYW1saW5lZCIgYWRh cHRhdGlvbiBvZiB0aGUgRFROIEJ1bmRsZSBTZWN1cml0eVxyXG5cdFByb3RvY29sIGRvY3VtZW50 ZWQgaW4gUkZDIDYyNTcuXHJcblxyXG4gICAgICBvIEFuIGVuY2Fwc3VsYXRpb24gcHJvdG9jb2wg Zm9yICJ0dW5uZWxpbmciIEJQIHRyYWZmaWMgd2l0aGluIGJ1bmRsZXNcclxuXHR0aGF0IGFyZSBz ZWN1cmVkIGFuZC9vciByb3V0ZWQgaW4gZGlmZmVyZW50IHdheSBmcm9tIHRoZSBlbmNhcHN1bGF0 ZWRcclxuXHRidW5kbGVzLlxyXG5cclxuICAgICAgbyBBIGRlbGF5LXRvbGVyYW50IHNlY3VyaXR5 IGtleSBtYW5hZ2VtZW50IHNjaGVtZSBmb3IgZW5zdXJpbmcgdGhhdFxyXG5cdHB1YmxpYyBrZXlz IGFyZSBjZXJ0aWZpZWQgYnkgYSBnbG9iYWxseSB0cnVzdGVkIGF1dGhvcml0eSB0byBwcm90ZWN0 XHJcblx0dGhlIGludGVncml0eSBvZiB0aGUgaW5mcmFzdHJ1Y3R1cmUuXHJcblxyXG4gICAgICBv IEEgc2ltcGxlIGRhdGFncmFtIGNvbnZlcmdlbmNlIGxheWVyIHByb3RvY29sIGZvciBhZGFwdGF0 aW9uIG9mIHRoZVxyXG4gICAgICAgIGJ1bmRsZSBwcm90b2NvbCB0byB1bmRlcmx5aW5nIGludGVy bmV0d29ya3MuIFdlIGV4cGVjdCB0byBkZXJpdmVcclxuICAgICAgICB0aGlzIGNvbnZlcmdlbmNl IGxheWVyIHByb3RvY29sIGZyb20gdGhlIERhdGFncmFtIENvbnZlcmdlbmNlXHJcbiAgICAgICAg cHJvdG9jb2wgZG9jdW1lbnRlZCBpbiBSRkMgNzEyMi5cclxuXHJcbiAgICAgIG8gQSBkZWxheS10 b2xlcmFudCBuZXR3b3JrIG1hbmFnZW1lbnQgcHJvdG9jb2wgZm9yIG1hbmFnZW1lbnQgb2YgdGhl XHJcbiAgICAgICAgaW5mcmFzdHJ1Y3R1cmUgaW4gdGhlIHByZXNlbmNlIG9mIGxvbmcgZGVsYXlz IGFuZC9vciBpbnRlcm1pdHRlbnRcclxuICAgICAgICBjb25uZWN0aXZpdHkuXHJcblxyXG4gICAg ICBvIEEgcmVnaXN0cnkgZm9yIERUTiBTZXJ2aWNlIElkZW50aWZpZXJzXHJcbiAgXHJcbiAgICBU aGUgd29ya2luZyBncm91cCB3aWxsIGNvbnNpZGVyIGV4dGVuZGluZyB0aGUgY3VycmVudCBtaWxl c3RvbmVzIGJhc2VkIG9uXHJcbiAgICBuZXcgaW5mb3JtYXRpb24gYW5kIGtub3dsZWRnZSBnYWlu ZWQgd2hpbGUgd29ya2luZyBvbiB0aGUgaW5pdGlhbCBjaGFydGVyLFxyXG4gICAgYXMgd2VsbCBh cyB0byBhY2NvbW1vZGF0ZSBuZXcgd29yayBpdGVtcyBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoZSBp bml0aWFsXHJcbiAgICBwaGFzZS4gIEZvciBleGFtcGxlLCB3ZSBleHBlY3QgdGhhdCB0cmFuc3Bv cnQgcHJvdG9jb2xzIHN1Y2ggYXMgTFRQIGFuZFxyXG4gICAgdGhlIFNhcmF0b2dhIHByb3RvY29s IGFyZSBhbW9uZyB0aGUgY2FuZGlkYXRlcyBmb3Igd29yayBpbiB0aGlzIHBoYXNlLlxyXG4gICAg XHJcbkdvYWxzIGFuZCBNaWxlc3RvbmVzOlxyXG4gIHN0YXJ0KzNtb3MgLSBTdWJtaXQgXCdCdW5k bGUgUHJvdG9jb2wgU3BlY2lmaWNhdGlvbiAoUkZDNTA1MGJpcylcJyBhcyBhXHJcbiAgICAgICAg ICAgICAgIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuIFRvIGJlIFByb3Bvc2VkIFN0YW5kYXJkLlxy XG4gIFN0YXJ0KzNtb3MgLSBTdWJtaXQgXCdTdHJlYW1saW5lZCBCdW5kbGUgU2VjdXJpdHkgUHJv dG9jb2wgKFNCU1ApXCcgYXMgYVxyXG4gICAgICAgICAgICAgICB3b3JraW5nIGdyb3VwIGRvY3Vt ZW50LiBUbyBiZSBQcm9wb3NlZCBTdGFuZGFyZC5cclxuICBzdGFydCs2bW9zIC0gU3VibWl0IFwn QnVuZGxlIEluIEJ1bmRsZSBFbmNhcHN1bGF0aW9uIChCSUJFKVwnIGFzIGEgd29ya2luZ1xyXG4g ICAgICAgICAgICAgICBncm91cCBkb2N1bWVudC4gVG8gYmUgUHJvcG9zZWQgU3RhbmRhcmQuXHJc biAgc3RhcnQrMTJtb3MgLSBTdWJtaXQgXCdEZWxheSBUb2xlcmFudCBOZXR3b3JraW5nIFNlY3Vy aXR5IEtleSBNYW5hZ2VtZW50XCcgYXNcclxuICAgICAgICAgICAgICAgIGEgd29ya2luZyBncm91 cCBkb2N1bWVudC4gVG8gYmUgUHJvcG9zZWQgU3RhbmRhcmQuXHJcbiAgc3RhcnQrMThtb3MgLSBX RyBkZXRlcm1pbmF0aW9uIGZvciBtZXJnaW5nIFJGQzUwNTBiaXMsIFNCU1AsIEJJQkUgYW5kL29y XHJcbiAgICAgICAgICAgICAgICBLZXkgTWdtdCBpbnRvIGEgY29tYmluZWQgZHJhZnQgb3Iga2Vl cCBhcyBzZXBhcmF0ZSBkcmFmdHMuXHJcbiAgc3RhcnQrMThtb3MgLSBTdWJtaXQgUkZDNTA1MGJp cywgU0JTUCwgQklCRSBhbmQgS2V5IE1nbXQgdG8gdGhlIElFU0cgZWl0aGVyXHJcbiAgICAgICAg ICAgICAgICBhcyBhIGNvbWJpbmVkIGRyYWZ0IG9yIGFzIHNlcGFyYXRlIGRyYWZ0cy5cclxuICBz dGFydCsxOG1vcyAtIFN1Ym1pdCBOZXR3b3JrIE1hbmFnZW1lbnQsIFJlZ2lzdHJ5IGFuZCBTaW1w bGUgQ29udmVyZ2VuY2VcclxuICAgICAgICAgICAgICAgIExheWVyIGFzIHdvcmtpbmcgZ3JvdXAg ZG9jdW1lbnRzLlxyXG4gIHN0YXJ0KzIwbW9zIC0gU3VydmV5IGFwcHJvcHJpYXRlIGZvcnVtcyAo ZS5nLiwgRFROUkcpIGZvciBlbWVyZ2luZ1xyXG4gICAgICAgICAgICAgICAgdGVjaG5vbG9naWVz IChlLmcuLCBjb252ZXJnZW5jZSBsYXllciBwcm90b2NvbHMsIGR5bmFtaWNcclxuICAgICAgICAg ICAgICAgIHJvdXRpbmcgcHJvdG9jb2xzLCBuYW1pbmcgYW5kIGFkZHJlc3Npbmcgc2VydmljZXMs IGV0Yy4pXHJcbiAgICAgICAgICAgICAgICByZWFkeSBmb3IgdHJhbnNpdGlvbiBpbnRvIElFVEYg RFROIFdvcmtpbmcgR3JvdXAuIFB1Ymxpc2hcclxuICAgICAgICAgICAgICAgIGRyYWZ0IG9uIHN1 cnZleSByZXN1bHRzIGFzIGluZGVwZW5kZW50IHN1Ym1pc3Npb24gcmVsYXRlZFxyXG4gICAgICAg ICAgICAgICAgdG8gdGhlIFdHLlxyXG4gIHN0YXJ0KzI0bW9zIC0gU3VibWl0IE5ldHdvcmsgTWFu YWdlbWVudCwgUmVnaXN0cnkgYW5kIFNpbXBsZSBDb252ZXJnZW5jZVxyXG4gICAgICAgICAgICAg ICAgTGF5ZXIgdG8gSUVTR1xyXG4gIHN0YXJ0KzI0bW9zIC0gUmVjaGFydGVyIHRvIGFjY29tbW9k YXRlIG5ldyB3b3JrIGl0ZW1zIG9yIGNsb3NlIFdvcmtpbmcgR3JvdXBcclxuXHJcblxyXG5bMV0g IkJQL0xUUCBkZXBsb3ltZW50IG9uIEVQT1hJIHNwYWNlY3JhZnQiIFsyMDA4XVxyXG5bMl0gIlBy b3Bvc2VkIFJldmlzZWQgQnVuZGxlIFByb3RvY29sIiBbMjAxNF0sXHJcbiAgICBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1idXJsZWlnaC1icHY3L1xyXG4nLCAnZmlsZW5h bWUxJzogJ0RyYWZ0IEJvRiBBZ2VuZGEgKDIuNWhycyk6XHJcbioqKioqKioqKioqKioqKioqKioq KioqKioqXHJcbjEpIFByb2JsZW0gc3RhdGVtZW50IChJRVRGIHdnIG1vdGl2YXRpb24pIC0gMzBt aW5cclxuXHJcbjIpIFJGQzUwNTAoYmlzKSAtIDE1bWluXHJcblxyXG4zKSBTdHJlYW1saW5lZCBC dW5kbGUgU2VjdXJpdHkgUHJvdG9jb2wgKFNCU1ApIC0gMTVtaW5cclxuXHJcbjQpIEJ1bmRsZS1p bi1CdW5kbGUgRW5jYXBzdWxhdGlvbiAtIDEwbWluXHJcblxyXG41KSBTZWN1cml0eSBLZXkgTWFu YWdlbWVudCAtIDEwbWluXHJcblxyXG42KSBSZWdpc3RyeSBmb3IgU2VydmljZSBJZGVudGlmaWVy cyAtIDEwbWluXHJcblxyXG43KSBOZXR3b3JrIE1hbmFnZW1lbnQgLSAxMG1pblxyXG5cclxuOCkg T3BlbiBEaXNjdXNzaW9uIC0gNTBtaW5cclxuXHJcblxyXG5Qcm9wb3NlZCB3b3JraW5nIGdyb3Vw IGNoYXJ0ZXI6XHJcbioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKipcclxuV29ya2luZyBn cm91cCBuYW1lOiBcclxuXHJcbiAgICAgIERlbGF5L0Rpc3J1cHRpb24gVG9sZXJhbnQgTmV0d29y a2luZyBXb3JraW5nIEdyb3VwIChEVE5XRylcclxuXHJcbkNoYWlyKHMpOlxyXG5cclxuICAgICAg VEJEXHJcblxyXG5BcmVhIGFuZCBBcmVhIERpcmVjdG9yKHMpOlxyXG5cclxuICAgICAgVHJhbnNw b3J0IEFyZWE6IEFEcyBTcGVuY2VyIERhd2tpbnMgX3NwZW5jZXJkYXdraW5zLmlldGYgYXQgZ21h aWwuY29tXyxcclxuICAgICAgICAgICAgICAgICAgICAgICAgICBNYXJ0aW4gU3RpZW1lcmxpbmcg X21scy5pZXRmIGF0IGdtYWlsLmNvbV9cclxuXHJcblJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3I6 XHJcblxyXG4gICAgICBUQkRcclxuXHJcbk1haWxpbmcgbGlzdDpcclxuXHJcbiAgICAgIEdlbmVy YWwgRGlzY3Vzc2lvbjogZHRuIGF0IGlldGYub3JnXHJcbiAgICAgIFRvIFN1YnNjcmliZTogaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kdG5cclxuICAgICAgQXJjaGl2ZTog aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2R0bi9jdXJyZW50L21haWxsaXN0 Lmh0bWxcclxuXHJcbkRlc2NyaXB0aW9uIG9mIFdvcmtpbmcgR3JvdXA6XHJcblxyXG4gICAgICBU aGUgRGVsYXkvRGlzcnVwdGlvbiBUb2xlcmFudCBOZXR3b3JrIFdvcmtpbmcgR3JvdXAgKERUTldH KSBzcGVjaWZpZXNcclxuICAgICAgbWVjaGFuaXNtcyBmb3IgZGF0YSBjb21tdW5pY2F0aW9ucyBp biB0aGUgcHJlc2VuY2Ugb2YgbG9uZyBkZWxheXNcclxuICAgICAgYW5kL29yIGludGVybWl0dGVu dCBjb25uZWN0aXZpdHkuIFRoZSB3b3JrIGlzIG1vdGl2YXRlZCBieSB3ZWxsIGtub3duXHJcbiAg ICAgIGxpbWl0YXRpb25zIG9mIHN0YW5kYXJkIEludGVybmV0IHByb3RvY29scyB0aGF0IGV4cGVj dCBlbmQtdG8tZW5kXHJcbiAgICAgIGNvbm5lY3Rpdml0eSBiZXR3ZWVuIGNvbW11bmljYXRpbmcg ZW5kcG9pbnRzLCBzdWItc2Vjb25kIHRyYW5zbWlzc2lvblxyXG4gICAgICBkZWxheXMgYW5kIHJv YnVzdCBwYWNrZXQgZGVsaXZlcnkgcmF0aW9zLiBJbiBlbnZpcm9ubWVudHMgd2hlcmUgdGhlc2Vc clxuICAgICAgZmF2b3JhYmxlIGNvbmRpdGlvbnMgZG8gbm90IGFwcGx5LCBleGlzdGluZyBtZWNo YW5pc21zIHN1Y2ggYXMgcmVsaWFibGVcclxuICAgICAgdHJhbnNwb3J0IHByb3RvY29scyBhbmQg cm91dGluZyBwcm90b2NvbHMgY2FuIGZhaWwgdG8gY29udmVyZ2UgcmVzdWx0aW5nXHJcbiAgICAg IGluIGNvbW11bmljYXRpb24gZmFpbHVyZXMuIEZ1cnRoZXJtb3JlLCBjbGFzc2ljYWwgZW5kLXRv LWVuZCBzZWN1cml0eVxyXG4gICAgICBhc3NvY2lhdGlvbnMgY2Fubm90IGJlIGNvb3JkaW5hdGVk IHdoZW4gY29tbXVuaWNhdGluZyBlbmRwb2ludHMgY2Fubm90XHJcbiAgICAgIGNvbmR1Y3QgbXVs dGktbWVzc2FnZSBrZXlpbmcgZXhjaGFuZ2VzIGluIGEgdGltZWx5IGZhc2hpb24uIFRoZXNlXHJc biAgICAgIGxpbWl0YXRpb25zIHN1Z2dlc3QgdGhlIG5lZWQgZm9yIGEgbmV3IGFwcHJvYWNoLiBc clxuICAgICAgXHJcbiAgICAgIERlbGF5LVRvbGVyYW50IE5ldHdvcmtpbmcgKERUTikgcHJvdG9j b2xzIGhhdmUgYmVlbiB0aGUgc3ViamVjdCBvZlxyXG4gICAgICBleHRlbnNpdmUgcmVzZWFyY2gg YW5kIGRldmVsb3BtZW50IGluIHRoZSBEZWxheS1Ub2xlcmFudCBOZXR3b3JraW5nXHJcbiAgICAg IFJlc2VhcmNoIEdyb3VwIG9mIHRoZSBJbnRlcm5ldCBSZXNlYXJjaCBUYXNrIEZvcmNlIHNpbmNl IDIwMDIuICBJblxyXG4gICAgICBwYXJ0aWN1bGFyLCB0aGUgRFROIEJ1bmRsZSBQcm90b2NvbCAo UkZDIDUwNTApIGFuZCBMaWNrbGlkZXJcclxuICAgICAgVHJhbnNtaXNzaW9uIFByb3RvY29sIChS RkMgNTMyNikgaGF2ZSBiZWVuIHNob3duIHRvIGFkZHJlc3MgdGhlXHJcbiAgICAgIGlzc3VlcyBp ZGVudGlmaWVkIGFib3ZlIGluIHN1YnN0YW50aWFsIGZpZWxkZWQgZGVwbG95bWVudHMgWzFdLlxy XG5cclxuICAgICAgVGhlIHN1Y2Nlc3Mgb2YgdGhlIEJQL0xUUCBwcm90b2NvbCBzdGFjayAtLSB0 aGUgY29yZSBwcm90b2NvbHMgb2YgdGhlXHJcbiAgICAgICJEVE4gQXJjaGl0ZWN0dXJlIiBvcmln aW5hbGx5IGRlc2NyaWJlZCBpbiBSRkMgNDgzOCAtLSBtYXkgYmUgYXR0cmlidXRlZFxyXG4gICAg ICB0byB0aGUgZm9sbG93aW5nIGZ1bmRhbWVudGFsIGRlc2lnbiBwcmluY2lwbGVzOlxyXG5cclxu XHQtIFRoZXJlIGlzIG5ldmVyIGFueSBleHBlY3RhdGlvbiBvZiBjb250ZW1wb3JhbmVvdXMgZW5k LXRvLWVuZFxyXG4gICAgICAgICAgY29ubmVjdGl2aXR5IGJldHdlZW4gYW55IHR3byBuZXR3b3Jr IG5vZGVzLlxyXG5cclxuXHQtIEJlY2F1c2UgZW5kLXRvLWVuZCBjb25uZWN0aXZpdHkgY2FuIG5l dmVyIGJlIGFzc3VtZWQsIGVhY2ggbm9kZVxyXG5cdCAgb24gdGhlIHBhdGggYmV0d2VlbiBzb3Vy Y2UgYW5kIGRlc3RpbmF0aW9uIG11c3QgYmUgcHJlcGFyZWQgdG9cclxuXHQgIGhhbmRsZSBpbmNv bWluZyAiYnVuZGxlcyIgb2YgZGF0YSB0aGF0IGNhbm5vdCBpbW1lZGlhdGVseSBiZVxyXG5cdCAg Zm9yd2FyZGVkLlxyXG5cclxuXHQtIEFnYWluIGJlY2F1c2UgZW5kLXRvLWVuZCBjb25uZWN0aXZp dHkgY2FuIG5ldmVyIGJlIGFzc3VtZWQsXHJcblx0ICBlbmQtdG8tZW5kIGNvbnZlcnNhdGlvbmFs IGRhdGEgZXhjaGFuZ2UgY2FuIG5ldmVyIGJlIGFzc3VtZWQgdG9cclxuXHQgIGNvbXBsZXRlIGlu IGEgdGltZWx5IG1hbm5lcjsgcHJvdG9jb2wgZmVhdHVyZXMgdGhhdCByZWx5IG9uXHJcblx0ICB0 aW1lbHkgY29udmVyc2F0aW9uYWwgZGF0YSBleGNoYW5nZSBtdXN0IGJlIGV4Y2x1ZGVkIGZyb20g dGhlXHJcblx0ICBhcmNoaXRlY3R1cmUuXHJcblxyXG4gICAgICBUaGUgRFROV0cgYmVsaWV2ZXMg dGhhdCBwcm90b2NvbHMgYWRoZXJpbmcgdG8gdGhlc2UgcHJpbmNpcGxlcyBvZmZlclxyXG4gICAg ICBvcHBvcnR1bml0aWVzIGZvciBlbmhhbmNpbmcgdGhlIGZ1bmN0aW9uYWxpdHkgb2YgdGhlIElu dGVybmV0IC0gaW5cclxuICAgICAgcGFydGljdWxhciwgZm9yIGZhY2lsaXRhdGluZyB0aGUgZXh0 ZW5zaW9uIG9mIHRoZSBJbnRlcm5ldCBpbnRvXHJcbiAgICAgIGVudmlyb25tZW50cyBzdWNoIGFz IHRoZSBvY2VhbiBmbG9vciBhbmQgZGVlcCBzcGFjZSBpbiB3aGljaCB0aGUgY29yZVxyXG4gICAg ICBJbnRlcm5ldCBwcm90b2NvbHMgb3BlcmF0ZSBzdWItb3B0aW1hbGx5IGZvciB0aGUgcmVhc29u cyBkaXNjdXNzZWRcclxuICAgICAgZWFybGllci4gIFdlIGJlbGlldmUgdGhhdCB0aGUgZXh0ZW5z aXZlIHJlc2VhcmNoLCBkZW1vbnN0cmF0aW9uLCBhbmRcclxuICAgICAgcGlsb3Qgb3BlcmF0aW9u cyBwZXJmb3JtZWQgdG8gZGF0ZSB1c2luZyB0aGUgRFROUkcgcHJvdG9jb2xzIHByb3ZpZGVzXHJc biAgICAgIGEgZmlybSBiYXNpcyBmb3IgcHVibGlzaGluZyBJbnRlcm5ldCBzdGFuZGFyZHMgZGVy aXZlZCBmcm9tIHRoYXQgd29yay5cclxuXHJcbiAgICAgIFdvcmsgaXRlbXMgcmVsYXRlZCB0byBE ZWxheS9EaXNydXB0aW9uIFRvbGVyYW50IE5ldHdvcmtpbmcgaW5jbHVkZTpcclxuXHJcbiAgICAg IG8gQSBtZWNoYW5pc20gZm9yIHRoZSBleGNoYW5nZSBvZiBwcm90b2NvbCBkYXRhIHVuaXRzLCB0 ZXJtZWRcclxuXHQiYnVuZGxlcyIsIHRoYXQgYXJlIGRlc2lnbmVkIHRvIG9idmlhdGUgY29udmVy c2F0aW9uYWwgY29tbXVuaWNhdGlvbnNcclxuXHRieSBjb250YWluaW5nIHZhbHVlcyBmb3IgYWxs IHBvdGVudGlhbGx5IHJlbGV2YW50IGNvbmZpZ3VyYXRpb25cclxuXHRwYXJhbWV0ZXJzLiAgVGhl c2UgcHJvdG9jb2wgZGF0YSB1bml0cyBhcmUgdHlwaWNhbGx5IGxhcmdlciB0aGFuXHJcblx0bmV0 d29yay1sYXllciBwYWNrZXRzLiAgV2Ugd2lsbCBkZXJpdmUgdGhpcyBidW5kbGUgZXhjaGFuZ2Ug bWVjaGFuaXNtXHJcbiAgICAgICAgZnJvbSB0aGUgRFROIEJ1bmRsZSBQcm90b2NvbCAoQlApIGRv Y3VtZW50ZWQgaW4gUkZDIDUwNTAuIENoYW5nZXMgZnJvbVxyXG4gICAgICAgIFJGQyA1MDUwIHdp bGwgYXBwZWFyIGluIGEgc29vbi10by1iZS1wdWJsaXNoZWQgUkZDIDUwNTAoYmlzKS5cclxuXHJc biAgICAgIG8gQSBzZWN1cml0eSBwcm90b2NvbCBmb3IgZW5zdXJpbmcgdGhhdCB0aGUgbmV0d29y ayBpbiB3aGljaCBidW5kbGVzXHJcblx0YXJlIGV4Y2hhbmdlZCBpcyBzZWN1cmVkIGFnYWluc3Qg dW5hdXRob3JpemVkIGFjY2VzcyBhbmQgZGVuaWFsIG9mXHJcblx0c2VydmljZSBhdHRhY2tzLCBh bmQgdG8gZW5zdXJlIGRhdGEgaW50ZWdyaXR5IGFuZCBjb25maWRlbnRpYWxpdHlcclxuXHRpbiB0 aGF0IG5ldHdvcmsgd2hlcmUgbmVjZXNzYXJ5LiAgV2Ugd2lsbCBkZXJpdmUgdGhpcyBzZWN1cml0 eVxyXG5cdHByb3RvY29sIGZyb20gYSAic3RyZWFtbGluZWQiIGFkYXB0YXRpb24gb2YgdGhlIERU TiBCdW5kbGUgU2VjdXJpdHlcclxuXHRQcm90b2NvbCBkb2N1bWVudGVkIGluIFJGQyA2MjU3Llxy XG5cclxuICAgICAgbyBBbiBlbmNhcHN1bGF0aW9uIHByb3RvY29sIGZvciAidHVubmVsaW5nIiBC UCB0cmFmZmljIHdpdGhpbiBidW5kbGVzXHJcblx0dGhhdCBhcmUgc2VjdXJlZCBhbmQvb3Igcm91 dGVkIGluIGRpZmZlcmVudCB3YXkgZnJvbSB0aGUgZW5jYXBzdWxhdGVkXHJcblx0YnVuZGxlcy5c clxuXHJcbiAgICAgIG8gQSBkZWxheS10b2xlcmFudCBzZWN1cml0eSBrZXkgbWFuYWdlbWVudCBz Y2hlbWUgZm9yIGVuc3VyaW5nIHRoYXRcclxuXHRwdWJsaWMga2V5cyBhcmUgY2VydGlmaWVkIGJ5 IGEgZ2xvYmFsbHkgdHJ1c3RlZCBhdXRob3JpdHkgdG8gcHJvdGVjdFxyXG5cdHRoZSBpbnRlZ3Jp dHkgb2YgdGhlIGluZnJhc3RydWN0dXJlLlxyXG5cclxuICAgICAgbyBBIHNpbXBsZSBkYXRhZ3Jh bSBjb252ZXJnZW5jZSBsYXllciBwcm90b2NvbCBmb3IgYWRhcHRhdGlvbiBvZiB0aGVcclxuICAg ICAgICBidW5kbGUgcHJvdG9jb2wgdG8gdW5kZXJseWluZyBpbnRlcm5ldHdvcmtzLiBXZSBleHBl Y3QgdG8gZGVyaXZlXHJcbiAgICAgICAgdGhpcyBjb252ZXJnZW5jZSBsYXllciBwcm90b2NvbCBm cm9tIHRoZSBEYXRhZ3JhbSBDb252ZXJnZW5jZVxyXG4gICAgICAgIHByb3RvY29sIGRvY3VtZW50 ZWQgaW4gUkZDIDcxMjIuXHJcblxyXG4gICAgICBvIEEgZGVsYXktdG9sZXJhbnQgbmV0d29yayBt YW5hZ2VtZW50IHByb3RvY29sIGZvciBtYW5hZ2VtZW50IG9mIHRoZVxyXG4gICAgICAgIGluZnJh c3RydWN0dXJlIGluIHRoZSBwcmVzZW5jZSBvZiBsb25nIGRlbGF5cyBhbmQvb3IgaW50ZXJtaXR0 ZW50XHJcbiAgICAgICAgY29ubmVjdGl2aXR5LlxyXG5cclxuICAgICAgbyBBIHJlZ2lzdHJ5IGZv ciBEVE4gU2VydmljZSBJZGVudGlmaWVyc1xyXG4gIFxyXG4gICAgVGhlIHdvcmtpbmcgZ3JvdXAg d2lsbCBjb25zaWRlciBleHRlbmRpbmcgdGhlIGN1cnJlbnQgbWlsZXN0b25lcyBiYXNlZCBvblxy XG4gICAgbmV3IGluZm9ybWF0aW9uIGFuZCBrbm93bGVkZ2UgZ2FpbmVkIHdoaWxlIHdvcmtpbmcg b24gdGhlIGluaXRpYWwgY2hhcnRlcixcclxuICAgIGFzIHdlbGwgYXMgdG8gYWNjb21tb2RhdGUg bmV3IHdvcmsgaXRlbXMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGUgaW5pdGlhbFxyXG4gICAgcGhh c2UuICBGb3IgZXhhbXBsZSwgd2UgZXhwZWN0IHRoYXQgdHJhbnNwb3J0IHByb3RvY29scyBzdWNo IGFzIExUUCBhbmRcclxuICAgIHRoZSBTYXJhdG9nYSBwcm90b2NvbCBhcmUgYW1vbmcgdGhlIGNh bmRpZGF0ZXMgZm9yIHdvcmsgaW4gdGhpcyBwaGFzZS5cclxuICAgIFxyXG5Hb2FscyBhbmQgTWls ZXN0b25lczpcclxuICBzdGFydCszbW9zIC0gU3VibWl0IFwnQnVuZGxlIFByb3RvY29sIFNwZWNp ZmljYXRpb24gKFJGQzUwNTBiaXMpXCcgYXMgYVxyXG4gICAgICAgICAgICAgICB3b3JraW5nIGdy b3VwIGRvY3VtZW50LiBUbyBiZSBQcm9wb3NlZCBTdGFuZGFyZC5cclxuICBTdGFydCszbW9zIC0g U3VibWl0IFwnU3RyZWFtbGluZWQgQnVuZGxlIFNlY3VyaXR5IFByb3RvY29sIChTQlNQKVwnIGFz IGFcclxuICAgICAgICAgICAgICAgd29ya2luZyBncm91cCBkb2N1bWVudC4gVG8gYmUgUHJvcG9z ZWQgU3RhbmRhcmQuXHJcbiAgc3RhcnQrNm1vcyAtIFN1Ym1pdCBcJ0J1bmRsZSBJbiBCdW5kbGUg RW5jYXBzdWxhdGlvbiAoQklCRSlcJyBhcyBhIHdvcmtpbmdcclxuICAgICAgICAgICAgICAgZ3Jv dXAgZG9jdW1lbnQuIFRvIGJlIFByb3Bvc2VkIFN0YW5kYXJkLlxyXG4gIHN0YXJ0KzEybW9zIC0g U3VibWl0IFwnRGVsYXkgVG9sZXJhbnQgTmV0d29ya2luZyBTZWN1cml0eSBLZXkgTWFuYWdlbWVu dFwnIGFzXHJcbiAgICAgICAgICAgICAgICBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuIFRvIGJl IFByb3Bvc2VkIFN0YW5kYXJkLlxyXG4gIHN0YXJ0KzE4bW9zIC0gV0cgZGV0ZXJtaW5hdGlvbiBm b3IgbWVyZ2luZyBSRkM1MDUwYmlzLCBTQlNQLCBCSUJFIGFuZC9vclxyXG4gICAgICAgICAgICAg ICAgS2V5IE1nbXQgaW50byBhIGNvbWJpbmVkIGRyYWZ0IG9yIGtlZXAgYXMgc2VwYXJhdGUgZHJh ZnRzLlxyXG4gIHN0YXJ0KzE4bW9zIC0gU3VibWl0IFJGQzUwNTBiaXMsIFNCU1AsIEJJQkUgYW5k IEtleSBNZ210IHRvIHRoZSBJRVNHIGVpdGhlclxyXG4gICAgICAgICAgICAgICAgYXMgYSBjb21i aW5lZCBkcmFmdCBvciBhcyBzZXBhcmF0ZSBkcmFmdHMuXHJcbiAgc3RhcnQrMThtb3MgLSBTdWJt aXQgTmV0d29yayBNYW5hZ2VtZW50LCBSZWdpc3RyeSBhbmQgU2ltcGxlIENvbnZlcmdlbmNlXHJc biAgICAgICAgICAgICAgICBMYXllciBhcyB3b3JraW5nIGdyb3VwIGRvY3VtZW50cy5cclxuICBz dGFydCsyMG1vcyAtIFN1cnZleSBhcHByb3ByaWF0ZSBmb3J1bXMgKGUuZy4sIERUTlJHKSBmb3Ig ZW1lcmdpbmdcclxuICAgICAgICAgICAgICAgIHRlY2hub2xvZ2llcyAoZS5nLiwgY29udmVyZ2Vu Y2UgbGF5ZXIgcHJvdG9jb2xzLCBkeW5hbWljXHJcbiAgICAgICAgICAgICAgICByb3V0aW5nIHBy b3RvY29scywgbmFtaW5nIGFuZCBhZGRyZXNzaW5nIHNlcnZpY2VzLCBldGMuKVxyXG4gICAgICAg ICAgICAgICAgcmVhZHkgZm9yIHRyYW5zaXRpb24gaW50byBJRVRGIERUTiBXb3JraW5nIEdyb3Vw LiBQdWJsaXNoXHJcbiAgICAgICAgICAgICAgICBkcmFmdCBvbiBzdXJ2ZXkgcmVzdWx0cyBhcyBp bmRlcGVuZGVudCBzdWJtaXNzaW9uIHJlbGF0ZWRcclxuICAgICAgICAgICAgICAgIHRvIHRoZSBX Ry5cclxuICBzdGFydCsyNG1vcyAtIFN1Ym1pdCBOZXR3b3JrIE1hbmFnZW1lbnQsIFJlZ2lzdHJ5 IGFuZCBTaW1wbGUgQ29udmVyZ2VuY2VcclxuICAgICAgICAgICAgICAgIExheWVyIHRvIElFU0dc clxuICBzdGFydCsyNG1vcyAtIFJlY2hhcnRlciB0byBhY2NvbW1vZGF0ZSBuZXcgd29yayBpdGVt cyBvciBjbG9zZSBXb3JraW5nIEdyb3VwXHJcblxyXG5cclxuWzFdIEJQL0xUUCBkZXBsb3ltZW50 IG9uIEVQT1hJIHNwYWNlY3JhZnQgWzIwMDhdXHJcbicsICd1cmwxJzogJycsICdzdWJtaXQnOiAn R2VuZXJhdGUgZGlmZicsICd1cmwyJzogJycsICctLW5ld2NvbG91cic6ICdncmVlbid9IC0tPg== --_002_2134F8430051B64F815C691A62D983181B2C05A4XCHBLV504nwnosb_-- From nobody Fri Jun 6 13:48:22 2014 Return-Path: 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 9B2341A0290 for ; Fri, 6 Jun 2014 13:48:17 -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 p18h3y657M5U for ; Fri, 6 Jun 2014 13:48:11 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.106]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 133481A0274 for ; Fri, 6 Jun 2014 13:48:11 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp01.jpl.nasa.gov [128.149.137.148]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s56Km1VJ028434 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Fri, 6 Jun 2014 13:48:02 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.217]) by ap-ehub-sp01.RES.AD.JPL ([169.254.3.182]) with mapi id 14.03.0174.001; Fri, 6 Jun 2014 13:48:01 -0700 From: "Burleigh, Scott C (312G)" To: "Templin, Fred L" , "dtn@ietf.org" Thread-Topic: [dtn] DTN BoF Proposal for IETF90 Thread-Index: Ac+AQa9Fez/CplZaSwyaLFpzb8tj0wAiVZ0AAAXfQWAADdLFAAAnSnygAAQYTsA= Date: Fri, 6 Jun 2014 20:48:00 +0000 Message-ID: References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2BF3F7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2BF96C@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2C05A4@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983181B2C05A4@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.114] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/YgLPNkZ0qk0UZmohzw9aPwrcNyc Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 20:48:17 -0000 Fred, a couple of suggested tweaks to the charter: - From "documented in RFC 5050 by publishing a new document [2], where appe= ndix A and B provide an update summary" to "documented in RFC 5050 by publi= shing a new document for which [2] is a proposed first draft (where appendi= x A provides a summary of the proposed changes)." - Maybe it would make the work plan look less challenging if other existing= Internet Drafts were cited? There are current I-Ds for SBSP and BIBE, at = least. Scott -----Original Message----- From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of Templin, Fred L Sent: Friday, June 06, 2014 11:44 AM To: dtn@ietf.org Subject: Re: [dtn] DTN BoF Proposal for IETF90 See below for updated charter with pointer to new doc (diffs attached). Thanks - Fred --- Draft BoF Agenda (2.5hrs): ************************** 1) Problem statement (IETF wg motivation) - 30min 2) RFC5050(bis) - 15min 3) Streamlined Bundle Security Protocol (SBSP) - 15min 4) Bundle-in-Bundle Encapsulation - 10min 5) Security Key Management - 10min 6) Registry for Service Identifiers - 10min 7) Network Management - 10min 8) Open Discussion - 50min Proposed working group charter: ******************************* Working group name:=20 Delay/Disruption Tolerant Networking Working Group (DTNWG) Chair(s): TBD Area and Area Director(s): Transport Area: ADs Spencer Dawkins , Martin Stiemerling Responsible Area Director: TBD Mailing list: General Discussion: dtn at ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dtn Archive: http://www.ietf.org/mail-archive/web/dtn/current/maillist.ht= ml Description of Working Group: The Delay/Disruption Tolerant Network Working Group (DTNWG) specifies mechanisms for data communications in the presence of long delays and/or intermittent connectivity. The work is motivated by well known limitations of standard Internet protocols that expect end-to-end connectivity between communicating endpoints, sub-second transmission delays and robust packet delivery ratios. In environments where these favorable conditions do not apply, existing mechanisms such as reliab= le transport protocols and routing protocols can fail to converge result= ing in communication failures. Furthermore, classical end-to-end security associations cannot be coordinated when communicating endpoints canno= t conduct multi-message keying exchanges in a timely fashion. These limitations suggest the need for a new approach.=20 =20 Delay-Tolerant Networking (DTN) protocols have been the subject of extensive research and development in the Delay-Tolerant Networking Research Group of the Internet Research Task Force since 2002. In particular, the DTN Bundle Protocol (RFC 5050) and Licklider Transmission Protocol (RFC 5326) have been shown to address the issues identified above in substantial fielded deployments [1]. The success of the BP/LTP protocol stack -- the core protocols of the "DTN Architecture" originally described in RFC 4838 -- may be attribu= ted to the following fundamental design principles: - There is never any expectation of contemporaneous end-to-end connectivity between any two network nodes. - Because end-to-end connectivity can never be assumed, each node on the path between source and destination must be prepared to handle incoming "bundles" of data that cannot immediately be forwarded. - Again because end-to-end connectivity can never be assumed, end-to-end conversational data exchange can never be assumed to complete in a timely manner; protocol features that rely on timely conversational data exchange must be excluded from the architecture. The DTNWG believes that protocols adhering to these principles offer opportunities for enhancing the functionality of the Internet - in particular, for facilitating the extension of the Internet into environments such as the ocean floor and deep space in which the core Internet protocols operate sub-optimally for the reasons discussed earlier. We believe that the extensive research, demonstration, and pilot operations performed to date using the DTNRG protocols provides a firm basis for publishing Internet standards derived from that work= . Work items related to Delay/Disruption Tolerant Networking include: o A mechanism for the exchange of protocol data units, termed "bundles", that are designed to obviate conversational communications by containing values for all potentially relevant configuration parameters. These protocol data units are typically larger than network-layer packets. We will derive this bundle exchange mechanism from the DTN Bundle Protocol (BP) documented in RFC 5050 by publish= ing a new document [2], where appendix A and B provide an update summar= y. o A security protocol for ensuring that the network in which bundles are exchanged is secured against unauthorized access and denial of service attacks, and to ensure data integrity and confidentiality in that network where necessary. We will derive this security protocol from a "streamlined" adaptation of the DTN Bundle Security Protocol documented in RFC 6257. o An encapsulation protocol for "tunneling" BP traffic within bundles that are secured and/or routed in different way from the encapsulated bundles. o A delay-tolerant security key management scheme for ensuring that public keys are certified by a globally trusted authority to protect the integrity of the infrastructure. o A simple datagram convergence layer protocol for adaptation of the bundle protocol to underlying internetworks. We expect to derive this convergence layer protocol from the Datagram Convergence protocol documented in RFC 7122. o A delay-tolerant network management protocol for management of the infrastructure in the presence of long delays and/or intermittent connectivity. o A registry for DTN Service Identifiers =20 The working group will consider extending the current milestones based = on new information and knowledge gained while working on the initial chart= er, as well as to accommodate new work items beyond the scope of the initia= l phase. For example, we expect that transport protocols such as LTP and the Saratoga protocol are among the candidates for work in this phase. =20 Goals and Milestones: start+3mos - Submit 'Bundle Protocol Specification (RFC5050bis)' as a working group document. To be Proposed Standard. Start+3mos - Submit 'Streamlined Bundle Security Protocol (SBSP)' as a working group document. To be Proposed Standard. start+6mos - Submit 'Bundle In Bundle Encapsulation (BIBE)' as a working group document. To be Proposed Standard. start+12mos - Submit 'Delay Tolerant Networking Security Key Management' = as a working group document. To be Proposed Standard. start+18mos - WG determination for merging RFC5050bis, SBSP, BIBE and/or Key Mgmt into a combined draft or keep as separate drafts. start+18mos - Submit RFC5050bis, SBSP, BIBE and Key Mgmt to the IESG eith= er as a combined draft or as separate drafts. start+18mos - Submit Network Management, Registry and Simple Convergence Layer as working group documents. start+20mos - Survey appropriate forums (e.g., DTNRG) for emerging technologies (e.g., convergence layer protocols, dynamic routing protocols, naming and addressing services, etc.) ready for transition into IETF DTN Working Group. Publish draft on survey results as independent submission related to the WG. start+24mos - Submit Network Management, Registry and Simple Convergence Layer to IESG start+24mos - Recharter to accommodate new work items or close Working Gr= oup [1] "BP/LTP deployment on EPOXI spacecraft" [2008] [2] "Proposed Revised Bu= ndle Protocol" [2014], https://datatracker.ietf.org/doc/draft-burleigh-bpv7/ From nobody Fri Jun 6 14:56:04 2014 Return-Path: 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 986281A02A9 for ; Fri, 6 Jun 2014 14:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.841 X-Spam-Level: X-Spam-Status: No, score=-4.841 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] 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 JOMi1HYapaU0 for ; Fri, 6 Jun 2014 14:55:59 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E50241A0273 for ; Fri, 6 Jun 2014 14:55:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s56LtpIB013637; Fri, 6 Jun 2014 14:55:51 -0700 Received: from XCH-PHX-209.sw.nos.boeing.com (xch-phx-209.sw.nos.boeing.com [130.247.25.29]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s56LtfFs013124 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 6 Jun 2014 14:55:42 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.105]) by XCH-PHX-209.sw.nos.boeing.com ([169.254.9.197]) with mapi id 14.03.0181.006; Fri, 6 Jun 2014 14:55:40 -0700 From: "Templin, Fred L" To: "Burleigh, Scott C (312G)" , "dtn@ietf.org" Thread-Topic: [dtn] DTN BoF Proposal for IETF90 Thread-Index: Ac+AQa9Fez/CplZaSwyaLFpzb8tj0wAiVZ0AAAXfQWAADdLFAAAnSnygAAQYTsAAApCFwA== Date: Fri, 6 Jun 2014 21:55:39 +0000 Message-ID: <2134F8430051B64F815C691A62D983181B2C0855@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2BF3F7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2BF96C@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2C05A4@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: multipart/mixed; boundary="_002_2134F8430051B64F815C691A62D983181B2C0855XCHBLV504nwnosb_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/ZsQTg7ZfLHGJJ9lBtttuW_mEmqo Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 21:56:02 -0000 --_002_2134F8430051B64F815C691A62D983181B2C0855XCHBLV504nwnosb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Scott, > Fred, a couple of suggested tweaks to the charter: Yes to both - see below for the update, plus attached diffs. Thanks - Fred fred.l.templin@boeing.com --- Draft BoF Agenda (2.5hrs): ************************** 1) Problem statement (IETF wg motivation) - 30min 2) RFC5050(bis) - 15min 3) Streamlined Bundle Security Protocol (SBSP) - 15min 4) Bundle-in-Bundle Encapsulation - 10min 5) Security Key Management - 10min 6) Registry for Service Identifiers - 10min 7) Network Management - 10min 8) Open Discussion - 50min Proposed working group charter: ******************************* Working group name:=20 Delay/Disruption Tolerant Networking Working Group (DTNWG) Chair(s): TBD Area and Area Director(s): Transport Area: ADs Spencer Dawkins , Martin Stiemerling Responsible Area Director: TBD Mailing list: General Discussion: dtn at ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dtn Archive: http://www.ietf.org/mail-archive/web/dtn/current/maillist.ht= ml Description of Working Group: The Delay/Disruption Tolerant Network Working Group (DTNWG) specifies mechanisms for data communications in the presence of long delays and/or intermittent connectivity. The work is motivated by well known limitations of standard Internet protocols that expect end-to-end connectivity between communicating endpoints, sub-second transmission delays and robust packet delivery ratios. In environments where these favorable conditions do not apply, existing mechanisms such as reliab= le transport protocols and routing protocols can fail to converge result= ing in communication failures. Furthermore, classical end-to-end security associations cannot be coordinated when communicating endpoints canno= t conduct multi-message keying exchanges in a timely fashion. These limitations suggest the need for a new approach.=20 =20 Delay-Tolerant Networking (DTN) protocols have been the subject of extensive research and development in the Delay-Tolerant Networking Research Group of the Internet Research Task Force since 2002. In particular, the DTN Bundle Protocol (RFC 5050) and Licklider Transmission Protocol (RFC 5326) have been shown to address the issues identified above in substantial fielded deployments [1]. The success of the BP/LTP protocol stack -- the core protocols of the "DTN Architecture" originally described in RFC 4838 -- may be attribu= ted to the following fundamental design principles: - There is never any expectation of contemporaneous end-to-end connectivity between any two network nodes. - Because end-to-end connectivity can never be assumed, each node on the path between source and destination must be prepared to handle incoming "bundles" of data that cannot immediately be forwarded. - Again because end-to-end connectivity can never be assumed, end-to-end conversational data exchange can never be assumed to complete in a timely manner; protocol features that rely on timely conversational data exchange must be excluded from the architecture. The DTNWG believes that protocols adhering to these principles offer opportunities for enhancing the functionality of the Internet - in particular, for facilitating the extension of the Internet into environments such as the ocean floor and deep space in which the core Internet protocols operate sub-optimally for the reasons discussed earlier. We believe that the extensive research, demonstration, and pilot operations performed to date using the DTNRG protocols provides a firm basis for publishing Internet standards derived from that work= . Work items related to Delay/Disruption Tolerant Networking include: o A mechanism for the exchange of protocol data units, termed "bundles", that are designed to obviate conversational communications by containing values for all potentially relevant configuration parameters. These protocol data units are typically larger than network-layer packets. We will derive this bundle exchange mechanism from the DTN Bundle Protocol (BP) documented in RFC 5050 by publish= ing a new document for which [2] is a proposed first draft (where appendix A provides a summary of the proposed changes). o A security protocol for ensuring that the network in which bundles are exchanged is secured against unauthorized access and denial of service attacks, and to ensure data integrity and confidentiality in that network where necessary. We will derive this security protocol from a "streamlined" adaptation of the DTN Bundle Security Protocol documented in RFC 6257. o An encapsulation protocol for "tunneling" BP traffic within bundles that are secured and/or routed in different way from the encapsulated bundles. o A delay-tolerant security key management scheme for ensuring that public keys are certified by a globally trusted authority to protect the integrity of the infrastructure. o A simple datagram convergence layer protocol for adaptation of the bundle protocol to underlying internetworks. We expect to derive this convergence layer protocol from the Datagram Convergence protocol documented in RFC 7122. o A delay-tolerant network management protocol for management of the infrastructure in the presence of long delays and/or intermittent connectivity. o A registry for DTN Service Identifiers =20 The working group will consider extending the current milestones based = on new information and knowledge gained while working on the initial chart= er, as well as to accommodate new work items beyond the scope of the initia= l phase. For example, we expect that transport protocols such as LTP and the Saratoga protocol are among the candidates for work in this phase. =20 Goals and Milestones: start+3mos - Submit 'Bundle Protocol Specification (RFC5050bis)' as a working group document [2]. To be Proposed Standard. Start+3mos - Submit 'Streamlined Bundle Security Protocol (SBSP)' as a working group document [3]. To be Proposed Standard. start+6mos - Submit 'Bundle In Bundle Encapsulation (BIBE)' as a working group document [4]. To be Proposed Standard. start+12mos - Submit 'Delay Tolerant Networking Security Key Management' = as a working group document. To be Proposed Standard. start+18mos - WG determination for merging RFC5050bis, SBSP, BIBE and/or Key Mgmt into a combined draft or keep as separate drafts. start+18mos - Submit RFC5050bis, SBSP, BIBE and Key Mgmt to the IESG eith= er as a combined draft or as separate drafts. start+18mos - Submit Network Management [5], Registry [6] and Simple Convergence Layer [7] as working group documents. start+20mos - Survey appropriate forums (e.g., DTNRG) for emerging technologies (e.g., convergence layer protocols, dynamic routing protocols, naming and addressing services, etc.) ready for transition into IETF DTN Working Group. Publish draft on survey results as independent submission related to the WG. start+24mos - Submit Network Management, Registry and Simple Convergence Layer to IESG start+24mos - Recharter to accommodate new work items or close Working Gr= oup [1] "BP/LTP deployment on EPOXI spacecraft" [2008], http://committees.comsoc.org/tccc/ccw/2010/slides/DINET_CCW.pdf =20 [2] "Proposed Revised Bundle Protocol" [2014], https://datatracker.ietf.org/doc/draft-burleigh-bpv7/ [3] "Streamlined Bundle Security Protocol Specification" [2014], https://datatracker.ietf.org/doc/draft-irtf-dtnrg-sbsp/ [4] "Bundle-in-Bundle Encapsulation" [2013], http://tools.ietf.org/id/draft-irtf-burleigh-bibe [5] "Delay Tolerant Network Management Protocol" [2013], http://tools.ietf.org/id/draft-irtf-dtnrg-dtnmp [6] "Delay-Tolerant Networking Bundle Protocol IANA Registries" [2011], https://datatracker.ietf.org/doc/rfc6255/ [7] "Datagram Convergence Layers ..." [2014], https://datatracker.ietf.org/doc/rfc7122/ --_002_2134F8430051B64F815C691A62D983181B2C0855XCHBLV504nwnosb_ Content-Type: text/html; name="wdiff 03a_txt 04a_txt.htm" Content-Description: wdiff 03a_txt 04a_txt.htm Content-Disposition: attachment; filename="wdiff 03a_txt 04a_txt.htm"; size=26411; creation-date="Fri, 06 Jun 2014 21:54:31 GMT"; modification-date="Fri, 06 Jun 2014 21:54:31 GMT" Content-Transfer-Encoding: base64 CjxodG1sPjxoZWFkPjx0aXRsZT53ZGlmZiAwM2EudHh0IDA0YS50eHQ8L3RpdGxlPjwvaGVhZD48 Ym9keT4KPHByZT4KRHJhZnQgQm9GIEFnZW5kYSAoMi41aHJzKToKKioqKioqKioqKioqKioqKioq KioqKioqKioKMSkgUHJvYmxlbSBzdGF0ZW1lbnQgKElFVEYgd2cgbW90aXZhdGlvbikgLSAzMG1p bgoKMikgUkZDNTA1MChiaXMpIC0gMTVtaW4KCjMpIFN0cmVhbWxpbmVkIEJ1bmRsZSBTZWN1cml0 eSBQcm90b2NvbCAoU0JTUCkgLSAxNW1pbgoKNCkgQnVuZGxlLWluLUJ1bmRsZSBFbmNhcHN1bGF0 aW9uIC0gMTBtaW4KCjUpIFNlY3VyaXR5IEtleSBNYW5hZ2VtZW50IC0gMTBtaW4KCjYpIFJlZ2lz dHJ5IGZvciBTZXJ2aWNlIElkZW50aWZpZXJzIC0gMTBtaW4KCjcpIE5ldHdvcmsgTWFuYWdlbWVu dCAtIDEwbWluCgo4KSBPcGVuIERpc2N1c3Npb24gLSA1MG1pbgoKUHJvcG9zZWQgd29ya2luZyBn cm91cCBjaGFydGVyOgoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCldvcmtpbmcgZ3Jv dXAgbmFtZToKCiAgICAgIERlbGF5L0Rpc3J1cHRpb24gVG9sZXJhbnQgTmV0d29ya2luZyBXb3Jr aW5nIEdyb3VwIChEVE5XRykKCkNoYWlyKHMpOgoKICAgICAgVEJECgpBcmVhIGFuZCBBcmVhIERp cmVjdG9yKHMpOgoKICAgICAgVHJhbnNwb3J0IEFyZWE6IEFEcyBTcGVuY2VyIERhd2tpbnMgJmx0 O3NwZW5jZXJkYXdraW5zLmlldGYgYXQgZ21haWwuY29tJmd0OywKICAgICAgICAgICAgICAgICAg ICAgICAgICBNYXJ0aW4gU3RpZW1lcmxpbmcgJmx0O21scy5pZXRmIGF0IGdtYWlsLmNvbSZndDsK ClJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3I6CgogICAgICBUQkQKCk1haWxpbmcgbGlzdDoKCiAg ICAgIEdlbmVyYWwgRGlzY3Vzc2lvbjogZHRuIGF0IGlldGYub3JnCiAgICAgIFRvIFN1YnNjcmli ZTogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kdG4KICAgICAgQXJjaGl2 ZTogaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2R0bi9jdXJyZW50L21haWxs aXN0Lmh0bWwKCkRlc2NyaXB0aW9uIG9mIFdvcmtpbmcgR3JvdXA6CgogICAgICBUaGUgRGVsYXkv RGlzcnVwdGlvbiBUb2xlcmFudCBOZXR3b3JrIFdvcmtpbmcgR3JvdXAgKERUTldHKSBzcGVjaWZp ZXMKICAgICAgbWVjaGFuaXNtcyBmb3IgZGF0YSBjb21tdW5pY2F0aW9ucyBpbiB0aGUgcHJlc2Vu Y2Ugb2YgbG9uZyBkZWxheXMKICAgICAgYW5kL29yIGludGVybWl0dGVudCBjb25uZWN0aXZpdHku IFRoZSB3b3JrIGlzIG1vdGl2YXRlZCBieSB3ZWxsIGtub3duCiAgICAgIGxpbWl0YXRpb25zIG9m IHN0YW5kYXJkIEludGVybmV0IHByb3RvY29scyB0aGF0IGV4cGVjdCBlbmQtdG8tZW5kCiAgICAg IGNvbm5lY3Rpdml0eSBiZXR3ZWVuIGNvbW11bmljYXRpbmcgZW5kcG9pbnRzLCBzdWItc2Vjb25k IHRyYW5zbWlzc2lvbgogICAgICBkZWxheXMgYW5kIHJvYnVzdCBwYWNrZXQgZGVsaXZlcnkgcmF0 aW9zLiBJbiBlbnZpcm9ubWVudHMgd2hlcmUgdGhlc2UKICAgICAgZmF2b3JhYmxlIGNvbmRpdGlv bnMgZG8gbm90IGFwcGx5LCBleGlzdGluZyBtZWNoYW5pc21zIHN1Y2ggYXMgcmVsaWFibGUKICAg ICAgdHJhbnNwb3J0IHByb3RvY29scyBhbmQgcm91dGluZyBwcm90b2NvbHMgY2FuIGZhaWwgdG8g Y29udmVyZ2UgcmVzdWx0aW5nCiAgICAgIGluIGNvbW11bmljYXRpb24gZmFpbHVyZXMuIEZ1cnRo ZXJtb3JlLCBjbGFzc2ljYWwgZW5kLXRvLWVuZCBzZWN1cml0eQogICAgICBhc3NvY2lhdGlvbnMg Y2Fubm90IGJlIGNvb3JkaW5hdGVkIHdoZW4gY29tbXVuaWNhdGluZyBlbmRwb2ludHMgY2Fubm90 CiAgICAgIGNvbmR1Y3QgbXVsdGktbWVzc2FnZSBrZXlpbmcgZXhjaGFuZ2VzIGluIGEgdGltZWx5 IGZhc2hpb24uIFRoZXNlCiAgICAgIGxpbWl0YXRpb25zIHN1Z2dlc3QgdGhlIG5lZWQgZm9yIGEg bmV3IGFwcHJvYWNoLgoKICAgICAgRGVsYXktVG9sZXJhbnQgTmV0d29ya2luZyAoRFROKSBwcm90 b2NvbHMgaGF2ZSBiZWVuIHRoZSBzdWJqZWN0IG9mCiAgICAgIGV4dGVuc2l2ZSByZXNlYXJjaCBh bmQgZGV2ZWxvcG1lbnQgaW4gdGhlIERlbGF5LVRvbGVyYW50IE5ldHdvcmtpbmcKICAgICAgUmVz ZWFyY2ggR3JvdXAgb2YgdGhlIEludGVybmV0IFJlc2VhcmNoIFRhc2sgRm9yY2Ugc2luY2UgMjAw Mi4gIEluCiAgICAgIHBhcnRpY3VsYXIsIHRoZSBEVE4gQnVuZGxlIFByb3RvY29sIChSRkMgNTA1 MCkgYW5kIExpY2tsaWRlcgogICAgICBUcmFuc21pc3Npb24gUHJvdG9jb2wgKFJGQyA1MzI2KSBo YXZlIGJlZW4gc2hvd24gdG8gYWRkcmVzcyB0aGUKICAgICAgaXNzdWVzIGlkZW50aWZpZWQgYWJv dmUgaW4gc3Vic3RhbnRpYWwgZmllbGRlZCBkZXBsb3ltZW50cyBbMV0uCgogICAgICBUaGUgc3Vj Y2VzcyBvZiB0aGUgQlAvTFRQIHByb3RvY29sIHN0YWNrIC0tIHRoZSBjb3JlIHByb3RvY29scyBv ZiB0aGUKICAgICAgIkRUTiBBcmNoaXRlY3R1cmUiIG9yaWdpbmFsbHkgZGVzY3JpYmVkIGluIFJG QyA0ODM4IC0tIG1heSBiZSBhdHRyaWJ1dGVkCiAgICAgIHRvIHRoZSBmb2xsb3dpbmcgZnVuZGFt ZW50YWwgZGVzaWduIHByaW5jaXBsZXM6CgoJLSBUaGVyZSBpcyBuZXZlciBhbnkgZXhwZWN0YXRp b24gb2YgY29udGVtcG9yYW5lb3VzIGVuZC10by1lbmQKICAgICAgICAgIGNvbm5lY3Rpdml0eSBi ZXR3ZWVuIGFueSB0d28gbmV0d29yayBub2Rlcy4KCgktIEJlY2F1c2UgZW5kLXRvLWVuZCBjb25u ZWN0aXZpdHkgY2FuIG5ldmVyIGJlIGFzc3VtZWQsIGVhY2ggbm9kZQoJICBvbiB0aGUgcGF0aCBi ZXR3ZWVuIHNvdXJjZSBhbmQgZGVzdGluYXRpb24gbXVzdCBiZSBwcmVwYXJlZCB0bwoJICBoYW5k bGUgaW5jb21pbmcgImJ1bmRsZXMiIG9mIGRhdGEgdGhhdCBjYW5ub3QgaW1tZWRpYXRlbHkgYmUK CSAgZm9yd2FyZGVkLgoKCS0gQWdhaW4gYmVjYXVzZSBlbmQtdG8tZW5kIGNvbm5lY3Rpdml0eSBj YW4gbmV2ZXIgYmUgYXNzdW1lZCwKCSAgZW5kLXRvLWVuZCBjb252ZXJzYXRpb25hbCBkYXRhIGV4 Y2hhbmdlIGNhbiBuZXZlciBiZSBhc3N1bWVkIHRvCgkgIGNvbXBsZXRlIGluIGEgdGltZWx5IG1h bm5lcjsgcHJvdG9jb2wgZmVhdHVyZXMgdGhhdCByZWx5IG9uCgkgIHRpbWVseSBjb252ZXJzYXRp b25hbCBkYXRhIGV4Y2hhbmdlIG11c3QgYmUgZXhjbHVkZWQgZnJvbSB0aGUKCSAgYXJjaGl0ZWN0 dXJlLgoKICAgICAgVGhlIERUTldHIGJlbGlldmVzIHRoYXQgcHJvdG9jb2xzIGFkaGVyaW5nIHRv IHRoZXNlIHByaW5jaXBsZXMgb2ZmZXIKICAgICAgb3Bwb3J0dW5pdGllcyBmb3IgZW5oYW5jaW5n IHRoZSBmdW5jdGlvbmFsaXR5IG9mIHRoZSBJbnRlcm5ldCAtIGluCiAgICAgIHBhcnRpY3VsYXIs IGZvciBmYWNpbGl0YXRpbmcgdGhlIGV4dGVuc2lvbiBvZiB0aGUgSW50ZXJuZXQgaW50bwogICAg ICBlbnZpcm9ubWVudHMgc3VjaCBhcyB0aGUgb2NlYW4gZmxvb3IgYW5kIGRlZXAgc3BhY2UgaW4g d2hpY2ggdGhlIGNvcmUKICAgICAgSW50ZXJuZXQgcHJvdG9jb2xzIG9wZXJhdGUgc3ViLW9wdGlt YWxseSBmb3IgdGhlIHJlYXNvbnMgZGlzY3Vzc2VkCiAgICAgIGVhcmxpZXIuICBXZSBiZWxpZXZl IHRoYXQgdGhlIGV4dGVuc2l2ZSByZXNlYXJjaCwgZGVtb25zdHJhdGlvbiwgYW5kCiAgICAgIHBp bG90IG9wZXJhdGlvbnMgcGVyZm9ybWVkIHRvIGRhdGUgdXNpbmcgdGhlIERUTlJHIHByb3RvY29s cyBwcm92aWRlcwogICAgICBhIGZpcm0gYmFzaXMgZm9yIHB1Ymxpc2hpbmcgSW50ZXJuZXQgc3Rh bmRhcmRzIGRlcml2ZWQgZnJvbSB0aGF0IHdvcmsuCgogICAgICBXb3JrIGl0ZW1zIHJlbGF0ZWQg dG8gRGVsYXkvRGlzcnVwdGlvbiBUb2xlcmFudCBOZXR3b3JraW5nIGluY2x1ZGU6CgogICAgICBv IEEgbWVjaGFuaXNtIGZvciB0aGUgZXhjaGFuZ2Ugb2YgcHJvdG9jb2wgZGF0YSB1bml0cywgdGVy bWVkCgkiYnVuZGxlcyIsIHRoYXQgYXJlIGRlc2lnbmVkIHRvIG9idmlhdGUgY29udmVyc2F0aW9u YWwgY29tbXVuaWNhdGlvbnMKCWJ5IGNvbnRhaW5pbmcgdmFsdWVzIGZvciBhbGwgcG90ZW50aWFs bHkgcmVsZXZhbnQgY29uZmlndXJhdGlvbgoJcGFyYW1ldGVycy4gIFRoZXNlIHByb3RvY29sIGRh dGEgdW5pdHMgYXJlIHR5cGljYWxseSBsYXJnZXIgdGhhbgoJbmV0d29yay1sYXllciBwYWNrZXRz LiBXZSB3aWxsIGRlcml2ZSB0aGlzIGJ1bmRsZSBleGNoYW5nZSBtZWNoYW5pc20KICAgICAgICBm cm9tIHRoZSBEVE4gQnVuZGxlIFByb3RvY29sIChCUCkgZG9jdW1lbnRlZCBpbiBSRkMgNTA1MCBi eSBwdWJsaXNoaW5nCiAgICAgICAgYSBuZXcgZG9jdW1lbnQgPHN0cmlrZT48Zm9udCBjb2xvcj0n cmVkJyA+WzJdLCB3aGVyZTwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3Jl ZW4nID5mb3Igd2hpY2ggWzJdIGlzIGEgcHJvcG9zZWQgZmlyc3QgZHJhZnQgKHdoZXJlPC9mb250 Pjwvc3Ryb25nPgogICAgICAgIGFwcGVuZGl4IEEgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJyA+ YW5kIEIgcHJvdmlkZSBhbiB1cGRhdGUgc3VtbWFyeS48L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+ PGZvbnQgY29sb3I9J2dyZWVuJyA+cHJvdmlkZXMgYSBzdW1tYXJ5IG9mIHRoZSBwcm9wb3NlZCBj aGFuZ2VzKS48L2ZvbnQ+PC9zdHJvbmc+CgogICAgICBvIEEgc2VjdXJpdHkgcHJvdG9jb2wgZm9y IGVuc3VyaW5nIHRoYXQgdGhlIG5ldHdvcmsgaW4gd2hpY2ggYnVuZGxlcwoJYXJlIGV4Y2hhbmdl ZCBpcyBzZWN1cmVkIGFnYWluc3QgdW5hdXRob3JpemVkIGFjY2VzcyBhbmQgZGVuaWFsIG9mCglz ZXJ2aWNlIGF0dGFja3MsIGFuZCB0byBlbnN1cmUgZGF0YSBpbnRlZ3JpdHkgYW5kIGNvbmZpZGVu dGlhbGl0eQoJaW4gdGhhdCBuZXR3b3JrIHdoZXJlIG5lY2Vzc2FyeS4gIFdlIHdpbGwgZGVyaXZl IHRoaXMgc2VjdXJpdHkKCXByb3RvY29sIGZyb20gYSAic3RyZWFtbGluZWQiIGFkYXB0YXRpb24g b2YgdGhlIERUTiBCdW5kbGUgU2VjdXJpdHkKCVByb3RvY29sIGRvY3VtZW50ZWQgaW4gUkZDIDYy NTcuCgogICAgICBvIEFuIGVuY2Fwc3VsYXRpb24gcHJvdG9jb2wgZm9yICJ0dW5uZWxpbmciIEJQ IHRyYWZmaWMgd2l0aGluIGJ1bmRsZXMKCXRoYXQgYXJlIHNlY3VyZWQgYW5kL29yIHJvdXRlZCBp biBkaWZmZXJlbnQgd2F5IGZyb20gdGhlIGVuY2Fwc3VsYXRlZAoJYnVuZGxlcy4KCiAgICAgIG8g QSBkZWxheS10b2xlcmFudCBzZWN1cml0eSBrZXkgbWFuYWdlbWVudCBzY2hlbWUgZm9yIGVuc3Vy aW5nIHRoYXQKCXB1YmxpYyBrZXlzIGFyZSBjZXJ0aWZpZWQgYnkgYSBnbG9iYWxseSB0cnVzdGVk IGF1dGhvcml0eSB0byBwcm90ZWN0Cgl0aGUgaW50ZWdyaXR5IG9mIHRoZSBpbmZyYXN0cnVjdHVy ZS4KCiAgICAgIG8gQSBzaW1wbGUgZGF0YWdyYW0gY29udmVyZ2VuY2UgbGF5ZXIgcHJvdG9jb2wg Zm9yIGFkYXB0YXRpb24gb2YgdGhlCiAgICAgICAgYnVuZGxlIHByb3RvY29sIHRvIHVuZGVybHlp bmcgaW50ZXJuZXR3b3Jrcy4gV2UgZXhwZWN0IHRvIGRlcml2ZQogICAgICAgIHRoaXMgY29udmVy Z2VuY2UgbGF5ZXIgcHJvdG9jb2wgZnJvbSB0aGUgRGF0YWdyYW0gQ29udmVyZ2VuY2UKICAgICAg ICBwcm90b2NvbCBkb2N1bWVudGVkIGluIFJGQyA3MTIyLgoKICAgICAgbyBBIGRlbGF5LXRvbGVy YW50IG5ldHdvcmsgbWFuYWdlbWVudCBwcm90b2NvbCBmb3IgbWFuYWdlbWVudCBvZiB0aGUKICAg ICAgICBpbmZyYXN0cnVjdHVyZSBpbiB0aGUgcHJlc2VuY2Ugb2YgbG9uZyBkZWxheXMgYW5kL29y IGludGVybWl0dGVudAogICAgICAgIGNvbm5lY3Rpdml0eS4KCiAgICAgIG8gQSByZWdpc3RyeSBm b3IgRFROIFNlcnZpY2UgSWRlbnRpZmllcnMKCiAgICBUaGUgd29ya2luZyBncm91cCB3aWxsIGNv bnNpZGVyIGV4dGVuZGluZyB0aGUgY3VycmVudCBtaWxlc3RvbmVzIGJhc2VkIG9uCiAgICBuZXcg aW5mb3JtYXRpb24gYW5kIGtub3dsZWRnZSBnYWluZWQgd2hpbGUgd29ya2luZyBvbiB0aGUgaW5p dGlhbCBjaGFydGVyLAogICAgYXMgd2VsbCBhcyB0byBhY2NvbW1vZGF0ZSBuZXcgd29yayBpdGVt cyBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoZSBpbml0aWFsCiAgICBwaGFzZS4gIEZvciBleGFtcGxl LCB3ZSBleHBlY3QgdGhhdCB0cmFuc3BvcnQgcHJvdG9jb2xzIHN1Y2ggYXMgTFRQIGFuZAogICAg dGhlIFNhcmF0b2dhIHByb3RvY29sIGFyZSBhbW9uZyB0aGUgY2FuZGlkYXRlcyBmb3Igd29yayBp biB0aGlzIHBoYXNlLgoKR29hbHMgYW5kIE1pbGVzdG9uZXM6CiAgc3RhcnQrM21vcyAtIFN1Ym1p dCAnQnVuZGxlIFByb3RvY29sIFNwZWNpZmljYXRpb24gKFJGQzUwNTBiaXMpJyBhcyBhCiAgICAg ICAgICAgICAgIHdvcmtpbmcgZ3JvdXAgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJyA+ZG9jdW1l bnQuPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicgPmRvY3VtZW50 IFsyXS48L2ZvbnQ+PC9zdHJvbmc+IFRvIGJlIFByb3Bvc2VkIFN0YW5kYXJkLgogIFN0YXJ0KzNt b3MgLSBTdWJtaXQgJ1N0cmVhbWxpbmVkIEJ1bmRsZSBTZWN1cml0eSBQcm90b2NvbCAoU0JTUCkn IGFzIGEKICAgICAgICAgICAgICAgd29ya2luZyBncm91cCA8c3RyaWtlPjxmb250IGNvbG9yPSdy ZWQnID5kb2N1bWVudC48L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVu JyA+ZG9jdW1lbnQgWzNdLjwvZm9udD48L3N0cm9uZz4gVG8gYmUgUHJvcG9zZWQgU3RhbmRhcmQu CiAgc3RhcnQrNm1vcyAtIFN1Ym1pdCAnQnVuZGxlIEluIEJ1bmRsZSBFbmNhcHN1bGF0aW9uIChC SUJFKScgYXMgYSB3b3JraW5nCiAgICAgICAgICAgICAgIGdyb3VwIDxzdHJpa2U+PGZvbnQgY29s b3I9J3JlZCcgPmRvY3VtZW50LjwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0n Z3JlZW4nID5kb2N1bWVudCBbNF0uPC9mb250Pjwvc3Ryb25nPiBUbyBiZSBQcm9wb3NlZCBTdGFu ZGFyZC4KICBzdGFydCsxMm1vcyAtIFN1Ym1pdCAnRGVsYXkgVG9sZXJhbnQgTmV0d29ya2luZyBT ZWN1cml0eSBLZXkgTWFuYWdlbWVudCcgYXMKICAgICAgICAgICAgICAgIGEgd29ya2luZyBncm91 cCBkb2N1bWVudC4gVG8gYmUgUHJvcG9zZWQgU3RhbmRhcmQuCiAgc3RhcnQrMThtb3MgLSBXRyBk ZXRlcm1pbmF0aW9uIGZvciBtZXJnaW5nIFJGQzUwNTBiaXMsIFNCU1AsIEJJQkUgYW5kL29yCiAg ICAgICAgICAgICAgICBLZXkgTWdtdCBpbnRvIGEgY29tYmluZWQgZHJhZnQgb3Iga2VlcCBhcyBz ZXBhcmF0ZSBkcmFmdHMuCiAgc3RhcnQrMThtb3MgLSBTdWJtaXQgUkZDNTA1MGJpcywgU0JTUCwg QklCRSBhbmQgS2V5IE1nbXQgdG8gdGhlIElFU0cgZWl0aGVyCiAgICAgICAgICAgICAgICBhcyBh IGNvbWJpbmVkIGRyYWZ0IG9yIGFzIHNlcGFyYXRlIGRyYWZ0cy4KICBzdGFydCsxOG1vcyAtIFN1 Ym1pdCBOZXR3b3JrIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCcgPk1hbmFnZW1lbnQsPC9mb250 Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicgPk1hbmFnZW1lbnQgWzVdLDwv Zm9udD48L3N0cm9uZz4gUmVnaXN0cnkgPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nID5bNl08 L2ZvbnQ+PC9zdHJvbmc+IGFuZCBTaW1wbGUKICAgICAgICAgICAgICAgIENvbnZlcmdlbmNlIExh eWVyIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJyA+WzddPC9mb250Pjwvc3Ryb25nPiBhcyB3 b3JraW5nIGdyb3VwIGRvY3VtZW50cy4KICBzdGFydCsyMG1vcyAtIFN1cnZleSBhcHByb3ByaWF0 ZSBmb3J1bXMgKGUuZy4sIERUTlJHKSBmb3IgZW1lcmdpbmcKICAgICAgICAgICAgICAgIHRlY2hu b2xvZ2llcyAoZS5nLiwgY29udmVyZ2VuY2UgbGF5ZXIgcHJvdG9jb2xzLCBkeW5hbWljCiAgICAg ICAgICAgICAgICByb3V0aW5nIHByb3RvY29scywgbmFtaW5nIGFuZCBhZGRyZXNzaW5nIHNlcnZp Y2VzLCBldGMuKQogICAgICAgICAgICAgICAgcmVhZHkgZm9yIHRyYW5zaXRpb24gaW50byBJRVRG IERUTiBXb3JraW5nIEdyb3VwLiBQdWJsaXNoCiAgICAgICAgICAgICAgICBkcmFmdCBvbiBzdXJ2 ZXkgcmVzdWx0cyBhcyBpbmRlcGVuZGVudCBzdWJtaXNzaW9uIHJlbGF0ZWQKICAgICAgICAgICAg ICAgIHRvIHRoZSBXRy4KICBzdGFydCsyNG1vcyAtIFN1Ym1pdCBOZXR3b3JrIE1hbmFnZW1lbnQs IFJlZ2lzdHJ5IGFuZCBTaW1wbGUgQ29udmVyZ2VuY2UKICAgICAgICAgICAgICAgIExheWVyIHRv IElFU0cKICBzdGFydCsyNG1vcyAtIFJlY2hhcnRlciB0byBhY2NvbW1vZGF0ZSBuZXcgd29yayBp dGVtcyBvciBjbG9zZSBXb3JraW5nIEdyb3VwCgpbMV0gIkJQL0xUUCBkZXBsb3ltZW50IG9uIEVQ T1hJIHNwYWNlY3JhZnQiIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCcgPlsyMDA4XTwvZm9udD48 L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nID5bMjAwOF0sCiAgICBodHRwOi8v Y29tbWl0dGVlcy5jb21zb2Mub3JnL3RjY2MvY2N3LzIwMTAvc2xpZGVzL0RJTkVUX0NDVy5wZGY8 L2ZvbnQ+PC9zdHJvbmc+ClsyXSAiUHJvcG9zZWQgUmV2aXNlZCBCdW5kbGUgUHJvdG9jb2wiIFsy MDE0XSwKICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJ1cmxlaWdo LWJwdjcvCjxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJyA+WzNdICJTdHJlYW1saW5lZCBCdW5k bGUgU2VjdXJpdHkgUHJvdG9jb2wgU3BlY2lmaWNhdGlvbiIgWzIwMTRdLAogICAgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaXJ0Zi1kdG5yZy1zYnNwLwpbNF0gIkJ1bmRs ZS1pbi1CdW5kbGUgRW5jYXBzdWxhdGlvbiIgWzIwMTNdLAogICAgaHR0cDovL3Rvb2xzLmlldGYu b3JnL2lkL2RyYWZ0LWlydGYtYnVybGVpZ2gtYmliZQpbNV0gIkRlbGF5IFRvbGVyYW50IE5ldHdv cmsgTWFuYWdlbWVudCBQcm90b2NvbCIgWzIwMTNdLAogICAgaHR0cDovL3Rvb2xzLmlldGYub3Jn L2lkL2RyYWZ0LWlydGYtZHRucmctZHRubXAKWzZdICJEZWxheS1Ub2xlcmFudCBOZXR3b3JraW5n IEJ1bmRsZSBQcm90b2NvbCBJQU5BIFJlZ2lzdHJpZXMiIFsyMDExXSwKICAgIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL3JmYzYyNTUvCls3XSAiRGF0YWdyYW0gQ29udmVyZ2VuY2Ug TGF5ZXJzIC4uLiIgWzIwMTRdLAogICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv cmZjNzEyMi88L2ZvbnQ+PC9zdHJvbmc+CjwvcHJlPgo8L2JvZHk+PC9odG1sPgpYLUdlbmVyYXRv cjogcHlodCAwLjM1Cgo8IS0tIGFyZ3M6IHsnLS1vbGRjb2xvdXInOiAncmVkJywgJy0td2lkdGgn OiAnJywgJ2RpZmZ0eXBlJzogJy0taHdkaWZmJywgJ2ZpbGVuYW1lMic6ICdEcmFmdCBCb0YgQWdl bmRhICgyLjVocnMpOlxyXG4qKioqKioqKioqKioqKioqKioqKioqKioqKlxyXG4xKSBQcm9ibGVt IHN0YXRlbWVudCAoSUVURiB3ZyBtb3RpdmF0aW9uKSAtIDMwbWluXHJcblxyXG4yKSBSRkM1MDUw KGJpcykgLSAxNW1pblxyXG5cclxuMykgU3RyZWFtbGluZWQgQnVuZGxlIFNlY3VyaXR5IFByb3Rv Y29sIChTQlNQKSAtIDE1bWluXHJcblxyXG40KSBCdW5kbGUtaW4tQnVuZGxlIEVuY2Fwc3VsYXRp b24gLSAxMG1pblxyXG5cclxuNSkgU2VjdXJpdHkgS2V5IE1hbmFnZW1lbnQgLSAxMG1pblxyXG5c clxuNikgUmVnaXN0cnkgZm9yIFNlcnZpY2UgSWRlbnRpZmllcnMgLSAxMG1pblxyXG5cclxuNykg TmV0d29yayBNYW5hZ2VtZW50IC0gMTBtaW5cclxuXHJcbjgpIE9wZW4gRGlzY3Vzc2lvbiAtIDUw bWluXHJcblxyXG5cclxuUHJvcG9zZWQgd29ya2luZyBncm91cCBjaGFydGVyOlxyXG4qKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqXHJcbldvcmtpbmcgZ3JvdXAgbmFtZTogXHJcblxyXG4g ICAgICBEZWxheS9EaXNydXB0aW9uIFRvbGVyYW50IE5ldHdvcmtpbmcgV29ya2luZyBHcm91cCAo RFROV0cpXHJcblxyXG5DaGFpcihzKTpcclxuXHJcbiAgICAgIFRCRFxyXG5cclxuQXJlYSBhbmQg QXJlYSBEaXJlY3RvcihzKTpcclxuXHJcbiAgICAgIFRyYW5zcG9ydCBBcmVhOiBBRHMgU3BlbmNl ciBEYXdraW5zIF9zcGVuY2VyZGF3a2lucy5pZXRmIGF0IGdtYWlsLmNvbV8sXHJcbiAgICAgICAg ICAgICAgICAgICAgICAgICAgTWFydGluIFN0aWVtZXJsaW5nIF9tbHMuaWV0ZiBhdCBnbWFpbC5j b21fXHJcblxyXG5SZXNwb25zaWJsZSBBcmVhIERpcmVjdG9yOlxyXG5cclxuICAgICAgVEJEXHJc blxyXG5NYWlsaW5nIGxpc3Q6XHJcblxyXG4gICAgICBHZW5lcmFsIERpc2N1c3Npb246IGR0biBh dCBpZXRmLm9yZ1xyXG4gICAgICBUbyBTdWJzY3JpYmU6IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZHRuXHJcbiAgICAgIEFyY2hpdmU6IGh0dHA6Ly93d3cuaWV0Zi5vcmcv bWFpbC1hcmNoaXZlL3dlYi9kdG4vY3VycmVudC9tYWlsbGlzdC5odG1sXHJcblxyXG5EZXNjcmlw dGlvbiBvZiBXb3JraW5nIEdyb3VwOlxyXG5cclxuICAgICAgVGhlIERlbGF5L0Rpc3J1cHRpb24g VG9sZXJhbnQgTmV0d29yayBXb3JraW5nIEdyb3VwIChEVE5XRykgc3BlY2lmaWVzXHJcbiAgICAg IG1lY2hhbmlzbXMgZm9yIGRhdGEgY29tbXVuaWNhdGlvbnMgaW4gdGhlIHByZXNlbmNlIG9mIGxv bmcgZGVsYXlzXHJcbiAgICAgIGFuZC9vciBpbnRlcm1pdHRlbnQgY29ubmVjdGl2aXR5LiBUaGUg d29yayBpcyBtb3RpdmF0ZWQgYnkgd2VsbCBrbm93blxyXG4gICAgICBsaW1pdGF0aW9ucyBvZiBz dGFuZGFyZCBJbnRlcm5ldCBwcm90b2NvbHMgdGhhdCBleHBlY3QgZW5kLXRvLWVuZFxyXG4gICAg ICBjb25uZWN0aXZpdHkgYmV0d2VlbiBjb21tdW5pY2F0aW5nIGVuZHBvaW50cywgc3ViLXNlY29u ZCB0cmFuc21pc3Npb25cclxuICAgICAgZGVsYXlzIGFuZCByb2J1c3QgcGFja2V0IGRlbGl2ZXJ5 IHJhdGlvcy4gSW4gZW52aXJvbm1lbnRzIHdoZXJlIHRoZXNlXHJcbiAgICAgIGZhdm9yYWJsZSBj b25kaXRpb25zIGRvIG5vdCBhcHBseSwgZXhpc3RpbmcgbWVjaGFuaXNtcyBzdWNoIGFzIHJlbGlh YmxlXHJcbiAgICAgIHRyYW5zcG9ydCBwcm90b2NvbHMgYW5kIHJvdXRpbmcgcHJvdG9jb2xzIGNh biBmYWlsIHRvIGNvbnZlcmdlIHJlc3VsdGluZ1xyXG4gICAgICBpbiBjb21tdW5pY2F0aW9uIGZh aWx1cmVzLiBGdXJ0aGVybW9yZSwgY2xhc3NpY2FsIGVuZC10by1lbmQgc2VjdXJpdHlcclxuICAg ICAgYXNzb2NpYXRpb25zIGNhbm5vdCBiZSBjb29yZGluYXRlZCB3aGVuIGNvbW11bmljYXRpbmcg ZW5kcG9pbnRzIGNhbm5vdFxyXG4gICAgICBjb25kdWN0IG11bHRpLW1lc3NhZ2Uga2V5aW5nIGV4 Y2hhbmdlcyBpbiBhIHRpbWVseSBmYXNoaW9uLiBUaGVzZVxyXG4gICAgICBsaW1pdGF0aW9ucyBz dWdnZXN0IHRoZSBuZWVkIGZvciBhIG5ldyBhcHByb2FjaC4gXHJcbiAgICAgIFxyXG4gICAgICBE ZWxheS1Ub2xlcmFudCBOZXR3b3JraW5nIChEVE4pIHByb3RvY29scyBoYXZlIGJlZW4gdGhlIHN1 YmplY3Qgb2ZcclxuICAgICAgZXh0ZW5zaXZlIHJlc2VhcmNoIGFuZCBkZXZlbG9wbWVudCBpbiB0 aGUgRGVsYXktVG9sZXJhbnQgTmV0d29ya2luZ1xyXG4gICAgICBSZXNlYXJjaCBHcm91cCBvZiB0 aGUgSW50ZXJuZXQgUmVzZWFyY2ggVGFzayBGb3JjZSBzaW5jZSAyMDAyLiAgSW5cclxuICAgICAg cGFydGljdWxhciwgdGhlIERUTiBCdW5kbGUgUHJvdG9jb2wgKFJGQyA1MDUwKSBhbmQgTGlja2xp ZGVyXHJcbiAgICAgIFRyYW5zbWlzc2lvbiBQcm90b2NvbCAoUkZDIDUzMjYpIGhhdmUgYmVlbiBz aG93biB0byBhZGRyZXNzIHRoZVxyXG4gICAgICBpc3N1ZXMgaWRlbnRpZmllZCBhYm92ZSBpbiBz dWJzdGFudGlhbCBmaWVsZGVkIGRlcGxveW1lbnRzIFsxXS5cclxuXHJcbiAgICAgIFRoZSBzdWNj ZXNzIG9mIHRoZSBCUC9MVFAgcHJvdG9jb2wgc3RhY2sgLS0gdGhlIGNvcmUgcHJvdG9jb2xzIG9m IHRoZVxyXG4gICAgICAiRFROIEFyY2hpdGVjdHVyZSIgb3JpZ2luYWxseSBkZXNjcmliZWQgaW4g UkZDIDQ4MzggLS0gbWF5IGJlIGF0dHJpYnV0ZWRcclxuICAgICAgdG8gdGhlIGZvbGxvd2luZyBm dW5kYW1lbnRhbCBkZXNpZ24gcHJpbmNpcGxlczpcclxuXHJcblx0LSBUaGVyZSBpcyBuZXZlciBh bnkgZXhwZWN0YXRpb24gb2YgY29udGVtcG9yYW5lb3VzIGVuZC10by1lbmRcclxuICAgICAgICAg IGNvbm5lY3Rpdml0eSBiZXR3ZWVuIGFueSB0d28gbmV0d29yayBub2Rlcy5cclxuXHJcblx0LSBC ZWNhdXNlIGVuZC10by1lbmQgY29ubmVjdGl2aXR5IGNhbiBuZXZlciBiZSBhc3N1bWVkLCBlYWNo IG5vZGVcclxuXHQgIG9uIHRoZSBwYXRoIGJldHdlZW4gc291cmNlIGFuZCBkZXN0aW5hdGlvbiBt dXN0IGJlIHByZXBhcmVkIHRvXHJcblx0ICBoYW5kbGUgaW5jb21pbmcgImJ1bmRsZXMiIG9mIGRh dGEgdGhhdCBjYW5ub3QgaW1tZWRpYXRlbHkgYmVcclxuXHQgIGZvcndhcmRlZC5cclxuXHJcblx0 LSBBZ2FpbiBiZWNhdXNlIGVuZC10by1lbmQgY29ubmVjdGl2aXR5IGNhbiBuZXZlciBiZSBhc3N1 bWVkLFxyXG5cdCAgZW5kLXRvLWVuZCBjb252ZXJzYXRpb25hbCBkYXRhIGV4Y2hhbmdlIGNhbiBu ZXZlciBiZSBhc3N1bWVkIHRvXHJcblx0ICBjb21wbGV0ZSBpbiBhIHRpbWVseSBtYW5uZXI7IHBy b3RvY29sIGZlYXR1cmVzIHRoYXQgcmVseSBvblxyXG5cdCAgdGltZWx5IGNvbnZlcnNhdGlvbmFs IGRhdGEgZXhjaGFuZ2UgbXVzdCBiZSBleGNsdWRlZCBmcm9tIHRoZVxyXG5cdCAgYXJjaGl0ZWN0 dXJlLlxyXG5cclxuICAgICAgVGhlIERUTldHIGJlbGlldmVzIHRoYXQgcHJvdG9jb2xzIGFkaGVy aW5nIHRvIHRoZXNlIHByaW5jaXBsZXMgb2ZmZXJcclxuICAgICAgb3Bwb3J0dW5pdGllcyBmb3Ig ZW5oYW5jaW5nIHRoZSBmdW5jdGlvbmFsaXR5IG9mIHRoZSBJbnRlcm5ldCAtIGluXHJcbiAgICAg IHBhcnRpY3VsYXIsIGZvciBmYWNpbGl0YXRpbmcgdGhlIGV4dGVuc2lvbiBvZiB0aGUgSW50ZXJu ZXQgaW50b1xyXG4gICAgICBlbnZpcm9ubWVudHMgc3VjaCBhcyB0aGUgb2NlYW4gZmxvb3IgYW5k IGRlZXAgc3BhY2UgaW4gd2hpY2ggdGhlIGNvcmVcclxuICAgICAgSW50ZXJuZXQgcHJvdG9jb2xz IG9wZXJhdGUgc3ViLW9wdGltYWxseSBmb3IgdGhlIHJlYXNvbnMgZGlzY3Vzc2VkXHJcbiAgICAg IGVhcmxpZXIuICBXZSBiZWxpZXZlIHRoYXQgdGhlIGV4dGVuc2l2ZSByZXNlYXJjaCwgZGVtb25z dHJhdGlvbiwgYW5kXHJcbiAgICAgIHBpbG90IG9wZXJhdGlvbnMgcGVyZm9ybWVkIHRvIGRhdGUg dXNpbmcgdGhlIERUTlJHIHByb3RvY29scyBwcm92aWRlc1xyXG4gICAgICBhIGZpcm0gYmFzaXMg Zm9yIHB1Ymxpc2hpbmcgSW50ZXJuZXQgc3RhbmRhcmRzIGRlcml2ZWQgZnJvbSB0aGF0IHdvcmsu XHJcblxyXG4gICAgICBXb3JrIGl0ZW1zIHJlbGF0ZWQgdG8gRGVsYXkvRGlzcnVwdGlvbiBUb2xl cmFudCBOZXR3b3JraW5nIGluY2x1ZGU6XHJcblxyXG4gICAgICBvIEEgbWVjaGFuaXNtIGZvciB0 aGUgZXhjaGFuZ2Ugb2YgcHJvdG9jb2wgZGF0YSB1bml0cywgdGVybWVkXHJcblx0ImJ1bmRsZXMi LCB0aGF0IGFyZSBkZXNpZ25lZCB0byBvYnZpYXRlIGNvbnZlcnNhdGlvbmFsIGNvbW11bmljYXRp b25zXHJcblx0YnkgY29udGFpbmluZyB2YWx1ZXMgZm9yIGFsbCBwb3RlbnRpYWxseSByZWxldmFu dCBjb25maWd1cmF0aW9uXHJcblx0cGFyYW1ldGVycy4gIFRoZXNlIHByb3RvY29sIGRhdGEgdW5p dHMgYXJlIHR5cGljYWxseSBsYXJnZXIgdGhhblxyXG5cdG5ldHdvcmstbGF5ZXIgcGFja2V0cy4g V2Ugd2lsbCBkZXJpdmUgdGhpcyBidW5kbGUgZXhjaGFuZ2UgbWVjaGFuaXNtXHJcbiAgICAgICAg ZnJvbSB0aGUgRFROIEJ1bmRsZSBQcm90b2NvbCAoQlApIGRvY3VtZW50ZWQgaW4gUkZDIDUwNTAg YnkgcHVibGlzaGluZ1xyXG4gICAgICAgIGEgbmV3IGRvY3VtZW50IGZvciB3aGljaCBbMl0gaXMg YSBwcm9wb3NlZCBmaXJzdCBkcmFmdCAod2hlcmVcclxuICAgICAgICBhcHBlbmRpeCBBIHByb3Zp ZGVzIGEgc3VtbWFyeSBvZiB0aGUgcHJvcG9zZWQgY2hhbmdlcykuXHJcblxyXG4gICAgICBvIEEg c2VjdXJpdHkgcHJvdG9jb2wgZm9yIGVuc3VyaW5nIHRoYXQgdGhlIG5ldHdvcmsgaW4gd2hpY2gg YnVuZGxlc1xyXG5cdGFyZSBleGNoYW5nZWQgaXMgc2VjdXJlZCBhZ2FpbnN0IHVuYXV0aG9yaXpl ZCBhY2Nlc3MgYW5kIGRlbmlhbCBvZlxyXG5cdHNlcnZpY2UgYXR0YWNrcywgYW5kIHRvIGVuc3Vy ZSBkYXRhIGludGVncml0eSBhbmQgY29uZmlkZW50aWFsaXR5XHJcblx0aW4gdGhhdCBuZXR3b3Jr IHdoZXJlIG5lY2Vzc2FyeS4gIFdlIHdpbGwgZGVyaXZlIHRoaXMgc2VjdXJpdHlcclxuXHRwcm90 b2NvbCBmcm9tIGEgInN0cmVhbWxpbmVkIiBhZGFwdGF0aW9uIG9mIHRoZSBEVE4gQnVuZGxlIFNl Y3VyaXR5XHJcblx0UHJvdG9jb2wgZG9jdW1lbnRlZCBpbiBSRkMgNjI1Ny5cclxuXHJcbiAgICAg IG8gQW4gZW5jYXBzdWxhdGlvbiBwcm90b2NvbCBmb3IgInR1bm5lbGluZyIgQlAgdHJhZmZpYyB3 aXRoaW4gYnVuZGxlc1xyXG5cdHRoYXQgYXJlIHNlY3VyZWQgYW5kL29yIHJvdXRlZCBpbiBkaWZm ZXJlbnQgd2F5IGZyb20gdGhlIGVuY2Fwc3VsYXRlZFxyXG5cdGJ1bmRsZXMuXHJcblxyXG4gICAg ICBvIEEgZGVsYXktdG9sZXJhbnQgc2VjdXJpdHkga2V5IG1hbmFnZW1lbnQgc2NoZW1lIGZvciBl bnN1cmluZyB0aGF0XHJcblx0cHVibGljIGtleXMgYXJlIGNlcnRpZmllZCBieSBhIGdsb2JhbGx5 IHRydXN0ZWQgYXV0aG9yaXR5IHRvIHByb3RlY3RcclxuXHR0aGUgaW50ZWdyaXR5IG9mIHRoZSBp bmZyYXN0cnVjdHVyZS5cclxuXHJcbiAgICAgIG8gQSBzaW1wbGUgZGF0YWdyYW0gY29udmVyZ2Vu Y2UgbGF5ZXIgcHJvdG9jb2wgZm9yIGFkYXB0YXRpb24gb2YgdGhlXHJcbiAgICAgICAgYnVuZGxl IHByb3RvY29sIHRvIHVuZGVybHlpbmcgaW50ZXJuZXR3b3Jrcy4gV2UgZXhwZWN0IHRvIGRlcml2 ZVxyXG4gICAgICAgIHRoaXMgY29udmVyZ2VuY2UgbGF5ZXIgcHJvdG9jb2wgZnJvbSB0aGUgRGF0 YWdyYW0gQ29udmVyZ2VuY2VcclxuICAgICAgICBwcm90b2NvbCBkb2N1bWVudGVkIGluIFJGQyA3 MTIyLlxyXG5cclxuICAgICAgbyBBIGRlbGF5LXRvbGVyYW50IG5ldHdvcmsgbWFuYWdlbWVudCBw cm90b2NvbCBmb3IgbWFuYWdlbWVudCBvZiB0aGVcclxuICAgICAgICBpbmZyYXN0cnVjdHVyZSBp biB0aGUgcHJlc2VuY2Ugb2YgbG9uZyBkZWxheXMgYW5kL29yIGludGVybWl0dGVudFxyXG4gICAg ICAgIGNvbm5lY3Rpdml0eS5cclxuXHJcbiAgICAgIG8gQSByZWdpc3RyeSBmb3IgRFROIFNlcnZp Y2UgSWRlbnRpZmllcnNcclxuICBcclxuICAgIFRoZSB3b3JraW5nIGdyb3VwIHdpbGwgY29uc2lk ZXIgZXh0ZW5kaW5nIHRoZSBjdXJyZW50IG1pbGVzdG9uZXMgYmFzZWQgb25cclxuICAgIG5ldyBp bmZvcm1hdGlvbiBhbmQga25vd2xlZGdlIGdhaW5lZCB3aGlsZSB3b3JraW5nIG9uIHRoZSBpbml0 aWFsIGNoYXJ0ZXIsXHJcbiAgICBhcyB3ZWxsIGFzIHRvIGFjY29tbW9kYXRlIG5ldyB3b3JrIGl0 ZW1zIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhlIGluaXRpYWxcclxuICAgIHBoYXNlLiAgRm9yIGV4 YW1wbGUsIHdlIGV4cGVjdCB0aGF0IHRyYW5zcG9ydCBwcm90b2NvbHMgc3VjaCBhcyBMVFAgYW5k XHJcbiAgICB0aGUgU2FyYXRvZ2EgcHJvdG9jb2wgYXJlIGFtb25nIHRoZSBjYW5kaWRhdGVzIGZv ciB3b3JrIGluIHRoaXMgcGhhc2UuXHJcbiAgICBcclxuR29hbHMgYW5kIE1pbGVzdG9uZXM6XHJc biAgc3RhcnQrM21vcyAtIFN1Ym1pdCBcJ0J1bmRsZSBQcm90b2NvbCBTcGVjaWZpY2F0aW9uIChS RkM1MDUwYmlzKVwnIGFzIGFcclxuICAgICAgICAgICAgICAgd29ya2luZyBncm91cCBkb2N1bWVu dCBbMl0uIFRvIGJlIFByb3Bvc2VkIFN0YW5kYXJkLlxyXG4gIFN0YXJ0KzNtb3MgLSBTdWJtaXQg XCdTdHJlYW1saW5lZCBCdW5kbGUgU2VjdXJpdHkgUHJvdG9jb2wgKFNCU1ApXCcgYXMgYVxyXG4g ICAgICAgICAgICAgICB3b3JraW5nIGdyb3VwIGRvY3VtZW50IFszXS4gVG8gYmUgUHJvcG9zZWQg U3RhbmRhcmQuXHJcbiAgc3RhcnQrNm1vcyAtIFN1Ym1pdCBcJ0J1bmRsZSBJbiBCdW5kbGUgRW5j YXBzdWxhdGlvbiAoQklCRSlcJyBhcyBhIHdvcmtpbmdcclxuICAgICAgICAgICAgICAgZ3JvdXAg ZG9jdW1lbnQgWzRdLiBUbyBiZSBQcm9wb3NlZCBTdGFuZGFyZC5cclxuICBzdGFydCsxMm1vcyAt IFN1Ym1pdCBcJ0RlbGF5IFRvbGVyYW50IE5ldHdvcmtpbmcgU2VjdXJpdHkgS2V5IE1hbmFnZW1l bnRcJyBhc1xyXG4gICAgICAgICAgICAgICAgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50LiBUbyBi ZSBQcm9wb3NlZCBTdGFuZGFyZC5cclxuICBzdGFydCsxOG1vcyAtIFdHIGRldGVybWluYXRpb24g Zm9yIG1lcmdpbmcgUkZDNTA1MGJpcywgU0JTUCwgQklCRSBhbmQvb3JcclxuICAgICAgICAgICAg ICAgIEtleSBNZ210IGludG8gYSBjb21iaW5lZCBkcmFmdCBvciBrZWVwIGFzIHNlcGFyYXRlIGRy YWZ0cy5cclxuICBzdGFydCsxOG1vcyAtIFN1Ym1pdCBSRkM1MDUwYmlzLCBTQlNQLCBCSUJFIGFu ZCBLZXkgTWdtdCB0byB0aGUgSUVTRyBlaXRoZXJcclxuICAgICAgICAgICAgICAgIGFzIGEgY29t YmluZWQgZHJhZnQgb3IgYXMgc2VwYXJhdGUgZHJhZnRzLlxyXG4gIHN0YXJ0KzE4bW9zIC0gU3Vi bWl0IE5ldHdvcmsgTWFuYWdlbWVudCBbNV0sIFJlZ2lzdHJ5IFs2XSBhbmQgU2ltcGxlXHJcbiAg ICAgICAgICAgICAgICBDb252ZXJnZW5jZSBMYXllciBbN10gYXMgd29ya2luZyBncm91cCBkb2N1 bWVudHMuXHJcbiAgc3RhcnQrMjBtb3MgLSBTdXJ2ZXkgYXBwcm9wcmlhdGUgZm9ydW1zIChlLmcu LCBEVE5SRykgZm9yIGVtZXJnaW5nXHJcbiAgICAgICAgICAgICAgICB0ZWNobm9sb2dpZXMgKGUu Zy4sIGNvbnZlcmdlbmNlIGxheWVyIHByb3RvY29scywgZHluYW1pY1xyXG4gICAgICAgICAgICAg ICAgcm91dGluZyBwcm90b2NvbHMsIG5hbWluZyBhbmQgYWRkcmVzc2luZyBzZXJ2aWNlcywgZXRj LilcclxuICAgICAgICAgICAgICAgIHJlYWR5IGZvciB0cmFuc2l0aW9uIGludG8gSUVURiBEVE4g V29ya2luZyBHcm91cC4gUHVibGlzaFxyXG4gICAgICAgICAgICAgICAgZHJhZnQgb24gc3VydmV5 IHJlc3VsdHMgYXMgaW5kZXBlbmRlbnQgc3VibWlzc2lvbiByZWxhdGVkXHJcbiAgICAgICAgICAg ICAgICB0byB0aGUgV0cuXHJcbiAgc3RhcnQrMjRtb3MgLSBTdWJtaXQgTmV0d29yayBNYW5hZ2Vt ZW50LCBSZWdpc3RyeSBhbmQgU2ltcGxlIENvbnZlcmdlbmNlXHJcbiAgICAgICAgICAgICAgICBM YXllciB0byBJRVNHXHJcbiAgc3RhcnQrMjRtb3MgLSBSZWNoYXJ0ZXIgdG8gYWNjb21tb2RhdGUg bmV3IHdvcmsgaXRlbXMgb3IgY2xvc2UgV29ya2luZyBHcm91cFxyXG5cclxuXHJcblsxXSAiQlAv TFRQIGRlcGxveW1lbnQgb24gRVBPWEkgc3BhY2VjcmFmdCIgWzIwMDhdLFxyXG4gICAgaHR0cDov L2NvbW1pdHRlZXMuY29tc29jLm9yZy90Y2NjL2Njdy8yMDEwL3NsaWRlcy9ESU5FVF9DQ1cucGRm ICBcclxuWzJdICJQcm9wb3NlZCBSZXZpc2VkIEJ1bmRsZSBQcm90b2NvbCIgWzIwMTRdLFxyXG4g ICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYnVybGVpZ2gtYnB2Ny9c clxuWzNdICJTdHJlYW1saW5lZCBCdW5kbGUgU2VjdXJpdHkgUHJvdG9jb2wgU3BlY2lmaWNhdGlv biIgWzIwMTRdLFxyXG4gICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aXJ0Zi1kdG5yZy1zYnNwL1xyXG5bNF0gIkJ1bmRsZS1pbi1CdW5kbGUgRW5jYXBzdWxhdGlvbiIg WzIwMTNdLFxyXG4gICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWlydGYtYnVybGVp Z2gtYmliZVxyXG5bNV0gIkRlbGF5IFRvbGVyYW50IE5ldHdvcmsgTWFuYWdlbWVudCBQcm90b2Nv bCIgWzIwMTNdLFxyXG4gICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWlydGYtZHRu cmctZHRubXBcclxuWzZdICJEZWxheS1Ub2xlcmFudCBOZXR3b3JraW5nIEJ1bmRsZSBQcm90b2Nv bCBJQU5BIFJlZ2lzdHJpZXMiIFsyMDExXSxcclxuICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL3JmYzYyNTUvXHJcbls3XSAiRGF0YWdyYW0gQ29udmVyZ2VuY2UgTGF5ZXJzIC4u LiIgWzIwMTRdLFxyXG4gICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvcmZjNzEy Mi9cclxuJywgJ2ZpbGVuYW1lMSc6ICdEcmFmdCBCb0YgQWdlbmRhICgyLjVocnMpOlxyXG4qKioq KioqKioqKioqKioqKioqKioqKioqKlxyXG4xKSBQcm9ibGVtIHN0YXRlbWVudCAoSUVURiB3ZyBt b3RpdmF0aW9uKSAtIDMwbWluXHJcblxyXG4yKSBSRkM1MDUwKGJpcykgLSAxNW1pblxyXG5cclxu MykgU3RyZWFtbGluZWQgQnVuZGxlIFNlY3VyaXR5IFByb3RvY29sIChTQlNQKSAtIDE1bWluXHJc blxyXG40KSBCdW5kbGUtaW4tQnVuZGxlIEVuY2Fwc3VsYXRpb24gLSAxMG1pblxyXG5cclxuNSkg U2VjdXJpdHkgS2V5IE1hbmFnZW1lbnQgLSAxMG1pblxyXG5cclxuNikgUmVnaXN0cnkgZm9yIFNl cnZpY2UgSWRlbnRpZmllcnMgLSAxMG1pblxyXG5cclxuNykgTmV0d29yayBNYW5hZ2VtZW50IC0g MTBtaW5cclxuXHJcbjgpIE9wZW4gRGlzY3Vzc2lvbiAtIDUwbWluXHJcblxyXG5cclxuUHJvcG9z ZWQgd29ya2luZyBncm91cCBjaGFydGVyOlxyXG4qKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqXHJcbldvcmtpbmcgZ3JvdXAgbmFtZTogXHJcblxyXG4gICAgICBEZWxheS9EaXNydXB0aW9u IFRvbGVyYW50IE5ldHdvcmtpbmcgV29ya2luZyBHcm91cCAoRFROV0cpXHJcblxyXG5DaGFpcihz KTpcclxuXHJcbiAgICAgIFRCRFxyXG5cclxuQXJlYSBhbmQgQXJlYSBEaXJlY3RvcihzKTpcclxu XHJcbiAgICAgIFRyYW5zcG9ydCBBcmVhOiBBRHMgU3BlbmNlciBEYXdraW5zIF9zcGVuY2VyZGF3 a2lucy5pZXRmIGF0IGdtYWlsLmNvbV8sXHJcbiAgICAgICAgICAgICAgICAgICAgICAgICAgTWFy dGluIFN0aWVtZXJsaW5nIF9tbHMuaWV0ZiBhdCBnbWFpbC5jb21fXHJcblxyXG5SZXNwb25zaWJs ZSBBcmVhIERpcmVjdG9yOlxyXG5cclxuICAgICAgVEJEXHJcblxyXG5NYWlsaW5nIGxpc3Q6XHJc blxyXG4gICAgICBHZW5lcmFsIERpc2N1c3Npb246IGR0biBhdCBpZXRmLm9yZ1xyXG4gICAgICBU byBTdWJzY3JpYmU6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZHRuXHJc biAgICAgIEFyY2hpdmU6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9kdG4v Y3VycmVudC9tYWlsbGlzdC5odG1sXHJcblxyXG5EZXNjcmlwdGlvbiBvZiBXb3JraW5nIEdyb3Vw OlxyXG5cclxuICAgICAgVGhlIERlbGF5L0Rpc3J1cHRpb24gVG9sZXJhbnQgTmV0d29yayBXb3Jr aW5nIEdyb3VwIChEVE5XRykgc3BlY2lmaWVzXHJcbiAgICAgIG1lY2hhbmlzbXMgZm9yIGRhdGEg Y29tbXVuaWNhdGlvbnMgaW4gdGhlIHByZXNlbmNlIG9mIGxvbmcgZGVsYXlzXHJcbiAgICAgIGFu ZC9vciBpbnRlcm1pdHRlbnQgY29ubmVjdGl2aXR5LiBUaGUgd29yayBpcyBtb3RpdmF0ZWQgYnkg d2VsbCBrbm93blxyXG4gICAgICBsaW1pdGF0aW9ucyBvZiBzdGFuZGFyZCBJbnRlcm5ldCBwcm90 b2NvbHMgdGhhdCBleHBlY3QgZW5kLXRvLWVuZFxyXG4gICAgICBjb25uZWN0aXZpdHkgYmV0d2Vl biBjb21tdW5pY2F0aW5nIGVuZHBvaW50cywgc3ViLXNlY29uZCB0cmFuc21pc3Npb25cclxuICAg ICAgZGVsYXlzIGFuZCByb2J1c3QgcGFja2V0IGRlbGl2ZXJ5IHJhdGlvcy4gSW4gZW52aXJvbm1l bnRzIHdoZXJlIHRoZXNlXHJcbiAgICAgIGZhdm9yYWJsZSBjb25kaXRpb25zIGRvIG5vdCBhcHBs eSwgZXhpc3RpbmcgbWVjaGFuaXNtcyBzdWNoIGFzIHJlbGlhYmxlXHJcbiAgICAgIHRyYW5zcG9y dCBwcm90b2NvbHMgYW5kIHJvdXRpbmcgcHJvdG9jb2xzIGNhbiBmYWlsIHRvIGNvbnZlcmdlIHJl c3VsdGluZ1xyXG4gICAgICBpbiBjb21tdW5pY2F0aW9uIGZhaWx1cmVzLiBGdXJ0aGVybW9yZSwg Y2xhc3NpY2FsIGVuZC10by1lbmQgc2VjdXJpdHlcclxuICAgICAgYXNzb2NpYXRpb25zIGNhbm5v dCBiZSBjb29yZGluYXRlZCB3aGVuIGNvbW11bmljYXRpbmcgZW5kcG9pbnRzIGNhbm5vdFxyXG4g ICAgICBjb25kdWN0IG11bHRpLW1lc3NhZ2Uga2V5aW5nIGV4Y2hhbmdlcyBpbiBhIHRpbWVseSBm YXNoaW9uLiBUaGVzZVxyXG4gICAgICBsaW1pdGF0aW9ucyBzdWdnZXN0IHRoZSBuZWVkIGZvciBh IG5ldyBhcHByb2FjaC4gXHJcbiAgICAgIFxyXG4gICAgICBEZWxheS1Ub2xlcmFudCBOZXR3b3Jr aW5nIChEVE4pIHByb3RvY29scyBoYXZlIGJlZW4gdGhlIHN1YmplY3Qgb2ZcclxuICAgICAgZXh0 ZW5zaXZlIHJlc2VhcmNoIGFuZCBkZXZlbG9wbWVudCBpbiB0aGUgRGVsYXktVG9sZXJhbnQgTmV0 d29ya2luZ1xyXG4gICAgICBSZXNlYXJjaCBHcm91cCBvZiB0aGUgSW50ZXJuZXQgUmVzZWFyY2gg VGFzayBGb3JjZSBzaW5jZSAyMDAyLiAgSW5cclxuICAgICAgcGFydGljdWxhciwgdGhlIERUTiBC dW5kbGUgUHJvdG9jb2wgKFJGQyA1MDUwKSBhbmQgTGlja2xpZGVyXHJcbiAgICAgIFRyYW5zbWlz c2lvbiBQcm90b2NvbCAoUkZDIDUzMjYpIGhhdmUgYmVlbiBzaG93biB0byBhZGRyZXNzIHRoZVxy XG4gICAgICBpc3N1ZXMgaWRlbnRpZmllZCBhYm92ZSBpbiBzdWJzdGFudGlhbCBmaWVsZGVkIGRl cGxveW1lbnRzIFsxXS5cclxuXHJcbiAgICAgIFRoZSBzdWNjZXNzIG9mIHRoZSBCUC9MVFAgcHJv dG9jb2wgc3RhY2sgLS0gdGhlIGNvcmUgcHJvdG9jb2xzIG9mIHRoZVxyXG4gICAgICAiRFROIEFy Y2hpdGVjdHVyZSIgb3JpZ2luYWxseSBkZXNjcmliZWQgaW4gUkZDIDQ4MzggLS0gbWF5IGJlIGF0 dHJpYnV0ZWRcclxuICAgICAgdG8gdGhlIGZvbGxvd2luZyBmdW5kYW1lbnRhbCBkZXNpZ24gcHJp bmNpcGxlczpcclxuXHJcblx0LSBUaGVyZSBpcyBuZXZlciBhbnkgZXhwZWN0YXRpb24gb2YgY29u dGVtcG9yYW5lb3VzIGVuZC10by1lbmRcclxuICAgICAgICAgIGNvbm5lY3Rpdml0eSBiZXR3ZWVu IGFueSB0d28gbmV0d29yayBub2Rlcy5cclxuXHJcblx0LSBCZWNhdXNlIGVuZC10by1lbmQgY29u bmVjdGl2aXR5IGNhbiBuZXZlciBiZSBhc3N1bWVkLCBlYWNoIG5vZGVcclxuXHQgIG9uIHRoZSBw YXRoIGJldHdlZW4gc291cmNlIGFuZCBkZXN0aW5hdGlvbiBtdXN0IGJlIHByZXBhcmVkIHRvXHJc blx0ICBoYW5kbGUgaW5jb21pbmcgImJ1bmRsZXMiIG9mIGRhdGEgdGhhdCBjYW5ub3QgaW1tZWRp YXRlbHkgYmVcclxuXHQgIGZvcndhcmRlZC5cclxuXHJcblx0LSBBZ2FpbiBiZWNhdXNlIGVuZC10 by1lbmQgY29ubmVjdGl2aXR5IGNhbiBuZXZlciBiZSBhc3N1bWVkLFxyXG5cdCAgZW5kLXRvLWVu ZCBjb252ZXJzYXRpb25hbCBkYXRhIGV4Y2hhbmdlIGNhbiBuZXZlciBiZSBhc3N1bWVkIHRvXHJc blx0ICBjb21wbGV0ZSBpbiBhIHRpbWVseSBtYW5uZXI7IHByb3RvY29sIGZlYXR1cmVzIHRoYXQg cmVseSBvblxyXG5cdCAgdGltZWx5IGNvbnZlcnNhdGlvbmFsIGRhdGEgZXhjaGFuZ2UgbXVzdCBi ZSBleGNsdWRlZCBmcm9tIHRoZVxyXG5cdCAgYXJjaGl0ZWN0dXJlLlxyXG5cclxuICAgICAgVGhl IERUTldHIGJlbGlldmVzIHRoYXQgcHJvdG9jb2xzIGFkaGVyaW5nIHRvIHRoZXNlIHByaW5jaXBs ZXMgb2ZmZXJcclxuICAgICAgb3Bwb3J0dW5pdGllcyBmb3IgZW5oYW5jaW5nIHRoZSBmdW5jdGlv bmFsaXR5IG9mIHRoZSBJbnRlcm5ldCAtIGluXHJcbiAgICAgIHBhcnRpY3VsYXIsIGZvciBmYWNp bGl0YXRpbmcgdGhlIGV4dGVuc2lvbiBvZiB0aGUgSW50ZXJuZXQgaW50b1xyXG4gICAgICBlbnZp cm9ubWVudHMgc3VjaCBhcyB0aGUgb2NlYW4gZmxvb3IgYW5kIGRlZXAgc3BhY2UgaW4gd2hpY2gg dGhlIGNvcmVcclxuICAgICAgSW50ZXJuZXQgcHJvdG9jb2xzIG9wZXJhdGUgc3ViLW9wdGltYWxs eSBmb3IgdGhlIHJlYXNvbnMgZGlzY3Vzc2VkXHJcbiAgICAgIGVhcmxpZXIuICBXZSBiZWxpZXZl IHRoYXQgdGhlIGV4dGVuc2l2ZSByZXNlYXJjaCwgZGVtb25zdHJhdGlvbiwgYW5kXHJcbiAgICAg IHBpbG90IG9wZXJhdGlvbnMgcGVyZm9ybWVkIHRvIGRhdGUgdXNpbmcgdGhlIERUTlJHIHByb3Rv Y29scyBwcm92aWRlc1xyXG4gICAgICBhIGZpcm0gYmFzaXMgZm9yIHB1Ymxpc2hpbmcgSW50ZXJu ZXQgc3RhbmRhcmRzIGRlcml2ZWQgZnJvbSB0aGF0IHdvcmsuXHJcblxyXG4gICAgICBXb3JrIGl0 ZW1zIHJlbGF0ZWQgdG8gRGVsYXkvRGlzcnVwdGlvbiBUb2xlcmFudCBOZXR3b3JraW5nIGluY2x1 ZGU6XHJcblxyXG4gICAgICBvIEEgbWVjaGFuaXNtIGZvciB0aGUgZXhjaGFuZ2Ugb2YgcHJvdG9j b2wgZGF0YSB1bml0cywgdGVybWVkXHJcblx0ImJ1bmRsZXMiLCB0aGF0IGFyZSBkZXNpZ25lZCB0 byBvYnZpYXRlIGNvbnZlcnNhdGlvbmFsIGNvbW11bmljYXRpb25zXHJcblx0YnkgY29udGFpbmlu ZyB2YWx1ZXMgZm9yIGFsbCBwb3RlbnRpYWxseSByZWxldmFudCBjb25maWd1cmF0aW9uXHJcblx0 cGFyYW1ldGVycy4gIFRoZXNlIHByb3RvY29sIGRhdGEgdW5pdHMgYXJlIHR5cGljYWxseSBsYXJn ZXIgdGhhblxyXG5cdG5ldHdvcmstbGF5ZXIgcGFja2V0cy4gV2Ugd2lsbCBkZXJpdmUgdGhpcyBi dW5kbGUgZXhjaGFuZ2UgbWVjaGFuaXNtXHJcbiAgICAgICAgZnJvbSB0aGUgRFROIEJ1bmRsZSBQ cm90b2NvbCAoQlApIGRvY3VtZW50ZWQgaW4gUkZDIDUwNTAgYnkgcHVibGlzaGluZ1xyXG4gICAg ICAgIGEgbmV3IGRvY3VtZW50IFsyXSwgd2hlcmUgYXBwZW5kaXggQSBhbmQgQiBwcm92aWRlIGFu IHVwZGF0ZSBzdW1tYXJ5LlxyXG5cclxuICAgICAgbyBBIHNlY3VyaXR5IHByb3RvY29sIGZvciBl bnN1cmluZyB0aGF0IHRoZSBuZXR3b3JrIGluIHdoaWNoIGJ1bmRsZXNcclxuXHRhcmUgZXhjaGFu Z2VkIGlzIHNlY3VyZWQgYWdhaW5zdCB1bmF1dGhvcml6ZWQgYWNjZXNzIGFuZCBkZW5pYWwgb2Zc clxuXHRzZXJ2aWNlIGF0dGFja3MsIGFuZCB0byBlbnN1cmUgZGF0YSBpbnRlZ3JpdHkgYW5kIGNv bmZpZGVudGlhbGl0eVxyXG5cdGluIHRoYXQgbmV0d29yayB3aGVyZSBuZWNlc3NhcnkuICBXZSB3 aWxsIGRlcml2ZSB0aGlzIHNlY3VyaXR5XHJcblx0cHJvdG9jb2wgZnJvbSBhICJzdHJlYW1saW5l ZCIgYWRhcHRhdGlvbiBvZiB0aGUgRFROIEJ1bmRsZSBTZWN1cml0eVxyXG5cdFByb3RvY29sIGRv Y3VtZW50ZWQgaW4gUkZDIDYyNTcuXHJcblxyXG4gICAgICBvIEFuIGVuY2Fwc3VsYXRpb24gcHJv dG9jb2wgZm9yICJ0dW5uZWxpbmciIEJQIHRyYWZmaWMgd2l0aGluIGJ1bmRsZXNcclxuXHR0aGF0 IGFyZSBzZWN1cmVkIGFuZC9vciByb3V0ZWQgaW4gZGlmZmVyZW50IHdheSBmcm9tIHRoZSBlbmNh cHN1bGF0ZWRcclxuXHRidW5kbGVzLlxyXG5cclxuICAgICAgbyBBIGRlbGF5LXRvbGVyYW50IHNl Y3VyaXR5IGtleSBtYW5hZ2VtZW50IHNjaGVtZSBmb3IgZW5zdXJpbmcgdGhhdFxyXG5cdHB1Ymxp YyBrZXlzIGFyZSBjZXJ0aWZpZWQgYnkgYSBnbG9iYWxseSB0cnVzdGVkIGF1dGhvcml0eSB0byBw cm90ZWN0XHJcblx0dGhlIGludGVncml0eSBvZiB0aGUgaW5mcmFzdHJ1Y3R1cmUuXHJcblxyXG4g ICAgICBvIEEgc2ltcGxlIGRhdGFncmFtIGNvbnZlcmdlbmNlIGxheWVyIHByb3RvY29sIGZvciBh ZGFwdGF0aW9uIG9mIHRoZVxyXG4gICAgICAgIGJ1bmRsZSBwcm90b2NvbCB0byB1bmRlcmx5aW5n IGludGVybmV0d29ya3MuIFdlIGV4cGVjdCB0byBkZXJpdmVcclxuICAgICAgICB0aGlzIGNvbnZl cmdlbmNlIGxheWVyIHByb3RvY29sIGZyb20gdGhlIERhdGFncmFtIENvbnZlcmdlbmNlXHJcbiAg ICAgICAgcHJvdG9jb2wgZG9jdW1lbnRlZCBpbiBSRkMgNzEyMi5cclxuXHJcbiAgICAgIG8gQSBk ZWxheS10b2xlcmFudCBuZXR3b3JrIG1hbmFnZW1lbnQgcHJvdG9jb2wgZm9yIG1hbmFnZW1lbnQg b2YgdGhlXHJcbiAgICAgICAgaW5mcmFzdHJ1Y3R1cmUgaW4gdGhlIHByZXNlbmNlIG9mIGxvbmcg ZGVsYXlzIGFuZC9vciBpbnRlcm1pdHRlbnRcclxuICAgICAgICBjb25uZWN0aXZpdHkuXHJcblxy XG4gICAgICBvIEEgcmVnaXN0cnkgZm9yIERUTiBTZXJ2aWNlIElkZW50aWZpZXJzXHJcbiAgXHJc biAgICBUaGUgd29ya2luZyBncm91cCB3aWxsIGNvbnNpZGVyIGV4dGVuZGluZyB0aGUgY3VycmVu dCBtaWxlc3RvbmVzIGJhc2VkIG9uXHJcbiAgICBuZXcgaW5mb3JtYXRpb24gYW5kIGtub3dsZWRn ZSBnYWluZWQgd2hpbGUgd29ya2luZyBvbiB0aGUgaW5pdGlhbCBjaGFydGVyLFxyXG4gICAgYXMg d2VsbCBhcyB0byBhY2NvbW1vZGF0ZSBuZXcgd29yayBpdGVtcyBiZXlvbmQgdGhlIHNjb3BlIG9m IHRoZSBpbml0aWFsXHJcbiAgICBwaGFzZS4gIEZvciBleGFtcGxlLCB3ZSBleHBlY3QgdGhhdCB0 cmFuc3BvcnQgcHJvdG9jb2xzIHN1Y2ggYXMgTFRQIGFuZFxyXG4gICAgdGhlIFNhcmF0b2dhIHBy b3RvY29sIGFyZSBhbW9uZyB0aGUgY2FuZGlkYXRlcyBmb3Igd29yayBpbiB0aGlzIHBoYXNlLlxy XG4gICAgXHJcbkdvYWxzIGFuZCBNaWxlc3RvbmVzOlxyXG4gIHN0YXJ0KzNtb3MgLSBTdWJtaXQg XCdCdW5kbGUgUHJvdG9jb2wgU3BlY2lmaWNhdGlvbiAoUkZDNTA1MGJpcylcJyBhcyBhXHJcbiAg ICAgICAgICAgICAgIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuIFRvIGJlIFByb3Bvc2VkIFN0YW5k YXJkLlxyXG4gIFN0YXJ0KzNtb3MgLSBTdWJtaXQgXCdTdHJlYW1saW5lZCBCdW5kbGUgU2VjdXJp dHkgUHJvdG9jb2wgKFNCU1ApXCcgYXMgYVxyXG4gICAgICAgICAgICAgICB3b3JraW5nIGdyb3Vw IGRvY3VtZW50LiBUbyBiZSBQcm9wb3NlZCBTdGFuZGFyZC5cclxuICBzdGFydCs2bW9zIC0gU3Vi bWl0IFwnQnVuZGxlIEluIEJ1bmRsZSBFbmNhcHN1bGF0aW9uIChCSUJFKVwnIGFzIGEgd29ya2lu Z1xyXG4gICAgICAgICAgICAgICBncm91cCBkb2N1bWVudC4gVG8gYmUgUHJvcG9zZWQgU3RhbmRh cmQuXHJcbiAgc3RhcnQrMTJtb3MgLSBTdWJtaXQgXCdEZWxheSBUb2xlcmFudCBOZXR3b3JraW5n IFNlY3VyaXR5IEtleSBNYW5hZ2VtZW50XCcgYXNcclxuICAgICAgICAgICAgICAgIGEgd29ya2lu ZyBncm91cCBkb2N1bWVudC4gVG8gYmUgUHJvcG9zZWQgU3RhbmRhcmQuXHJcbiAgc3RhcnQrMTht b3MgLSBXRyBkZXRlcm1pbmF0aW9uIGZvciBtZXJnaW5nIFJGQzUwNTBiaXMsIFNCU1AsIEJJQkUg YW5kL29yXHJcbiAgICAgICAgICAgICAgICBLZXkgTWdtdCBpbnRvIGEgY29tYmluZWQgZHJhZnQg b3Iga2VlcCBhcyBzZXBhcmF0ZSBkcmFmdHMuXHJcbiAgc3RhcnQrMThtb3MgLSBTdWJtaXQgUkZD NTA1MGJpcywgU0JTUCwgQklCRSBhbmQgS2V5IE1nbXQgdG8gdGhlIElFU0cgZWl0aGVyXHJcbiAg ICAgICAgICAgICAgICBhcyBhIGNvbWJpbmVkIGRyYWZ0IG9yIGFzIHNlcGFyYXRlIGRyYWZ0cy5c clxuICBzdGFydCsxOG1vcyAtIFN1Ym1pdCBOZXR3b3JrIE1hbmFnZW1lbnQsIFJlZ2lzdHJ5IGFu ZCBTaW1wbGUgQ29udmVyZ2VuY2VcclxuICAgICAgICAgICAgICAgIExheWVyIGFzIHdvcmtpbmcg Z3JvdXAgZG9jdW1lbnRzLlxyXG4gIHN0YXJ0KzIwbW9zIC0gU3VydmV5IGFwcHJvcHJpYXRlIGZv cnVtcyAoZS5nLiwgRFROUkcpIGZvciBlbWVyZ2luZ1xyXG4gICAgICAgICAgICAgICAgdGVjaG5v bG9naWVzIChlLmcuLCBjb252ZXJnZW5jZSBsYXllciBwcm90b2NvbHMsIGR5bmFtaWNcclxuICAg ICAgICAgICAgICAgIHJvdXRpbmcgcHJvdG9jb2xzLCBuYW1pbmcgYW5kIGFkZHJlc3Npbmcgc2Vy dmljZXMsIGV0Yy4pXHJcbiAgICAgICAgICAgICAgICByZWFkeSBmb3IgdHJhbnNpdGlvbiBpbnRv IElFVEYgRFROIFdvcmtpbmcgR3JvdXAuIFB1Ymxpc2hcclxuICAgICAgICAgICAgICAgIGRyYWZ0 IG9uIHN1cnZleSByZXN1bHRzIGFzIGluZGVwZW5kZW50IHN1Ym1pc3Npb24gcmVsYXRlZFxyXG4g ICAgICAgICAgICAgICAgdG8gdGhlIFdHLlxyXG4gIHN0YXJ0KzI0bW9zIC0gU3VibWl0IE5ldHdv cmsgTWFuYWdlbWVudCwgUmVnaXN0cnkgYW5kIFNpbXBsZSBDb252ZXJnZW5jZVxyXG4gICAgICAg ICAgICAgICAgTGF5ZXIgdG8gSUVTR1xyXG4gIHN0YXJ0KzI0bW9zIC0gUmVjaGFydGVyIHRvIGFj Y29tbW9kYXRlIG5ldyB3b3JrIGl0ZW1zIG9yIGNsb3NlIFdvcmtpbmcgR3JvdXBcclxuXHJcblxy XG5bMV0gIkJQL0xUUCBkZXBsb3ltZW50IG9uIEVQT1hJIHNwYWNlY3JhZnQiIFsyMDA4XVxyXG5b Ml0gIlByb3Bvc2VkIFJldmlzZWQgQnVuZGxlIFByb3RvY29sIiBbMjAxNF0sXHJcbiAgICBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1idXJsZWlnaC1icHY3L1xyXG4nLCAn dXJsMSc6ICcnLCAnc3VibWl0JzogJ0dlbmVyYXRlIGRpZmYnLCAndXJsMic6ICcnLCAnLS1uZXdj b2xvdXInOiAnZ3JlZW4nfSAtLT4= --_002_2134F8430051B64F815C691A62D983181B2C0855XCHBLV504nwnosb_-- From nobody Mon Jun 9 08:46:30 2014 Return-Path: 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 DEC851A0249; Mon, 9 Jun 2014 08:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.953 X-Spam-Level: X-Spam-Status: No, score=-2.953 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 U8jiGaTQybmr; Mon, 9 Jun 2014 08:46:16 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85B241A0238; Mon, 9 Jun 2014 08:46:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s59Fk8F4028203; Mon, 9 Jun 2014 08:46:08 -0700 Received: from XCH-PHX-508.sw.nos.boeing.com (xch-phx-508.sw.nos.boeing.com [137.136.239.67]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s59FjvXd028072 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 9 Jun 2014 08:45:58 -0700 Received: from XCH-BLV-209.nw.nos.boeing.com (137.136.239.109) by XCH-PHX-508.sw.nos.boeing.com (137.136.239.67) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 9 Jun 2014 08:45:57 -0700 Received: from XCH-BLV-512.nw.nos.boeing.com ([169.254.12.74]) by XCH-BLV-209.nw.nos.boeing.com ([169.254.9.248]) with mapi id 14.03.0181.006; Mon, 9 Jun 2014 08:45:56 -0700 From: "Templin, Fred L" To: "l.wood@surrey.ac.uk" , "spencerdawkins.ietf@gmail.com" , "mls.ietf@gmail.com" Thread-Topic: [dtn] DTN BoF Proposal for IETF90 Thread-Index: Ac+AQa9Fez/CplZaSwyaLFpzb8tj0wAiVZ0A///Hp/D//5OnYIABipvO//qPd7A= Date: Mon, 9 Jun 2014 15:45:56 +0000 Message-ID: <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com>, <1401967219583.26821@surrey.ac.uk>, <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk> In-Reply-To: <1402028661896.54716@surrey.ac.uk> 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/zMJ4Xwp6rZSi1jevEg-xb_CBvLM Cc: "iesg@ietf.org" , "dtn@ietf.org" Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 15:46:19 -0000 Hi Lloyd, Responding to your other points: > CCSDS exerts lockin on space agencies. It's very resistant to market forc= es (like, you know, TCP/IP), > and utterly resistant to multiple competing solutions - which is why the = bundle protocol was developed > and pushed. It's rather analogous to the telcos developing ATM in the 199= 0s to meet their needs, and > then doing that development in the ATM Forum. The IETF sat happily by, sh= aking its head for the most > part. I don't see it at all that the bundle protocol is analogous to ATM. ATM was about turning the Internet into "the matrix" - everything lined up so neat and homogeneous - no room for diversity - an innovation killer. The Internet is about accommodating diversity, and we are surely seeing that play out with the way the Internet has evolved. DTN (and the bundle protocol) is about interconnecting Internets. Let each Internet evolve according to its own characteristics, then hook them up at the edges. BP is all about accommodating diversity. =20 =20 > The question is, why should the IETF spend further time and effort for CC= SDS on the bundle protocol to > preserve the CCSDS bulwark against IP, where there are other things its e= xperts could be doing that > benefit actual IETF protocols? The bundle protocol is politically favoure= d by CCSDS, but is not > technically good. I don't understand "preserve the CCSDS bulwark against IP". BP is designed to connect IP internetworks and uses actual IETF protocols. Also, "not technically good" is not much of a technical assessment. You have published "Bundle of Problems", and as I have said it provides a useful problem statement to build on in a new revision of RFC5050. Protocols evolve based on insights gained through operational experience; none of them are perfect in their first iteration. Thanks - Fred fred.l.templin@boeing.com=20 From nobody Mon Jun 9 20:55:35 2014 Return-Path: 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 BF8211A03A2 for ; Mon, 9 Jun 2014 20:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.853 X-Spam-Level: X-Spam-Status: No, score=-4.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 LUFb5J5FVUVM for ; Mon, 9 Jun 2014 20:55:31 -0700 (PDT) Received: from pilot.jhuapl.edu (pilot.jhuapl.edu [128.244.251.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C76001A03A0 for ; Mon, 9 Jun 2014 20:55:30 -0700 (PDT) Received: from aplexcas2.dom1.jhuapl.edu (unknown [128.244.198.91]) by pilot.jhuapl.edu with smtp (TLS: TLSv1/SSLv3,128bits,RC4-MD5) id 6088_1169_25e567d1_ae58_4866_b9dd_7a8f7ee2a651; Mon, 09 Jun 2014 23:55:28 -0400 Received: from aplesfreedom.dom1.jhuapl.edu ([128.244.198.204]) by aplexcas2.dom1.jhuapl.edu ([128.244.198.91]) with mapi; Mon, 9 Jun 2014 23:55:28 -0400 From: "Birrane, Edward J." To: "dtn@ietf.org" Date: Mon, 9 Jun 2014 23:55:27 -0400 Thread-Topic: [dtn] DTN BoF Proposal for IETF90 Thread-Index: Ac+AQa9Fez/CplZaSwyaLFpzb8tj0wAiVZ0AAAXfQWAADdLFAAAnSnygAKnlzQc= Message-ID: <329D879C76FDD04AAAE84BB1D89B39700957131B79@aplesfreedom.dom1.jhuapl.edu> References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2BF3F7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2BF96C@XCH-BLV-504.nw.nos.boeing.com>, <2134F8430051B64F815C691A62D983181B2C05A4@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983181B2C05A4@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/tC83AGP7uUdS8bRQdnwiSM4DeZw Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 03:55:34 -0000 Fred, I wanted to concur on the changes to the BOF agenda times. Some time disc= ussing security, management, and 5050bis are good ways to prime the larger = discussion for the charter of the proposed working group. I also think the = updated working group charter goals and milestones are more appropriate. I = have a few notes for security and management, which I will put forward in d= ifferent messages to preserve threading. -Ed =20 ________________________________________ From: dtn [dtn-bounces@ietf.org] On Behalf Of Templin, Fred L [Fred.L.Templ= in@boeing.com] Sent: Friday, June 06, 2014 2:44 PM To: dtn@ietf.org Subject: Re: [dtn] DTN BoF Proposal for IETF90 See below for updated charter with pointer to new doc (diffs attached). Thanks - Fred --- Draft BoF Agenda (2.5hrs): ************************** 1) Problem statement (IETF wg motivation) - 30min 2) RFC5050(bis) - 15min 3) Streamlined Bundle Security Protocol (SBSP) - 15min 4) Bundle-in-Bundle Encapsulation - 10min 5) Security Key Management - 10min 6) Registry for Service Identifiers - 10min 7) Network Management - 10min 8) Open Discussion - 50min Proposed working group charter: ******************************* Working group name: Delay/Disruption Tolerant Networking Working Group (DTNWG) Chair(s): TBD Area and Area Director(s): Transport Area: ADs Spencer Dawkins , Martin Stiemerling Responsible Area Director: TBD Mailing list: General Discussion: dtn at ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dtn Archive: http://www.ietf.org/mail-archive/web/dtn/current/maillist.ht= ml Description of Working Group: The Delay/Disruption Tolerant Network Working Group (DTNWG) specifies mechanisms for data communications in the presence of long delays and/or intermittent connectivity. The work is motivated by well known limitations of standard Internet protocols that expect end-to-end connectivity between communicating endpoints, sub-second transmission delays and robust packet delivery ratios. In environments where these favorable conditions do not apply, existing mechanisms such as reliab= le transport protocols and routing protocols can fail to converge result= ing in communication failures. Furthermore, classical end-to-end security associations cannot be coordinated when communicating endpoints canno= t conduct multi-message keying exchanges in a timely fashion. These limitations suggest the need for a new approach. Delay-Tolerant Networking (DTN) protocols have been the subject of extensive research and development in the Delay-Tolerant Networking Research Group of the Internet Research Task Force since 2002. In particular, the DTN Bundle Protocol (RFC 5050) and Licklider Transmission Protocol (RFC 5326) have been shown to address the issues identified above in substantial fielded deployments [1]. The success of the BP/LTP protocol stack -- the core protocols of the "DTN Architecture" originally described in RFC 4838 -- may be attribu= ted to the following fundamental design principles: - There is never any expectation of contemporaneous end-to-end connectivity between any two network nodes. - Because end-to-end connectivity can never be assumed, each node on the path between source and destination must be prepared to handle incoming "bundles" of data that cannot immediately be forwarded. - Again because end-to-end connectivity can never be assumed, end-to-end conversational data exchange can never be assumed to complete in a timely manner; protocol features that rely on timely conversational data exchange must be excluded from the architecture. The DTNWG believes that protocols adhering to these principles offer opportunities for enhancing the functionality of the Internet - in particular, for facilitating the extension of the Internet into environments such as the ocean floor and deep space in which the core Internet protocols operate sub-optimally for the reasons discussed earlier. We believe that the extensive research, demonstration, and pilot operations performed to date using the DTNRG protocols provides a firm basis for publishing Internet standards derived from that work= . Work items related to Delay/Disruption Tolerant Networking include: o A mechanism for the exchange of protocol data units, termed "bundles", that are designed to obviate conversational communicatio= ns by containing values for all potentially relevant configuration parameters. These protocol data units are typically larger than network-layer packets. We will derive this bundle exchange mechanis= m from the DTN Bundle Protocol (BP) documented in RFC 5050 by publish= ing a new document [2], where appendix A and B provide an update summar= y. o A security protocol for ensuring that the network in which bundles are exchanged is secured against unauthorized access and denial of service attacks, and to ensure data integrity and confidentiality in that network where necessary. We will derive this security protocol from a "streamlined" adaptation of the DTN Bundle Security Protocol documented in RFC 6257. o An encapsulation protocol for "tunneling" BP traffic within bundles that are secured and/or routed in different way from the encapsulat= ed bundles. o A delay-tolerant security key management scheme for ensuring that public keys are certified by a globally trusted authority to protec= t the integrity of the infrastructure. o A simple datagram convergence layer protocol for adaptation of the bundle protocol to underlying internetworks. We expect to derive this convergence layer protocol from the Datagram Convergence protocol documented in RFC 7122. o A delay-tolerant network management protocol for management of the infrastructure in the presence of long delays and/or intermittent connectivity. o A registry for DTN Service Identifiers The working group will consider extending the current milestones based = on new information and knowledge gained while working on the initial chart= er, as well as to accommodate new work items beyond the scope of the initia= l phase. For example, we expect that transport protocols such as LTP and the Saratoga protocol are among the candidates for work in this phase. Goals and Milestones: start+3mos - Submit 'Bundle Protocol Specification (RFC5050bis)' as a working group document. To be Proposed Standard. Start+3mos - Submit 'Streamlined Bundle Security Protocol (SBSP)' as a working group document. To be Proposed Standard. start+6mos - Submit 'Bundle In Bundle Encapsulation (BIBE)' as a working group document. To be Proposed Standard. start+12mos - Submit 'Delay Tolerant Networking Security Key Management' = as a working group document. To be Proposed Standard. start+18mos - WG determination for merging RFC5050bis, SBSP, BIBE and/or Key Mgmt into a combined draft or keep as separate drafts. start+18mos - Submit RFC5050bis, SBSP, BIBE and Key Mgmt to the IESG eith= er as a combined draft or as separate drafts. start+18mos - Submit Network Management, Registry and Simple Convergence Layer as working group documents. start+20mos - Survey appropriate forums (e.g., DTNRG) for emerging technologies (e.g., convergence layer protocols, dynamic routing protocols, naming and addressing services, etc.) ready for transition into IETF DTN Working Group. Publish draft on survey results as independent submission related to the WG. start+24mos - Submit Network Management, Registry and Simple Convergence Layer to IESG start+24mos - Recharter to accommodate new work items or close Working Gr= oup [1] "BP/LTP deployment on EPOXI spacecraft" [2008] [2] "Proposed Revised Bundle Protocol" [2014], https://datatracker.ietf.org/doc/draft-burleigh-bpv7/= From nobody Mon Jun 9 21:13:26 2014 Return-Path: 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 580791A0398 for ; Mon, 9 Jun 2014 21:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.853 X-Spam-Level: X-Spam-Status: No, score=-4.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 FGMxeToVwSTt for ; Mon, 9 Jun 2014 21:13:22 -0700 (PDT) Received: from pilot.jhuapl.edu (pilot.jhuapl.edu [128.244.251.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00A291A0396 for ; Mon, 9 Jun 2014 21:13:21 -0700 (PDT) Received: from aplexcas1.dom1.jhuapl.edu (unknown [128.244.198.90]) by pilot.jhuapl.edu with smtp (TLS: TLSv1/SSLv3,128bits,RC4-MD5) id 60a2_ab34_6c1ab30b_80ce_4a42_9d0c_f6cd9f070a11; Tue, 10 Jun 2014 00:13:14 -0400 Received: from aplesfreedom.dom1.jhuapl.edu ([128.244.198.204]) by aplexcas1.dom1.jhuapl.edu ([128.244.198.90]) with mapi; Tue, 10 Jun 2014 00:13:14 -0400 From: "Birrane, Edward J." To: "Templin, Fred L" , "dtn@ietf.org" Date: Tue, 10 Jun 2014 00:13:14 -0400 Thread-Topic: Security in BPv7 Thread-Index: AQHPhGJM1cQphzBZO02l8sAiqho8CQ== Message-ID: <329D879C76FDD04AAAE84BB1D89B39700957131B7B@aplesfreedom.dom1.jhuapl.edu> References: <2134F8430051B64F815C691A62D983181B2C0587@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983181B2C0587@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/dbE5v3LHmlURficLkJnnRbN7mZ0 Subject: [dtn] Security in BPv7 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 04:13:24 -0000 I've been thinking through the concept of whether security (e.g., security = blocks) should be formally defined in BPv7 or whether their definition shou= ld be deferred to a separate document. Having worked through several use cases for both space and terrestrial netw= orking, I think that BPv7 should not mandate a particular security block st= ructure. In most cases, we've been using the design mantra "make the common= case fast", which will work for (by definition) a majority of deployments.= However, I am sure there are boundary cases and pathological topologies fo= r which a particular closed network or other special deployment would want = something different. For those networks, it is far easier to stay compliant= with BP and then non-compliant with BSP/SBSP than to require divergence fr= om the core standard.=20 Further, my intuition is that the security posture is best captured in a se= ries of (at least) three documents: the initial common-case security blocks= (SBSP), a security recipe for common security services (drafting in progre= ss), and configurations/policy best practices. To the extent that a "recipe= book" for security would show more than one way to achieve a desired secur= ity service, baselining a single methodology in 5050 or BP7 spec would be u= nduly constraining. Long story short, I think the path proposed in BPv7 (pointing outside of th= e document) for security services seems like a sensical thing to be doing. -Ed ________________________________________ From: dtn [dtn-bounces@ietf.org] On Behalf Of Templin, Fred L [Fred.L.Templ= in@boeing.com] Sent: Friday, June 06, 2014 2:38 PM To: dtn@ietf.org Subject: [dtn] FW: I-D Action: draft-burleigh-bpv7-00.txt FYI, see below for a first draft of RFC5050bis (Appendix A has a summary of differences from RFC5050). Comments to dtn@ietf.org. -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Friday, June 06, 2014 10:38 AM To: i-d-announce@ietf.org Subject: I-D Action: draft-burleigh-bpv7-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Proposed Revised Bundle Protocol Author : Scott Burleigh Filename : draft-burleigh-bpv7-00.txt Pages : 64 Date : 2014-06-06 Abstract: This Internet Draft presents a proposed modification to the Bundle Protocol Specification, including notes on the rationale underlying some of the proposed changes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-burleigh-bpv7/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-burleigh-bpv7-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ dtn mailing list dtn@ietf.org https://www.ietf.org/mailman/listinfo/dtn From nobody Mon Jun 9 21:39:58 2014 Return-Path: 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 6B0E51A03C4 for ; Mon, 9 Jun 2014 21:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.853 X-Spam-Level: X-Spam-Status: No, score=-4.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 N3zZJEsal3OD for ; Mon, 9 Jun 2014 21:39:54 -0700 (PDT) Received: from piper.jhuapl.edu (piper.jhuapl.edu [128.244.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0A1C1A03BB for ; Mon, 9 Jun 2014 21:39:54 -0700 (PDT) Received: from aplexcas1.dom1.jhuapl.edu (unknown [128.244.198.90]) by piper.jhuapl.edu with smtp (TLS: TLSv1/SSLv3,128bits,RC4-MD5) id 3438_a552_7bf64326_2621_4747_8b1c_7761a9ea118e; Tue, 10 Jun 2014 00:39:52 -0400 Received: from aplesfreedom.dom1.jhuapl.edu ([128.244.198.204]) by aplexcas1.dom1.jhuapl.edu ([128.244.198.90]) with mapi; Tue, 10 Jun 2014 00:39:52 -0400 From: "Birrane, Edward J." To: "dtn@ietf.org" Date: Tue, 10 Jun 2014 00:39:52 -0400 Thread-Topic: Network Management - Node IDs versus EIDs? Thread-Index: AQHPhGYEI/0btvEdLEustvFMtPLB3Q== Message-ID: <329D879C76FDD04AAAE84BB1D89B39700957131B7F@aplesfreedom.dom1.jhuapl.edu> References: <2134F8430051B64F815C691A62D983181B2C0587@XCH-BLV-504.nw.nos.boeing.com>, <329D879C76FDD04AAAE84BB1D89B39700957131B7B@aplesfreedom.dom1.jhuapl.edu> In-Reply-To: <329D879C76FDD04AAAE84BB1D89B39700957131B7B@aplesfreedom.dom1.jhuapl.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/KCowt2Cmu1xk3ndsZLON3KaDAbc Subject: [dtn] Network Management - Node IDs versus EIDs? X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 04:39:56 -0000 A question about Node identifiers versus endpoint identifiers....=20 I have been reading through BPv7 to see what, if anything, needs to change = in the update to DTNMP that I'm currently working on. It seems to me that n= ode identifiers should be the preferred identifier when discussing network = management services in a DTN. It seems reasonable that management services = operate on singletons and avoid the potential pitfalls of shared or re-assi= gned EIDs in a network. So, when making an SNMP/DTNMP/other query against a= node, going forward, Node IDs are the way to go. Other than reporting status/performance of EIDs configured at a particular = Node ID, are there any use cases where EIDs should be the first-class targe= ts of performance monitoring, configuration, or control?=20 This may become a NM scoping issue... if EIDs evolve to be the moral equiva= lents of service numbers, then extending NM into EIDs would be similar to e= xtending network management services into application management services. Thoughts? -Ed= From nobody Mon Jun 9 23:46:20 2014 Return-Path: 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 9A2F11A03DC for ; Mon, 9 Jun 2014 23:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 Pzu-ObFyneLh for ; Mon, 9 Jun 2014 23:46:16 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 869071A0407 for ; Mon, 9 Jun 2014 23:46:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4859BBE50; Tue, 10 Jun 2014 07:46:15 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMkFk-TXN85s; Tue, 10 Jun 2014 07:46:14 +0100 (IST) Received: from [172.16.23.144] (217.64.246.155.mactelecom.net [217.64.246.155]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2903FBE38; Tue, 10 Jun 2014 07:46:14 +0100 (IST) Message-ID: <5396A9B5.7030405@cs.tcd.ie> Date: Tue, 10 Jun 2014 07:46:13 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Birrane, Edward J." , "Templin, Fred L" , "dtn@ietf.org" References: <2134F8430051B64F815C691A62D983181B2C0587@XCH-BLV-504.nw.nos.boeing.com> <329D879C76FDD04AAAE84BB1D89B39700957131B7B@aplesfreedom.dom1.jhuapl.edu> In-Reply-To: <329D879C76FDD04AAAE84BB1D89B39700957131B7B@aplesfreedom.dom1.jhuapl.edu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/ZVEPNFCR1lE9stmfZGK98SNTS-w Subject: Re: [dtn] Security in BPv7 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 06:46:18 -0000 Hi Ed, Two thoughts on that: On 10/06/14 05:13, Birrane, Edward J. wrote: > Long story short, I think the path proposed in BPv7 (pointing outside > of the document) for security services seems like a sensical thing to > be doing. I don't really care how the spec might be broken up into documents but I do think that doing whatever security work is to be done at the same time is the right thing - we suffered from that last time with the BSP. I think what ought be mandatory to implement etc. is a level of detail for later, but would like the putative WG to consider having some security services on by default. But that's also a discussion probably better had later, if a WG is chartered. S. From nobody Tue Jun 10 01:40:48 2014 Return-Path: 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 89DFC1A0329; Tue, 10 Jun 2014 01:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 ZYM0o5WoLxgi; Tue, 10 Jun 2014 01:40:44 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.113]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B2251A01B3; Tue, 10 Jun 2014 01:40:41 -0700 (PDT) Received: from [193.109.255.147:2309] by server-9.bemta-14.messagelabs.com id 49/78-03644-884C6935; Tue, 10 Jun 2014 08:40:40 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-10.tower-72.messagelabs.com!1402389639!13414382!1 X-Originating-IP: [131.227.200.31] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18849 invoked from network); 10 Jun 2014 08:40:39 -0000 Received: from exht011p.surrey.ac.uk (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-10.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 10 Jun 2014 08:40:39 -0000 Received: from EXHY012V.surrey.ac.uk (131.227.201.103) by exht011p.surrey.ac.uk (131.227.200.31) with Microsoft SMTP Server (TLS) id 8.3.348.2; Tue, 10 Jun 2014 09:40:39 +0100 Received: from emea01-db3-obe.outbound.protection.outlook.com (131.227.201.241) by EXHY012v.surrey.ac.uk (131.227.201.103) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 10 Jun 2014 09:40:38 +0100 Received: from AMSPR06MB439.eurprd06.prod.outlook.com (10.242.23.19) by AMSPR06MB439.eurprd06.prod.outlook.com (10.242.23.19) with Microsoft SMTP Server (TLS) id 15.0.954.9; Tue, 10 Jun 2014 08:40:38 +0000 Received: from AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) by AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) with mapi id 15.00.0954.000; Tue, 10 Jun 2014 08:40:38 +0000 From: To: , , Thread-Topic: [dtn] DTN BoF Proposal for IETF90 Thread-Index: Ac+AQa9Fez/CplZaSwyaLFpzb8tj0wAiVZ0A///Hp/D//5OnYIABipvO//qPd7CAC7TeXQ== Date: Tue, 10 Jun 2014 08:40:37 +0000 Message-ID: <1402389636710.92429@surrey.ac.uk> References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com>, <1401967219583.26821@surrey.ac.uk>, <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk>, <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> Accept-Language: en-AU, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [122.200.59.30] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 0238AEEDB0 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(377454003)(189002)(199002)(15975445006)(2656002)(74662001)(54356999)(74502001)(21056001)(99396002)(76482001)(83322001)(76176999)(79102001)(64706001)(77096999)(20776003)(561944003)(19580405001)(83072002)(31966008)(74482001)(85852003)(66066001)(77982001)(46102001)(19580395003)(50986999)(87936001)(81342001)(101416001)(4396001)(92726001)(80022001)(15395725005)(81542001)(2201001)(86362001)(92566001)(36756003)(93886002)(15202345003); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR06MB439; H:AMSPR06MB439.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: surrey.ac.uk does not designate permitted sender hosts) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: AMSPR06MB439.eurprd06.prod.outlook.com X-CrossPremisesHeadersFiltered: EXHY012v.surrey.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/YhpGxUFpxzCif5amgvq_SniPqoc Cc: iesg@ietf.org, dtn@ietf.org Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 08:40:46 -0000 Hi Fred,=0A= =0A= I see I'll need to explain my ATM analogy to the bundle protocol=0A= in a bit more detail.=0A= =0A= Please bear with me while I do that and step through some history, before g= oing=0A= into some IETF/CCSDS interaction nuances. (Understanding the needs of the= =0A= Consultative Committee for Space Data Systems is key to understanding why t= he=0A= bundle protocol exists.)=0A= =0A= A brief history of ATM=0A= =0A= ATM was developed by a single community - telcos with some very restrictive= =0A= legacy voice requirements - and passed onto a larger audience as the one tr= ue=0A= way to handle true QoS and high-speed switching with Proper Managed=0A= Multiplexing. It had processing performance and other problems, and=0A= was then bypassed by market forces and technical developments, even=0A= though few ever said outright that 'ATM is technically poor'. And it's no= =0A= longer used much, even in its core community. Technology has moved on.=0A= =0A= Jon Crowcroft's 'J'accuse, ATM' end2end-interest piece from 1994 gives=0A= a flavour of this while it was happening.=0A= https://groups.google.com/forum/#!topic/info.ietf/HCe2X7jzuNY=0A= Daniel Stevenson's 'Electro Political Correctness and High-Speed Networking= =0A= or why ATM is Like a Nose,' from the same era, gives more technical detail = of=0A= the problems, including the legacy echo cancellation reasons and=0A= compromising that led to that 48-byte payload.=0A= =0A= Few actually working on ATM complained much, in public. There were a=0A= number of US research projects, with a number of European research=0A= projects following on after to catch onto what seemed like a good trend.=0A= (Disclaimer of interest: my PhD work was funded by European projects=0A= bringing up the tail end of the ATM infatuation. MPLS seemed like a useful= =0A= way out of wholeheartedly committing to anything involving ATM. And=0A= that's why I'm using ATM as the example instead of the earlier OSI stuff.)= =0A= =0A= ATM was not revised to fix its problems.=0A= The world moved on to better things.=0A= =0A= =0A= A brief history of the Bundle Protocol=0A= =0A= Similarly, the bundle protocol was developed by and for a single community= =0A= - NASA-led CCSDS for the 'interplanetary internet' - and passed to a larger= =0A= audience as the one true way to handle delay-tolerant networking. (Fall's= =0A= 2003 SIGCOMM paper was seminal in that; it gave the MANET/ad-hoc crowd=0A= a new focus and banner to wave. Impressive going for a conference paper wit= h=0A= no actual results, widely cited, very influential, and rightly deserving of= awards=0A= for being so!)=0A= =0A= However, it's sometimes hard to tell a truly useful vision from a momentary= =0A= hallucination. "Delay-tolerant networking" soon turned out to be badly scop= ed,=0A= hence the rise of "disruption-tolerant networking" for the more MANET-ish= =0A= and military crowd. DARPA evaluated the bundle protocol, and moved on.=0A= CCSDS and NASA stuck with it.=0A= =0A= CCSDS and space agencies are largely resistant to market forces, and slow= =0A= to accept technical change; the risks of change are high compared to the=0A= possible rewards. CCSDS is positively risk-friendly compared to people=0A= actually designing for missions. There's also little room for diversity in = CCSDS.=0A= =0A= CCSDS also has a strong 'not invented here' culture - as an ISO subgroup,= =0A= CCSDS even refuses to carry the ISO standard 13239 HDLC. (disclaimer of=0A= interest: we've done some neat things with HDLC from a router in space,=0A= which is why I know enough to make that point as a minor example.)=0A= =0A= But then, NASA isn't quite onboard with ISO units of measurement, either.= =0A= Hey, ISO's useful - as far as it goes, but not too far. It's nice to be par= t of a=0A= standards body, but actually commit to using their standards? Really?=0A= Allow HDLC and open the door to layering and IP? No way. In CCSDS,=0A= any layering is an inefficiency, to be designed out. Much engineering=0A= time is spent on this.=0A= =0A= Unlike the open-to-everyone IETF, CCSDS is a more closed community=0A= for aerospace - you only get on their mailing lists via space agency=0A= sponsorship, the traditional ISO 'nominated subject matter expert' model.= =0A= =0A= CCSDS is trapped with a pre-packet processing model, and that needs to chan= ge.=0A= CCSDS does not have particularly strong expertise in packetised networking,= =0A= which is why SCPS was brought in almost wholesale from TCP/IP in the 1990s= =0A= before being modified, and why the IRTF workgroups were set up to help=0A= CCSDS out with the Interplanetary Internet idea; the SIGCCOMM paper=0A= got a lot of people onboard for that. =0A= =0A= CCSDS needs to both outsource the development it can't do that well itself,= =0A= and yet control its own destiny and standards, by modifying the results. Th= ose=0A= two goals are somewhat incompatible. So if the IETF were to help CCSDS=0A= out with a standards-track workgroup and do the work to get a published=0A= standard, CCSDS would promptly 'improve' it as was done with SCPS, and=0A= as is currently being done by standardising DTPC, DTNMP and other pieces=0A= around the core bundle protocol, in cooperation with European projects=0A= bringing up the tail end of the DTN movement. (DARPA et al. having=0A= already left the building.) And 'not invented here' becomes 'invented here'= =0A= with a CCSDS blue book, which is the kind of thing that e.g. the Internatio= nal=0A= Space Station crowd would be comfortable with.=0A= =0A= Given that CCSDS is standardising a whole bunch of pieces that the core=0A= bundle protocol needs, and is restandardising RFC5050 into a blue book,=0A= CCSDS can do the RFC5050bis work as well. Perhaps not as well as the IETF= =0A= might if serious IETF effort was brought to bear on it, but the IRTF DTNRG= =0A= and RFC5050 already suggests what might result.=0A= =0A= It's not as if anyone else other than CCSDS aspires to use the bundle proto= col=0A= operationally, so CCSDS may as well own RFC5050bis from the start. And sell= ing=0A= RFC5050bis to the space agencies to adopt is CCSDS's problem.=0A= =0A= I don't see an upside for the IETF community in doing this standards work f= or=0A= CCSDS. And I don't see an upside for the DTN/MANET community, research=0A= or operational, as the bundle protocol restricts innovation by proposing=0A= one homogenous, non-diverse, straitjacket for everyone. Rather as ATM did.= =0A= =0A= Instead, the world needs to embrace innovation and move on from the=0A= Bundle Protocol.=0A= =0A= The bundle protocol is not about connecting different types of internets -= =0A= other than IP and CCSDS, what other types of internets are in the picture?= =0A= Layering over the top just as IP layered over everything is a wellmeaning= =0A= early idea, nothing more. IP internetworks can be connected using.... IP.= =0A= CCSDS has to use IP on the ground, but is strongly resistant to using it=0A= in space. CCSDS is going to have trouble getting missions to accept=0A= layering the bundle protocol over the top of their links. The inefficiencie= s!=0A= But the bundle protocol is the solution that CCSDS has invested in=0A= heavily.=0A= =0A= Given that, I can't see anyone in NASA standing up today and saying 'this b= undle=0A= protocol really isn't much good'. Too much would be at stake politically.= =0A= It would be like standing up in the 1970s and saying 'I think this side-mou= nted=0A= solid-booster ceramic-tiled space shuttle is quite unsafe and possibly a ra= ther=0A= bad idea.' The shuttle was the one solution, and that was that. To suggest= =0A= otherwise would be a career-limiting moment, going against the tide.=0A= (In hindsight, the problems with the shuttle are now obvious to layman=0A= historians:=0A= http://idlewords.com/2005/08/a_rocket_to_nowhere.htm )=0A= =0A= "It is difficult to get a man to understand something,=0A= when his salary depends upon his not understanding it!"=0A= -- Upton Sinclair=0A= =0A= Our "A bundle of problems" paper [1] was intended to provide a problem=0A= statement - when it was written, in late 2008, after first attempting to ta= ke=0A= the points in it to the research group. We even put 'problems' in the name.= =0A= And most of our problem points were obtained through simple analysis, which= =0A= our tests rather predictably bore out. It is now 2014, and in over five yea= rs=0A= none of the problems raised have been remedied in the design of the bundle= =0A= protocol. Because to do so would be to admit that the bundle protocol is, i= n fact,=0A= flawed. Rather like ATM, or like the space shuttle.=0A= =0A= And the world has moved on from ATM and from the space shuttle.=0A= It didn't try to do them over with a version 2.=0A= =0A= [1] http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/index.html= #bundle-problems=0A= Lloyd Wood, Wesley M. Eddy and Peter Holliday, 'A Bundle of Problems',=0A= IEEE Aerospace Conference, Big Sky, Montana, March 2009. 16 pages.=0A= ("the bundle protocol is not technically good"=0A= is just my brief TL;DR summary of those 16 pages.)=0A= http://dx.doi.org/10.1109/AERO.2009.4839384=0A= =0A= best regards=0A= =0A= Lloyd Wood=0A= http://sat-net.com/L.Wood/dtn/=0A= ________________________________________=0A= From: Templin, Fred L =0A= Sent: Tuesday, 10 June 2014 1:45 AM=0A= To: Wood L Dr (Electronic Eng); spencerdawkins.ietf@gmail.com; mls.ietf@gm= ail.com=0A= Cc: iesg@ietf.org; dtn@ietf.org=0A= Subject: RE: [dtn] DTN BoF Proposal for IETF90=0A= =0A= Hi Lloyd,=0A= =0A= Responding to your other points:=0A= =0A= > CCSDS exerts lockin on space agencies. It's very resistant to market forc= es (like, you know, TCP/IP),=0A= > and utterly resistant to multiple competing solutions - which is why the = bundle protocol was developed=0A= > and pushed. It's rather analogous to the telcos developing ATM in the 199= 0s to meet their needs, and=0A= > then doing that development in the ATM Forum. The IETF sat happily by, sh= aking its head for the most=0A= > part.=0A= =0A= I don't see it at all that the bundle protocol is analogous to ATM.=0A= ATM was about turning the Internet into "the matrix" - everything=0A= lined up so neat and homogeneous - no room for diversity - an=0A= innovation killer. The Internet is about accommodating diversity,=0A= and we are surely seeing that play out with the way the Internet=0A= has evolved.=0A= =0A= DTN (and the bundle protocol) is about interconnecting Internets.=0A= Let each Internet evolve according to its own characteristics, then=0A= hook them up at the edges. BP is all about accommodating diversity.=0A= =0A= > The question is, why should the IETF spend further time and effort for CC= SDS on the bundle protocol to=0A= > preserve the CCSDS bulwark against IP, where there are other things its e= xperts could be doing that=0A= > benefit actual IETF protocols? The bundle protocol is politically favoure= d by CCSDS, but is not=0A= > technically good.=0A= =0A= I don't understand "preserve the CCSDS bulwark against IP". BP is=0A= designed to connect IP internetworks and uses actual IETF protocols.=0A= =0A= Also, "not technically good" is not much of a technical assessment.=0A= You have published "Bundle of Problems", and as I have said it provides=0A= a useful problem statement to build on in a new revision of RFC5050.=0A= Protocols evolve based on insights gained through operational experience;= =0A= none of them are perfect in their first iteration.=0A= =0A= Thanks - Fred=0A= fred.l.templin@boeing.com=0A= From nobody Tue Jun 10 08:11:31 2014 Return-Path: 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 990DD1B2802; Tue, 10 Jun 2014 08:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.252 X-Spam-Level: X-Spam-Status: No, score=-4.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, 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 Qpzpk_u2RJUs; Tue, 10 Jun 2014 08:11:15 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E754C1B2812; Tue, 10 Jun 2014 08:11:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s5AFB8jL030050; Tue, 10 Jun 2014 08:11:08 -0700 Received: from XCH-PHX-407.sw.nos.boeing.com (xch-phx-407.sw.nos.boeing.com [137.136.239.48]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s5AFAwMh029428 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 10 Jun 2014 08:10:59 -0700 Received: from XCH-BLV-512.nw.nos.boeing.com ([169.254.12.74]) by XCH-PHX-407.sw.nos.boeing.com ([169.254.3.167]) with mapi id 14.03.0181.006; Tue, 10 Jun 2014 08:10:57 -0700 From: "Templin, Fred L" To: "l.wood@surrey.ac.uk" , "spencerdawkins.ietf@gmail.com" , "mls.ietf@gmail.com" Thread-Topic: [dtn] DTN BoF Proposal for IETF90 Thread-Index: Ac+AQa9Fez/CplZaSwyaLFpzb8tj0wAiVZ0A///Hp/D//5OnYIABipvO//qPd7CAC7TeXf//SGxA Date: Tue, 10 Jun 2014 15:10:57 +0000 Message-ID: <2134F8430051B64F815C691A62D9831830486EBE@XCH-BLV-512.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com>, <1401967219583.26821@surrey.ac.uk>, <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk>, <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> <1402389636710.92429@surrey.ac.uk> In-Reply-To: <1402389636710.92429@surrey.ac.uk> 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/kLavgUvQ8zdPLyHjEuxiHRW7l68 Cc: "iesg@ietf.org" , "dtn@ietf.org" Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 15:11:26 -0000 Hi Lloyd, You don't need to lecture me about ATM - I was there in the late 80's and early 90's when Digital Equipment Corporation was trying to make a go at ATM and OSI networking ("DECnet Phase V"). Both crashed and burned (and later so did the company), but that has nothing whatsoever to do with DTN. About the rest of your message, your distaste for the origins of the Bundle Protocol is clear but that has nothing to do with the way forward for DTN and the Bundle Protocol as an open solution within the IETF. All protocols get there start somewhere, but this is not about dragging along legacy. Rather, it is about forming a community of interest to establish open standards within the IETF based on the participation of a diverse set of individuals. I was going to send a separate message, but this seems like a useful starting point. This is a call to the list for a show of hands as to who would like to see a BoF held at IETF90. Please respond to this message thread if you would like to see a BoF. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk] > Sent: Tuesday, June 10, 2014 1:41 AM > To: Templin, Fred L; spencerdawkins.ietf@gmail.com; mls.ietf@gmail.com > Cc: iesg@ietf.org; dtn@ietf.org > Subject: RE: [dtn] DTN BoF Proposal for IETF90 >=20 > Hi Fred, >=20 > I see I'll need to explain my ATM analogy to the bundle protocol > in a bit more detail. >=20 > Please bear with me while I do that and step through some history, before= going > into some IETF/CCSDS interaction nuances. (Understanding the needs of the > Consultative Committee for Space Data Systems is key to understanding why= the > bundle protocol exists.) >=20 > A brief history of ATM >=20 > ATM was developed by a single community - telcos with some very restricti= ve > legacy voice requirements - and passed onto a larger audience as the one = true > way to handle true QoS and high-speed switching with Proper Managed > Multiplexing. It had processing performance and other problems, and > was then bypassed by market forces and technical developments, even > though few ever said outright that 'ATM is technically poor'. And it's no > longer used much, even in its core community. Technology has moved on. >=20 > Jon Crowcroft's 'J'accuse, ATM' end2end-interest piece from 1994 gives > a flavour of this while it was happening. > https://groups.google.com/forum/#!topic/info.ietf/HCe2X7jzuNY > Daniel Stevenson's 'Electro Political Correctness and High-Speed Networki= ng > or why ATM is Like a Nose,' from the same era, gives more technical detai= l of > the problems, including the legacy echo cancellation reasons and > compromising that led to that 48-byte payload. >=20 > Few actually working on ATM complained much, in public. There were a > number of US research projects, with a number of European research > projects following on after to catch onto what seemed like a good trend. > (Disclaimer of interest: my PhD work was funded by European projects > bringing up the tail end of the ATM infatuation. MPLS seemed like a usefu= l > way out of wholeheartedly committing to anything involving ATM. And > that's why I'm using ATM as the example instead of the earlier OSI stuff.= ) >=20 > ATM was not revised to fix its problems. > The world moved on to better things. >=20 >=20 > A brief history of the Bundle Protocol >=20 > Similarly, the bundle protocol was developed by and for a single communit= y > - NASA-led CCSDS for the 'interplanetary internet' - and passed to a larg= er > audience as the one true way to handle delay-tolerant networking. (Fall's > 2003 SIGCOMM paper was seminal in that; it gave the MANET/ad-hoc crowd > a new focus and banner to wave. Impressive going for a conference paper w= ith > no actual results, widely cited, very influential, and rightly deserving = of awards > for being so!) >=20 > However, it's sometimes hard to tell a truly useful vision from a momenta= ry > hallucination. "Delay-tolerant networking" soon turned out to be badly sc= oped, > hence the rise of "disruption-tolerant networking" for the more MANET-ish > and military crowd. DARPA evaluated the bundle protocol, and moved on. > CCSDS and NASA stuck with it. >=20 > CCSDS and space agencies are largely resistant to market forces, and slow > to accept technical change; the risks of change are high compared to the > possible rewards. CCSDS is positively risk-friendly compared to people > actually designing for missions. There's also little room for diversity i= n CCSDS. >=20 > CCSDS also has a strong 'not invented here' culture - as an ISO subgroup, > CCSDS even refuses to carry the ISO standard 13239 HDLC. (disclaimer of > interest: we've done some neat things with HDLC from a router in space, > which is why I know enough to make that point as a minor example.) >=20 > But then, NASA isn't quite onboard with ISO units of measurement, either. > Hey, ISO's useful - as far as it goes, but not too far. It's nice to be p= art of a > standards body, but actually commit to using their standards? Really? > Allow HDLC and open the door to layering and IP? No way. In CCSDS, > any layering is an inefficiency, to be designed out. Much engineering > time is spent on this. >=20 > Unlike the open-to-everyone IETF, CCSDS is a more closed community > for aerospace - you only get on their mailing lists via space agency > sponsorship, the traditional ISO 'nominated subject matter expert' model. >=20 > CCSDS is trapped with a pre-packet processing model, and that needs to ch= ange. > CCSDS does not have particularly strong expertise in packetised networkin= g, > which is why SCPS was brought in almost wholesale from TCP/IP in the 1990= s > before being modified, and why the IRTF workgroups were set up to help > CCSDS out with the Interplanetary Internet idea; the SIGCCOMM paper > got a lot of people onboard for that. >=20 > CCSDS needs to both outsource the development it can't do that well itsel= f, > and yet control its own destiny and standards, by modifying the results. = Those > two goals are somewhat incompatible. So if the IETF were to help CCSDS > out with a standards-track workgroup and do the work to get a published > standard, CCSDS would promptly 'improve' it as was done with SCPS, and > as is currently being done by standardising DTPC, DTNMP and other pieces > around the core bundle protocol, in cooperation with European projects > bringing up the tail end of the DTN movement. (DARPA et al. having > already left the building.) And 'not invented here' becomes 'invented her= e' > with a CCSDS blue book, which is the kind of thing that e.g. the Internat= ional > Space Station crowd would be comfortable with. >=20 > Given that CCSDS is standardising a whole bunch of pieces that the core > bundle protocol needs, and is restandardising RFC5050 into a blue book, > CCSDS can do the RFC5050bis work as well. Perhaps not as well as the IETF > might if serious IETF effort was brought to bear on it, but the IRTF DTNR= G > and RFC5050 already suggests what might result. >=20 > It's not as if anyone else other than CCSDS aspires to use the bundle pro= tocol > operationally, so CCSDS may as well own RFC5050bis from the start. And se= lling > RFC5050bis to the space agencies to adopt is CCSDS's problem. >=20 > I don't see an upside for the IETF community in doing this standards work= for > CCSDS. And I don't see an upside for the DTN/MANET community, research > or operational, as the bundle protocol restricts innovation by proposing > one homogenous, non-diverse, straitjacket for everyone. Rather as ATM did= . >=20 > Instead, the world needs to embrace innovation and move on from the > Bundle Protocol. >=20 > The bundle protocol is not about connecting different types of internets = - > other than IP and CCSDS, what other types of internets are in the picture= ? > Layering over the top just as IP layered over everything is a wellmeanin= g > early idea, nothing more. IP internetworks can be connected using.... IP. > CCSDS has to use IP on the ground, but is strongly resistant to using it > in space. CCSDS is going to have trouble getting missions to accept > layering the bundle protocol over the top of their links. The inefficienc= ies! > But the bundle protocol is the solution that CCSDS has invested in > heavily. >=20 > Given that, I can't see anyone in NASA standing up today and saying 'this= bundle > protocol really isn't much good'. Too much would be at stake politically. > It would be like standing up in the 1970s and saying 'I think this side-m= ounted > solid-booster ceramic-tiled space shuttle is quite unsafe and possibly a = rather > bad idea.' The shuttle was the one solution, and that was that. To sugges= t > otherwise would be a career-limiting moment, going against the tide. > (In hindsight, the problems with the shuttle are now obvious to layman > historians: > http://idlewords.com/2005/08/a_rocket_to_nowhere.htm ) >=20 > "It is difficult to get a man to understand something, > when his salary depends upon his not understanding it!" > -- Upton Sinclair >=20 > Our "A bundle of problems" paper [1] was intended to provide a problem > statement - when it was written, in late 2008, after first attempting to = take > the points in it to the research group. We even put 'problems' in the nam= e. > And most of our problem points were obtained through simple analysis, whi= ch > our tests rather predictably bore out. It is now 2014, and in over five y= ears > none of the problems raised have been remedied in the design of the bundl= e > protocol. Because to do so would be to admit that the bundle protocol is,= in fact, > flawed. Rather like ATM, or like the space shuttle. >=20 > And the world has moved on from ATM and from the space shuttle. > It didn't try to do them over with a version 2. >=20 > [1] http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/index.ht= ml#bundle-problems > Lloyd Wood, Wesley M. Eddy and Peter Holliday, 'A Bundle of Problems', > IEEE Aerospace Conference, Big Sky, Montana, March 2009. 16 pages. > ("the bundle protocol is not technically good" > is just my brief TL;DR summary of those 16 pages.) > http://dx.doi.org/10.1109/AERO.2009.4839384 >=20 > best regards >=20 > Lloyd Wood > http://sat-net.com/L.Wood/dtn/ > ________________________________________ > From: Templin, Fred L > Sent: Tuesday, 10 June 2014 1:45 AM > To: Wood L Dr (Electronic Eng); spencerdawkins.ietf@gmail.com; mls.ietf@= gmail.com > Cc: iesg@ietf.org; dtn@ietf.org > Subject: RE: [dtn] DTN BoF Proposal for IETF90 >=20 > Hi Lloyd, >=20 > Responding to your other points: >=20 > > CCSDS exerts lockin on space agencies. It's very resistant to market fo= rces (like, you know, > TCP/IP), > > and utterly resistant to multiple competing solutions - which is why th= e bundle protocol was > developed > > and pushed. It's rather analogous to the telcos developing ATM in the 1= 990s to meet their needs, and > > then doing that development in the ATM Forum. The IETF sat happily by, = shaking its head for the most > > part. >=20 > I don't see it at all that the bundle protocol is analogous to ATM. > ATM was about turning the Internet into "the matrix" - everything > lined up so neat and homogeneous - no room for diversity - an > innovation killer. The Internet is about accommodating diversity, > and we are surely seeing that play out with the way the Internet > has evolved. >=20 > DTN (and the bundle protocol) is about interconnecting Internets. > Let each Internet evolve according to its own characteristics, then > hook them up at the edges. BP is all about accommodating diversity. >=20 > > The question is, why should the IETF spend further time and effort for = CCSDS on the bundle protocol > to > > preserve the CCSDS bulwark against IP, where there are other things its= experts could be doing that > > benefit actual IETF protocols? The bundle protocol is politically favou= red by CCSDS, but is not > > technically good. >=20 > I don't understand "preserve the CCSDS bulwark against IP". BP is > designed to connect IP internetworks and uses actual IETF protocols. >=20 > Also, "not technically good" is not much of a technical assessment. > You have published "Bundle of Problems", and as I have said it provides > a useful problem statement to build on in a new revision of RFC5050. > Protocols evolve based on insights gained through operational experience; > none of them are perfect in their first iteration. >=20 > Thanks - Fred > fred.l.templin@boeing.com From nobody Tue Jun 10 08:44:49 2014 Return-Path: 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 D09EE1B280C; Tue, 10 Jun 2014 08:44:44 -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 yxKXq7XksoWH; Tue, 10 Jun 2014 08:44:38 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 037B51A0228; Tue, 10 Jun 2014 08:44:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s5AFia2o021222; Tue, 10 Jun 2014 08:44:36 -0700 Received: from XCH-PHX-205.sw.nos.boeing.com (xch-phx-205.sw.nos.boeing.com [137.136.238.16]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s5AFiYKT021201 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 10 Jun 2014 08:44:35 -0700 Received: from XCH-BLV-512.nw.nos.boeing.com ([169.254.12.74]) by XCH-PHX-205.sw.nos.boeing.com ([169.254.1.106]) with mapi id 14.03.0181.006; Tue, 10 Jun 2014 08:44:34 -0700 From: "Templin, Fred L" To: "iesg@ietf.org" , "dtn@ietf.org" Thread-Topic: [dtn] DTN BoF Proposal for IETF90 Thread-Index: Ac+AQa9Fez/CplZaSwyaLFpzb8tj0wAiVZ0A///Hp/D//5OnYIABipvO//qPd7CAC7TeXf//SGxA//6DxzA= Date: Tue, 10 Jun 2014 15:44:34 +0000 Message-ID: <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com>, <1401967219583.26821@surrey.ac.uk>, <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk>, <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> <1402389636710.92429@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830486EBE@XCH-BLV-512.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831830486EBE@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/geMseHkV96rXppk33sBNe8JcTKw Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 15:44:45 -0000 Let me make this clearer and decoupled from earlier discussions: Who would like to see a DTN BoF at IETF90? Thanks - Fred fred.l.templin@boeing.com From nobody Tue Jun 10 08:52:27 2014 Return-Path: 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 F30B31A01DF; Tue, 10 Jun 2014 08:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.853 X-Spam-Level: X-Spam-Status: No, score=-4.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 Ob41S4lVaBaE; Tue, 10 Jun 2014 08:52:21 -0700 (PDT) Received: from pilot.jhuapl.edu (pilot.jhuapl.edu [128.244.251.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 320FB1A01A6; Tue, 10 Jun 2014 08:52:20 -0700 (PDT) Received: from aplexcas2.dom1.jhuapl.edu (aplexcas2.dom1.jhuapl.edu [128.244.198.91]) by pilot.jhuapl.edu with smtp (TLS: TLSv1/SSLv3,128bits,RC4-MD5) id 4c00_4d00_05df91a2_62a3_47dd_96df_025ae56e0dec; Tue, 10 Jun 2014 11:52:16 -0400 Received: from aplesfreedom.dom1.jhuapl.edu ([128.244.198.204]) by aplexcas2.dom1.jhuapl.edu ([128.244.198.91]) with mapi; Tue, 10 Jun 2014 11:52:15 -0400 From: "Krupiarz, Christopher" To: "Templin, Fred L" , "iesg@ietf.org" , "dtn@ietf.org" Date: Tue, 10 Jun 2014 11:52:09 -0400 Thread-Topic: [dtn] DTN BoF Proposal for IETF90 Thread-Index: Ac+Ew/NBL0jFQX6jTX6dPRoPRhxsPw== Message-ID: References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> <1401967219583.26821@surrey.ac.uk> <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> <1402389636710.92429@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830486EBE@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/7PtYDoKZVcUp6jvG7cUiZ1CQY3I Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 15:52:23 -0000 Fred, I would like to see a DTN BoF at IETF90. Chris Krupiarz JHU/APL On 6/10/14, 11:44 AM, "Templin, Fred L" wrote: >Let me make this clearer and decoupled from earlier discussions: > >Who would like to see a DTN BoF at IETF90? > >Thanks - Fred >fred.l.templin@boeing.com > >_______________________________________________ >dtn mailing list >dtn@ietf.org >https://www.ietf.org/mailman/listinfo/dtn From nobody Tue Jun 10 08:55:37 2014 Return-Path: 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 F3B4B1A01C0; Tue, 10 Jun 2014 08:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.671 X-Spam-Level: X-Spam-Status: No, score=-0.671 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=no 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 oHOX_aIVCbmO; Tue, 10 Jun 2014 08:51:50 -0700 (PDT) Received: from mail.arces.unibo.it (mail.arces.unibo.it [137.204.143.6]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 432581A01E7; Tue, 10 Jun 2014 08:51:50 -0700 (PDT) Received: from webmail.arces.unibo.it (web.arces.unibo.it [137.204.143.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.arces.unibo.it (Postfix) with ESMTP id 158AD4137711; Tue, 10 Jun 2014 17:51:37 +0200 (CEST) MIME-Version: 1.0 Date: Tue, 10 Jun 2014 17:51:36 +0200 From: ccaini To: "Templin, Fred L" In-Reply-To: <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com>, <1401967219583.26821@surrey.ac.uk>, <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk>, <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> <1402389636710.92429@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830486EBE@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> Message-ID: <59100930efd60ede25c93b143230dd52@arces.unibo.it> X-Sender: ccaini@arces.unibo.it User-Agent: RoundCube Webmail/0.2 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 X-Arces-MailScanner-Information: Please contact the ISP for more information X-Arces-MailScanner-ID: 158AD4137711.44BB5 X-Arces-MailScanner: Found to be clean X-Arces-MailScanner-From: ccaini@arces.unibo.it Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/Lv0Fc0Tpegme5c_xoEOScgsW2cM X-Mailman-Approved-At: Tue, 10 Jun 2014 08:55:35 -0700 Cc: iesg@ietf.org, dtn@ietf.org Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 15:51:52 -0000 Dear Fred, I am in favor. Yours, Carlo Caini On Tue, 10 Jun 2014 15:44:34 +0000, "Templin, Fred L" wrote: > Let me make this clearer and decoupled from earlier discussions: > > Who would like to see a DTN BoF at IETF90? > > Thanks - Fred > fred.l.templin@boeing.com > > _______________________________________________ > dtn mailing list > dtn@ietf.org > https://www.ietf.org/mailman/listinfo/dtn From nobody Tue Jun 10 09:11:02 2014 Return-Path: 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 F289B1A01DF; Tue, 10 Jun 2014 09:10:56 -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 W0AvNKHruQA7; Tue, 10 Jun 2014 09:10:52 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFDEB1A01CB; Tue, 10 Jun 2014 09:10:46 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp02.jpl.nasa.gov [128.149.137.149]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s5AGAF8U030211 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Tue, 10 Jun 2014 09:10:15 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.217]) by ap-ehub-sp02.RES.AD.JPL ([fe80::dd85:7b07:1e36:7e3c%15]) with mapi id 14.03.0174.001; Tue, 10 Jun 2014 09:10:43 -0700 From: "Burleigh, Scott C (312G)" To: "Templin, Fred L" , "iesg@ietf.org" , "dtn@ietf.org" Thread-Topic: [dtn] DTN BoF Proposal for IETF90 Thread-Index: Ac+AQa9Fez/CplZaSwyaLFpzb8tj0wAiVZ0A///Hp/D//5OnYIABipvO//qPd7CAC7TeXf//SGxA//6DxzD//P+0Cg== Date: Tue, 10 Jun 2014 16:10:42 +0000 Message-ID: References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com>, <1401967219583.26821@surrey.ac.uk>, <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk>, <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> <1402389636710.92429@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830486EBE@XCH-BLV-512.nw.nos.boeing.com>, <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831830486F8F@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: [128.149.137.114] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/WSlewEjE-3OBafX34kjsDxzLqgM Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 16:10:57 -0000 I would like to see a DTN BoF at IETF90.=0A= =0A= Scott=0A= ________________________________________=0A= From: dtn [dtn-bounces@ietf.org] on behalf of Templin, Fred L [Fred.L.Templ= in@boeing.com]=0A= Sent: Tuesday, June 10, 2014 8:44 AM=0A= To: iesg@ietf.org; dtn@ietf.org=0A= Subject: Re: [dtn] DTN BoF Proposal for IETF90=0A= =0A= Let me make this clearer and decoupled from earlier discussions:=0A= =0A= Who would like to see a DTN BoF at IETF90?=0A= =0A= Thanks - Fred=0A= fred.l.templin@boeing.com=0A= =0A= _______________________________________________=0A= dtn mailing list=0A= dtn@ietf.org=0A= https://www.ietf.org/mailman/listinfo/dtn=0A= From nobody Tue Jun 10 09:23:31 2014 Return-Path: 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 3E4C51B2802; Tue, 10 Jun 2014 09:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.952 X-Spam-Level: X-Spam-Status: No, score=-4.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 dqVqYZhjLXNq; Tue, 10 Jun 2014 09:20:36 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A43D1B280E; Tue, 10 Jun 2014 09:20:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1402417236; x=1433953236; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=m3V2J45O8XREBcKjJqwNNztw2UZGCvZEVtVYe1E7ZtQ=; b=yiq4ajiZzBSdO2pwqTvXxyp9CvcnTKgl2Rbdo0/s+roym7WzkdZU31NM iJQ0cDkm3nZM+b0vwZbAU5LI1sZSP2HQiMz59R/H0hjPV8NfqbAgAHkEU sUMexjDwTw4J1bjwJOuD9+ziSpz/oXi4VPnxbX4h3CtUrNo+px7jZ1HV5 E=; X-IronPort-AV: E=McAfee;i="5600,1067,7464"; a="42272941" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP; 10 Jun 2014 09:20:36 -0700 X-IronPort-AV: E=Sophos;i="4.98,1009,1392192000"; d="scan'208";a="656884705" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 10 Jun 2014 09:20:35 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 10 Jun 2014 09:20:35 -0700 Message-ID: <53973051.60908@qti.qualcomm.com> Date: Tue, 10 Jun 2014 11:20:33 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "Templin, Fred L" References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com>, <1401967219583.26821@surrey.ac.uk>, <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk>, <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> <1402389636710.92429@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830486EBE@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/-4mIsXtSxBb_v9AjGzWtaJFt0wU X-Mailman-Approved-At: Tue, 10 Jun 2014 09:23:28 -0700 Cc: "iesg@ietf.org" , "dtn@ietf.org" Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 16:20:41 -0000 On 6/10/14 10:44 AM, Templin, Fred L wrote: > Let me make this clearer and decoupled from earlier discussions: > > Who would like to see a DTN BoF at IETF90? > Speaking as just one AD: That does not make it any clearer, as demonstrated by the three people who've already said, without comment, "I want a BOF". Lots of people want BOFs, but that isn't in and of itself a reason to have one. What matters here are whether there are reasons to have one (e.g., "There's real potential work here and we should talk about whether we can do it in the IETF"), reasons *not* to have one (e.g., "Getting together in a room is likely to generate lots of heat and no light and we shouldn't waste people's time"), and some evaluation of which is more likely to be true. Most of Lloyd's comments can be taken as BOF input (e.g., "The BOF should conclude that there's nothing to do here") rather than as reasons to not hold the BOF at all, and I'd like to hear from him whether there's reason to believe that the holding of the BOF itself is problematic for some reason. But having people pile on saying, "Yes, we should hold a BOF" is not useful. At least not to me. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From Vinny.Ramachandran@jhuapl.edu Tue Jun 10 09:27:28 2014 Return-Path: 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 925F11A01FB; Tue, 10 Jun 2014 09:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.853 X-Spam-Level: X-Spam-Status: No, score=-4.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 fkEXHWTdN2Jn; Tue, 10 Jun 2014 09:27:27 -0700 (PDT) Received: from piper.jhuapl.edu (piper.jhuapl.edu [128.244.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 979551A019B; Tue, 10 Jun 2014 09:27:26 -0700 (PDT) Received: from aplexcas2.dom1.jhuapl.edu (aplexcas2.dom1.jhuapl.edu [128.244.198.91]) by piper.jhuapl.edu with smtp (TLS: TLSv1/SSLv3,128bits,RC4-MD5) id 27e0_6dcf_a17aacff_2474_4dae_92e2_7c2581eeaedb; Tue, 10 Jun 2014 12:27:25 -0400 Received: from aplesfreedom.dom1.jhuapl.edu ([128.244.198.204]) by aplexcas2.dom1.jhuapl.edu ([128.244.198.91]) with mapi; Tue, 10 Jun 2014 12:26:42 -0400 From: "Ramachandran, Vignesh R. (Vinny)" To: "iesg@ietf.org" , "dtn@ietf.org" , "Templin, Fred L" Date: Tue, 10 Jun 2014 12:26:40 -0400 Thread-Topic: [dtn] DTN BoF Proposal for IETF90 Thread-Index: Ac+EyMMYYbaUPkmOSviSlrAAZ3qsfQ== Message-ID: References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> <1401967219583.26821@surrey.ac.uk> <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> <1402389636710.92429@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830486EBE@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/izJNCurURQJRBsZbbQot0HiZcps Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 16:32:34 -0000 I am also in favor. Best,=20 Vinny Ramachandran On 6/10/14 12:10 PM, "Burleigh, Scott C (312G)" wrote: >I would like to see a DTN BoF at IETF90. > >Scott >________________________________________ >From: dtn [dtn-bounces@ietf.org] on behalf of Templin, Fred L >[Fred.L.Templin@boeing.com] >Sent: Tuesday, June 10, 2014 8:44 AM >To: iesg@ietf.org; dtn@ietf.org >Subject: Re: [dtn] DTN BoF Proposal for IETF90 > >Let me make this clearer and decoupled from earlier discussions: > >Who would like to see a DTN BoF at IETF90? > >Thanks - Fred >fred.l.templin@boeing.com > >_______________________________________________ >dtn mailing list >dtn@ietf.org >https://www.ietf.org/mailman/listinfo/dtn > > From nobody Tue Jun 10 09:36:27 2014 Return-Path: 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 4DB691B2829; Tue, 10 Jun 2014 09:36:25 -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 anI5g3BSnaFy; Tue, 10 Jun 2014 09:36:23 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD0271B2821; Tue, 10 Jun 2014 09:36:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s5AGaMRT023947; Tue, 10 Jun 2014 11:36:23 -0500 Received: from XCH-PHX-405.sw.nos.boeing.com (xch-phx-405.sw.nos.boeing.com [137.136.239.44]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s5AGaD5i023401 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 10 Jun 2014 11:36:14 -0500 Received: from XCH-BLV-410.nw.nos.boeing.com (137.136.239.131) by XCH-PHX-405.sw.nos.boeing.com (137.136.239.44) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 10 Jun 2014 09:36:13 -0700 Received: from XCH-BLV-512.nw.nos.boeing.com ([169.254.12.74]) by XCH-BLV-410.nw.nos.boeing.com ([169.254.10.180]) with mapi id 14.03.0181.006; Tue, 10 Jun 2014 09:36:12 -0700 From: "Templin, Fred L" To: Pete Resnick Thread-Topic: [dtn] DTN BoF Proposal for IETF90 Thread-Index: Ac+AQa9Fez/CplZaSwyaLFpzb8tj0wAiVZ0A///Hp/D//5OnYIABipvO//qPd7CAC7TeXf//SGxA//6DxzD//IdVgP/5gOHQ Date: Tue, 10 Jun 2014 16:36:11 +0000 Message-ID: <2134F8430051B64F815C691A62D98318304870BB@XCH-BLV-512.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com>, <1401967219583.26821@surrey.ac.uk>, <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk>, <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> <1402389636710.92429@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830486EBE@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> <53973051.60908@qti.qualcomm.com> In-Reply-To: <53973051.60908@qti.qualcomm.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/8R5REHBBFCkKo0eKQrIOT0GL8s4 Cc: "iesg@ietf.org" , "dtn@ietf.org" Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 16:36:25 -0000 Hi Pete, Yes, I agree that the question called could benefit from more context. The formal BoF request is found here: http://trac.tools.ietf.org/bof/trac/wiki/WikiStart# and has the following description: "The DTN BoF will investigate interest in transitioning technologies developed in the IRTF DTN research group into standards-track activities through the formation of a new IETF working group. The BoF will present a draft working group charter, including work items based on the DTN Bundle Protocol (BP). The goal of the BoF will be to discuss the draft charter and present the candidate work items, as well as to determine the level of support for conducting the work in the IETF. The desired end state is the formation of a new working group soon after IETF90." So, perhaps the better question would be who would agree that this justification for holding a BoF has merit? Thanks - Fred fred.l.templin@boeing.com=20 > -----Original Message----- > From: Pete Resnick [mailto:presnick@qti.qualcomm.com] > Sent: Tuesday, June 10, 2014 9:21 AM > To: Templin, Fred L > Cc: iesg@ietf.org; dtn@ietf.org > Subject: Re: [dtn] DTN BoF Proposal for IETF90 >=20 > On 6/10/14 10:44 AM, Templin, Fred L wrote: > > Let me make this clearer and decoupled from earlier discussions: > > > > Who would like to see a DTN BoF at IETF90? > > >=20 > Speaking as just one AD: That does not make it any clearer, as > demonstrated by the three people who've already said, without comment, > "I want a BOF". Lots of people want BOFs, but that isn't in and of > itself a reason to have one. What matters here are whether there are > reasons to have one (e.g., "There's real potential work here and we > should talk about whether we can do it in the IETF"), reasons *not* to > have one (e.g., "Getting together in a room is likely to generate lots > of heat and no light and we shouldn't waste people's time"), and some > evaluation of which is more likely to be true. >=20 > Most of Lloyd's comments can be taken as BOF input (e.g., "The BOF > should conclude that there's nothing to do here") rather than as reasons > to not hold the BOF at all, and I'd like to hear from him whether > there's reason to believe that the holding of the BOF itself is > problematic for some reason. But having people pile on saying, "Yes, we > should hold a BOF" is not useful. At least not to me. >=20 > pr >=20 > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Tue Jun 10 09:52:56 2014 Return-Path: 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 2DA1D1A0238; Tue, 10 Jun 2014 09:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.853 X-Spam-Level: X-Spam-Status: No, score=-4.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 jGXSdIM7rRGp; Tue, 10 Jun 2014 09:52:50 -0700 (PDT) Received: from pilot.jhuapl.edu (pilot.jhuapl.edu [128.244.251.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE1911A021F; Tue, 10 Jun 2014 09:52:49 -0700 (PDT) Received: from aplexcas2.dom1.jhuapl.edu (aplexcas2.dom1.jhuapl.edu [128.244.198.91]) by pilot.jhuapl.edu with smtp (TLS: TLSv1/SSLv3,128bits,RC4-MD5) id 4be7_4255_25b02398_2d9b_466d_9cf9_26e74b7863b9; Tue, 10 Jun 2014 12:52:41 -0400 Received: from aplesfreedom.dom1.jhuapl.edu ([128.244.198.204]) by aplexcas2.dom1.jhuapl.edu ([128.244.198.91]) with mapi; Tue, 10 Jun 2014 12:52:41 -0400 From: "Krupiarz, Christopher" To: "Templin, Fred L" , Pete Resnick Date: Tue, 10 Jun 2014 12:52:37 -0400 Thread-Topic: [dtn] DTN BoF Proposal for IETF90 Thread-Index: Ac+EzGR+ShGxnDphQyiYUMFejCgipQ== Message-ID: References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> <1401967219583.26821@surrey.ac.uk> <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> <1402389636710.92429@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830486EBE@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> <53973051.60908@qti.qualcomm.com> <2134F8430051B64F815C691A62D98318304870BB@XCH-BLV-512.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D98318304870BB@XCH-BLV-512.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/rpCl_cmF_6sOhHBVDBn3nnoLIA0 Cc: "iesg@ietf.org" , "dtn@ietf.org" Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 16:52:52 -0000 I would agree that this justification for holding a BoF has merit. :) Sorry for being blunt, but after years of reading the dtn-interest mailing list, I don=B9t see how more emails on whether to hold a BoF is going to make any difference. There=B9s a group that thinks BP is a good idea; there=B9s a group that doesn=B9t. Other than resolving this through a show= of hands, I don=B9t see a path out. There is not going to be a consensus. On 6/10/14, 12:36 PM, "Templin, Fred L" wrote: >Hi Pete, > >Yes, I agree that the question called could benefit from more >context. The formal BoF request is found here: > >http://trac.tools.ietf.org/bof/trac/wiki/WikiStart# > >and has the following description: > > "The DTN BoF will investigate interest in transitioning technologies > developed in the IRTF DTN research group into standards-track >activities > through the formation of a new IETF working group. The BoF will present > a draft working group charter, including work items based on the DTN > Bundle Protocol (BP). The goal of the BoF will be to discuss the draft > charter and present the candidate work items, as well as to determine > the level of support for conducting the work in the IETF. The desired > end state is the formation of a new working group soon after IETF90." > >So, perhaps the better question would be who would agree that >this justification for holding a BoF has merit? > >Thanks - Fred >fred.l.templin@boeing.com > > >> -----Original Message----- >> From: Pete Resnick [mailto:presnick@qti.qualcomm.com] >> Sent: Tuesday, June 10, 2014 9:21 AM >> To: Templin, Fred L >> Cc: iesg@ietf.org; dtn@ietf.org >> Subject: Re: [dtn] DTN BoF Proposal for IETF90 >>=20 >> On 6/10/14 10:44 AM, Templin, Fred L wrote: >> > Let me make this clearer and decoupled from earlier discussions: >> > >> > Who would like to see a DTN BoF at IETF90? >> > >>=20 >> Speaking as just one AD: That does not make it any clearer, as >> demonstrated by the three people who've already said, without comment, >> "I want a BOF". Lots of people want BOFs, but that isn't in and of >> itself a reason to have one. What matters here are whether there are >> reasons to have one (e.g., "There's real potential work here and we >> should talk about whether we can do it in the IETF"), reasons *not* to >> have one (e.g., "Getting together in a room is likely to generate lots >> of heat and no light and we shouldn't waste people's time"), and some >> evaluation of which is more likely to be true. >>=20 >> Most of Lloyd's comments can be taken as BOF input (e.g., "The BOF >> should conclude that there's nothing to do here") rather than as reasons >> to not hold the BOF at all, and I'd like to hear from him whether >> there's reason to believe that the holding of the BOF itself is >> problematic for some reason. But having people pile on saying, "Yes, we >> should hold a BOF" is not useful. At least not to me. >>=20 >> pr >>=20 >> -- >> Pete Resnick >> Qualcomm Technologies, Inc. - +1 (858)651-4478 > >_______________________________________________ >dtn mailing list >dtn@ietf.org >https://www.ietf.org/mailman/listinfo/dtn From nobody Tue Jun 10 10:05:04 2014 Return-Path: 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 D31AF1A0234; Tue, 10 Jun 2014 10:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.853 X-Spam-Level: X-Spam-Status: No, score=-4.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 fackOEn_6z3z; Tue, 10 Jun 2014 10:05:01 -0700 (PDT) Received: from piper.jhuapl.edu (piper.jhuapl.edu [128.244.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBDF31A0040; Tue, 10 Jun 2014 10:05:00 -0700 (PDT) Received: from aplexcas1.dom1.jhuapl.edu (aplexcas1.dom1.jhuapl.edu [128.244.198.90]) by piper.jhuapl.edu with smtp (TLS: TLSv1/SSLv3,128bits,RC4-MD5) id 27f3_ae9a_f3a7e3ca_7bd2_45da_9e15_0b186b40aa97; Tue, 10 Jun 2014 13:04:51 -0400 Received: from aplesfreedom.dom1.jhuapl.edu ([128.244.198.204]) by aplexcas1.dom1.jhuapl.edu ([128.244.198.90]) with mapi; Tue, 10 Jun 2014 13:04:48 -0400 From: "Birrane, Edward J." To: "Templin, Fred L" , "iesg@ietf.org" , "dtn@ietf.org" Date: Tue, 10 Jun 2014 13:04:46 -0400 Thread-Topic: [dtn] DTN BoF Proposal for IETF90 Thread-Index: Ac+AQa9Fez/CplZaSwyaLFpzb8tj0wAiVZ0A///Hp/D//5OnYIABipvO//qPd7CAC7TeXf//SGxA//6DxzD//PBnsA== Message-ID: <329D879C76FDD04AAAE84BB1D89B39700956E92651@aplesfreedom.dom1.jhuapl.edu> References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com>, <1401967219583.26821@surrey.ac.uk>, <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk>, <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> <1402389636710.92429@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830486EBE@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/GUl8SgRF0kU8kMK6Zpt3eRscXQQ Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 17:05:03 -0000 I would like to see a DTN BoF at IETF90 and will be there to participate. -Ed --- Ed Birrane Principal Professional Staff, Space Department Johns Hopkins Applied Physics Laboratory (W) 443-778-7423 / (F) 443-228-3839 =A0=20 > -----Original Message----- > From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of Templin, Fred L > Sent: Tuesday, June 10, 2014 11:45 AM > To: iesg@ietf.org; dtn@ietf.org > Subject: Re: [dtn] DTN BoF Proposal for IETF90 >=20 > Let me make this clearer and decoupled from earlier discussions: >=20 > Who would like to see a DTN BoF at IETF90? >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > _______________________________________________ > dtn mailing list > dtn@ietf.org > https://www.ietf.org/mailman/listinfo/dtn From nobody Tue Jun 10 10:10:52 2014 Return-Path: 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 A3B671A0238; Tue, 10 Jun 2014 09:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Qan3-KY_Tf6x; Tue, 10 Jun 2014 09:58:13 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17E301A0234; Tue, 10 Jun 2014 09:58:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1402419493; x=1433955493; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=n/PeCrXtIsmIBM9kPGM6KbGFzF7Up9D9DtFBu7AcN14=; b=wtKZXdsoyf3I8sKuitvYZG/wN+xK9sgAz0LDOSzZPFaANvRlypIbB7rE x25HG9eAEe/HISrHKj2dV8yvOtj7UbLjSg3L20TnTiROmUK6JgJUONR5T ObHjQyXDGx9J1e6aZu4zoUlz1t/AUxj4IxqcvQEirxrgBn4fL0frga69o M=; X-IronPort-AV: E=McAfee;i="5600,1067,7464"; a="66676967" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth01.qualcomm.com with ESMTP; 10 Jun 2014 09:58:13 -0700 X-IronPort-AV: E=Sophos;i="4.98,1009,1392192000"; d="scan'208";a="30501774" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 10 Jun 2014 09:58:12 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 10 Jun 2014 09:58:11 -0700 Message-ID: <53973922.2040603@qti.qualcomm.com> Date: Tue, 10 Jun 2014 11:58:10 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "Templin, Fred L" References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com>, <1401967219583.26821@surrey.ac.uk>, <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk>, <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> <1402389636710.92429@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830486EBE@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> <53973051.60908@qti.qualcomm.com> <2134F8430051B64F815C691A62D98318304870BB@XCH-BLV-512.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D98318304870BB@XCH-BLV-512.nw.nos.boeing.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/eSxvTFqofmsEFEAbg3UHaQoPN_c X-Mailman-Approved-At: Tue, 10 Jun 2014 10:10:50 -0700 Cc: "iesg@ietf.org" , "dtn@ietf.org" Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 16:58:14 -0000 On 6/10/14 11:36 AM, Templin, Fred L wrote: > http://trac.tools.ietf.org/bof/trac/wiki/WikiStart# > [...] > So, perhaps the better question would be who would agree that > this justification for holding a BoF has merit? > Let's reverse it. Let's presume that people do agree that this justification for the BOF has merit. We've heard some of those voices already, and as far as I can tell nobody has said that there are too few people who care, so asking who thinks it has merit is just knocking over a straw man. The right question is who *disagrees* that there is merit in holding a BOF. If nobody does, that's good info. If there is disagreement (framed as a reason not to hold the BOF, not simply reasons to conclude that a WG should not be eventually formed), that will give proponents a chance to reply to those concerns. At this point, I don't really care how many people think there's a justification to hold the BOF. Separately, I'm happy to see the discussion of the *outcome* of the BOF continue (whether a WG is likely to be successful and produce something useful). But let's leave that separate from the discussion of whether there should be a BOF at all. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Tue Jun 10 10:15:24 2014 Return-Path: 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 9EEF91A0240; Tue, 10 Jun 2014 10:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.853 X-Spam-Level: X-Spam-Status: No, score=-4.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 eCzR9TWtQEgN; Tue, 10 Jun 2014 10:14:58 -0700 (PDT) Received: from piper.jhuapl.edu (piper.jhuapl.edu [128.244.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93E581A026B; Tue, 10 Jun 2014 10:14:53 -0700 (PDT) Received: from aplexcas1.dom1.jhuapl.edu (aplexcas1.dom1.jhuapl.edu [128.244.198.90]) by piper.jhuapl.edu with smtp (TLS: TLSv1/SSLv3,128bits,RC4-MD5) id 27e7_8d5d_ba88171d_1a78_451e_9e05_13414242366a; Tue, 10 Jun 2014 13:14:44 -0400 Received: from aplesfreedom.dom1.jhuapl.edu ([128.244.198.204]) by aplexcas1.dom1.jhuapl.edu ([128.244.198.90]) with mapi; Tue, 10 Jun 2014 13:14:34 -0400 From: "Krupiarz, Christopher" To: Pete Resnick , "Templin, Fred L" Date: Tue, 10 Jun 2014 13:14:28 -0400 Thread-Topic: [dtn] DTN BoF Proposal for IETF90 Thread-Index: Ac+Ez3ME+M62ZIE9TuOlIuQGrI4ZcA== Message-ID: References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> <1401967219583.26821@surrey.ac.uk> <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> <1402389636710.92429@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830486EBE@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> <53973051.60908@qti.qualcomm.com> <2134F8430051B64F815C691A62D98318304870BB@XCH-BLV-512.nw.nos.boeing.com> <53973922.2040603@qti.qualcomm.com> In-Reply-To: <53973922.2040603@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/Bs620j4PAXdr3GLeUYHMefeWhXQ Cc: "iesg@ietf.org" , "dtn@ietf.org" Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 17:15:03 -0000 Pete, Your answer is better than mine. That makes sense to frame it as you have it. =20 Chris On 6/10/14, 12:58 PM, "Pete Resnick" wrote: >On 6/10/14 11:36 AM, Templin, Fred L wrote: >> http://trac.tools.ietf.org/bof/trac/wiki/WikiStart# >> [...] >> So, perhaps the better question would be who would agree that >> this justification for holding a BoF has merit? >> =20 > >Let's reverse it. Let's presume that people do agree that this >justification for the BOF has merit. We've heard some of those voices >already, and as far as I can tell nobody has said that there are too few >people who care, so asking who thinks it has merit is just knocking over >a straw man. > >The right question is who *disagrees* that there is merit in holding a >BOF. If nobody does, that's good info. If there is disagreement (framed >as a reason not to hold the BOF, not simply reasons to conclude that a >WG should not be eventually formed), that will give proponents a chance >to reply to those concerns. At this point, I don't really care how many >people think there's a justification to hold the BOF. > >Separately, I'm happy to see the discussion of the *outcome* of the BOF >continue (whether a WG is likely to be successful and produce something >useful). But let's leave that separate from the discussion of whether >there should be a BOF at all. > >pr > >--=20 >Pete Resnick >Qualcomm Technologies, Inc. - +1 (858)651-4478 > >_______________________________________________ >dtn mailing list >dtn@ietf.org >https://www.ietf.org/mailman/listinfo/dtn From nobody Tue Jun 10 10:46:36 2014 Return-Path: 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 D38B21A020F; Tue, 10 Jun 2014 10:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.853 X-Spam-Level: X-Spam-Status: No, score=-4.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 gH5yw50wWKzd; Tue, 10 Jun 2014 10:46:11 -0700 (PDT) Received: from piper.jhuapl.edu (piper.jhuapl.edu [128.244.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAD1B1A0180; Tue, 10 Jun 2014 10:46:10 -0700 (PDT) Received: from aplexcas1.dom1.jhuapl.edu (aplexcas1.dom1.jhuapl.edu [128.244.198.90]) by piper.jhuapl.edu with smtp (TLS: TLSv1/SSLv3,128bits,RC4-MD5) id 27cd_5f22_e1d87a61_09fe_469a_91ff_735a8446d4b4; Tue, 10 Jun 2014 13:46:00 -0400 Received: from aplesfreedom.dom1.jhuapl.edu ([128.244.198.204]) by aplexcas1.dom1.jhuapl.edu ([128.244.198.90]) with mapi; Tue, 10 Jun 2014 13:45:57 -0400 From: "Birrane, Edward J." To: Pete Resnick , "Templin, Fred L" Date: Tue, 10 Jun 2014 13:45:56 -0400 Thread-Topic: [dtn] DTN BoF Proposal for IETF90 Thread-Index: Ac+EyFKN81poJbFjQWaxZTWXLFopNgABgGpA Message-ID: <329D879C76FDD04AAAE84BB1D89B39700956E9266F@aplesfreedom.dom1.jhuapl.edu> References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com>, <1401967219583.26821@surrey.ac.uk>, <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk>, <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> <1402389636710.92429@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830486EBE@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> <53973051.60908@qti.qualcomm.com> In-Reply-To: <53973051.60908@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/GMl6hORRJ1e5e1GJsAKpMQ68wto Cc: "iesg@ietf.org" , "dtn@ietf.org" Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 17:46:14 -0000 Pete, Completely agree that it would be useful to understand any position advo= cating a BoF as undesirable, separate from a discussion on the merits of a = DTN IETF WG. I think Fred has identified a useful charter describing useful work that = could be accomplished in a working group. I (perhaps naively) interpret res= ponses of "I would like to see a BoF" as an endorsement of his concept, goa= ls, milestones, and likely impact. As you point out, simple "voting" is not= helpful, but a past criticism has been that there is disagreement between = the space and terrestrial communities in this area and showing a diversity = of support for the proposed work is input. =20 So, let me clarify my previous comment of "I would support a BoF": I would support a BoF in both time and resources because I believe that F= red's charter, to particularly include the proposed Bpv7, security standard= s, and management standards, represent real potential work that would resul= t in adoptable, deployable RFCs. I think a BoF should inform the discussion= of the impact of such a working group, and since I expect that impact to b= e > 0, I am willing to devote time and effort to the standards process and = to help shepherd the adoption of the outputs of the working group in areas = where I am able and where it is appropriate. I am unaware of a position that states that there is no need to alter 505= 0, that security standards are either solved or unnecessary, or that existi= ng management solutions scale with disruption or delay. It has been express= ed to me, several times, the value of a non-experimental RFC in the context= of operational deployment. So I would truly be surprised if there was a co= nsensus that the proposed work is not necessary. Perhaps further discussion of the desired "exit criteria" of the BOF meet= ing would also be useful? -Ed --- Ed Birrane Principal Professional Staff, Space Department Johns Hopkins Applied Physics Laboratory (W) 443-778-7423 / (F) 443-228-3839 =A0=20 > -----Original Message----- > From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of Pete Resnick > Sent: Tuesday, June 10, 2014 12:21 PM > To: Templin, Fred L > Cc: iesg@ietf.org; dtn@ietf.org > Subject: Re: [dtn] DTN BoF Proposal for IETF90 >=20 > On 6/10/14 10:44 AM, Templin, Fred L wrote: > > Let me make this clearer and decoupled from earlier discussions: > > > > Who would like to see a DTN BoF at IETF90? > > >=20 > Speaking as just one AD: That does not make it any clearer, as demonstrat= ed > by the three people who've already said, without comment, "I want a BOF". > Lots of people want BOFs, but that isn't in and of itself a reason to hav= e one. > What matters here are whether there are reasons to have one (e.g., > "There's real potential work here and we should talk about whether we can > do it in the IETF"), reasons *not* to have one (e.g., "Getting together i= n a > room is likely to generate lots of heat and no light and we shouldn't was= te > people's time"), and some evaluation of which is more likely to be true. >=20 > Most of Lloyd's comments can be taken as BOF input (e.g., "The BOF should > conclude that there's nothing to do here") rather than as reasons to not = hold > the BOF at all, and I'd like to hear from him whether there's reason to b= elieve > that the holding of the BOF itself is problematic for some reason. But ha= ving > people pile on saying, "Yes, we should hold a BOF" is not useful. At leas= t not > to me. >=20 > pr >=20 > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 >=20 > _______________________________________________ > dtn mailing list > dtn@ietf.org > https://www.ietf.org/mailman/listinfo/dtn From nobody Tue Jun 10 11:08:43 2014 Return-Path: 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 3B47F1A020F for ; Tue, 10 Jun 2014 11:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 w0nLfnK0ix7y for ; Tue, 10 Jun 2014 11:08:20 -0700 (PDT) Received: from mailout1.zih.tu-dresden.de (mailout1.zih.tu-dresden.de [141.30.67.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1FF1A0177 for ; Tue, 10 Jun 2014 11:08:20 -0700 (PDT) Received: from mail.zih.tu-dresden.de ([141.76.14.4]) by mailout1.zih.tu-dresden.de with esmtp (Exim 4.63) (envelope-from ) id 1WuQSy-0006Un-Rs for dtn@ietf.org; Tue, 10 Jun 2014 20:08:19 +0200 Received: from server-50 ([10.30.8.50]) by server-50.mailclusterdns.zih.tu-dresden.de with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (envelope-from ) id 1WuQSy-0007CC-Ob for dtn@ietf.org; Tue, 10 Jun 2014 20:08:12 +0200 Received: from p4FF1DA37.dip0.t-ipconnect.de (p4FF1DA37.dip0.t-ipconnect.de [79.241.218.55]) by mail.zih.tu-dresden.de (Horde Framework) with HTTP; Tue, 10 Jun 2014 18:08:12 +0000 Date: Tue, 10 Jun 2014 18:08:12 +0000 Message-ID: <20140610180812.Horde._TqvsFPaV6soR57fslkBug1@mail.zih.tu-dresden.de> From: Marius Feldmann To: dtn@ietf.org References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> <1401967219583.26821@surrey.ac.uk> <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> <1402389636710.92429@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830486EBE@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> User-Agent: Internet Messaging Program (IMP) H5 (6.1.6) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-TUD-Virus-Scanned: mailout1.zih.tu-dresden.de Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/fAOQv4zzLaAO6Nu-mBTPRF1lpPM Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 18:08:24 -0000 I would like to see a DTN BoF at IETF90 (though I can only participate remotely). Marius Zitat von "Templin, Fred L" : > Let me make this clearer and decoupled from earlier discussions: > > Who would like to see a DTN BoF at IETF90? > > Thanks - Fred > fred.l.templin@boeing.com > > _______________________________________________ > dtn mailing list > dtn@ietf.org > https://www.ietf.org/mailman/listinfo/dtn From nobody Tue Jun 10 15:54:11 2014 Return-Path: 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 3D39D1A0264; Tue, 10 Jun 2014 15:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 dm3vcYIDkIqj; Tue, 10 Jun 2014 15:54:06 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CB9A1A00A5; Tue, 10 Jun 2014 15:54:05 -0700 (PDT) Received: from [85.158.137.99:4516] by server-13.bemta-3.messagelabs.com id 72/E7-18692-A8C87935; Tue, 10 Jun 2014 22:54:02 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-5.tower-217.messagelabs.com!1402440842!16690083!1 X-Originating-IP: [131.227.200.43] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26450 invoked from network); 10 Jun 2014 22:54:02 -0000 Received: from exht022p.surrey.ac.uk (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-5.tower-217.messagelabs.com with AES128-SHA encrypted SMTP; 10 Jun 2014 22:54:02 -0000 Received: from EXHY012V.surrey.ac.uk (131.227.201.103) by EXHT022P.surrey.ac.uk (131.227.200.43) with Microsoft SMTP Server (TLS) id 8.3.342.0; Tue, 10 Jun 2014 23:54:01 +0100 Received: from emea01-am1-obe.outbound.protection.outlook.com (131.227.201.241) by EXHY012v.surrey.ac.uk (131.227.201.103) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 10 Jun 2014 23:54:01 +0100 Received: from AMSPR06MB439.eurprd06.prod.outlook.com (10.242.23.19) by AMSPR06MB437.eurprd06.prod.outlook.com (10.242.23.11) with Microsoft SMTP Server (TLS) id 15.0.959.24; Tue, 10 Jun 2014 22:54:00 +0000 Received: from AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) by AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) with mapi id 15.00.0954.000; Tue, 10 Jun 2014 22:54:00 +0000 From: To: , Thread-Topic: [dtn] DTN BoF Proposal for IETF90 Thread-Index: Ac+AQa9Fez/CplZaSwyaLFpzb8tj0wAiVZ0A///Hp/D//5OnYIABipvO//qPd7CAC7TeXf//SGxA//6DxzD//PytgP/59PyA//Pj1AD/52XgLw== Date: Tue, 10 Jun 2014 22:54:00 +0000 Message-ID: <1402440838737.37492@surrey.ac.uk> References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com>, <1401967219583.26821@surrey.ac.uk>, <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk>, <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> <1402389636710.92429@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830486EBE@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> <53973051.60908@qti.qualcomm.com> <2134F8430051B64F815C691A62D98318304870BB@XCH-BLV-512.nw.nos.boeing.com>, <53973922.2040603@qti.qualcomm.com> In-Reply-To: <53973922.2040603@qti.qualcomm.com> Accept-Language: en-AU, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [124.149.114.231] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0238AEEDB0 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(24454002)(199002)(189002)(479174003)(377454003)(66066001)(80022001)(21056001)(64706001)(20776003)(15975445006)(79102001)(2656002)(74482001)(86362001)(74662001)(101416001)(74502001)(31966008)(77982001)(83072002)(76176999)(15202345003)(54356999)(83322001)(19580395003)(99396002)(19580405001)(76482001)(85852003)(77096999)(561944003)(93886003)(81342001)(87936001)(81542001)(36756003)(50986999)(46102001)(92726001)(92566001)(4396001); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR06MB437; H:AMSPR06MB439.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: surrey.ac.uk does not designate permitted sender hosts) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: AMSPR06MB437.eurprd06.prod.outlook.com X-CrossPremisesHeadersFiltered: EXHY012v.surrey.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/7DXL2B9o5fOzQNJ0zpsUukaQOCk Cc: iesg@ietf.org, dtn@ietf.org Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 22:54:08 -0000 Ed says:=0A= > I (perhaps naively) interpret responses of "I would like to see a BoF" = =0A= > as an endorsement of his concept, goals, milestones, and likely impact. = =0A= =0A= as do I. And I do not endorse the outlined concept, the stated goals,=0A= or the milestones, and believe that there will be no useful impact.=0A= =0A= Pete says:=0A= >The right question is who *disagrees* that there is merit in holding a=0A= >BOF. If nobody does, that's good info. If there is disagreement (framed=0A= >as a reason not to hold the BOF, not simply reasons to conclude that a=0A= >WG should not be eventually formed), that will give proponents a chance=0A= >to reply to those concerns. At this point, I don't really care how many=0A= >people think there's a justification to hold the BOF.=0A= =0A= This DTN BOF aims to set up a WG to bring the bundle protocol to standards= =0A= track. I believe there is no merit in holding this BOF, because there=0A= is no merit in bringing the bundle protocol to IETF standards track.=0A= I've previously given my reasoning.=0A= =0A= There are a number of topics asking for BOFs and time at IETF 90:=0A= http://tools.ietf.org/bof/trac/=0A= =0A= I view the DTN BOF as the least deserving of time, and would not=0A= want to disadvantage another BOF request simply to give time to=0A= DTN over that BOF. DTN is, in my view, the least deserving of those=0A= requests.=0A= =0A= There's already a DTNRG where the bundle protocol has gotten =0A= time and attention. I would be in favour of a last DTNRG=0A= meeting at a following IETF to wrap up any remaining items,=0A= and then shutting that research group down as concluded.=0A= =0A= Lloyd Wood=0A= http://sat-net.com/L.Wood/dtn=0A= ________________________________________=0A= From: dtn on behalf of Pete Resnick =0A= Sent: Wednesday, 11 June 2014 2:58 AM=0A= To: Templin, Fred L=0A= Cc: iesg@ietf.org; dtn@ietf.org=0A= Subject: Re: [dtn] DTN BoF Proposal for IETF90=0A= =0A= On 6/10/14 11:36 AM, Templin, Fred L wrote:=0A= > http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#=0A= > [...]=0A= > So, perhaps the better question would be who would agree that=0A= > this justification for holding a BoF has merit?=0A= >=0A= =0A= Let's reverse it. Let's presume that people do agree that this=0A= justification for the BOF has merit. We've heard some of those voices=0A= already, and as far as I can tell nobody has said that there are too few=0A= people who care, so asking who thinks it has merit is just knocking over=0A= a straw man.=0A= =0A= The right question is who *disagrees* that there is merit in holding a=0A= BOF. If nobody does, that's good info. If there is disagreement (framed=0A= as a reason not to hold the BOF, not simply reasons to conclude that a=0A= WG should not be eventually formed), that will give proponents a chance=0A= to reply to those concerns. At this point, I don't really care how many=0A= people think there's a justification to hold the BOF.=0A= =0A= Separately, I'm happy to see the discussion of the *outcome* of the BOF=0A= continue (whether a WG is likely to be successful and produce something=0A= useful). But let's leave that separate from the discussion of whether=0A= there should be a BOF at all.=0A= =0A= pr=0A= =0A= --=0A= Pete Resnick=0A= Qualcomm Technologies, Inc. - +1 (858)651-4478=0A= =0A= _______________________________________________=0A= dtn mailing list=0A= dtn@ietf.org=0A= https://www.ietf.org/mailman/listinfo/dtn=0A= From nobody Tue Jun 10 19:15:55 2014 Return-Path: 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 2D05D1A0341; Tue, 10 Jun 2014 19:15:53 -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 8y6LJ6dDYMGV; Tue, 10 Jun 2014 19:15:51 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B35141A032D; Tue, 10 Jun 2014 19:15:51 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp01.jpl.nasa.gov [128.149.137.148]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s5B2FH7Q029271 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Tue, 10 Jun 2014 19:15:18 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.217]) by ap-ehub-sp01.RES.AD.JPL ([169.254.3.182]) with mapi id 14.03.0174.001; Tue, 10 Jun 2014 19:15:47 -0700 From: "Burleigh, Scott C (312G)" To: Pete Resnick , "Templin, Fred L" Thread-Topic: [dtn] DTN BoF Proposal for IETF90 Thread-Index: Ac+AQa9Fez/CplZaSwyaLFpzb8tj0wAiVZ0A///Hp/D//5OnYIABipvO//qPd7CAC7TeXf//SGxA//6DxzD//IdVgP/5gOHQ//KFCAD/5O35XQ== Date: Wed, 11 Jun 2014 02:15:46 +0000 Message-ID: References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com>, <1401967219583.26821@surrey.ac.uk>, <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk>, <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> <1402389636710.92429@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830486EBE@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> <53973051.60908@qti.qualcomm.com> <2134F8430051B64F815C691A62D98318304870BB@XCH-BLV-512.nw.nos.boeing.com>, <53973922.2040603@qti.qualcomm.com> In-Reply-To: <53973922.2040603@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.114] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/IKMflvwfy947tr0RQRl_l4vrGVM Cc: "iesg@ietf.org" , "dtn@ietf.org" Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 02:15:53 -0000 Lloyd's concern, as I understand it, is that there is limited time for BoFs= at IETF90; if time is allotted to a BoF whose topic is the possible format= ion of a standards-track working group for the DTN protocols then some othe= r worthy BoF request must be denied.=0A= =0A= That seems like a valid concern to me, but I nonetheless think that a DTN B= oF should be scheduled at IETF90. My reason for this is that I think formi= ng a working group aimed at standardizing the DTN protocols for the Interne= t is important and worthwhile. Whether it is more important and worthwhile= than the objectives of the other IETF90 BoF requests is a topic that we ha= ven't explored on this list. I'm happy to try to contribute to that discus= sion if that's the discussion we need to have. But in the meantime I can t= ry to explain briefly my opinion of the importance of forming a DTN working= group in IETF.=0A= =0A= My interest in DTN does indeed originally stem from wanting to be able to i= ntegrate space flight mission communications with Internet communications o= n Earth. The best way to do that seemed -- and seems -- to me to develop s= tandardized end-to-end protocols above the Internet transport layer. As Ll= oyd has pointed out, the main protocol we have been working on resides at t= he same layer of the stack as HTTP. But where HTTP was (as I understand it= ) specifically designed for the exchange of hypertext between clients and s= ervers, Bundle Protocol and its supporting protocols were instead specifica= lly designed for the peer-to-peer exchange of data of arbitrary semantics w= here the round-trip time between peers might routinely -- for one reason or= another -- be measured in milliseconds, minutes, or days at various times.= =0A= =0A= It may well be possible to adapt HTTP to accomplish this purpose, just as I= expect it would be possible to use Bundle Protocol to exchange hypertext b= etween clients and servers. But in each case I believe there are carefully= considered operational features that make the protocols particularly well-= suited to the jobs they were designed to do. So I think the Internet would= be well served by formal standardization of the protocols that have been d= eveloped in the DTN Research Group.=0A= =0A= Scott=0A= ________________________________________=0A= From: dtn [dtn-bounces@ietf.org] on behalf of Pete Resnick [presnick@qti.qu= alcomm.com]=0A= Sent: Tuesday, June 10, 2014 9:58 AM=0A= To: Templin, Fred L=0A= Cc: iesg@ietf.org; dtn@ietf.org=0A= Subject: Re: [dtn] DTN BoF Proposal for IETF90=0A= =0A= On 6/10/14 11:36 AM, Templin, Fred L wrote:=0A= > http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#=0A= > [...]=0A= > So, perhaps the better question would be who would agree that=0A= > this justification for holding a BoF has merit?=0A= >=0A= =0A= Let's reverse it. Let's presume that people do agree that this=0A= justification for the BOF has merit. We've heard some of those voices=0A= already, and as far as I can tell nobody has said that there are too few=0A= people who care, so asking who thinks it has merit is just knocking over=0A= a straw man.=0A= =0A= The right question is who *disagrees* that there is merit in holding a=0A= BOF. If nobody does, that's good info. If there is disagreement (framed=0A= as a reason not to hold the BOF, not simply reasons to conclude that a=0A= WG should not be eventually formed), that will give proponents a chance=0A= to reply to those concerns. At this point, I don't really care how many=0A= people think there's a justification to hold the BOF.=0A= =0A= Separately, I'm happy to see the discussion of the *outcome* of the BOF=0A= continue (whether a WG is likely to be successful and produce something=0A= useful). But let's leave that separate from the discussion of whether=0A= there should be a BOF at all.=0A= =0A= pr=0A= =0A= --=0A= Pete Resnick=0A= Qualcomm Technologies, Inc. - +1 (858)651-4478=0A= =0A= _______________________________________________=0A= dtn mailing list=0A= dtn@ietf.org=0A= https://www.ietf.org/mailman/listinfo/dtn=0A= From nobody Tue Jun 10 19:49:20 2014 Return-Path: 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 7EC6D1A046A; Tue, 10 Jun 2014 19:49:15 -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 LjSW1FjAWsMs; Tue, 10 Jun 2014 19:49:13 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEC5D1A035E; Tue, 10 Jun 2014 19:49:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s5B2nBpR014705; Tue, 10 Jun 2014 19:49:11 -0700 Received: from XCH-PHX-303.sw.nos.boeing.com (xch-phx-303.sw.nos.boeing.com [137.136.239.24]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s5B2n5JD014679 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 10 Jun 2014 19:49:05 -0700 Received: from XCH-BLV-512.nw.nos.boeing.com ([169.254.12.74]) by XCH-PHX-303.sw.nos.boeing.com ([169.254.6.13]) with mapi id 14.03.0181.006; Tue, 10 Jun 2014 19:49:04 -0700 From: "Templin, Fred L" To: "Burleigh, Scott C (312G)" , Pete Resnick Thread-Topic: [dtn] DTN BoF Proposal for IETF90 Thread-Index: Ac+AQa9Fez/CplZaSwyaLFpzb8tj0wAiVZ0A///Hp/D//5OnYIABipvO//qPd7CAC7TeXf//SGxA//6DxzD//IdVgP/5gOHQ//KFCAD/5O35Xf/J0Lqw Date: Wed, 11 Jun 2014 02:49:04 +0000 Message-ID: <2134F8430051B64F815C691A62D983183048887B@XCH-BLV-512.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com>, <1401967219583.26821@surrey.ac.uk>, <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk>, <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> <1402389636710.92429@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830486EBE@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> <53973051.60908@qti.qualcomm.com> <2134F8430051B64F815C691A62D98318304870BB@XCH-BLV-512.nw.nos.boeing.com>, <53973922.2040603@qti.qualcomm.com> In-Reply-To: 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/GytYHk-BOIdTP2FfsPmwiz3L9Ww Cc: "iesg@ietf.org" , "dtn@ietf.org" Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 02:49:15 -0000 I would just add that the technologies that are subject of this proposed BoF are represented by far more interoperable running code and open functional specifications than is typical for new starts. So, there is reason to believe that an eventual working group would have a substantial starting basis to build on. However, I do not see that it is our business to speculate as to how much room is available for BoFs for the IETF90 schedule, nor which BoFs are more deserving than others. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Burleigh, Scott C (312G) [mailto:scott.c.burleigh@jpl.nasa.gov] > Sent: Tuesday, June 10, 2014 7:16 PM > To: Pete Resnick; Templin, Fred L > Cc: iesg@ietf.org; dtn@ietf.org > Subject: RE: [dtn] DTN BoF Proposal for IETF90 >=20 > Lloyd's concern, as I understand it, is that there is limited time for Bo= Fs at IETF90; if time is > allotted to a BoF whose topic is the possible formation of a standards-tr= ack working group for the DTN > protocols then some other worthy BoF request must be denied. >=20 > That seems like a valid concern to me, but I nonetheless think that a DTN= BoF should be scheduled at > IETF90. My reason for this is that I think forming a working group aimed= at standardizing the DTN > protocols for the Internet is important and worthwhile. Whether it is mo= re important and worthwhile > than the objectives of the other IETF90 BoF requests is a topic that we h= aven't explored on this list. > I'm happy to try to contribute to that discussion if that's the discussio= n we need to have. But in > the meantime I can try to explain briefly my opinion of the importance of= forming a DTN working group > in IETF. >=20 > My interest in DTN does indeed originally stem from wanting to be able to= integrate space flight > mission communications with Internet communications on Earth. The best w= ay to do that seemed -- and > seems -- to me to develop standardized end-to-end protocols above the Int= ernet transport layer. As > Lloyd has pointed out, the main protocol we have been working on resides = at the same layer of the > stack as HTTP. But where HTTP was (as I understand it) specifically desi= gned for the exchange of > hypertext between clients and servers, Bundle Protocol and its supporting= protocols were instead > specifically designed for the peer-to-peer exchange of data of arbitrary = semantics where the round- > trip time between peers might routinely -- for one reason or another -- b= e measured in milliseconds, > minutes, or days at various times. >=20 > It may well be possible to adapt HTTP to accomplish this purpose, just as= I expect it would be > possible to use Bundle Protocol to exchange hypertext between clients and= servers. But in each case I > believe there are carefully considered operational features that make the= protocols particularly well- > suited to the jobs they were designed to do. So I think the Internet wou= ld be well served by formal > standardization of the protocols that have been developed in the DTN Rese= arch Group. >=20 > Scott > ________________________________________ > From: dtn [dtn-bounces@ietf.org] on behalf of Pete Resnick [presnick@qti.= qualcomm.com] > Sent: Tuesday, June 10, 2014 9:58 AM > To: Templin, Fred L > Cc: iesg@ietf.org; dtn@ietf.org > Subject: Re: [dtn] DTN BoF Proposal for IETF90 >=20 > On 6/10/14 11:36 AM, Templin, Fred L wrote: > > http://trac.tools.ietf.org/bof/trac/wiki/WikiStart# > > [...] > > So, perhaps the better question would be who would agree that > > this justification for holding a BoF has merit? > > >=20 > Let's reverse it. Let's presume that people do agree that this > justification for the BOF has merit. We've heard some of those voices > already, and as far as I can tell nobody has said that there are too few > people who care, so asking who thinks it has merit is just knocking over > a straw man. >=20 > The right question is who *disagrees* that there is merit in holding a > BOF. If nobody does, that's good info. If there is disagreement (framed > as a reason not to hold the BOF, not simply reasons to conclude that a > WG should not be eventually formed), that will give proponents a chance > to reply to those concerns. At this point, I don't really care how many > people think there's a justification to hold the BOF. >=20 > Separately, I'm happy to see the discussion of the *outcome* of the BOF > continue (whether a WG is likely to be successful and produce something > useful). But let's leave that separate from the discussion of whether > there should be a BOF at all. >=20 > pr >=20 > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 >=20 > _______________________________________________ > dtn mailing list > dtn@ietf.org > https://www.ietf.org/mailman/listinfo/dtn From nobody Wed Jun 11 05:50:17 2014 Return-Path: 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 5BDBF1A0278; Wed, 11 Jun 2014 05:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 K8xef55W_HID; Wed, 11 Jun 2014 05:49:42 -0700 (PDT) Received: from b.b.painless.aa.net.uk (b.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 800681A0263; Wed, 11 Jun 2014 05:49:42 -0700 (PDT) Received: from mightyatom.folly.org.uk ([81.187.254.250]) by b.painless.aa.net.uk with esmtp (Exim 4.72) (envelope-from ) id 1Wuhy7-0006wr-UV; Wed, 11 Jun 2014 13:49:36 +0100 From: Elwyn Davies To: "Templin, Fred L" In-Reply-To: <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> , <1401967219583.26821@surrey.ac.uk> , <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk> , <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> <1402389636710.92429@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830486EBE@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> Content-Type: text/plain Organization: Folly Consulting Date: Wed, 11 Jun 2014 13:49:30 +0100 Message-Id: <1402490970.2995.76.camel@mightyatom> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/Yb7VfuiGb5HZP9Zn_sljPGSOi98 Cc: "iesg@ietf.org" , "dtn@ietf.org" Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 12:49:49 -0000 Hi. I would be happy to see a BoF at IETF90, but I think we need to be clearer about what would be the expected usage of the work that would come out a WG that was formed as a result. I have the impression from what I have seen on the mailing list that the work might well be dominated by the requirements of the space use case but the charter is currently silent on the intentions. Personally I am keen to see DTN used in space but I am also still a believer in terrestrial usage. There is clearly a tension between getting something done quickly and efficiently for the space case where there is potential for (relatively) short term (nothing is really that short term in space exploration!) deployment, and updating the BP etc in a way that will also move along the terrestrial usage where the requirements are slightly different and not so well set in concrete. The lack of clarity over intended usage could well have a bad impact on the WG if it results in disagreements over the specifications. It also shows up in what is *not* in the charter. most notably in the absence of any consideration of how to route the bundles that BPbis handles. IMO a DTN system that doen't address bundle routing is only half-baked. There seems to be a reasonable concensus that Contact Graph Routing (CGR) would be appropriate for the space case. Now this is primarily a centralized all-informed oracle based system so there isn't the need to exchange advertisements and such like but it strikes me that there are aspects of a CGR that might need standardization such as disseminating contact and route information to remote nodes, notifying the oracle of traffic requests and ideas for handling failures such as notifying the oracle that things didn't work as intended. I therefore think that work on CGR should be part of the charter at least (I understood that CCSDS was thinking about it but that work seems to have stalled). On the terretrial front, one of the major barriers to progress has been the lack of an effective, reasonably general purpose, opportunistic routing protocol despite the immense amount of academic work that has been put in. I believe (and am trying to put some concrete answers into practice) that this is a soluble problem but it limits the current deployability of DTN outside the space sector. It may be that this problem is seen as a show stopper for the terrestrial use case and, hence, that the WG should be entirely devoted to the space case. Personally I think this would be a shame and I would be less enthusiastic about working with this limited agenda. However, if that agenda is the case, the charter ought to be clear and the IESG needs to be aware of where things are going. BTW I concur with Lars that the timescales in the charter proposal are wildly optimistic. Regards, Elwyn On Tue, 2014-06-10 at 15:44 +0000, Templin, Fred L wrote: > Let me make this clearer and decoupled from earlier discussions: > > Who would like to see a DTN BoF at IETF90? > > Thanks - Fred > fred.l.templin@boeing.com > > _______________________________________________ > dtn mailing list > dtn@ietf.org > https://www.ietf.org/mailman/listinfo/dtn From nobody Wed Jun 11 06:49:19 2014 Return-Path: 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 D8D181A00A2; Wed, 11 Jun 2014 06:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 1qgRjbCPpO_i; Wed, 11 Jun 2014 06:49:16 -0700 (PDT) Received: from mail.ibr.cs.tu-bs.de (mail.ibr.cs.tu-bs.de [134.169.34.52]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A81F1A0088; Wed, 11 Jun 2014 06:49:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.ibr.cs.tu-bs.de (Postfix) with ESMTP id C31D3182ED7; Wed, 11 Jun 2014 15:49:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ibr.cs.tu-bs.de; h=x-mailer:references:message-id:content-transfer-encoding:date :date:in-reply-to:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=key1; t= 1402494552; x=1404308953; bh=1Q8OMggsh5go7aTuDKOBu0ThgQD9l5DSnhV LGGjT59k=; b=bkK1GwmjRAWVoPLxBom5J6i+TUQKQmjkIcyIiCMeAoGLGPQ86yf 6L9Eg6EK8FE92mkUu6Z62Fak/6CtwPgUAbMfnQ/N7ZMjiI+l3ASCWLGAimN0mh+b ocaQdZ/3PhikitvK0uO61c6BCr/JbiKlE58NX6oSYGyX0pY1w6XcB5QI= X-Virus-Scanned: Debian amavisd-new at ibr.cs.tu-bs.de Received: from mail.ibr.cs.tu-bs.de ([127.0.0.1]) by localhost (mail.ibr.cs.tu-bs.de [127.0.0.1]) (amavisd-new, port 10026) with LMTP id sm8iZ5FtjapR; Wed, 11 Jun 2014 15:49:12 +0200 (CEST) Received: from [IPv6:2001:6f8:900:8d3d:adfa:60d0:faa1:b60] (unknown [IPv6:2001:6f8:900:8d3d:adfa:60d0:faa1:b60]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schildt@ibr.cs.tu-bs.de) by mail.ibr.cs.tu-bs.de (Postfix) with ESMTPSA id 2FC4E182ECC; Wed, 11 Jun 2014 15:49:12 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Sebastian Schildt In-Reply-To: <1402490970.2995.76.camel@mightyatom> Date: Wed, 11 Jun 2014 15:49:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> , <1401967219583.26821@surrey.ac.uk> , <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk> , <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> <1402389636710.92429@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830486EBE@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> <1402490970.2995.76.camel@mightyatom> To: Elwyn Davies X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/QJtuCmQaG7EghfwahfygWezinAw Cc: "iesg@ietf.org" , "dtn@ietf.org" Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 13:49:19 -0000 Hello everybody! On 11 Jun 2014, at 14:49, Elwyn Davies wrote: >=20 > Personally I am keen to see DTN used in space but I am also still a > believer in terrestrial usage. There is clearly a tension between > getting something done quickly and efficiently for the space case = where > there is potential for (relatively) short term (nothing is really that > short term in space exploration!) deployment, and updating the BP etc = in > a way that will also move along the terrestrial usage where the > requirements are slightly different and not so well set in concrete. While it is true that requirements for space scenarios seems to be much = clearer, we (IBR) have been using the BP solely for various terrestial = scenarios over the last years. While not everything is perfect, we had a = profound feeling that the BP is sort of "good enough". Of course we = followed the various semi-regular what-is-time? what-is-end-to-end? = SDNV-Flexble-or-Epic-Fail? discussions on dtn-interest. The key point = is: Mostly we _followed_, not so much participated. Of course there have = been some heated lunch break discussions over all these things within = our group, but for the most part it did not matter that much in the = application. Consider, that today we use "responsive" desktop-like applications = written in Javascript using text-based JSON formats over non-latency = optimized links using HTTP protocols. That is (literally) wrong on so = many levels. Some hacky/impressive engeneering such as WebSockets/SPDY = and ridicoulously optimized JavaScript engines etc. are used to make it = less painful. But it works fine, doesn't it? So we feel, compared to = that, we are of to quite a good start with the BP! So generally, we are in favor of the idea of slightly = polishing/repairing the BP without starting from scratch. Which is the = correct path or institution to do it, and whether the BoF is the correct = way to go, we can not say. The inner workings of the IETF and stuff are = magical to us. However, the point is: I feel, even if the following efforts will have a = slight focus on space applications, not much will be lost for = terrestrial applications, if things are still based on the BP. = Especially if the main difference is seen as routing: >=20 > The lack of clarity over intended usage could well have a bad impact = on > the WG if it results in disagreements over the specifications. It = also > shows up in what is *not* in the charter. most notably in the absence = of > any consideration of how to route the bundles that BPbis handles. IMO = a > DTN system that doen't address bundle routing is only half-baked.=20 I know we had some discussion at some conference or workshop about this. = I believe routing (as in "a better Epidemic/Prophet") is not neccessary = for terrestrial DTN applications. Most of the time we have small scale = networks (Flooding/Gossipping is fine), or highly application-specific = solutions (nobody would use a general purpose routing mechanism if the = application is public transportation). For interconnection we have the = internet/ip, so we just need naming there. I know, we can have the = discussion and agree to disagree, so I would rephrase it like this "IMO a DTN system that doesn't address bundle routing is only = half-baked. " Yes, defintely. At least you should know how to get stuff from A to B in = your application. However I would add "Routing is of no concern for the core BP(bis) specification" Just as the IPv(4/6) main specs do not say much about routing.=20 So there could be specifications on top specifying routing mechanisms. = And if the space-community knows exactly what they want, they should go = forward with it. I feel this does not hurt us terrestrial guys. The most = magic routing mechansim should still work on top of an unmodified BP. In = our implementation, once two nodes meet there is a magical routing = handshake, so the peers knows what routing the communication partner is = using. That might be the only thing that should be nailed in an = official way on top of the current BP to be safe for the future (some = baseline approaches such as "only direct delivery please" could be made = mandatory) . >=20 >=20 > On the terretrial front, one of the major barriers to progress has = been > the lack of an effective, reasonably general purpose, opportunistic > routing protocol despite the immense amount of academic work that has > been put in. I believe (and am trying to put some concrete answers = into > practice) that this is a soluble problem but it limits the current > deployability of DTN outside the space sector. Again, I think it is not such a large barrier, even though usable = general purpose large-scale opportunistic routing would certainly be = nice.=20 >=20 > It may be that this problem is seen as a show stopper for the > terrestrial use case and, hence, that the WG should be entirely = devoted > to the space case. Personally I think this would be a shame and I = would > be less enthusiastic about working with this limited agenda. However, > if that agenda is the case, the charter ought to be clear and the IESG > needs to be aware of where things are going.=20 I think that barrier for terrestrial applications would not get any = harder to cross, even if the WG focusses more on space missions. As long = as us terrestrians keep an open eye to what is done and make sure = nothing important gets cut away form the BP and the system remains open = enough with regard to routing. Developing and specifying the perfect, = mandatory opportunistic routing within the WG would probably fail, = because as you have pointed out so far "despite the immense amount of = academic work that has been put in" nothing came out.=20 But that is no reason to be less enthusiastic! :) MfG Sebastian From nobody Wed Jun 11 08:56:44 2014 Return-Path: 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 170DF1B27AA; Wed, 11 Jun 2014 08:56:39 -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 KRhl56lBdBYv; Wed, 11 Jun 2014 08:56:35 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D65E31A0649; Wed, 11 Jun 2014 08:56:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s5BFuZEh024731; Wed, 11 Jun 2014 08:56:35 -0700 Received: from XCH-PHX-403.sw.nos.boeing.com (xch-phx-403.sw.nos.boeing.com [137.136.239.40]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s5BFuWVC024692 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 11 Jun 2014 08:56:33 -0700 Received: from XCH-BLV-512.nw.nos.boeing.com ([169.254.12.74]) by XCH-PHX-403.sw.nos.boeing.com ([169.254.6.117]) with mapi id 14.03.0181.006; Wed, 11 Jun 2014 08:56:31 -0700 From: "Templin, Fred L" To: Elwyn Davies Thread-Topic: [dtn] DTN BoF Proposal for IETF90 Thread-Index: Ac+AQa9Fez/CplZaSwyaLFpzb8tj0wAiVZ0A///Hp/D//5OnYIABipvO//qPd7CAC7TeXf//SGxA//6DxzD/+y/3AP/2pkiA Date: Wed, 11 Jun 2014 15:56:31 +0000 Message-ID: <2134F8430051B64F815C691A62D983183048A030@XCH-BLV-512.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> , <1401967219583.26821@surrey.ac.uk> , <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk> , <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> <1402389636710.92429@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830486EBE@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> <1402490970.2995.76.camel@mightyatom> In-Reply-To: <1402490970.2995.76.camel@mightyatom> 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/9ogNMqe17Zpg0VtcFjoPSboiZe4 Cc: "iesg@ietf.org" , "dtn@ietf.org" Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 15:56:39 -0000 Hi Elwyn, See below for some responses: > -----Original Message----- > From: Elwyn Davies [mailto:elwynd@folly.org.uk] > Sent: Wednesday, June 11, 2014 5:50 AM > To: Templin, Fred L > Cc: iesg@ietf.org; dtn@ietf.org > Subject: Re: [dtn] DTN BoF Proposal for IETF90 >=20 > Hi. >=20 > I would be happy to see a BoF at IETF90, but I think we need to be > clearer about what would be the expected usage of the work that would > come out a WG that was formed as a result. I have the impression from > what I have seen on the mailing list that the work might well be > dominated by the requirements of the space use case but the charter is > currently silent on the intentions. The charter is open for discussion as input to the BoF. I too want for the charter to point the way to uses cases beyond just space-based.=20 > Personally I am keen to see DTN used in space but I am also still a > believer in terrestrial usage. Concur. > There is clearly a tension between > getting something done quickly and efficiently for the space case where > there is potential for (relatively) short term (nothing is really that > short term in space exploration!) deployment, and updating the BP etc in > a way that will also move along the terrestrial usage where the > requirements are slightly different and not so well set in concrete. Whatever gets standardized should apply equally for space-based and terrestrial. If more is needed to fully support opportunistic terrestrial use cases beyond what is accomplished in the initial chartered work items, then the additional items will be brought in through a rechater. > The lack of clarity over intended usage could well have a bad impact on > the WG if it results in disagreements over the specifications. It also > shows up in what is *not* in the charter. most notably in the absence of > any consideration of how to route the bundles that BPbis handles. IMO a > DTN system that doen't address bundle routing is only half-baked. The initial charter calls for a simple CL; it could also call for a simple routing mechanism, e.g., CGR. > There seems to be a reasonable concensus that Contact Graph Routing > (CGR) would be appropriate for the space case. Now this is primarily a > centralized all-informed oracle based system so there isn't the need to > exchange advertisements and such like but it strikes me that there are > aspects of a CGR that might need standardization such as disseminating > contact and route information to remote nodes, notifying the oracle of > traffic requests and ideas for handling failures such as notifying the > oracle that things didn't work as intended. I therefore think that work > on CGR should be part of the charter at least (I understood that CCSDS > was thinking about it but that work seems to have stalled). I think that is a reasonable suggestion, and would be happy to entertain suggestions on charter amendments. But, do we need to do that before the BoF or as an output of the BoF? > On the terretrial front, one of the major barriers to progress has been > the lack of an effective, reasonably general purpose, opportunistic > routing protocol despite the immense amount of academic work that has > been put in. I believe (and am trying to put some concrete answers into > practice) that this is a soluble problem but it limits the current > deployability of DTN outside the space sector. Not necessarily. I think we can also consider coordinated terrestrial use cases where CGR is sufficient as in-scope for the initial charter. =20 > It may be that this problem is seen as a show stopper for the > terrestrial use case and, hence, that the WG should be entirely devoted > to the space case. Personally I think this would be a shame and I would > be less enthusiastic about working with this limited agenda. However, > if that agenda is the case, the charter ought to be clear and the IESG > needs to be aware of where things are going. Agree that the charter needs to point the way to a broader set of use cases beyond space-based and coordinated terrestrial even if it is beyond the scope of the initial work items. > BTW I concur with Lars that the timescales in the charter proposal are > wildly optimistic. Which of the work items do you believe have unrealistic timescales? Thanks - Fred fred.l.templin@boeing.com > Regards, > Elwyn >=20 > On Tue, 2014-06-10 at 15:44 +0000, Templin, Fred L wrote: > > Let me make this clearer and decoupled from earlier discussions: > > > > Who would like to see a DTN BoF at IETF90? > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > _______________________________________________ > > dtn mailing list > > dtn@ietf.org > > https://www.ietf.org/mailman/listinfo/dtn From nobody Wed Jun 11 11:21:44 2014 Return-Path: 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 300B01B27FC; Wed, 11 Jun 2014 11:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 sQiKJ8An5oCz; Wed, 11 Jun 2014 11:21:37 -0700 (PDT) Received: from b.b.painless.aa.net.uk (b.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A6AA1B2806; Wed, 11 Jun 2014 11:21:37 -0700 (PDT) Received: from mightyatom.folly.org.uk ([81.187.254.250]) by b.painless.aa.net.uk with esmtp (Exim 4.72) (envelope-from ) id 1Wun9N-0002xn-6K; Wed, 11 Jun 2014 19:21:34 +0100 From: Elwyn Davies To: Sebastian Schildt In-Reply-To: References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> , <1401967219583.26821@surrey.ac.uk> , <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk> , <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> <1402389636710.92429@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830486EBE@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> <1402490970.2995.76.camel@mightyatom> Content-Type: text/plain Organization: Folly Consulting Date: Wed, 11 Jun 2014 19:21:27 +0100 Message-Id: <1402510887.2995.155.camel@mightyatom> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/C6lM7wVzmTJeuU1x6FQWYTUGi0U Cc: "iesg@ietf.org" , "dtn@ietf.org" Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 18:21:41 -0000 Hi, Sebastian. In the light of what you say below, I think it would be useful to suggest a couple of use cases that should be kept in mind during the update of the BP so that we can incorporate them into the charter asap. More below... On Wed, 2014-06-11 at 15:49 +0200, Sebastian Schildt wrote: > Hello everybody! > > On 11 Jun 2014, at 14:49, Elwyn Davies wrote: > > > > Personally I am keen to see DTN used in space but I am also still a > > believer in terrestrial usage. There is clearly a tension between > > getting something done quickly and efficiently for the space case where > > there is potential for (relatively) short term (nothing is really that > > short term in space exploration!) deployment, and updating the BP etc in > > a way that will also move along the terrestrial usage where the > > requirements are slightly different and not so well set in concrete. > > While it is true that requirements for space scenarios seems to be > much clearer, we (IBR) have been using the BP solely for various > terrestial scenarios over the last years. While not everything is > perfect, we had a profound feeling that the BP is sort of "good > enough". Of course we followed the various semi-regular what-is-time? > what-is-end-to-end? SDNV-Flexble-or-Epic-Fail? discussions on > dtn-interest. The key point is: Mostly we _followed_, not so much > participated. Of course there have been some heated lunch break > discussions over all these things within our group, but for the most > part it did not matter that much in the application. Indeed I have been involved in a number of projects that have tried out various routing schemes but, as you say, for most purposes the BP is "good enough". I have identified a number of issues that need addressing but this is not the moment to go into them. > > Consider, that today we use "responsive" desktop-like applications > written in Javascript using text-based JSON formats over non-latency > optimized links using HTTP protocols. That is (literally) wrong on so > many levels. Some hacky/impressive engeneering such as WebSockets/SPDY > and ridicoulously optimized JavaScript engines etc. are used to make > it less painful. But it works fine, doesn't it? So we feel, compared > to that, we are of to quite a good start with the BP! Definitely +several! > > So generally, we are in favor of the idea of slightly > polishing/repairing the BP without starting from scratch. Agreed. The difficulty will be deciding what constitutes slightly. Again that is a discussion either at the BOF or more likely once the WG is approved. > Which is the correct path or institution to do it, and whether the > BoF is the correct way to go, we can not say. The inner workings of > the IETF and stuff are magical to us. The key thing is to get a standards track specification for BPbis. This is most conveniently done with an IETF WG which can coordinate activities both within the work on the BPbis draft and with the auxiliary items mentioned in the charter. For that the process needs a BoF and, if the BoF goes well, approval by the IESG/IAB to form a new WG. Tomorrow is a key day when the decision to allow the BoF to take place is made by the IESG/IAB. > > However, the point is: I feel, even if the following efforts will have > a slight focus on space applications, not much will be lost for > terrestrial applications, if things are still based on the BP. > Especially if the main difference is seen as routing: > > > > > The lack of clarity over intended usage could well have a bad impact on > > the WG if it results in disagreements over the specifications. It also > > shows up in what is *not* in the charter. most notably in the absence of > > any consideration of how to route the bundles that BPbis handles. IMO a > > DTN system that doen't address bundle routing is only half-baked. > > > I know we had some discussion at some conference or workshop about > this. I believe routing (as in "a better Epidemic/Prophet") is not > neccessary for terrestrial DTN applications. Most of the time we have > small scale networks (Flooding/Gossipping is fine), or highly > application-specific solutions (nobody would use a general purpose > routing mechanism if the application is public transportation). For > interconnection we have the internet/ip, so we just need naming there. > I know, we can have the discussion and agree to disagree, so I would > rephrase it like this > > "IMO a DTN system that doesn't address bundle routing is only half-baked. " > Yes, defintely. At least you should know how to get stuff from A to B > in your application. > > However I would add > "Routing is of no concern for the core BP(bis) specification" > Just as the IPv(4/6) main specs do not say much about routing. Absolutely: My opinion is that the charter needs to say something about routing immediately. This wouldn't affect the work items already identified but would add an extra item or two to begin the process of specifying both CGR and getting the requirements in place for an opportunistic protocol. This is partly political to show that we haven't forgotten routing and partly to snsure we don't do anything too stupid in the other work items that will later screw up routing (addressing is a key area!) > > So there could be specifications on top specifying routing mechanisms. > And if the space-community knows exactly what they want, they should > go forward with it. I feel this does not hurt us terrestrial guys. Probably not.. but we need to keep a good watching brief and contribute as necessary to ensure that this remains the case! (as you say below). > The most magic routing mechansim should still work on top of an > unmodified BP. In our implementation, once two nodes meet there is a > magical routing handshake, so the peers knows what routing the > communication partner is using. That might be the only thing that > should be nailed in an official way on top of the current BP to be > safe for the future (some baseline approaches such as "only direct > delivery please" could be made mandatory) . I *think* what I am hearing here is that we should have a standardized discovery protocol. I agree (and I think it has been mentioned elsewhere on the list). > > > > > > > > On the terretrial front, one of the major barriers to progress has been > > the lack of an effective, reasonably general purpose, opportunistic > > routing protocol despite the immense amount of academic work that has > > been put in. I believe (and am trying to put some concrete answers into > > practice) that this is a soluble problem but it limits the current > > deployability of DTN outside the space sector. > Again, I think it is not such a large barrier, even though usable > general purpose large-scale opportunistic routing would certainly be > nice. > > > > > It may be that this problem is seen as a show stopper for the > > terrestrial use case and, hence, that the WG should be entirely devoted > > to the space case. Personally I think this would be a shame and I would > > be less enthusiastic about working with this limited agenda. However, > > if that agenda is the case, the charter ought to be clear and the IESG > > needs to be aware of where things are going. > > I think that barrier for terrestrial applications would not get any > harder to cross, even if the WG focusses more on space missions. As > long as us terrestrians keep an open eye to what is done and make sure > nothing important gets cut away form the BP and the system remains > open enough with regard to routing. Again +several! > Developing and specifying the perfect, mandatory opportunistic routing > within the WG would probably fail, because as you have pointed out so > far "despite the immense amount of academic work that has been put in" > nothing came out. Right. I am not proposing that we do that in this phase. Get CGR sorted out and any bits standardized that ought to be. In parallel (maybe back in DTNRG or just privately) try to sort out the opportunistic protocol and if we do, come back later to get it standardized. > > > But that is no reason to be less enthusiastic! :) > Good! Regards, Elwyn > > MfG > > Sebastian > > _______________________________________________ > dtn mailing list > dtn@ietf.org > https://www.ietf.org/mailman/listinfo/dtn From nobody Wed Jun 11 12:00:23 2014 Return-Path: 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 6CE3E1A024A; Wed, 11 Jun 2014 11:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 QLsB-0tTS4DD; Wed, 11 Jun 2014 11:59:48 -0700 (PDT) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42B411B2813; Wed, 11 Jun 2014 11:59:48 -0700 (PDT) Received: by mail-yh0-f49.google.com with SMTP id f73so125003yha.22 for ; Wed, 11 Jun 2014 11:59:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=GqabJeWBhHQT5BJgTJ0pSWkiOAW1WeEO+0O0a9ooPUo=; b=wL8MAZFrXQ7a7HAE/q5eJmlHpL7/s0rHDbBODk06Z8hGG8J5EsFQmlAXFWWOvt1c0u Ur1AXcjudKsBHjpBxr21ndEyRyR0Xf9gddTpNRR6tKw7XzlGx39FPIVW+Mk5SqxH5FmZ kXt25RWMEgFL6vDjuERiuCFY961PppwXspHtOCpr8mVXGaeRJkwx5WD413b2D6GFjRfP zEl4a3+CDnb/eaQMXq9+Iv84q98OIov1zYJcmViPw/ldeK9D28b83tvcH4B+lOT80yZT onik9r9PYN49F/h6yzDSCfyHU+MmYSao8dLU7l8SYUkdviwSiFHRIPLBafdf2vor2HcQ ZoDA== X-Received: by 10.236.131.42 with SMTP id l30mr6217782yhi.130.1402513187556; Wed, 11 Jun 2014 11:59:47 -0700 (PDT) Received: from [10.3.15.99] ([64.197.173.10]) by mx.google.com with ESMTPSA id f2sm36938974yhc.41.2014.06.11.11.59.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Jun 2014 11:59:47 -0700 (PDT) Message-ID: <5398A721.7080701@gmail.com> Date: Wed, 11 Jun 2014 13:59:45 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Elwyn Davies , Sebastian Schildt References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> , <1401967219583.26821@surrey.ac.uk> , <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk> , <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> <1402389636710.92429@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830486EBE@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> <1402490970.2995.76.camel@mightyatom> <1402510887.2995.155.camel@mightyatom> In-Reply-To: <1402510887.2995.155.camel@mightyatom> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/Lel2JjnxmMJzUFqvKJ2jRpvMLAo Cc: "iesg@ietf.org" , "dtn@ietf.org" Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 18:59:56 -0000 On 06/11/2014 01:21 PM, Elwyn Davies wrote: > Hi, Sebastian. > > In the light of what you say below, I think it would be useful to > suggest a couple of use cases that should be kept in mind during the > update of the BP so that we can incorporate them into the charter asap. > > More below... > > > On Wed, 2014-06-11 at 15:49 +0200, Sebastian Schildt wrote: >> I know we had some discussion at some conference or workshop about >> this. I believe routing (as in "a better Epidemic/Prophet") is not >> neccessary for terrestrial DTN applications. Most of the time we have >> small scale networks (Flooding/Gossipping is fine), or highly >> application-specific solutions (nobody would use a general purpose >> routing mechanism if the application is public transportation). For >> interconnection we have the internet/ip, so we just need naming there. >> I know, we can have the discussion and agree to disagree, so I would >> rephrase it like this >> >> "IMO a DTN system that doesn't address bundle routing is only half-baked." >> Yes, defintely. At least you should know how to get stuff from A to B >> in your application. >> >> However I would add >> "Routing is of no concern for the core BP(bis) specification" >> Just as the IPv(4/6) main specs do not say much about routing. > Absolutely: My opinion is that the charter needs to say something about > routing immediately. This wouldn't affect the work items already > identified but would add an extra item or two to begin the process of > specifying both CGR and getting the requirements in place for an > opportunistic protocol. This is partly political to show that we > haven't forgotten routing and partly to snsure we don't do anything too > stupid in the other work items that will later screw up routing > (addressing is a key area!) So, Martin and I haven't divided up the TSV BOFs yet, so I might be the responsible AD or I might be the irresponsible AD, but speaking as at least one of those two possibilities ... Why would DTN routing be part of the work that might or might not be chartered in TSV? Lumping transport and routing (and whatever else) in the IRTF DTNRG makes perfect sense, but I would have thought that we'd split transport and routing in an IETF WG. Could someone help me understand? Thanks, Spencer From nobody Wed Jun 11 12:03:55 2014 Return-Path: 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 8E2B41B2806; Wed, 11 Jun 2014 12:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 I0UF-tJ05zoK; Wed, 11 Jun 2014 12:03:46 -0700 (PDT) Received: from b.b.painless.aa.net.uk (b.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 283BB1B280C; Wed, 11 Jun 2014 12:03:46 -0700 (PDT) Received: from mightyatom.folly.org.uk ([81.187.254.250]) by b.painless.aa.net.uk with esmtp (Exim 4.72) (envelope-from ) id 1Wuno9-00051L-Ge; Wed, 11 Jun 2014 20:03:40 +0100 From: Elwyn Davies To: "Templin, Fred L" In-Reply-To: <2134F8430051B64F815C691A62D983183048A030@XCH-BLV-512.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> , <1401967219583.26821@surrey.ac.uk> , <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk> , <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> <1402389636710.92429@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830486EBE@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> <1402490970.2995.76.camel@mightyatom> <2134F8430051B64F815C691A62D983183048A030@XCH-BLV-512.nw.nos.boeing.com> Content-Type: text/plain Organization: Folly Consulting Date: Wed, 11 Jun 2014 20:03:36 +0100 Message-Id: <1402513416.2995.198.camel@mightyatom> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/FFKR3o6cjf0r03gG5zBb2q_4zkY Cc: "iesg@ietf.org" , "dtn@ietf.org" Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 19:03:52 -0000 Hi, Fred. It looks like we are more or less singing from the same hymn sheet (or whatever) here. I would say that we should update the charter asap since it will be discussed by the IESG/IAB probably tomorrow and it would be desirable to make it clear what we are trying to achieve and that it hangs together as a system. Some specific points for the charter : >From my experience of BoFS, I would say that you need to allow at least 30 minutes at the end for general discussion and decision 'hums'. Accordingly you will have to claw back some time from all or most of the segments. It might be possible to scrap the registry discussion altogether as it is a bit detailed. Maybe replace it with a brief discussion on routing mainly devoted to CGR. Put in some other terrestrial use cases and generally even up the balance between space and terrestrial. I'll try and produce some actual words later in a concrete redraft of the charter (also taking into account Lars' comments). I think that Lars is roughly right on the timescales... multiply everything by 2 or maybe 3. I would add two and possibly three or four work items: - Specify a node discovery protocol (standards track) - Describe the operation of CGR in a DTN BPbis environment (informational doc) and identify if there is any useful standardization work that needs to be done (this might be specifying information formats for bundles passing contact schedules, traffic requests and notifications about in a CGR network - could possibly be new BP block types). - (If the CGR work decides it is useful) Specify the information formats and/or block types for CGR. (could be in a recharter) - (maybe) Specify requirements for a general purpose opportunistic routing protocol. Regards, Elwyn On Wed, 2014-06-11 at 15:56 +0000, Templin, Fred L wrote: > Hi Elwyn, > > See below for some responses: > > > -----Original Message----- > > From: Elwyn Davies [mailto:elwynd@folly.org.uk] > > Sent: Wednesday, June 11, 2014 5:50 AM > > To: Templin, Fred L > > Cc: iesg@ietf.org; dtn@ietf.org > > Subject: Re: [dtn] DTN BoF Proposal for IETF90 > > > > Hi. > > > > I would be happy to see a BoF at IETF90, but I think we need to be > > clearer about what would be the expected usage of the work that would > > come out a WG that was formed as a result. I have the impression from > > what I have seen on the mailing list that the work might well be > > dominated by the requirements of the space use case but the charter is > > currently silent on the intentions. > > The charter is open for discussion as input to the BoF. I too > want for the charter to point the way to uses cases beyond just > space-based. > > > Personally I am keen to see DTN used in space but I am also still a > > believer in terrestrial usage. > > Concur. > > > There is clearly a tension between > > getting something done quickly and efficiently for the space case where > > there is potential for (relatively) short term (nothing is really that > > short term in space exploration!) deployment, and updating the BP etc in > > a way that will also move along the terrestrial usage where the > > requirements are slightly different and not so well set in concrete. > > Whatever gets standardized should apply equally for space-based > and terrestrial. If more is needed to fully support opportunistic > terrestrial use cases beyond what is accomplished in the initial > chartered work items, then the additional items will be brought > in through a rechater. > > > The lack of clarity over intended usage could well have a bad impact on > > the WG if it results in disagreements over the specifications. It also > > shows up in what is *not* in the charter. most notably in the absence of > > any consideration of how to route the bundles that BPbis handles. IMO a > > DTN system that doen't address bundle routing is only half-baked. > > The initial charter calls for a simple CL; it could also call > for a simple routing mechanism, e.g., CGR. > > > There seems to be a reasonable concensus that Contact Graph Routing > > (CGR) would be appropriate for the space case. Now this is primarily a > > centralized all-informed oracle based system so there isn't the need to > > exchange advertisements and such like but it strikes me that there are > > aspects of a CGR that might need standardization such as disseminating > > contact and route information to remote nodes, notifying the oracle of > > traffic requests and ideas for handling failures such as notifying the > > oracle that things didn't work as intended. I therefore think that work > > on CGR should be part of the charter at least (I understood that CCSDS > > was thinking about it but that work seems to have stalled). > > I think that is a reasonable suggestion, and would be happy to > entertain suggestions on charter amendments. But, do we need to > do that before the BoF or as an output of the BoF? > > > On the terretrial front, one of the major barriers to progress has been > > the lack of an effective, reasonably general purpose, opportunistic > > routing protocol despite the immense amount of academic work that has > > been put in. I believe (and am trying to put some concrete answers into > > practice) that this is a soluble problem but it limits the current > > deployability of DTN outside the space sector. > > Not necessarily. I think we can also consider coordinated > terrestrial use cases where CGR is sufficient as in-scope > for the initial charter. > > > It may be that this problem is seen as a show stopper for the > > terrestrial use case and, hence, that the WG should be entirely devoted > > to the space case. Personally I think this would be a shame and I would > > be less enthusiastic about working with this limited agenda. However, > > if that agenda is the case, the charter ought to be clear and the IESG > > needs to be aware of where things are going. > > Agree that the charter needs to point the way to a broader set > of use cases beyond space-based and coordinated terrestrial even > if it is beyond the scope of the initial work items. > > > BTW I concur with Lars that the timescales in the charter proposal are > > wildly optimistic. > > Which of the work items do you believe have unrealistic timescales? > > Thanks - Fred > fred.l.templin@boeing.com > > > Regards, > > Elwyn > > > > On Tue, 2014-06-10 at 15:44 +0000, Templin, Fred L wrote: > > > Let me make this clearer and decoupled from earlier discussions: > > > > > > Who would like to see a DTN BoF at IETF90? > > > > > > Thanks - Fred > > > fred.l.templin@boeing.com > > > > > > _______________________________________________ > > > dtn mailing list > > > dtn@ietf.org > > > https://www.ietf.org/mailman/listinfo/dtn > From nobody Wed Jun 11 13:04:47 2014 Return-Path: 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 32E981A026D; Wed, 11 Jun 2014 13:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 PM_oSUOdv8o9; Wed, 11 Jun 2014 13:04:38 -0700 (PDT) Received: from mail.ibr.cs.tu-bs.de (mail.ibr.cs.tu-bs.de [IPv6:2001:638:602:1181:5054:ff:fe75:abbf]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E75B1B281A; Wed, 11 Jun 2014 13:04:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.ibr.cs.tu-bs.de (Postfix) with ESMTP id 2DB25182EDE; Wed, 11 Jun 2014 22:04:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ibr.cs.tu-bs.de; h=x-mailer:references:message-id:content-transfer-encoding:date :date:in-reply-to:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=key1; t= 1402517073; x=1404331474; bh=Id9HCCj2db0iiFqVbtBWcxikIfjMW5mV5dM wuOozvO0=; b=ZD3PPHxzHk4amf4ThgU6egyOm2KAnXpw6FhDmCmh1c88Ve9EJxE jHODuxxmgLTEJPuo+rKfeO7fHB4VmxQ5tRNJjWiAnwWdeqQS8EEodn5tpN+/G1YD ojNvIDz07VtTEYZBTtD6EXskeX0WZ1LcLEjGIBb5rZWIX/DJMsERHM6M= X-Virus-Scanned: Debian amavisd-new at ibr.cs.tu-bs.de Received: from mail.ibr.cs.tu-bs.de ([127.0.0.1]) by localhost (mail.ibr.cs.tu-bs.de [127.0.0.1]) (amavisd-new, port 10026) with LMTP id E9WwkHKL1z_e; Wed, 11 Jun 2014 22:04:33 +0200 (CEST) Received: from [IPv6:2001:6f8:900:8d3d:adfa:60d0:faa1:b60] (unknown [IPv6:2001:6f8:900:8d3d:adfa:60d0:faa1:b60]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schildt@ibr.cs.tu-bs.de) by mail.ibr.cs.tu-bs.de (Postfix) with ESMTPSA id B011D182AEB; Wed, 11 Jun 2014 22:04:32 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Sebastian Schildt In-Reply-To: <1402510887.2995.155.camel@mightyatom> Date: Wed, 11 Jun 2014 22:04:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> , <1401967219583.26821@surrey.ac.uk> , <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk> , <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> <1402389636710.92429@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830486EBE@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> <1402490970.2995.76.camel@mightyatom> <1402510887.2995.155.camel@mightyatom> To: Elwyn Davies X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/WcJr66SMdtceBcyUbXHVeUA5yi8 Cc: "iesg@ietf.org" , "dtn@ietf.org" Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 20:04:46 -0000 Hi Elwyn, Hi * On 11 Jun 2014, at 20:21, Elwyn Davies wrote: > Hi, Sebastian. >=20 > In the light of what you say below, I think it would be useful to > suggest a couple of use cases that should be kept in mind during the > update of the BP so that we can incorporate them into the charter = asap. >=20 ok, so since we are rather implementation-driven, these points might be = too technical/specific at this point, but here goes my wishlist. All of = these things we really did use for some of our applications. 1. Network Types: I think the main differences are in the contact = qualities: Hard-scheduled fully-deterministic IPN, and "soft-scheduled" = things like public transportation (schedule+uncertainty, we put nodes on = trams for example) and fully opportunistic (think mobile phones, we are = doing Android apps). While most differences here would need to be = absorbed by whatever routing is employed, and do not have an impact on = the protocol per-se the latter two cases imply that: 2. We need discovery. I guess here the key thing is a generic = description of a node. So far we have been using some variants of IPND. = We have used that idea not only for IP, but also use it for ZigBee, and = store a similar structure in the DHT when announcing nodes. What should = be carried over to a standard is the general (extensible) key-value = idea. Something like this could be specified as a prerequsite during = node-to-node handshake. How to use this apart from node handshake (i.e. = using IP multicast as is the case for IPND, or put it in an IEEE = 802.15.4 datagram or whatever), should not be in the core specs.=20 2a) I guess one or two standard convergence layers should be proposed. = Those could also specify how, on their medium (if it is not just PtP = anyway) discovery is realized, preferably using the node-handshake data = structure mentioned in 2 3. I don't want to revive the holy time-wars, but in our experience at = the moment it s quite perfect that you can have "real" timestamps = (expire this on christmas!) as well as the age block (throw it away = after 2 months). Depending on the application, one works better than the = other, so we really, really think we should make sure BP keeps both = possibilites. Maybe some thought needs to be put into how to = interoperate between both modes of operation (when should an age bloock = be replaced with an expiration and vice versa. Alternatively just forbid = mixing both worlds ..) 4. Not my area of expertise, but as has been said many times here: = Bundle Security is a must, and needs to be simplified. While this might = be an as-large a can of worms as routing, I think key management should = be at least be "adressed". For example some of my colleagues have been = worked implementing a "trust level" for exchanged keys. So they use = every opportunitiy (as they might be scarce) between node contacts to = exchange keys following a "trust on first use" model. This implies a = lower trust level for a key than an user initiated exchange with = verficiation, which for example you might want to visulaize if your = application is an end-user app on a mobile phone 5. Make sure delays can be months or milliseconds (it is fine now) So going back to the bigger picture - Applications: Make sure there is nothing in the protocol that = fundamentally precludes the use of fully determinitic and fully = opportunisitic scenarios. Make sure ms delay (we are using this to = remotely control robots from a mobile phone), work the same as = days/weeks months. This is already working now, and we do not want to = loose those capabilities for no good reason - A generic discovery/handshake, i.e. nothing that every CL or routing = needs to do for itself - Allow relative (sensor nodes without RTC) and aboslute time (cold = storage, disks, flash drives). - Include streamlined security. Think about key exchange.=20 That is all :) As I warned you before, this may be a little bit too = technical at this stage. The main point is, while maybe some parts of = what we currently have in our documents are a bit wishy-washy or have = gotten overly general/complex, there is also lot of (not-hurting) = flexibility that we should not loose. MfG Sebastian > On Wed, 2014-06-11 at 15:49 +0200, Sebastian Schildt wrote: >> Hello everybody! >>=20 >> On 11 Jun 2014, at 14:49, Elwyn Davies wrote: >>>=20 >>> Personally I am keen to see DTN used in space but I am also still a >>> believer in terrestrial usage. There is clearly a tension between >>> getting something done quickly and efficiently for the space case = where >>> there is potential for (relatively) short term (nothing is really = that >>> short term in space exploration!) deployment, and updating the BP = etc in >>> a way that will also move along the terrestrial usage where the >>> requirements are slightly different and not so well set in concrete. >>=20 >> While it is true that requirements for space scenarios seems to be >> much clearer, we (IBR) have been using the BP solely for various >> terrestial scenarios over the last years. While not everything is >> perfect, we had a profound feeling that the BP is sort of "good >> enough". Of course we followed the various semi-regular what-is-time? >> what-is-end-to-end? SDNV-Flexble-or-Epic-Fail? discussions on >> dtn-interest. The key point is: Mostly we _followed_, not so much >> participated. Of course there have been some heated lunch break >> discussions over all these things within our group, but for the most >> part it did not matter that much in the application. >=20 > Indeed I have been involved in a number of projects that have tried = out > various routing schemes but, as you say, for most purposes the BP is > "good enough". I have identified a number of issues that need > addressing but this is not the moment to go into them.=20 >>=20 >> Consider, that today we use "responsive" desktop-like applications >> written in Javascript using text-based JSON formats over non-latency >> optimized links using HTTP protocols. That is (literally) wrong on so >> many levels. Some hacky/impressive engeneering such as = WebSockets/SPDY >> and ridicoulously optimized JavaScript engines etc. are used to make >> it less painful. But it works fine, doesn't it? So we feel, compared >> to that, we are of to quite a good start with the BP! >=20 > Definitely +several! =20 >>=20 >> So generally, we are in favor of the idea of slightly >> polishing/repairing the BP without starting from scratch. >=20 > Agreed. The difficulty will be deciding what constitutes slightly. > Again that is a discussion either at the BOF or more likely once the = WG > is approved. >=20 >> Which is the correct path or institution to do it, and whether the >> BoF is the correct way to go, we can not say. The inner workings of >> the IETF and stuff are magical to us. >=20 > The key thing is to get a standards track specification for BPbis. = This > is most conveniently done with an IETF WG which can coordinate > activities both within the work on the BPbis draft and with the > auxiliary items mentioned in the charter. For that the process needs a > BoF and, if the BoF goes well, approval by the IESG/IAB to form a new > WG. >=20 > Tomorrow is a key day when the decision to allow the BoF to take place > is made by the IESG/IAB.=20 >=20 >>=20 >> However, the point is: I feel, even if the following efforts will = have >> a slight focus on space applications, not much will be lost for >> terrestrial applications, if things are still based on the BP. >> Especially if the main difference is seen as routing: >>=20 >>>=20 >>> The lack of clarity over intended usage could well have a bad impact = on >>> the WG if it results in disagreements over the specifications. It = also >>> shows up in what is *not* in the charter. most notably in the = absence of >>> any consideration of how to route the bundles that BPbis handles. = IMO a >>> DTN system that doen't address bundle routing is only half-baked.=20 >>=20 >>=20 >> I know we had some discussion at some conference or workshop about >> this. I believe routing (as in "a better Epidemic/Prophet") is not >> neccessary for terrestrial DTN applications. Most of the time we have >> small scale networks (Flooding/Gossipping is fine), or highly >> application-specific solutions (nobody would use a general purpose >> routing mechanism if the application is public transportation). For >> interconnection we have the internet/ip, so we just need naming = there. >> I know, we can have the discussion and agree to disagree, so I would >> rephrase it like this >>=20 >> "IMO a DTN system that doesn't address bundle routing is only = half-baked. " >> Yes, defintely. At least you should know how to get stuff from A to B >> in your application. >>=20 >> However I would add >> "Routing is of no concern for the core BP(bis) specification" >> Just as the IPv(4/6) main specs do not say much about routing.=20 >=20 > Absolutely: My opinion is that the charter needs to say something = about > routing immediately. This wouldn't affect the work items already > identified but would add an extra item or two to begin the process of > specifying both CGR and getting the requirements in place for an > opportunistic protocol. This is partly political to show that we > haven't forgotten routing and partly to snsure we don't do anything = too > stupid in the other work items that will later screw up routing > (addressing is a key area!) >>=20 >> So there could be specifications on top specifying routing = mechanisms. >> And if the space-community knows exactly what they want, they should >> go forward with it. I feel this does not hurt us terrestrial guys.=20 >=20 > Probably not.. but we need to keep a good watching brief and = contribute > as necessary to ensure that this remains the case! (as you say below). >=20 >> The most magic routing mechansim should still work on top of an >> unmodified BP. In our implementation, once two nodes meet there is a >> magical routing handshake, so the peers knows what routing the >> communication partner is using. That might be the only thing that >> should be nailed in an official way on top of the current BP to be >> safe for the future (some baseline approaches such as "only direct >> delivery please" could be made mandatory) . >=20 > I *think* what I am hearing here is that we should have a standardized > discovery protocol. I agree (and I think it has been mentioned > elsewhere on the list). >>=20 >>=20 >>>=20 >>>=20 >>> On the terretrial front, one of the major barriers to progress has = been >>> the lack of an effective, reasonably general purpose, opportunistic >>> routing protocol despite the immense amount of academic work that = has >>> been put in. I believe (and am trying to put some concrete answers = into >>> practice) that this is a soluble problem but it limits the current >>> deployability of DTN outside the space sector. >> Again, I think it is not such a large barrier, even though usable >> general purpose large-scale opportunistic routing would certainly be >> nice.=20 >>=20 >>>=20 >>> It may be that this problem is seen as a show stopper for the >>> terrestrial use case and, hence, that the WG should be entirely = devoted >>> to the space case. Personally I think this would be a shame and I = would >>> be less enthusiastic about working with this limited agenda. = However, >>> if that agenda is the case, the charter ought to be clear and the = IESG >>> needs to be aware of where things are going.=20 >>=20 >> I think that barrier for terrestrial applications would not get any >> harder to cross, even if the WG focusses more on space missions. As >> long as us terrestrians keep an open eye to what is done and make = sure >> nothing important gets cut away form the BP and the system remains >> open enough with regard to routing.=20 >=20 > Again +several! >=20 >> Developing and specifying the perfect, mandatory opportunistic = routing >> within the WG would probably fail, because as you have pointed out so >> far "despite the immense amount of academic work that has been put = in" >> nothing came out. >=20 > Right. I am not proposing that we do that in this phase. Get CGR > sorted out and any bits standardized that ought to be. In parallel > (maybe back in DTNRG or just privately) try to sort out the > opportunistic protocol and if we do, come back later to get it > standardized. >>=20 >>=20 >> But that is no reason to be less enthusiastic! :) >>=20 > Good! >=20 > Regards, > Elwyn >>=20 >> MfG >>=20 >> Sebastian >>=20 >> _______________________________________________ >> dtn mailing list >> dtn@ietf.org >> https://www.ietf.org/mailman/listinfo/dtn From nobody Wed Jun 11 16:08:58 2014 Return-Path: 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 84FCA1B28CB; Wed, 11 Jun 2014 16:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 kDk1AE6nX9o5; Wed, 11 Jun 2014 16:08:54 -0700 (PDT) Received: from b.b.painless.aa.net.uk (b.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F6691B28B5; Wed, 11 Jun 2014 16:08:53 -0700 (PDT) Received: from mightyatom.folly.org.uk ([81.187.254.250]) by b.painless.aa.net.uk with esmtp (Exim 4.72) (envelope-from ) id 1WurdP-0007Bv-Fs; Thu, 12 Jun 2014 00:08:51 +0100 From: Elwyn Davies To: Spencer Dawkins In-Reply-To: <5398A721.7080701@gmail.com> References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> , <1401967219583.26821@surrey.ac.uk> , <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk> , <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> <1402389636710.92429@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830486EBE@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> <1402490970.2995.76.camel@mightyatom> <1402510887.2995.155.camel@mightyatom> <5398A721.7080701@gmail.com> Content-Type: text/plain Organization: Folly Consulting Date: Thu, 12 Jun 2014 00:08:46 +0100 Message-Id: <1402528126.2995.294.camel@mightyatom> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/ZQRwK5FO9nGsyMwV49Gg4E6m4U8 Cc: "iesg@ietf.org" , "dtn@ietf.org" , Sebastian Schildt Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 23:08:56 -0000 Hi, Spencer. I'll try and rationalise why I think we might want to go this way... see below. On Wed, 2014-06-11 at 13:59 -0500, Spencer Dawkins wrote: > On 06/11/2014 01:21 PM, Elwyn Davies wrote: > > Hi, Sebastian. > > > > In the light of what you say below, I think it would be useful to > > suggest a couple of use cases that should be kept in mind during the > > update of the BP so that we can incorporate them into the charter asap. > > > > More below... > > > > > > On Wed, 2014-06-11 at 15:49 +0200, Sebastian Schildt wrote: > >> I know we had some discussion at some conference or workshop about > >> this. I believe routing (as in "a better Epidemic/Prophet") is not > >> neccessary for terrestrial DTN applications. Most of the time we have > >> small scale networks (Flooding/Gossipping is fine), or highly > >> application-specific solutions (nobody would use a general purpose > >> routing mechanism if the application is public transportation). For > >> interconnection we have the internet/ip, so we just need naming there. > >> I know, we can have the discussion and agree to disagree, so I would > >> rephrase it like this > >> > >> "IMO a DTN system that doesn't address bundle routing is only half-baked." > >> Yes, defintely. At least you should know how to get stuff from A to B > >> in your application. > >> > >> However I would add > >> "Routing is of no concern for the core BP(bis) specification" > >> Just as the IPv(4/6) main specs do not say much about routing. > > Absolutely: My opinion is that the charter needs to say something about > > routing immediately. This wouldn't affect the work items already > > identified but would add an extra item or two to begin the process of > > specifying both CGR and getting the requirements in place for an > > opportunistic protocol. This is partly political to show that we > > haven't forgotten routing and partly to snsure we don't do anything too > > stupid in the other work items that will later screw up routing > > (addressing is a key area!) > > So, Martin and I haven't divided up the TSV BOFs yet, so I might be the > responsible AD or I might be the irresponsible AD, but speaking as at > least one of those two possibilities ... > > Why would DTN routing be part of the work that might or might not be > chartered in TSV? > > Lumping transport and routing (and whatever else) in the IRTF DTNRG > makes perfect sense, but I would have thought that we'd split transport > and routing in an IETF WG. > > Could someone help me understand? I'll try a bit... 1. DTN is a distinct architecture that does not really match the terminology used to distinguish the areas in the IETF. You could make a perfectly valid case for the Bundle Protocol finding a home in Apps, TSV or Internet areas.. and there is a management piece. And it's new as a standards track so it isn't going to get its own area and it's quite small. So we would be really grateful if you can give us a home until we grow up. But enough of this neediness! 2. As a new system there are a number of parts that need to be in place to have the bare bones of a complete system. Arguably we should at the very least be going for a SEC area WG to do the SBSP and maybe an OPS area WG to do the management part (which isn't just a MIB). Whether we have critical mass to do all of these things in separate WGs in parallel I wouldn't like to say. However they are rather more closely coupled in the DTN bundle architecture than in the conventional IP architecture and would need to be closely coordinated. The "routing" component is the other piece which really needs to be in place to achieve a complete story. 3. The space use case is most likely to get production deployment in the short to medium term. I put "routing" in quotes because the expected way that DTN bundles will be forwarded is using Contact Graph Routing. This is not a distributed system. It is more in the nature of a centralized application or oracle that is all-informed as regards contact opportunities and traffic loads and provides a forwarding schedule for nodes that is loaded into nodes in advance - effectively an extension of the management story. At least one implementation exists (ION) but it is not formally documented and AFAIK there is no standardized way for nodes to interact with the oracle to give it information and find out what they should be doing. It seems to me that this part ought to be documented and standardized to complete a minimalist DTN system for space (and for some terrestrial applications also). 4. The opportunistic routing story is not something we can start on at present as we don't know what it will be yet. This would be nearer a real routing story although (a.s.) still be entirely different from IP routing systems. If and when we have a solution to standardize, this one may well be worth its own WG but that is a story for another day. What might make sense is to devote some effort to a requirements document to ensure that the BPbis can handle what is needed. 5. So overall, I see that CGR is effectively an aspect of management rather than a routing protocol in the IP sense when it comes to bits on the wire/aether. So, Spencer, if you are prepared to host the management part in the existing charter, then CGR can be viewed as an extension of this. I hope this helps a bit. Cheers, Elwyn > > Thanks, > > Spencer From nobody Wed Jun 11 21:09:00 2014 Return-Path: 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 4B9911B29BC; Wed, 11 Jun 2014 21:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 2pQBUNSeZ8WE; Wed, 11 Jun 2014 21:08:52 -0700 (PDT) Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3D0C1B29BB; Wed, 11 Jun 2014 21:08:51 -0700 (PDT) Received: by mail-yh0-f43.google.com with SMTP id a41so560665yho.16 for ; Wed, 11 Jun 2014 21:08:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Nkmnqw9bnc33ldRaVJewxuzOx6XFI8FpSh4R6qo65Sg=; b=fUzQu85y9LNT8u4N1AfbfklG8U1YpUD50L/6nIy6nBBdISJNQiywRUyziUXdp76J0m wq6S6BW1pFkjWpqpGWaB64xQoOyLhLWqFwSstq9jZNJi9SwAQCMlPoMOY0jmhY6Yjz5b YAj6n4AjAYqADJgoJGAnY39qSbNnfst9tHxt3M2AEbwyQrTKkQsdD7M317ubqvBc3m/a IsZcdxTgWJa9PqSALHU9wpn4tdorcGhVfSun/+NxuKoqYhW+xmgbjrzBv8EpDsqnPcU1 G8fZkZDIo9J4S3Flv7Oh8W3GPbmP2sAs3X5UPiCyMg4cld7ntdXbgYWMJOgbQvJt/yM4 o/xg== X-Received: by 10.236.51.233 with SMTP id b69mr11975859yhc.93.1402546131132; Wed, 11 Jun 2014 21:08:51 -0700 (PDT) Received: from [10.71.14.162] ([64.197.173.10]) by mx.google.com with ESMTPSA id e4sm38941795yhe.42.2014.06.11.21.08.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Jun 2014 21:08:50 -0700 (PDT) Message-ID: <539927CF.6010901@gmail.com> Date: Wed, 11 Jun 2014 23:08:47 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Elwyn Davies References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> , <1401967219583.26821@surrey.ac.uk> , <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk> , <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> <1402389636710.92429@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830486EBE@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> <1402490970.2995.76.camel@mightyatom> <1402510887.2995.155.camel@mightyatom> <5398A721.7080701@gmail.com> <1402528126.2995.294.camel@mightyatom> In-Reply-To: <1402528126.2995.294.camel@mightyatom> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/InN5EiTu5zk2GKVxAHf0qg5EJJc Cc: "iesg@ietf.org" , "dtn@ietf.org" , Sebastian Schildt Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 04:08:54 -0000 Hi, Elwyn, Thanks for the quick and helpful response. See inline. Spencer On 06/11/2014 06:08 PM, Elwyn Davies wrote: > Hi, Spencer. > > I'll try and rationalise why I think we might want to go this way... > see below. > > On Wed, 2014-06-11 at 13:59 -0500, Spencer Dawkins wrote: >> On 06/11/2014 01:21 PM, Elwyn Davies wrote: >>> Hi, Sebastian. >>> >>> In the light of what you say below, I think it would be useful to >>> suggest a couple of use cases that should be kept in mind during the >>> update of the BP so that we can incorporate them into the charter asap. >>> >>> More below... >>> >>> >>> On Wed, 2014-06-11 at 15:49 +0200, Sebastian Schildt wrote: >>>> I know we had some discussion at some conference or workshop about >>>> this. I believe routing (as in "a better Epidemic/Prophet") is not >>>> neccessary for terrestrial DTN applications. Most of the time we have >>>> small scale networks (Flooding/Gossipping is fine), or highly >>>> application-specific solutions (nobody would use a general purpose >>>> routing mechanism if the application is public transportation). For >>>> interconnection we have the internet/ip, so we just need naming there. >>>> I know, we can have the discussion and agree to disagree, so I would >>>> rephrase it like this >>>> >>>> "IMO a DTN system that doesn't address bundle routing is only half-baked." >>>> Yes, defintely. At least you should know how to get stuff from A to B >>>> in your application. >>>> >>>> However I would add >>>> "Routing is of no concern for the core BP(bis) specification" >>>> Just as the IPv(4/6) main specs do not say much about routing. >>> Absolutely: My opinion is that the charter needs to say something about >>> routing immediately. This wouldn't affect the work items already >>> identified but would add an extra item or two to begin the process of >>> specifying both CGR and getting the requirements in place for an >>> opportunistic protocol. This is partly political to show that we >>> haven't forgotten routing and partly to snsure we don't do anything too >>> stupid in the other work items that will later screw up routing >>> (addressing is a key area!) >> So, Martin and I haven't divided up the TSV BOFs yet, so I might be the >> responsible AD or I might be the irresponsible AD, but speaking as at >> least one of those two possibilities ... >> >> Why would DTN routing be part of the work that might or might not be >> chartered in TSV? >> >> Lumping transport and routing (and whatever else) in the IRTF DTNRG >> makes perfect sense, but I would have thought that we'd split transport >> and routing in an IETF WG. >> >> Could someone help me understand? > I'll try a bit... > > 1. DTN is a distinct architecture that does not really match the > terminology used to distinguish the areas in the IETF. You could make a > perfectly valid case for the Bundle Protocol finding a home in Apps, TSV > or Internet areas.. and there is a management piece. And it's new as a > standards track so it isn't going to get its own area and it's quite > small. So we would be really grateful if you can give us a home until > we grow up. But enough of this neediness! > > 2. As a new system there are a number of parts that need to be in place > to have the bare bones of a complete system. Arguably we should at the > very least be going for a SEC area WG to do the SBSP and maybe an OPS > area WG to do the management part (which isn't just a MIB). Whether we > have critical mass to do all of these things in separate WGs in parallel > I wouldn't like to say. However they are rather more closely coupled in > the DTN bundle architecture than in the conventional IP architecture and > would need to be closely coordinated. The "routing" component is the > other piece which really needs to be in place to achieve a complete > story. > > 3. The space use case is most likely to get production deployment in the > short to medium term. I put "routing" in quotes because the expected > way that DTN bundles will be forwarded is using Contact Graph Routing. > This is not a distributed system. It is more in the nature of a > centralized application or oracle that is all-informed as regards > contact opportunities and traffic loads and provides a forwarding > schedule for nodes that is loaded into nodes in advance - effectively an > extension of the management story. At least one implementation exists > (ION) but it is not formally documented and AFAIK there is no > standardized way for nodes to interact with the oracle to give it > information and find out what they should be doing. It seems to me that > this part ought to be documented and standardized to complete a > minimalist DTN system for space (and for some terrestrial applications > also). > > 4. The opportunistic routing story is not something we can start on at > present as we don't know what it will be yet. This would be nearer a > real routing story although (a.s.) still be entirely different from IP > routing systems. If and when we have a solution to standardize, this one > may well be worth its own WG but that is a story for another day. What > might make sense is to devote some effort to a requirements document to > ensure that the BPbis can handle what is needed. > > 5. So overall, I see that CGR is effectively an aspect of management > rather than a routing protocol in the IP sense when it comes to bits on > the wire/aether. So, Spencer, if you are prepared to host the > management part in the existing charter, then CGR can be viewed as an > extension of this. > > I hope this helps a bit. None of this surprises me a lot (I never worked on DTN, but did pay attention to it from time to time). I was responding to a note about keeping options open for routing, and wondered if having a completely different home for routing would help enforce that separation. IIUC, the first targeted use case can base routing decisions on a centralized oracle, so wouldn't particularly benefit from RTG clue; if you are able to keep a solid fence between the rest of DTN and routing in a single working group, any subsequent work that looks more like The Distributed Routing System We Know And Love could be spun up in a RTG working group, if that seems helpful, with the subsequent output parachuted in as a CGR replacement. Did I get that right? From nobody Thu Jun 12 00:05:57 2014 Return-Path: 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 BA3CB1A0259; Thu, 12 Jun 2014 00:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 O5J-RPAn3qTe; Thu, 12 Jun 2014 00:05:52 -0700 (PDT) Received: from b.b.painless.aa.net.uk (b.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDE2F1A01DC; Thu, 12 Jun 2014 00:05:51 -0700 (PDT) Received: from mightyatom.folly.org.uk ([81.187.254.250]) by b.painless.aa.net.uk with esmtp (Exim 4.72) (envelope-from ) id 1Wuz4z-0006AJ-LV; Thu, 12 Jun 2014 08:05:49 +0100 From: Elwyn Davies To: Spencer Dawkins In-Reply-To: <539927CF.6010901@gmail.com> References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> , <1401967219583.26821@surrey.ac.uk> , <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk> , <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> <1402389636710.92429@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830486EBE@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> <1402490970.2995.76.camel@mightyatom> <1402510887.2995.155.camel@mightyatom> <5398A721.7080701@gmail.com> <1402528126.2995.294.camel@mightyatom> <539927CF.6010901@gmail.com> Content-Type: text/plain Organization: Folly Consulting Date: Thu, 12 Jun 2014 08:05:44 +0100 Message-Id: <1402556744.2995.335.camel@mightyatom> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/ofZQyxLgEVt4bgdn7__Lc5eceEs Cc: "iesg@ietf.org" , "dtn@ietf.org" , Sebastian Schildt Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 07:05:54 -0000 Hi, Spencer. Phew! A bit more below.. On Wed, 2014-06-11 at 23:08 -0500, Spencer Dawkins wrote: > Hi, Elwyn, > > Thanks for the quick and helpful response. See inline. > > Spencer > > On 06/11/2014 06:08 PM, Elwyn Davies wrote: > > Hi, Spencer. > > > > I'll try and rationalise why I think we might want to go this way... > > see below. > > > > On Wed, 2014-06-11 at 13:59 -0500, Spencer Dawkins wrote: > >> On 06/11/2014 01:21 PM, Elwyn Davies wrote: > >>> Hi, Sebastian. > >>> > >>> In the light of what you say below, I think it would be useful to > >>> suggest a couple of use cases that should be kept in mind during the > >>> update of the BP so that we can incorporate them into the charter asap. > >>> > >>> More below... > >>> > >>> > >>> On Wed, 2014-06-11 at 15:49 +0200, Sebastian Schildt wrote: > >>>> I know we had some discussion at some conference or workshop about > >>>> this. I believe routing (as in "a better Epidemic/Prophet") is not > >>>> neccessary for terrestrial DTN applications. Most of the time we have > >>>> small scale networks (Flooding/Gossipping is fine), or highly > >>>> application-specific solutions (nobody would use a general purpose > >>>> routing mechanism if the application is public transportation). For > >>>> interconnection we have the internet/ip, so we just need naming there. > >>>> I know, we can have the discussion and agree to disagree, so I would > >>>> rephrase it like this > >>>> > >>>> "IMO a DTN system that doesn't address bundle routing is only half-baked." > >>>> Yes, defintely. At least you should know how to get stuff from A to B > >>>> in your application. > >>>> > >>>> However I would add > >>>> "Routing is of no concern for the core BP(bis) specification" > >>>> Just as the IPv(4/6) main specs do not say much about routing. > >>> Absolutely: My opinion is that the charter needs to say something about > >>> routing immediately. This wouldn't affect the work items already > >>> identified but would add an extra item or two to begin the process of > >>> specifying both CGR and getting the requirements in place for an > >>> opportunistic protocol. This is partly political to show that we > >>> haven't forgotten routing and partly to snsure we don't do anything too > >>> stupid in the other work items that will later screw up routing > >>> (addressing is a key area!) > >> So, Martin and I haven't divided up the TSV BOFs yet, so I might be the > >> responsible AD or I might be the irresponsible AD, but speaking as at > >> least one of those two possibilities ... > >> > >> Why would DTN routing be part of the work that might or might not be > >> chartered in TSV? > >> > >> Lumping transport and routing (and whatever else) in the IRTF DTNRG > >> makes perfect sense, but I would have thought that we'd split transport > >> and routing in an IETF WG. > >> > >> Could someone help me understand? > > I'll try a bit... > > > > 1. DTN is a distinct architecture that does not really match the > > terminology used to distinguish the areas in the IETF. You could make a > > perfectly valid case for the Bundle Protocol finding a home in Apps, TSV > > or Internet areas.. and there is a management piece. And it's new as a > > standards track so it isn't going to get its own area and it's quite > > small. So we would be really grateful if you can give us a home until > > we grow up. But enough of this neediness! > > > > 2. As a new system there are a number of parts that need to be in place > > to have the bare bones of a complete system. Arguably we should at the > > very least be going for a SEC area WG to do the SBSP and maybe an OPS > > area WG to do the management part (which isn't just a MIB). Whether we > > have critical mass to do all of these things in separate WGs in parallel > > I wouldn't like to say. However they are rather more closely coupled in > > the DTN bundle architecture than in the conventional IP architecture and > > would need to be closely coordinated. The "routing" component is the > > other piece which really needs to be in place to achieve a complete > > story. > > > > 3. The space use case is most likely to get production deployment in the > > short to medium term. I put "routing" in quotes because the expected > > way that DTN bundles will be forwarded is using Contact Graph Routing. > > This is not a distributed system. It is more in the nature of a > > centralized application or oracle that is all-informed as regards > > contact opportunities and traffic loads and provides a forwarding > > schedule for nodes that is loaded into nodes in advance - effectively an > > extension of the management story. At least one implementation exists > > (ION) but it is not formally documented and AFAIK there is no > > standardized way for nodes to interact with the oracle to give it > > information and find out what they should be doing. It seems to me that > > this part ought to be documented and standardized to complete a > > minimalist DTN system for space (and for some terrestrial applications > > also). > > > > 4. The opportunistic routing story is not something we can start on at > > present as we don't know what it will be yet. This would be nearer a > > real routing story although (a.s.) still be entirely different from IP > > routing systems. If and when we have a solution to standardize, this one > > may well be worth its own WG but that is a story for another day. What > > might make sense is to devote some effort to a requirements document to > > ensure that the BPbis can handle what is needed. > > > > 5. So overall, I see that CGR is effectively an aspect of management > > rather than a routing protocol in the IP sense when it comes to bits on > > the wire/aether. So, Spencer, if you are prepared to host the > > management part in the existing charter, then CGR can be viewed as an > > extension of this. > > > > I hope this helps a bit. > > None of this surprises me a lot (I never worked on DTN, but did pay > attention to it from time to time). I was responding to a note about > keeping options open for routing, and wondered if having a completely > different home for routing would help enforce that separation. > > IIUC, the first targeted use case can base routing decisions on a > centralized oracle, so wouldn't particularly benefit from RTG clue; if > you are able to keep a solid fence between the rest of DTN and routing > in a single working group, any subsequent work that looks more like The > Distributed Routing System We Know And Love could be spun up in a RTG > working group, if that seems helpful, with the subsequent output > parachuted in as a CGR replacement. > > Did I get that right? Almost. It is unlikely that the space use case would ever use anything but CGR for the foreseeable future. Celestial mechanics, resource scheduling on the ground stations and for the most part unidirectional links means that anything more opportunistic isn't realistic. Other forms of routing would support more terrestrial use cases and extend the penetration of DTN rather than replacing CGR. Cheers, Elwyn From nobody Thu Jun 12 00:47:23 2014 Return-Path: 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 175E91A02DF; Thu, 12 Jun 2014 00:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 sjoLJST8PKQ4; Thu, 12 Jun 2014 00:47:18 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B5221A02AF; Thu, 12 Jun 2014 00:47:17 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id n12so810894wgh.19 for ; Thu, 12 Jun 2014 00:47:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=Bg+ravAEizPTynmORhukLPFlvMYIIT7arT/px7XLDVA=; b=E3UoTqDWnwhX49v5LuJX4KV1iCLBbhGBkg/PvPV9vUFyLHmIPOu1/OwhG/Qhi3OJmw j2kMLxZOGcx0GzDopo2t6uyV20aL+Mw49RJ03LBcOjtrKf2HVOu4okbLV5H51Q7RNcnU UFGbHuIru35Hq/AftbkuWqWpuFvb60ebiMnrUfmYqdlOXMWxwuVJRnnEF/n53sJ7LmkT NxnQRY8rQQ5iM2vwI7/5Ll6BJEqbngTQV1EqtIkHmv3yNYtDelEUSoT3fgp0/RhV7pjr YSObNIht7SkELk3jHpMouiApb0+sUHy9XonINP1cnix0IGtsJBT47/dnB0NFAUE0ikvy ug0w== X-Received: by 10.180.84.168 with SMTP id a8mr3852827wiz.36.1402559236072; Thu, 12 Jun 2014 00:47:16 -0700 (PDT) Received: from [192.168.1.2] (dsl-aav4md.dyn.edudsl.gr. [37.32.219.37]) by mx.google.com with ESMTPSA id 8sm3166312eea.10.2014.06.12.00.47.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 00:47:15 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_08A9C25B-ED19-477F-A78C-4B377695B75C" From: Nikolaos Bezirgiannidis In-Reply-To: <1402528126.2995.294.camel@mightyatom> Date: Thu, 12 Jun 2014 10:47:11 +0300 Message-Id: <2799290A-EB6D-42D7-A5C2-B3B176E6D614@gmail.com> References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> , <1401967219583.26821@surrey.ac.uk> , <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk> , <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> <1402389636710.92429@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830486EBE@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> <1402490970.2995.76.camel@mightyatom> <1402510887.2995.155.camel@mightyatom> <5398A721.7080701@gmail.com> <1402528126.2995.294.camel@mightyatom> To: Elwyn Davies X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/x4eVan_OWlDnoUN_kkAR6nbW3Jk Cc: Sebastian Schildt , Spencer Dawkins , "dtn@ietf.org" , "iesg@ietf.org" Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 07:47:20 -0000 --Apple-Mail=_08A9C25B-ED19-477F-A78C-4B377695B75C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Elwyn, All I agree that CGR standardization will be an important initial step = towards the right direction for the DTN WG. More below. On Jun 12, 2014, at 2:08 AM, Elwyn Davies wrote: > 3. The space use case is most likely to get production deployment in = the > short to medium term. I put "routing" in quotes because the expected > way that DTN bundles will be forwarded is using Contact Graph Routing. > This is not a distributed system. It is more in the nature of a > centralized application or oracle that is all-informed as regards > contact opportunities and traffic loads and provides a forwarding > schedule for nodes that is loaded into nodes in advance - effectively = an > extension of the management story. At least one implementation exists > (ION) but it is not formally documented and AFAIK there is no > standardized way for nodes to interact with the oracle to give it > information and find out what they should be doing. It seems to me = that > this part ought to be documented and standardized to complete a > minimalist DTN system for space (and for some terrestrial applications > also). In the management part, just to inform you that in last year=92s Chants = workshop we have presented Contact Plan Update Protocol (CPUP) and a = dissemination mechanism to reactively inform nodes about contact plan = updates. It is also in our future plans to implement it in ION. http://dl.acm.org/citation.cfm?id=3D2505499 Regards, Nikos= --Apple-Mail=_08A9C25B-ED19-477F-A78C-4B377695B75C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi Elwyn, All

I agree = that CGR standardization will be an important initial step towards the = right direction for the DTN WG. More below.

On Jun = 12, 2014, at 2:08 AM, Elwyn Davies <elwynd@folly.org.uk> = wrote:

3. The space use case is most likely = to get production deployment in the
short to medium term.  I = put "routing" in quotes because the expected
way that DTN bundles will be forwarded is using Contact = Graph Routing.
This is not a distributed system.  It is more in the = nature of a
centralized application or oracle that is all-informed as = regards
contact opportunities and traffic loads and provides a = forwarding
schedule for nodes that is loaded into nodes in advance - = effectively an
extension of the management story.  At least one = implementation exists
(ION) but it is not formally = documented and AFAIK there is no
standardized way for nodes to = interact with the oracle to give it
information and find out what = they should be doing.  It seems to me that
this part ought to be documented and standardized to = complete a
minimalist DTN system for space (and for some terrestrial = applications
also).

In the = management part, just to inform you that in last year=92s Chants = workshop we have presented Contact Plan Update Protocol (CPUP) and a = dissemination mechanism to reactively inform nodes about contact plan = updates. It is also in our future plans to implement it in = ION.


Regards,
Nik= os
= --Apple-Mail=_08A9C25B-ED19-477F-A78C-4B377695B75C-- From nobody Thu Jun 12 04:35:08 2014 Return-Path: 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 304631B284E; Thu, 12 Jun 2014 04:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 6nbBy5IcwBcU; Thu, 12 Jun 2014 04:34:59 -0700 (PDT) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 351231B284F; Thu, 12 Jun 2014 04:34:59 -0700 (PDT) Received: by mail-yh0-f41.google.com with SMTP id z6so839171yhz.0 for ; Thu, 12 Jun 2014 04:34:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=WsxOV7cfonfcz7ekjaRsLUvRE40JwMyOJGlJN+ipuys=; b=j8aex2uhLFoozULFnTO0BuzINwsi8oATmowgJQ2ip5lQOTYgLQrC7V9RcRTKoflYb+ 8gZSkboTSFxZz9d23sxmuexbGpUg5ot75I5ayGLZAMigMvznFzfMGd/LMG/METrVTsiF eckfJwp7RrXIAomr+UspmYGYeXR5liQr8SsxusutAFI2g1tbFkFWheRBbbNUJfoGGX7Z ulalRF5bCx0847m8BzHTVVtfY/xTvxFSUSF3H1M0xMkkfftXJ/l5dxkiIgK7rIqyD1kr 04EsAq80pExKaGWKxmFdGLekV3r+JLRX2ZqwTgoovfPKee4Kw5Ts+1KozfCzP4IdIKbK 86IA== X-Received: by 10.236.18.195 with SMTP id l43mr2393045yhl.150.1402572898537; Thu, 12 Jun 2014 04:34:58 -0700 (PDT) Received: from [10.71.14.162] ([64.197.173.10]) by mx.google.com with ESMTPSA id v60sm954300yhc.40.2014.06.12.04.34.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 04:34:58 -0700 (PDT) Message-ID: <53999060.7090900@gmail.com> Date: Thu, 12 Jun 2014 06:34:56 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Elwyn Davies References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> , <1401967219583.26821@surrey.ac.uk> , <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk> , <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> <1402389636710.92429@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830486EBE@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> <1402490970.2995.76.camel@mightyatom> <1402510887.2995.155.camel@mightyatom> <5398A721.7080701@gmail.com> <1402528126.2995.294.camel@mightyatom> <539927CF.6010901@gmail.com> <1402556744.2995.335.camel@mightyatom> In-Reply-To: <1402556744.2995.335.camel@mightyatom> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/7VzZC_Glfw8UMNfdyo7kcJjok8c Cc: "iesg@ietf.org" , "dtn@ietf.org" , Sebastian Schildt Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 11:35:01 -0000 On 06/12/2014 02:05 AM, Elwyn Davies wrote: > Hi, Spencer. > > Phew! > > A bit more below.. > > On Wed, 2014-06-11 at 23:08 -0500, Spencer Dawkins wrote: >> Hi, Elwyn, >> >> Thanks for the quick and helpful response. See inline. >> >> Spencer >> >> On 06/11/2014 06:08 PM, Elwyn Davies wrote: >>> Hi, Spencer. >>> >>> I'll try and rationalise why I think we might want to go this way... >>> see below. >>> >>> On Wed, 2014-06-11 at 13:59 -0500, Spencer Dawkins wrote: >>>> On 06/11/2014 01:21 PM, Elwyn Davies wrote: >>>>> Hi, Sebastian. >>>>> >>>>> In the light of what you say below, I think it would be useful to >>>>> suggest a couple of use cases that should be kept in mind during the >>>>> update of the BP so that we can incorporate them into the charter asap. >>>>> >>>>> More below... >>>>> >>>>> >>>>> On Wed, 2014-06-11 at 15:49 +0200, Sebastian Schildt wrote: >>>>>> I know we had some discussion at some conference or workshop about >>>>>> this. I believe routing (as in "a better Epidemic/Prophet") is not >>>>>> neccessary for terrestrial DTN applications. Most of the time we have >>>>>> small scale networks (Flooding/Gossipping is fine), or highly >>>>>> application-specific solutions (nobody would use a general purpose >>>>>> routing mechanism if the application is public transportation). For >>>>>> interconnection we have the internet/ip, so we just need naming there. >>>>>> I know, we can have the discussion and agree to disagree, so I would >>>>>> rephrase it like this >>>>>> >>>>>> "IMO a DTN system that doesn't address bundle routing is only half-baked." >>>>>> Yes, defintely. At least you should know how to get stuff from A to B >>>>>> in your application. >>>>>> >>>>>> However I would add >>>>>> "Routing is of no concern for the core BP(bis) specification" >>>>>> Just as the IPv(4/6) main specs do not say much about routing. >>>>> Absolutely: My opinion is that the charter needs to say something about >>>>> routing immediately. This wouldn't affect the work items already >>>>> identified but would add an extra item or two to begin the process of >>>>> specifying both CGR and getting the requirements in place for an >>>>> opportunistic protocol. This is partly political to show that we >>>>> haven't forgotten routing and partly to snsure we don't do anything too >>>>> stupid in the other work items that will later screw up routing >>>>> (addressing is a key area!) >>>> So, Martin and I haven't divided up the TSV BOFs yet, so I might be the >>>> responsible AD or I might be the irresponsible AD, but speaking as at >>>> least one of those two possibilities ... >>>> >>>> Why would DTN routing be part of the work that might or might not be >>>> chartered in TSV? >>>> >>>> Lumping transport and routing (and whatever else) in the IRTF DTNRG >>>> makes perfect sense, but I would have thought that we'd split transport >>>> and routing in an IETF WG. >>>> >>>> Could someone help me understand? >>> I'll try a bit... >>> >>> 1. DTN is a distinct architecture that does not really match the >>> terminology used to distinguish the areas in the IETF. You could make a >>> perfectly valid case for the Bundle Protocol finding a home in Apps, TSV >>> or Internet areas.. and there is a management piece. And it's new as a >>> standards track so it isn't going to get its own area and it's quite >>> small. So we would be really grateful if you can give us a home until >>> we grow up. But enough of this neediness! >>> >>> 2. As a new system there are a number of parts that need to be in place >>> to have the bare bones of a complete system. Arguably we should at the >>> very least be going for a SEC area WG to do the SBSP and maybe an OPS >>> area WG to do the management part (which isn't just a MIB). Whether we >>> have critical mass to do all of these things in separate WGs in parallel >>> I wouldn't like to say. However they are rather more closely coupled in >>> the DTN bundle architecture than in the conventional IP architecture and >>> would need to be closely coordinated. The "routing" component is the >>> other piece which really needs to be in place to achieve a complete >>> story. >>> >>> 3. The space use case is most likely to get production deployment in the >>> short to medium term. I put "routing" in quotes because the expected >>> way that DTN bundles will be forwarded is using Contact Graph Routing. >>> This is not a distributed system. It is more in the nature of a >>> centralized application or oracle that is all-informed as regards >>> contact opportunities and traffic loads and provides a forwarding >>> schedule for nodes that is loaded into nodes in advance - effectively an >>> extension of the management story. At least one implementation exists >>> (ION) but it is not formally documented and AFAIK there is no >>> standardized way for nodes to interact with the oracle to give it >>> information and find out what they should be doing. It seems to me that >>> this part ought to be documented and standardized to complete a >>> minimalist DTN system for space (and for some terrestrial applications >>> also). >>> >>> 4. The opportunistic routing story is not something we can start on at >>> present as we don't know what it will be yet. This would be nearer a >>> real routing story although (a.s.) still be entirely different from IP >>> routing systems. If and when we have a solution to standardize, this one >>> may well be worth its own WG but that is a story for another day. What >>> might make sense is to devote some effort to a requirements document to >>> ensure that the BPbis can handle what is needed. >>> >>> 5. So overall, I see that CGR is effectively an aspect of management >>> rather than a routing protocol in the IP sense when it comes to bits on >>> the wire/aether. So, Spencer, if you are prepared to host the >>> management part in the existing charter, then CGR can be viewed as an >>> extension of this. >>> >>> I hope this helps a bit. >> None of this surprises me a lot (I never worked on DTN, but did pay >> attention to it from time to time). I was responding to a note about >> keeping options open for routing, and wondered if having a completely >> different home for routing would help enforce that separation. >> >> IIUC, the first targeted use case can base routing decisions on a >> centralized oracle, so wouldn't particularly benefit from RTG clue; if >> you are able to keep a solid fence between the rest of DTN and routing >> in a single working group, any subsequent work that looks more like The >> Distributed Routing System We Know And Love could be spun up in a RTG >> working group, if that seems helpful, with the subsequent output >> parachuted in as a CGR replacement. >> >> Did I get that right? > Almost. It is unlikely that the space use case would ever use anything > but CGR for the foreseeable future. Celestial mechanics, resource > scheduling on the ground stations and for the most part unidirectional > links means that anything more opportunistic isn't realistic. Other > forms of routing would support more terrestrial use cases and extend the > penetration of DTN rather than replacing CGR. Thanks for the clue :-) And I'm fine housing the centralized "routing-lite" function in the same working group, unless Adrian or Alia clue-by-four me (which is appreciated when it's needed). Spencer From nobody Thu Jun 12 07:21:43 2014 Return-Path: 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 272231B2872 for ; Thu, 12 Jun 2014 05:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 DhnM_s5bKZ44 for ; Thu, 12 Jun 2014 05:25:02 -0700 (PDT) Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F28D1B286C for ; Thu, 12 Jun 2014 05:25:02 -0700 (PDT) Received: by mail-yh0-f43.google.com with SMTP id a41so874936yho.30 for ; Thu, 12 Jun 2014 05:25:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=lCLPiIonLJoXi2WT/koXXDmhPeh/Pblc2WBg1B9zVTg=; b=J+1xw/r8s9q9fmEPausBXfbaYrdDiTwVwrb3+JldK2NneX+ZfWOGeQV4orwmtk4E+0 +RtK8QYvNE3bbTAbojp9Ihgu5EWE9U2yVnbnB3DIC8jtn4/RTbg+MVc/c7aokFHnRJQw Hreeao6y9MB0e5pckhzsMORjmnPZcZBl2HYbD6yFI7gieptM1/igXzWRySJftjNjyooA a/Tw3m3g/vlddhzuw00s3J0gB+lWxbpGXjqppDYAAC/cKHUqLCyVo2L7ItK1hrGJk2Qd /85hSUDQB1uJYmUmmnltm/eEy9l5wxbJMe6OatNo1HfKtYSfSUUhSOKZZS5KFmA/PCTG KAZg== MIME-Version: 1.0 X-Received: by 10.236.110.234 with SMTP id u70mr2045658yhg.160.1402575901596; Thu, 12 Jun 2014 05:25:01 -0700 (PDT) Received: by 10.170.203.193 with HTTP; Thu, 12 Jun 2014 05:25:01 -0700 (PDT) Date: Thu, 12 Jun 2014 08:25:01 -0400 Message-ID: From: Angela Hennessy To: "Birrane, Edward J." , dtn@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/DiOe1HLXa2wWnb83b_XIrZ1o8tY X-Mailman-Approved-At: Thu, 12 Jun 2014 07:21:39 -0700 Subject: Re: [dtn] Security in BPv7 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 12:25:03 -0000 I agree, it's much easier to work on a security document while addressing BPv7 (so for example, we can include things like block identification). Ed makes a good case for a separate BSP/SBSP document, which could specify having some security services on by default. -Angela From nobody Thu Jun 12 07:21:44 2014 Return-Path: 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 67FEB1B2880 for ; Thu, 12 Jun 2014 05:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.028 X-Spam-Level: X-Spam-Status: No, score=-1.028 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 0T9k562odrNJ for ; Thu, 12 Jun 2014 05:29:44 -0700 (PDT) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B3251B2872 for ; Thu, 12 Jun 2014 05:29:44 -0700 (PDT) Received: by mail-yh0-f52.google.com with SMTP id a41so875504yho.25 for ; Thu, 12 Jun 2014 05:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=dg+CekeytSw4HEJmn3okbx02r5cBQck/qDcSSegHwlQ=; b=zpveUA3i5djFcc6nnscVp8cs8tYYfp7/ip+WwBaubIpHy7Eu798gVDtWPFCkAk+Kbe fQrdLHYWscWW4KCmqM8UY+8J4tXuhB1HWkm516xBkaRTnS93mY/rtYsMsVspFip2EQzz bxwq8bXkARuEXNsq1/xVwcpBZmvUygcxU0Zh66yJfefwEL+ltHnRbbqkBTA7i8o1DnYR 7KwxopWTrkoIOsfQN9fNYirNr6c0UAoRlugHzQQgYTY/g0Q6zrox41zL5SlB9Tsm23X2 NWRQMe8tIPP3mGgiA24CsNhxy+mRYIpUOp3pZZ5gNQz+QtXeFlj+BgySqlfDV3uyrJA7 zHnQ== MIME-Version: 1.0 X-Received: by 10.236.114.193 with SMTP id c41mr2786195yhh.156.1402576183857; Thu, 12 Jun 2014 05:29:43 -0700 (PDT) Sender: ahennes1@gmail.com Received: by 10.170.203.193 with HTTP; Thu, 12 Jun 2014 05:29:43 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 Jun 2014 08:29:43 -0400 X-Google-Sender-Auth: r_Gjyivfz_mUS-Vpe9L-t9MnPX4 Message-ID: From: Angela Hennessy To: "Birrane, Edward J." , dtn@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/jDjXMW1KwjlLU4Id_ierR3VT5Vg X-Mailman-Approved-At: Thu, 12 Jun 2014 07:21:40 -0700 Subject: Re: [dtn] Security in BPv7 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 12:29:45 -0000 I agree, it's much easier to work on a security document while addressing BPv7 (so for example, we can include things like block identification). Ed makes a good case for a separate BSP/SBSP document, which could specify having some security services on by default. -Angela From nobody Thu Jun 12 07:43:38 2014 Return-Path: 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 6954F1B2A6F for ; Thu, 12 Jun 2014 07:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 jI8dSDlLRDGM for ; Thu, 12 Jun 2014 07:43:36 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8BA91B2A68 for ; Thu, 12 Jun 2014 07:43:35 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id u56so1391153wes.22 for ; Thu, 12 Jun 2014 07:43:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=MEBQYCDBj6cDBirY/pZDH7wG35I9igKS2TzLxQH2zHI=; b=yolzXffrJRn1htAU9EK884Iw1oST0byh2/WSjYQhvyzWJ773z6qk6qhY+6VXgUTjth z6CQNrgI1+fRG2gC8jVBWHYALuu4/jwQnGjj8MuDYMdMPjZm4kFzDqM//3H850gcI84g 0Es5n3lmbJNF7E26fa4Pmih2ejcVqH4ehlSrl77Vt/y+wMd+PpK60tD8UAEtXIJ5HMq9 tgcUTJ83veX/r29TPe9z7bPhQd0sP6ZQ5a/kA0aMZr7qaSh4LAE+JTXiI3xw/jqB+AsI 3PrmMwm55Zazn5ciA6fJ+OhoVAfU6yFYDYpgh6Q3jtvOQat/39SQHyANcoy5ifpla1R0 xAKQ== X-Received: by 10.180.96.6 with SMTP id do6mr7307118wib.44.1402584214133; Thu, 12 Jun 2014 07:43:34 -0700 (PDT) Received: from Martins-MacBook-Pro-2.local (tmo-106-220.customers.d1-online.com. [80.187.106.220]) by mx.google.com with ESMTPSA id v7sm5095280eew.37.2014.06.12.07.43.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 07:43:33 -0700 (PDT) Message-ID: <5399BBE9.4010208@gmail.com> Date: Thu, 12 Jun 2014 16:40:41 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dtn@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/jBFwTEOw8TZ5TUhsYZW4OXd2EBE Subject: [dtn] DTN BOF approved X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 14:43:37 -0000 Dear all, Just to let you know that the DTN BOF is approved for the IETF-90 meeting in Toronto. There are no chairs appointed for the BOF by now, but I will get to this quite soon. Thanks, Martin -- your responsible Area Director From nobody Thu Jun 12 07:43:45 2014 Return-Path: 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 201451B2A68 for ; Thu, 12 Jun 2014 07:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 Lto0N20GYEW3 for ; Thu, 12 Jun 2014 07:43:39 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D62A1B2A75 for ; Thu, 12 Jun 2014 07:43:38 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id q59so1426015wes.27 for ; Thu, 12 Jun 2014 07:43:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=IqYE73j5eWLydVmrYl4OLxfwJE0C//DxjUsBliyjNAQ=; b=zdHFZLrhHhFrF23B5m2mOMrnN4nZwrc9xPNlN0HhNj+/fTYlOukKYg/BPZPiHrDdkE BHvPmZv65yZ+HfrNc41t4tN1eqwzEsyjudu2+sbBFX960vmWtX4GuzUseK32PJdpYsBm 2ecnEXzGGYZi1prv4zbOVcF+waQuT7/w+OoFeCJov1ZPUWgpkt3yQPVmsYBy0+tvshyO mnWnuMaFok8YJJsCD4on9r57lYKNyTjx31CZTriN8PB/Bl/zBf+b9ocSSY6oLv7spNB1 SagFZTo6G24mTt5xpiaWsV62oQG4uusBBDmOgqkbPjr0EDhfm2oj7vlkDhrgKxwGsku5 pU6w== X-Received: by 10.180.12.135 with SMTP id y7mr7103155wib.39.1402584217296; Thu, 12 Jun 2014 07:43:37 -0700 (PDT) Received: from Martins-MacBook-Pro-2.local (tmo-106-220.customers.d1-online.com. [80.187.106.220]) by mx.google.com with ESMTPSA id h6sm5093777eew.38.2014.06.12.07.43.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 07:43:36 -0700 (PDT) Message-ID: <5399BC2E.10707@gmail.com> Date: Thu, 12 Jun 2014 16:41:50 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Elwyn Davies , "Templin, Fred L" , "dtn@ietf.org" References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> , <1401967219583.26821@surrey.ac.uk> , <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk> , <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> <1402389636710.92429@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830486EBE@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> <1402490970.2995.76.camel@mightyatom> <2134F8430051B64F815C691A62D983183048A030@XCH-BLV-512.nw.nos.boeing.com> <1402513416.2995.198.camel@mightyatom> In-Reply-To: <1402513416.2995.198.camel@mightyatom> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/Wwmk2oAa__ssUNySoA8O5FKbySs Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 14:43:44 -0000 Hi all, Yes, it is time to work on a charter on **this list**. One point that came up during the IESG review is if the charter should include work that re-evalutes the DTN architecture and figures out if other protocols are neeeded or if the choices for the bundle protocol is the right forward. Thanks, Martin Am 11.06.14 21:03, schrieb Elwyn Davies: > Hi, Fred. > > It looks like we are more or less singing from the same hymn sheet (or > whatever) here. > > I would say that we should update the charter asap since it will be > discussed by the IESG/IAB probably tomorrow and it would be desirable to > make it clear what we are trying to achieve and that it hangs together > as a system. > > Some specific points for the charter : > >>From my experience of BoFS, I would say that you need to allow at least > 30 minutes at the end for general discussion and decision 'hums'. > Accordingly you will have to claw back some time from all or most of the > segments. It might be possible to scrap the registry discussion > altogether as it is a bit detailed. Maybe replace it with a brief > discussion on routing mainly devoted to CGR. > > Put in some other terrestrial use cases and generally even up the > balance between space and terrestrial. I'll try and produce some actual > words later in a concrete redraft of the charter (also taking into > account Lars' comments). > > I think that Lars is roughly right on the timescales... multiply > everything by 2 or maybe 3. > > I would add two and possibly three or four work items: > - Specify a node discovery protocol (standards track) > - Describe the operation of CGR in a DTN BPbis environment > (informational doc) and identify if there is any useful standardization > work that needs to be done (this might be specifying information formats > for bundles passing contact schedules, traffic requests and > notifications about in a CGR network - could possibly be new BP block > types). > - (If the CGR work decides it is useful) Specify the information formats > and/or block types for CGR. (could be in a recharter) > - (maybe) Specify requirements for a general purpose opportunistic > routing protocol. > > Regards, > Elwyn > > On Wed, 2014-06-11 at 15:56 +0000, Templin, Fred L wrote: >> Hi Elwyn, >> >> See below for some responses: >> >>> -----Original Message----- >>> From: Elwyn Davies [mailto:elwynd@folly.org.uk] >>> Sent: Wednesday, June 11, 2014 5:50 AM >>> To: Templin, Fred L >>> Cc: iesg@ietf.org; dtn@ietf.org >>> Subject: Re: [dtn] DTN BoF Proposal for IETF90 >>> >>> Hi. >>> >>> I would be happy to see a BoF at IETF90, but I think we need to be >>> clearer about what would be the expected usage of the work that would >>> come out a WG that was formed as a result. I have the impression from >>> what I have seen on the mailing list that the work might well be >>> dominated by the requirements of the space use case but the charter is >>> currently silent on the intentions. >> >> The charter is open for discussion as input to the BoF. I too >> want for the charter to point the way to uses cases beyond just >> space-based. >> >>> Personally I am keen to see DTN used in space but I am also still a >>> believer in terrestrial usage. >> >> Concur. >> >>> There is clearly a tension between >>> getting something done quickly and efficiently for the space case where >>> there is potential for (relatively) short term (nothing is really that >>> short term in space exploration!) deployment, and updating the BP etc in >>> a way that will also move along the terrestrial usage where the >>> requirements are slightly different and not so well set in concrete. >> >> Whatever gets standardized should apply equally for space-based >> and terrestrial. If more is needed to fully support opportunistic >> terrestrial use cases beyond what is accomplished in the initial >> chartered work items, then the additional items will be brought >> in through a rechater. >> >>> The lack of clarity over intended usage could well have a bad impact on >>> the WG if it results in disagreements over the specifications. It also >>> shows up in what is *not* in the charter. most notably in the absence of >>> any consideration of how to route the bundles that BPbis handles. IMO a >>> DTN system that doen't address bundle routing is only half-baked. >> >> The initial charter calls for a simple CL; it could also call >> for a simple routing mechanism, e.g., CGR. >> >>> There seems to be a reasonable concensus that Contact Graph Routing >>> (CGR) would be appropriate for the space case. Now this is primarily a >>> centralized all-informed oracle based system so there isn't the need to >>> exchange advertisements and such like but it strikes me that there are >>> aspects of a CGR that might need standardization such as disseminating >>> contact and route information to remote nodes, notifying the oracle of >>> traffic requests and ideas for handling failures such as notifying the >>> oracle that things didn't work as intended. I therefore think that work >>> on CGR should be part of the charter at least (I understood that CCSDS >>> was thinking about it but that work seems to have stalled). >> >> I think that is a reasonable suggestion, and would be happy to >> entertain suggestions on charter amendments. But, do we need to >> do that before the BoF or as an output of the BoF? >> >>> On the terretrial front, one of the major barriers to progress has been >>> the lack of an effective, reasonably general purpose, opportunistic >>> routing protocol despite the immense amount of academic work that has >>> been put in. I believe (and am trying to put some concrete answers into >>> practice) that this is a soluble problem but it limits the current >>> deployability of DTN outside the space sector. >> >> Not necessarily. I think we can also consider coordinated >> terrestrial use cases where CGR is sufficient as in-scope >> for the initial charter. >> >>> It may be that this problem is seen as a show stopper for the >>> terrestrial use case and, hence, that the WG should be entirely devoted >>> to the space case. Personally I think this would be a shame and I would >>> be less enthusiastic about working with this limited agenda. However, >>> if that agenda is the case, the charter ought to be clear and the IESG >>> needs to be aware of where things are going. >> >> Agree that the charter needs to point the way to a broader set >> of use cases beyond space-based and coordinated terrestrial even >> if it is beyond the scope of the initial work items. >> >>> BTW I concur with Lars that the timescales in the charter proposal are >>> wildly optimistic. >> >> Which of the work items do you believe have unrealistic timescales? >> >> Thanks - Fred >> fred.l.templin@boeing.com >> >>> Regards, >>> Elwyn >>> >>> On Tue, 2014-06-10 at 15:44 +0000, Templin, Fred L wrote: >>>> Let me make this clearer and decoupled from earlier discussions: >>>> >>>> Who would like to see a DTN BoF at IETF90? >>>> >>>> Thanks - Fred >>>> fred.l.templin@boeing.com >>>> >>>> _______________________________________________ >>>> 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 > From nobody Thu Jun 12 07:54:33 2014 Return-Path: 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 BEBF61B2A76 for ; Thu, 12 Jun 2014 07:54:31 -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 WuyLooWj1TDg for ; Thu, 12 Jun 2014 07:54:29 -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 B273E1B2A46 for ; Thu, 12 Jun 2014 07:54:29 -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 s5CEsS0B011988; Thu, 12 Jun 2014 09:54:29 -0500 Received: from XCH-PHX-106.sw.nos.boeing.com (xch-phx-106.sw.nos.boeing.com [137.136.238.9]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s5CEsNtu011939 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 12 Jun 2014 09:54:24 -0500 Received: from XCH-BLV-412.nw.nos.boeing.com (137.136.239.136) by XCH-PHX-106.sw.nos.boeing.com (137.136.238.9) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 12 Jun 2014 07:54:23 -0700 Received: from XCH-BLV-512.nw.nos.boeing.com ([169.254.12.74]) by XCH-BLV-412.nw.nos.boeing.com ([169.254.12.88]) with mapi id 14.03.0181.006; Thu, 12 Jun 2014 07:54:22 -0700 From: "Templin, Fred L" To: Martin Stiemerling , Elwyn Davies , "dtn@ietf.org" Thread-Topic: [dtn] DTN BoF Proposal for IETF90 Thread-Index: Ac+AQa9Fez/CplZaSwyaLFpzb8tj0wAiVZ0A///Hp/D//5OnYIABipvO//qPd7CAC7TeXf//SGxA//6DxzD/+y/3AP/2pkiA/+vJSB7/15AZcA== Date: Thu, 12 Jun 2014 14:54:21 +0000 Message-ID: <2134F8430051B64F815C691A62D983183048ACFE@XCH-BLV-512.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> , <1401967219583.26821@surrey.ac.uk> , <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk> , <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> <1402389636710.92429@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830486EBE@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> <1402490970.2995.76.camel@mightyatom> <2134F8430051B64F815C691A62D983183048A030@XCH-BLV-512.nw.nos.boeing.com> <1402513416.2995.198.camel@mightyatom> <5399BC2E.10707@gmail.com> In-Reply-To: <5399BC2E.10707@gmail.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/YlLAEw1c3BNwG52K70sMo6guVjs Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 14:54:31 -0000 Hello Martin, > Yes, it is time to work on a charter on **this list**. See below for the current draft charter: Fred fred.l.templin@boeing.com --- Proposed working group charter: ******************************* Working group name:=20 Delay/Disruption Tolerant Networking Working Group (DTNWG) Chair(s): TBD Area and Area Director(s): Transport Area: ADs Spencer Dawkins , Martin Stiemerling Responsible Area Director: TBD Mailing list: General Discussion: dtn at ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dtn Archive: http://www.ietf.org/mail-archive/web/dtn/current/maillist.ht= ml Description of Working Group: The Delay/Disruption Tolerant Network Working Group (DTNWG) specifies mechanisms for data communications in the presence of long delays and/or intermittent connectivity. The work is motivated by well known limitations of standard Internet protocols that expect end-to-end connectivity between communicating endpoints, sub-second transmission delays and robust packet delivery ratios. In environments where these favorable conditions do not apply, existing mechanisms such as reliab= le transport protocols and routing protocols can fail to converge result= ing in communication failures. Furthermore, classical end-to-end security associations cannot be coordinated when communicating endpoints canno= t conduct multi-message keying exchanges in a timely fashion. These limitations suggest the need for a new approach.=20 =20 Delay-Tolerant Networking (DTN) protocols have been the subject of extensive research and development in the Delay-Tolerant Networking Research Group of the Internet Research Task Force since 2002. In particular, the DTN Bundle Protocol (RFC 5050) and Licklider Transmission Protocol (RFC 5326) have been shown to address the issues identified above in substantial fielded deployments [1]. The success of the BP/LTP protocol stack -- the core protocols of the "DTN Architecture" originally described in RFC 4838 -- may be attribu= ted to the following fundamental design principles: - There is never any expectation of contemporaneous end-to-end connectivity between any two network nodes. - Because end-to-end connectivity can never be assumed, each node on the path between source and destination must be prepared to handle incoming "bundles" of data that cannot immediately be forwarded. - Again because end-to-end connectivity can never be assumed, end-to-end conversational data exchange can never be assumed to complete in a timely manner; protocol features that rely on timely conversational data exchange must be excluded from the architecture. The DTNWG believes that protocols adhering to these principles offer opportunities for enhancing the functionality of the Internet - in particular, for facilitating the extension of the Internet into environments such as the ocean floor and deep space in which the core Internet protocols operate sub-optimally for the reasons discussed earlier. We believe that the extensive research, demonstration, and pilot operations performed to date using the DTNRG protocols provides a firm basis for publishing Internet standards derived from that work= . Work items related to Delay/Disruption Tolerant Networking include: o A mechanism for the exchange of protocol data units, termed "bundles", that are designed to obviate conversational communications by containing values for all potentially relevant configuration parameters. These protocol data units are typically larger than network-layer packets. We will derive this bundle exchange mechanism from the DTN Bundle Protocol (BP) documented in RFC 5050 by publish= ing a new document for which [2] is a proposed first draft (where appendix A provides a summary of the proposed changes). o A security protocol for ensuring that the network in which bundles are exchanged is secured against unauthorized access and denial of service attacks, and to ensure data integrity and confidentiality in that network where necessary. We will derive this security protocol from a "streamlined" adaptation of the DTN Bundle Security Protocol documented in RFC 6257. o An encapsulation protocol for "tunneling" BP traffic within bundles that are secured and/or routed in different way from the encapsulated bundles. o A delay-tolerant security key management scheme for ensuring that public keys are certified by a globally trusted authority to protect the integrity of the infrastructure. o A simple datagram convergence layer protocol for adaptation of the bundle protocol to underlying internetworks. We expect to derive this convergence layer protocol from the Datagram Convergence protocol documented in RFC 7122. o A delay-tolerant network management protocol for management of the infrastructure in the presence of long delays and/or intermittent connectivity. o A registry for DTN Service Identifiers =20 The working group will consider extending the current milestones based = on new information and knowledge gained while working on the initial chart= er, as well as to accommodate new work items beyond the scope of the initia= l phase. For example, we expect that transport protocols such as LTP and the Saratoga protocol are among the candidates for work in this phase. =20 Goals and Milestones: start+3mos - Submit 'Bundle Protocol Specification (RFC5050bis)' as a working group document [2]. To be Proposed Standard. Start+3mos - Submit 'Streamlined Bundle Security Protocol (SBSP)' as a working group document [3]. To be Proposed Standard. start+6mos - Submit 'Bundle In Bundle Encapsulation (BIBE)' as a working group document [4]. To be Proposed Standard. start+12mos - Submit 'Delay Tolerant Networking Security Key Management' = as a working group document. To be Proposed Standard. start+18mos - WG determination for merging RFC5050bis, SBSP, BIBE and/or Key Mgmt into a combined draft or keep as separate drafts. start+18mos - Submit RFC5050bis, SBSP, BIBE and Key Mgmt to the IESG eith= er as a combined draft or as separate drafts. start+18mos - Submit Network Management [5], Registry [6] and Simple Convergence Layer [7] as working group documents. start+20mos - Survey appropriate forums (e.g., DTNRG) for emerging technologies (e.g., convergence layer protocols, dynamic routing protocols, naming and addressing services, etc.) ready for transition into IETF DTN Working Group. Publish draft on survey results as independent submission related to the WG. start+24mos - Submit Network Management, Registry and Simple Convergence Layer to IESG start+24mos - Recharter to accommodate new work items or close Working Gr= oup [1] "BP/LTP deployment on EPOXI spacecraft" [2008], http://committees.comsoc.org/tccc/ccw/2010/slides/DINET_CCW.pdf =20 [2] "Proposed Revised Bundle Protocol" [2014], https://datatracker.ietf.org/doc/draft-burleigh-bpv7/ [3] "Streamlined Bundle Security Protocol Specification" [2014], https://datatracker.ietf.org/doc/draft-irtf-dtnrg-sbsp/ [4] "Bundle-in-Bundle Encapsulation" [2013], http://tools.ietf.org/id/draft-irtf-burleigh-bibe [5] "Delay Tolerant Network Management Protocol" [2013], http://tools.ietf.org/id/draft-irtf-dtnrg-dtnmp [6] "Delay-Tolerant Networking Bundle Protocol IANA Registries" [2011], https://datatracker.ietf.org/doc/rfc6255/ [7] "Datagram Convergence Layers ..." [2014], https://datatracker.ietf.org/doc/rfc7122/ From nobody Thu Jun 12 08:07:55 2014 Return-Path: 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 99F1E1A0108 for ; Thu, 12 Jun 2014 08:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 NmVndgefuLuY for ; Thu, 12 Jun 2014 08:07:37 -0700 (PDT) Received: from mail.ibr.cs.tu-bs.de (mail.ibr.cs.tu-bs.de [IPv6:2001:638:602:1181:5054:ff:fe75:abbf]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B7FC1B2A78 for ; Thu, 12 Jun 2014 08:07:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.ibr.cs.tu-bs.de (Postfix) with ESMTP id 0A99B182F07; Thu, 12 Jun 2014 17:07:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ibr.cs.tu-bs.de; h=x-mailer:references:message-id:content-transfer-encoding:date :date:in-reply-to:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=key1; t= 1402585651; x=1404400052; bh=DbslRdHrkce/73Taw3bKJUd5t44BVOBZrdR ft/HkLSo=; b=qyJFgNu2trtHIaJxS7ZQp2KvUMTy+xcMUCAECc+rOtK9W7DFmrc x0v6lHPhYjrSgAwjdrvd1d6F/I+tqspEISuNxNDsRAseob4pJ76wQVzzp1dTUhP3 H7i1H+zIPeH/rNtuFRBS/+BG2uxdwGTRprxh2u90YVtyfiOYEXJQoCy8= X-Virus-Scanned: Debian amavisd-new at ibr.cs.tu-bs.de Received: from mail.ibr.cs.tu-bs.de ([127.0.0.1]) by localhost (mail.ibr.cs.tu-bs.de [127.0.0.1]) (amavisd-new, port 10026) with LMTP id qcpl76znuLEa; Thu, 12 Jun 2014 17:07:31 +0200 (CEST) Received: from [134.169.35.10] (unknown [134.169.35.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schildt@ibr.cs.tu-bs.de) by mail.ibr.cs.tu-bs.de (Postfix) with ESMTPSA id 461A6182DE2; Thu, 12 Jun 2014 17:07:31 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Sebastian Schildt In-Reply-To: <2134F8430051B64F815C691A62D983183048ACFE@XCH-BLV-512.nw.nos.boeing.com> Date: Thu, 12 Jun 2014 17:07:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> , <1401967219583.26821@surrey.ac.uk> , <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk> , <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> <1402389636710.92429@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830486EBE@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> <1402490970.2995.76.camel@mightyatom> <2134F8430051B64F815C691A62D983183048A030@XCH-BLV-512.nw.nos.boeing.com> <1402513416.2995.198.camel@mightyatom> <5399BC2E.10707@gmail.com> <2134F8430051B64F815C691A62D983183048ACFE@XCH-BLV-512.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/P8n3gpteHdKDRLb6Wwsep5KrOyA Cc: Martin Stiemerling , Elwyn Davies , "dtn@ietf.org" Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 15:07:49 -0000 Hi, two small remarks Am 12.06.2014 um 16:54 schrieb Templin, Fred L = : >=20 > - There is never any expectation of contemporaneous end-to-end > connectivity between any two network nodes. >=20 > - Because end-to-end connectivity can never be assumed, each = node > on the path between source and destination must be prepared to > handle incoming "bundles" of data that cannot immediately be > forwarded. >=20 > - Again because end-to-end connectivity can never be assumed, > end-to-end conversational data exchange can never be assumed = to > complete in a timely manner; protocol features that rely on > timely conversational data exchange must be excluded from the > architecture. >=20 The third point seems redundant. Also during contact between two nodes = (not end-to-end) you might have for example some handshaking that "rely = on timely conversational data exchange". Maybe you rather want to say = something about whether and how unidirectional links are supported. >=20 > Work items related to Delay/Disruption Tolerant Networking = include: >=20 >=20 > o A delay-tolerant security key management scheme for ensuring = that > public keys are certified by a globally trusted authority to = protect > the integrity of the infrastructure. Seems a pretty bad idea for most applications. Not only, but especially = in a DTN. I think while key management is definitely a very(!) = important point, the charter should not already fix a "solution" (that = some might argue is none). What about a more neutral > Delay-tolerant security key management schemes that can protect the = integrity of a DTN network MfG Sebastian= From nobody Thu Jun 12 08:11:21 2014 Return-Path: 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 35B721B2A92 for ; Thu, 12 Jun 2014 08:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 TyGMH2pXUoAI for ; Thu, 12 Jun 2014 08:11:14 -0700 (PDT) Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59DFB1B2A85 for ; Thu, 12 Jun 2014 08:11:11 -0700 (PDT) Received: by mail-ob0-f174.google.com with SMTP id va2so1436782obc.19 for ; Thu, 12 Jun 2014 08:11:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xdqNMv64vbXyABl9+1cLLrZxTzrGR9ptFpsPf4QU2qM=; b=Vg4WqbQ7JN5/4IHqg2Rwt+5vOspGpidmo9waMCbTJ1O6aC/eMER9ZW73vxwiONrQO5 szuShOsXv8a9cwNu/Aa+pxXlKySfibYq1JmWemuEKnwk30MWm9n5mRfh/hSi2HpeGjmH 977SdUlTdT38gA9LxsnQsCRu1GKLk+weqqztuwTmWgAKtupVLvIUM1XjncHiamjLmFze vwx8hSf0+ewebHFmovkEx6eCmWjMU0sOuul+VU7tqSUdWWitGgF02LMzcBpxFXvxBbTI YYm7Nd9LjNFJbHuvcMuUn5t30xvl50jWNJj5+ZHk+GFvRPetCh3ukR1XvCOy/pGoioSq dvww== X-Gm-Message-State: ALoCoQlLqKabOVa1geqdZS1cHkXLnCQqshIF25kYO10I+c1IhMQEIEBq/ZszuymKZIYaBnDi1dKp MIME-Version: 1.0 X-Received: by 10.182.18.69 with SMTP id u5mr34520505obd.54.1402585870747; Thu, 12 Jun 2014 08:11:10 -0700 (PDT) Received: by 10.182.176.5 with HTTP; Thu, 12 Jun 2014 08:11:10 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 Jun 2014 11:11:10 -0400 Message-ID: From: Amy Alford To: Angela Hennessy Content-Type: multipart/alternative; boundary=001a11c338aa97f6fd04fba4f815 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/dmXqtoEI6XpyLbvl4wAh_daUgYI Cc: dtn@ietf.org, "Birrane, Edward J." Subject: Re: [dtn] Security in BPv7 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 15:11:19 -0000 --001a11c338aa97f6fd04fba4f815 Content-Type: text/plain; charset=UTF-8 BSP felt overcomplicated. The proposed BP7 draft meshes really nicely with the SBSP draft to simplify things. In particular: - block ids solve the problem of not being able to specify which extension block a security block is acting on (usually signing) - moving mutable fields to extension blocks (from the primary block) simplifies hashing - getting rid of the dictionary eliminates the risk of the dictionary changing between signing and verification - simplifying src addresses and singleton destination addresses will help with key management. It wasn't clear in BSP what a key should be associated with (a node, a part of the eid, the whole eid?) I would also like to see something in the BP about managing extension blocks during fragment reassembly. There is no reasonable way for a node that doesn't understand an extension block to manage it during the reassembly process. Why not specify that nodes may only reassemble fragments if they are able to process all the extension blocks present in them? In that case, the specs for the extension blocks themselves can specify how they should be handled on reassembly. On Thu, Jun 12, 2014 at 8:25 AM, Angela Hennessy wrote: > I agree, it's much easier to work on a security document while > addressing BPv7 (so for example, we can include things like block > identification). Ed makes a good case for a separate BSP/SBSP > document, which could specify having some security services on by > default. > > > -Angela > > _______________________________________________ > dtn mailing list > dtn@ietf.org > https://www.ietf.org/mailman/listinfo/dtn > --001a11c338aa97f6fd04fba4f815 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
BSP felt overcomplicated. =C2=A0The proposed BP7 draft mes= hes really nicely with the SBSP draft to simplify things.=C2=A0

In particular:
- block ids solve the problem of not being able = to specify which extension block a security block is acting on (usually sig= ning)
- moving mutable fields to extension blocks (from the primary block) s= implifies hashing
- getting rid of the dictionary eliminates the = risk of the dictionary changing between signing and verification
- simplifying src addresses and singleton destination addresses will h= elp with key management. =C2=A0It wasn't clear in BSP what a key should= be associated with (a node, a part of the eid, the whole eid?)=C2=A0
=

I would also like to see something in the BP about managing = extension blocks during fragment reassembly. =C2=A0There is no reasonable w= ay for a node that doesn't understand an extension block to manage it d= uring the reassembly process. =C2=A0Why not specify that nodes may only rea= ssemble fragments if they are able to process all the extension blocks pres= ent in them? =C2=A0In that case, the specs for the extension blocks themsel= ves can specify how they should be handled on reassembly.


On Thu, Jun 12, 2014 at 8:25 AM, Angela Hennessy <= ;ahennes1@gmail.com= > wrote:
I agree, it's much easier to work on a s= ecurity document while
addressing BPv7 (so for example, we can include things like block
identification). Ed makes a good case for a separate BSP/SBSP
document, which could specify having some security services on by
default.


-Angela

_______________________________________________
dtn mailing list
dtn@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dtn

--001a11c338aa97f6fd04fba4f815-- From nobody Thu Jun 12 09:59:42 2014 Return-Path: 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 C2B761B27C6 for ; Thu, 12 Jun 2014 09:59:39 -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 AxyheWlor_ha for ; Thu, 12 Jun 2014 09:59:38 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EA5B1A0505 for ; Thu, 12 Jun 2014 09:59:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s5CGxcKN027137; Thu, 12 Jun 2014 09:59:38 -0700 Received: from XCH-PHX-508.sw.nos.boeing.com (xch-phx-508.sw.nos.boeing.com [137.136.239.67]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s5CGxStp026587 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 12 Jun 2014 09:59:29 -0700 Received: from XCH-BLV-412.nw.nos.boeing.com (137.136.239.136) by XCH-PHX-508.sw.nos.boeing.com (137.136.239.67) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 12 Jun 2014 09:59:28 -0700 Received: from XCH-BLV-512.nw.nos.boeing.com ([169.254.12.74]) by XCH-BLV-412.nw.nos.boeing.com ([169.254.12.88]) with mapi id 14.03.0181.006; Thu, 12 Jun 2014 09:59:27 -0700 From: "Templin, Fred L" To: Sebastian Schildt Thread-Topic: [dtn] DTN BoF Proposal for IETF90 Thread-Index: Ac+AQa9Fez/CplZaSwyaLFpzb8tj0wAiVZ0A///Hp/D//5OnYIABipvO//qPd7CAC7TeXf//SGxA//6DxzD/+y/3AP/2pkiA/+vJSB7/15AZcP+uprQA/12mIbA= Date: Thu, 12 Jun 2014 16:59:27 +0000 Message-ID: <2134F8430051B64F815C691A62D983183048B009@XCH-BLV-512.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> , <1401967219583.26821@surrey.ac.uk> , <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk> , <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> <1402389636710.92429@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830486EBE@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> <1402490970.2995.76.camel@mightyatom> <2134F8430051B64F815C691A62D983183048A030@XCH-BLV-512.nw.nos.boeing.com> <1402513416.2995.198.camel@mightyatom> <5399BC2E.10707@gmail.com> <2134F8430051B64F815C691A62D983183048ACFE@XCH-BLV-512.nw.nos.boeing.com> In-Reply-To: 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/0INvLCK1QdvjsAVfFE3UFz4Oxbc Cc: Martin Stiemerling , Elwyn Davies , "dtn@ietf.org" Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 16:59:40 -0000 Hi Sebastian, > -----Original Message----- > From: Sebastian Schildt [mailto:schildt@ibr.cs.tu-bs.de] > Sent: Thursday, June 12, 2014 8:08 AM > To: Templin, Fred L > Cc: Martin Stiemerling; Elwyn Davies; dtn@ietf.org > Subject: Re: [dtn] DTN BoF Proposal for IETF90 >=20 > Hi, >=20 > two small remarks >=20 > Am 12.06.2014 um 16:54 schrieb Templin, Fred L : > > > > - There is never any expectation of contemporaneous end-to-end > > connectivity between any two network nodes. > > > > - Because end-to-end connectivity can never be assumed, each node > > on the path between source and destination must be prepared to > > handle incoming "bundles" of data that cannot immediately be > > forwarded. > > > > - Again because end-to-end connectivity can never be assumed, > > end-to-end conversational data exchange can never be assumed to > > complete in a timely manner; protocol features that rely on > > timely conversational data exchange must be excluded from the > > architecture. > > >=20 > The third point seems redundant. I'm not sure I see a problem with leaving the bullet as is, because the previous bullet talks about hop-by-hop considerations while the bullet in question talks about end-to-end. Is there a problem with leaving what we already have? > Also during contact between two nodes (not end-to-end) you might have > for example some handshaking that "rely on timely conversational data > exchange". Maybe you rather want > to say something about whether and how unidirectional links are supported= . How would the envisioned convergence layers deal with unidirectional links? I.e., if we can't get some acknowledgment of reception then there is no way to ensure reliable delivery. Or, am I missing your point? > > Work items related to Delay/Disruption Tolerant Networking include= : > > > > > > o A delay-tolerant security key management scheme for ensuring tha= t > > public keys are certified by a globally trusted authority to protect > > the integrity of the infrastructure. > Seems a pretty bad idea for most applications. Not only, but especially i= n a DTN. I think while key > management is definitely a very(!) important point, the charter should no= t already fix a "solution" > (that some might argue is none). What about a more neutral >=20 > > Delay-tolerant security key management schemes that can protect the int= egrity of a DTN network I'm OK with making a more neutral statement, but we should have an idea from the onset as to whether we want to standardize one solution to the problem or multiple solutions. For example, do we anticipate different solutions for different use cases, or a one-size-fits-all. Thoughts? Thanks - Fred fred.l.templin@boeing.com > MfG >=20 > Sebastian From nobody Thu Jun 12 10:48:12 2014 Return-Path: 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 A42EE1A01B7 for ; Thu, 12 Jun 2014 10:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 giZJ7ApO0lUm for ; Thu, 12 Jun 2014 10:48:03 -0700 (PDT) Received: from mail.ibr.cs.tu-bs.de (mail.ibr.cs.tu-bs.de [134.169.34.52]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F7FD1A01CE for ; Thu, 12 Jun 2014 10:48:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.ibr.cs.tu-bs.de (Postfix) with ESMTP id 2D550182F0B; Thu, 12 Jun 2014 19:48:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ibr.cs.tu-bs.de; h=x-mailer:references:message-id:content-transfer-encoding:date :date:in-reply-to:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=key1; t= 1402595279; x=1404409680; bh=0Y0TTwaZ0HX8A181w9Fvw5aYB7fLAH3MAdn vcsHmcwg=; b=oIDvs/NvjRX+KownU9yN6thfBHDFoXmv/QD9QRhT3nsVW9K93Dh +sS+domErOloDV5fTL5/Yavk9KmV9V0uUb4iyJox6ffva1jREEZBIXuiCbS8hdfZ nLAC6/1egVfmi+KWGyvoQaMStNk71bMrPy2Px3w8uEdCuUMIVqIvi4Q0= X-Virus-Scanned: Debian amavisd-new at ibr.cs.tu-bs.de Received: from mail.ibr.cs.tu-bs.de ([127.0.0.1]) by localhost (mail.ibr.cs.tu-bs.de [127.0.0.1]) (amavisd-new, port 10026) with LMTP id mWqAtQICuPyK; Thu, 12 Jun 2014 19:47:59 +0200 (CEST) Received: from defiant.fritz.box (brsg-4dbbdd35.pool.mediaWays.net [77.187.221.53]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schildt@ibr.cs.tu-bs.de) by mail.ibr.cs.tu-bs.de (Postfix) with ESMTPSA id 8ECA3182DE2; Thu, 12 Jun 2014 19:47:58 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Sebastian Schildt In-Reply-To: <2134F8430051B64F815C691A62D983183048B009@XCH-BLV-512.nw.nos.boeing.com> Date: Thu, 12 Jun 2014 19:47:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4B061CF6-73AC-449A-BDE9-FA9A774F2FDB@ibr.cs.tu-bs.de> References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> , <1401967219583.26821@surrey.ac.uk> , <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk> , <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> <1402389636710.92429@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830486EBE@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> <1402490970.2995.76.camel@mightyatom> <2134F8430051B64F815C691A62D983183048A030@XCH-BLV-512.nw.nos.boeing.com> <1402513416.2995.198.camel@mightyatom> <5399BC2E.10707@gmail.com> <2134F8430051B64F815C691A62D983183048ACFE@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983183048B009@XCH-BLV-512.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/bIL3mjudsnN62Ai5EKjelrXXSR8 Cc: Martin Stiemerling , Elwyn Davies , "dtn@ietf.org" Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 17:48:11 -0000 Hi Fred,=20 On 12 Jun 2014, at 18:59, Templin, Fred L = wrote: >>>=20 >>> - Again because end-to-end connectivity can never be assumed, >>> end-to-end conversational data exchange can never be assumed = to >>> complete in a timely manner; protocol features that rely on >>> timely conversational data exchange must be excluded from the >>> architecture. >>>=20 >>=20 >> The third point seems redundant. >=20 > I'm not sure I see a problem with leaving the bullet as is, because = the > previous bullet talks about hop-by-hop considerations while the bullet > in question talks about end-to-end. Is there a problem with leaving = what > we already have? I guess I was typing the mail while thinking. So when reading this, I = thought about what you meant by "timely conversational data exchange", = because of course for communication between arbitrary endpoints = (end-to-end) we can not do it. That is the essence of DTN, so I was = puzzled, why it was explicitly mentioned here. Then I thought about = "contacts", i.e. two nodes connected directly via a CL exchanging BP = data. In that case - at least in all usecases I have experienced - = those two nodes could do a lot of request-reply stuff for = handshaking/synchronizing storages, talk about routing etc. So it did = not seem good to me, if the paragraph could be understood to exclude = that mode of operation. >=20 >> Also during contact between two nodes (not end-to-end) you might have >> for example some handshaking that "rely on timely conversational data >> exchange". Maybe you rather want >> to say something about whether and how unidirectional links are = supported. >=20 > How would the envisioned convergence layers deal with unidirectional > links? I.e., if we can't get some acknowledgment of reception then > there is no way to ensure reliable delivery. Or, am I missing your > point? I kept thinking (woah.. seems I really did a lot of thinking today:) ) = about space applications, where maybe you already have a delay of = "minutes" upon a direct contact, and thus would want to avoid roundtrips = for BP housekeeping, which is why I came to think about the extreme case = of unidirectional node-to-node links. I do not need them at all. But do = the space guys need them?=20 With the current BP it is certainly possible: Blast a valid bundle over = some link, using a convergence layer that has no additonal hadnshake = built in, and it should work. So I just think it is an interesting = question, whether future BP should be able to work over unidirectional = links. A mandatory handshake on the BP level would prevent this. So in a nuthsell: I have nothing against the paragraph as it is, but I = felt it just restates the obvious, and then weird thoughts came flying = through my mind :) >=20 >>> Work items related to Delay/Disruption Tolerant Networking = include: >>>=20 >>>=20 >>> o A delay-tolerant security key management scheme for ensuring = that >>> public keys are certified by a globally trusted authority to = protect >>> the integrity of the infrastructure. >> Seems a pretty bad idea for most applications. Not only, but = especially in a DTN. I think while key >> management is definitely a very(!) important point, the charter = should not already fix a "solution" >> (that some might argue is none). What about a more neutral >>=20 >>> Delay-tolerant security key management schemes that can protect the = integrity of a DTN network >=20 > I'm OK with making a more neutral statement, but we should have an = idea > from the onset as to whether we want to standardize one solution to = the > problem or multiple solutions. For example, do we anticipate different > solutions for different use cases, or a one-size-fits-all. I am not clear myself, how much of this should be specified. Definitely = we would need the notion of keys and how to flag bundles as signed or = encrypted with such-and-such algorithm and key. I think this is what the = current BSP does, and what a streamlined version provides. I would also = argue, that some generic protocol to exchange keys is probably useful. = Apart from that, things really differ, depending on whether you just = want to use a vanilla public/private key system, whether you want to = built certificates on top, or whether you intend to use some ID-based = cryptography.=20 As people might need different solutions, just saying for example "Ok we = use X509 and are done with it=93, might not be a good idea. I really = think an important question for the WG later is, "how much" do we = specify. An example I am a little more familiar with: IEEE 802.15.4. The = specification basically just says, =84Ok you can use AES, the key is = this long, switch on this flag to show it is AES." And that is that. = Where do the keys come from? Your problem! Now there IS also Zigbee, an = industry supported standard which provides higher layers on top of = 802.15.4. ZigBee says more about key exchange and related stuff. But = then again: Nobody uses ZigBee! Most people/companies who call their = stuff ZigBee basically just use the 802.15.4 base spec and do their own = stuff on top. Go figure. So the art is to specify enough, that it will = not be useless, but not too much so that it is overly complex or does = not fit any application. Therefore I think, for the initial charta, the = point should really be quite open and neutral. Hope this makes things clearer :) MfG Sebastian From nobody Thu Jun 12 11:26:08 2014 Return-Path: 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 467211B27BB for ; Thu, 12 Jun 2014 11:26:06 -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 60Hgx2ncH6oT for ; Thu, 12 Jun 2014 11:26:03 -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 48E471A0213 for ; Thu, 12 Jun 2014 11:26:03 -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 s5CIQ22J010410; Thu, 12 Jun 2014 13:26:02 -0500 Received: from XCH-PHX-402.sw.nos.boeing.com (xch-phx-402.sw.nos.boeing.com [137.136.239.38]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s5CIPrN1009724 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 12 Jun 2014 13:25:55 -0500 Received: from XCH-BLV-512.nw.nos.boeing.com ([169.254.12.74]) by XCH-PHX-402.sw.nos.boeing.com ([169.254.7.196]) with mapi id 14.03.0181.006; Thu, 12 Jun 2014 11:25:53 -0700 From: "Templin, Fred L" To: Sebastian Schildt Thread-Topic: [dtn] DTN BoF Proposal for IETF90 Thread-Index: Ac+AQa9Fez/CplZaSwyaLFpzb8tj0wAiVZ0A///Hp/D//5OnYIABipvO//qPd7CAC7TeXf//SGxA//6DxzD/+y/3AP/2pkiA/+vJSB7/15AZcP+uprQA/12mIbD+usa2AP11/GwA Date: Thu, 12 Jun 2014 18:25:52 +0000 Message-ID: <2134F8430051B64F815C691A62D983183048B25C@XCH-BLV-512.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> , <1401967219583.26821@surrey.ac.uk> , <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk> , <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> <1402389636710.92429@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830486EBE@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> <1402490970.2995.76.camel@mightyatom> <2134F8430051B64F815C691A62D983183048A030@XCH-BLV-512.nw.nos.boeing.com> <1402513416.2995.198.camel@mightyatom> <5399BC2E.10707@gmail.com> <2134F8430051B64F815C691A62D983183048ACFE@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983183048B009@XCH-BLV-512.nw.nos.boeing.com> <4B061CF6-73AC-449A-BDE9-FA9A774F2FDB@ibr.cs.tu-bs.de> In-Reply-To: <4B061CF6-73AC-449A-BDE9-FA9A774F2FDB@ibr.cs.tu-bs.de> 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/u_f1jykd13scpm3hUU9NuyrZAow Cc: Martin Stiemerling , Elwyn Davies , "dtn@ietf.org" Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 18:26:06 -0000 Hi Sebastian, > -----Original Message----- > From: Sebastian Schildt [mailto:schildt@ibr.cs.tu-bs.de] > Sent: Thursday, June 12, 2014 10:48 AM > To: Templin, Fred L > Cc: Martin Stiemerling; Elwyn Davies; dtn@ietf.org > Subject: Re: [dtn] DTN BoF Proposal for IETF90 >=20 > Hi Fred, >=20 > On 12 Jun 2014, at 18:59, Templin, Fred L wro= te: > >>> > >>> - Again because end-to-end connectivity can never be assumed, > >>> end-to-end conversational data exchange can never be assumed to > >>> complete in a timely manner; protocol features that rely on > >>> timely conversational data exchange must be excluded from the > >>> architecture. > >>> > >> > >> The third point seems redundant. > > > > I'm not sure I see a problem with leaving the bullet as is, because the > > previous bullet talks about hop-by-hop considerations while the bullet > > in question talks about end-to-end. Is there a problem with leaving wha= t > > we already have? >=20 > I guess I was typing the mail while thinking. So when reading this, I tho= ught about what you meant by > "timely conversational data exchange", because of course for communicatio= n between arbitrary endpoints > (end-to-end) we can not do it. That is the essence of DTN, so I was puzz= led, why it was explicitly > mentioned here. IMHO, it is worth mentioning here because BP is a transport over which end-to-end conversational data exchanges between endpoints will often not be possible. This is a paradigm-breaking concept to the transport area, and so seems worth mentioning to set the right context. > Then I thought about "contacts", i.e. two nodes connected directly via a = CL exchanging > BP data. In that case - at least in all usecases I have experienced - th= ose two nodes could do a lot > of request-reply stuff for handshaking/synchronizing storages, talk about= routing etc. So it did not > seem good to me, if the paragraph could be understood to exclude that mod= e of operation. That would be a hop-by-hop consideration, which is intended to be covered by the previous bullet: =3D=3D> - Because end-to-end connectivity can never be assumed, each node =3D=3D> on the path between source and destination must be prepared to =3D=3D> handle incoming "bundles" of data that cannot immediately be =3D=3D> forwarded. Do you suggest any changes to this bullet? =20 > >> Also during contact between two nodes (not end-to-end) you might have > >> for example some handshaking that "rely on timely conversational data > >> exchange". Maybe you rather want > >> to say something about whether and how unidirectional links are suppor= ted. > > > > How would the envisioned convergence layers deal with unidirectional > > links? I.e., if we can't get some acknowledgment of reception then > > there is no way to ensure reliable delivery. Or, am I missing your > > point? >=20 >=20 > I kept thinking (woah.. seems I really did a lot of thinking today:) ) ab= out space applications, where > maybe you already have a delay of "minutes" upon a direct contact, and th= us would want to avoid > roundtrips for BP housekeeping, which is why I came to think about the ex= treme case of unidirectional > node-to-node links. I do not need them at all. But do the space guys need= them? > With the current BP it is certainly possible: Blast a valid bundle over s= ome link, using a convergence > layer that has no additonal hadnshake built in, and it should work. So I = just think it is an > interesting question, whether future BP should be able to work over unidi= rectional links. A mandatory > handshake on the BP level would prevent this. What does anyone else think about unidirectional link? Any text change suggestions? > So in a nuthsell: I have nothing against the paragraph as it is, but I f= elt it just restates the > obvious, and then weird thoughts came flying through my mind :) Since this is intended for the IETF transport area where discussing DTN is essentially breaking new ground, I think it is useful to include the bullets for the benefit of new readers who may have no former experience with DTN and hence insufficient context for understanding the charter. Is it OK for you? > >>> Work items related to Delay/Disruption Tolerant Networking includ= e: > >>> > >>> > >>> o A delay-tolerant security key management scheme for ensuring th= at > >>> public keys are certified by a globally trusted authority to protect > >>> the integrity of the infrastructure. > >> Seems a pretty bad idea for most applications. Not only, but especiall= y in a DTN. I think while > key > >> management is definitely a very(!) important point, the charter should= not already fix a "solution" > >> (that some might argue is none). What about a more neutral > >> > >>> Delay-tolerant security key management schemes that can protect the i= ntegrity of a DTN network > > > > I'm OK with making a more neutral statement, but we should have an idea > > from the onset as to whether we want to standardize one solution to the > > problem or multiple solutions. For example, do we anticipate different > > solutions for different use cases, or a one-size-fits-all. >=20 >=20 > I am not clear myself, how much of this should be specified. Definitely w= e would need the notion of > keys and how to flag bundles as signed or encrypted with such-and-such al= gorithm and key. I think this > is what the current BSP does, and what a streamlined version provides. I = would also argue, that some > generic protocol to exchange keys is probably useful. Apart from that, th= ings really differ, depending > on whether you just want to use a vanilla public/private key system, whet= her you want to built > certificates on top, or whether you intend to use some ID-based cryptogra= phy. >=20 > As people might need different solutions, just saying for example "Ok we = use X509 and are done with > it", might not be a good idea. I really think an important question for t= he WG later is, "how much" do > we specify. An example I am a little more familiar with: IEEE 802.15.4. T= he specification basically > just says, "Ok you can use AES, the key is this long, switch on this flag= to show it is AES." And that > is that. Where do the keys come from? Your problem! Now there IS also Zig= bee, an industry supported > standard which provides higher layers on top of 802.15.4. ZigBee says mor= e about key exchange and > related stuff. But then again: Nobody uses ZigBee! Most people/companies = who call their stuff ZigBee > basically just use the 802.15.4 base spec and do their own stuff on top. = Go figure. So the art is to > specify enough, that it will not be useless, but not too much so that it = is overly complex or does not > fit any application. Therefore I think, for the initial charta, the point= should really be quite open > and neutral. I don't mind taking a slightly revised version of your proposed bullet: o A delay-tolerant security key management scheme that can protect the integrity of a DTN network. Would that be OK? Thanks - Fred fred.l.templin@boeing.com =20 > Hope this makes things clearer :) >=20 > MfG >=20 > Sebastian From nobody Thu Jun 12 11:35:03 2014 Return-Path: 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 264B31B2AE9 for ; Thu, 12 Jun 2014 11:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.841 X-Spam-Level: X-Spam-Status: No, score=-4.841 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] 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 1MmqdRwrQYN0 for ; Thu, 12 Jun 2014 11:34:56 -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 0A00F1B2AE8 for ; Thu, 12 Jun 2014 11:34:55 -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 s5CIYt7I001278; Thu, 12 Jun 2014 13:34:55 -0500 Received: from XCH-PHX-504.sw.nos.boeing.com (xch-phx-504.sw.nos.boeing.com [137.136.239.59]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s5CIY8jv031914 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Thu, 12 Jun 2014 13:34:45 -0500 Received: from XCH-BLV-113.nw.nos.boeing.com (137.136.239.107) by XCH-PHX-504.sw.nos.boeing.com (137.136.239.59) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 12 Jun 2014 11:34:23 -0700 Received: from XCH-BLV-512.nw.nos.boeing.com ([169.254.12.74]) by XCH-BLV-113.nw.nos.boeing.com ([169.254.12.220]) with mapi id 14.03.0181.006; Thu, 12 Jun 2014 11:34:23 -0700 From: "Templin, Fred L" To: "dtn@ietf.org" Thread-Topic: Draft Charter Discussion Thread-Index: Ac+GbO3wN7xIp4CqSFeVEjvJc65+vA== Date: Thu, 12 Jun 2014 18:34:23 +0000 Message-ID: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [137.136.248.6] Content-Type: multipart/mixed; boundary="_002_2134F8430051B64F815C691A62D983183048B287XCHBLV512nwnosb_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/qXdWsJoV4GLdJWnMjOLU-xXNTKI Subject: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 18:35:00 -0000 --_002_2134F8430051B64F815C691A62D983183048B287XCHBLV512nwnosb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, There were some additional off-list updates to the charter emerging as Martin was calling for charter discussion. Please see below for the revised version (diffs attached) and use this as basis for further discussion. (Sebastian and others - please post any follow-ups to this thread.) Fred --- Draft working group charter: **************************** Working group name:=20 Delay/Disruption Tolerant Networking Working Group (DTNWG) Chair(s): TBD Area and Area Director(s): Transport Area: ADs Spencer Dawkins , Martin Stiemerling Responsible Area Director: TBD Mailing list: General Discussion: dtn at ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dtn Archive: http://www.ietf.org/mail-archive/web/dtn/current/maillist.ht= ml Description of Working Group: The Delay/Disruption Tolerant Network Working Group (DTNWG) specifies mechanisms for data communications in the presence of long delays and/or intermittent connectivity. The work is motivated by well known limitations of standard Internet protocols that expect end-to-end connectivity between communicating endpoints, sub-second transmission delays and robust packet delivery ratios. In environments where these favorable conditions do not apply, existing mechanisms encounter prob= lems=20 such as reliable transport protocol handshakes timing out and routing= =20 protocols failing to converge resulting in communication failures.=20 Furthermore, classical end-to-end security associations cannot be=20 coordinated when communicating endpoints cannot conduct multi-message= =20 keying exchanges in a timely fashion. These limitations suggested the= =20 need for a new approach.=20 =20 Delay-Tolerant Networking (DTN) protocols have been the subject of extensive research and development in the Delay-Tolerant Networking Research Group (DTNRG) of the Internet Research Task Force since 2002= . The DTNRG has developed the Delay-Tolerant Networking Architecture=20 (RFC 4838) that the DTNWG uses as the basis for its work. The key=20 components of the this architecture are the bundle concept for=20 encapsulating data units, the bundle transmission protocol and the=20 underlying convergence layer architecture. =20 The experimental DTN Bundle Protocol (RFC 5050) and Licklider Transmission Protocol (RFC 5326) have been shown to address the issues identified above in substantial fielded deployments in the spa= ce=20 sector [1]. RFC 5050 in conjunction with TCP- and UDP-based converge= nce=20 layers has been used successfully in a number of experiments both in= =20 communications challenged environments around the edges of the Intern= et=20 and as an Internet overlay where applications require delay- and/or=20 disruption-tolerance [refs needed]. =20 The success of the BP over convergence layer protocol stack -- the co= re=20 protocols of the "DTN Architecture" described in RFC 4838 -- may be=20 attributed to the following fundamental design principles: - There is never any expectation of contemporaneous end-to-end connectivity between any two network nodes. - Because end-to-end connectivity can never be assumed, each node on the path between source and destination must be prepared to handle incoming "bundles" of data that cannot immediately be forwarded. - Again because end-to-end connectivity can never be assumed, end-to-end conversational data exchange can never be assumed to complete in a timely manner; protocol features that rely on timely conversational data exchange must be excluded from the architecture. The DTNWG believes that protocols adhering to these principles offer opportunities for enhancing the functionality of the Internet, includ= ing=20 - facilitating the extension of the Internet into environments such= as=20 the ocean floor and deep space in which the core Internet protoco= ls=20 operate sub-optimally for the reasons discussed earlier; - extending the Internet into communications challenged terrestrial= =20 environments where it is not possible to provide continuous, low= =20 delay Internet connections; and=20 - supporting Internet applications that need DTN capabiliies. We believe that the extensive research, demonstration, and pilot operations performed to date using the DTNRG protocols provides a firm basis for publishing Internet standards derived from that work= . Work items related to Delay/Disruption Tolerant Networking include: o A mechanism for the exchange of protocol data units, termed "bundles", that are designed to obviate conversational communications by containing values for all potentially relevant configuration parameters. These protocol data units are typically larger than network-layer packets. We will derive this bundle exchange mechanism from the DTN Bundle Protocol (BP) documented in RFC 5050 by publish= ing a new document for which [2] is a proposed first draft (where appendix A provides a summary of the proposed changes). o A security protocol for ensuring that the network in which bundles are exchanged is secured against unauthorized access and denial of service attacks, and to ensure data integrity and confidentiality in that network where necessary. We will derive this security protocol from a "streamlined" adaptation of the DTN Bundle Security Protocol documented in RFC 6257. o A delay-tolerant security key management scheme for ensuring that public keys are certified by a globally trusted authority to protect the integrity of the infrastructure. o A simple datagram convergence layer protocol for adaptation of the bundle protocol to underlying internetworks. We expect to derive this convergence layer protocol from the Datagram Convergence protocol documented in RFC 7122. o A delay-tolerant network management protocol for management of the infrastructure in the presence of long delays and/or intermittent connectivity. o A functional specification of Contact Graph Routing (CGR) specifyin= g=20 the inputs (global contact schedules, traffic demands, etc.) and=20 outputs (node specific transmission and reception schedules,=20 notifications, etc.). CGR is a centralized, oracle-based bundle=20 transmission and reception scheduling scheme used in space segment= =20 DTN deployments. o An adjunct to the management protocol that will allow the contact=20 schedules generated by CGR to be distributed to nodes. This may be= =20 based on the Contact Plan Update Protocol (CPUP) proposed in =20 o An encapsulation protocol for "tunneling" BP traffic within bundles that are secured and/or routed in different way from the encapsulated bundles. o A registry for DTN Service Identifiers =20 The working group will consider extending the current milestones based = on new information and knowledge gained while working on the initial chart= er, as well as to accommodate new work items beyond the scope of the initia= l phase. For example, we expect that transport protocols such as LTP and the Saratoga protocol are among the candidates for work in this phase. =20 Goals and Milestones: start+3mos - Submit 'Bundle Protocol Specification (RFC5050bis)' as a working group document [2]. To be Proposed Standard. Start+3mos - Submit 'Streamlined Bundle Security Protocol (SBSP)' as a working group document [3]. To be Proposed Standard. start+6mos - Submit 'Bundle In Bundle Encapsulation (BIBE)' as a working group document [4]. To be Proposed Standard. start+12mos - Submit 'CGR Functional Specification' as a working group=20 document. To be an informational document. start+12mos - Submit 'Delay Tolerant Networking Security Key Management' = as a working group document. To be Proposed Standard. start+15mos - Submit 'Contact Plan Update Protocol' as working group=20 document. To be Proposed Standaqqrd. start+18mos - WG determination for merging RFC5050bis, SBSP, BIBE and/or Key Mgmt into a combined draft or keep as separate drafts. start+18mos - Submit RFC5050bis, SBSP, BIBE and Key Mgmt to the IESG eith= er as a combined draft or as separate drafts. start+18mos - Submit Network Management [5], Registry [6] and Simple Convergence Layer [7] as working group documents. start+20mos - Survey appropriate forums (e.g., DTNRG) for emerging technologies (e.g., convergence layer protocols, dynamic routing protocols, naming and addressing services, etc.) ready for transition into IETF DTN Working Group. Publish draft on survey results as independent submission related to the WG. start+24mos - Submit Network Management, Registry and Simple Convergence Layer to IESG start+24mos - Recharter to accommodate new work items or close Working Gr= oup [1] "BP/LTP deployment on EPOXI spacecraft" [2008], http://committees.comsoc.org/tccc/ccw/2010/slides/DINET_CCW.pdf =20 [2] "Proposed Revised Bundle Protocol" [2014], https://datatracker.ietf.org/doc/draft-burleigh-bpv7/ [3] "Streamlined Bundle Security Protocol Specification" [2014], https://datatracker.ietf.org/doc/draft-irtf-dtnrg-sbsp/ [4] "Bundle-in-Bundle Encapsulation" [2013], http://tools.ietf.org/id/draft-irtf-burleigh-bibe [5] "Delay Tolerant Network Management Protocol" [2013], http://tools.ietf.org/id/draft-irtf-dtnrg-dtnmp [6] "Delay-Tolerant Networking Bundle Protocol IANA Registries" [2011], https://datatracker.ietf.org/doc/rfc6255/ [7] "Datagram Convergence Layers ..." [2014], https://datatracker.ietf.org/doc/rfc7122/ [8] "Towards Flexibility and Accuracy in Space DTN Communications", Bezirgianndia et al, CHANTS 2012, http://dl.acm.org/citation.cfm?id=3D2505499 [2012] --_002_2134F8430051B64F815C691A62D983183048B287XCHBLV512nwnosb_ Content-Type: text/html; name="wdiff 04a_txt 04b_txt.htm" Content-Description: wdiff 04a_txt 04b_txt.htm Content-Disposition: attachment; filename="wdiff 04a_txt 04b_txt.htm"; size=32918; creation-date="Thu, 12 Jun 2014 18:33:46 GMT"; modification-date="Thu, 12 Jun 2014 18:33:46 GMT" Content-Transfer-Encoding: base64 CjxodG1sPjxoZWFkPjx0aXRsZT53ZGlmZiAwNGEudHh0IDA0Yi50eHQ8L3RpdGxlPjwvaGVhZD48 Ym9keT4KPHByZT4KRHJhZnQgQm9GIEFnZW5kYSAoMi41aHJzKToKKioqKioqKioqKioqKioqKioq KioqKioqKioKMSkgUHJvYmxlbSBzdGF0ZW1lbnQgKElFVEYgd2cgbW90aXZhdGlvbikgLSAzMG1p bgoKMikgUkZDNTA1MChiaXMpIC0gMTVtaW4KCjMpIFN0cmVhbWxpbmVkIEJ1bmRsZSBTZWN1cml0 eSBQcm90b2NvbCAoU0JTUCkgLSAxNW1pbgoKNCkgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJyA+ QnVuZGxlLWluLUJ1bmRsZSBFbmNhcHN1bGF0aW9uPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxm b250IGNvbG9yPSdncmVlbicgPlNlY3VyaXR5IEtleSBNYW5hZ2VtZW50PC9mb250Pjwvc3Ryb25n PiAtIDEwbWluCgo1KSA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnID5TZWN1cml0eSBLZXk8L2Zv bnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJyA+TmV0d29yazwvZm9udD48 L3N0cm9uZz4gTWFuYWdlbWVudCAtIDEwbWluCgo2KSA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQn ID5SZWdpc3RyeSBmb3IgU2VydmljZSBJZGVudGlmaWVyczwvZm9udD48L3N0cmlrZT4gPHN0cm9u Zz48Zm9udCBjb2xvcj0nZ3JlZW4nID5Db250YWN0IEdyYXBoIFJvdXRpbmcgYW5kIENvbnRhY3Qg UGxhbiBVcGRhdGUgUHJvdG9jb2w8L2ZvbnQ+PC9zdHJvbmc+IC0gMTBtaW4KCjcpIDxzdHJpa2U+ PGZvbnQgY29sb3I9J3JlZCcgPk5ldHdvcmsgTWFuYWdlbWVudDwvZm9udD48L3N0cmlrZT4gPHN0 cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nID5CdW5kbGUtaW4tQnVuZGxlIEVuY2Fwc3VsYXRpb248 L2ZvbnQ+PC9zdHJvbmc+IC0gPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJyA+MTBtaW48L2ZvbnQ+ PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJyA+NW1pbjwvZm9udD48L3N0cm9u Zz4KCjgpIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJyA+UmVnaXN0cnkgZm9yIFNlcnZpY2Ug SWRlbnRpZmllcnMgLSA1bWluCgo5KTwvZm9udD48L3N0cm9uZz4gT3BlbiBEaXNjdXNzaW9uIC0g NTBtaW4KCjxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCcgPlByb3Bvc2VkPC9mb250Pjwvc3RyaWtl PgoKPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nID5EcmFmdDwvZm9udD48L3N0cm9uZz4gd29y a2luZyBncm91cCBjaGFydGVyOgo8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnID4qKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqPC9mb250Pjwvc3RyaWtlPgo8c3Ryb25nPjxmb250IGNvbG9y PSdncmVlbicgPioqKioqKioqKioqKioqKioqKioqKioqKioqKio8L2ZvbnQ+PC9zdHJvbmc+Cldv cmtpbmcgZ3JvdXAgbmFtZToKCiAgICAgIERlbGF5L0Rpc3J1cHRpb24gVG9sZXJhbnQgTmV0d29y a2luZyBXb3JraW5nIEdyb3VwIChEVE5XRykKCkNoYWlyKHMpOgoKICAgICAgVEJECgpBcmVhIGFu ZCBBcmVhIERpcmVjdG9yKHMpOgoKICAgICAgVHJhbnNwb3J0IEFyZWE6IEFEcyBTcGVuY2VyIERh d2tpbnMgJmx0O3NwZW5jZXJkYXdraW5zLmlldGYgYXQgZ21haWwuY29tJmd0OywKICAgICAgICAg ICAgICAgICAgICAgICAgICBNYXJ0aW4gU3RpZW1lcmxpbmcgJmx0O21scy5pZXRmIGF0IGdtYWls LmNvbSZndDsKClJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3I6CgogICAgICBUQkQKCk1haWxpbmcg bGlzdDoKCiAgICAgIEdlbmVyYWwgRGlzY3Vzc2lvbjogZHRuIGF0IGlldGYub3JnCiAgICAgIFRv IFN1YnNjcmliZTogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kdG4KICAg ICAgQXJjaGl2ZTogaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2R0bi9jdXJy ZW50L21haWxsaXN0Lmh0bWwKCkRlc2NyaXB0aW9uIG9mIFdvcmtpbmcgR3JvdXA6CgogICAgICBU aGUgRGVsYXkvRGlzcnVwdGlvbiBUb2xlcmFudCBOZXR3b3JrIFdvcmtpbmcgR3JvdXAgKERUTldH KSBzcGVjaWZpZXMKICAgICAgbWVjaGFuaXNtcyBmb3IgZGF0YSBjb21tdW5pY2F0aW9ucyBpbiB0 aGUgcHJlc2VuY2Ugb2YgbG9uZyBkZWxheXMKICAgICAgYW5kL29yIGludGVybWl0dGVudCBjb25u ZWN0aXZpdHkuIFRoZSB3b3JrIGlzIG1vdGl2YXRlZCBieSB3ZWxsIGtub3duCiAgICAgIGxpbWl0 YXRpb25zIG9mIHN0YW5kYXJkIEludGVybmV0IHByb3RvY29scyB0aGF0IGV4cGVjdCBlbmQtdG8t ZW5kCiAgICAgIGNvbm5lY3Rpdml0eSBiZXR3ZWVuIGNvbW11bmljYXRpbmcgZW5kcG9pbnRzLCBz dWItc2Vjb25kIHRyYW5zbWlzc2lvbgogICAgICBkZWxheXMgYW5kIHJvYnVzdCBwYWNrZXQgZGVs aXZlcnkgcmF0aW9zLiBJbiBlbnZpcm9ubWVudHMgd2hlcmUgdGhlc2UKICAgICAgZmF2b3JhYmxl IGNvbmRpdGlvbnMgZG8gbm90IGFwcGx5LCBleGlzdGluZyBtZWNoYW5pc21zIDxzdHJvbmc+PGZv bnQgY29sb3I9J2dyZWVuJyA+ZW5jb3VudGVyIHByb2JsZW1zPC9mb250Pjwvc3Ryb25nPgogICAg ICBzdWNoIGFzIHJlbGlhYmxlIHRyYW5zcG9ydCA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnID5w cm90b2NvbHM8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJyA+cHJv dG9jb2wgaGFuZHNoYWtlcyB0aW1pbmcgb3V0PC9mb250Pjwvc3Ryb25nPiBhbmQgcm91dGluZwog ICAgICBwcm90b2NvbHMgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJyA+Y2FuIGZhaWw8L2ZvbnQ+ PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJyA+ZmFpbGluZzwvZm9udD48L3N0 cm9uZz4gdG8gY29udmVyZ2UgcmVzdWx0aW5nIGluIGNvbW11bmljYXRpb24gZmFpbHVyZXMuCiAg ICAgIEZ1cnRoZXJtb3JlLCBjbGFzc2ljYWwgZW5kLXRvLWVuZCBzZWN1cml0eSBhc3NvY2lhdGlv bnMgY2Fubm90IGJlCiAgICAgIGNvb3JkaW5hdGVkIHdoZW4gY29tbXVuaWNhdGluZyBlbmRwb2lu dHMgY2Fubm90IGNvbmR1Y3QgbXVsdGktbWVzc2FnZQogICAgICBrZXlpbmcgZXhjaGFuZ2VzIGlu IGEgdGltZWx5IGZhc2hpb24uIFRoZXNlIGxpbWl0YXRpb25zIDxzdHJpa2U+PGZvbnQgY29sb3I9 J3JlZCcgPnN1Z2dlc3Q8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVu JyA+c3VnZ2VzdGVkPC9mb250Pjwvc3Ryb25nPiB0aGUKICAgICAgbmVlZCBmb3IgYSBuZXcgYXBw cm9hY2guCgogICAgICBEZWxheS1Ub2xlcmFudCBOZXR3b3JraW5nIChEVE4pIHByb3RvY29scyBo YXZlIGJlZW4gdGhlIHN1YmplY3Qgb2YKICAgICAgZXh0ZW5zaXZlIHJlc2VhcmNoIGFuZCBkZXZl bG9wbWVudCBpbiB0aGUgRGVsYXktVG9sZXJhbnQgTmV0d29ya2luZwogICAgICBSZXNlYXJjaCBH cm91cCA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicgPihEVE5SRyk8L2ZvbnQ+PC9zdHJvbmc+ IG9mIHRoZSBJbnRlcm5ldCBSZXNlYXJjaCBUYXNrIEZvcmNlIHNpbmNlIDIwMDIuICA8c3RyaWtl Pjxmb250IGNvbG9yPSdyZWQnID5JbgogICAgICBwYXJ0aWN1bGFyLDwvZm9udD48L3N0cmlrZT4K ICAgICAgPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nID5UaGUgRFROUkcgaGFzIGRldmVsb3Bl ZCB0aGUgRGVsYXktVG9sZXJhbnQgTmV0d29ya2luZyBBcmNoaXRlY3R1cmUKICAgICAgKFJGQyA0 ODM4KSB0aGF0IHRoZSBEVE5XRyB1c2VzIGFzPC9mb250Pjwvc3Ryb25nPiB0aGUgPHN0cm9uZz48 Zm9udCBjb2xvcj0nZ3JlZW4nID5iYXNpcyBmb3IgaXRzIHdvcmsuICBUaGUga2V5CiAgICAgIGNv bXBvbmVudHMgb2YgdGhlIHRoaXMgYXJjaGl0ZWN0dXJlIGFyZSB0aGUgYnVuZGxlIGNvbmNlcHQg Zm9yCiAgICAgIGVuY2Fwc3VsYXRpbmcgZGF0YSB1bml0cywgdGhlIGJ1bmRsZSB0cmFuc21pc3Np b24gcHJvdG9jb2wgYW5kIHRoZQogICAgICB1bmRlcmx5aW5nIGNvbnZlcmdlbmNlIGxheWVyIGFy Y2hpdGVjdHVyZS4KCiAgICAgIFRoZSBleHBlcmltZW50YWw8L2ZvbnQ+PC9zdHJvbmc+IERUTiBC dW5kbGUgUHJvdG9jb2wgKFJGQyA1MDUwKSBhbmQgTGlja2xpZGVyCiAgICAgIFRyYW5zbWlzc2lv biBQcm90b2NvbCAoUkZDIDUzMjYpIGhhdmUgYmVlbiBzaG93biB0byBhZGRyZXNzIHRoZQogICAg ICBpc3N1ZXMgaWRlbnRpZmllZCBhYm92ZSBpbiBzdWJzdGFudGlhbCBmaWVsZGVkIGRlcGxveW1l bnRzIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJyA+aW4gdGhlIHNwYWNlCiAgICAgIHNlY3Rv cjwvZm9udD48L3N0cm9uZz4gWzFdLiAgPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nID5SRkMg NTA1MCBpbiBjb25qdW5jdGlvbiB3aXRoIFRDUC0gYW5kIFVEUC1iYXNlZCBjb252ZXJnZW5jZQog ICAgICBsYXllcnMgaGFzIGJlZW4gdXNlZCBzdWNjZXNzZnVsbHkgaW4gYSBudW1iZXIgb2YgZXhw ZXJpbWVudHMgYm90aCBpbgogICAgICBjb21tdW5pY2F0aW9ucyBjaGFsbGVuZ2VkIGVudmlyb25t ZW50cyBhcm91bmQgdGhlIGVkZ2VzIG9mIHRoZSBJbnRlcm5ldAogICAgICBhbmQgYXMgYW4gSW50 ZXJuZXQgb3ZlcmxheSB3aGVyZSBhcHBsaWNhdGlvbnMgcmVxdWlyZSBkZWxheS0gYW5kL29yCiAg ICAgIGRpc3J1cHRpb24tdG9sZXJhbmNlIFtyZWZzIG5lZWRlZF0uPC9mb250Pjwvc3Ryb25nPgoK ICAgICAgVGhlIHN1Y2Nlc3Mgb2YgdGhlIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCcgPkJQL0xU UDwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nID5CUCBvdmVyIGNv bnZlcmdlbmNlIGxheWVyPC9mb250Pjwvc3Ryb25nPiBwcm90b2NvbCBzdGFjayAtLSB0aGUgY29y ZQogICAgICBwcm90b2NvbHMgb2YgdGhlICJEVE4gQXJjaGl0ZWN0dXJlIiA8c3RyaWtlPjxmb250 IGNvbG9yPSdyZWQnID5vcmlnaW5hbGx5PC9mb250Pjwvc3RyaWtlPiBkZXNjcmliZWQgaW4gUkZD IDQ4MzggLS0gbWF5IGJlCiAgICAgIGF0dHJpYnV0ZWQgdG8gdGhlIGZvbGxvd2luZyBmdW5kYW1l bnRhbCBkZXNpZ24gcHJpbmNpcGxlczoKCgktIFRoZXJlIGlzIG5ldmVyIGFueSBleHBlY3RhdGlv biBvZiBjb250ZW1wb3JhbmVvdXMgZW5kLXRvLWVuZAogICAgICAgICAgY29ubmVjdGl2aXR5IGJl dHdlZW4gYW55IHR3byBuZXR3b3JrIG5vZGVzLgoKCS0gQmVjYXVzZSBlbmQtdG8tZW5kIGNvbm5l Y3Rpdml0eSBjYW4gbmV2ZXIgYmUgYXNzdW1lZCwgZWFjaCBub2RlCgkgIG9uIHRoZSBwYXRoIGJl dHdlZW4gc291cmNlIGFuZCBkZXN0aW5hdGlvbiBtdXN0IGJlIHByZXBhcmVkIHRvCgkgIGhhbmRs ZSBpbmNvbWluZyAiYnVuZGxlcyIgb2YgZGF0YSB0aGF0IGNhbm5vdCBpbW1lZGlhdGVseSBiZQoJ ICBmb3J3YXJkZWQuCgoJLSBBZ2FpbiBiZWNhdXNlIGVuZC10by1lbmQgY29ubmVjdGl2aXR5IGNh biBuZXZlciBiZSBhc3N1bWVkLAoJICBlbmQtdG8tZW5kIGNvbnZlcnNhdGlvbmFsIGRhdGEgZXhj aGFuZ2UgY2FuIG5ldmVyIGJlIGFzc3VtZWQgdG8KCSAgY29tcGxldGUgaW4gYSB0aW1lbHkgbWFu bmVyOyBwcm90b2NvbCBmZWF0dXJlcyB0aGF0IHJlbHkgb24KCSAgdGltZWx5IGNvbnZlcnNhdGlv bmFsIGRhdGEgZXhjaGFuZ2UgbXVzdCBiZSBleGNsdWRlZCBmcm9tIHRoZQoJICBhcmNoaXRlY3R1 cmUuCgogICAgICBUaGUgRFROV0cgYmVsaWV2ZXMgdGhhdCBwcm90b2NvbHMgYWRoZXJpbmcgdG8g dGhlc2UgcHJpbmNpcGxlcyBvZmZlcgogICAgICBvcHBvcnR1bml0aWVzIGZvciBlbmhhbmNpbmcg dGhlIGZ1bmN0aW9uYWxpdHkgb2YgdGhlIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCcgPkludGVy bmV0PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicgPkludGVybmV0 LCBpbmNsdWRpbmc8L2ZvbnQ+PC9zdHJvbmc+CgogICAgICAgIC0gPHN0cmlrZT48Zm9udCBjb2xv cj0ncmVkJyA+aW4KICAgICAgcGFydGljdWxhciwgZm9yPC9mb250Pjwvc3RyaWtlPiBmYWNpbGl0 YXRpbmcgdGhlIGV4dGVuc2lvbiBvZiB0aGUgSW50ZXJuZXQgaW50byBlbnZpcm9ubWVudHMgc3Vj aCBhcwogICAgICAgICAgdGhlIG9jZWFuIGZsb29yIGFuZCBkZWVwIHNwYWNlIGluIHdoaWNoIHRo ZSBjb3JlIEludGVybmV0IHByb3RvY29scwogICAgICAgICAgb3BlcmF0ZSBzdWItb3B0aW1hbGx5 IGZvciB0aGUgcmVhc29ucyBkaXNjdXNzZWQKICAgICAgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVk JyA+ZWFybGllci48L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJyA+ ZWFybGllcjsKCiAgICAgICAgLSBleHRlbmRpbmcgdGhlIEludGVybmV0IGludG8gY29tbXVuaWNh dGlvbnMgY2hhbGxlbmdlZCB0ZXJyZXN0cmlhbAogICAgICAgICAgZW52aXJvbm1lbnRzIHdoZXJl IGl0IGlzIG5vdCBwb3NzaWJsZSB0byBwcm92aWRlIGNvbnRpbnVvdXMsIGxvdwogICAgICAgICAg ZGVsYXkgSW50ZXJuZXQgY29ubmVjdGlvbnM7IGFuZAoKICAgICAgICAtIHN1cHBvcnRpbmcgSW50 ZXJuZXQgYXBwbGljYXRpb25zIHRoYXQgbmVlZCBEVE4gY2FwYWJpbGlpZXMuPC9mb250Pjwvc3Ry b25nPgoKICAgICAgV2UgYmVsaWV2ZSB0aGF0IHRoZSBleHRlbnNpdmUgcmVzZWFyY2gsIGRlbW9u c3RyYXRpb24sIGFuZAogICAgICBwaWxvdCBvcGVyYXRpb25zIHBlcmZvcm1lZCB0byBkYXRlIHVz aW5nIHRoZSBEVE5SRyBwcm90b2NvbHMgcHJvdmlkZXMKICAgICAgYSBmaXJtIGJhc2lzIGZvciBw dWJsaXNoaW5nIEludGVybmV0IHN0YW5kYXJkcyBkZXJpdmVkIGZyb20gdGhhdCB3b3JrLgoKICAg ICAgV29yayBpdGVtcyByZWxhdGVkIHRvIERlbGF5L0Rpc3J1cHRpb24gVG9sZXJhbnQgTmV0d29y a2luZyBpbmNsdWRlOgoKICAgICAgbyBBIG1lY2hhbmlzbSBmb3IgdGhlIGV4Y2hhbmdlIG9mIHBy b3RvY29sIGRhdGEgdW5pdHMsIHRlcm1lZAoJImJ1bmRsZXMiLCB0aGF0IGFyZSBkZXNpZ25lZCB0 byBvYnZpYXRlIGNvbnZlcnNhdGlvbmFsIGNvbW11bmljYXRpb25zCglieSBjb250YWluaW5nIHZh bHVlcyBmb3IgYWxsIHBvdGVudGlhbGx5IHJlbGV2YW50IGNvbmZpZ3VyYXRpb24KCXBhcmFtZXRl cnMuICBUaGVzZSBwcm90b2NvbCBkYXRhIHVuaXRzIGFyZSB0eXBpY2FsbHkgbGFyZ2VyIHRoYW4K CW5ldHdvcmstbGF5ZXIgcGFja2V0cy4gV2Ugd2lsbCBkZXJpdmUgdGhpcyBidW5kbGUgZXhjaGFu Z2UgbWVjaGFuaXNtCiAgICAgICAgZnJvbSB0aGUgRFROIEJ1bmRsZSBQcm90b2NvbCAoQlApIGRv Y3VtZW50ZWQgaW4gUkZDIDUwNTAgYnkgcHVibGlzaGluZwogICAgICAgIGEgbmV3IGRvY3VtZW50 IGZvciB3aGljaCBbMl0gaXMgYSBwcm9wb3NlZCBmaXJzdCBkcmFmdCAod2hlcmUKICAgICAgICBh cHBlbmRpeCBBIHByb3ZpZGVzIGEgc3VtbWFyeSBvZiB0aGUgcHJvcG9zZWQgY2hhbmdlcykuCgog ICAgICBvIEEgc2VjdXJpdHkgcHJvdG9jb2wgZm9yIGVuc3VyaW5nIHRoYXQgdGhlIG5ldHdvcmsg aW4gd2hpY2ggYnVuZGxlcwoJYXJlIGV4Y2hhbmdlZCBpcyBzZWN1cmVkIGFnYWluc3QgdW5hdXRo b3JpemVkIGFjY2VzcyBhbmQgZGVuaWFsIG9mCglzZXJ2aWNlIGF0dGFja3MsIGFuZCB0byBlbnN1 cmUgZGF0YSBpbnRlZ3JpdHkgYW5kIGNvbmZpZGVudGlhbGl0eQoJaW4gdGhhdCBuZXR3b3JrIHdo ZXJlIG5lY2Vzc2FyeS4gIFdlIHdpbGwgZGVyaXZlIHRoaXMgc2VjdXJpdHkKCXByb3RvY29sIGZy b20gYSAic3RyZWFtbGluZWQiIGFkYXB0YXRpb24gb2YgdGhlIERUTiBCdW5kbGUgU2VjdXJpdHkK CVByb3RvY29sIGRvY3VtZW50ZWQgaW4gUkZDIDYyNTcuCgogICAgICBvIDxzdHJpa2U+PGZvbnQg Y29sb3I9J3JlZCcgPkFuIGVuY2Fwc3VsYXRpb24gcHJvdG9jb2wgZm9yICJ0dW5uZWxpbmciIEJQ IHRyYWZmaWMgd2l0aGluIGJ1bmRsZXMKCXRoYXQgYXJlIHNlY3VyZWQgYW5kL29yIHJvdXRlZCBp biBkaWZmZXJlbnQgd2F5IGZyb20gdGhlIGVuY2Fwc3VsYXRlZAoJYnVuZGxlcy4KCiAgICAgIG88 L2ZvbnQ+PC9zdHJpa2U+IEEgZGVsYXktdG9sZXJhbnQgc2VjdXJpdHkga2V5IG1hbmFnZW1lbnQg c2NoZW1lIGZvciBlbnN1cmluZyB0aGF0CglwdWJsaWMga2V5cyBhcmUgY2VydGlmaWVkIGJ5IGEg Z2xvYmFsbHkgdHJ1c3RlZCBhdXRob3JpdHkgdG8gcHJvdGVjdAoJdGhlIGludGVncml0eSBvZiB0 aGUgaW5mcmFzdHJ1Y3R1cmUuCgogICAgICBvIEEgc2ltcGxlIGRhdGFncmFtIGNvbnZlcmdlbmNl IGxheWVyIHByb3RvY29sIGZvciBhZGFwdGF0aW9uIG9mIHRoZQogICAgICAgIGJ1bmRsZSBwcm90 b2NvbCB0byB1bmRlcmx5aW5nIGludGVybmV0d29ya3MuIFdlIGV4cGVjdCB0byBkZXJpdmUKICAg ICAgICB0aGlzIGNvbnZlcmdlbmNlIGxheWVyIHByb3RvY29sIGZyb20gdGhlIERhdGFncmFtIENv bnZlcmdlbmNlCiAgICAgICAgcHJvdG9jb2wgZG9jdW1lbnRlZCBpbiBSRkMgNzEyMi4KCiAgICAg IG8gQSBkZWxheS10b2xlcmFudCBuZXR3b3JrIG1hbmFnZW1lbnQgcHJvdG9jb2wgZm9yIG1hbmFn ZW1lbnQgb2YgdGhlCiAgICAgICAgaW5mcmFzdHJ1Y3R1cmUgaW4gdGhlIHByZXNlbmNlIG9mIGxv bmcgZGVsYXlzIGFuZC9vciBpbnRlcm1pdHRlbnQKICAgICAgICBjb25uZWN0aXZpdHkuCgogICAg ICBvIEEgPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nID5mdW5jdGlvbmFsIHNwZWNpZmljYXRp b24gb2YgQ29udGFjdCBHcmFwaCBSb3V0aW5nIChDR1IpIHNwZWNpZnlpbmcKICAgICAgICB0aGUg aW5wdXRzIChnbG9iYWwgY29udGFjdCBzY2hlZHVsZXMsIHRyYWZmaWMgZGVtYW5kcywgZXRjLikg YW5kCiAgICAgICAgb3V0cHV0cyAobm9kZSBzcGVjaWZpYyB0cmFuc21pc3Npb24gYW5kIHJlY2Vw dGlvbiBzY2hlZHVsZXMsCiAgICAgICAgbm90aWZpY2F0aW9ucywgZXRjLikuICBDR1IgaXMgYSBj ZW50cmFsaXplZCwgb3JhY2xlLWJhc2VkIGJ1bmRsZQogICAgICAgIHRyYW5zbWlzc2lvbiBhbmQg cmVjZXB0aW9uIHNjaGVkdWxpbmcgc2NoZW1lIHVzZWQgaW4gc3BhY2Ugc2VnbWVudAogICAgICAg IERUTiBkZXBsb3ltZW50cy4KCiAgICAgIG8gQW4gYWRqdW5jdCB0byB0aGUgbWFuYWdlbWVudCBw cm90b2NvbCB0aGF0IHdpbGwgYWxsb3cgdGhlIGNvbnRhY3QKICAgICAgICBzY2hlZHVsZXMgZ2Vu ZXJhdGVkIGJ5IENHUiB0byBiZSBkaXN0cmlidXRlZCB0byBub2Rlcy4gIFRoaXMgbWF5IGJlCiAg ICAgICAgYmFzZWQgb24gdGhlIENvbnRhY3QgUGxhbiBVcGRhdGUgUHJvdG9jb2wgKENQVVApIHBy b3Bvc2VkIGluCgogICAgICBvIEFuIGVuY2Fwc3VsYXRpb24gcHJvdG9jb2wgZm9yICJ0dW5uZWxp bmciIEJQIHRyYWZmaWMgd2l0aGluIGJ1bmRsZXMKCXRoYXQgYXJlIHNlY3VyZWQgYW5kL29yIHJv dXRlZCBpbiBkaWZmZXJlbnQgd2F5IGZyb20gdGhlIGVuY2Fwc3VsYXRlZAoJYnVuZGxlcy4KCiAg ICAgIG8gQTwvZm9udD48L3N0cm9uZz4gcmVnaXN0cnkgZm9yIERUTiBTZXJ2aWNlIElkZW50aWZp ZXJzCgogICAgVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBjb25zaWRlciBleHRlbmRpbmcgdGhlIGN1 cnJlbnQgbWlsZXN0b25lcyBiYXNlZCBvbgogICAgbmV3IGluZm9ybWF0aW9uIGFuZCBrbm93bGVk Z2UgZ2FpbmVkIHdoaWxlIHdvcmtpbmcgb24gdGhlIGluaXRpYWwgY2hhcnRlciwKICAgIGFzIHdl bGwgYXMgdG8gYWNjb21tb2RhdGUgbmV3IHdvcmsgaXRlbXMgYmV5b25kIHRoZSBzY29wZSBvZiB0 aGUgaW5pdGlhbAogICAgcGhhc2UuICBGb3IgZXhhbXBsZSwgd2UgZXhwZWN0IHRoYXQgdHJhbnNw b3J0IHByb3RvY29scyBzdWNoIGFzIExUUCBhbmQKICAgIHRoZSBTYXJhdG9nYSBwcm90b2NvbCBh cmUgYW1vbmcgdGhlIGNhbmRpZGF0ZXMgZm9yIHdvcmsgaW4gdGhpcyBwaGFzZS4KCkdvYWxzIGFu ZCBNaWxlc3RvbmVzOgogIHN0YXJ0KzNtb3MgLSBTdWJtaXQgJ0J1bmRsZSBQcm90b2NvbCBTcGVj aWZpY2F0aW9uIChSRkM1MDUwYmlzKScgYXMgYQogICAgICAgICAgICAgICB3b3JraW5nIGdyb3Vw IGRvY3VtZW50IFsyXS4gVG8gYmUgUHJvcG9zZWQgU3RhbmRhcmQuCiAgU3RhcnQrM21vcyAtIFN1 Ym1pdCAnU3RyZWFtbGluZWQgQnVuZGxlIFNlY3VyaXR5IFByb3RvY29sIChTQlNQKScgYXMgYQog ICAgICAgICAgICAgICB3b3JraW5nIGdyb3VwIGRvY3VtZW50IFszXS4gVG8gYmUgUHJvcG9zZWQg U3RhbmRhcmQuCiAgc3RhcnQrNm1vcyAtIFN1Ym1pdCAnQnVuZGxlIEluIEJ1bmRsZSBFbmNhcHN1 bGF0aW9uIChCSUJFKScgYXMgYSB3b3JraW5nCiAgICAgICAgICAgICAgIGdyb3VwIGRvY3VtZW50 IFs0XS4gVG8gYmUgUHJvcG9zZWQgU3RhbmRhcmQuCiAgc3RhcnQrMTJtb3MgLSBTdWJtaXQgPHN0 cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nID4nQ0dSIEZ1bmN0aW9uYWwgU3BlY2lmaWNhdGlvbicg YXMgYSB3b3JraW5nIGdyb3VwCiAgICAgICAgICAgICAgICBkb2N1bWVudC4gVG8gYmUgYW4gaW5m b3JtYXRpb25hbCBkb2N1bWVudC4KICBzdGFydCsxMm1vcyAtIFN1Ym1pdDwvZm9udD48L3N0cm9u Zz4gJ0RlbGF5IFRvbGVyYW50IE5ldHdvcmtpbmcgU2VjdXJpdHkgS2V5IE1hbmFnZW1lbnQnIGFz CiAgICAgICAgICAgICAgICBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuIFRvIGJlIFByb3Bvc2Vk IFN0YW5kYXJkLgogIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJyA+c3RhcnQrMTVtb3MgLSBT dWJtaXQgJ0NvbnRhY3QgUGxhbiBVcGRhdGUgUHJvdG9jb2wnIGFzIHdvcmtpbmcgZ3JvdXAKICAg ICAgICAgICAgICAgIGRvY3VtZW50LiAgVG8gYmUgUHJvcG9zZWQgU3RhbmRhcXFyZC48L2ZvbnQ+ PC9zdHJvbmc+CiAgc3RhcnQrMThtb3MgLSBXRyBkZXRlcm1pbmF0aW9uIGZvciBtZXJnaW5nIFJG QzUwNTBiaXMsIFNCU1AsIEJJQkUgYW5kL29yCiAgICAgICAgICAgICAgICBLZXkgTWdtdCBpbnRv IGEgY29tYmluZWQgZHJhZnQgb3Iga2VlcCBhcyBzZXBhcmF0ZSBkcmFmdHMuCiAgc3RhcnQrMTht b3MgLSBTdWJtaXQgUkZDNTA1MGJpcywgU0JTUCwgQklCRSBhbmQgS2V5IE1nbXQgdG8gdGhlIElF U0cgZWl0aGVyCiAgICAgICAgICAgICAgICBhcyBhIGNvbWJpbmVkIGRyYWZ0IG9yIGFzIHNlcGFy YXRlIGRyYWZ0cy4KICBzdGFydCsxOG1vcyAtIFN1Ym1pdCBOZXR3b3JrIE1hbmFnZW1lbnQgWzVd LCBSZWdpc3RyeSBbNl0gYW5kIFNpbXBsZQogICAgICAgICAgICAgICAgQ29udmVyZ2VuY2UgTGF5 ZXIgWzddIGFzIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnRzLgogIHN0YXJ0KzIwbW9zIC0gU3VydmV5 IGFwcHJvcHJpYXRlIGZvcnVtcyAoZS5nLiwgRFROUkcpIGZvciBlbWVyZ2luZwogICAgICAgICAg ICAgICAgdGVjaG5vbG9naWVzIChlLmcuLCBjb252ZXJnZW5jZSBsYXllciBwcm90b2NvbHMsIGR5 bmFtaWMKICAgICAgICAgICAgICAgIHJvdXRpbmcgcHJvdG9jb2xzLCBuYW1pbmcgYW5kIGFkZHJl c3Npbmcgc2VydmljZXMsIGV0Yy4pCiAgICAgICAgICAgICAgICByZWFkeSBmb3IgdHJhbnNpdGlv biBpbnRvIElFVEYgRFROIFdvcmtpbmcgR3JvdXAuIFB1Ymxpc2gKICAgICAgICAgICAgICAgIGRy YWZ0IG9uIHN1cnZleSByZXN1bHRzIGFzIGluZGVwZW5kZW50IHN1Ym1pc3Npb24gcmVsYXRlZAog ICAgICAgICAgICAgICAgdG8gdGhlIFdHLgogIHN0YXJ0KzI0bW9zIC0gU3VibWl0IE5ldHdvcmsg TWFuYWdlbWVudCwgUmVnaXN0cnkgYW5kIFNpbXBsZSBDb252ZXJnZW5jZQogICAgICAgICAgICAg ICAgTGF5ZXIgdG8gSUVTRwogIHN0YXJ0KzI0bW9zIC0gUmVjaGFydGVyIHRvIGFjY29tbW9kYXRl IG5ldyB3b3JrIGl0ZW1zIG9yIGNsb3NlIFdvcmtpbmcgR3JvdXAKClsxXSAiQlAvTFRQIGRlcGxv eW1lbnQgb24gRVBPWEkgc3BhY2VjcmFmdCIgWzIwMDhdLAogICAgaHR0cDovL2NvbW1pdHRlZXMu Y29tc29jLm9yZy90Y2NjL2Njdy8yMDEwL3NsaWRlcy9ESU5FVF9DQ1cucGRmClsyXSAiUHJvcG9z ZWQgUmV2aXNlZCBCdW5kbGUgUHJvdG9jb2wiIFsyMDE0XSwKICAgIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJ1cmxlaWdoLWJwdjcvClszXSAiU3RyZWFtbGluZWQgQnVu ZGxlIFNlY3VyaXR5IFByb3RvY29sIFNwZWNpZmljYXRpb24iIFsyMDE0XSwKICAgIGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlydGYtZHRucmctc2JzcC8KWzRdICJCdW5k bGUtaW4tQnVuZGxlIEVuY2Fwc3VsYXRpb24iIFsyMDEzXSwKICAgIGh0dHA6Ly90b29scy5pZXRm Lm9yZy9pZC9kcmFmdC1pcnRmLWJ1cmxlaWdoLWJpYmUKWzVdICJEZWxheSBUb2xlcmFudCBOZXR3 b3JrIE1hbmFnZW1lbnQgUHJvdG9jb2wiIFsyMDEzXSwKICAgIGh0dHA6Ly90b29scy5pZXRmLm9y Zy9pZC9kcmFmdC1pcnRmLWR0bnJnLWR0bm1wCls2XSAiRGVsYXktVG9sZXJhbnQgTmV0d29ya2lu ZyBCdW5kbGUgUHJvdG9jb2wgSUFOQSBSZWdpc3RyaWVzIiBbMjAxMV0sCiAgICBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9yZmM2MjU1LwpbN10gIkRhdGFncmFtIENvbnZlcmdlbmNl IExheWVycyAuLi4iIFsyMDE0XSwKICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L3JmYzcxMjIvCjxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJyA+WzhdICJUb3dhcmRzIEZsZXhp YmlsaXR5IGFuZCBBY2N1cmFjeSBpbiBTcGFjZSBEVE4gQ29tbXVuaWNhdGlvbnMiLAogICAgQmV6 aXJnaWFubmRpYSBldCBhbCwgQ0hBTlRTIDIwMTIsCiAgICBodHRwOi8vZGwuYWNtLm9yZy9jaXRh dGlvbi5jZm0/aWQ9MjUwNTQ5OSBbMjAxMl08L2ZvbnQ+PC9zdHJvbmc+CjwvcHJlPgo8L2JvZHk+ PC9odG1sPgpYLUdlbmVyYXRvcjogcHlodCAwLjM1Cgo8IS0tIGFyZ3M6IHsnLS1vbGRjb2xvdXIn OiAncmVkJywgJy0td2lkdGgnOiAnJywgJ2RpZmZ0eXBlJzogJy0taHdkaWZmJywgJ2ZpbGVuYW1l Mic6ICdEcmFmdCBCb0YgQWdlbmRhICgyLjVocnMpOlxyXG4qKioqKioqKioqKioqKioqKioqKioq KioqKlxyXG4xKSBQcm9ibGVtIHN0YXRlbWVudCAoSUVURiB3ZyBtb3RpdmF0aW9uKSAtIDMwbWlu XHJcblxyXG4yKSBSRkM1MDUwKGJpcykgLSAxNW1pblxyXG5cclxuMykgU3RyZWFtbGluZWQgQnVu ZGxlIFNlY3VyaXR5IFByb3RvY29sIChTQlNQKSAtIDE1bWluXHJcblxyXG40KSBTZWN1cml0eSBL ZXkgTWFuYWdlbWVudCAtIDEwbWluXHJcblxyXG41KSBOZXR3b3JrIE1hbmFnZW1lbnQgLSAxMG1p blxyXG5cclxuNikgQ29udGFjdCBHcmFwaCBSb3V0aW5nIGFuZCBDb250YWN0IFBsYW4gVXBkYXRl IFByb3RvY29sIC0gMTBtaW5cclxuXHJcbjcpIEJ1bmRsZS1pbi1CdW5kbGUgRW5jYXBzdWxhdGlv biAtIDVtaW5cclxuXHJcbjgpIFJlZ2lzdHJ5IGZvciBTZXJ2aWNlIElkZW50aWZpZXJzIC0gNW1p blxyXG5cclxuOSkgT3BlbiBEaXNjdXNzaW9uIC0gNTBtaW5cclxuXHJcblxyXG5EcmFmdCB3b3Jr aW5nIGdyb3VwIGNoYXJ0ZXI6XHJcbioqKioqKioqKioqKioqKioqKioqKioqKioqKipcclxuV29y a2luZyBncm91cCBuYW1lOiBcclxuXHJcbiAgICAgIERlbGF5L0Rpc3J1cHRpb24gVG9sZXJhbnQg TmV0d29ya2luZyBXb3JraW5nIEdyb3VwIChEVE5XRylcclxuXHJcbkNoYWlyKHMpOlxyXG5cclxu ICAgICAgVEJEXHJcblxyXG5BcmVhIGFuZCBBcmVhIERpcmVjdG9yKHMpOlxyXG5cclxuICAgICAg VHJhbnNwb3J0IEFyZWE6IEFEcyBTcGVuY2VyIERhd2tpbnMgX3NwZW5jZXJkYXdraW5zLmlldGYg YXQgZ21haWwuY29tXyxcclxuICAgICAgICAgICAgICAgICAgICAgICAgICBNYXJ0aW4gU3RpZW1l cmxpbmcgX21scy5pZXRmIGF0IGdtYWlsLmNvbV9cclxuXHJcblJlc3BvbnNpYmxlIEFyZWEgRGly ZWN0b3I6XHJcblxyXG4gICAgICBUQkRcclxuXHJcbk1haWxpbmcgbGlzdDpcclxuXHJcbiAgICAg IEdlbmVyYWwgRGlzY3Vzc2lvbjogZHRuIGF0IGlldGYub3JnXHJcbiAgICAgIFRvIFN1YnNjcmli ZTogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kdG5cclxuICAgICAgQXJj aGl2ZTogaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2R0bi9jdXJyZW50L21h aWxsaXN0Lmh0bWxcclxuXHJcbkRlc2NyaXB0aW9uIG9mIFdvcmtpbmcgR3JvdXA6XHJcblxyXG4g ICAgICBUaGUgRGVsYXkvRGlzcnVwdGlvbiBUb2xlcmFudCBOZXR3b3JrIFdvcmtpbmcgR3JvdXAg KERUTldHKSBzcGVjaWZpZXNcclxuICAgICAgbWVjaGFuaXNtcyBmb3IgZGF0YSBjb21tdW5pY2F0 aW9ucyBpbiB0aGUgcHJlc2VuY2Ugb2YgbG9uZyBkZWxheXNcclxuICAgICAgYW5kL29yIGludGVy bWl0dGVudCBjb25uZWN0aXZpdHkuIFRoZSB3b3JrIGlzIG1vdGl2YXRlZCBieSB3ZWxsIGtub3du XHJcbiAgICAgIGxpbWl0YXRpb25zIG9mIHN0YW5kYXJkIEludGVybmV0IHByb3RvY29scyB0aGF0 IGV4cGVjdCBlbmQtdG8tZW5kXHJcbiAgICAgIGNvbm5lY3Rpdml0eSBiZXR3ZWVuIGNvbW11bmlj YXRpbmcgZW5kcG9pbnRzLCBzdWItc2Vjb25kIHRyYW5zbWlzc2lvblxyXG4gICAgICBkZWxheXMg YW5kIHJvYnVzdCBwYWNrZXQgZGVsaXZlcnkgcmF0aW9zLiBJbiBlbnZpcm9ubWVudHMgd2hlcmUg dGhlc2VcclxuICAgICAgZmF2b3JhYmxlIGNvbmRpdGlvbnMgZG8gbm90IGFwcGx5LCBleGlzdGlu ZyBtZWNoYW5pc21zIGVuY291bnRlciBwcm9ibGVtcyBcclxuICAgICAgc3VjaCBhcyByZWxpYWJs ZSB0cmFuc3BvcnQgcHJvdG9jb2wgaGFuZHNoYWtlcyB0aW1pbmcgb3V0IGFuZCByb3V0aW5nIFxy XG4gICAgICBwcm90b2NvbHMgZmFpbGluZyB0byBjb252ZXJnZSByZXN1bHRpbmcgaW4gY29tbXVu aWNhdGlvbiBmYWlsdXJlcy4gXHJcbiAgICAgIEZ1cnRoZXJtb3JlLCBjbGFzc2ljYWwgZW5kLXRv LWVuZCBzZWN1cml0eSBhc3NvY2lhdGlvbnMgY2Fubm90IGJlIFxyXG4gICAgICBjb29yZGluYXRl ZCB3aGVuIGNvbW11bmljYXRpbmcgZW5kcG9pbnRzIGNhbm5vdCBjb25kdWN0IG11bHRpLW1lc3Nh Z2UgXHJcbiAgICAgIGtleWluZyBleGNoYW5nZXMgaW4gYSB0aW1lbHkgZmFzaGlvbi4gVGhlc2Ug bGltaXRhdGlvbnMgc3VnZ2VzdGVkIHRoZSBcclxuICAgICAgbmVlZCBmb3IgYSBuZXcgYXBwcm9h Y2guIFxyXG4gICAgICBcclxuICAgICAgRGVsYXktVG9sZXJhbnQgTmV0d29ya2luZyAoRFROKSBw cm90b2NvbHMgaGF2ZSBiZWVuIHRoZSBzdWJqZWN0IG9mXHJcbiAgICAgIGV4dGVuc2l2ZSByZXNl YXJjaCBhbmQgZGV2ZWxvcG1lbnQgaW4gdGhlIERlbGF5LVRvbGVyYW50IE5ldHdvcmtpbmdcclxu ICAgICAgUmVzZWFyY2ggR3JvdXAgKERUTlJHKSBvZiB0aGUgSW50ZXJuZXQgUmVzZWFyY2ggVGFz ayBGb3JjZSBzaW5jZSAyMDAyLlxyXG4gICAgICBUaGUgRFROUkcgaGFzIGRldmVsb3BlZCB0aGUg RGVsYXktVG9sZXJhbnQgTmV0d29ya2luZyBBcmNoaXRlY3R1cmUgXHJcbiAgICAgIChSRkMgNDgz OCkgdGhhdCB0aGUgRFROV0cgdXNlcyBhcyB0aGUgYmFzaXMgZm9yIGl0cyB3b3JrLiAgVGhlIGtl eSBcclxuICAgICAgY29tcG9uZW50cyBvZiB0aGUgdGhpcyBhcmNoaXRlY3R1cmUgYXJlIHRoZSBi dW5kbGUgY29uY2VwdCBmb3IgXHJcbiAgICAgIGVuY2Fwc3VsYXRpbmcgZGF0YSB1bml0cywgdGhl IGJ1bmRsZSB0cmFuc21pc3Npb24gcHJvdG9jb2wgYW5kIHRoZSBcclxuICAgICAgdW5kZXJseWlu ZyBjb252ZXJnZW5jZSBsYXllciBhcmNoaXRlY3R1cmUuXHJcbiAgICBcclxuICAgICAgVGhlIGV4 cGVyaW1lbnRhbCBEVE4gQnVuZGxlIFByb3RvY29sIChSRkMgNTA1MCkgYW5kIExpY2tsaWRlclxy XG4gICAgICBUcmFuc21pc3Npb24gUHJvdG9jb2wgKFJGQyA1MzI2KSBoYXZlIGJlZW4gc2hvd24g dG8gYWRkcmVzcyB0aGVcclxuICAgICAgaXNzdWVzIGlkZW50aWZpZWQgYWJvdmUgaW4gc3Vic3Rh bnRpYWwgZmllbGRlZCBkZXBsb3ltZW50cyBpbiB0aGUgc3BhY2UgXHJcbiAgICAgIHNlY3RvciBb MV0uICBSRkMgNTA1MCBpbiBjb25qdW5jdGlvbiB3aXRoIFRDUC0gYW5kIFVEUC1iYXNlZCBjb252 ZXJnZW5jZSBcclxuICAgICAgbGF5ZXJzIGhhcyBiZWVuIHVzZWQgc3VjY2Vzc2Z1bGx5IGluIGEg bnVtYmVyIG9mIGV4cGVyaW1lbnRzIGJvdGggaW4gXHJcbiAgICAgIGNvbW11bmljYXRpb25zIGNo YWxsZW5nZWQgZW52aXJvbm1lbnRzIGFyb3VuZCB0aGUgZWRnZXMgb2YgdGhlIEludGVybmV0IFxy XG4gICAgICBhbmQgYXMgYW4gSW50ZXJuZXQgb3ZlcmxheSB3aGVyZSBhcHBsaWNhdGlvbnMgcmVx dWlyZSBkZWxheS0gYW5kL29yIFxyXG4gICAgICBkaXNydXB0aW9uLXRvbGVyYW5jZSBbcmVmcyBu ZWVkZWRdLiAgXHJcblxyXG4gICAgICBUaGUgc3VjY2VzcyBvZiB0aGUgQlAgb3ZlciBjb252ZXJn ZW5jZSBsYXllciBwcm90b2NvbCBzdGFjayAtLSB0aGUgY29yZSBcclxuICAgICAgcHJvdG9jb2xz IG9mIHRoZSAiRFROIEFyY2hpdGVjdHVyZSIgZGVzY3JpYmVkIGluIFJGQyA0ODM4IC0tIG1heSBi ZSBcclxuICAgICAgYXR0cmlidXRlZCB0byB0aGUgZm9sbG93aW5nIGZ1bmRhbWVudGFsIGRlc2ln biBwcmluY2lwbGVzOlxyXG5cclxuXHQtIFRoZXJlIGlzIG5ldmVyIGFueSBleHBlY3RhdGlvbiBv ZiBjb250ZW1wb3JhbmVvdXMgZW5kLXRvLWVuZFxyXG4gICAgICAgICAgY29ubmVjdGl2aXR5IGJl dHdlZW4gYW55IHR3byBuZXR3b3JrIG5vZGVzLlxyXG5cclxuXHQtIEJlY2F1c2UgZW5kLXRvLWVu ZCBjb25uZWN0aXZpdHkgY2FuIG5ldmVyIGJlIGFzc3VtZWQsIGVhY2ggbm9kZVxyXG5cdCAgb24g dGhlIHBhdGggYmV0d2VlbiBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uIG11c3QgYmUgcHJlcGFyZWQg dG9cclxuXHQgIGhhbmRsZSBpbmNvbWluZyAiYnVuZGxlcyIgb2YgZGF0YSB0aGF0IGNhbm5vdCBp bW1lZGlhdGVseSBiZVxyXG5cdCAgZm9yd2FyZGVkLlxyXG5cclxuXHQtIEFnYWluIGJlY2F1c2Ug ZW5kLXRvLWVuZCBjb25uZWN0aXZpdHkgY2FuIG5ldmVyIGJlIGFzc3VtZWQsXHJcblx0ICBlbmQt dG8tZW5kIGNvbnZlcnNhdGlvbmFsIGRhdGEgZXhjaGFuZ2UgY2FuIG5ldmVyIGJlIGFzc3VtZWQg dG9cclxuXHQgIGNvbXBsZXRlIGluIGEgdGltZWx5IG1hbm5lcjsgcHJvdG9jb2wgZmVhdHVyZXMg dGhhdCByZWx5IG9uXHJcblx0ICB0aW1lbHkgY29udmVyc2F0aW9uYWwgZGF0YSBleGNoYW5nZSBt dXN0IGJlIGV4Y2x1ZGVkIGZyb20gdGhlXHJcblx0ICBhcmNoaXRlY3R1cmUuXHJcblxyXG4gICAg ICBUaGUgRFROV0cgYmVsaWV2ZXMgdGhhdCBwcm90b2NvbHMgYWRoZXJpbmcgdG8gdGhlc2UgcHJp bmNpcGxlcyBvZmZlclxyXG4gICAgICBvcHBvcnR1bml0aWVzIGZvciBlbmhhbmNpbmcgdGhlIGZ1 bmN0aW9uYWxpdHkgb2YgdGhlIEludGVybmV0LCBpbmNsdWRpbmcgXHJcblxyXG4gICAgICAgIC0g ZmFjaWxpdGF0aW5nIHRoZSBleHRlbnNpb24gb2YgdGhlIEludGVybmV0IGludG8gZW52aXJvbm1l bnRzIHN1Y2ggYXMgXHJcbiAgICAgICAgICB0aGUgb2NlYW4gZmxvb3IgYW5kIGRlZXAgc3BhY2Ug aW4gd2hpY2ggdGhlIGNvcmUgSW50ZXJuZXQgcHJvdG9jb2xzIFxyXG4gICAgICAgICAgb3BlcmF0 ZSBzdWItb3B0aW1hbGx5IGZvciB0aGUgcmVhc29ucyBkaXNjdXNzZWQgZWFybGllcjtcclxuXHJc biAgICAgICAgLSBleHRlbmRpbmcgdGhlIEludGVybmV0IGludG8gY29tbXVuaWNhdGlvbnMgY2hh bGxlbmdlZCB0ZXJyZXN0cmlhbCBcclxuICAgICAgICAgIGVudmlyb25tZW50cyB3aGVyZSBpdCBp cyBub3QgcG9zc2libGUgdG8gcHJvdmlkZSBjb250aW51b3VzLCBsb3cgXHJcbiAgICAgICAgICBk ZWxheSBJbnRlcm5ldCBjb25uZWN0aW9uczsgYW5kIFxyXG5cclxuICAgICAgICAtIHN1cHBvcnRp bmcgSW50ZXJuZXQgYXBwbGljYXRpb25zIHRoYXQgbmVlZCBEVE4gY2FwYWJpbGlpZXMuXHJcblxy XG4gICAgICBXZSBiZWxpZXZlIHRoYXQgdGhlIGV4dGVuc2l2ZSByZXNlYXJjaCwgZGVtb25zdHJh dGlvbiwgYW5kXHJcbiAgICAgIHBpbG90IG9wZXJhdGlvbnMgcGVyZm9ybWVkIHRvIGRhdGUgdXNp bmcgdGhlIERUTlJHIHByb3RvY29scyBwcm92aWRlc1xyXG4gICAgICBhIGZpcm0gYmFzaXMgZm9y IHB1Ymxpc2hpbmcgSW50ZXJuZXQgc3RhbmRhcmRzIGRlcml2ZWQgZnJvbSB0aGF0IHdvcmsuXHJc blxyXG4gICAgICBXb3JrIGl0ZW1zIHJlbGF0ZWQgdG8gRGVsYXkvRGlzcnVwdGlvbiBUb2xlcmFu dCBOZXR3b3JraW5nIGluY2x1ZGU6XHJcblxyXG4gICAgICBvIEEgbWVjaGFuaXNtIGZvciB0aGUg ZXhjaGFuZ2Ugb2YgcHJvdG9jb2wgZGF0YSB1bml0cywgdGVybWVkXHJcblx0ImJ1bmRsZXMiLCB0 aGF0IGFyZSBkZXNpZ25lZCB0byBvYnZpYXRlIGNvbnZlcnNhdGlvbmFsIGNvbW11bmljYXRpb25z XHJcblx0YnkgY29udGFpbmluZyB2YWx1ZXMgZm9yIGFsbCBwb3RlbnRpYWxseSByZWxldmFudCBj b25maWd1cmF0aW9uXHJcblx0cGFyYW1ldGVycy4gIFRoZXNlIHByb3RvY29sIGRhdGEgdW5pdHMg YXJlIHR5cGljYWxseSBsYXJnZXIgdGhhblxyXG5cdG5ldHdvcmstbGF5ZXIgcGFja2V0cy4gV2Ug d2lsbCBkZXJpdmUgdGhpcyBidW5kbGUgZXhjaGFuZ2UgbWVjaGFuaXNtXHJcbiAgICAgICAgZnJv bSB0aGUgRFROIEJ1bmRsZSBQcm90b2NvbCAoQlApIGRvY3VtZW50ZWQgaW4gUkZDIDUwNTAgYnkg cHVibGlzaGluZ1xyXG4gICAgICAgIGEgbmV3IGRvY3VtZW50IGZvciB3aGljaCBbMl0gaXMgYSBw cm9wb3NlZCBmaXJzdCBkcmFmdCAod2hlcmVcclxuICAgICAgICBhcHBlbmRpeCBBIHByb3ZpZGVz IGEgc3VtbWFyeSBvZiB0aGUgcHJvcG9zZWQgY2hhbmdlcykuXHJcblxyXG4gICAgICBvIEEgc2Vj dXJpdHkgcHJvdG9jb2wgZm9yIGVuc3VyaW5nIHRoYXQgdGhlIG5ldHdvcmsgaW4gd2hpY2ggYnVu ZGxlc1xyXG5cdGFyZSBleGNoYW5nZWQgaXMgc2VjdXJlZCBhZ2FpbnN0IHVuYXV0aG9yaXplZCBh Y2Nlc3MgYW5kIGRlbmlhbCBvZlxyXG5cdHNlcnZpY2UgYXR0YWNrcywgYW5kIHRvIGVuc3VyZSBk YXRhIGludGVncml0eSBhbmQgY29uZmlkZW50aWFsaXR5XHJcblx0aW4gdGhhdCBuZXR3b3JrIHdo ZXJlIG5lY2Vzc2FyeS4gIFdlIHdpbGwgZGVyaXZlIHRoaXMgc2VjdXJpdHlcclxuXHRwcm90b2Nv bCBmcm9tIGEgInN0cmVhbWxpbmVkIiBhZGFwdGF0aW9uIG9mIHRoZSBEVE4gQnVuZGxlIFNlY3Vy aXR5XHJcblx0UHJvdG9jb2wgZG9jdW1lbnRlZCBpbiBSRkMgNjI1Ny5cclxuXHJcbiAgICAgIG8g QSBkZWxheS10b2xlcmFudCBzZWN1cml0eSBrZXkgbWFuYWdlbWVudCBzY2hlbWUgZm9yIGVuc3Vy aW5nIHRoYXRcclxuXHRwdWJsaWMga2V5cyBhcmUgY2VydGlmaWVkIGJ5IGEgZ2xvYmFsbHkgdHJ1 c3RlZCBhdXRob3JpdHkgdG8gcHJvdGVjdFxyXG5cdHRoZSBpbnRlZ3JpdHkgb2YgdGhlIGluZnJh c3RydWN0dXJlLlxyXG5cclxuICAgICAgbyBBIHNpbXBsZSBkYXRhZ3JhbSBjb252ZXJnZW5jZSBs YXllciBwcm90b2NvbCBmb3IgYWRhcHRhdGlvbiBvZiB0aGVcclxuICAgICAgICBidW5kbGUgcHJv dG9jb2wgdG8gdW5kZXJseWluZyBpbnRlcm5ldHdvcmtzLiBXZSBleHBlY3QgdG8gZGVyaXZlXHJc biAgICAgICAgdGhpcyBjb252ZXJnZW5jZSBsYXllciBwcm90b2NvbCBmcm9tIHRoZSBEYXRhZ3Jh bSBDb252ZXJnZW5jZVxyXG4gICAgICAgIHByb3RvY29sIGRvY3VtZW50ZWQgaW4gUkZDIDcxMjIu XHJcblxyXG4gICAgICBvIEEgZGVsYXktdG9sZXJhbnQgbmV0d29yayBtYW5hZ2VtZW50IHByb3Rv Y29sIGZvciBtYW5hZ2VtZW50IG9mIHRoZVxyXG4gICAgICAgIGluZnJhc3RydWN0dXJlIGluIHRo ZSBwcmVzZW5jZSBvZiBsb25nIGRlbGF5cyBhbmQvb3IgaW50ZXJtaXR0ZW50XHJcbiAgICAgICAg Y29ubmVjdGl2aXR5LlxyXG5cclxuICAgICAgbyBBIGZ1bmN0aW9uYWwgc3BlY2lmaWNhdGlvbiBv ZiBDb250YWN0IEdyYXBoIFJvdXRpbmcgKENHUikgc3BlY2lmeWluZyBcclxuICAgICAgICB0aGUg aW5wdXRzIChnbG9iYWwgY29udGFjdCBzY2hlZHVsZXMsIHRyYWZmaWMgZGVtYW5kcywgZXRjLikg YW5kIFxyXG4gICAgICAgIG91dHB1dHMgKG5vZGUgc3BlY2lmaWMgdHJhbnNtaXNzaW9uIGFuZCBy ZWNlcHRpb24gc2NoZWR1bGVzLCBcclxuICAgICAgICBub3RpZmljYXRpb25zLCBldGMuKS4gIENH UiBpcyBhIGNlbnRyYWxpemVkLCBvcmFjbGUtYmFzZWQgYnVuZGxlIFxyXG4gICAgICAgIHRyYW5z bWlzc2lvbiBhbmQgcmVjZXB0aW9uIHNjaGVkdWxpbmcgc2NoZW1lIHVzZWQgaW4gc3BhY2Ugc2Vn bWVudCBcclxuICAgICAgICBEVE4gZGVwbG95bWVudHMuXHJcblxyXG4gICAgICBvIEFuIGFkanVu Y3QgdG8gdGhlIG1hbmFnZW1lbnQgcHJvdG9jb2wgdGhhdCB3aWxsIGFsbG93IHRoZSBjb250YWN0 IFxyXG4gICAgICAgIHNjaGVkdWxlcyBnZW5lcmF0ZWQgYnkgQ0dSIHRvIGJlIGRpc3RyaWJ1dGVk IHRvIG5vZGVzLiAgVGhpcyBtYXkgYmUgXHJcbiAgICAgICAgYmFzZWQgb24gdGhlIENvbnRhY3Qg UGxhbiBVcGRhdGUgUHJvdG9jb2wgKENQVVApIHByb3Bvc2VkIGluICBcclxuXHJcbiAgICAgIG8g QW4gZW5jYXBzdWxhdGlvbiBwcm90b2NvbCBmb3IgInR1bm5lbGluZyIgQlAgdHJhZmZpYyB3aXRo aW4gYnVuZGxlc1xyXG5cdHRoYXQgYXJlIHNlY3VyZWQgYW5kL29yIHJvdXRlZCBpbiBkaWZmZXJl bnQgd2F5IGZyb20gdGhlIGVuY2Fwc3VsYXRlZFxyXG5cdGJ1bmRsZXMuXHJcblxyXG4gICAgICBv IEEgcmVnaXN0cnkgZm9yIERUTiBTZXJ2aWNlIElkZW50aWZpZXJzXHJcbiAgXHJcbiAgICBUaGUg d29ya2luZyBncm91cCB3aWxsIGNvbnNpZGVyIGV4dGVuZGluZyB0aGUgY3VycmVudCBtaWxlc3Rv bmVzIGJhc2VkIG9uXHJcbiAgICBuZXcgaW5mb3JtYXRpb24gYW5kIGtub3dsZWRnZSBnYWluZWQg d2hpbGUgd29ya2luZyBvbiB0aGUgaW5pdGlhbCBjaGFydGVyLFxyXG4gICAgYXMgd2VsbCBhcyB0 byBhY2NvbW1vZGF0ZSBuZXcgd29yayBpdGVtcyBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoZSBpbml0 aWFsXHJcbiAgICBwaGFzZS4gIEZvciBleGFtcGxlLCB3ZSBleHBlY3QgdGhhdCB0cmFuc3BvcnQg cHJvdG9jb2xzIHN1Y2ggYXMgTFRQIGFuZFxyXG4gICAgdGhlIFNhcmF0b2dhIHByb3RvY29sIGFy ZSBhbW9uZyB0aGUgY2FuZGlkYXRlcyBmb3Igd29yayBpbiB0aGlzIHBoYXNlLlxyXG4gICAgXHJc bkdvYWxzIGFuZCBNaWxlc3RvbmVzOlxyXG4gIHN0YXJ0KzNtb3MgLSBTdWJtaXQgXCdCdW5kbGUg UHJvdG9jb2wgU3BlY2lmaWNhdGlvbiAoUkZDNTA1MGJpcylcJyBhcyBhXHJcbiAgICAgICAgICAg ICAgIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQgWzJdLiBUbyBiZSBQcm9wb3NlZCBTdGFuZGFyZC5c clxuICBTdGFydCszbW9zIC0gU3VibWl0IFwnU3RyZWFtbGluZWQgQnVuZGxlIFNlY3VyaXR5IFBy b3RvY29sIChTQlNQKVwnIGFzIGFcclxuICAgICAgICAgICAgICAgd29ya2luZyBncm91cCBkb2N1 bWVudCBbM10uIFRvIGJlIFByb3Bvc2VkIFN0YW5kYXJkLlxyXG4gIHN0YXJ0KzZtb3MgLSBTdWJt aXQgXCdCdW5kbGUgSW4gQnVuZGxlIEVuY2Fwc3VsYXRpb24gKEJJQkUpXCcgYXMgYSB3b3JraW5n XHJcbiAgICAgICAgICAgICAgIGdyb3VwIGRvY3VtZW50IFs0XS4gVG8gYmUgUHJvcG9zZWQgU3Rh bmRhcmQuXHJcbiAgc3RhcnQrMTJtb3MgLSBTdWJtaXQgXCdDR1IgRnVuY3Rpb25hbCBTcGVjaWZp Y2F0aW9uXCcgYXMgYSB3b3JraW5nIGdyb3VwIFxyXG4gICAgICAgICAgICAgICAgZG9jdW1lbnQu IFRvIGJlIGFuIGluZm9ybWF0aW9uYWwgZG9jdW1lbnQuXHJcbiAgc3RhcnQrMTJtb3MgLSBTdWJt aXQgXCdEZWxheSBUb2xlcmFudCBOZXR3b3JraW5nIFNlY3VyaXR5IEtleSBNYW5hZ2VtZW50XCcg YXNcclxuICAgICAgICAgICAgICAgIGEgd29ya2luZyBncm91cCBkb2N1bWVudC4gVG8gYmUgUHJv cG9zZWQgU3RhbmRhcmQuXHJcbiAgc3RhcnQrMTVtb3MgLSBTdWJtaXQgXCdDb250YWN0IFBsYW4g VXBkYXRlIFByb3RvY29sXCcgYXMgd29ya2luZyBncm91cCBcclxuICAgICAgICAgICAgICAgIGRv Y3VtZW50LiAgVG8gYmUgUHJvcG9zZWQgU3RhbmRhcXFyZC5cclxuICBzdGFydCsxOG1vcyAtIFdH IGRldGVybWluYXRpb24gZm9yIG1lcmdpbmcgUkZDNTA1MGJpcywgU0JTUCwgQklCRSBhbmQvb3Jc clxuICAgICAgICAgICAgICAgIEtleSBNZ210IGludG8gYSBjb21iaW5lZCBkcmFmdCBvciBrZWVw IGFzIHNlcGFyYXRlIGRyYWZ0cy5cclxuICBzdGFydCsxOG1vcyAtIFN1Ym1pdCBSRkM1MDUwYmlz LCBTQlNQLCBCSUJFIGFuZCBLZXkgTWdtdCB0byB0aGUgSUVTRyBlaXRoZXJcclxuICAgICAgICAg ICAgICAgIGFzIGEgY29tYmluZWQgZHJhZnQgb3IgYXMgc2VwYXJhdGUgZHJhZnRzLlxyXG4gIHN0 YXJ0KzE4bW9zIC0gU3VibWl0IE5ldHdvcmsgTWFuYWdlbWVudCBbNV0sIFJlZ2lzdHJ5IFs2XSBh bmQgU2ltcGxlXHJcbiAgICAgICAgICAgICAgICBDb252ZXJnZW5jZSBMYXllciBbN10gYXMgd29y a2luZyBncm91cCBkb2N1bWVudHMuXHJcbiAgc3RhcnQrMjBtb3MgLSBTdXJ2ZXkgYXBwcm9wcmlh dGUgZm9ydW1zIChlLmcuLCBEVE5SRykgZm9yIGVtZXJnaW5nXHJcbiAgICAgICAgICAgICAgICB0 ZWNobm9sb2dpZXMgKGUuZy4sIGNvbnZlcmdlbmNlIGxheWVyIHByb3RvY29scywgZHluYW1pY1xy XG4gICAgICAgICAgICAgICAgcm91dGluZyBwcm90b2NvbHMsIG5hbWluZyBhbmQgYWRkcmVzc2lu ZyBzZXJ2aWNlcywgZXRjLilcclxuICAgICAgICAgICAgICAgIHJlYWR5IGZvciB0cmFuc2l0aW9u IGludG8gSUVURiBEVE4gV29ya2luZyBHcm91cC4gUHVibGlzaFxyXG4gICAgICAgICAgICAgICAg ZHJhZnQgb24gc3VydmV5IHJlc3VsdHMgYXMgaW5kZXBlbmRlbnQgc3VibWlzc2lvbiByZWxhdGVk XHJcbiAgICAgICAgICAgICAgICB0byB0aGUgV0cuXHJcbiAgc3RhcnQrMjRtb3MgLSBTdWJtaXQg TmV0d29yayBNYW5hZ2VtZW50LCBSZWdpc3RyeSBhbmQgU2ltcGxlIENvbnZlcmdlbmNlXHJcbiAg ICAgICAgICAgICAgICBMYXllciB0byBJRVNHXHJcbiAgc3RhcnQrMjRtb3MgLSBSZWNoYXJ0ZXIg dG8gYWNjb21tb2RhdGUgbmV3IHdvcmsgaXRlbXMgb3IgY2xvc2UgV29ya2luZyBHcm91cFxyXG5c clxuXHJcblsxXSAiQlAvTFRQIGRlcGxveW1lbnQgb24gRVBPWEkgc3BhY2VjcmFmdCIgWzIwMDhd LFxyXG4gICAgaHR0cDovL2NvbW1pdHRlZXMuY29tc29jLm9yZy90Y2NjL2Njdy8yMDEwL3NsaWRl cy9ESU5FVF9DQ1cucGRmICBcclxuWzJdICJQcm9wb3NlZCBSZXZpc2VkIEJ1bmRsZSBQcm90b2Nv bCIgWzIwMTRdLFxyXG4gICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt YnVybGVpZ2gtYnB2Ny9cclxuWzNdICJTdHJlYW1saW5lZCBCdW5kbGUgU2VjdXJpdHkgUHJvdG9j b2wgU3BlY2lmaWNhdGlvbiIgWzIwMTRdLFxyXG4gICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaXJ0Zi1kdG5yZy1zYnNwL1xyXG5bNF0gIkJ1bmRsZS1pbi1CdW5kbGUg RW5jYXBzdWxhdGlvbiIgWzIwMTNdLFxyXG4gICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2Ry YWZ0LWlydGYtYnVybGVpZ2gtYmliZVxyXG5bNV0gIkRlbGF5IFRvbGVyYW50IE5ldHdvcmsgTWFu YWdlbWVudCBQcm90b2NvbCIgWzIwMTNdLFxyXG4gICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2lk L2RyYWZ0LWlydGYtZHRucmctZHRubXBcclxuWzZdICJEZWxheS1Ub2xlcmFudCBOZXR3b3JraW5n IEJ1bmRsZSBQcm90b2NvbCBJQU5BIFJlZ2lzdHJpZXMiIFsyMDExXSxcclxuICAgIGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL3JmYzYyNTUvXHJcbls3XSAiRGF0YWdyYW0gQ29udmVy Z2VuY2UgTGF5ZXJzIC4uLiIgWzIwMTRdLFxyXG4gICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvcmZjNzEyMi9cclxuWzhdICJUb3dhcmRzIEZsZXhpYmlsaXR5IGFuZCBBY2N1cmFj eSBpbiBTcGFjZSBEVE4gQ29tbXVuaWNhdGlvbnMiLFxyXG4gICAgQmV6aXJnaWFubmRpYSBldCBh bCwgQ0hBTlRTIDIwMTIsXHJcbiAgICBodHRwOi8vZGwuYWNtLm9yZy9jaXRhdGlvbi5jZm0/aWQ9 MjUwNTQ5OSBbMjAxMl1cclxuXHJcblxyXG4nLCAnZmlsZW5hbWUxJzogJ0RyYWZ0IEJvRiBBZ2Vu ZGEgKDIuNWhycyk6XHJcbioqKioqKioqKioqKioqKioqKioqKioqKioqXHJcbjEpIFByb2JsZW0g c3RhdGVtZW50IChJRVRGIHdnIG1vdGl2YXRpb24pIC0gMzBtaW5cclxuXHJcbjIpIFJGQzUwNTAo YmlzKSAtIDE1bWluXHJcblxyXG4zKSBTdHJlYW1saW5lZCBCdW5kbGUgU2VjdXJpdHkgUHJvdG9j b2wgKFNCU1ApIC0gMTVtaW5cclxuXHJcbjQpIEJ1bmRsZS1pbi1CdW5kbGUgRW5jYXBzdWxhdGlv biAtIDEwbWluXHJcblxyXG41KSBTZWN1cml0eSBLZXkgTWFuYWdlbWVudCAtIDEwbWluXHJcblxy XG42KSBSZWdpc3RyeSBmb3IgU2VydmljZSBJZGVudGlmaWVycyAtIDEwbWluXHJcblxyXG43KSBO ZXR3b3JrIE1hbmFnZW1lbnQgLSAxMG1pblxyXG5cclxuOCkgT3BlbiBEaXNjdXNzaW9uIC0gNTBt aW5cclxuXHJcblxyXG5Qcm9wb3NlZCB3b3JraW5nIGdyb3VwIGNoYXJ0ZXI6XHJcbioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKipcclxuV29ya2luZyBncm91cCBuYW1lOiBcclxuXHJcbiAg ICAgIERlbGF5L0Rpc3J1cHRpb24gVG9sZXJhbnQgTmV0d29ya2luZyBXb3JraW5nIEdyb3VwIChE VE5XRylcclxuXHJcbkNoYWlyKHMpOlxyXG5cclxuICAgICAgVEJEXHJcblxyXG5BcmVhIGFuZCBB cmVhIERpcmVjdG9yKHMpOlxyXG5cclxuICAgICAgVHJhbnNwb3J0IEFyZWE6IEFEcyBTcGVuY2Vy IERhd2tpbnMgX3NwZW5jZXJkYXdraW5zLmlldGYgYXQgZ21haWwuY29tXyxcclxuICAgICAgICAg ICAgICAgICAgICAgICAgICBNYXJ0aW4gU3RpZW1lcmxpbmcgX21scy5pZXRmIGF0IGdtYWlsLmNv bV9cclxuXHJcblJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3I6XHJcblxyXG4gICAgICBUQkRcclxu XHJcbk1haWxpbmcgbGlzdDpcclxuXHJcbiAgICAgIEdlbmVyYWwgRGlzY3Vzc2lvbjogZHRuIGF0 IGlldGYub3JnXHJcbiAgICAgIFRvIFN1YnNjcmliZTogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9kdG5cclxuICAgICAgQXJjaGl2ZTogaHR0cDovL3d3dy5pZXRmLm9yZy9t YWlsLWFyY2hpdmUvd2ViL2R0bi9jdXJyZW50L21haWxsaXN0Lmh0bWxcclxuXHJcbkRlc2NyaXB0 aW9uIG9mIFdvcmtpbmcgR3JvdXA6XHJcblxyXG4gICAgICBUaGUgRGVsYXkvRGlzcnVwdGlvbiBU b2xlcmFudCBOZXR3b3JrIFdvcmtpbmcgR3JvdXAgKERUTldHKSBzcGVjaWZpZXNcclxuICAgICAg bWVjaGFuaXNtcyBmb3IgZGF0YSBjb21tdW5pY2F0aW9ucyBpbiB0aGUgcHJlc2VuY2Ugb2YgbG9u ZyBkZWxheXNcclxuICAgICAgYW5kL29yIGludGVybWl0dGVudCBjb25uZWN0aXZpdHkuIFRoZSB3 b3JrIGlzIG1vdGl2YXRlZCBieSB3ZWxsIGtub3duXHJcbiAgICAgIGxpbWl0YXRpb25zIG9mIHN0 YW5kYXJkIEludGVybmV0IHByb3RvY29scyB0aGF0IGV4cGVjdCBlbmQtdG8tZW5kXHJcbiAgICAg IGNvbm5lY3Rpdml0eSBiZXR3ZWVuIGNvbW11bmljYXRpbmcgZW5kcG9pbnRzLCBzdWItc2Vjb25k IHRyYW5zbWlzc2lvblxyXG4gICAgICBkZWxheXMgYW5kIHJvYnVzdCBwYWNrZXQgZGVsaXZlcnkg cmF0aW9zLiBJbiBlbnZpcm9ubWVudHMgd2hlcmUgdGhlc2VcclxuICAgICAgZmF2b3JhYmxlIGNv bmRpdGlvbnMgZG8gbm90IGFwcGx5LCBleGlzdGluZyBtZWNoYW5pc21zIHN1Y2ggYXMgcmVsaWFi bGVcclxuICAgICAgdHJhbnNwb3J0IHByb3RvY29scyBhbmQgcm91dGluZyBwcm90b2NvbHMgY2Fu IGZhaWwgdG8gY29udmVyZ2UgcmVzdWx0aW5nXHJcbiAgICAgIGluIGNvbW11bmljYXRpb24gZmFp bHVyZXMuIEZ1cnRoZXJtb3JlLCBjbGFzc2ljYWwgZW5kLXRvLWVuZCBzZWN1cml0eVxyXG4gICAg ICBhc3NvY2lhdGlvbnMgY2Fubm90IGJlIGNvb3JkaW5hdGVkIHdoZW4gY29tbXVuaWNhdGluZyBl bmRwb2ludHMgY2Fubm90XHJcbiAgICAgIGNvbmR1Y3QgbXVsdGktbWVzc2FnZSBrZXlpbmcgZXhj aGFuZ2VzIGluIGEgdGltZWx5IGZhc2hpb24uIFRoZXNlXHJcbiAgICAgIGxpbWl0YXRpb25zIHN1 Z2dlc3QgdGhlIG5lZWQgZm9yIGEgbmV3IGFwcHJvYWNoLiBcclxuICAgICAgXHJcbiAgICAgIERl bGF5LVRvbGVyYW50IE5ldHdvcmtpbmcgKERUTikgcHJvdG9jb2xzIGhhdmUgYmVlbiB0aGUgc3Vi amVjdCBvZlxyXG4gICAgICBleHRlbnNpdmUgcmVzZWFyY2ggYW5kIGRldmVsb3BtZW50IGluIHRo ZSBEZWxheS1Ub2xlcmFudCBOZXR3b3JraW5nXHJcbiAgICAgIFJlc2VhcmNoIEdyb3VwIG9mIHRo ZSBJbnRlcm5ldCBSZXNlYXJjaCBUYXNrIEZvcmNlIHNpbmNlIDIwMDIuICBJblxyXG4gICAgICBw YXJ0aWN1bGFyLCB0aGUgRFROIEJ1bmRsZSBQcm90b2NvbCAoUkZDIDUwNTApIGFuZCBMaWNrbGlk ZXJcclxuICAgICAgVHJhbnNtaXNzaW9uIFByb3RvY29sIChSRkMgNTMyNikgaGF2ZSBiZWVuIHNo b3duIHRvIGFkZHJlc3MgdGhlXHJcbiAgICAgIGlzc3VlcyBpZGVudGlmaWVkIGFib3ZlIGluIHN1 YnN0YW50aWFsIGZpZWxkZWQgZGVwbG95bWVudHMgWzFdLlxyXG5cclxuICAgICAgVGhlIHN1Y2Nl c3Mgb2YgdGhlIEJQL0xUUCBwcm90b2NvbCBzdGFjayAtLSB0aGUgY29yZSBwcm90b2NvbHMgb2Yg dGhlXHJcbiAgICAgICJEVE4gQXJjaGl0ZWN0dXJlIiBvcmlnaW5hbGx5IGRlc2NyaWJlZCBpbiBS RkMgNDgzOCAtLSBtYXkgYmUgYXR0cmlidXRlZFxyXG4gICAgICB0byB0aGUgZm9sbG93aW5nIGZ1 bmRhbWVudGFsIGRlc2lnbiBwcmluY2lwbGVzOlxyXG5cclxuXHQtIFRoZXJlIGlzIG5ldmVyIGFu eSBleHBlY3RhdGlvbiBvZiBjb250ZW1wb3JhbmVvdXMgZW5kLXRvLWVuZFxyXG4gICAgICAgICAg Y29ubmVjdGl2aXR5IGJldHdlZW4gYW55IHR3byBuZXR3b3JrIG5vZGVzLlxyXG5cclxuXHQtIEJl Y2F1c2UgZW5kLXRvLWVuZCBjb25uZWN0aXZpdHkgY2FuIG5ldmVyIGJlIGFzc3VtZWQsIGVhY2gg bm9kZVxyXG5cdCAgb24gdGhlIHBhdGggYmV0d2VlbiBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uIG11 c3QgYmUgcHJlcGFyZWQgdG9cclxuXHQgIGhhbmRsZSBpbmNvbWluZyAiYnVuZGxlcyIgb2YgZGF0 YSB0aGF0IGNhbm5vdCBpbW1lZGlhdGVseSBiZVxyXG5cdCAgZm9yd2FyZGVkLlxyXG5cclxuXHQt IEFnYWluIGJlY2F1c2UgZW5kLXRvLWVuZCBjb25uZWN0aXZpdHkgY2FuIG5ldmVyIGJlIGFzc3Vt ZWQsXHJcblx0ICBlbmQtdG8tZW5kIGNvbnZlcnNhdGlvbmFsIGRhdGEgZXhjaGFuZ2UgY2FuIG5l dmVyIGJlIGFzc3VtZWQgdG9cclxuXHQgIGNvbXBsZXRlIGluIGEgdGltZWx5IG1hbm5lcjsgcHJv dG9jb2wgZmVhdHVyZXMgdGhhdCByZWx5IG9uXHJcblx0ICB0aW1lbHkgY29udmVyc2F0aW9uYWwg ZGF0YSBleGNoYW5nZSBtdXN0IGJlIGV4Y2x1ZGVkIGZyb20gdGhlXHJcblx0ICBhcmNoaXRlY3R1 cmUuXHJcblxyXG4gICAgICBUaGUgRFROV0cgYmVsaWV2ZXMgdGhhdCBwcm90b2NvbHMgYWRoZXJp bmcgdG8gdGhlc2UgcHJpbmNpcGxlcyBvZmZlclxyXG4gICAgICBvcHBvcnR1bml0aWVzIGZvciBl bmhhbmNpbmcgdGhlIGZ1bmN0aW9uYWxpdHkgb2YgdGhlIEludGVybmV0IC0gaW5cclxuICAgICAg cGFydGljdWxhciwgZm9yIGZhY2lsaXRhdGluZyB0aGUgZXh0ZW5zaW9uIG9mIHRoZSBJbnRlcm5l dCBpbnRvXHJcbiAgICAgIGVudmlyb25tZW50cyBzdWNoIGFzIHRoZSBvY2VhbiBmbG9vciBhbmQg ZGVlcCBzcGFjZSBpbiB3aGljaCB0aGUgY29yZVxyXG4gICAgICBJbnRlcm5ldCBwcm90b2NvbHMg b3BlcmF0ZSBzdWItb3B0aW1hbGx5IGZvciB0aGUgcmVhc29ucyBkaXNjdXNzZWRcclxuICAgICAg ZWFybGllci4gIFdlIGJlbGlldmUgdGhhdCB0aGUgZXh0ZW5zaXZlIHJlc2VhcmNoLCBkZW1vbnN0 cmF0aW9uLCBhbmRcclxuICAgICAgcGlsb3Qgb3BlcmF0aW9ucyBwZXJmb3JtZWQgdG8gZGF0ZSB1 c2luZyB0aGUgRFROUkcgcHJvdG9jb2xzIHByb3ZpZGVzXHJcbiAgICAgIGEgZmlybSBiYXNpcyBm b3IgcHVibGlzaGluZyBJbnRlcm5ldCBzdGFuZGFyZHMgZGVyaXZlZCBmcm9tIHRoYXQgd29yay5c clxuXHJcbiAgICAgIFdvcmsgaXRlbXMgcmVsYXRlZCB0byBEZWxheS9EaXNydXB0aW9uIFRvbGVy YW50IE5ldHdvcmtpbmcgaW5jbHVkZTpcclxuXHJcbiAgICAgIG8gQSBtZWNoYW5pc20gZm9yIHRo ZSBleGNoYW5nZSBvZiBwcm90b2NvbCBkYXRhIHVuaXRzLCB0ZXJtZWRcclxuXHQiYnVuZGxlcyIs IHRoYXQgYXJlIGRlc2lnbmVkIHRvIG9idmlhdGUgY29udmVyc2F0aW9uYWwgY29tbXVuaWNhdGlv bnNcclxuXHRieSBjb250YWluaW5nIHZhbHVlcyBmb3IgYWxsIHBvdGVudGlhbGx5IHJlbGV2YW50 IGNvbmZpZ3VyYXRpb25cclxuXHRwYXJhbWV0ZXJzLiAgVGhlc2UgcHJvdG9jb2wgZGF0YSB1bml0 cyBhcmUgdHlwaWNhbGx5IGxhcmdlciB0aGFuXHJcblx0bmV0d29yay1sYXllciBwYWNrZXRzLiBX ZSB3aWxsIGRlcml2ZSB0aGlzIGJ1bmRsZSBleGNoYW5nZSBtZWNoYW5pc21cclxuICAgICAgICBm cm9tIHRoZSBEVE4gQnVuZGxlIFByb3RvY29sIChCUCkgZG9jdW1lbnRlZCBpbiBSRkMgNTA1MCBi eSBwdWJsaXNoaW5nXHJcbiAgICAgICAgYSBuZXcgZG9jdW1lbnQgZm9yIHdoaWNoIFsyXSBpcyBh IHByb3Bvc2VkIGZpcnN0IGRyYWZ0ICh3aGVyZVxyXG4gICAgICAgIGFwcGVuZGl4IEEgcHJvdmlk ZXMgYSBzdW1tYXJ5IG9mIHRoZSBwcm9wb3NlZCBjaGFuZ2VzKS5cclxuXHJcbiAgICAgIG8gQSBz ZWN1cml0eSBwcm90b2NvbCBmb3IgZW5zdXJpbmcgdGhhdCB0aGUgbmV0d29yayBpbiB3aGljaCBi dW5kbGVzXHJcblx0YXJlIGV4Y2hhbmdlZCBpcyBzZWN1cmVkIGFnYWluc3QgdW5hdXRob3JpemVk IGFjY2VzcyBhbmQgZGVuaWFsIG9mXHJcblx0c2VydmljZSBhdHRhY2tzLCBhbmQgdG8gZW5zdXJl IGRhdGEgaW50ZWdyaXR5IGFuZCBjb25maWRlbnRpYWxpdHlcclxuXHRpbiB0aGF0IG5ldHdvcmsg d2hlcmUgbmVjZXNzYXJ5LiAgV2Ugd2lsbCBkZXJpdmUgdGhpcyBzZWN1cml0eVxyXG5cdHByb3Rv Y29sIGZyb20gYSAic3RyZWFtbGluZWQiIGFkYXB0YXRpb24gb2YgdGhlIERUTiBCdW5kbGUgU2Vj dXJpdHlcclxuXHRQcm90b2NvbCBkb2N1bWVudGVkIGluIFJGQyA2MjU3LlxyXG5cclxuICAgICAg byBBbiBlbmNhcHN1bGF0aW9uIHByb3RvY29sIGZvciAidHVubmVsaW5nIiBCUCB0cmFmZmljIHdp dGhpbiBidW5kbGVzXHJcblx0dGhhdCBhcmUgc2VjdXJlZCBhbmQvb3Igcm91dGVkIGluIGRpZmZl cmVudCB3YXkgZnJvbSB0aGUgZW5jYXBzdWxhdGVkXHJcblx0YnVuZGxlcy5cclxuXHJcbiAgICAg IG8gQSBkZWxheS10b2xlcmFudCBzZWN1cml0eSBrZXkgbWFuYWdlbWVudCBzY2hlbWUgZm9yIGVu c3VyaW5nIHRoYXRcclxuXHRwdWJsaWMga2V5cyBhcmUgY2VydGlmaWVkIGJ5IGEgZ2xvYmFsbHkg dHJ1c3RlZCBhdXRob3JpdHkgdG8gcHJvdGVjdFxyXG5cdHRoZSBpbnRlZ3JpdHkgb2YgdGhlIGlu ZnJhc3RydWN0dXJlLlxyXG5cclxuICAgICAgbyBBIHNpbXBsZSBkYXRhZ3JhbSBjb252ZXJnZW5j ZSBsYXllciBwcm90b2NvbCBmb3IgYWRhcHRhdGlvbiBvZiB0aGVcclxuICAgICAgICBidW5kbGUg cHJvdG9jb2wgdG8gdW5kZXJseWluZyBpbnRlcm5ldHdvcmtzLiBXZSBleHBlY3QgdG8gZGVyaXZl XHJcbiAgICAgICAgdGhpcyBjb252ZXJnZW5jZSBsYXllciBwcm90b2NvbCBmcm9tIHRoZSBEYXRh Z3JhbSBDb252ZXJnZW5jZVxyXG4gICAgICAgIHByb3RvY29sIGRvY3VtZW50ZWQgaW4gUkZDIDcx MjIuXHJcblxyXG4gICAgICBvIEEgZGVsYXktdG9sZXJhbnQgbmV0d29yayBtYW5hZ2VtZW50IHBy b3RvY29sIGZvciBtYW5hZ2VtZW50IG9mIHRoZVxyXG4gICAgICAgIGluZnJhc3RydWN0dXJlIGlu IHRoZSBwcmVzZW5jZSBvZiBsb25nIGRlbGF5cyBhbmQvb3IgaW50ZXJtaXR0ZW50XHJcbiAgICAg ICAgY29ubmVjdGl2aXR5LlxyXG5cclxuICAgICAgbyBBIHJlZ2lzdHJ5IGZvciBEVE4gU2Vydmlj ZSBJZGVudGlmaWVyc1xyXG4gIFxyXG4gICAgVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBjb25zaWRl ciBleHRlbmRpbmcgdGhlIGN1cnJlbnQgbWlsZXN0b25lcyBiYXNlZCBvblxyXG4gICAgbmV3IGlu Zm9ybWF0aW9uIGFuZCBrbm93bGVkZ2UgZ2FpbmVkIHdoaWxlIHdvcmtpbmcgb24gdGhlIGluaXRp YWwgY2hhcnRlcixcclxuICAgIGFzIHdlbGwgYXMgdG8gYWNjb21tb2RhdGUgbmV3IHdvcmsgaXRl bXMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGUgaW5pdGlhbFxyXG4gICAgcGhhc2UuICBGb3IgZXhh bXBsZSwgd2UgZXhwZWN0IHRoYXQgdHJhbnNwb3J0IHByb3RvY29scyBzdWNoIGFzIExUUCBhbmRc clxuICAgIHRoZSBTYXJhdG9nYSBwcm90b2NvbCBhcmUgYW1vbmcgdGhlIGNhbmRpZGF0ZXMgZm9y IHdvcmsgaW4gdGhpcyBwaGFzZS5cclxuICAgIFxyXG5Hb2FscyBhbmQgTWlsZXN0b25lczpcclxu ICBzdGFydCszbW9zIC0gU3VibWl0IFwnQnVuZGxlIFByb3RvY29sIFNwZWNpZmljYXRpb24gKFJG QzUwNTBiaXMpXCcgYXMgYVxyXG4gICAgICAgICAgICAgICB3b3JraW5nIGdyb3VwIGRvY3VtZW50 IFsyXS4gVG8gYmUgUHJvcG9zZWQgU3RhbmRhcmQuXHJcbiAgU3RhcnQrM21vcyAtIFN1Ym1pdCBc J1N0cmVhbWxpbmVkIEJ1bmRsZSBTZWN1cml0eSBQcm90b2NvbCAoU0JTUClcJyBhcyBhXHJcbiAg ICAgICAgICAgICAgIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQgWzNdLiBUbyBiZSBQcm9wb3NlZCBT dGFuZGFyZC5cclxuICBzdGFydCs2bW9zIC0gU3VibWl0IFwnQnVuZGxlIEluIEJ1bmRsZSBFbmNh cHN1bGF0aW9uIChCSUJFKVwnIGFzIGEgd29ya2luZ1xyXG4gICAgICAgICAgICAgICBncm91cCBk b2N1bWVudCBbNF0uIFRvIGJlIFByb3Bvc2VkIFN0YW5kYXJkLlxyXG4gIHN0YXJ0KzEybW9zIC0g U3VibWl0IFwnRGVsYXkgVG9sZXJhbnQgTmV0d29ya2luZyBTZWN1cml0eSBLZXkgTWFuYWdlbWVu dFwnIGFzXHJcbiAgICAgICAgICAgICAgICBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuIFRvIGJl IFByb3Bvc2VkIFN0YW5kYXJkLlxyXG4gIHN0YXJ0KzE4bW9zIC0gV0cgZGV0ZXJtaW5hdGlvbiBm b3IgbWVyZ2luZyBSRkM1MDUwYmlzLCBTQlNQLCBCSUJFIGFuZC9vclxyXG4gICAgICAgICAgICAg ICAgS2V5IE1nbXQgaW50byBhIGNvbWJpbmVkIGRyYWZ0IG9yIGtlZXAgYXMgc2VwYXJhdGUgZHJh ZnRzLlxyXG4gIHN0YXJ0KzE4bW9zIC0gU3VibWl0IFJGQzUwNTBiaXMsIFNCU1AsIEJJQkUgYW5k IEtleSBNZ210IHRvIHRoZSBJRVNHIGVpdGhlclxyXG4gICAgICAgICAgICAgICAgYXMgYSBjb21i aW5lZCBkcmFmdCBvciBhcyBzZXBhcmF0ZSBkcmFmdHMuXHJcbiAgc3RhcnQrMThtb3MgLSBTdWJt aXQgTmV0d29yayBNYW5hZ2VtZW50IFs1XSwgUmVnaXN0cnkgWzZdIGFuZCBTaW1wbGVcclxuICAg ICAgICAgICAgICAgIENvbnZlcmdlbmNlIExheWVyIFs3XSBhcyB3b3JraW5nIGdyb3VwIGRvY3Vt ZW50cy5cclxuICBzdGFydCsyMG1vcyAtIFN1cnZleSBhcHByb3ByaWF0ZSBmb3J1bXMgKGUuZy4s IERUTlJHKSBmb3IgZW1lcmdpbmdcclxuICAgICAgICAgICAgICAgIHRlY2hub2xvZ2llcyAoZS5n LiwgY29udmVyZ2VuY2UgbGF5ZXIgcHJvdG9jb2xzLCBkeW5hbWljXHJcbiAgICAgICAgICAgICAg ICByb3V0aW5nIHByb3RvY29scywgbmFtaW5nIGFuZCBhZGRyZXNzaW5nIHNlcnZpY2VzLCBldGMu KVxyXG4gICAgICAgICAgICAgICAgcmVhZHkgZm9yIHRyYW5zaXRpb24gaW50byBJRVRGIERUTiBX b3JraW5nIEdyb3VwLiBQdWJsaXNoXHJcbiAgICAgICAgICAgICAgICBkcmFmdCBvbiBzdXJ2ZXkg cmVzdWx0cyBhcyBpbmRlcGVuZGVudCBzdWJtaXNzaW9uIHJlbGF0ZWRcclxuICAgICAgICAgICAg ICAgIHRvIHRoZSBXRy5cclxuICBzdGFydCsyNG1vcyAtIFN1Ym1pdCBOZXR3b3JrIE1hbmFnZW1l bnQsIFJlZ2lzdHJ5IGFuZCBTaW1wbGUgQ29udmVyZ2VuY2VcclxuICAgICAgICAgICAgICAgIExh eWVyIHRvIElFU0dcclxuICBzdGFydCsyNG1vcyAtIFJlY2hhcnRlciB0byBhY2NvbW1vZGF0ZSBu ZXcgd29yayBpdGVtcyBvciBjbG9zZSBXb3JraW5nIEdyb3VwXHJcblxyXG5cclxuWzFdICJCUC9M VFAgZGVwbG95bWVudCBvbiBFUE9YSSBzcGFjZWNyYWZ0IiBbMjAwOF0sXHJcbiAgICBodHRwOi8v Y29tbWl0dGVlcy5jb21zb2Mub3JnL3RjY2MvY2N3LzIwMTAvc2xpZGVzL0RJTkVUX0NDVy5wZGYg IFxyXG5bMl0gIlByb3Bvc2VkIFJldmlzZWQgQnVuZGxlIFByb3RvY29sIiBbMjAxNF0sXHJcbiAg ICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1idXJsZWlnaC1icHY3L1xy XG5bM10gIlN0cmVhbWxpbmVkIEJ1bmRsZSBTZWN1cml0eSBQcm90b2NvbCBTcGVjaWZpY2F0aW9u IiBbMjAxNF0sXHJcbiAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p cnRmLWR0bnJnLXNic3AvXHJcbls0XSAiQnVuZGxlLWluLUJ1bmRsZSBFbmNhcHN1bGF0aW9uIiBb MjAxM10sXHJcbiAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtaXJ0Zi1idXJsZWln aC1iaWJlXHJcbls1XSAiRGVsYXkgVG9sZXJhbnQgTmV0d29yayBNYW5hZ2VtZW50IFByb3RvY29s IiBbMjAxM10sXHJcbiAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtaXJ0Zi1kdG5y Zy1kdG5tcFxyXG5bNl0gIkRlbGF5LVRvbGVyYW50IE5ldHdvcmtpbmcgQnVuZGxlIFByb3RvY29s IElBTkEgUmVnaXN0cmllcyIgWzIwMTFdLFxyXG4gICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvcmZjNjI1NS9cclxuWzddICJEYXRhZ3JhbSBDb252ZXJnZW5jZSBMYXllcnMgLi4u IiBbMjAxNF0sXHJcbiAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9yZmM3MTIy L1xyXG4nLCAndXJsMSc6ICcnLCAnc3VibWl0JzogJ0dlbmVyYXRlIGRpZmYnLCAndXJsMic6ICcn LCAnLS1uZXdjb2xvdXInOiAnZ3JlZW4nfSAtLT4= --_002_2134F8430051B64F815C691A62D983183048B287XCHBLV512nwnosb_-- From nobody Thu Jun 12 11:49:18 2014 Return-Path: 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 992281B27C5 for ; Thu, 12 Jun 2014 11:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 8XSp4ncODlLV for ; Thu, 12 Jun 2014 11:49:05 -0700 (PDT) Received: from mail.ibr.cs.tu-bs.de (mail.ibr.cs.tu-bs.de [134.169.34.52]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E0C01B2799 for ; Thu, 12 Jun 2014 11:49:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.ibr.cs.tu-bs.de (Postfix) with ESMTP id 4C585182F0C; Thu, 12 Jun 2014 20:49:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ibr.cs.tu-bs.de; h=x-mailer:references:message-id:content-transfer-encoding:date :date:in-reply-to:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=key1; t= 1402598942; x=1404413343; bh=1y0SN8hRce1D/vTd2ka1YDUi/MqWtK1vTqb AjX18dcc=; b=jCIUYMgzvzWWb7kF54cy4HFoE96jy+BRnnJ0bTuTJnsk0hxpw4Z YL9tn9Kq2Y8Alq4gvFzuCszYGbPPSUyT8MM3zL/9DGNiyEfppUoU+jLkuIJgDZFo /BIXR0mCrJe79AgGKz23ZLek34wgW8dpY7ae963FFhiKK+xnBk4EHzzA= X-Virus-Scanned: Debian amavisd-new at ibr.cs.tu-bs.de Received: from mail.ibr.cs.tu-bs.de ([127.0.0.1]) by localhost (mail.ibr.cs.tu-bs.de [127.0.0.1]) (amavisd-new, port 10026) with LMTP id JBDFffqSqkia; Thu, 12 Jun 2014 20:49:02 +0200 (CEST) Received: from [IPv6:2001:6f8:900:8d3d:bd4b:c86:1d38:c339] (unknown [IPv6:2001:6f8:900:8d3d:bd4b:c86:1d38:c339]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schildt@ibr.cs.tu-bs.de) by mail.ibr.cs.tu-bs.de (Postfix) with ESMTPSA id 13B28182BA5; Thu, 12 Jun 2014 20:49:01 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Sebastian Schildt In-Reply-To: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> Date: Thu, 12 Jun 2014 20:49:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/itZtgg1fogk27hifOyAOfB-mhIc Cc: "dtn@ietf.org" Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 18:49:13 -0000 Hi On 12 Jun 2014, at 20:34, Templin, Fred L = wrote: > Hello, >=20 > There were some additional off-list updates to the charter > emerging as Martin was calling for charter discussion. Please > see below for the revised version (diffs attached) and use this > as basis for further discussion. (Sebastian and others - please > post any follow-ups to this thread.) >=20 Ok. So far so good. Referring to the previous thread I would just take = you up on the offer to replace this=20 >=20 >=20 > o A delay-tolerant security key management scheme for ensuring = that > public keys are certified by a globally trusted authority to = protect > the integrity of the infrastructure. >=20 with that=20 On 12 Jun 2014, at 20:25, Templin, Fred L = wrote: >=20 > I don't mind taking a slightly revised version of your proposed = bullet: >=20 > o A delay-tolerant security key management scheme that can protect > the integrity of a DTN network. Apart from that I am not sure what is meant by: >=20 > o A delay-tolerant network management protocol for management of = the > infrastructure in the presence of long delays and/or = intermittent > connectivity. DT-SNMP? Maybe the stakeholders in this could add/suggest a sentence to = clarify what =84network management=93 means in this case? MfG Sebastian From nobody Thu Jun 12 12:46:47 2014 Return-Path: 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 C934E1A0289 for ; Thu, 12 Jun 2014 12:46:45 -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 Ye0p53GYYdKK for ; Thu, 12 Jun 2014 12:46:43 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63DF11A025A for ; Thu, 12 Jun 2014 12:46:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s5CJkg13017912; Thu, 12 Jun 2014 14:46:42 -0500 Received: from XCH-PHX-504.sw.nos.boeing.com (xch-phx-504.sw.nos.boeing.com [137.136.239.59]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s5CJkV7I017280 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 12 Jun 2014 14:46:33 -0500 Received: from XCH-BLV-512.nw.nos.boeing.com ([169.254.12.74]) by XCH-PHX-504.sw.nos.boeing.com ([169.254.5.96]) with mapi id 14.03.0181.006; Thu, 12 Jun 2014 12:46:31 -0700 From: "Templin, Fred L" To: Sebastian Schildt Thread-Topic: [dtn] Draft Charter Discussion Thread-Index: Ac+GbO3wN7xIp4CqSFeVEjvJc65+vAAPLd8AAAy+SjA= Date: Thu, 12 Jun 2014 19:46:31 +0000 Message-ID: <2134F8430051B64F815C691A62D983183048B3B6@XCH-BLV-512.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> In-Reply-To: <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> 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/N_-XnYMHjBf0mWaQ219kLrQuYhI Cc: "dtn@ietf.org" Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 19:46:45 -0000 Hi Sebastian, > -----Original Message----- > From: Sebastian Schildt [mailto:schildt@ibr.cs.tu-bs.de] > Sent: Thursday, June 12, 2014 11:49 AM > To: Templin, Fred L > Cc: dtn@ietf.org > Subject: Re: [dtn] Draft Charter Discussion >=20 > Hi >=20 > On 12 Jun 2014, at 20:34, Templin, Fred L wro= te: >=20 > > Hello, > > > > There were some additional off-list updates to the charter > > emerging as Martin was calling for charter discussion. Please > > see below for the revised version (diffs attached) and use this > > as basis for further discussion. (Sebastian and others - please > > post any follow-ups to this thread.) > > >=20 > Ok. So far so good. Referring to the previous thread I would just take yo= u up on the offer to replace > this > > > > > > o A delay-tolerant security key management scheme for ensuring tha= t > > public keys are certified by a globally trusted authority to protect > > the integrity of the infrastructure. > > >=20 > with that >=20 > On 12 Jun 2014, at 20:25, Templin, Fred L wro= te: >=20 > > > > I don't mind taking a slightly revised version of your proposed bullet: > > > > o A delay-tolerant security key management scheme that can protect > > the integrity of a DTN network. OK - this will be fixed in the next update. > Apart from that I am not sure what is meant by: > > > > o A delay-tolerant network management protocol for management of t= he > > infrastructure in the presence of long delays and/or intermitten= t > > connectivity. >=20 > DT-SNMP? Maybe the stakeholders in this could add/suggest a sentence to = clarify what "network > management" means in this case? Can someone with interest in DTN network management address this point? Thanks - Fred fred.l.templin@boeing.com =20 > MfG >=20 > Sebastian From nobody Thu Jun 12 16:55:56 2014 Return-Path: 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 5C3881A02FA for ; Thu, 12 Jun 2014 16:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Bqi3QkzBQ_Rk for ; Thu, 12 Jun 2014 16:55:51 -0700 (PDT) Received: from b.b.painless.aa.net.uk (b.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA4A41A02EF for ; Thu, 12 Jun 2014 16:55:50 -0700 (PDT) Received: from mightyatom.folly.org.uk ([81.187.254.250]) by b.painless.aa.net.uk with esmtp (Exim 4.72) (envelope-from ) id 1WvEqL-0005x4-DQ; Fri, 13 Jun 2014 00:55:44 +0100 From: Elwyn Davies To: "Templin, Fred L" In-Reply-To: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> Content-Type: text/plain Organization: Folly Consulting Date: Fri, 13 Jun 2014 00:55:40 +0100 Message-Id: <1402617340.2995.817.camel@mightyatom> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/gi3Kem8e9CVRHP0ecZMW1Y86ngc Cc: "dtn@ietf.org" Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 23:55:54 -0000 Hi. Looking at the milestones and timescales... I am still not totally convinced by the timescales which I think are somewhat optimistic (i'll take out the 'wildly' which I used previously). However before we get onto the nitty gritty of milestone dates, I think there are some wording and scheduling issues to sort out: There are several entries such as start+3mos - Submit 'Bundle Protocol Specification (RFC5050bis)' as a working group document [2]. To be Proposed Standard. I think this means 'Accept "" [n] as working group work item intended for . However I suspect that putting these in as milestones is maybe not a good idea. Presumably what we should be doing is initially making up our collective mind on the changes that should be done (c.f., Martin S's comment). Certainly for the BPbis work, depending on the outcome of this discussion, either the prototype individual drafts may or may not be the right basis for the ongoing work based on the results. I'd be inclined to go for a milestone at 6-9 months on getting concensus on changes to be implemented in the existing RFC 5050. On the SBSP I'd probably go for accepting it as a WG work item on day 1 since this is effectively new work. For the items that become WG work items later: What do we expect people to be doing with these in the interim? Can't we just make them WG items immediately, assuming that we agree we want to do them? This next pair doesn't seem to be practical: start+18mos - WG determination for merging RFC5050bis, SBSP, BIBE and/or Key Mgmt into a combined draft or keep as separate drafts. start+18mos - Submit RFC5050bis, SBSP, BIBE and Key Mgmt to the IESG either as a combined draft or as separate drafts. Prior to this point, the charter sort of assumes that there will be separate drafts. Assuming that the decision alters this to a combined draft at this late stage in development, switching will a.s. take an immense amount of work in zero elapsed time and I wouldn't like to guarantee the quality of the result. I *really* think we have to make a decision much earlier (about the time we agree what changes are needed) and live with it. Returning to the amount of time needed, I am extremely sceptical that we can cut and polish something like six RFCs in just over 18 months even given the running start we have. This is partly because I don't know if any of the expected participants have some dedicated person power at your disposal to work on the specifications. I'd expect that we would need 2 years and even then I'd not bet too heavily on getting there in time. As regards Martin S's feedback from the IESG discussion: - *Please* let's not go back into the conclusions of the architecture in the WG. Let's settle that before the BoF if we need to, report there and have an end of it. I suspect that if we did reopen the architecture in a major way, quite a lot of people would walk away: Opinions? - There are some fairly major items that are at least partially architectural that we do have to sort out, not least the timestamps in bundles and the effects on nodes. I suggested a tactical way fowards on that above. We probably ought to start a separate thread on BP changes, starting with a listing of what has changed in BPv7. - Other protocols: + I already mentioned the CGR support - something like the proposed CPUP - and put it in the charter update. + Similarly the discovery protocol. + Taking LTP to Proposed Standard ... does this need much work? Have those who are using it found much in the way of holes/improvements? + Other IP based convergence layer protocols (update of the TCP CL which I think is very important). + Multicast/Anycast and content distribution. Whether non-singleton EIDs are actually useful. + Opportunistic routing scheme(s). Of these protocols, the first two are now in the charter and are fairly lightweight. Having a standardized LTP would complete the space story as it is currently used. There is a CCSDS LTP draft (http://public.ccsds.org/sites/cwe/rids/Lists/CCSDS% 207341R2/NASAUSOverview.aspx). I believe the TCP CL needs a bit of a rethink (mainly to provide parallel channels and some additional fragmentation support) but isn't essential to the space sector unless they would really like it for the ground segment. The opportunistic routing protocol is really a white space at the moment. On Thu, 2014-06-12 at 18:34 +0000, Templin, Fred L wrote: > Hello, > > There were some additional off-list updates to the charter > emerging as Martin was calling for charter discussion. Please > see below for the revised version (diffs attached) and use this > as basis for further discussion. (Sebastian and others - please > post any follow-ups to this thread.) > > Fred > > --- > > Draft working group charter: > **************************** > Working group name: > > Delay/Disruption Tolerant Networking Working Group (DTNWG) > > Chair(s): > > TBD > > Area and Area Director(s): > > Transport Area: ADs Spencer Dawkins , > Martin Stiemerling > > Responsible Area Director: > > TBD > > Mailing list: > > General Discussion: dtn at ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/dtn > Archive: http://www.ietf.org/mail-archive/web/dtn/current/maillist.html > > Description of Working Group: > > The Delay/Disruption Tolerant Network Working Group (DTNWG) specifies > mechanisms for data communications in the presence of long delays > and/or intermittent connectivity. The work is motivated by well known > limitations of standard Internet protocols that expect end-to-end > connectivity between communicating endpoints, sub-second transmission > delays and robust packet delivery ratios. In environments where these > favorable conditions do not apply, existing mechanisms encounter problems > such as reliable transport protocol handshakes timing out and routing > protocols failing to converge resulting in communication failures. > Furthermore, classical end-to-end security associations cannot be > coordinated when communicating endpoints cannot conduct multi-message > keying exchanges in a timely fashion. These limitations suggested the > need for a new approach. > > Delay-Tolerant Networking (DTN) protocols have been the subject of > extensive research and development in the Delay-Tolerant Networking > Research Group (DTNRG) of the Internet Research Task Force since 2002. > The DTNRG has developed the Delay-Tolerant Networking Architecture > (RFC 4838) that the DTNWG uses as the basis for its work. The key > components of the this architecture are the bundle concept for > encapsulating data units, the bundle transmission protocol and the > underlying convergence layer architecture. > > The experimental DTN Bundle Protocol (RFC 5050) and Licklider > Transmission Protocol (RFC 5326) have been shown to address the > issues identified above in substantial fielded deployments in the space > sector [1]. RFC 5050 in conjunction with TCP- and UDP-based convergence > layers has been used successfully in a number of experiments both in > communications challenged environments around the edges of the Internet > and as an Internet overlay where applications require delay- and/or > disruption-tolerance [refs needed]. > > The success of the BP over convergence layer protocol stack -- the core > protocols of the "DTN Architecture" described in RFC 4838 -- may be > attributed to the following fundamental design principles: > > - There is never any expectation of contemporaneous end-to-end > connectivity between any two network nodes. > > - Because end-to-end connectivity can never be assumed, each node > on the path between source and destination must be prepared to > handle incoming "bundles" of data that cannot immediately be > forwarded. > > - Again because end-to-end connectivity can never be assumed, > end-to-end conversational data exchange can never be assumed to > complete in a timely manner; protocol features that rely on > timely conversational data exchange must be excluded from the > architecture. > > The DTNWG believes that protocols adhering to these principles offer > opportunities for enhancing the functionality of the Internet, including > > - facilitating the extension of the Internet into environments such as > the ocean floor and deep space in which the core Internet protocols > operate sub-optimally for the reasons discussed earlier; > > - extending the Internet into communications challenged terrestrial > environments where it is not possible to provide continuous, low > delay Internet connections; and > > - supporting Internet applications that need DTN capabiliies. > > We believe that the extensive research, demonstration, and > pilot operations performed to date using the DTNRG protocols provides > a firm basis for publishing Internet standards derived from that work. > > Work items related to Delay/Disruption Tolerant Networking include: > > o A mechanism for the exchange of protocol data units, termed > "bundles", that are designed to obviate conversational communications > by containing values for all potentially relevant configuration > parameters. These protocol data units are typically larger than > network-layer packets. We will derive this bundle exchange mechanism > from the DTN Bundle Protocol (BP) documented in RFC 5050 by publishing > a new document for which [2] is a proposed first draft (where > appendix A provides a summary of the proposed changes). > > o A security protocol for ensuring that the network in which bundles > are exchanged is secured against unauthorized access and denial of > service attacks, and to ensure data integrity and confidentiality > in that network where necessary. We will derive this security > protocol from a "streamlined" adaptation of the DTN Bundle Security > Protocol documented in RFC 6257. > > o A delay-tolerant security key management scheme for ensuring that > public keys are certified by a globally trusted authority to protect > the integrity of the infrastructure. > > o A simple datagram convergence layer protocol for adaptation of the > bundle protocol to underlying internetworks. We expect to derive > this convergence layer protocol from the Datagram Convergence > protocol documented in RFC 7122. > > o A delay-tolerant network management protocol for management of the > infrastructure in the presence of long delays and/or intermittent > connectivity. > > o A functional specification of Contact Graph Routing (CGR) specifying > the inputs (global contact schedules, traffic demands, etc.) and > outputs (node specific transmission and reception schedules, > notifications, etc.). CGR is a centralized, oracle-based bundle > transmission and reception scheduling scheme used in space segment > DTN deployments. > > o An adjunct to the management protocol that will allow the contact > schedules generated by CGR to be distributed to nodes. This may be > based on the Contact Plan Update Protocol (CPUP) proposed in > > o An encapsulation protocol for "tunneling" BP traffic within bundles > that are secured and/or routed in different way from the encapsulated > bundles. > > o A registry for DTN Service Identifiers > > The working group will consider extending the current milestones based on > new information and knowledge gained while working on the initial charter, > as well as to accommodate new work items beyond the scope of the initial > phase. For example, we expect that transport protocols such as LTP and > the Saratoga protocol are among the candidates for work in this phase. > > Goals and Milestones: > start+3mos - Submit 'Bundle Protocol Specification (RFC5050bis)' as a > working group document [2]. To be Proposed Standard. > Start+3mos - Submit 'Streamlined Bundle Security Protocol (SBSP)' as a > working group document [3]. To be Proposed Standard. > start+6mos - Submit 'Bundle In Bundle Encapsulation (BIBE)' as a working > group document [4]. To be Proposed Standard. > start+12mos - Submit 'CGR Functional Specification' as a working group > document. To be an informational document. > start+12mos - Submit 'Delay Tolerant Networking Security Key Management' as > a working group document. To be Proposed Standard. > start+15mos - Submit 'Contact Plan Update Protocol' as working group > document. To be Proposed Standaqqrd. > start+18mos - WG determination for merging RFC5050bis, SBSP, BIBE and/or > Key Mgmt into a combined draft or keep as separate drafts. > start+18mos - Submit RFC5050bis, SBSP, BIBE and Key Mgmt to the IESG either > as a combined draft or as separate drafts. > start+18mos - Submit Network Management [5], Registry [6] and Simple > Convergence Layer [7] as working group documents. > start+20mos - Survey appropriate forums (e.g., DTNRG) for emerging > technologies (e.g., convergence layer protocols, dynamic > routing protocols, naming and addressing services, etc.) > ready for transition into IETF DTN Working Group. Publish > draft on survey results as independent submission related > to the WG. > start+24mos - Submit Network Management, Registry and Simple Convergence > Layer to IESG > start+24mos - Recharter to accommodate new work items or close Working Group > > > [1] "BP/LTP deployment on EPOXI spacecraft" [2008], > http://committees.comsoc.org/tccc/ccw/2010/slides/DINET_CCW.pdf > [2] "Proposed Revised Bundle Protocol" [2014], > https://datatracker.ietf.org/doc/draft-burleigh-bpv7/ > [3] "Streamlined Bundle Security Protocol Specification" [2014], > https://datatracker.ietf.org/doc/draft-irtf-dtnrg-sbsp/ > [4] "Bundle-in-Bundle Encapsulation" [2013], > http://tools.ietf.org/id/draft-irtf-burleigh-bibe > [5] "Delay Tolerant Network Management Protocol" [2013], > http://tools.ietf.org/id/draft-irtf-dtnrg-dtnmp > [6] "Delay-Tolerant Networking Bundle Protocol IANA Registries" [2011], > https://datatracker.ietf.org/doc/rfc6255/ > [7] "Datagram Convergence Layers ..." [2014], > https://datatracker.ietf.org/doc/rfc7122/ > [8] "Towards Flexibility and Accuracy in Space DTN Communications", > Bezirgianndia et al, CHANTS 2012, > http://dl.acm.org/citation.cfm?id=2505499 [2012] > > > _______________________________________________ > dtn mailing list > dtn@ietf.org > https://www.ietf.org/mailman/listinfo/dtn From nobody Thu Jun 12 16:58:30 2014 Return-Path: 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 7B1141A02FA; Thu, 12 Jun 2014 16:58:21 -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 En0nYXAM6D-v; Thu, 12 Jun 2014 16:58:19 -0700 (PDT) Received: from mail.jpl.nasa.gov (sentrion3.jpl.nasa.gov [128.149.139.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0D0B1A02EF; Thu, 12 Jun 2014 16:58:19 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp01.jpl.nasa.gov [128.149.137.148]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s5CNwFcU017099 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Thu, 12 Jun 2014 16:58:16 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.217]) by ap-ehub-sp01.RES.AD.JPL ([169.254.3.182]) with mapi id 14.03.0174.001; Thu, 12 Jun 2014 16:58:15 -0700 From: "Burleigh, Scott C (312G)" To: "Templin, Fred L" , Elwyn Davies Thread-Topic: [dtn] DTN BoF Proposal for IETF90 Thread-Index: Ac+AQa9Fez/CplZaSwyaLFpzb8tj0wAiVZ0A///Hp/D//5OnYIABipvO//qPd7CAC7TeXf//SGxA//6DxzD/+y/3AP/2pkiA/+sxqZA= Date: Thu, 12 Jun 2014 23:58:15 +0000 Message-ID: References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> , <1401967219583.26821@surrey.ac.uk> , <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk> , <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> <1402389636710.92429@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830486EBE@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> <1402490970.2995.76.camel@mightyatom> <2134F8430051B64F815C691A62D983183048A030@XCH-BLV-512.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983183048A030@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: [128.149.137.113] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/MOr8v5a47FaKuZpxvd9x2BPDLxk Cc: "iesg@ietf.org" , "dtn@ietf.org" Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 23:58:21 -0000 This is the wrong venue for a technical deep dive on this topic, but becaus= e it bears on the charter I want to mention it: I have been thinking for so= me time that CGR -- operating on contact plans that are extended to include= not only scheduled contacts but also contacts that are predicted with less= than 100% confidence -- might be a general enough framework to hang opport= unistic routing on as well, leveraging huge chunks of the innovative routin= g practice that has already emerged in academic research. I'm happy to try to defend this modest proposal in another thread. For now= , I at least wanted to add a vote of optimism that a general solution to th= e problem of DTN routing might be possible and to agree that investigating = that possibility would be a worthwhile topic for the charter. Scott -----Original Message----- From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of Templin, Fred L Sent: Wednesday, June 11, 2014 8:57 AM To: Elwyn Davies Cc: iesg@ietf.org; dtn@ietf.org Subject: Re: [dtn] DTN BoF Proposal for IETF90 .... > The lack of clarity over intended usage could well have a bad impact=20 > on the WG if it results in disagreements over the specifications. It=20 > also shows up in what is *not* in the charter. most notably in the=20 > absence of any consideration of how to route the bundles that BPbis=20 > handles. IMO a DTN system that doen't address bundle routing is only hal= f-baked. The initial charter calls for a simple CL; it could also call for a simple = routing mechanism, e.g., CGR. > There seems to be a reasonable concensus that Contact Graph Routing > (CGR) would be appropriate for the space case. Now this is primarily=20 > a centralized all-informed oracle based system so there isn't the need=20 > to exchange advertisements and such like but it strikes me that there=20 > are aspects of a CGR that might need standardization such as=20 > disseminating contact and route information to remote nodes, notifying=20 > the oracle of traffic requests and ideas for handling failures such as=20 > notifying the oracle that things didn't work as intended. I therefore=20 > think that work on CGR should be part of the charter at least (I=20 > understood that CCSDS was thinking about it but that work seems to have s= talled). I think that is a reasonable suggestion, and would be happy to entertain su= ggestions on charter amendments. But, do we need to do that before the BoF = or as an output of the BoF? > On the terretrial front, one of the major barriers to progress has=20 > been the lack of an effective, reasonably general purpose,=20 > opportunistic routing protocol despite the immense amount of academic=20 > work that has been put in. I believe (and am trying to put some=20 > concrete answers into > practice) that this is a soluble problem but it limits the current=20 > deployability of DTN outside the space sector. Not necessarily. I think we can also consider coordinated terrestrial use c= ases where CGR is sufficient as in-scope for the initial charter. From nobody Thu Jun 12 17:02:31 2014 Return-Path: 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 3E0621A031F for ; Thu, 12 Jun 2014 17:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 qV_5ILT8XD0X for ; Thu, 12 Jun 2014 17:02:23 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22C2C1A030C for ; Thu, 12 Jun 2014 17:02:22 -0700 (PDT) Received: from [195.245.230.131:49323] by server-5.bemta-3.messagelabs.com id C7/64-18761-D8F3A935; Fri, 13 Jun 2014 00:02:21 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-15.tower-78.messagelabs.com!1402617740!30442370!1 X-Originating-IP: [131.227.200.31] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10891 invoked from network); 13 Jun 2014 00:02:21 -0000 Received: from exht011p.surrey.ac.uk (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-15.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 13 Jun 2014 00:02:21 -0000 Received: from EXHY011V.surrey.ac.uk (131.227.200.103) by exht011p.surrey.ac.uk (131.227.200.31) with Microsoft SMTP Server (TLS) id 8.3.348.2; Fri, 13 Jun 2014 01:02:20 +0100 Received: from emea01-am1-obe.outbound.protection.outlook.com (131.227.200.4) by email365.surrey.ac.uk (131.227.200.103) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 13 Jun 2014 01:02:20 +0100 Received: from AMSPR06MB439.eurprd06.prod.outlook.com (10.242.23.19) by AMSPR06MB439.eurprd06.prod.outlook.com (10.242.23.19) with Microsoft SMTP Server (TLS) id 15.0.959.24; Fri, 13 Jun 2014 00:02:19 +0000 Received: from AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) by AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) with mapi id 15.00.0959.000; Fri, 13 Jun 2014 00:02:19 +0000 From: To: , , , Thread-Topic: [dtn] DTN BoF Proposal for IETF90 Thread-Index: Ac+AQa9Fez/CplZaSwyaLFpzb8tj0wAiVZ0A///Hp/D//5OnYIABipvO//qPd7CAC7TeXf//SGxA//6DxzD/+6VQAP/3FmCA/+34egD/2qfDAP+0sx9u Date: Fri, 13 Jun 2014 00:02:18 +0000 Message-ID: <1402617737911.60597@surrey.ac.uk> References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> , <1401967219583.26821@surrey.ac.uk> , <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk> , <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> <1402389636710.92429@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830486EBE@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> <1402490970.2995.76.camel@mightyatom> <2134F8430051B64F815C691A62D983183048A030@XCH-BLV-512.nw.nos.boeing.com> <1402513416.2995.198.camel@mightyatom>,<5399BC2E.10707@gmail.com> In-Reply-To: <5399BC2E.10707@gmail.com> Accept-Language: en-AU, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [122.200.59.30] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0241D5F98C x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(164054003)(189002)(199002)(377454003)(53754006)(81542001)(85852003)(21056001)(15202345003)(77982001)(79102001)(83072002)(76482001)(46102001)(20776003)(15198665003)(86362001)(36756003)(105586001)(80022001)(15395725005)(92726001)(83322001)(54356999)(92566001)(76176999)(2656002)(101416001)(77096999)(87936001)(93886003)(561944003)(4396001)(66066001)(64706001)(50986999)(15975445006)(19580405001)(19580395003)(31966008)(74662001)(74482001)(74502001)(99396002)(81342001); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR06MB439; H:AMSPR06MB439.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: surrey.ac.uk does not designate permitted sender hosts) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: AMSPR06MB439.eurprd06.prod.outlook.com X-OriginatorOrg: surrey.ac.uk X-CrossPremisesHeadersPromoted: EXHY011v.surrey.ac.uk X-CrossPremisesHeadersFiltered: EXHY011v.surrey.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/Z3EtuHdI2eY_67wlO4QpBrBVbPQ Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 00:02:26 -0000 Martin,=0A= =0A= are minutes or a recording of that IESG review discussion available?=0A= =0A= thanks,=0A= =0A= Lloyd Wood=0A= http://about.me/lloydwood=0A= ________________________________________=0A= From: dtn on behalf of Martin Stiemerling =0A= Sent: Friday, 13 June 2014 12:41 AM=0A= To: Elwyn Davies; Templin, Fred L; dtn@ietf.org=0A= Subject: Re: [dtn] DTN BoF Proposal for IETF90=0A= =0A= Hi all,=0A= =0A= Yes, it is time to work on a charter on **this list**.=0A= =0A= One point that came up during the IESG review is if the charter should=0A= include work that re-evalutes the DTN architecture and figures out if=0A= other protocols are neeeded or if the choices for the bundle protocol is=0A= the right forward.=0A= =0A= Thanks,=0A= =0A= Martin=0A= =0A= From nobody Thu Jun 12 17:22:55 2014 Return-Path: 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 E839C1A0328; Thu, 12 Jun 2014 17:22:49 -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 zVnoxH2x9w-W; Thu, 12 Jun 2014 17:22:47 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A640B1A0344; Thu, 12 Jun 2014 17:22:47 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp02.jpl.nasa.gov [128.149.137.149]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s5D0MAGK005742 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Thu, 12 Jun 2014 17:22:11 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.217]) by ap-ehub-sp02.RES.AD.JPL ([fe80::dd85:7b07:1e36:7e3c%15]) with mapi id 14.03.0174.001; Thu, 12 Jun 2014 17:22:40 -0700 From: "Burleigh, Scott C (312G)" To: Sebastian Schildt , Elwyn Davies Thread-Topic: [dtn] DTN BoF Proposal for IETF90 Thread-Index: Ac+AQa9Fez/CplZaSwyaLFpzb8tj0wAiVZ0A///Hp/D//5OnYIABipvO//qPd7CAC7TeXf//SGxA//6DxzD/+y/3AP/2T0MA/+xScoD/2IgZgP+vrTqA Date: Fri, 13 Jun 2014 00:22:38 +0000 Message-ID: References: <2134F8430051B64F815C691A62D983181B2BE63E@XCH-BLV-504.nw.nos.boeing.com> , <1401967219583.26821@surrey.ac.uk> , <2134F8430051B64F815C691A62D983181B2BF498@XCH-BLV-504.nw.nos.boeing.com> <1402028661896.54716@surrey.ac.uk> , <2134F8430051B64F815C691A62D9831830485251@XCH-BLV-512.nw.nos.boeing.com> <1402389636710.92429@surrey.ac.uk> <2134F8430051B64F815C691A62D9831830486EBE@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831830486F8F@XCH-BLV-512.nw.nos.boeing.com> <1402490970.2995.76.camel@mightyatom> <1402510887.2995.155.camel@mightyatom> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.113] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/FhGCZjzB-CMlxRWNPPvT-ag1D2I Cc: "iesg@ietf.org" , "dtn@ietf.org" Subject: Re: [dtn] DTN BoF Proposal for IETF90 X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 00:22:50 -0000 Making sure that the charter addresses all of the capabilities that Sebasti= an identifies here make sense to me. On #3 in particular, I enthusiastical= ly agree: both mechanisms have value, and I think we can devise specificati= ons that will let them coexist and interoperate in the same world. Scott -----Original Message----- From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of Sebastian Schildt Sent: Wednesday, June 11, 2014 1:05 PM To: Elwyn Davies Cc: iesg@ietf.org; dtn@ietf.org Subject: Re: [dtn] DTN BoF Proposal for IETF90 Hi Elwyn, Hi * On 11 Jun 2014, at 20:21, Elwyn Davies wrote: > Hi, Sebastian. >=20 > In the light of what you say below, I think it would be useful to=20 > suggest a couple of use cases that should be kept in mind during the=20 > update of the BP so that we can incorporate them into the charter asap. >=20 ok, so since we are rather implementation-driven, these points might be too= technical/specific at this point, but here goes my wishlist. All of these = things we really did use for some of our applications. 1. Network Types: I think the main differences are in the contact qualities= : Hard-scheduled fully-deterministic IPN, and "soft-scheduled" things like = public transportation (schedule+uncertainty, we put nodes on trams for exam= ple) and fully opportunistic (think mobile phones, we are doing Android app= s). While most differences here would need to be absorbed by whatever routi= ng is employed, and do not have an impact on the protocol per-se the latter= two cases imply that: 2. We need discovery. I guess here the key thing is a generic description o= f a node. So far we have been using some variants of IPND. We have used tha= t idea not only for IP, but also use it for ZigBee, and store a similar str= ucture in the DHT when announcing nodes. What should be carried over to a s= tandard is the general (extensible) key-value idea. Something like this cou= ld be specified as a prerequsite during node-to-node handshake. How to use = this apart from node handshake (i.e. using IP multicast as is the case for = IPND, or put it in an IEEE 802.15.4 datagram or whatever), should not be in= the core specs.=20 2a) I guess one or two standard convergence layers should be proposed. Th= ose could also specify how, on their medium (if it is not just PtP anyway) = discovery is realized, preferably using the node-handshake data structure m= entioned in 2 3. I don't want to revive the holy time-wars, but in our experience at the = moment it s quite perfect that you can have "real" timestamps (expire this = on christmas!) as well as the age block (throw it away after 2 months). Dep= ending on the application, one works better than the other, so we really, r= eally think we should make sure BP keeps both possibilites. Maybe some thou= ght needs to be put into how to interoperate between both modes of operatio= n (when should an age bloock be replaced with an expiration and vice versa.= Alternatively just forbid mixing both worlds ..) 4. Not my area of expertise, but as has been said many times here: Bundle S= ecurity is a must, and needs to be simplified. While this might be an as-la= rge a can of worms as routing, I think key management should be at least be= "adressed". For example some of my colleagues have been worked implementin= g a "trust level" for exchanged keys. So they use every opportunitiy (as th= ey might be scarce) between node contacts to exchange keys following a "tru= st on first use" model. This implies a lower trust level for a key than an = user initiated exchange with verficiation, which for example you might want= to visulaize if your application is an end-user app on a mobile phone 5. Make sure delays can be months or milliseconds (it is fine now) So going back to the bigger picture - Applications: Make sure there is nothing in the protocol that fundamental= ly precludes the use of fully determinitic and fully opportunisitic scenari= os. Make sure ms delay (we are using this to remotely control robots from = a mobile phone), work the same as days/weeks months. This is already workin= g now, and we do not want to loose those capabilities for no good reason - A generic discovery/handshake, i.e. nothing that every CL or routing need= s to do for itself - Allow relative (sensor nodes without RTC) and aboslute time (cold storage= , disks, flash drives). - Include streamlined security. Think about key exchange.=20 That is all :) As I warned you before, this may be a little bit too technic= al at this stage. The main point is, while maybe some parts of what we curr= ently have in our documents are a bit wishy-washy or have gotten overly gen= eral/complex, there is also lot of (not-hurting) flexibility that we should= not loose. MfG Sebastian > On Wed, 2014-06-11 at 15:49 +0200, Sebastian Schildt wrote: >> Hello everybody! >>=20 >> On 11 Jun 2014, at 14:49, Elwyn Davies wrote: >>>=20 >>> Personally I am keen to see DTN used in space but I am also still a=20 >>> believer in terrestrial usage. There is clearly a tension between=20 >>> getting something done quickly and efficiently for the space case=20 >>> where there is potential for (relatively) short term (nothing is=20 >>> really that short term in space exploration!) deployment, and=20 >>> updating the BP etc in a way that will also move along the=20 >>> terrestrial usage where the requirements are slightly different and not= so well set in concrete. >>=20 >> While it is true that requirements for space scenarios seems to be=20 >> much clearer, we (IBR) have been using the BP solely for various=20 >> terrestial scenarios over the last years. While not everything is=20 >> perfect, we had a profound feeling that the BP is sort of "good=20 >> enough". Of course we followed the various semi-regular what-is-time? >> what-is-end-to-end? SDNV-Flexble-or-Epic-Fail? discussions on=20 >> dtn-interest. The key point is: Mostly we _followed_, not so much=20 >> participated. Of course there have been some heated lunch break=20 >> discussions over all these things within our group, but for the most=20 >> part it did not matter that much in the application. >=20 > Indeed I have been involved in a number of projects that have tried=20 > out various routing schemes but, as you say, for most purposes the BP=20 > is "good enough". I have identified a number of issues that need=20 > addressing but this is not the moment to go into them. >>=20 >> Consider, that today we use "responsive" desktop-like applications=20 >> written in Javascript using text-based JSON formats over non-latency=20 >> optimized links using HTTP protocols. That is (literally) wrong on so=20 >> many levels. Some hacky/impressive engeneering such as=20 >> WebSockets/SPDY and ridicoulously optimized JavaScript engines etc.=20 >> are used to make it less painful. But it works fine, doesn't it? So=20 >> we feel, compared to that, we are of to quite a good start with the BP! >=20 > Definitely +several! =20 >>=20 >> So generally, we are in favor of the idea of slightly=20 >> polishing/repairing the BP without starting from scratch. >=20 > Agreed. The difficulty will be deciding what constitutes slightly. > Again that is a discussion either at the BOF or more likely once the=20 > WG is approved. >=20 >> Which is the correct path or institution to do it, and whether the=20 >> BoF is the correct way to go, we can not say. The inner workings of=20 >> the IETF and stuff are magical to us. >=20 > The key thing is to get a standards track specification for BPbis. =20 > This is most conveniently done with an IETF WG which can coordinate=20 > activities both within the work on the BPbis draft and with the=20 > auxiliary items mentioned in the charter. For that the process needs a=20 > BoF and, if the BoF goes well, approval by the IESG/IAB to form a new=20 > WG. >=20 > Tomorrow is a key day when the decision to allow the BoF to take place=20 > is made by the IESG/IAB. >=20 >>=20 >> However, the point is: I feel, even if the following efforts will=20 >> have a slight focus on space applications, not much will be lost for=20 >> terrestrial applications, if things are still based on the BP. >> Especially if the main difference is seen as routing: >>=20 >>>=20 >>> The lack of clarity over intended usage could well have a bad impact=20 >>> on the WG if it results in disagreements over the specifications. =20 >>> It also shows up in what is *not* in the charter. most notably in=20 >>> the absence of any consideration of how to route the bundles that=20 >>> BPbis handles. IMO a DTN system that doen't address bundle routing is = only half-baked. >>=20 >>=20 >> I know we had some discussion at some conference or workshop about=20 >> this. I believe routing (as in "a better Epidemic/Prophet") is not=20 >> neccessary for terrestrial DTN applications. Most of the time we have=20 >> small scale networks (Flooding/Gossipping is fine), or highly=20 >> application-specific solutions (nobody would use a general purpose=20 >> routing mechanism if the application is public transportation). For=20 >> interconnection we have the internet/ip, so we just need naming there. >> I know, we can have the discussion and agree to disagree, so I would=20 >> rephrase it like this >>=20 >> "IMO a DTN system that doesn't address bundle routing is only half-baked= . " >> Yes, defintely. At least you should know how to get stuff from A to B=20 >> in your application. >>=20 >> However I would add >> "Routing is of no concern for the core BP(bis) specification" >> Just as the IPv(4/6) main specs do not say much about routing.=20 >=20 > Absolutely: My opinion is that the charter needs to say something=20 > about routing immediately. This wouldn't affect the work items=20 > already identified but would add an extra item or two to begin the=20 > process of specifying both CGR and getting the requirements in place=20 > for an opportunistic protocol. This is partly political to show that=20 > we haven't forgotten routing and partly to snsure we don't do anything=20 > too stupid in the other work items that will later screw up routing=20 > (addressing is a key area!) >>=20 >> So there could be specifications on top specifying routing mechanisms. >> And if the space-community knows exactly what they want, they should=20 >> go forward with it. I feel this does not hurt us terrestrial guys. >=20 > Probably not.. but we need to keep a good watching brief and=20 > contribute as necessary to ensure that this remains the case! (as you say= below). >=20 >> The most magic routing mechansim should still work on top of an=20 >> unmodified BP. In our implementation, once two nodes meet there is a=20 >> magical routing handshake, so the peers knows what routing the=20 >> communication partner is using. That might be the only thing that=20 >> should be nailed in an official way on top of the current BP to be=20 >> safe for the future (some baseline approaches such as "only direct=20 >> delivery please" could be made mandatory) . >=20 > I *think* what I am hearing here is that we should have a standardized=20 > discovery protocol. I agree (and I think it has been mentioned=20 > elsewhere on the list). >>=20 >>=20 >>>=20 >>>=20 >>> On the terretrial front, one of the major barriers to progress has=20 >>> been the lack of an effective, reasonably general purpose,=20 >>> opportunistic routing protocol despite the immense amount of=20 >>> academic work that has been put in. I believe (and am trying to put=20 >>> some concrete answers into >>> practice) that this is a soluble problem but it limits the current=20 >>> deployability of DTN outside the space sector. >> Again, I think it is not such a large barrier, even though usable=20 >> general purpose large-scale opportunistic routing would certainly be=20 >> nice. >>=20 >>>=20 >>> It may be that this problem is seen as a show stopper for the=20 >>> terrestrial use case and, hence, that the WG should be entirely=20 >>> devoted to the space case. Personally I think this would be a shame=20 >>> and I would be less enthusiastic about working with this limited=20 >>> agenda. However, if that agenda is the case, the charter ought to=20 >>> be clear and the IESG needs to be aware of where things are going. >>=20 >> I think that barrier for terrestrial applications would not get any=20 >> harder to cross, even if the WG focusses more on space missions. As=20 >> long as us terrestrians keep an open eye to what is done and make=20 >> sure nothing important gets cut away form the BP and the system=20 >> remains open enough with regard to routing. >=20 > Again +several! >=20 >> Developing and specifying the perfect, mandatory opportunistic=20 >> routing within the WG would probably fail, because as you have=20 >> pointed out so far "despite the immense amount of academic work that has= been put in" >> nothing came out. >=20 > Right. I am not proposing that we do that in this phase. Get CGR=20 > sorted out and any bits standardized that ought to be. In parallel=20 > (maybe back in DTNRG or just privately) try to sort out the=20 > opportunistic protocol and if we do, come back later to get it=20 > standardized. >>=20 >>=20 >> But that is no reason to be less enthusiastic! :) >>=20 > Good! >=20 > Regards, > Elwyn >>=20 >> MfG >>=20 >> Sebastian >>=20 >> _______________________________________________ >> 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 From nobody Thu Jun 12 17:56:41 2014 Return-Path: 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 B452B1A0640 for ; Thu, 12 Jun 2014 17:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 lcl2UR-MIBZs for ; Thu, 12 Jun 2014 17:56:38 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FBB51A0549 for ; Thu, 12 Jun 2014 17:56:38 -0700 (PDT) Received: from [85.158.137.99:35321] by server-9.bemta-3.messagelabs.com id 04/D7-30063-44C4A935; Fri, 13 Jun 2014 00:56:36 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-4.tower-217.messagelabs.com!1402620995!21666451!1 X-Originating-IP: [131.227.200.43] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22867 invoked from network); 13 Jun 2014 00:56:35 -0000 Received: from exht022p.surrey.ac.uk (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-4.tower-217.messagelabs.com with AES128-SHA encrypted SMTP; 13 Jun 2014 00:56:35 -0000 Received: from EXHY021V.surrey.ac.uk (131.227.200.104) by EXHT022P.surrey.ac.uk (131.227.200.43) with Microsoft SMTP Server (TLS) id 8.3.342.0; Fri, 13 Jun 2014 01:56:34 +0100 Received: from emea01-am1-obe.outbound.protection.outlook.com (131.227.200.4) by email365.surrey.ac.uk (131.227.200.104) with Microsoft SMTP Server (TLS) id 14.3.174.1; Fri, 13 Jun 2014 01:56:34 +0100 Received: from AMSPR06MB439.eurprd06.prod.outlook.com (10.242.23.19) by AMSPR06MB439.eurprd06.prod.outlook.com (10.242.23.19) with Microsoft SMTP Server (TLS) id 15.0.959.24; Fri, 13 Jun 2014 00:56:33 +0000 Received: from AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) by AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) with mapi id 15.00.0959.000; Fri, 13 Jun 2014 00:56:33 +0000 From: To: , Thread-Topic: [dtn] Draft Charter Discussion Thread-Index: Ac+GbO3wN7xIp4CqSFeVEjvJc65+vAALOJcAAAHelEw= Date: Fri, 13 Jun 2014 00:56:33 +0000 Message-ID: <1402620993016.36040@surrey.ac.uk> References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com>, <1402617340.2995.817.camel@mightyatom> In-Reply-To: <1402617340.2995.817.camel@mightyatom> Accept-Language: en-AU, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [122.200.59.30] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0241D5F98C x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(189002)(199002)(4396001)(76176999)(77096999)(101416001)(87936001)(2656002)(99396002)(81342001)(50986999)(64706001)(66066001)(74502001)(15975445006)(74482001)(74662001)(19580395003)(31966008)(76482001)(20776003)(46102001)(21056001)(85852003)(81542001)(15202345003)(83072002)(77982001)(79102001)(80022001)(92726001)(83322001)(54356999)(92566001)(86362001)(36756003)(105586001); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR06MB439; H:AMSPR06MB439.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: surrey.ac.uk does not designate permitted sender hosts) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: AMSPR06MB439.eurprd06.prod.outlook.com X-OriginatorOrg: surrey.ac.uk X-CrossPremisesHeadersPromoted: EXHY021v.surrey.ac.uk X-CrossPremisesHeadersFiltered: EXHY021v.surrey.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/CVxTOaYLRTH0Wa3ucQdFMkRnoHg Cc: dtn@ietf.org Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 00:56:40 -0000 Elwyn:=0A= > As regards Martin S's feedback from the IESG discussion:=0A= > - *Please* let's not go back into the conclusions of the architecture in= =0A= > the WG. Let's settle that before the BoF if we need to, report there=0A= > and have an end of it. I suspect that if we did reopen the architecture= =0A= > in a major way, quite a lot of people would walk away: Opinions?=0A= =0A= The architecture question is valid. It's valid and reasonable to question= =0A= why an obviously failed design is being pushed through so heavily,=0A= particularly when it has so little relevance to the rest of IETF work,=0A= and any putative IETF workgroup should consider things other than the=0A= bundle protocol.=0A= =0A= The IESG made the correct call there imo - though I don't think it made=0A= the right one in allowing the BOF.=0A= =0A= I see scope has already opened up on routing etc. Why not on=0A= base protocol?=0A= =0A= (Oh, you should also certainly push for a revision of RFC6256 to go=0A= standards track, since everything else is being revised for standards=0A= track as well.)=0A= =0A= Lloyd Wood=0A= http://sat-net.com/L.Wood/dtn= From nobody Fri Jun 13 08:44:48 2014 Return-Path: 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 F08121B2968 for ; Fri, 13 Jun 2014 08:44:46 -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 V_lCuLaBAw2A for ; Fri, 13 Jun 2014 08:44:44 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6315E1B2965 for ; Fri, 13 Jun 2014 08:44:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s5DFih7D026231; Fri, 13 Jun 2014 08:44:43 -0700 Received: from XCH-PHX-102.sw.nos.boeing.com (xch-phx-102.sw.nos.boeing.com [137.136.238.5]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s5DFiI1I025611 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 13 Jun 2014 08:44:40 -0700 Received: from XCH-BLV-111.nw.nos.boeing.com (137.136.239.103) by XCH-PHX-102.sw.nos.boeing.com (137.136.238.5) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 13 Jun 2014 08:44:34 -0700 Received: from XCH-BLV-512.nw.nos.boeing.com ([169.254.12.74]) by XCH-BLV-111.nw.nos.boeing.com ([169.254.10.69]) with mapi id 14.03.0181.006; Fri, 13 Jun 2014 08:44:34 -0700 From: "Templin, Fred L" To: Elwyn Davies Thread-Topic: [dtn] Draft Charter Discussion Thread-Index: Ac+GbO3wN7xIp4CqSFeVEjvJc65+vAAZ468AABGqYiA= Date: Fri, 13 Jun 2014 15:44:33 +0000 Message-ID: <2134F8430051B64F815C691A62D983183048BCAF@XCH-BLV-512.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> <1402617340.2995.817.camel@mightyatom> In-Reply-To: <1402617340.2995.817.camel@mightyatom> 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/MS7nhav7M5QBKI4QCp_3hJRrV6s Cc: "dtn@ietf.org" Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 15:44:47 -0000 Hi Elwyn, > -----Original Message----- > From: Elwyn Davies [mailto:elwynd@folly.org.uk] > Sent: Thursday, June 12, 2014 4:56 PM > To: Templin, Fred L > Cc: dtn@ietf.org > Subject: Re: [dtn] Draft Charter Discussion >=20 > Hi. >=20 > Looking at the milestones and timescales... >=20 > I am still not totally convinced by the timescales which I think are > somewhat optimistic (i'll take out the 'wildly' which I used > previously). However before we get onto the nitty gritty of milestone > dates, I think there are some wording > and scheduling issues to sort out: >=20 > There are several entries such as > start+3mos - Submit 'Bundle Protocol Specification (RFC5050bis)' as a > working group document [2]. To be Proposed Standard. >=20 > I think this means 'Accept "" [n] as working group > work item intended for . However I > suspect that putting these in as milestones is maybe not a good idea. Do you want me to change the language, or should we just leave it alone? > Presumably what we should be doing is initially making up our collective > mind on the changes that should be done (c.f., Martin S's comment). >=20 > Certainly for the BPbis work, depending on the outcome of this > discussion, either the prototype individual drafts may or may not be > the right basis for the ongoing work based on the results. I'd be > inclined to go for a milestone at 6-9 months on getting concensus on > changes to be implemented in the existing RFC 5050. So, submit BPbis as a working group item from day one in parallel with generating consensus on changes leading up to a 6-9mo milestone? I'm OK with it if that's what you mean - just seeking clarification.=20 > On the SBSP I'd > probably go for accepting it as a WG work item on day 1 since this is > effectively new work. For the items that become WG work items later: > What do we expect people to be doing with these in the interim? Can't > we just make them WG items immediately, assuming that we agree we want > to do them? That would be OK with me. =20 > This next pair doesn't seem to be practical: > start+18mos - WG determination for merging RFC5050bis, SBSP, BIBE and/= or > Key Mgmt into a combined draft or keep as separate draft= s. > start+18mos - Submit RFC5050bis, SBSP, BIBE and Key Mgmt to the IESG e= ither > as a combined draft or as separate drafts. > Prior to this point, the charter sort of assumes that there will be > separate drafts. Assuming that the decision alters this to a combined > draft at this late stage in development, switching will a.s. > take an immense amount of work in zero elapsed time and I wouldn't like > to guarantee the quality of the result. I *really* think we have to > make a decision much earlier (about the time we agree what changes are > needed) and live with it. Change to "start+9mos" for "WG determination for merging"? > Returning to the amount of time needed, I am extremely sceptical that > we can cut and polish something like six RFCs in just over 18 months > even given the running start we have. This is partly because I don't > know if any of the expected participants have some dedicated person > power at your disposal to work on the specifications. I'd expect that > we would need 2 years and even then I'd not bet too heavily on getting > there in time. Well, the charter already has milestones out to 2yrs and from what I have seen of other IETF charters that seems like a fairly long timeframe for a working group to run before rechartering. And, the expectation is to recharter after 24mos. > As regards Martin S's feedback from the IESG discussion: > - *Please* let's not go back into the conclusions of the architecture in > the WG. Let's settle that before the BoF if we need to, report there > and have an end of it. I suspect that if we did reopen the architecture > in a major way, quite a lot of people would walk away: Opinions? >=20 > - There are some fairly major items that are at least partially > architectural that we do have to sort out, not least the timestamps in > bundles and the effects on nodes. I suggested a tactical way fowards on > that above. We probably ought to start a separate thread on BP changes, > starting with a listing of what has changed in BPv7. There is already a list in Appendix A of: https://datatracker.ietf.org/doc/draft-burleigh-bpv7/ Should that be posted under a new thread on this list? > - Other protocols: > + I already mentioned the CGR support - something like the proposed > CPUP - and put it in the charter update. > + Similarly the discovery protocol. > + Taking LTP to Proposed Standard ... does this need much work? Have > those who are using it found much in the way of holes/improvements? > + Other IP based convergence layer protocols (update of the TCP CL > which I think is very important). > + Multicast/Anycast and content distribution. Whether non-singleton > EIDs are actually useful. > + Opportunistic routing scheme(s). >=20 > Of these protocols, the first two are now in the charter and are > fairly lightweight. Having a standardized LTP would complete the space > story as it is currently used. There is a CCSDS LTP draft > (http://public.ccsds.org/sites/cwe/rids/Lists/CCSDS% > 207341R2/NASAUSOverview.aspx). I believe the TCP CL needs a bit of a > rethink (mainly to provide parallel channels and some additional > fragmentation support) but isn't essential to the space sector unless > they would really like it for the ground segment. The opportunistic > routing protocol is really a white space at the moment. The thinking was that the advanced CLs and reliable delay tolerant transports would come in during a recharter. That would not preclude posting drafts with "-dtn" in their names in the near term and listing them as documents associated with the working group. The idea is that associated documents with community consensus would be targeted for wg adoption during the recharter. Thanks - Fred fred.l.templin@boeing.com =20 > On Thu, 2014-06-12 at 18:34 +0000, Templin, Fred L wrote: > > Hello, > > > > There were some additional off-list updates to the charter > > emerging as Martin was calling for charter discussion. Please > > see below for the revised version (diffs attached) and use this > > as basis for further discussion. (Sebastian and others - please > > post any follow-ups to this thread.) > > > > Fred > > > > --- > > > > Draft working group charter: > > **************************** > > Working group name: > > > > Delay/Disruption Tolerant Networking Working Group (DTNWG) > > > > Chair(s): > > > > TBD > > > > Area and Area Director(s): > > > > Transport Area: ADs Spencer Dawkins , > > Martin Stiemerling > > > > Responsible Area Director: > > > > TBD > > > > Mailing list: > > > > General Discussion: dtn at ietf.org > > To Subscribe: https://www.ietf.org/mailman/listinfo/dtn > > Archive: http://www.ietf.org/mail-archive/web/dtn/current/maillis= t.html > > > > Description of Working Group: > > > > The Delay/Disruption Tolerant Network Working Group (DTNWG) speci= fies > > mechanisms for data communications in the presence of long delays > > and/or intermittent connectivity. The work is motivated by well k= nown > > limitations of standard Internet protocols that expect end-to-end > > connectivity between communicating endpoints, sub-second transmis= sion > > delays and robust packet delivery ratios. In environments where t= hese > > favorable conditions do not apply, existing mechanisms encounter = problems > > such as reliable transport protocol handshakes timing out and rou= ting > > protocols failing to converge resulting in communication failures= . > > Furthermore, classical end-to-end security associations cannot be > > coordinated when communicating endpoints cannot conduct multi-mes= sage > > keying exchanges in a timely fashion. These limitations suggested= the > > need for a new approach. > > > > Delay-Tolerant Networking (DTN) protocols have been the subject o= f > > extensive research and development in the Delay-Tolerant Networki= ng > > Research Group (DTNRG) of the Internet Research Task Force since = 2002. > > The DTNRG has developed the Delay-Tolerant Networking Architectur= e > > (RFC 4838) that the DTNWG uses as the basis for its work. The ke= y > > components of the this architecture are the bundle concept for > > encapsulating data units, the bundle transmission protocol and th= e > > underlying convergence layer architecture. > > > > The experimental DTN Bundle Protocol (RFC 5050) and Licklider > > Transmission Protocol (RFC 5326) have been shown to address the > > issues identified above in substantial fielded deployments in the= space > > sector [1]. RFC 5050 in conjunction with TCP- and UDP-based conv= ergence > > layers has been used successfully in a number of experiments both= in > > communications challenged environments around the edges of the In= ternet > > and as an Internet overlay where applications require delay- and/= or > > disruption-tolerance [refs needed]. > > > > The success of the BP over convergence layer protocol stack -- th= e core > > protocols of the "DTN Architecture" described in RFC 4838 -- may = be > > attributed to the following fundamental design principles: > > > > - There is never any expectation of contemporaneous end-to-end > > connectivity between any two network nodes. > > > > - Because end-to-end connectivity can never be assumed, each node > > on the path between source and destination must be prepared to > > handle incoming "bundles" of data that cannot immediately be > > forwarded. > > > > - Again because end-to-end connectivity can never be assumed, > > end-to-end conversational data exchange can never be assumed to > > complete in a timely manner; protocol features that rely on > > timely conversational data exchange must be excluded from the > > architecture. > > > > The DTNWG believes that protocols adhering to these principles of= fer > > opportunities for enhancing the functionality of the Internet, in= cluding > > > > - facilitating the extension of the Internet into environments = such as > > the ocean floor and deep space in which the core Internet pro= tocols > > operate sub-optimally for the reasons discussed earlier; > > > > - extending the Internet into communications challenged terrest= rial > > environments where it is not possible to provide continuous, = low > > delay Internet connections; and > > > > - supporting Internet applications that need DTN capabiliies. > > > > We believe that the extensive research, demonstration, and > > pilot operations performed to date using the DTNRG protocols prov= ides > > a firm basis for publishing Internet standards derived from that = work. > > > > Work items related to Delay/Disruption Tolerant Networking includ= e: > > > > o A mechanism for the exchange of protocol data units, termed > > "bundles", that are designed to obviate conversational communications > > by containing values for all potentially relevant configuration > > parameters. These protocol data units are typically larger than > > network-layer packets. We will derive this bundle exchange mechanism > > from the DTN Bundle Protocol (BP) documented in RFC 5050 by pub= lishing > > a new document for which [2] is a proposed first draft (where > > appendix A provides a summary of the proposed changes). > > > > o A security protocol for ensuring that the network in which bund= les > > are exchanged is secured against unauthorized access and denial of > > service attacks, and to ensure data integrity and confidentiality > > in that network where necessary. We will derive this security > > protocol from a "streamlined" adaptation of the DTN Bundle Security > > Protocol documented in RFC 6257. > > > > o A delay-tolerant security key management scheme for ensuring th= at > > public keys are certified by a globally trusted authority to protect > > the integrity of the infrastructure. > > > > o A simple datagram convergence layer protocol for adaptation of = the > > bundle protocol to underlying internetworks. We expect to deriv= e > > this convergence layer protocol from the Datagram Convergence > > protocol documented in RFC 7122. > > > > o A delay-tolerant network management protocol for management of = the > > infrastructure in the presence of long delays and/or intermitte= nt > > connectivity. > > > > o A functional specification of Contact Graph Routing (CGR) speci= fying > > the inputs (global contact schedules, traffic demands, etc.) an= d > > outputs (node specific transmission and reception schedules, > > notifications, etc.). CGR is a centralized, oracle-based bundl= e > > transmission and reception scheduling scheme used in space segm= ent > > DTN deployments. > > > > o An adjunct to the management protocol that will allow the conta= ct > > schedules generated by CGR to be distributed to nodes. This ma= y be > > based on the Contact Plan Update Protocol (CPUP) proposed in > > > > o An encapsulation protocol for "tunneling" BP traffic within bun= dles > > that are secured and/or routed in different way from the encapsulated > > bundles. > > > > o A registry for DTN Service Identifiers > > > > The working group will consider extending the current milestones ba= sed on > > new information and knowledge gained while working on the initial c= harter, > > as well as to accommodate new work items beyond the scope of the in= itial > > phase. For example, we expect that transport protocols such as LTP= and > > the Saratoga protocol are among the candidates for work in this pha= se. > > > > Goals and Milestones: > > start+3mos - Submit 'Bundle Protocol Specification (RFC5050bis)' as a > > working group document [2]. To be Proposed Standard. > > Start+3mos - Submit 'Streamlined Bundle Security Protocol (SBSP)' as = a > > working group document [3]. To be Proposed Standard. > > start+6mos - Submit 'Bundle In Bundle Encapsulation (BIBE)' as a work= ing > > group document [4]. To be Proposed Standard. > > start+12mos - Submit 'CGR Functional Specification' as a working grou= p > > document. To be an informational document. > > start+12mos - Submit 'Delay Tolerant Networking Security Key Manageme= nt' as > > a working group document. To be Proposed Standard. > > start+15mos - Submit 'Contact Plan Update Protocol' as working group > > document. To be Proposed Standaqqrd. > > start+18mos - WG determination for merging RFC5050bis, SBSP, BIBE and= /or > > Key Mgmt into a combined draft or keep as separate draf= ts. > > start+18mos - Submit RFC5050bis, SBSP, BIBE and Key Mgmt to the IESG = either > > as a combined draft or as separate drafts. > > start+18mos - Submit Network Management [5], Registry [6] and Simple > > Convergence Layer [7] as working group documents. > > start+20mos - Survey appropriate forums (e.g., DTNRG) for emerging > > technologies (e.g., convergence layer protocols, dynami= c > > routing protocols, naming and addressing services, etc.= ) > > ready for transition into IETF DTN Working Group. Publi= sh > > draft on survey results as independent submission relat= ed > > to the WG. > > start+24mos - Submit Network Management, Registry and Simple Converge= nce > > Layer to IESG > > start+24mos - Recharter to accommodate new work items or close Workin= g Group > > > > > > [1] "BP/LTP deployment on EPOXI spacecraft" [2008], > > http://committees.comsoc.org/tccc/ccw/2010/slides/DINET_CCW.pdf > > [2] "Proposed Revised Bundle Protocol" [2014], > > https://datatracker.ietf.org/doc/draft-burleigh-bpv7/ > > [3] "Streamlined Bundle Security Protocol Specification" [2014], > > https://datatracker.ietf.org/doc/draft-irtf-dtnrg-sbsp/ > > [4] "Bundle-in-Bundle Encapsulation" [2013], > > http://tools.ietf.org/id/draft-irtf-burleigh-bibe > > [5] "Delay Tolerant Network Management Protocol" [2013], > > http://tools.ietf.org/id/draft-irtf-dtnrg-dtnmp > > [6] "Delay-Tolerant Networking Bundle Protocol IANA Registries" [2011], > > https://datatracker.ietf.org/doc/rfc6255/ > > [7] "Datagram Convergence Layers ..." [2014], > > https://datatracker.ietf.org/doc/rfc7122/ > > [8] "Towards Flexibility and Accuracy in Space DTN Communications", > > Bezirgianndia et al, CHANTS 2012, > > http://dl.acm.org/citation.cfm?id=3D2505499 [2012] > > > > > > _______________________________________________ > > dtn mailing list > > dtn@ietf.org > > https://www.ietf.org/mailman/listinfo/dtn From nobody Fri Jun 13 12:16:15 2014 Return-Path: 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 7D0A21B2A1B for ; Fri, 13 Jun 2014 12:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.853 X-Spam-Level: X-Spam-Status: No, score=-4.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 RCoCK-z1gZeo for ; Fri, 13 Jun 2014 12:16:11 -0700 (PDT) Received: from pilot.jhuapl.edu (pilot.jhuapl.edu [128.244.251.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B04021B2A14 for ; Fri, 13 Jun 2014 12:16:10 -0700 (PDT) Received: from aplexcas1.dom1.jhuapl.edu (unknown [128.244.198.90]) by pilot.jhuapl.edu with smtp (TLS: TLSv1/SSLv3,128bits,RC4-MD5) id 6bf5_48cf_46b906c4_5640_40e0_a7a0_a1bc8e337b0c; Fri, 13 Jun 2014 15:15:56 -0400 Received: from aplesfreedom.dom1.jhuapl.edu ([128.244.198.204]) by aplexcas1.dom1.jhuapl.edu ([128.244.198.90]) with mapi; Fri, 13 Jun 2014 15:15:56 -0400 From: "Ramachandran, Vignesh R. (Vinny)" To: "Templin, Fred L" , Sebastian Schildt Date: Fri, 13 Jun 2014 15:15:53 -0400 Thread-Topic: [dtn] Draft Charter Discussion Thread-Index: Ac+HO+ZDcWd5WNEhT7mjs1YwrvZQ8g== Message-ID: References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> <2134F8430051B64F815C691A62D983183048B3B6@XCH-BLV-512.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983183048B3B6@XCH-BLV-512.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/__GkNfkE4M6nkclJI-buz4Oxxr8 Cc: "dtn@ietf.org" Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 19:16:12 -0000 Hi all, > >> Apart from that I am not sure what is meant by: >> > >> > o A delay-tolerant network management protocol for management of >>the >> > infrastructure in the presence of long delays and/or >>intermittent >> > connectivity. >>=20 >> DT-SNMP? Maybe the stakeholders in this could add/suggest a sentence >>to clarify what "network >> management" means in this case? > >Can someone with interest in DTN network management address this point? Ed Birrane and I published the DTNMP experimental internet draft document back in October, so perhaps I can shed some light... I believe the intent here may be clarified with "A protocol for remote status monitoring, configuration, and administration of network nodes in the presence of long delays and/or intermittent connectivity." Conceptually, this is in line with SNMP offerings, without the overhead and bidirectionality requirements of a request/response conversation. I believe the DING protocol proposal also offers similar features, so DTNMP is by no means the only answer. Apologies for jumping in mid-stream on this quite long discussion. =20 > >Thanks - Fred >fred.l.templin@boeing.com >=20 >> MfG >>=20 >> Sebastian > Best,=20 Vinny Ramachandran From nobody Tue Jun 17 10:40:59 2014 Return-Path: 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 E37891A03BD for ; Tue, 17 Jun 2014 10:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.841 X-Spam-Level: X-Spam-Status: No, score=-4.841 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] 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 dvvIu6V2lR4T for ; Tue, 17 Jun 2014 10:40:54 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E3411A03B4 for ; Tue, 17 Jun 2014 10:40:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s5HHerAO008714; Tue, 17 Jun 2014 10:40:53 -0700 Received: from XCH-PHX-305.sw.nos.boeing.com (xch-phx-305.sw.nos.boeing.com [137.136.239.28]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s5HHeiVm008081 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Tue, 17 Jun 2014 10:40:44 -0700 Received: from XCH-BLV-410.nw.nos.boeing.com (137.136.239.131) by XCH-PHX-305.sw.nos.boeing.com (137.136.239.28) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 17 Jun 2014 10:40:43 -0700 Received: from XCH-BLV-512.nw.nos.boeing.com ([169.254.12.74]) by XCH-BLV-410.nw.nos.boeing.com ([169.254.10.180]) with mapi id 14.03.0181.006; Tue, 17 Jun 2014 10:40:43 -0700 From: "Templin, Fred L" To: "dtn@ietf.org" Thread-Topic: [dtn] Draft Charter Discussion Thread-Index: Ac+GbO3wN7xIp4CqSFeVEjvJc65+vAAPLd8AAAy+SjAAJnyrgAC3CG0Q Date: Tue, 17 Jun 2014 17:40:42 +0000 Message-ID: <2134F8430051B64F815C691A62D983183048DB80@XCH-BLV-512.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> <2134F8430051B64F815C691A62D983183048B3B6@XCH-BLV-512.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [137.136.248.6] Content-Type: multipart/mixed; boundary="_002_2134F8430051B64F815C691A62D983183048DB80XCHBLV512nwnosb_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/V6xSdpCl2amj5rxvoj2DbmZEpxQ Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 17:40:58 -0000 --_002_2134F8430051B64F815C691A62D983183048DB80XCHBLV512nwnosb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please see below for an updated version of the draft charter based on list discussions, and post any further comments in follow-up. (See also attached for diffs relative to the previous version.) Thanks - Fred fred.l.templin@boeing.com --- Draft BoF Agenda (2.5hrs): ************************** 1) Problem statement (IETF wg motivation) - 30min 2) RFC5050(bis) - 15min 3) Streamlined Bundle Security Protocol (SBSP) - 15min 4) Security Key Management - 10min 5) Network Management - 10min 6) Contact Graph Routing and Contact Plan Update Protocol - 10min 7) Bundle-in-Bundle Encapsulation - 5min 8) Registry for Service Identifiers - 5min 9) Open Discussion - 50min Draft working group charter: **************************** Working group name:=20 Delay/Disruption Tolerant Networking Working Group (DTNWG) Chair(s): TBD Area and Area Director(s): Transport Area: ADs Spencer Dawkins , Martin Stiemerling Responsible Area Director: TBD Mailing list: General Discussion: dtn at ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dtn Archive: http://www.ietf.org/mail-archive/web/dtn/current/maillist.ht= ml Description of Working Group: The Delay/Disruption Tolerant Network Working Group (DTNWG) specifies mechanisms for data communications in the presence of long delays and/or intermittent connectivity. The work is motivated by well known limitations of standard Internet protocols that expect end-to-end connectivity between communicating endpoints, sub-second transmission delays and robust packet delivery ratios. In environments where these favorable conditions do not apply, existing mechanisms encounter prob= lems=20 such as reliable transport protocol handshakes timing out and routing= =20 protocols failing to converge resulting in communication failures.=20 Furthermore, classical end-to-end security associations cannot be=20 coordinated when communicating endpoints cannot conduct multi-message= =20 keying exchanges in a timely fashion. These limitations suggested the= =20 need for a new approach.=20 =20 Delay-Tolerant Networking (DTN) protocols have been the subject of extensive research and development in the Delay-Tolerant Networking Research Group (DTNRG) of the Internet Research Task Force since 2002= . The DTNRG has developed the Delay-Tolerant Networking Architecture=20 (RFC 4838) that the DTNWG uses as the basis for its work. The key=20 components of the this architecture are the bundle concept for=20 encapsulating data units, the bundle transmission protocol and the=20 underlying convergence layer architecture. =20 The experimental DTN Bundle Protocol (RFC 5050) and Licklider Transmission Protocol (RFC 5326) have been shown to address the issues identified above in substantial fielded deployments in the spa= ce=20 sector [1]. RFC 5050 in conjunction with TCP- and UDP-based converge= nce=20 layers has been used successfully in a number of experiments both in= =20 communications challenged environments around the edges of the Intern= et=20 and as an Internet overlay where applications require delay- and/or=20 disruption-tolerance [refs needed]. =20 The success of the BP over convergence layer protocol stack -- the co= re=20 protocols of the "DTN Architecture" described in RFC 4838 -- may be=20 attributed to the following fundamental design principles: - There is never any expectation of contemporaneous end-to-end connectivity between any two network nodes. - Because end-to-end connectivity can never be assumed, each node on the path between source and destination must be prepared to handle incoming "bundles" of data that cannot immediately be forwarded. - Again because end-to-end connectivity can never be assumed, end-to-end conversational data exchange can never be assumed to complete in a timely manner; protocol features that rely on timely conversational data exchange must be excluded from the architecture. The DTNWG believes that protocols adhering to these principles offer opportunities for enhancing the functionality of the Internet, includ= ing=20 - facilitating the extension of the Internet into environments such= as=20 the ocean floor and deep space in which the core Internet protoco= ls=20 operate sub-optimally for the reasons discussed earlier; - extending the Internet into communications challenged terrestrial= =20 environments where it is not possible to provide continuous, low= =20 delay Internet connections; and=20 - supporting Internet applications that need DTN capabiliies. We believe that the extensive research, demonstration, and pilot operations performed to date using the DTNRG protocols provides a firm basis for publishing Internet standards derived from that work= . Work items related to Delay/Disruption Tolerant Networking include: o A mechanism for the exchange of protocol data units, termed "bundles", that are designed to obviate conversational communications by containing values for all potentially relevant configuration parameters. These protocol data units are typically larger than network-layer packets. We will derive this bundle exchange mechanism from the DTN Bundle Protocol (BP) documented in RFC 5050 by publish= ing a new document for which [2] is a proposed first draft (where appendix A provides a summary of the proposed changes). o A security protocol for ensuring that the network in which bundles are exchanged is secured against unauthorized access and denial of service attacks, and to ensure data integrity and confidentiality in that network where necessary. We will derive this security protocol from a "streamlined" adaptation of the DTN Bundle Security Protocol documented in RFC 6257. o A delay-tolerant security key management scheme that can protect the integrity of a DTN network. o A simple datagram convergence layer protocol for adaptation of the bundle protocol to underlying internetworks. We expect to derive this convergence layer protocol from the Datagram Convergence protocol documented in RFC 7122. o A protocol for remote status monitoring, configuration, and administration of network nodes in the presence of long delays and/or intermittent connectivity. o A functional specification of Contact Graph Routing (CGR) specifyin= g=20 the inputs (global contact schedules, traffic demands, etc.) and=20 outputs (node specific transmission and reception schedules,=20 notifications, etc.). CGR is a centralized, oracle-based bundle=20 transmission and reception scheduling scheme used in space segment= =20 DTN deployments. o An adjunct to the management protocol that will allow the contact=20 schedules generated by CGR to be distributed to nodes. This may be= =20 based on the Contact Plan Update Protocol (CPUP) proposed in =20 o An encapsulation protocol for "tunneling" BP traffic within bundles that are secured and/or routed in different way from the encapsulated bundles. o A registry for DTN Service Identifiers =20 The working group will consider extending the current milestones based = on new information and knowledge gained while working on the initial chart= er, as well as to accommodate new work items beyond the scope of the initia= l phase. For example, we expect that transport protocols such as LTP and the Saratoga protocol are among the candidates for work in this phase. =20 Goals and Milestones: start+0mos - Accept 'Bundle Protocol Specification (RFC5050bis)' [2] as a working group work item intended for Proposed Standard. Start+0mos - Accept 'Streamlined Bundle Security Protocol (SBSP)' [3] as a working group work item intended for Proposed Standard. start+3mos - Accept 'Bundle In Bundle Encapsulation (BIBE)' [4] as a working work item intended for Proposed Standard. start+6mos - Working group getting concensus on changes to be implemented in RFC 5050(bis). start+9mos - Working group getting consensus on merging RFC5050bis, SBSP, BIBE etc. into a combined draft or keep as separate drafts. start+12mos - Accept 'CGR Functional Specification' as a working group=20 working group work item intended for Informational. start+12mos - Accept 'Delay Tolerant Networking Security Key Management' as a working group work item intended for Proposed Standard= . start+15mos - Accept 'Contact Plan Update Protocol' as working group work item intended for Proposed Standard. start+18mos - Submit RFC5050bis, SBSP, BIBE and Key Mgmt to the IESG eith= er as a combined draft or as separate drafts. start+18mos - Submit Network Management [5], Registry [6] and Simple Convergence Layer [7] as working group documents. start+20mos - Survey appropriate forums (e.g., DTNRG) for emerging technologies (e.g., convergence layer protocols, dynamic routing protocols, naming and addressing services, etc.) ready for transition into IETF DTN Working Group. Publish draft on survey results as independent submission related to the WG. start+24mos - Submit Network Management, Registry and Simple Convergence Layer to IESG start+24mos - Recharter to accommodate new work items or close Working Gr= oup [1] "BP/LTP deployment on EPOXI spacecraft" [2008], http://committees.comsoc.org/tccc/ccw/2010/slides/DINET_CCW.pdf =20 [2] "Proposed Revised Bundle Protocol" [2014], https://datatracker.ietf.org/doc/draft-burleigh-bpv7/ [3] "Streamlined Bundle Security Protocol Specification" [2014], https://datatracker.ietf.org/doc/draft-irtf-dtnrg-sbsp/ [4] "Bundle-in-Bundle Encapsulation" [2013], http://tools.ietf.org/id/draft-irtf-burleigh-bibe [5] "Delay Tolerant Network Management Protocol" [2013], http://tools.ietf.org/id/draft-irtf-dtnrg-dtnmp [6] "Delay-Tolerant Networking Bundle Protocol IANA Registries" [2011], https://datatracker.ietf.org/doc/rfc6255/ [7] "Datagram Convergence Layers ..." [2014], https://datatracker.ietf.org/doc/rfc7122/ [8] "Towards Flexibility and Accuracy in Space DTN Communications", Bezirgianndia et al, CHANTS 2012, http://dl.acm.org/citation.cfm?id=3D2505499 [2012] --_002_2134F8430051B64F815C691A62D983183048DB80XCHBLV512nwnosb_ Content-Type: text/html; name="wdiff 04c_txt 04d_txt.htm" Content-Description: wdiff 04c_txt 04d_txt.htm Content-Disposition: attachment; filename="wdiff 04c_txt 04d_txt.htm"; size=35487; creation-date="Tue, 17 Jun 2014 17:36:29 GMT"; modification-date="Tue, 17 Jun 2014 17:36:29 GMT" Content-Transfer-Encoding: base64 CjxodG1sPjxoZWFkPjx0aXRsZT53ZGlmZiAwNGMudHh0IDA0ZC50eHQ8L3RpdGxlPjwvaGVhZD48 Ym9keT4KPHByZT4KRHJhZnQgQm9GIEFnZW5kYSAoMi41aHJzKToKKioqKioqKioqKioqKioqKioq KioqKioqKioKMSkgUHJvYmxlbSBzdGF0ZW1lbnQgKElFVEYgd2cgbW90aXZhdGlvbikgLSAzMG1p bgoKMikgUkZDNTA1MChiaXMpIC0gMTVtaW4KCjMpIFN0cmVhbWxpbmVkIEJ1bmRsZSBTZWN1cml0 eSBQcm90b2NvbCAoU0JTUCkgLSAxNW1pbgoKNCkgU2VjdXJpdHkgS2V5IE1hbmFnZW1lbnQgLSAx MG1pbgoKNSkgTmV0d29yayBNYW5hZ2VtZW50IC0gMTBtaW4KCjYpIENvbnRhY3QgR3JhcGggUm91 dGluZyBhbmQgQ29udGFjdCBQbGFuIFVwZGF0ZSBQcm90b2NvbCAtIDEwbWluCgo3KSBCdW5kbGUt aW4tQnVuZGxlIEVuY2Fwc3VsYXRpb24gLSA1bWluCgo4KSBSZWdpc3RyeSBmb3IgU2VydmljZSBJ ZGVudGlmaWVycyAtIDVtaW4KCjkpIE9wZW4gRGlzY3Vzc2lvbiAtIDUwbWluCgpEcmFmdCB3b3Jr aW5nIGdyb3VwIGNoYXJ0ZXI6CioqKioqKioqKioqKioqKioqKioqKioqKioqKioKV29ya2luZyBn cm91cCBuYW1lOgoKICAgICAgRGVsYXkvRGlzcnVwdGlvbiBUb2xlcmFudCBOZXR3b3JraW5nIFdv cmtpbmcgR3JvdXAgKERUTldHKQoKQ2hhaXIocyk6CgogICAgICBUQkQKCkFyZWEgYW5kIEFyZWEg RGlyZWN0b3Iocyk6CgogICAgICBUcmFuc3BvcnQgQXJlYTogQURzIFNwZW5jZXIgRGF3a2lucyAm bHQ7c3BlbmNlcmRhd2tpbnMuaWV0ZiBhdCBnbWFpbC5jb20mZ3Q7LAogICAgICAgICAgICAgICAg ICAgICAgICAgIE1hcnRpbiBTdGllbWVybGluZyAmbHQ7bWxzLmlldGYgYXQgZ21haWwuY29tJmd0 OwoKUmVzcG9uc2libGUgQXJlYSBEaXJlY3RvcjoKCiAgICAgIFRCRAoKTWFpbGluZyBsaXN0OgoK ICAgICAgR2VuZXJhbCBEaXNjdXNzaW9uOiBkdG4gYXQgaWV0Zi5vcmcKICAgICAgVG8gU3Vic2Ny aWJlOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2R0bgogICAgICBBcmNo aXZlOiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvZHRuL2N1cnJlbnQvbWFp bGxpc3QuaHRtbAoKRGVzY3JpcHRpb24gb2YgV29ya2luZyBHcm91cDoKCiAgICAgIFRoZSBEZWxh eS9EaXNydXB0aW9uIFRvbGVyYW50IE5ldHdvcmsgV29ya2luZyBHcm91cCAoRFROV0cpIHNwZWNp ZmllcwogICAgICBtZWNoYW5pc21zIGZvciBkYXRhIGNvbW11bmljYXRpb25zIGluIHRoZSBwcmVz ZW5jZSBvZiBsb25nIGRlbGF5cwogICAgICBhbmQvb3IgaW50ZXJtaXR0ZW50IGNvbm5lY3Rpdml0 eS4gVGhlIHdvcmsgaXMgbW90aXZhdGVkIGJ5IHdlbGwga25vd24KICAgICAgbGltaXRhdGlvbnMg b2Ygc3RhbmRhcmQgSW50ZXJuZXQgcHJvdG9jb2xzIHRoYXQgZXhwZWN0IGVuZC10by1lbmQKICAg ICAgY29ubmVjdGl2aXR5IGJldHdlZW4gY29tbXVuaWNhdGluZyBlbmRwb2ludHMsIHN1Yi1zZWNv bmQgdHJhbnNtaXNzaW9uCiAgICAgIGRlbGF5cyBhbmQgcm9idXN0IHBhY2tldCBkZWxpdmVyeSBy YXRpb3MuIEluIGVudmlyb25tZW50cyB3aGVyZSB0aGVzZQogICAgICBmYXZvcmFibGUgY29uZGl0 aW9ucyBkbyBub3QgYXBwbHksIGV4aXN0aW5nIG1lY2hhbmlzbXMgZW5jb3VudGVyIHByb2JsZW1z CiAgICAgIHN1Y2ggYXMgcmVsaWFibGUgdHJhbnNwb3J0IHByb3RvY29sIGhhbmRzaGFrZXMgdGlt aW5nIG91dCBhbmQgcm91dGluZwogICAgICBwcm90b2NvbHMgZmFpbGluZyB0byBjb252ZXJnZSBy ZXN1bHRpbmcgaW4gY29tbXVuaWNhdGlvbiBmYWlsdXJlcy4KICAgICAgRnVydGhlcm1vcmUsIGNs YXNzaWNhbCBlbmQtdG8tZW5kIHNlY3VyaXR5IGFzc29jaWF0aW9ucyBjYW5ub3QgYmUKICAgICAg Y29vcmRpbmF0ZWQgd2hlbiBjb21tdW5pY2F0aW5nIGVuZHBvaW50cyBjYW5ub3QgY29uZHVjdCBt dWx0aS1tZXNzYWdlCiAgICAgIGtleWluZyBleGNoYW5nZXMgaW4gYSB0aW1lbHkgZmFzaGlvbi4g VGhlc2UgbGltaXRhdGlvbnMgc3VnZ2VzdGVkIHRoZQogICAgICBuZWVkIGZvciBhIG5ldyBhcHBy b2FjaC4KCiAgICAgIERlbGF5LVRvbGVyYW50IE5ldHdvcmtpbmcgKERUTikgcHJvdG9jb2xzIGhh dmUgYmVlbiB0aGUgc3ViamVjdCBvZgogICAgICBleHRlbnNpdmUgcmVzZWFyY2ggYW5kIGRldmVs b3BtZW50IGluIHRoZSBEZWxheS1Ub2xlcmFudCBOZXR3b3JraW5nCiAgICAgIFJlc2VhcmNoIEdy b3VwIChEVE5SRykgb2YgdGhlIEludGVybmV0IFJlc2VhcmNoIFRhc2sgRm9yY2Ugc2luY2UgMjAw Mi4KICAgICAgVGhlIERUTlJHIGhhcyBkZXZlbG9wZWQgdGhlIERlbGF5LVRvbGVyYW50IE5ldHdv cmtpbmcgQXJjaGl0ZWN0dXJlCiAgICAgIChSRkMgNDgzOCkgdGhhdCB0aGUgRFROV0cgdXNlcyBh cyB0aGUgYmFzaXMgZm9yIGl0cyB3b3JrLiAgVGhlIGtleQogICAgICBjb21wb25lbnRzIG9mIHRo ZSB0aGlzIGFyY2hpdGVjdHVyZSBhcmUgdGhlIGJ1bmRsZSBjb25jZXB0IGZvcgogICAgICBlbmNh cHN1bGF0aW5nIGRhdGEgdW5pdHMsIHRoZSBidW5kbGUgdHJhbnNtaXNzaW9uIHByb3RvY29sIGFu ZCB0aGUKICAgICAgdW5kZXJseWluZyBjb252ZXJnZW5jZSBsYXllciBhcmNoaXRlY3R1cmUuCgog ICAgICBUaGUgZXhwZXJpbWVudGFsIERUTiBCdW5kbGUgUHJvdG9jb2wgKFJGQyA1MDUwKSBhbmQg TGlja2xpZGVyCiAgICAgIFRyYW5zbWlzc2lvbiBQcm90b2NvbCAoUkZDIDUzMjYpIGhhdmUgYmVl biBzaG93biB0byBhZGRyZXNzIHRoZQogICAgICBpc3N1ZXMgaWRlbnRpZmllZCBhYm92ZSBpbiBz dWJzdGFudGlhbCBmaWVsZGVkIGRlcGxveW1lbnRzIGluIHRoZSBzcGFjZQogICAgICBzZWN0b3Ig WzFdLiAgUkZDIDUwNTAgaW4gY29uanVuY3Rpb24gd2l0aCBUQ1AtIGFuZCBVRFAtYmFzZWQgY29u dmVyZ2VuY2UKICAgICAgbGF5ZXJzIGhhcyBiZWVuIHVzZWQgc3VjY2Vzc2Z1bGx5IGluIGEgbnVt YmVyIG9mIGV4cGVyaW1lbnRzIGJvdGggaW4KICAgICAgY29tbXVuaWNhdGlvbnMgY2hhbGxlbmdl ZCBlbnZpcm9ubWVudHMgYXJvdW5kIHRoZSBlZGdlcyBvZiB0aGUgSW50ZXJuZXQKICAgICAgYW5k IGFzIGFuIEludGVybmV0IG92ZXJsYXkgd2hlcmUgYXBwbGljYXRpb25zIHJlcXVpcmUgZGVsYXkt IGFuZC9vcgogICAgICBkaXNydXB0aW9uLXRvbGVyYW5jZSBbcmVmcyBuZWVkZWRdLgoKICAgICAg VGhlIHN1Y2Nlc3Mgb2YgdGhlIEJQIG92ZXIgY29udmVyZ2VuY2UgbGF5ZXIgcHJvdG9jb2wgc3Rh Y2sgLS0gdGhlIGNvcmUKICAgICAgcHJvdG9jb2xzIG9mIHRoZSAiRFROIEFyY2hpdGVjdHVyZSIg ZGVzY3JpYmVkIGluIFJGQyA0ODM4IC0tIG1heSBiZQogICAgICBhdHRyaWJ1dGVkIHRvIHRoZSBm b2xsb3dpbmcgZnVuZGFtZW50YWwgZGVzaWduIHByaW5jaXBsZXM6CgoJLSBUaGVyZSBpcyBuZXZl ciBhbnkgZXhwZWN0YXRpb24gb2YgY29udGVtcG9yYW5lb3VzIGVuZC10by1lbmQKICAgICAgICAg IGNvbm5lY3Rpdml0eSBiZXR3ZWVuIGFueSB0d28gbmV0d29yayBub2Rlcy4KCgktIEJlY2F1c2Ug ZW5kLXRvLWVuZCBjb25uZWN0aXZpdHkgY2FuIG5ldmVyIGJlIGFzc3VtZWQsIGVhY2ggbm9kZQoJ ICBvbiB0aGUgcGF0aCBiZXR3ZWVuIHNvdXJjZSBhbmQgZGVzdGluYXRpb24gbXVzdCBiZSBwcmVw YXJlZCB0bwoJICBoYW5kbGUgaW5jb21pbmcgImJ1bmRsZXMiIG9mIGRhdGEgdGhhdCBjYW5ub3Qg aW1tZWRpYXRlbHkgYmUKCSAgZm9yd2FyZGVkLgoKCS0gQWdhaW4gYmVjYXVzZSBlbmQtdG8tZW5k IGNvbm5lY3Rpdml0eSBjYW4gbmV2ZXIgYmUgYXNzdW1lZCwKCSAgZW5kLXRvLWVuZCBjb252ZXJz YXRpb25hbCBkYXRhIGV4Y2hhbmdlIGNhbiBuZXZlciBiZSBhc3N1bWVkIHRvCgkgIGNvbXBsZXRl IGluIGEgdGltZWx5IG1hbm5lcjsgcHJvdG9jb2wgZmVhdHVyZXMgdGhhdCByZWx5IG9uCgkgIHRp bWVseSBjb252ZXJzYXRpb25hbCBkYXRhIGV4Y2hhbmdlIG11c3QgYmUgZXhjbHVkZWQgZnJvbSB0 aGUKCSAgYXJjaGl0ZWN0dXJlLgoKICAgICAgVGhlIERUTldHIGJlbGlldmVzIHRoYXQgcHJvdG9j b2xzIGFkaGVyaW5nIHRvIHRoZXNlIHByaW5jaXBsZXMgb2ZmZXIKICAgICAgb3Bwb3J0dW5pdGll cyBmb3IgZW5oYW5jaW5nIHRoZSBmdW5jdGlvbmFsaXR5IG9mIHRoZSBJbnRlcm5ldCwgaW5jbHVk aW5nCgogICAgICAgIC0gZmFjaWxpdGF0aW5nIHRoZSBleHRlbnNpb24gb2YgdGhlIEludGVybmV0 IGludG8gZW52aXJvbm1lbnRzIHN1Y2ggYXMKICAgICAgICAgIHRoZSBvY2VhbiBmbG9vciBhbmQg ZGVlcCBzcGFjZSBpbiB3aGljaCB0aGUgY29yZSBJbnRlcm5ldCBwcm90b2NvbHMKICAgICAgICAg IG9wZXJhdGUgc3ViLW9wdGltYWxseSBmb3IgdGhlIHJlYXNvbnMgZGlzY3Vzc2VkIGVhcmxpZXI7 CgogICAgICAgIC0gZXh0ZW5kaW5nIHRoZSBJbnRlcm5ldCBpbnRvIGNvbW11bmljYXRpb25zIGNo YWxsZW5nZWQgdGVycmVzdHJpYWwKICAgICAgICAgIGVudmlyb25tZW50cyB3aGVyZSBpdCBpcyBu b3QgcG9zc2libGUgdG8gcHJvdmlkZSBjb250aW51b3VzLCBsb3cKICAgICAgICAgIGRlbGF5IElu dGVybmV0IGNvbm5lY3Rpb25zOyBhbmQKCiAgICAgICAgLSBzdXBwb3J0aW5nIEludGVybmV0IGFw cGxpY2F0aW9ucyB0aGF0IG5lZWQgRFROIGNhcGFiaWxpaWVzLgoKICAgICAgV2UgYmVsaWV2ZSB0 aGF0IHRoZSBleHRlbnNpdmUgcmVzZWFyY2gsIGRlbW9uc3RyYXRpb24sIGFuZAogICAgICBwaWxv dCBvcGVyYXRpb25zIHBlcmZvcm1lZCB0byBkYXRlIHVzaW5nIHRoZSBEVE5SRyBwcm90b2NvbHMg cHJvdmlkZXMKICAgICAgYSBmaXJtIGJhc2lzIGZvciBwdWJsaXNoaW5nIEludGVybmV0IHN0YW5k YXJkcyBkZXJpdmVkIGZyb20gdGhhdCB3b3JrLgoKICAgICAgV29yayBpdGVtcyByZWxhdGVkIHRv IERlbGF5L0Rpc3J1cHRpb24gVG9sZXJhbnQgTmV0d29ya2luZyBpbmNsdWRlOgoKICAgICAgbyBB IG1lY2hhbmlzbSBmb3IgdGhlIGV4Y2hhbmdlIG9mIHByb3RvY29sIGRhdGEgdW5pdHMsIHRlcm1l ZAoJICAgImJ1bmRsZXMiLCB0aGF0IGFyZSBkZXNpZ25lZCB0byBvYnZpYXRlIGNvbnZlcnNhdGlv bmFsIGNvbW11bmljYXRpb25zCgkgICBieSBjb250YWluaW5nIHZhbHVlcyBmb3IgYWxsIHBvdGVu dGlhbGx5IHJlbGV2YW50IGNvbmZpZ3VyYXRpb24KCSAgIHBhcmFtZXRlcnMuIFRoZXNlIHByb3Rv Y29sIGRhdGEgdW5pdHMgYXJlIHR5cGljYWxseSBsYXJnZXIgdGhhbgoJICAgbmV0d29yay1sYXll ciBwYWNrZXRzLiBXZSB3aWxsIGRlcml2ZSB0aGlzIGJ1bmRsZSBleGNoYW5nZSBtZWNoYW5pc20K ICAgICAgICBmcm9tIHRoZSBEVE4gQnVuZGxlIFByb3RvY29sIChCUCkgZG9jdW1lbnRlZCBpbiBS RkMgNTA1MCBieSBwdWJsaXNoaW5nCiAgICAgICAgYSBuZXcgZG9jdW1lbnQgZm9yIHdoaWNoIFsy XSBpcyBhIHByb3Bvc2VkIGZpcnN0IGRyYWZ0ICh3aGVyZQogICAgICAgIGFwcGVuZGl4IEEgcHJv dmlkZXMgYSBzdW1tYXJ5IG9mIHRoZSBwcm9wb3NlZCBjaGFuZ2VzKS4KCiAgICAgIG8gQSBzZWN1 cml0eSBwcm90b2NvbCBmb3IgZW5zdXJpbmcgdGhhdCB0aGUgbmV0d29yayBpbiB3aGljaCBidW5k bGVzCgkgICBhcmUgZXhjaGFuZ2VkIGlzIHNlY3VyZWQgYWdhaW5zdCB1bmF1dGhvcml6ZWQgYWNj ZXNzIGFuZCBkZW5pYWwgb2YKCSAgIHNlcnZpY2UgYXR0YWNrcywgYW5kIHRvIGVuc3VyZSBkYXRh IGludGVncml0eSBhbmQgY29uZmlkZW50aWFsaXR5CgkgICBpbiB0aGF0IG5ldHdvcmsgd2hlcmUg bmVjZXNzYXJ5LiAgV2Ugd2lsbCBkZXJpdmUgdGhpcyBzZWN1cml0eQoJICAgcHJvdG9jb2wgZnJv bSBhICJzdHJlYW1saW5lZCIgYWRhcHRhdGlvbiBvZiB0aGUgRFROIEJ1bmRsZSBTZWN1cml0eQoJ ICAgUHJvdG9jb2wgZG9jdW1lbnRlZCBpbiBSRkMgNjI1Ny4KCiAgICAgICBvIEEgZGVsYXktdG9s ZXJhbnQgc2VjdXJpdHkga2V5IG1hbmFnZW1lbnQgc2NoZW1lIHRoYXQgY2FuIHByb3RlY3QKICAg ICAgICAgdGhlIGludGVncml0eSBvZiBhIERUTiBuZXR3b3JrLgoKICAgICAgbyBBIHNpbXBsZSBk YXRhZ3JhbSBjb252ZXJnZW5jZSBsYXllciBwcm90b2NvbCBmb3IgYWRhcHRhdGlvbiBvZiB0aGUK ICAgICAgICBidW5kbGUgcHJvdG9jb2wgdG8gdW5kZXJseWluZyBpbnRlcm5ldHdvcmtzLiBXZSBl eHBlY3QgdG8gZGVyaXZlCiAgICAgICAgdGhpcyBjb252ZXJnZW5jZSBsYXllciBwcm90b2NvbCBm cm9tIHRoZSBEYXRhZ3JhbSBDb252ZXJnZW5jZQogICAgICAgIHByb3RvY29sIGRvY3VtZW50ZWQg aW4gUkZDIDcxMjIuCgogICAgICBvIEEgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJyA+ZGVsYXkt dG9sZXJhbnQgbmV0d29yayBtYW5hZ2VtZW50PC9mb250Pjwvc3RyaWtlPiBwcm90b2NvbCBmb3Ig PHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJyA+bWFuYWdlbWVudDwvZm9udD48L3N0cmlrZT4gPHN0 cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nID5yZW1vdGUgc3RhdHVzIG1vbml0b3JpbmcsIGNvbmZp Z3VyYXRpb24sIGFuZAogICAgICAgIGFkbWluaXN0cmF0aW9uPC9mb250Pjwvc3Ryb25nPiBvZiA8 c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnID50aGUKICAgICAgICBpbmZyYXN0cnVjdHVyZTwvZm9u dD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nID5uZXR3b3JrIG5vZGVzPC9m b250Pjwvc3Ryb25nPiBpbiB0aGUgcHJlc2VuY2Ugb2YgbG9uZyBkZWxheXMKICAgICAgICBhbmQv b3IgaW50ZXJtaXR0ZW50IGNvbm5lY3Rpdml0eS4KCiAgICAgIG8gQSBmdW5jdGlvbmFsIHNwZWNp ZmljYXRpb24gb2YgQ29udGFjdCBHcmFwaCBSb3V0aW5nIChDR1IpIHNwZWNpZnlpbmcKICAgICAg ICB0aGUgaW5wdXRzIChnbG9iYWwgY29udGFjdCBzY2hlZHVsZXMsIHRyYWZmaWMgZGVtYW5kcywg ZXRjLikgYW5kCiAgICAgICAgb3V0cHV0cyAobm9kZSBzcGVjaWZpYyB0cmFuc21pc3Npb24gYW5k IHJlY2VwdGlvbiBzY2hlZHVsZXMsCiAgICAgICAgbm90aWZpY2F0aW9ucywgZXRjLikuICBDR1Ig aXMgYSBjZW50cmFsaXplZCwgb3JhY2xlLWJhc2VkIGJ1bmRsZQogICAgICAgIHRyYW5zbWlzc2lv biBhbmQgcmVjZXB0aW9uIHNjaGVkdWxpbmcgc2NoZW1lIHVzZWQgaW4gc3BhY2Ugc2VnbWVudAog ICAgICAgIERUTiBkZXBsb3ltZW50cy4KCiAgICAgIG8gQW4gYWRqdW5jdCB0byB0aGUgbWFuYWdl bWVudCBwcm90b2NvbCB0aGF0IHdpbGwgYWxsb3cgdGhlIGNvbnRhY3QKICAgICAgICBzY2hlZHVs ZXMgZ2VuZXJhdGVkIGJ5IENHUiB0byBiZSBkaXN0cmlidXRlZCB0byBub2Rlcy4gIFRoaXMgbWF5 IGJlCiAgICAgICAgYmFzZWQgb24gdGhlIENvbnRhY3QgUGxhbiBVcGRhdGUgUHJvdG9jb2wgKENQ VVApIHByb3Bvc2VkIGluCgogICAgICBvIEFuIGVuY2Fwc3VsYXRpb24gcHJvdG9jb2wgZm9yICJ0 dW5uZWxpbmciIEJQIHRyYWZmaWMgd2l0aGluIGJ1bmRsZXMKCSAgIHRoYXQgYXJlIHNlY3VyZWQg YW5kL29yIHJvdXRlZCBpbiBkaWZmZXJlbnQgd2F5IGZyb20gdGhlIGVuY2Fwc3VsYXRlZAoJICAg YnVuZGxlcy4KCiAgICAgIG8gQSByZWdpc3RyeSBmb3IgRFROIFNlcnZpY2UgSWRlbnRpZmllcnMK CiAgICBUaGUgd29ya2luZyBncm91cCB3aWxsIGNvbnNpZGVyIGV4dGVuZGluZyB0aGUgY3VycmVu dCBtaWxlc3RvbmVzIGJhc2VkIG9uCiAgICBuZXcgaW5mb3JtYXRpb24gYW5kIGtub3dsZWRnZSBn YWluZWQgd2hpbGUgd29ya2luZyBvbiB0aGUgaW5pdGlhbCBjaGFydGVyLAogICAgYXMgd2VsbCBh cyB0byBhY2NvbW1vZGF0ZSBuZXcgd29yayBpdGVtcyBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoZSBp bml0aWFsCiAgICBwaGFzZS4gIEZvciBleGFtcGxlLCB3ZSBleHBlY3QgdGhhdCB0cmFuc3BvcnQg cHJvdG9jb2xzIHN1Y2ggYXMgTFRQIGFuZAogICAgdGhlIFNhcmF0b2dhIHByb3RvY29sIGFyZSBh bW9uZyB0aGUgY2FuZGlkYXRlcyBmb3Igd29yayBpbiB0aGlzIHBoYXNlLgoKR29hbHMgYW5kIE1p bGVzdG9uZXM6CiAgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJyA+c3RhcnQrM21vczwvZm9udD48 L3N0cmlrZT4KICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicgPnN0YXJ0KzBtb3M8L2ZvbnQ+ PC9zdHJvbmc+IC0gPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJyA+U3VibWl0PC9mb250Pjwvc3Ry aWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicgPkFjY2VwdDwvZm9udD48L3N0cm9uZz4g J0J1bmRsZSBQcm90b2NvbCBTcGVjaWZpY2F0aW9uIChSRkM1MDUwYmlzKScgPHN0cm9uZz48Zm9u dCBjb2xvcj0nZ3JlZW4nID5bMl08L2ZvbnQ+PC9zdHJvbmc+IGFzCiAgICAgICAgICAgICAgIGEg d29ya2luZyBncm91cCA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnID5kb2N1bWVudCBbMl0uIFRv IGJlPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicgPndvcmsgaXRl bSBpbnRlbmRlZCBmb3I8L2ZvbnQ+PC9zdHJvbmc+IFByb3Bvc2VkIFN0YW5kYXJkLgogIDxzdHJp a2U+PGZvbnQgY29sb3I9J3JlZCcgPlN0YXJ0KzNtb3M8L2ZvbnQ+PC9zdHJpa2U+CiAgPHN0cm9u Zz48Zm9udCBjb2xvcj0nZ3JlZW4nID5TdGFydCswbW9zPC9mb250Pjwvc3Ryb25nPiAtIDxzdHJp a2U+PGZvbnQgY29sb3I9J3JlZCcgPlN1Ym1pdDwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9u dCBjb2xvcj0nZ3JlZW4nID5BY2NlcHQ8L2ZvbnQ+PC9zdHJvbmc+ICdTdHJlYW1saW5lZCBCdW5k bGUgU2VjdXJpdHkgUHJvdG9jb2wgKFNCU1ApJyA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicg PlszXTwvZm9udD48L3N0cm9uZz4gYXMKICAgICAgICAgICAgICAgYSB3b3JraW5nIGdyb3VwIDxz dHJpa2U+PGZvbnQgY29sb3I9J3JlZCcgPmRvY3VtZW50IFszXS4gVG8gYmU8L2ZvbnQ+PC9zdHJp a2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJyA+d29yayBpdGVtIGludGVuZGVkIGZvcjwv Zm9udD48L3N0cm9uZz4gUHJvcG9zZWQgU3RhbmRhcmQuCiAgPHN0cmlrZT48Zm9udCBjb2xvcj0n cmVkJyA+c3RhcnQrNm1vczwvZm9udD48L3N0cmlrZT4KICA8c3Ryb25nPjxmb250IGNvbG9yPSdn cmVlbicgPnN0YXJ0KzNtb3M8L2ZvbnQ+PC9zdHJvbmc+IC0gPHN0cmlrZT48Zm9udCBjb2xvcj0n cmVkJyA+U3VibWl0PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicg PkFjY2VwdDwvZm9udD48L3N0cm9uZz4gJ0J1bmRsZSBJbiBCdW5kbGUgRW5jYXBzdWxhdGlvbiAo QklCRSknIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJyA+WzRdPC9mb250Pjwvc3Ryb25nPiBh cyBhCiAgICAgICAgICAgICAgIHdvcmtpbmcKICAgICAgICAgICAgICAgPHN0cmlrZT48Zm9udCBj b2xvcj0ncmVkJyA+Z3JvdXAgZG9jdW1lbnQgWzRdLiBUbyBiZTwvZm9udD48L3N0cmlrZT4gPHN0 cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nID53b3JrIGl0ZW0gaW50ZW5kZWQgZm9yPC9mb250Pjwv c3Ryb25nPiBQcm9wb3NlZCBTdGFuZGFyZC4KICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicg PnN0YXJ0KzZtb3MgLSBXb3JraW5nIGdyb3VwIGdldHRpbmcgY29uY2Vuc3VzIG9uIGNoYW5nZXMg dG8gYmUgaW1wbGVtZW50ZWQKICAgICAgICAgICAgICAgaW4gUkZDIDUwNTAoYmlzKS4KICBzdGFy dCs5bW9zIC0gV29ya2luZyBncm91cCBnZXR0aW5nIGNvbnNlbnN1cyBvbiBtZXJnaW5nIFJGQzUw NTBiaXMsIFNCU1AsCiAgICAgICAgICAgICAgIEJJQkUgZXRjLiBpbnRvIGEgY29tYmluZWQgZHJh ZnQgb3Iga2VlcCBhcyBzZXBhcmF0ZSBkcmFmdHMuPC9mb250Pjwvc3Ryb25nPgogIHN0YXJ0KzEy bW9zIC0gPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJyA+U3VibWl0PC9mb250Pjwvc3RyaWtlPiA8 c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicgPkFjY2VwdDwvZm9udD48L3N0cm9uZz4gJ0NHUiBG dW5jdGlvbmFsIFNwZWNpZmljYXRpb24nIGFzIGEgd29ya2luZyBncm91cAogICAgICAgICAgICAg ICAgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJyA+ZG9jdW1lbnQuIFRvIGJlIGFuIGluZm9ybWF0 aW9uYWwgZG9jdW1lbnQuPC9mb250Pjwvc3RyaWtlPgogICAgICAgICAgICAgICAgPHN0cm9uZz48 Zm9udCBjb2xvcj0nZ3JlZW4nID53b3JraW5nIGdyb3VwIHdvcmsgaXRlbSBpbnRlbmRlZCBmb3Ig SW5mb3JtYXRpb25hbC48L2ZvbnQ+PC9zdHJvbmc+CiAgc3RhcnQrMTJtb3MgLSA8c3RyaWtlPjxm b250IGNvbG9yPSdyZWQnID5TdWJtaXQ8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29s b3I9J2dyZWVuJyA+QWNjZXB0PC9mb250Pjwvc3Ryb25nPiAnRGVsYXkgVG9sZXJhbnQgTmV0d29y a2luZyBTZWN1cml0eSBLZXkgTWFuYWdlbWVudCcKICAgICAgICAgICAgICAgIGFzIGEgd29ya2lu ZyBncm91cCA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnID5kb2N1bWVudC4gVG8gYmU8L2ZvbnQ+ PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJyA+d29yayBpdGVtIGludGVuZGVk IGZvcjwvZm9udD48L3N0cm9uZz4gUHJvcG9zZWQgU3RhbmRhcmQuCiAgc3RhcnQrMTVtb3MgLSA8 c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnID5TdWJtaXQ8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+ PGZvbnQgY29sb3I9J2dyZWVuJyA+QWNjZXB0PC9mb250Pjwvc3Ryb25nPiAnQ29udGFjdCBQbGFu IFVwZGF0ZSBQcm90b2NvbCcgYXMgd29ya2luZyBncm91cAogICAgICAgICAgICAgICAgPHN0cmlr ZT48Zm9udCBjb2xvcj0ncmVkJyA+ZG9jdW1lbnQuICBUbyBiZSBQcm9wb3NlZCBTdGFuZGFxcXJk LgogIHN0YXJ0KzE4bW9zIC0gV0cgZGV0ZXJtaW5hdGlvbjwvZm9udD48L3N0cmlrZT4gPHN0cm9u Zz48Zm9udCBjb2xvcj0nZ3JlZW4nID53b3JrCiAgICAgICAgICAgICAgICBpdGVtIGludGVuZGVk PC9mb250Pjwvc3Ryb25nPiBmb3IgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJyA+bWVyZ2luZyBS RkM1MDUwYmlzLCBTQlNQLCBCSUJFIGFuZC9vcgogICAgICAgICAgICAgICAgS2V5IE1nbXQgaW50 byBhIGNvbWJpbmVkIGRyYWZ0IG9yIGtlZXAgYXMgc2VwYXJhdGUgZHJhZnRzLjwvZm9udD48L3N0 cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nID5Qcm9wb3NlZCBTdGFuZGFyZC48L2Zv bnQ+PC9zdHJvbmc+CiAgc3RhcnQrMThtb3MgLSBTdWJtaXQgUkZDNTA1MGJpcywgU0JTUCwgQklC RSBhbmQgS2V5IE1nbXQgdG8gdGhlIElFU0cgZWl0aGVyCiAgICAgICAgICAgICAgICBhcyBhIGNv bWJpbmVkIGRyYWZ0IG9yIGFzIHNlcGFyYXRlIGRyYWZ0cy4KICBzdGFydCsxOG1vcyAtIFN1Ym1p dCBOZXR3b3JrIE1hbmFnZW1lbnQgWzVdLCBSZWdpc3RyeSBbNl0gYW5kIFNpbXBsZQogICAgICAg ICAgICAgICAgQ29udmVyZ2VuY2UgTGF5ZXIgWzddIGFzIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnRz LgogIHN0YXJ0KzIwbW9zIC0gU3VydmV5IGFwcHJvcHJpYXRlIGZvcnVtcyAoZS5nLiwgRFROUkcp IGZvciBlbWVyZ2luZwogICAgICAgICAgICAgICAgdGVjaG5vbG9naWVzIChlLmcuLCBjb252ZXJn ZW5jZSBsYXllciBwcm90b2NvbHMsIGR5bmFtaWMKICAgICAgICAgICAgICAgIHJvdXRpbmcgcHJv dG9jb2xzLCBuYW1pbmcgYW5kIGFkZHJlc3Npbmcgc2VydmljZXMsIGV0Yy4pCiAgICAgICAgICAg ICAgICByZWFkeSBmb3IgdHJhbnNpdGlvbiBpbnRvIElFVEYgRFROIFdvcmtpbmcgR3JvdXAuIFB1 Ymxpc2gKICAgICAgICAgICAgICAgIGRyYWZ0IG9uIHN1cnZleSByZXN1bHRzIGFzIGluZGVwZW5k ZW50IHN1Ym1pc3Npb24gcmVsYXRlZAogICAgICAgICAgICAgICAgdG8gdGhlIFdHLgogIHN0YXJ0 KzI0bW9zIC0gU3VibWl0IE5ldHdvcmsgTWFuYWdlbWVudCwgUmVnaXN0cnkgYW5kIFNpbXBsZSBD b252ZXJnZW5jZQogICAgICAgICAgICAgICAgTGF5ZXIgdG8gSUVTRwogIHN0YXJ0KzI0bW9zIC0g UmVjaGFydGVyIHRvIGFjY29tbW9kYXRlIG5ldyB3b3JrIGl0ZW1zIG9yIGNsb3NlIFdvcmtpbmcg R3JvdXAKClsxXSAiQlAvTFRQIGRlcGxveW1lbnQgb24gRVBPWEkgc3BhY2VjcmFmdCIgWzIwMDhd LAogICAgaHR0cDovL2NvbW1pdHRlZXMuY29tc29jLm9yZy90Y2NjL2Njdy8yMDEwL3NsaWRlcy9E SU5FVF9DQ1cucGRmClsyXSAiUHJvcG9zZWQgUmV2aXNlZCBCdW5kbGUgUHJvdG9jb2wiIFsyMDE0 XSwKICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJ1cmxlaWdoLWJw djcvClszXSAiU3RyZWFtbGluZWQgQnVuZGxlIFNlY3VyaXR5IFByb3RvY29sIFNwZWNpZmljYXRp b24iIFsyMDE0XSwKICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWly dGYtZHRucmctc2JzcC8KWzRdICJCdW5kbGUtaW4tQnVuZGxlIEVuY2Fwc3VsYXRpb24iIFsyMDEz XSwKICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1pcnRmLWJ1cmxlaWdoLWJpYmUK WzVdICJEZWxheSBUb2xlcmFudCBOZXR3b3JrIE1hbmFnZW1lbnQgUHJvdG9jb2wiIFsyMDEzXSwK ICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1pcnRmLWR0bnJnLWR0bm1wCls2XSAi RGVsYXktVG9sZXJhbnQgTmV0d29ya2luZyBCdW5kbGUgUHJvdG9jb2wgSUFOQSBSZWdpc3RyaWVz IiBbMjAxMV0sCiAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9yZmM2MjU1Lwpb N10gIkRhdGFncmFtIENvbnZlcmdlbmNlIExheWVycyAuLi4iIFsyMDE0XSwKICAgIGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL3JmYzcxMjIvCls4XSAiVG93YXJkcyBGbGV4aWJpbGl0 eSBhbmQgQWNjdXJhY3kgaW4gU3BhY2UgRFROIENvbW11bmljYXRpb25zIiwKICAgIEJlemlyZ2lh bm5kaWEgZXQgYWwsIENIQU5UUyAyMDEyLAogICAgaHR0cDovL2RsLmFjbS5vcmcvY2l0YXRpb24u Y2ZtP2lkPTI1MDU0OTkgWzIwMTJdCjwvcHJlPgo8L2JvZHk+PC9odG1sPgpYLUdlbmVyYXRvcjog cHlodCAwLjM1Cgo8IS0tIGFyZ3M6IHsnLS1vbGRjb2xvdXInOiAncmVkJywgJy0td2lkdGgnOiAn JywgJ2RpZmZ0eXBlJzogJy0taHdkaWZmJywgJ2ZpbGVuYW1lMic6ICdEcmFmdCBCb0YgQWdlbmRh ICgyLjVocnMpOlxyXG4qKioqKioqKioqKioqKioqKioqKioqKioqKlxyXG4xKSBQcm9ibGVtIHN0 YXRlbWVudCAoSUVURiB3ZyBtb3RpdmF0aW9uKSAtIDMwbWluXHJcblxyXG4yKSBSRkM1MDUwKGJp cykgLSAxNW1pblxyXG5cclxuMykgU3RyZWFtbGluZWQgQnVuZGxlIFNlY3VyaXR5IFByb3RvY29s IChTQlNQKSAtIDE1bWluXHJcblxyXG40KSBTZWN1cml0eSBLZXkgTWFuYWdlbWVudCAtIDEwbWlu XHJcblxyXG41KSBOZXR3b3JrIE1hbmFnZW1lbnQgLSAxMG1pblxyXG5cclxuNikgQ29udGFjdCBH cmFwaCBSb3V0aW5nIGFuZCBDb250YWN0IFBsYW4gVXBkYXRlIFByb3RvY29sIC0gMTBtaW5cclxu XHJcbjcpIEJ1bmRsZS1pbi1CdW5kbGUgRW5jYXBzdWxhdGlvbiAtIDVtaW5cclxuXHJcbjgpIFJl Z2lzdHJ5IGZvciBTZXJ2aWNlIElkZW50aWZpZXJzIC0gNW1pblxyXG5cclxuOSkgT3BlbiBEaXNj dXNzaW9uIC0gNTBtaW5cclxuXHJcblxyXG5EcmFmdCB3b3JraW5nIGdyb3VwIGNoYXJ0ZXI6XHJc bioqKioqKioqKioqKioqKioqKioqKioqKioqKipcclxuV29ya2luZyBncm91cCBuYW1lOiBcclxu XHJcbiAgICAgIERlbGF5L0Rpc3J1cHRpb24gVG9sZXJhbnQgTmV0d29ya2luZyBXb3JraW5nIEdy b3VwIChEVE5XRylcclxuXHJcbkNoYWlyKHMpOlxyXG5cclxuICAgICAgVEJEXHJcblxyXG5BcmVh IGFuZCBBcmVhIERpcmVjdG9yKHMpOlxyXG5cclxuICAgICAgVHJhbnNwb3J0IEFyZWE6IEFEcyBT cGVuY2VyIERhd2tpbnMgX3NwZW5jZXJkYXdraW5zLmlldGYgYXQgZ21haWwuY29tXyxcclxuICAg ICAgICAgICAgICAgICAgICAgICAgICBNYXJ0aW4gU3RpZW1lcmxpbmcgX21scy5pZXRmIGF0IGdt YWlsLmNvbV9cclxuXHJcblJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3I6XHJcblxyXG4gICAgICBU QkRcclxuXHJcbk1haWxpbmcgbGlzdDpcclxuXHJcbiAgICAgIEdlbmVyYWwgRGlzY3Vzc2lvbjog ZHRuIGF0IGlldGYub3JnXHJcbiAgICAgIFRvIFN1YnNjcmliZTogaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9kdG5cclxuICAgICAgQXJjaGl2ZTogaHR0cDovL3d3dy5pZXRm Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL2R0bi9jdXJyZW50L21haWxsaXN0Lmh0bWxcclxuXHJcbkRl c2NyaXB0aW9uIG9mIFdvcmtpbmcgR3JvdXA6XHJcblxyXG4gICAgICBUaGUgRGVsYXkvRGlzcnVw dGlvbiBUb2xlcmFudCBOZXR3b3JrIFdvcmtpbmcgR3JvdXAgKERUTldHKSBzcGVjaWZpZXNcclxu ICAgICAgbWVjaGFuaXNtcyBmb3IgZGF0YSBjb21tdW5pY2F0aW9ucyBpbiB0aGUgcHJlc2VuY2Ug b2YgbG9uZyBkZWxheXNcclxuICAgICAgYW5kL29yIGludGVybWl0dGVudCBjb25uZWN0aXZpdHku IFRoZSB3b3JrIGlzIG1vdGl2YXRlZCBieSB3ZWxsIGtub3duXHJcbiAgICAgIGxpbWl0YXRpb25z IG9mIHN0YW5kYXJkIEludGVybmV0IHByb3RvY29scyB0aGF0IGV4cGVjdCBlbmQtdG8tZW5kXHJc biAgICAgIGNvbm5lY3Rpdml0eSBiZXR3ZWVuIGNvbW11bmljYXRpbmcgZW5kcG9pbnRzLCBzdWIt c2Vjb25kIHRyYW5zbWlzc2lvblxyXG4gICAgICBkZWxheXMgYW5kIHJvYnVzdCBwYWNrZXQgZGVs aXZlcnkgcmF0aW9zLiBJbiBlbnZpcm9ubWVudHMgd2hlcmUgdGhlc2VcclxuICAgICAgZmF2b3Jh YmxlIGNvbmRpdGlvbnMgZG8gbm90IGFwcGx5LCBleGlzdGluZyBtZWNoYW5pc21zIGVuY291bnRl ciBwcm9ibGVtcyBcclxuICAgICAgc3VjaCBhcyByZWxpYWJsZSB0cmFuc3BvcnQgcHJvdG9jb2wg aGFuZHNoYWtlcyB0aW1pbmcgb3V0IGFuZCByb3V0aW5nIFxyXG4gICAgICBwcm90b2NvbHMgZmFp bGluZyB0byBjb252ZXJnZSByZXN1bHRpbmcgaW4gY29tbXVuaWNhdGlvbiBmYWlsdXJlcy4gXHJc biAgICAgIEZ1cnRoZXJtb3JlLCBjbGFzc2ljYWwgZW5kLXRvLWVuZCBzZWN1cml0eSBhc3NvY2lh dGlvbnMgY2Fubm90IGJlIFxyXG4gICAgICBjb29yZGluYXRlZCB3aGVuIGNvbW11bmljYXRpbmcg ZW5kcG9pbnRzIGNhbm5vdCBjb25kdWN0IG11bHRpLW1lc3NhZ2UgXHJcbiAgICAgIGtleWluZyBl eGNoYW5nZXMgaW4gYSB0aW1lbHkgZmFzaGlvbi4gVGhlc2UgbGltaXRhdGlvbnMgc3VnZ2VzdGVk IHRoZSBcclxuICAgICAgbmVlZCBmb3IgYSBuZXcgYXBwcm9hY2guIFxyXG4gICAgICBcclxuICAg ICAgRGVsYXktVG9sZXJhbnQgTmV0d29ya2luZyAoRFROKSBwcm90b2NvbHMgaGF2ZSBiZWVuIHRo ZSBzdWJqZWN0IG9mXHJcbiAgICAgIGV4dGVuc2l2ZSByZXNlYXJjaCBhbmQgZGV2ZWxvcG1lbnQg aW4gdGhlIERlbGF5LVRvbGVyYW50IE5ldHdvcmtpbmdcclxuICAgICAgUmVzZWFyY2ggR3JvdXAg KERUTlJHKSBvZiB0aGUgSW50ZXJuZXQgUmVzZWFyY2ggVGFzayBGb3JjZSBzaW5jZSAyMDAyLlxy XG4gICAgICBUaGUgRFROUkcgaGFzIGRldmVsb3BlZCB0aGUgRGVsYXktVG9sZXJhbnQgTmV0d29y a2luZyBBcmNoaXRlY3R1cmUgXHJcbiAgICAgIChSRkMgNDgzOCkgdGhhdCB0aGUgRFROV0cgdXNl cyBhcyB0aGUgYmFzaXMgZm9yIGl0cyB3b3JrLiAgVGhlIGtleSBcclxuICAgICAgY29tcG9uZW50 cyBvZiB0aGUgdGhpcyBhcmNoaXRlY3R1cmUgYXJlIHRoZSBidW5kbGUgY29uY2VwdCBmb3IgXHJc biAgICAgIGVuY2Fwc3VsYXRpbmcgZGF0YSB1bml0cywgdGhlIGJ1bmRsZSB0cmFuc21pc3Npb24g cHJvdG9jb2wgYW5kIHRoZSBcclxuICAgICAgdW5kZXJseWluZyBjb252ZXJnZW5jZSBsYXllciBh cmNoaXRlY3R1cmUuXHJcbiAgICBcclxuICAgICAgVGhlIGV4cGVyaW1lbnRhbCBEVE4gQnVuZGxl IFByb3RvY29sIChSRkMgNTA1MCkgYW5kIExpY2tsaWRlclxyXG4gICAgICBUcmFuc21pc3Npb24g UHJvdG9jb2wgKFJGQyA1MzI2KSBoYXZlIGJlZW4gc2hvd24gdG8gYWRkcmVzcyB0aGVcclxuICAg ICAgaXNzdWVzIGlkZW50aWZpZWQgYWJvdmUgaW4gc3Vic3RhbnRpYWwgZmllbGRlZCBkZXBsb3lt ZW50cyBpbiB0aGUgc3BhY2UgXHJcbiAgICAgIHNlY3RvciBbMV0uICBSRkMgNTA1MCBpbiBjb25q dW5jdGlvbiB3aXRoIFRDUC0gYW5kIFVEUC1iYXNlZCBjb252ZXJnZW5jZSBcclxuICAgICAgbGF5 ZXJzIGhhcyBiZWVuIHVzZWQgc3VjY2Vzc2Z1bGx5IGluIGEgbnVtYmVyIG9mIGV4cGVyaW1lbnRz IGJvdGggaW4gXHJcbiAgICAgIGNvbW11bmljYXRpb25zIGNoYWxsZW5nZWQgZW52aXJvbm1lbnRz IGFyb3VuZCB0aGUgZWRnZXMgb2YgdGhlIEludGVybmV0IFxyXG4gICAgICBhbmQgYXMgYW4gSW50 ZXJuZXQgb3ZlcmxheSB3aGVyZSBhcHBsaWNhdGlvbnMgcmVxdWlyZSBkZWxheS0gYW5kL29yIFxy XG4gICAgICBkaXNydXB0aW9uLXRvbGVyYW5jZSBbcmVmcyBuZWVkZWRdLiAgXHJcblxyXG4gICAg ICBUaGUgc3VjY2VzcyBvZiB0aGUgQlAgb3ZlciBjb252ZXJnZW5jZSBsYXllciBwcm90b2NvbCBz dGFjayAtLSB0aGUgY29yZSBcclxuICAgICAgcHJvdG9jb2xzIG9mIHRoZSAiRFROIEFyY2hpdGVj dHVyZSIgZGVzY3JpYmVkIGluIFJGQyA0ODM4IC0tIG1heSBiZSBcclxuICAgICAgYXR0cmlidXRl ZCB0byB0aGUgZm9sbG93aW5nIGZ1bmRhbWVudGFsIGRlc2lnbiBwcmluY2lwbGVzOlxyXG5cclxu XHQtIFRoZXJlIGlzIG5ldmVyIGFueSBleHBlY3RhdGlvbiBvZiBjb250ZW1wb3JhbmVvdXMgZW5k LXRvLWVuZFxyXG4gICAgICAgICAgY29ubmVjdGl2aXR5IGJldHdlZW4gYW55IHR3byBuZXR3b3Jr IG5vZGVzLlxyXG5cclxuXHQtIEJlY2F1c2UgZW5kLXRvLWVuZCBjb25uZWN0aXZpdHkgY2FuIG5l dmVyIGJlIGFzc3VtZWQsIGVhY2ggbm9kZVxyXG5cdCAgb24gdGhlIHBhdGggYmV0d2VlbiBzb3Vy Y2UgYW5kIGRlc3RpbmF0aW9uIG11c3QgYmUgcHJlcGFyZWQgdG9cclxuXHQgIGhhbmRsZSBpbmNv bWluZyAiYnVuZGxlcyIgb2YgZGF0YSB0aGF0IGNhbm5vdCBpbW1lZGlhdGVseSBiZVxyXG5cdCAg Zm9yd2FyZGVkLlxyXG5cclxuXHQtIEFnYWluIGJlY2F1c2UgZW5kLXRvLWVuZCBjb25uZWN0aXZp dHkgY2FuIG5ldmVyIGJlIGFzc3VtZWQsXHJcblx0ICBlbmQtdG8tZW5kIGNvbnZlcnNhdGlvbmFs IGRhdGEgZXhjaGFuZ2UgY2FuIG5ldmVyIGJlIGFzc3VtZWQgdG9cclxuXHQgIGNvbXBsZXRlIGlu IGEgdGltZWx5IG1hbm5lcjsgcHJvdG9jb2wgZmVhdHVyZXMgdGhhdCByZWx5IG9uXHJcblx0ICB0 aW1lbHkgY29udmVyc2F0aW9uYWwgZGF0YSBleGNoYW5nZSBtdXN0IGJlIGV4Y2x1ZGVkIGZyb20g dGhlXHJcblx0ICBhcmNoaXRlY3R1cmUuXHJcblxyXG4gICAgICBUaGUgRFROV0cgYmVsaWV2ZXMg dGhhdCBwcm90b2NvbHMgYWRoZXJpbmcgdG8gdGhlc2UgcHJpbmNpcGxlcyBvZmZlclxyXG4gICAg ICBvcHBvcnR1bml0aWVzIGZvciBlbmhhbmNpbmcgdGhlIGZ1bmN0aW9uYWxpdHkgb2YgdGhlIElu dGVybmV0LCBpbmNsdWRpbmcgXHJcblxyXG4gICAgICAgIC0gZmFjaWxpdGF0aW5nIHRoZSBleHRl bnNpb24gb2YgdGhlIEludGVybmV0IGludG8gZW52aXJvbm1lbnRzIHN1Y2ggYXMgXHJcbiAgICAg ICAgICB0aGUgb2NlYW4gZmxvb3IgYW5kIGRlZXAgc3BhY2UgaW4gd2hpY2ggdGhlIGNvcmUgSW50 ZXJuZXQgcHJvdG9jb2xzIFxyXG4gICAgICAgICAgb3BlcmF0ZSBzdWItb3B0aW1hbGx5IGZvciB0 aGUgcmVhc29ucyBkaXNjdXNzZWQgZWFybGllcjtcclxuXHJcbiAgICAgICAgLSBleHRlbmRpbmcg dGhlIEludGVybmV0IGludG8gY29tbXVuaWNhdGlvbnMgY2hhbGxlbmdlZCB0ZXJyZXN0cmlhbCBc clxuICAgICAgICAgIGVudmlyb25tZW50cyB3aGVyZSBpdCBpcyBub3QgcG9zc2libGUgdG8gcHJv dmlkZSBjb250aW51b3VzLCBsb3cgXHJcbiAgICAgICAgICBkZWxheSBJbnRlcm5ldCBjb25uZWN0 aW9uczsgYW5kIFxyXG5cclxuICAgICAgICAtIHN1cHBvcnRpbmcgSW50ZXJuZXQgYXBwbGljYXRp b25zIHRoYXQgbmVlZCBEVE4gY2FwYWJpbGlpZXMuXHJcblxyXG4gICAgICBXZSBiZWxpZXZlIHRo YXQgdGhlIGV4dGVuc2l2ZSByZXNlYXJjaCwgZGVtb25zdHJhdGlvbiwgYW5kXHJcbiAgICAgIHBp bG90IG9wZXJhdGlvbnMgcGVyZm9ybWVkIHRvIGRhdGUgdXNpbmcgdGhlIERUTlJHIHByb3RvY29s cyBwcm92aWRlc1xyXG4gICAgICBhIGZpcm0gYmFzaXMgZm9yIHB1Ymxpc2hpbmcgSW50ZXJuZXQg c3RhbmRhcmRzIGRlcml2ZWQgZnJvbSB0aGF0IHdvcmsuXHJcblxyXG4gICAgICBXb3JrIGl0ZW1z IHJlbGF0ZWQgdG8gRGVsYXkvRGlzcnVwdGlvbiBUb2xlcmFudCBOZXR3b3JraW5nIGluY2x1ZGU6 XHJcblxyXG4gICAgICBvIEEgbWVjaGFuaXNtIGZvciB0aGUgZXhjaGFuZ2Ugb2YgcHJvdG9jb2wg ZGF0YSB1bml0cywgdGVybWVkXHJcblx0ICAgImJ1bmRsZXMiLCB0aGF0IGFyZSBkZXNpZ25lZCB0 byBvYnZpYXRlIGNvbnZlcnNhdGlvbmFsIGNvbW11bmljYXRpb25zXHJcblx0ICAgYnkgY29udGFp bmluZyB2YWx1ZXMgZm9yIGFsbCBwb3RlbnRpYWxseSByZWxldmFudCBjb25maWd1cmF0aW9uXHJc blx0ICAgcGFyYW1ldGVycy4gVGhlc2UgcHJvdG9jb2wgZGF0YSB1bml0cyBhcmUgdHlwaWNhbGx5 IGxhcmdlciB0aGFuXHJcblx0ICAgbmV0d29yay1sYXllciBwYWNrZXRzLiBXZSB3aWxsIGRlcml2 ZSB0aGlzIGJ1bmRsZSBleGNoYW5nZSBtZWNoYW5pc21cclxuICAgICAgICBmcm9tIHRoZSBEVE4g QnVuZGxlIFByb3RvY29sIChCUCkgZG9jdW1lbnRlZCBpbiBSRkMgNTA1MCBieSBwdWJsaXNoaW5n XHJcbiAgICAgICAgYSBuZXcgZG9jdW1lbnQgZm9yIHdoaWNoIFsyXSBpcyBhIHByb3Bvc2VkIGZp cnN0IGRyYWZ0ICh3aGVyZVxyXG4gICAgICAgIGFwcGVuZGl4IEEgcHJvdmlkZXMgYSBzdW1tYXJ5 IG9mIHRoZSBwcm9wb3NlZCBjaGFuZ2VzKS5cclxuXHJcbiAgICAgIG8gQSBzZWN1cml0eSBwcm90 b2NvbCBmb3IgZW5zdXJpbmcgdGhhdCB0aGUgbmV0d29yayBpbiB3aGljaCBidW5kbGVzXHJcblx0 ICAgYXJlIGV4Y2hhbmdlZCBpcyBzZWN1cmVkIGFnYWluc3QgdW5hdXRob3JpemVkIGFjY2VzcyBh bmQgZGVuaWFsIG9mXHJcblx0ICAgc2VydmljZSBhdHRhY2tzLCBhbmQgdG8gZW5zdXJlIGRhdGEg aW50ZWdyaXR5IGFuZCBjb25maWRlbnRpYWxpdHlcclxuXHQgICBpbiB0aGF0IG5ldHdvcmsgd2hl cmUgbmVjZXNzYXJ5LiAgV2Ugd2lsbCBkZXJpdmUgdGhpcyBzZWN1cml0eVxyXG5cdCAgIHByb3Rv Y29sIGZyb20gYSAic3RyZWFtbGluZWQiIGFkYXB0YXRpb24gb2YgdGhlIERUTiBCdW5kbGUgU2Vj dXJpdHlcclxuXHQgICBQcm90b2NvbCBkb2N1bWVudGVkIGluIFJGQyA2MjU3LlxyXG5cclxuICAg ICAgIG8gQSBkZWxheS10b2xlcmFudCBzZWN1cml0eSBrZXkgbWFuYWdlbWVudCBzY2hlbWUgdGhh dCBjYW4gcHJvdGVjdFxyXG4gICAgICAgICB0aGUgaW50ZWdyaXR5IG9mIGEgRFROIG5ldHdvcmsu XHJcblxyXG4gICAgICBvIEEgc2ltcGxlIGRhdGFncmFtIGNvbnZlcmdlbmNlIGxheWVyIHByb3Rv Y29sIGZvciBhZGFwdGF0aW9uIG9mIHRoZVxyXG4gICAgICAgIGJ1bmRsZSBwcm90b2NvbCB0byB1 bmRlcmx5aW5nIGludGVybmV0d29ya3MuIFdlIGV4cGVjdCB0byBkZXJpdmVcclxuICAgICAgICB0 aGlzIGNvbnZlcmdlbmNlIGxheWVyIHByb3RvY29sIGZyb20gdGhlIERhdGFncmFtIENvbnZlcmdl bmNlXHJcbiAgICAgICAgcHJvdG9jb2wgZG9jdW1lbnRlZCBpbiBSRkMgNzEyMi5cclxuXHJcbiAg ICAgIG8gQSBwcm90b2NvbCBmb3IgcmVtb3RlIHN0YXR1cyBtb25pdG9yaW5nLCBjb25maWd1cmF0 aW9uLCBhbmRcclxuICAgICAgICBhZG1pbmlzdHJhdGlvbiBvZiBuZXR3b3JrIG5vZGVzIGluIHRo ZSBwcmVzZW5jZSBvZiBsb25nIGRlbGF5c1xyXG4gICAgICAgIGFuZC9vciBpbnRlcm1pdHRlbnQg Y29ubmVjdGl2aXR5LlxyXG5cclxuICAgICAgbyBBIGZ1bmN0aW9uYWwgc3BlY2lmaWNhdGlvbiBv ZiBDb250YWN0IEdyYXBoIFJvdXRpbmcgKENHUikgc3BlY2lmeWluZyBcclxuICAgICAgICB0aGUg aW5wdXRzIChnbG9iYWwgY29udGFjdCBzY2hlZHVsZXMsIHRyYWZmaWMgZGVtYW5kcywgZXRjLikg YW5kIFxyXG4gICAgICAgIG91dHB1dHMgKG5vZGUgc3BlY2lmaWMgdHJhbnNtaXNzaW9uIGFuZCBy ZWNlcHRpb24gc2NoZWR1bGVzLCBcclxuICAgICAgICBub3RpZmljYXRpb25zLCBldGMuKS4gIENH UiBpcyBhIGNlbnRyYWxpemVkLCBvcmFjbGUtYmFzZWQgYnVuZGxlIFxyXG4gICAgICAgIHRyYW5z bWlzc2lvbiBhbmQgcmVjZXB0aW9uIHNjaGVkdWxpbmcgc2NoZW1lIHVzZWQgaW4gc3BhY2Ugc2Vn bWVudCBcclxuICAgICAgICBEVE4gZGVwbG95bWVudHMuXHJcblxyXG4gICAgICBvIEFuIGFkanVu Y3QgdG8gdGhlIG1hbmFnZW1lbnQgcHJvdG9jb2wgdGhhdCB3aWxsIGFsbG93IHRoZSBjb250YWN0 IFxyXG4gICAgICAgIHNjaGVkdWxlcyBnZW5lcmF0ZWQgYnkgQ0dSIHRvIGJlIGRpc3RyaWJ1dGVk IHRvIG5vZGVzLiAgVGhpcyBtYXkgYmUgXHJcbiAgICAgICAgYmFzZWQgb24gdGhlIENvbnRhY3Qg UGxhbiBVcGRhdGUgUHJvdG9jb2wgKENQVVApIHByb3Bvc2VkIGluICBcclxuXHJcbiAgICAgIG8g QW4gZW5jYXBzdWxhdGlvbiBwcm90b2NvbCBmb3IgInR1bm5lbGluZyIgQlAgdHJhZmZpYyB3aXRo aW4gYnVuZGxlc1xyXG5cdCAgIHRoYXQgYXJlIHNlY3VyZWQgYW5kL29yIHJvdXRlZCBpbiBkaWZm ZXJlbnQgd2F5IGZyb20gdGhlIGVuY2Fwc3VsYXRlZFxyXG5cdCAgIGJ1bmRsZXMuXHJcblxyXG4g ICAgICBvIEEgcmVnaXN0cnkgZm9yIERUTiBTZXJ2aWNlIElkZW50aWZpZXJzXHJcbiAgXHJcbiAg ICBUaGUgd29ya2luZyBncm91cCB3aWxsIGNvbnNpZGVyIGV4dGVuZGluZyB0aGUgY3VycmVudCBt aWxlc3RvbmVzIGJhc2VkIG9uXHJcbiAgICBuZXcgaW5mb3JtYXRpb24gYW5kIGtub3dsZWRnZSBn YWluZWQgd2hpbGUgd29ya2luZyBvbiB0aGUgaW5pdGlhbCBjaGFydGVyLFxyXG4gICAgYXMgd2Vs bCBhcyB0byBhY2NvbW1vZGF0ZSBuZXcgd29yayBpdGVtcyBiZXlvbmQgdGhlIHNjb3BlIG9mIHRo ZSBpbml0aWFsXHJcbiAgICBwaGFzZS4gIEZvciBleGFtcGxlLCB3ZSBleHBlY3QgdGhhdCB0cmFu c3BvcnQgcHJvdG9jb2xzIHN1Y2ggYXMgTFRQIGFuZFxyXG4gICAgdGhlIFNhcmF0b2dhIHByb3Rv Y29sIGFyZSBhbW9uZyB0aGUgY2FuZGlkYXRlcyBmb3Igd29yayBpbiB0aGlzIHBoYXNlLlxyXG4g ICAgXHJcbkdvYWxzIGFuZCBNaWxlc3RvbmVzOlxyXG4gIHN0YXJ0KzBtb3MgLSBBY2NlcHQgXCdC dW5kbGUgUHJvdG9jb2wgU3BlY2lmaWNhdGlvbiAoUkZDNTA1MGJpcylcJyBbMl0gYXNcclxuICAg ICAgICAgICAgICAgYSB3b3JraW5nIGdyb3VwIHdvcmsgaXRlbSBpbnRlbmRlZCBmb3IgUHJvcG9z ZWQgU3RhbmRhcmQuXHJcbiAgU3RhcnQrMG1vcyAtIEFjY2VwdCBcJ1N0cmVhbWxpbmVkIEJ1bmRs ZSBTZWN1cml0eSBQcm90b2NvbCAoU0JTUClcJyBbM10gYXNcclxuICAgICAgICAgICAgICAgYSB3 b3JraW5nIGdyb3VwIHdvcmsgaXRlbSBpbnRlbmRlZCBmb3IgUHJvcG9zZWQgU3RhbmRhcmQuXHJc biAgc3RhcnQrM21vcyAtIEFjY2VwdCBcJ0J1bmRsZSBJbiBCdW5kbGUgRW5jYXBzdWxhdGlvbiAo QklCRSlcJyBbNF0gYXMgYVxyXG4gICAgICAgICAgICAgICB3b3JraW5nIHdvcmsgaXRlbSBpbnRl bmRlZCBmb3IgUHJvcG9zZWQgU3RhbmRhcmQuXHJcbiAgc3RhcnQrNm1vcyAtIFdvcmtpbmcgZ3Jv dXAgZ2V0dGluZyBjb25jZW5zdXMgb24gY2hhbmdlcyB0byBiZSBpbXBsZW1lbnRlZFxyXG4gICAg ICAgICAgICAgICBpbiBSRkMgNTA1MChiaXMpLlxyXG4gIHN0YXJ0Kzltb3MgLSBXb3JraW5nIGdy b3VwIGdldHRpbmcgY29uc2Vuc3VzIG9uIG1lcmdpbmcgUkZDNTA1MGJpcywgU0JTUCxcclxuICAg ICAgICAgICAgICAgQklCRSBldGMuIGludG8gYSBjb21iaW5lZCBkcmFmdCBvciBrZWVwIGFzIHNl cGFyYXRlIGRyYWZ0cy5cclxuICBzdGFydCsxMm1vcyAtIEFjY2VwdCBcJ0NHUiBGdW5jdGlvbmFs IFNwZWNpZmljYXRpb25cJyBhcyBhIHdvcmtpbmcgZ3JvdXAgXHJcbiAgICAgICAgICAgICAgICB3 b3JraW5nIGdyb3VwIHdvcmsgaXRlbSBpbnRlbmRlZCBmb3IgSW5mb3JtYXRpb25hbC5cclxuICBz dGFydCsxMm1vcyAtIEFjY2VwdCBcJ0RlbGF5IFRvbGVyYW50IE5ldHdvcmtpbmcgU2VjdXJpdHkg S2V5IE1hbmFnZW1lbnRcJ1xyXG4gICAgICAgICAgICAgICAgYXMgYSB3b3JraW5nIGdyb3VwIHdv cmsgaXRlbSBpbnRlbmRlZCBmb3IgUHJvcG9zZWQgU3RhbmRhcmQuXHJcbiAgc3RhcnQrMTVtb3Mg LSBBY2NlcHQgXCdDb250YWN0IFBsYW4gVXBkYXRlIFByb3RvY29sXCcgYXMgd29ya2luZyBncm91 cCB3b3JrXHJcbiAgICAgICAgICAgICAgICBpdGVtIGludGVuZGVkIGZvciBQcm9wb3NlZCBTdGFu ZGFyZC5cclxuICBzdGFydCsxOG1vcyAtIFN1Ym1pdCBSRkM1MDUwYmlzLCBTQlNQLCBCSUJFIGFu ZCBLZXkgTWdtdCB0byB0aGUgSUVTRyBlaXRoZXJcclxuICAgICAgICAgICAgICAgIGFzIGEgY29t YmluZWQgZHJhZnQgb3IgYXMgc2VwYXJhdGUgZHJhZnRzLlxyXG4gIHN0YXJ0KzE4bW9zIC0gU3Vi bWl0IE5ldHdvcmsgTWFuYWdlbWVudCBbNV0sIFJlZ2lzdHJ5IFs2XSBhbmQgU2ltcGxlXHJcbiAg ICAgICAgICAgICAgICBDb252ZXJnZW5jZSBMYXllciBbN10gYXMgd29ya2luZyBncm91cCBkb2N1 bWVudHMuXHJcbiAgc3RhcnQrMjBtb3MgLSBTdXJ2ZXkgYXBwcm9wcmlhdGUgZm9ydW1zIChlLmcu LCBEVE5SRykgZm9yIGVtZXJnaW5nXHJcbiAgICAgICAgICAgICAgICB0ZWNobm9sb2dpZXMgKGUu Zy4sIGNvbnZlcmdlbmNlIGxheWVyIHByb3RvY29scywgZHluYW1pY1xyXG4gICAgICAgICAgICAg ICAgcm91dGluZyBwcm90b2NvbHMsIG5hbWluZyBhbmQgYWRkcmVzc2luZyBzZXJ2aWNlcywgZXRj LilcclxuICAgICAgICAgICAgICAgIHJlYWR5IGZvciB0cmFuc2l0aW9uIGludG8gSUVURiBEVE4g V29ya2luZyBHcm91cC4gUHVibGlzaFxyXG4gICAgICAgICAgICAgICAgZHJhZnQgb24gc3VydmV5 IHJlc3VsdHMgYXMgaW5kZXBlbmRlbnQgc3VibWlzc2lvbiByZWxhdGVkXHJcbiAgICAgICAgICAg ICAgICB0byB0aGUgV0cuXHJcbiAgc3RhcnQrMjRtb3MgLSBTdWJtaXQgTmV0d29yayBNYW5hZ2Vt ZW50LCBSZWdpc3RyeSBhbmQgU2ltcGxlIENvbnZlcmdlbmNlXHJcbiAgICAgICAgICAgICAgICBM YXllciB0byBJRVNHXHJcbiAgc3RhcnQrMjRtb3MgLSBSZWNoYXJ0ZXIgdG8gYWNjb21tb2RhdGUg bmV3IHdvcmsgaXRlbXMgb3IgY2xvc2UgV29ya2luZyBHcm91cFxyXG5cclxuXHJcblsxXSAiQlAv TFRQIGRlcGxveW1lbnQgb24gRVBPWEkgc3BhY2VjcmFmdCIgWzIwMDhdLFxyXG4gICAgaHR0cDov L2NvbW1pdHRlZXMuY29tc29jLm9yZy90Y2NjL2Njdy8yMDEwL3NsaWRlcy9ESU5FVF9DQ1cucGRm ICBcclxuWzJdICJQcm9wb3NlZCBSZXZpc2VkIEJ1bmRsZSBQcm90b2NvbCIgWzIwMTRdLFxyXG4g ICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYnVybGVpZ2gtYnB2Ny9c clxuWzNdICJTdHJlYW1saW5lZCBCdW5kbGUgU2VjdXJpdHkgUHJvdG9jb2wgU3BlY2lmaWNhdGlv biIgWzIwMTRdLFxyXG4gICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aXJ0Zi1kdG5yZy1zYnNwL1xyXG5bNF0gIkJ1bmRsZS1pbi1CdW5kbGUgRW5jYXBzdWxhdGlvbiIg WzIwMTNdLFxyXG4gICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWlydGYtYnVybGVp Z2gtYmliZVxyXG5bNV0gIkRlbGF5IFRvbGVyYW50IE5ldHdvcmsgTWFuYWdlbWVudCBQcm90b2Nv bCIgWzIwMTNdLFxyXG4gICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWlydGYtZHRu cmctZHRubXBcclxuWzZdICJEZWxheS1Ub2xlcmFudCBOZXR3b3JraW5nIEJ1bmRsZSBQcm90b2Nv bCBJQU5BIFJlZ2lzdHJpZXMiIFsyMDExXSxcclxuICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL3JmYzYyNTUvXHJcbls3XSAiRGF0YWdyYW0gQ29udmVyZ2VuY2UgTGF5ZXJzIC4u LiIgWzIwMTRdLFxyXG4gICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvcmZjNzEy Mi9cclxuWzhdICJUb3dhcmRzIEZsZXhpYmlsaXR5IGFuZCBBY2N1cmFjeSBpbiBTcGFjZSBEVE4g Q29tbXVuaWNhdGlvbnMiLFxyXG4gICAgQmV6aXJnaWFubmRpYSBldCBhbCwgQ0hBTlRTIDIwMTIs XHJcbiAgICBodHRwOi8vZGwuYWNtLm9yZy9jaXRhdGlvbi5jZm0/aWQ9MjUwNTQ5OSBbMjAxMl1c clxuXHJcblxyXG4nLCAnZmlsZW5hbWUxJzogJ0RyYWZ0IEJvRiBBZ2VuZGEgKDIuNWhycyk6XHJc bioqKioqKioqKioqKioqKioqKioqKioqKioqXHJcbjEpIFByb2JsZW0gc3RhdGVtZW50IChJRVRG IHdnIG1vdGl2YXRpb24pIC0gMzBtaW5cclxuXHJcbjIpIFJGQzUwNTAoYmlzKSAtIDE1bWluXHJc blxyXG4zKSBTdHJlYW1saW5lZCBCdW5kbGUgU2VjdXJpdHkgUHJvdG9jb2wgKFNCU1ApIC0gMTVt aW5cclxuXHJcbjQpIFNlY3VyaXR5IEtleSBNYW5hZ2VtZW50IC0gMTBtaW5cclxuXHJcbjUpIE5l dHdvcmsgTWFuYWdlbWVudCAtIDEwbWluXHJcblxyXG42KSBDb250YWN0IEdyYXBoIFJvdXRpbmcg YW5kIENvbnRhY3QgUGxhbiBVcGRhdGUgUHJvdG9jb2wgLSAxMG1pblxyXG5cclxuNykgQnVuZGxl LWluLUJ1bmRsZSBFbmNhcHN1bGF0aW9uIC0gNW1pblxyXG5cclxuOCkgUmVnaXN0cnkgZm9yIFNl cnZpY2UgSWRlbnRpZmllcnMgLSA1bWluXHJcblxyXG45KSBPcGVuIERpc2N1c3Npb24gLSA1MG1p blxyXG5cclxuXHJcbkRyYWZ0IHdvcmtpbmcgZ3JvdXAgY2hhcnRlcjpcclxuKioqKioqKioqKioq KioqKioqKioqKioqKioqKlxyXG5Xb3JraW5nIGdyb3VwIG5hbWU6IFxyXG5cclxuICAgICAgRGVs YXkvRGlzcnVwdGlvbiBUb2xlcmFudCBOZXR3b3JraW5nIFdvcmtpbmcgR3JvdXAgKERUTldHKVxy XG5cclxuQ2hhaXIocyk6XHJcblxyXG4gICAgICBUQkRcclxuXHJcbkFyZWEgYW5kIEFyZWEgRGly ZWN0b3Iocyk6XHJcblxyXG4gICAgICBUcmFuc3BvcnQgQXJlYTogQURzIFNwZW5jZXIgRGF3a2lu cyBfc3BlbmNlcmRhd2tpbnMuaWV0ZiBhdCBnbWFpbC5jb21fLFxyXG4gICAgICAgICAgICAgICAg ICAgICAgICAgIE1hcnRpbiBTdGllbWVybGluZyBfbWxzLmlldGYgYXQgZ21haWwuY29tX1xyXG5c clxuUmVzcG9uc2libGUgQXJlYSBEaXJlY3RvcjpcclxuXHJcbiAgICAgIFRCRFxyXG5cclxuTWFp bGluZyBsaXN0OlxyXG5cclxuICAgICAgR2VuZXJhbCBEaXNjdXNzaW9uOiBkdG4gYXQgaWV0Zi5v cmdcclxuICAgICAgVG8gU3Vic2NyaWJlOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2R0blxyXG4gICAgICBBcmNoaXZlOiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJj aGl2ZS93ZWIvZHRuL2N1cnJlbnQvbWFpbGxpc3QuaHRtbFxyXG5cclxuRGVzY3JpcHRpb24gb2Yg V29ya2luZyBHcm91cDpcclxuXHJcbiAgICAgIFRoZSBEZWxheS9EaXNydXB0aW9uIFRvbGVyYW50 IE5ldHdvcmsgV29ya2luZyBHcm91cCAoRFROV0cpIHNwZWNpZmllc1xyXG4gICAgICBtZWNoYW5p c21zIGZvciBkYXRhIGNvbW11bmljYXRpb25zIGluIHRoZSBwcmVzZW5jZSBvZiBsb25nIGRlbGF5 c1xyXG4gICAgICBhbmQvb3IgaW50ZXJtaXR0ZW50IGNvbm5lY3Rpdml0eS4gVGhlIHdvcmsgaXMg bW90aXZhdGVkIGJ5IHdlbGwga25vd25cclxuICAgICAgbGltaXRhdGlvbnMgb2Ygc3RhbmRhcmQg SW50ZXJuZXQgcHJvdG9jb2xzIHRoYXQgZXhwZWN0IGVuZC10by1lbmRcclxuICAgICAgY29ubmVj dGl2aXR5IGJldHdlZW4gY29tbXVuaWNhdGluZyBlbmRwb2ludHMsIHN1Yi1zZWNvbmQgdHJhbnNt aXNzaW9uXHJcbiAgICAgIGRlbGF5cyBhbmQgcm9idXN0IHBhY2tldCBkZWxpdmVyeSByYXRpb3Mu IEluIGVudmlyb25tZW50cyB3aGVyZSB0aGVzZVxyXG4gICAgICBmYXZvcmFibGUgY29uZGl0aW9u cyBkbyBub3QgYXBwbHksIGV4aXN0aW5nIG1lY2hhbmlzbXMgZW5jb3VudGVyIHByb2JsZW1zIFxy XG4gICAgICBzdWNoIGFzIHJlbGlhYmxlIHRyYW5zcG9ydCBwcm90b2NvbCBoYW5kc2hha2VzIHRp bWluZyBvdXQgYW5kIHJvdXRpbmcgXHJcbiAgICAgIHByb3RvY29scyBmYWlsaW5nIHRvIGNvbnZl cmdlIHJlc3VsdGluZyBpbiBjb21tdW5pY2F0aW9uIGZhaWx1cmVzLiBcclxuICAgICAgRnVydGhl cm1vcmUsIGNsYXNzaWNhbCBlbmQtdG8tZW5kIHNlY3VyaXR5IGFzc29jaWF0aW9ucyBjYW5ub3Qg YmUgXHJcbiAgICAgIGNvb3JkaW5hdGVkIHdoZW4gY29tbXVuaWNhdGluZyBlbmRwb2ludHMgY2Fu bm90IGNvbmR1Y3QgbXVsdGktbWVzc2FnZSBcclxuICAgICAga2V5aW5nIGV4Y2hhbmdlcyBpbiBh IHRpbWVseSBmYXNoaW9uLiBUaGVzZSBsaW1pdGF0aW9ucyBzdWdnZXN0ZWQgdGhlIFxyXG4gICAg ICBuZWVkIGZvciBhIG5ldyBhcHByb2FjaC4gXHJcbiAgICAgIFxyXG4gICAgICBEZWxheS1Ub2xl cmFudCBOZXR3b3JraW5nIChEVE4pIHByb3RvY29scyBoYXZlIGJlZW4gdGhlIHN1YmplY3Qgb2Zc clxuICAgICAgZXh0ZW5zaXZlIHJlc2VhcmNoIGFuZCBkZXZlbG9wbWVudCBpbiB0aGUgRGVsYXkt VG9sZXJhbnQgTmV0d29ya2luZ1xyXG4gICAgICBSZXNlYXJjaCBHcm91cCAoRFROUkcpIG9mIHRo ZSBJbnRlcm5ldCBSZXNlYXJjaCBUYXNrIEZvcmNlIHNpbmNlIDIwMDIuXHJcbiAgICAgIFRoZSBE VE5SRyBoYXMgZGV2ZWxvcGVkIHRoZSBEZWxheS1Ub2xlcmFudCBOZXR3b3JraW5nIEFyY2hpdGVj dHVyZSBcclxuICAgICAgKFJGQyA0ODM4KSB0aGF0IHRoZSBEVE5XRyB1c2VzIGFzIHRoZSBiYXNp cyBmb3IgaXRzIHdvcmsuICBUaGUga2V5IFxyXG4gICAgICBjb21wb25lbnRzIG9mIHRoZSB0aGlz IGFyY2hpdGVjdHVyZSBhcmUgdGhlIGJ1bmRsZSBjb25jZXB0IGZvciBcclxuICAgICAgZW5jYXBz dWxhdGluZyBkYXRhIHVuaXRzLCB0aGUgYnVuZGxlIHRyYW5zbWlzc2lvbiBwcm90b2NvbCBhbmQg dGhlIFxyXG4gICAgICB1bmRlcmx5aW5nIGNvbnZlcmdlbmNlIGxheWVyIGFyY2hpdGVjdHVyZS5c clxuICAgIFxyXG4gICAgICBUaGUgZXhwZXJpbWVudGFsIERUTiBCdW5kbGUgUHJvdG9jb2wgKFJG QyA1MDUwKSBhbmQgTGlja2xpZGVyXHJcbiAgICAgIFRyYW5zbWlzc2lvbiBQcm90b2NvbCAoUkZD IDUzMjYpIGhhdmUgYmVlbiBzaG93biB0byBhZGRyZXNzIHRoZVxyXG4gICAgICBpc3N1ZXMgaWRl bnRpZmllZCBhYm92ZSBpbiBzdWJzdGFudGlhbCBmaWVsZGVkIGRlcGxveW1lbnRzIGluIHRoZSBz cGFjZSBcclxuICAgICAgc2VjdG9yIFsxXS4gIFJGQyA1MDUwIGluIGNvbmp1bmN0aW9uIHdpdGgg VENQLSBhbmQgVURQLWJhc2VkIGNvbnZlcmdlbmNlIFxyXG4gICAgICBsYXllcnMgaGFzIGJlZW4g dXNlZCBzdWNjZXNzZnVsbHkgaW4gYSBudW1iZXIgb2YgZXhwZXJpbWVudHMgYm90aCBpbiBcclxu ICAgICAgY29tbXVuaWNhdGlvbnMgY2hhbGxlbmdlZCBlbnZpcm9ubWVudHMgYXJvdW5kIHRoZSBl ZGdlcyBvZiB0aGUgSW50ZXJuZXQgXHJcbiAgICAgIGFuZCBhcyBhbiBJbnRlcm5ldCBvdmVybGF5 IHdoZXJlIGFwcGxpY2F0aW9ucyByZXF1aXJlIGRlbGF5LSBhbmQvb3IgXHJcbiAgICAgIGRpc3J1 cHRpb24tdG9sZXJhbmNlIFtyZWZzIG5lZWRlZF0uICBcclxuXHJcbiAgICAgIFRoZSBzdWNjZXNz IG9mIHRoZSBCUCBvdmVyIGNvbnZlcmdlbmNlIGxheWVyIHByb3RvY29sIHN0YWNrIC0tIHRoZSBj b3JlIFxyXG4gICAgICBwcm90b2NvbHMgb2YgdGhlICJEVE4gQXJjaGl0ZWN0dXJlIiBkZXNjcmli ZWQgaW4gUkZDIDQ4MzggLS0gbWF5IGJlIFxyXG4gICAgICBhdHRyaWJ1dGVkIHRvIHRoZSBmb2xs b3dpbmcgZnVuZGFtZW50YWwgZGVzaWduIHByaW5jaXBsZXM6XHJcblxyXG5cdC0gVGhlcmUgaXMg bmV2ZXIgYW55IGV4cGVjdGF0aW9uIG9mIGNvbnRlbXBvcmFuZW91cyBlbmQtdG8tZW5kXHJcbiAg ICAgICAgICBjb25uZWN0aXZpdHkgYmV0d2VlbiBhbnkgdHdvIG5ldHdvcmsgbm9kZXMuXHJcblxy XG5cdC0gQmVjYXVzZSBlbmQtdG8tZW5kIGNvbm5lY3Rpdml0eSBjYW4gbmV2ZXIgYmUgYXNzdW1l ZCwgZWFjaCBub2RlXHJcblx0ICBvbiB0aGUgcGF0aCBiZXR3ZWVuIHNvdXJjZSBhbmQgZGVzdGlu YXRpb24gbXVzdCBiZSBwcmVwYXJlZCB0b1xyXG5cdCAgaGFuZGxlIGluY29taW5nICJidW5kbGVz IiBvZiBkYXRhIHRoYXQgY2Fubm90IGltbWVkaWF0ZWx5IGJlXHJcblx0ICBmb3J3YXJkZWQuXHJc blxyXG5cdC0gQWdhaW4gYmVjYXVzZSBlbmQtdG8tZW5kIGNvbm5lY3Rpdml0eSBjYW4gbmV2ZXIg YmUgYXNzdW1lZCxcclxuXHQgIGVuZC10by1lbmQgY29udmVyc2F0aW9uYWwgZGF0YSBleGNoYW5n ZSBjYW4gbmV2ZXIgYmUgYXNzdW1lZCB0b1xyXG5cdCAgY29tcGxldGUgaW4gYSB0aW1lbHkgbWFu bmVyOyBwcm90b2NvbCBmZWF0dXJlcyB0aGF0IHJlbHkgb25cclxuXHQgIHRpbWVseSBjb252ZXJz YXRpb25hbCBkYXRhIGV4Y2hhbmdlIG11c3QgYmUgZXhjbHVkZWQgZnJvbSB0aGVcclxuXHQgIGFy Y2hpdGVjdHVyZS5cclxuXHJcbiAgICAgIFRoZSBEVE5XRyBiZWxpZXZlcyB0aGF0IHByb3RvY29s cyBhZGhlcmluZyB0byB0aGVzZSBwcmluY2lwbGVzIG9mZmVyXHJcbiAgICAgIG9wcG9ydHVuaXRp ZXMgZm9yIGVuaGFuY2luZyB0aGUgZnVuY3Rpb25hbGl0eSBvZiB0aGUgSW50ZXJuZXQsIGluY2x1 ZGluZyBcclxuXHJcbiAgICAgICAgLSBmYWNpbGl0YXRpbmcgdGhlIGV4dGVuc2lvbiBvZiB0aGUg SW50ZXJuZXQgaW50byBlbnZpcm9ubWVudHMgc3VjaCBhcyBcclxuICAgICAgICAgIHRoZSBvY2Vh biBmbG9vciBhbmQgZGVlcCBzcGFjZSBpbiB3aGljaCB0aGUgY29yZSBJbnRlcm5ldCBwcm90b2Nv bHMgXHJcbiAgICAgICAgICBvcGVyYXRlIHN1Yi1vcHRpbWFsbHkgZm9yIHRoZSByZWFzb25zIGRp c2N1c3NlZCBlYXJsaWVyO1xyXG5cclxuICAgICAgICAtIGV4dGVuZGluZyB0aGUgSW50ZXJuZXQg aW50byBjb21tdW5pY2F0aW9ucyBjaGFsbGVuZ2VkIHRlcnJlc3RyaWFsIFxyXG4gICAgICAgICAg ZW52aXJvbm1lbnRzIHdoZXJlIGl0IGlzIG5vdCBwb3NzaWJsZSB0byBwcm92aWRlIGNvbnRpbnVv dXMsIGxvdyBcclxuICAgICAgICAgIGRlbGF5IEludGVybmV0IGNvbm5lY3Rpb25zOyBhbmQgXHJc blxyXG4gICAgICAgIC0gc3VwcG9ydGluZyBJbnRlcm5ldCBhcHBsaWNhdGlvbnMgdGhhdCBuZWVk IERUTiBjYXBhYmlsaWllcy5cclxuXHJcbiAgICAgIFdlIGJlbGlldmUgdGhhdCB0aGUgZXh0ZW5z aXZlIHJlc2VhcmNoLCBkZW1vbnN0cmF0aW9uLCBhbmRcclxuICAgICAgcGlsb3Qgb3BlcmF0aW9u cyBwZXJmb3JtZWQgdG8gZGF0ZSB1c2luZyB0aGUgRFROUkcgcHJvdG9jb2xzIHByb3ZpZGVzXHJc biAgICAgIGEgZmlybSBiYXNpcyBmb3IgcHVibGlzaGluZyBJbnRlcm5ldCBzdGFuZGFyZHMgZGVy aXZlZCBmcm9tIHRoYXQgd29yay5cclxuXHJcbiAgICAgIFdvcmsgaXRlbXMgcmVsYXRlZCB0byBE ZWxheS9EaXNydXB0aW9uIFRvbGVyYW50IE5ldHdvcmtpbmcgaW5jbHVkZTpcclxuXHJcbiAgICAg IG8gQSBtZWNoYW5pc20gZm9yIHRoZSBleGNoYW5nZSBvZiBwcm90b2NvbCBkYXRhIHVuaXRzLCB0 ZXJtZWRcclxuXHQgICAiYnVuZGxlcyIsIHRoYXQgYXJlIGRlc2lnbmVkIHRvIG9idmlhdGUgY29u dmVyc2F0aW9uYWwgY29tbXVuaWNhdGlvbnNcclxuXHQgICBieSBjb250YWluaW5nIHZhbHVlcyBm b3IgYWxsIHBvdGVudGlhbGx5IHJlbGV2YW50IGNvbmZpZ3VyYXRpb25cclxuXHQgICBwYXJhbWV0 ZXJzLiBUaGVzZSBwcm90b2NvbCBkYXRhIHVuaXRzIGFyZSB0eXBpY2FsbHkgbGFyZ2VyIHRoYW5c clxuXHQgICBuZXR3b3JrLWxheWVyIHBhY2tldHMuIFdlIHdpbGwgZGVyaXZlIHRoaXMgYnVuZGxl IGV4Y2hhbmdlIG1lY2hhbmlzbVxyXG4gICAgICAgIGZyb20gdGhlIERUTiBCdW5kbGUgUHJvdG9j b2wgKEJQKSBkb2N1bWVudGVkIGluIFJGQyA1MDUwIGJ5IHB1Ymxpc2hpbmdcclxuICAgICAgICBh IG5ldyBkb2N1bWVudCBmb3Igd2hpY2ggWzJdIGlzIGEgcHJvcG9zZWQgZmlyc3QgZHJhZnQgKHdo ZXJlXHJcbiAgICAgICAgYXBwZW5kaXggQSBwcm92aWRlcyBhIHN1bW1hcnkgb2YgdGhlIHByb3Bv c2VkIGNoYW5nZXMpLlxyXG5cclxuICAgICAgbyBBIHNlY3VyaXR5IHByb3RvY29sIGZvciBlbnN1 cmluZyB0aGF0IHRoZSBuZXR3b3JrIGluIHdoaWNoIGJ1bmRsZXNcclxuXHQgICBhcmUgZXhjaGFu Z2VkIGlzIHNlY3VyZWQgYWdhaW5zdCB1bmF1dGhvcml6ZWQgYWNjZXNzIGFuZCBkZW5pYWwgb2Zc clxuXHQgICBzZXJ2aWNlIGF0dGFja3MsIGFuZCB0byBlbnN1cmUgZGF0YSBpbnRlZ3JpdHkgYW5k IGNvbmZpZGVudGlhbGl0eVxyXG5cdCAgIGluIHRoYXQgbmV0d29yayB3aGVyZSBuZWNlc3Nhcnku ICBXZSB3aWxsIGRlcml2ZSB0aGlzIHNlY3VyaXR5XHJcblx0ICAgcHJvdG9jb2wgZnJvbSBhICJz dHJlYW1saW5lZCIgYWRhcHRhdGlvbiBvZiB0aGUgRFROIEJ1bmRsZSBTZWN1cml0eVxyXG5cdCAg IFByb3RvY29sIGRvY3VtZW50ZWQgaW4gUkZDIDYyNTcuXHJcblxyXG4gICAgICAgbyBBIGRlbGF5 LXRvbGVyYW50IHNlY3VyaXR5IGtleSBtYW5hZ2VtZW50IHNjaGVtZSB0aGF0IGNhbiBwcm90ZWN0 XHJcbiAgICAgICAgIHRoZSBpbnRlZ3JpdHkgb2YgYSBEVE4gbmV0d29yay5cclxuXHJcbiAgICAg IG8gQSBzaW1wbGUgZGF0YWdyYW0gY29udmVyZ2VuY2UgbGF5ZXIgcHJvdG9jb2wgZm9yIGFkYXB0 YXRpb24gb2YgdGhlXHJcbiAgICAgICAgYnVuZGxlIHByb3RvY29sIHRvIHVuZGVybHlpbmcgaW50 ZXJuZXR3b3Jrcy4gV2UgZXhwZWN0IHRvIGRlcml2ZVxyXG4gICAgICAgIHRoaXMgY29udmVyZ2Vu Y2UgbGF5ZXIgcHJvdG9jb2wgZnJvbSB0aGUgRGF0YWdyYW0gQ29udmVyZ2VuY2VcclxuICAgICAg ICBwcm90b2NvbCBkb2N1bWVudGVkIGluIFJGQyA3MTIyLlxyXG5cclxuICAgICAgbyBBIGRlbGF5 LXRvbGVyYW50IG5ldHdvcmsgbWFuYWdlbWVudCBwcm90b2NvbCBmb3IgbWFuYWdlbWVudCBvZiB0 aGVcclxuICAgICAgICBpbmZyYXN0cnVjdHVyZSBpbiB0aGUgcHJlc2VuY2Ugb2YgbG9uZyBkZWxh eXMgYW5kL29yIGludGVybWl0dGVudFxyXG4gICAgICAgIGNvbm5lY3Rpdml0eS5cclxuXHJcbiAg ICAgIG8gQSBmdW5jdGlvbmFsIHNwZWNpZmljYXRpb24gb2YgQ29udGFjdCBHcmFwaCBSb3V0aW5n IChDR1IpIHNwZWNpZnlpbmcgXHJcbiAgICAgICAgdGhlIGlucHV0cyAoZ2xvYmFsIGNvbnRhY3Qg c2NoZWR1bGVzLCB0cmFmZmljIGRlbWFuZHMsIGV0Yy4pIGFuZCBcclxuICAgICAgICBvdXRwdXRz IChub2RlIHNwZWNpZmljIHRyYW5zbWlzc2lvbiBhbmQgcmVjZXB0aW9uIHNjaGVkdWxlcywgXHJc biAgICAgICAgbm90aWZpY2F0aW9ucywgZXRjLikuICBDR1IgaXMgYSBjZW50cmFsaXplZCwgb3Jh Y2xlLWJhc2VkIGJ1bmRsZSBcclxuICAgICAgICB0cmFuc21pc3Npb24gYW5kIHJlY2VwdGlvbiBz Y2hlZHVsaW5nIHNjaGVtZSB1c2VkIGluIHNwYWNlIHNlZ21lbnQgXHJcbiAgICAgICAgRFROIGRl cGxveW1lbnRzLlxyXG5cclxuICAgICAgbyBBbiBhZGp1bmN0IHRvIHRoZSBtYW5hZ2VtZW50IHBy b3RvY29sIHRoYXQgd2lsbCBhbGxvdyB0aGUgY29udGFjdCBcclxuICAgICAgICBzY2hlZHVsZXMg Z2VuZXJhdGVkIGJ5IENHUiB0byBiZSBkaXN0cmlidXRlZCB0byBub2Rlcy4gIFRoaXMgbWF5IGJl IFxyXG4gICAgICAgIGJhc2VkIG9uIHRoZSBDb250YWN0IFBsYW4gVXBkYXRlIFByb3RvY29sIChD UFVQKSBwcm9wb3NlZCBpbiAgXHJcblxyXG4gICAgICBvIEFuIGVuY2Fwc3VsYXRpb24gcHJvdG9j b2wgZm9yICJ0dW5uZWxpbmciIEJQIHRyYWZmaWMgd2l0aGluIGJ1bmRsZXNcclxuXHQgICB0aGF0 IGFyZSBzZWN1cmVkIGFuZC9vciByb3V0ZWQgaW4gZGlmZmVyZW50IHdheSBmcm9tIHRoZSBlbmNh cHN1bGF0ZWRcclxuXHQgICBidW5kbGVzLlxyXG5cclxuICAgICAgbyBBIHJlZ2lzdHJ5IGZvciBE VE4gU2VydmljZSBJZGVudGlmaWVyc1xyXG4gIFxyXG4gICAgVGhlIHdvcmtpbmcgZ3JvdXAgd2ls bCBjb25zaWRlciBleHRlbmRpbmcgdGhlIGN1cnJlbnQgbWlsZXN0b25lcyBiYXNlZCBvblxyXG4g ICAgbmV3IGluZm9ybWF0aW9uIGFuZCBrbm93bGVkZ2UgZ2FpbmVkIHdoaWxlIHdvcmtpbmcgb24g dGhlIGluaXRpYWwgY2hhcnRlcixcclxuICAgIGFzIHdlbGwgYXMgdG8gYWNjb21tb2RhdGUgbmV3 IHdvcmsgaXRlbXMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGUgaW5pdGlhbFxyXG4gICAgcGhhc2Uu ICBGb3IgZXhhbXBsZSwgd2UgZXhwZWN0IHRoYXQgdHJhbnNwb3J0IHByb3RvY29scyBzdWNoIGFz IExUUCBhbmRcclxuICAgIHRoZSBTYXJhdG9nYSBwcm90b2NvbCBhcmUgYW1vbmcgdGhlIGNhbmRp ZGF0ZXMgZm9yIHdvcmsgaW4gdGhpcyBwaGFzZS5cclxuICAgIFxyXG5Hb2FscyBhbmQgTWlsZXN0 b25lczpcclxuICBzdGFydCszbW9zIC0gU3VibWl0IFwnQnVuZGxlIFByb3RvY29sIFNwZWNpZmlj YXRpb24gKFJGQzUwNTBiaXMpXCcgYXMgYVxyXG4gICAgICAgICAgICAgICB3b3JraW5nIGdyb3Vw IGRvY3VtZW50IFsyXS4gVG8gYmUgUHJvcG9zZWQgU3RhbmRhcmQuXHJcbiAgU3RhcnQrM21vcyAt IFN1Ym1pdCBcJ1N0cmVhbWxpbmVkIEJ1bmRsZSBTZWN1cml0eSBQcm90b2NvbCAoU0JTUClcJyBh cyBhXHJcbiAgICAgICAgICAgICAgIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQgWzNdLiBUbyBiZSBQ cm9wb3NlZCBTdGFuZGFyZC5cclxuICBzdGFydCs2bW9zIC0gU3VibWl0IFwnQnVuZGxlIEluIEJ1 bmRsZSBFbmNhcHN1bGF0aW9uIChCSUJFKVwnIGFzIGEgd29ya2luZ1xyXG4gICAgICAgICAgICAg ICBncm91cCBkb2N1bWVudCBbNF0uIFRvIGJlIFByb3Bvc2VkIFN0YW5kYXJkLlxyXG4gIHN0YXJ0 KzEybW9zIC0gU3VibWl0IFwnQ0dSIEZ1bmN0aW9uYWwgU3BlY2lmaWNhdGlvblwnIGFzIGEgd29y a2luZyBncm91cCBcclxuICAgICAgICAgICAgICAgIGRvY3VtZW50LiBUbyBiZSBhbiBpbmZvcm1h dGlvbmFsIGRvY3VtZW50LlxyXG4gIHN0YXJ0KzEybW9zIC0gU3VibWl0IFwnRGVsYXkgVG9sZXJh bnQgTmV0d29ya2luZyBTZWN1cml0eSBLZXkgTWFuYWdlbWVudFwnIGFzXHJcbiAgICAgICAgICAg ICAgICBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuIFRvIGJlIFByb3Bvc2VkIFN0YW5kYXJkLlxy XG4gIHN0YXJ0KzE1bW9zIC0gU3VibWl0IFwnQ29udGFjdCBQbGFuIFVwZGF0ZSBQcm90b2NvbFwn IGFzIHdvcmtpbmcgZ3JvdXAgXHJcbiAgICAgICAgICAgICAgICBkb2N1bWVudC4gIFRvIGJlIFBy b3Bvc2VkIFN0YW5kYXFxcmQuXHJcbiAgc3RhcnQrMThtb3MgLSBXRyBkZXRlcm1pbmF0aW9uIGZv ciBtZXJnaW5nIFJGQzUwNTBiaXMsIFNCU1AsIEJJQkUgYW5kL29yXHJcbiAgICAgICAgICAgICAg ICBLZXkgTWdtdCBpbnRvIGEgY29tYmluZWQgZHJhZnQgb3Iga2VlcCBhcyBzZXBhcmF0ZSBkcmFm dHMuXHJcbiAgc3RhcnQrMThtb3MgLSBTdWJtaXQgUkZDNTA1MGJpcywgU0JTUCwgQklCRSBhbmQg S2V5IE1nbXQgdG8gdGhlIElFU0cgZWl0aGVyXHJcbiAgICAgICAgICAgICAgICBhcyBhIGNvbWJp bmVkIGRyYWZ0IG9yIGFzIHNlcGFyYXRlIGRyYWZ0cy5cclxuICBzdGFydCsxOG1vcyAtIFN1Ym1p dCBOZXR3b3JrIE1hbmFnZW1lbnQgWzVdLCBSZWdpc3RyeSBbNl0gYW5kIFNpbXBsZVxyXG4gICAg ICAgICAgICAgICAgQ29udmVyZ2VuY2UgTGF5ZXIgWzddIGFzIHdvcmtpbmcgZ3JvdXAgZG9jdW1l bnRzLlxyXG4gIHN0YXJ0KzIwbW9zIC0gU3VydmV5IGFwcHJvcHJpYXRlIGZvcnVtcyAoZS5nLiwg RFROUkcpIGZvciBlbWVyZ2luZ1xyXG4gICAgICAgICAgICAgICAgdGVjaG5vbG9naWVzIChlLmcu LCBjb252ZXJnZW5jZSBsYXllciBwcm90b2NvbHMsIGR5bmFtaWNcclxuICAgICAgICAgICAgICAg IHJvdXRpbmcgcHJvdG9jb2xzLCBuYW1pbmcgYW5kIGFkZHJlc3Npbmcgc2VydmljZXMsIGV0Yy4p XHJcbiAgICAgICAgICAgICAgICByZWFkeSBmb3IgdHJhbnNpdGlvbiBpbnRvIElFVEYgRFROIFdv cmtpbmcgR3JvdXAuIFB1Ymxpc2hcclxuICAgICAgICAgICAgICAgIGRyYWZ0IG9uIHN1cnZleSBy ZXN1bHRzIGFzIGluZGVwZW5kZW50IHN1Ym1pc3Npb24gcmVsYXRlZFxyXG4gICAgICAgICAgICAg ICAgdG8gdGhlIFdHLlxyXG4gIHN0YXJ0KzI0bW9zIC0gU3VibWl0IE5ldHdvcmsgTWFuYWdlbWVu dCwgUmVnaXN0cnkgYW5kIFNpbXBsZSBDb252ZXJnZW5jZVxyXG4gICAgICAgICAgICAgICAgTGF5 ZXIgdG8gSUVTR1xyXG4gIHN0YXJ0KzI0bW9zIC0gUmVjaGFydGVyIHRvIGFjY29tbW9kYXRlIG5l dyB3b3JrIGl0ZW1zIG9yIGNsb3NlIFdvcmtpbmcgR3JvdXBcclxuXHJcblxyXG5bMV0gIkJQL0xU UCBkZXBsb3ltZW50IG9uIEVQT1hJIHNwYWNlY3JhZnQiIFsyMDA4XSxcclxuICAgIGh0dHA6Ly9j b21taXR0ZWVzLmNvbXNvYy5vcmcvdGNjYy9jY3cvMjAxMC9zbGlkZXMvRElORVRfQ0NXLnBkZiAg XHJcblsyXSAiUHJvcG9zZWQgUmV2aXNlZCBCdW5kbGUgUHJvdG9jb2wiIFsyMDE0XSxcclxuICAg IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJ1cmxlaWdoLWJwdjcvXHJc blszXSAiU3RyZWFtbGluZWQgQnVuZGxlIFNlY3VyaXR5IFByb3RvY29sIFNwZWNpZmljYXRpb24i IFsyMDE0XSxcclxuICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWly dGYtZHRucmctc2JzcC9cclxuWzRdICJCdW5kbGUtaW4tQnVuZGxlIEVuY2Fwc3VsYXRpb24iIFsy MDEzXSxcclxuICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1pcnRmLWJ1cmxlaWdo LWJpYmVcclxuWzVdICJEZWxheSBUb2xlcmFudCBOZXR3b3JrIE1hbmFnZW1lbnQgUHJvdG9jb2wi IFsyMDEzXSxcclxuICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1pcnRmLWR0bnJn LWR0bm1wXHJcbls2XSAiRGVsYXktVG9sZXJhbnQgTmV0d29ya2luZyBCdW5kbGUgUHJvdG9jb2wg SUFOQSBSZWdpc3RyaWVzIiBbMjAxMV0sXHJcbiAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9yZmM2MjU1L1xyXG5bN10gIkRhdGFncmFtIENvbnZlcmdlbmNlIExheWVycyAuLi4i IFsyMDE0XSxcclxuICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL3JmYzcxMjIv XHJcbls4XSAiVG93YXJkcyBGbGV4aWJpbGl0eSBhbmQgQWNjdXJhY3kgaW4gU3BhY2UgRFROIENv bW11bmljYXRpb25zIixcclxuICAgIEJlemlyZ2lhbm5kaWEgZXQgYWwsIENIQU5UUyAyMDEyLFxy XG4gICAgaHR0cDovL2RsLmFjbS5vcmcvY2l0YXRpb24uY2ZtP2lkPTI1MDU0OTkgWzIwMTJdXHJc blxyXG5cclxuJywgJ3VybDEnOiAnJywgJ3N1Ym1pdCc6ICdHZW5lcmF0ZSBkaWZmJywgJ3VybDIn OiAnJywgJy0tbmV3Y29sb3VyJzogJ2dyZWVuJ30gLS0+ --_002_2134F8430051B64F815C691A62D983183048DB80XCHBLV512nwnosb_-- From nobody Tue Jun 17 11:24:41 2014 Return-Path: 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 B66BD1A0127 for ; Tue, 17 Jun 2014 11:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 FC-Xgz1EUvh9 for ; Tue, 17 Jun 2014 11:24:37 -0700 (PDT) Received: from nm4-vm1.bullet.mail.ne1.yahoo.com (nm4-vm1.bullet.mail.ne1.yahoo.com [98.138.91.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C8571A0111 for ; Tue, 17 Jun 2014 11:24:37 -0700 (PDT) Received: from [98.138.101.128] by nm4.bullet.mail.ne1.yahoo.com with NNFMP; 17 Jun 2014 18:24:36 -0000 Received: from [98.138.87.10] by tm16.bullet.mail.ne1.yahoo.com with NNFMP; 17 Jun 2014 18:24:36 -0000 Received: from [127.0.0.1] by omp1010.mail.ne1.yahoo.com with NNFMP; 17 Jun 2014 18:24:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 320914.76950.bm@omp1010.mail.ne1.yahoo.com Received: (qmail 44336 invoked by uid 60001); 17 Jun 2014 18:24:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1403029476; bh=HtwSbOVhyIIAw3Vpkdqn4vpdsvMmI7fZbcg+J+Vzc+k=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=RhFid6lZwmbbcwyTK9HHzhQS6f5r0uEtwEFG4yfj3auG3UQpdvydr8OYmpJwHcObDe+14uwG+ec0gZG5ORUOCSyHkQwEn1BVtdJEiyOd3T9XHwiH1vInn0TMy/AxRP94QUBAEIbPrDtQtyFPr31PWOjqDDB47pAghlWfuGWNHfo= X-YMail-OSG: 2wEfSkoVM1kK5KgL2SgPaRFK12cpELwTuR03xViPCxXog9R KTveU9wuaQojghSZ86mBFuPenY7qyQZQr5azrTv40UyGspiWBY893duTT.vT IgD50nJqSj7P2z.g9ROA84hTmGEQwlxRyXoz2SvA8NsgunUWKU9m6ibETTl_ l7VGxUb0kLU53EQpaGurfn5HTzik4ckDv5Png6aP3Yi2JZOJYAwcZSdcVqva JVhQDt1iGUy4BNIyzyhIuFbR92CfqmGdSIBOoNzcLtVseJpVmH1fzMj5OJTm xeRAlXLGyKy.m3Emsd4QuX_JBtpMfV2UE3RWRyHtdydahcGd47x_RplKUHdd BLQ5rMDzHJ2GUur9HDUY4EFiECA7bd36LJm_eX9HZuxBV_Z1R7JXHgsA.B9l zFGGATIDfBLjU3VOR6cmpFGC3ht037rUUYdVPPdcSIaBVpMTpbZCkAFzqI5T EMuWFXrJU6O0TCdB9QjPcw859zxa7bdCs83A.LBc3sA8xTUDPsgvfPFp35si I5ui7HLcmVZMTDGbjmLWnsz8lRhH7ygQi.aFNw.Odn1s7a0Zi.u5nC84gLig NiuhV Received: from [128.156.10.80] by web125106.mail.ne1.yahoo.com via HTTP; Tue, 17 Jun 2014 11:24:36 PDT X-Rocket-MIMEInfo: 002.001, U29tZSB0aG91Z2h0czoKCgpJIHRoaW5rIHdlIG5lZWQgc29tZSBkZWVwIHBoaWxvc29waGljYWwgZGlzY3Vzc2lvbiBhdCB0aGUgQk9GIG9uIHdoYXQgd2UgYXJlIHRyeWluZyB0byBkbyB3aXRoIERUTi7CoCBNb3N0IChhY3R1YWxseSBBTEwpIGRlcGxveW1lbnRzIEkgYW0gYXdhcmUgb2YgaGF2ZSBiZWVuIGluIHRoZSBvcmRlciBvZiBwcm9iYWJseSB0ZW5zIG9yIGxlc3Mgbm9kZXMgLSBjZXJ0YWlubHkgbGVzcyB0aGFuIDEwMC7CoCBBcmUgd2UgZGV2ZWxvcGluZyBhIHN0YW5kYXJkIGZvciBzcGFjZSBzeXMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.190.668 References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> <2134F8430051B64F815C691A62D983183048B3B6@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983183048DB80@XCH-BLV-512.nw.nos.boeing.com> Message-ID: <1403029476.99627.YahooMailNeo@web125106.mail.ne1.yahoo.com> Date: Tue, 17 Jun 2014 11:24:36 -0700 From: William Ivancic To: "Templin, Fred L" , "dtn@ietf.org" In-Reply-To: <2134F8430051B64F815C691A62D983183048DB80@XCH-BLV-512.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1552829269-1568648109-1403029476=:99627" Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/ysPfPWiqw1R6BK2IgXb7wXl-bgw Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: William Ivancic List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 18:24:39 -0000 --1552829269-1568648109-1403029476=:99627 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Some thoughts:=0A=0A=0AI think we need some deep philosophical discussion a= t the BOF on what we are trying to do with DTN.=A0 Most (actually ALL) depl= oyments I am aware of have been in the order of probably tens or less nodes= - certainly less than 100.=A0 Are we developing a standard for space syste= ms or looking at hundreds of thousands or millions of nodes? =0A=0A=0AI thi= nk the last time IETF worked a specific problem it was TCPSAT and, I believ= e, the IETF decided that we would not do work on a specific deployment area= .=A0 (Fortunately, the TCP over Satellite actually had a more generic probl= em which was time/bandwidth.)=A0 If the end result is deploying over 100 no= des (10 nodes in 10 deployments) in the next 5 years, I doubt we should be = considering a standard at this time.=0A=0A=0AThere has never been a "proble= m statement" written, so we don't really know what problem we are trying to= solve.=A0 Is Scalability an issue?=A0 I think so.=0A=0A=0AThere is current= ly=A0 no document of which I am aware of that states what the default opera= tion of a forwarding agent is.=A0 For example, if you have no route, do you= drop a bundle even if it has not expired or do you hold it in anticipation= of perhaps having a route later?=A0 =0A=0A=0AI do know that some groups wa= nt to run DTN (RFC5050) at extremely high rates (Gbps and higher).=A0 The c= urrent structure, while nice for research with all the flexibility, is not = very well suited for high-speed deployments - particularly if you are consi= dering space-based hardware and processors.=A0 Do we address this?=0A=0A"We= believe that the extensive research, demonstration, and=0A=A0=A0=A0=A0=A0 = pilot operations performed to date using the DTNRG protocols provides=0A=A0= =A0=A0=A0=A0 a firm basis for publishing Internet standards derived from th= at work."=0A=0AQuite honestly, I cannot agree with this statement.=A0 I hav= e seen very little with regards to scalability, a mix of traffic, a mix of = bundle lifetimes, a mix of bundle sizes, complex networks, etc.=A0 If you d= o a PING, you can, with high degree of confidence, conclude that you have c= onnectivity, but not much else.=A0 To date, IMHO, we haven't done much more= that the equivalent of a PING with regard to DTN RFC5050 (and nearly every= one I've talked to has realized that there system wasn't synced to the 30 s= econd default in DTNPING.).=0A=0A=0AI was attracted to this research group = because there are so many areas ripe for research.=A0 That hasn't changed i= n over 7 years or more. All categories are still wide open for research.=0A= =0AWill Ivancic=0ASyzygy Engineering =0A=0A=0A=0A=0A=0A____________________= ____________ --1552829269-1568648109-1403029476=:99627 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Some thoughts:

I think we need some deep philosophical discus= sion at the BOF on what we are trying to do with DTN.  Most (actually = ALL) deployments I am aware of have been in the order of probably tens or l= ess nodes - certainly less than 100.  Are we developing a standard for= space systems or looking at hundreds of thousands or millions of nodes?

I think the last time IETF worked a speci= fic problem it was TCPSAT and, I believe, the IETF decided that we would no= t do work on a specific deployment area.  (Fortunately, the TCP over S= atellite actually had a more generic problem which was time/bandwidth.)&nbs= p; If the end result is deploying over 100 nodes (10 nodes in 10 deployment= s) in the next 5 years, I doubt we should be considering a standard at this= time.

There has never been a "problem statement" written, so we don't really know what problem we are trying to = solve.  Is Scalability an issue?  I think so.

There is currently  no document of which I am aware of= that states what the default operation of a forwarding agent is.  For= example, if you have no route, do you drop a bundle even if it has not exp= ired or do you hold it in anticipation of perhaps having a route later?&nbs= p;

I do know that some groups want t= o run DTN (RFC5050) at extremely high rates (Gbps and higher).  The cu= rrent structure, while nice for research with all the flexibility, is not v= ery well suited for high-speed deployments - particularly if you are consid= ering space-based hardware and processors.  Do we address this?=

"We believe that the extensive research, demonstra= tion, and
      pilot operations performed to d= ate using the DTNRG protocols provides
      a firm basis for publishing Internet standards derived from that work."

Quite honestly, I cannot agree with this state= ment.  I have seen very little with regards to scalability, a mix of t= raffic, a mix of bundle lifetimes, a mix of bundle sizes, complex networks,= etc.  If you do a PING, you can, with high degree of confidence, conc= lude that you have connectivity, but not much else.  To date, IMHO, we= haven't done much more that the equivalent of a PING with regard to DTN RF= C5050 (and nearly everyone I've talked to has realized that there system wa= sn't synced to the 30 second default in DTNPING.).
I was attracted to this research group because there are so = many areas ripe for research.  That hasn't changed in over 7 years or = more. All categories are still wide open for research.

Will Ivancic
Syzygy Engineering


=
--1552829269-1568648109-1403029476=:99627-- From nobody Tue Jun 17 12:50:36 2014 Return-Path: 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 28AFF1A00E7 for ; Tue, 17 Jun 2014 12:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 8uM5N8etsgft for ; Tue, 17 Jun 2014 12:50:30 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 002461A00C0 for ; Tue, 17 Jun 2014 12:50:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s5HJoS24008933; Tue, 17 Jun 2014 14:50:28 -0500 Received: from XCH-PHX-501.sw.nos.boeing.com (xch-phx-501.sw.nos.boeing.com [137.136.239.53]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s5HJoIPB008359 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 17 Jun 2014 14:50:19 -0500 Received: from XCH-BLV-512.nw.nos.boeing.com ([169.254.12.74]) by XCH-PHX-501.sw.nos.boeing.com ([169.254.8.60]) with mapi id 14.03.0181.006; Tue, 17 Jun 2014 12:50:18 -0700 From: "Templin, Fred L" To: William Ivancic , "dtn@ietf.org" Thread-Topic: [dtn] Draft Charter Discussion Thread-Index: Ac+GbO3wN7xIp4CqSFeVEjvJc65+vAAPLd8AAAy+SjAAJnyrgAC3CG0QABBXewAADJn14A== Date: Tue, 17 Jun 2014 19:50:17 +0000 Message-ID: <2134F8430051B64F815C691A62D983183048DD26@XCH-BLV-512.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> <2134F8430051B64F815C691A62D983183048B3B6@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983183048DB80@XCH-BLV-512.nw.nos.boeing.com> <1403029476.99627.YahooMailNeo@web125106.mail.ne1.yahoo.com> In-Reply-To: <1403029476.99627.YahooMailNeo@web125106.mail.ne1.yahoo.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: multipart/alternative; boundary="_000_2134F8430051B64F815C691A62D983183048DD26XCHBLV512nwnosb_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/6TlY0lBc-4Nv4Iu4XtWU75iUOrk Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 19:50:33 -0000 --_000_2134F8430051B64F815C691A62D983183048DD26XCHBLV512nwnosb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Will, I may address some of your individual points later, but for now I have to s= ay that I don't understand the concern about scalability. The Internet started with a few n= odes with static routing and address provisioning as well as static host tables maint= ained in a central repository (SRI-NIC). The IETF also got its start from the early days begin= ning with the IEN documents and then transitioning into the RFC document series where the cor= e Internet protocols were standardized. That model stood for many years while the Inte= rnet grew to larger scale, and not until much later did dynamic routing protocols, the D= omain Name System and DHCP come online. I don't see why a similar model would not hold= for DTN, independent of specific use cases. I think another fallacy in the scaling concern is the notion that there wou= ld be "one DTN" in the beginning in the same way that we have "one Internet" today. Instead, I= can imagine there would be many independent DTNs established for many diverse use cases= . Some of these purpose-built DTNs might be joined together at some point in the f= uture to form larger DTNs, and to accommodate seamless interoperability we needs interope= rable IETF standards from the very beginning - sort of like how the Internet got start= ed. Thanks - Fred From: William Ivancic [mailto:ivancic@syzygyengineering.com] Sent: Tuesday, June 17, 2014 11:25 AM To: Templin, Fred L; dtn@ietf.org Subject: Re: [dtn] Draft Charter Discussion Some thoughts: I think we need some deep philosophical discussion at the BOF on what we ar= e trying to do with DTN. Most (actually ALL) deployments I am aware of hav= e been in the order of probably tens or less nodes - certainly less than 10= 0. Are we developing a standard for space systems or looking at hundreds o= f thousands or millions of nodes? I think the last time IETF worked a specific problem it was TCPSAT and, I b= elieve, the IETF decided that we would not do work on a specific deployment= area. (Fortunately, the TCP over Satellite actually had a more generic pr= oblem which was time/bandwidth.) If the end result is deploying over 100 n= odes (10 nodes in 10 deployments) in the next 5 years, I doubt we should be= considering a standard at this time. There has never been a "problem statement" written, so we don't really know= what problem we are trying to solve. Is Scalability an issue? I think so= . There is currently no document of which I am aware of that states what the= default operation of a forwarding agent is. For example, if you have no r= oute, do you drop a bundle even if it has not expired or do you hold it in = anticipation of perhaps having a route later? I do know that some groups want to run DTN (RFC5050) at extremely high rate= s (Gbps and higher). The current structure, while nice for research with a= ll the flexibility, is not very well suited for high-speed deployments - pa= rticularly if you are considering space-based hardware and processors. Do = we address this? "We believe that the extensive research, demonstration, and pilot operations performed to date using the DTNRG protocols provides a firm basis for publishing Internet standards derived from that work= ." Quite honestly, I cannot agree with this statement. I have seen very littl= e with regards to scalability, a mix of traffic, a mix of bundle lifetimes,= a mix of bundle sizes, complex networks, etc. If you do a PING, you can, = with high degree of confidence, conclude that you have connectivity, but no= t much else. To date, IMHO, we haven't done much more that the equivalent = of a PING with regard to DTN RFC5050 (and nearly everyone I've talked to ha= s realized that there system wasn't synced to the 30 second default in DTNP= ING.). I was attracted to this research group because there are so many areas ripe= for research. That hasn't changed in over 7 years or more. All categories= are still wide open for research. Will Ivancic Syzygy Engineering ________________________________ --_000_2134F8430051B64F815C691A62D983183048DD26XCHBLV512nwnosb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Will,

 <= /p>

I may address some of you= r individual points later, but for now I have to say that I don’t

understand the concern ab= out scalability. The Internet started with a few nodes with

static routing and addres= s provisioning as well as static host tables maintained in a central

repository (SRI-NIC). The= IETF also got its start from the early days beginning with the IEN

documents and then transi= tioning into the RFC document series where the core Internet

protocols were standardiz= ed. That model stood for many years while the Internet grew to

larger scale, and not unt= il much later did dynamic routing protocols, the Domain Name

System and DHCP come onli= ne. I don’t see why a similar model would not hold for DTN,

independent of specific u= se cases.

 <= /p>

I think another fallacy i= n the scaling concern is the notion that there would be “one DTN̶= 1; in

the beginning in the same= way that we have “one Internet” today. Instead, I can imagine<= o:p>

there would be many indep= endent DTNs established for many diverse use cases. Some<= /p>

of these purpose-built DT= Ns might be joined together at some point in the future to form<= /span>

larger DTNs, and to accom= modate seamless interoperability we needs interoperable IETF

standards from the very b= eginning – sort of like how the Internet got started.

 <= /p>

Thanks - Fred<= /span>

 <= /p>

From: William = Ivancic [mailto:ivancic@syzygyengineering.com]
Sent: Tuesday, June 17, 2014 11:25 AM
To: Templin, Fred L; dtn@ietf.org
Subject: Re: [dtn] Draft Charter Discussion

 

Some thoughts:=

 

I think we need some deep philosophical discus= sion at the BOF on what we are trying to do with DTN.  Most (actually = ALL) deployments I am aware of have been in the order of probably tens or less nodes - certainly less than 100.  Are we developing a st= andard for space systems or looking at hundreds of thousands or millions of= nodes?

 

I think the last time IETF worked a specific p= roblem it was TCPSAT and, I believe, the IETF decided that we would not do = work on a specific deployment area.  (Fortunately, the TCP over Satellite actually had a more generic problem which was time/bandwidt= h.)  If the end result is deploying over 100 nodes (10 nodes in 10 dep= loyments) in the next 5 years, I doubt we should be considering a standard = at this time.

 

There has never been a "problem statement= " written, so we don't really know what problem we are trying to solve= .  Is Scalability an issue?  I think so.

 

There is currently  no document of which = I am aware of that states what the default operation of a forwarding agent = is.  For example, if you have no route, do you drop a bundle even if it has not expired or do you hold it in anticipation of perhaps ha= ving a route later? 

 

I do know that some groups want to run DTN (RF= C5050) at extremely high rates (Gbps and higher).  The current structu= re, while nice for research with all the flexibility, is not very well suited for high-speed deployments - particularly if you are cons= idering space-based hardware and processors.  Do we address this?=

 

"We believe that the extensive research, = demonstration, and
      pilot operations performed to date using the= DTNRG protocols provides
      a firm basis for publishing Internet standar= ds derived from that work."

 

Quite honestly, I cannot agree with this state= ment.  I have seen very little with regards to scalability, a mix of t= raffic, a mix of bundle lifetimes, a mix of bundle sizes, complex networks, etc.  If you do a PING, you can, with high degree of confid= ence, conclude that you have connectivity, but not much else.  To date= , IMHO, we haven't done much more that the equivalent of a PING with regard= to DTN RFC5050 (and nearly everyone I've talked to has realized that there system wasn't synced to the 30 second de= fault in DTNPING.).

 

I was attracted to this research group because= there are so many areas ripe for research.  That hasn't changed in ov= er 7 years or more. All categories are still wide open for research.

 

Will Ivancic

Syzygy Engineering

 

 

 

 

--_000_2134F8430051B64F815C691A62D983183048DD26XCHBLV512nwnosb_-- From nobody Tue Jun 17 13:05:05 2014 Return-Path: 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 A54F41A0160 for ; Tue, 17 Jun 2014 13:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 8I9qQwE5GMov for ; Tue, 17 Jun 2014 13:04:54 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A566D1A00DF for ; Tue, 17 Jun 2014 13:04:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id F2B74BF0D; Tue, 17 Jun 2014 21:04:52 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nNGMvYwqlEp; Tue, 17 Jun 2014 21:04:49 +0100 (IST) Received: from [10.87.48.12] (unknown [86.46.21.97]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 92AF4BF09; Tue, 17 Jun 2014 21:04:49 +0100 (IST) Message-ID: <53A09F61.2030900@cs.tcd.ie> Date: Tue, 17 Jun 2014 21:04:49 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Templin, Fred L" , "dtn@ietf.org" References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> <2134F8430051B64F815C691A62D983183048B3B6@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983183048DB80@XCH-BLV-512.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983183048DB80@XCH-BLV-512.nw.nos.boeing.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/6LQD9hhnTSjqGXUcVqKI9gJbs7M Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 20:04:56 -0000 Fred and others, I think I've asked this before so apologies if I just forget the good answer;-) We have the space use-case and some fairly well known niche terrestrial use-cases, which are fine. But we've known these for years and the DTNRG didn't want to move to the standards track until now. I think it'd help the IESG to decide whether to approve a WG if there were more information available about what has changed to motivate moving to the standards track. If (say for Boeing) those are such that you can't say and there aren't any others who can, then that's a pity, since it does make it harder to get why a 5050bis on the standards track is attractive. I'm just noting this again because I think many recent successful BoFs have tended to have this topic as part of the agenda, but it seems missing in yours, which just assumes that the room knows that RFC5050 needs a bit of work. (I'm exaggerating a bit there, but I hope you get what I mean.) S. On 17/06/14 18:40, Templin, Fred L wrote: > Please see below for an updated version of the draft charter based > on list discussions, and post any further comments in follow-up. > (See also attached for diffs relative to the previous version.) > > Thanks - Fred > fred.l.templin@boeing.com > > --- > > Draft BoF Agenda (2.5hrs): > ************************** > 1) Problem statement (IETF wg motivation) - 30min > > 2) RFC5050(bis) - 15min > > 3) Streamlined Bundle Security Protocol (SBSP) - 15min > > 4) Security Key Management - 10min > > 5) Network Management - 10min > > 6) Contact Graph Routing and Contact Plan Update Protocol - 10min > > 7) Bundle-in-Bundle Encapsulation - 5min > > 8) Registry for Service Identifiers - 5min > > 9) Open Discussion - 50min > > > Draft working group charter: > **************************** > Working group name: > > Delay/Disruption Tolerant Networking Working Group (DTNWG) > > Chair(s): > > TBD > > Area and Area Director(s): > > Transport Area: ADs Spencer Dawkins , > Martin Stiemerling > > Responsible Area Director: > > TBD > > Mailing list: > > General Discussion: dtn at ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/dtn > Archive: http://www.ietf.org/mail-archive/web/dtn/current/maillist.html > > Description of Working Group: > > The Delay/Disruption Tolerant Network Working Group (DTNWG) specifies > mechanisms for data communications in the presence of long delays > and/or intermittent connectivity. The work is motivated by well known > limitations of standard Internet protocols that expect end-to-end > connectivity between communicating endpoints, sub-second transmission > delays and robust packet delivery ratios. In environments where these > favorable conditions do not apply, existing mechanisms encounter problems > such as reliable transport protocol handshakes timing out and routing > protocols failing to converge resulting in communication failures. > Furthermore, classical end-to-end security associations cannot be > coordinated when communicating endpoints cannot conduct multi-message > keying exchanges in a timely fashion. These limitations suggested the > need for a new approach. > > Delay-Tolerant Networking (DTN) protocols have been the subject of > extensive research and development in the Delay-Tolerant Networking > Research Group (DTNRG) of the Internet Research Task Force since 2002. > The DTNRG has developed the Delay-Tolerant Networking Architecture > (RFC 4838) that the DTNWG uses as the basis for its work. The key > components of the this architecture are the bundle concept for > encapsulating data units, the bundle transmission protocol and the > underlying convergence layer architecture. > > The experimental DTN Bundle Protocol (RFC 5050) and Licklider > Transmission Protocol (RFC 5326) have been shown to address the > issues identified above in substantial fielded deployments in the space > sector [1]. RFC 5050 in conjunction with TCP- and UDP-based convergence > layers has been used successfully in a number of experiments both in > communications challenged environments around the edges of the Internet > and as an Internet overlay where applications require delay- and/or > disruption-tolerance [refs needed]. > > The success of the BP over convergence layer protocol stack -- the core > protocols of the "DTN Architecture" described in RFC 4838 -- may be > attributed to the following fundamental design principles: > > - There is never any expectation of contemporaneous end-to-end > connectivity between any two network nodes. > > - Because end-to-end connectivity can never be assumed, each node > on the path between source and destination must be prepared to > handle incoming "bundles" of data that cannot immediately be > forwarded. > > - Again because end-to-end connectivity can never be assumed, > end-to-end conversational data exchange can never be assumed to > complete in a timely manner; protocol features that rely on > timely conversational data exchange must be excluded from the > architecture. > > The DTNWG believes that protocols adhering to these principles offer > opportunities for enhancing the functionality of the Internet, including > > - facilitating the extension of the Internet into environments such as > the ocean floor and deep space in which the core Internet protocols > operate sub-optimally for the reasons discussed earlier; > > - extending the Internet into communications challenged terrestrial > environments where it is not possible to provide continuous, low > delay Internet connections; and > > - supporting Internet applications that need DTN capabiliies. > > We believe that the extensive research, demonstration, and > pilot operations performed to date using the DTNRG protocols provides > a firm basis for publishing Internet standards derived from that work. > > Work items related to Delay/Disruption Tolerant Networking include: > > o A mechanism for the exchange of protocol data units, termed > "bundles", that are designed to obviate conversational communications > by containing values for all potentially relevant configuration > parameters. These protocol data units are typically larger than > network-layer packets. We will derive this bundle exchange mechanism > from the DTN Bundle Protocol (BP) documented in RFC 5050 by publishing > a new document for which [2] is a proposed first draft (where > appendix A provides a summary of the proposed changes). > > o A security protocol for ensuring that the network in which bundles > are exchanged is secured against unauthorized access and denial of > service attacks, and to ensure data integrity and confidentiality > in that network where necessary. We will derive this security > protocol from a "streamlined" adaptation of the DTN Bundle Security > Protocol documented in RFC 6257. > > o A delay-tolerant security key management scheme that can protect > the integrity of a DTN network. > > o A simple datagram convergence layer protocol for adaptation of the > bundle protocol to underlying internetworks. We expect to derive > this convergence layer protocol from the Datagram Convergence > protocol documented in RFC 7122. > > o A protocol for remote status monitoring, configuration, and > administration of network nodes in the presence of long delays > and/or intermittent connectivity. > > o A functional specification of Contact Graph Routing (CGR) specifying > the inputs (global contact schedules, traffic demands, etc.) and > outputs (node specific transmission and reception schedules, > notifications, etc.). CGR is a centralized, oracle-based bundle > transmission and reception scheduling scheme used in space segment > DTN deployments. > > o An adjunct to the management protocol that will allow the contact > schedules generated by CGR to be distributed to nodes. This may be > based on the Contact Plan Update Protocol (CPUP) proposed in > > o An encapsulation protocol for "tunneling" BP traffic within bundles > that are secured and/or routed in different way from the encapsulated > bundles. > > o A registry for DTN Service Identifiers > > The working group will consider extending the current milestones based on > new information and knowledge gained while working on the initial charter, > as well as to accommodate new work items beyond the scope of the initial > phase. For example, we expect that transport protocols such as LTP and > the Saratoga protocol are among the candidates for work in this phase. > > Goals and Milestones: > start+0mos - Accept 'Bundle Protocol Specification (RFC5050bis)' [2] as > a working group work item intended for Proposed Standard. > Start+0mos - Accept 'Streamlined Bundle Security Protocol (SBSP)' [3] as > a working group work item intended for Proposed Standard. > start+3mos - Accept 'Bundle In Bundle Encapsulation (BIBE)' [4] as a > working work item intended for Proposed Standard. > start+6mos - Working group getting concensus on changes to be implemented > in RFC 5050(bis). > start+9mos - Working group getting consensus on merging RFC5050bis, SBSP, > BIBE etc. into a combined draft or keep as separate drafts. > start+12mos - Accept 'CGR Functional Specification' as a working group > working group work item intended for Informational. > start+12mos - Accept 'Delay Tolerant Networking Security Key Management' > as a working group work item intended for Proposed Standard. > start+15mos - Accept 'Contact Plan Update Protocol' as working group work > item intended for Proposed Standard. > start+18mos - Submit RFC5050bis, SBSP, BIBE and Key Mgmt to the IESG either > as a combined draft or as separate drafts. > start+18mos - Submit Network Management [5], Registry [6] and Simple > Convergence Layer [7] as working group documents. > start+20mos - Survey appropriate forums (e.g., DTNRG) for emerging > technologies (e.g., convergence layer protocols, dynamic > routing protocols, naming and addressing services, etc.) > ready for transition into IETF DTN Working Group. Publish > draft on survey results as independent submission related > to the WG. > start+24mos - Submit Network Management, Registry and Simple Convergence > Layer to IESG > start+24mos - Recharter to accommodate new work items or close Working Group > > > [1] "BP/LTP deployment on EPOXI spacecraft" [2008], > http://committees.comsoc.org/tccc/ccw/2010/slides/DINET_CCW.pdf > [2] "Proposed Revised Bundle Protocol" [2014], > https://datatracker.ietf.org/doc/draft-burleigh-bpv7/ > [3] "Streamlined Bundle Security Protocol Specification" [2014], > https://datatracker.ietf.org/doc/draft-irtf-dtnrg-sbsp/ > [4] "Bundle-in-Bundle Encapsulation" [2013], > http://tools.ietf.org/id/draft-irtf-burleigh-bibe > [5] "Delay Tolerant Network Management Protocol" [2013], > http://tools.ietf.org/id/draft-irtf-dtnrg-dtnmp > [6] "Delay-Tolerant Networking Bundle Protocol IANA Registries" [2011], > https://datatracker.ietf.org/doc/rfc6255/ > [7] "Datagram Convergence Layers ..." [2014], > https://datatracker.ietf.org/doc/rfc7122/ > [8] "Towards Flexibility and Accuracy in Space DTN Communications", > Bezirgianndia et al, CHANTS 2012, > http://dl.acm.org/citation.cfm?id=2505499 [2012] > > > > _______________________________________________ > dtn mailing list > dtn@ietf.org > https://www.ietf.org/mailman/listinfo/dtn > From nobody Tue Jun 17 13:12:28 2014 Return-Path: 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 41C651A0123 for ; Tue, 17 Jun 2014 13:12:26 -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 xYCMOZM_5ift for ; Tue, 17 Jun 2014 13:12:23 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B3EF1A011C for ; Tue, 17 Jun 2014 13:12:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s5HKCNO4011600; Tue, 17 Jun 2014 13:12:23 -0700 Received: from XCH-PHX-205.sw.nos.boeing.com (xch-phx-205.sw.nos.boeing.com [137.136.238.16]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s5HKCFBj011506 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 17 Jun 2014 13:12:15 -0700 Received: from XCH-BLV-512.nw.nos.boeing.com ([169.254.12.74]) by XCH-PHX-205.sw.nos.boeing.com ([169.254.1.106]) with mapi id 14.03.0181.006; Tue, 17 Jun 2014 13:12:15 -0700 From: "Templin, Fred L" To: Stephen Farrell , "dtn@ietf.org" Thread-Topic: [dtn] Draft Charter Discussion Thread-Index: Ac+GbO3wN7xIp4CqSFeVEjvJc65+vAAPLd8AAAy+SjAAJnyrgAC3CG0QABPXfIAADpF2cA== Date: Tue, 17 Jun 2014 20:12:14 +0000 Message-ID: <2134F8430051B64F815C691A62D983183048DD9A@XCH-BLV-512.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> <2134F8430051B64F815C691A62D983183048B3B6@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983183048DB80@XCH-BLV-512.nw.nos.boeing.com> <53A09F61.2030900@cs.tcd.ie> In-Reply-To: <53A09F61.2030900@cs.tcd.ie> 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/2IgQwKk1vft25nUhz2Hp8f39Egs Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 20:12:26 -0000 Hi Stephen, > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Tuesday, June 17, 2014 1:05 PM > To: Templin, Fred L; dtn@ietf.org > Subject: Re: [dtn] Draft Charter Discussion >=20 >=20 > Fred and others, >=20 > I think I've asked this before so apologies if I just forget > the good answer;-) >=20 > We have the space use-case and some fairly well known niche > terrestrial use-cases, which are fine. But we've known these > for years and the DTNRG didn't want to move to the standards > track until now. Yes, a diverse set of use cases and not a single use case. That means that in the early days there may be many purpose-built DTNs that may at a later time be joined together to form larger DTNs. A "DTN-of-DTNs" in the same way that the Internet is a "network- of-networks". The whole reason the Internet was able to join together smaller networks to form larger networks is that the Internet had interoperable standards from the very beginning. It is now time for us to do that for DTN. Thanks - Fred fred.l.templin@boeing.com=20 > I think it'd help the IESG to decide whether to approve a > WG if there were more information available about what has > changed to motivate moving to the standards track. >=20 > If (say for Boeing) those are such that you can't say and > there aren't any others who can, then that's a pity, since > it does make it harder to get why a 5050bis on the standards > track is attractive. >=20 > I'm just noting this again because I think many recent > successful BoFs have tended to have this topic as part of > the agenda, but it seems missing in yours, which just > assumes that the room knows that RFC5050 needs a bit of > work. (I'm exaggerating a bit there, but I hope you get > what I mean.) >=20 > S. >=20 > On 17/06/14 18:40, Templin, Fred L wrote: > > Please see below for an updated version of the draft charter based > > on list discussions, and post any further comments in follow-up. > > (See also attached for diffs relative to the previous version.) > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > --- > > > > Draft BoF Agenda (2.5hrs): > > ************************** > > 1) Problem statement (IETF wg motivation) - 30min > > > > 2) RFC5050(bis) - 15min > > > > 3) Streamlined Bundle Security Protocol (SBSP) - 15min > > > > 4) Security Key Management - 10min > > > > 5) Network Management - 10min > > > > 6) Contact Graph Routing and Contact Plan Update Protocol - 10min > > > > 7) Bundle-in-Bundle Encapsulation - 5min > > > > 8) Registry for Service Identifiers - 5min > > > > 9) Open Discussion - 50min > > > > > > Draft working group charter: > > **************************** > > Working group name: > > > > Delay/Disruption Tolerant Networking Working Group (DTNWG) > > > > Chair(s): > > > > TBD > > > > Area and Area Director(s): > > > > Transport Area: ADs Spencer Dawkins , > > Martin Stiemerling > > > > Responsible Area Director: > > > > TBD > > > > Mailing list: > > > > General Discussion: dtn at ietf.org > > To Subscribe: https://www.ietf.org/mailman/listinfo/dtn > > Archive: http://www.ietf.org/mail-archive/web/dtn/current/maillis= t.html > > > > Description of Working Group: > > > > The Delay/Disruption Tolerant Network Working Group (DTNWG) speci= fies > > mechanisms for data communications in the presence of long delays > > and/or intermittent connectivity. The work is motivated by well k= nown > > limitations of standard Internet protocols that expect end-to-end > > connectivity between communicating endpoints, sub-second transmis= sion > > delays and robust packet delivery ratios. In environments where t= hese > > favorable conditions do not apply, existing mechanisms encounter = problems > > such as reliable transport protocol handshakes timing out and rou= ting > > protocols failing to converge resulting in communication failures= . > > Furthermore, classical end-to-end security associations cannot be > > coordinated when communicating endpoints cannot conduct multi-mes= sage > > keying exchanges in a timely fashion. These limitations suggested= the > > need for a new approach. > > > > Delay-Tolerant Networking (DTN) protocols have been the subject o= f > > extensive research and development in the Delay-Tolerant Networki= ng > > Research Group (DTNRG) of the Internet Research Task Force since = 2002. > > The DTNRG has developed the Delay-Tolerant Networking Architectur= e > > (RFC 4838) that the DTNWG uses as the basis for its work. The ke= y > > components of the this architecture are the bundle concept for > > encapsulating data units, the bundle transmission protocol and th= e > > underlying convergence layer architecture. > > > > The experimental DTN Bundle Protocol (RFC 5050) and Licklider > > Transmission Protocol (RFC 5326) have been shown to address the > > issues identified above in substantial fielded deployments in the= space > > sector [1]. RFC 5050 in conjunction with TCP- and UDP-based conv= ergence > > layers has been used successfully in a number of experiments both= in > > communications challenged environments around the edges of the In= ternet > > and as an Internet overlay where applications require delay- and/= or > > disruption-tolerance [refs needed]. > > > > The success of the BP over convergence layer protocol stack -- th= e core > > protocols of the "DTN Architecture" described in RFC 4838 -- may = be > > attributed to the following fundamental design principles: > > > > - There is never any expectation of contemporaneous end-to-end > > connectivity between any two network nodes. > > > > - Because end-to-end connectivity can never be assumed, each node > > on the path between source and destination must be prepared to > > handle incoming "bundles" of data that cannot immediately be > > forwarded. > > > > - Again because end-to-end connectivity can never be assumed, > > end-to-end conversational data exchange can never be assumed to > > complete in a timely manner; protocol features that rely on > > timely conversational data exchange must be excluded from the > > architecture. > > > > The DTNWG believes that protocols adhering to these principles of= fer > > opportunities for enhancing the functionality of the Internet, in= cluding > > > > - facilitating the extension of the Internet into environments = such as > > the ocean floor and deep space in which the core Internet pro= tocols > > operate sub-optimally for the reasons discussed earlier; > > > > - extending the Internet into communications challenged terrest= rial > > environments where it is not possible to provide continuous, = low > > delay Internet connections; and > > > > - supporting Internet applications that need DTN capabiliies. > > > > We believe that the extensive research, demonstration, and > > pilot operations performed to date using the DTNRG protocols prov= ides > > a firm basis for publishing Internet standards derived from that = work. > > > > Work items related to Delay/Disruption Tolerant Networking includ= e: > > > > o A mechanism for the exchange of protocol data units, termed > > "bundles", that are designed to obviate conversational communicatio= ns > > by containing values for all potentially relevant configuration > > parameters. These protocol data units are typically larger than > > network-layer packets. We will derive this bundle exchange mechanis= m > > from the DTN Bundle Protocol (BP) documented in RFC 5050 by pub= lishing > > a new document for which [2] is a proposed first draft (where > > appendix A provides a summary of the proposed changes). > > > > o A security protocol for ensuring that the network in which bund= les > > are exchanged is secured against unauthorized access and denial of > > service attacks, and to ensure data integrity and confidentiality > > in that network where necessary. We will derive this security > > protocol from a "streamlined" adaptation of the DTN Bundle Security > > Protocol documented in RFC 6257. > > > > o A delay-tolerant security key management scheme that can prote= ct > > the integrity of a DTN network. > > > > o A simple datagram convergence layer protocol for adaptation of = the > > bundle protocol to underlying internetworks. We expect to deriv= e > > this convergence layer protocol from the Datagram Convergence > > protocol documented in RFC 7122. > > > > o A protocol for remote status monitoring, configuration, and > > administration of network nodes in the presence of long delays > > and/or intermittent connectivity. > > > > o A functional specification of Contact Graph Routing (CGR) speci= fying > > the inputs (global contact schedules, traffic demands, etc.) an= d > > outputs (node specific transmission and reception schedules, > > notifications, etc.). CGR is a centralized, oracle-based bundl= e > > transmission and reception scheduling scheme used in space segm= ent > > DTN deployments. > > > > o An adjunct to the management protocol that will allow the conta= ct > > schedules generated by CGR to be distributed to nodes. This ma= y be > > based on the Contact Plan Update Protocol (CPUP) proposed in > > > > o An encapsulation protocol for "tunneling" BP traffic within bun= dles > > that are secured and/or routed in different way from the encapsulat= ed > > bundles. > > > > o A registry for DTN Service Identifiers > > > > The working group will consider extending the current milestones ba= sed on > > new information and knowledge gained while working on the initial c= harter, > > as well as to accommodate new work items beyond the scope of the in= itial > > phase. For example, we expect that transport protocols such as LTP= and > > the Saratoga protocol are among the candidates for work in this pha= se. > > > > Goals and Milestones: > > start+0mos - Accept 'Bundle Protocol Specification (RFC5050bis)' [2] = as > > a working group work item intended for Proposed Standard= . > > Start+0mos - Accept 'Streamlined Bundle Security Protocol (SBSP)' [3]= as > > a working group work item intended for Proposed Standard= . > > start+3mos - Accept 'Bundle In Bundle Encapsulation (BIBE)' [4] as a > > working work item intended for Proposed Standard. > > start+6mos - Working group getting concensus on changes to be impleme= nted > > in RFC 5050(bis). > > start+9mos - Working group getting consensus on merging RFC5050bis, S= BSP, > > BIBE etc. into a combined draft or keep as separate draf= ts. > > start+12mos - Accept 'CGR Functional Specification' as a working grou= p > > working group work item intended for Informational. > > start+12mos - Accept 'Delay Tolerant Networking Security Key Manageme= nt' > > as a working group work item intended for Proposed Stan= dard. > > start+15mos - Accept 'Contact Plan Update Protocol' as working group = work > > item intended for Proposed Standard. > > start+18mos - Submit RFC5050bis, SBSP, BIBE and Key Mgmt to the IESG = either > > as a combined draft or as separate drafts. > > start+18mos - Submit Network Management [5], Registry [6] and Simple > > Convergence Layer [7] as working group documents. > > start+20mos - Survey appropriate forums (e.g., DTNRG) for emerging > > technologies (e.g., convergence layer protocols, dynami= c > > routing protocols, naming and addressing services, etc.= ) > > ready for transition into IETF DTN Working Group. Publi= sh > > draft on survey results as independent submission relat= ed > > to the WG. > > start+24mos - Submit Network Management, Registry and Simple Converge= nce > > Layer to IESG > > start+24mos - Recharter to accommodate new work items or close Workin= g Group > > > > > > [1] "BP/LTP deployment on EPOXI spacecraft" [2008], > > http://committees.comsoc.org/tccc/ccw/2010/slides/DINET_CCW.pdf > > [2] "Proposed Revised Bundle Protocol" [2014], > > https://datatracker.ietf.org/doc/draft-burleigh-bpv7/ > > [3] "Streamlined Bundle Security Protocol Specification" [2014], > > https://datatracker.ietf.org/doc/draft-irtf-dtnrg-sbsp/ > > [4] "Bundle-in-Bundle Encapsulation" [2013], > > http://tools.ietf.org/id/draft-irtf-burleigh-bibe > > [5] "Delay Tolerant Network Management Protocol" [2013], > > http://tools.ietf.org/id/draft-irtf-dtnrg-dtnmp > > [6] "Delay-Tolerant Networking Bundle Protocol IANA Registries" [2011], > > https://datatracker.ietf.org/doc/rfc6255/ > > [7] "Datagram Convergence Layers ..." [2014], > > https://datatracker.ietf.org/doc/rfc7122/ > > [8] "Towards Flexibility and Accuracy in Space DTN Communications", > > Bezirgianndia et al, CHANTS 2012, > > http://dl.acm.org/citation.cfm?id=3D2505499 [2012] > > > > > > > > _______________________________________________ > > dtn mailing list > > dtn@ietf.org > > https://www.ietf.org/mailman/listinfo/dtn > > From nobody Tue Jun 17 13:19:22 2014 Return-Path: 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 4E1D51A011C for ; Tue, 17 Jun 2014 13:19:21 -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 3g3jYcxjV-86 for ; Tue, 17 Jun 2014 13:19:17 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FD8A1A010C for ; Tue, 17 Jun 2014 13:19:17 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp01.jpl.nasa.gov [128.149.137.148]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s5HKJGNt023661 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO) for ; Tue, 17 Jun 2014 13:19:16 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.217]) by ap-ehub-sp01.RES.AD.JPL ([169.254.3.182]) with mapi id 14.03.0174.001; Tue, 17 Jun 2014 13:19:15 -0700 From: "Burleigh, Scott C (312G)" To: "dtn@ietf.org" Thread-Topic: [dtn] Draft Charter Discussion Thread-Index: Ac+GbO3wN7xIp4CqSFeVEjvJc65+vAAPLd8AAAy+SjAAJnyrgAC3CG0QABPXfIAADoUqgA== Date: Tue, 17 Jun 2014 20:19:14 +0000 Message-ID: References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> <2134F8430051B64F815C691A62D983183048B3B6@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983183048DB80@XCH-BLV-512.nw.nos.boeing.com> <53A09F61.2030900@cs.tcd.ie> In-Reply-To: <53A09F61.2030900@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.26] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/iJNvmZ8oTiF-FRBo30_n2JqgbQk Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 20:19:21 -0000 Stephen, I'm confused: the first 30 minutes of the agenda Fred has proposed= are reserved for "Problem statement (IETF wg motivation)". Are you saying= that's not as much time as recent successful BoFs have spent on this part = of the agenda? How much more time do you think will be needed? Scott -----Original Message----- From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of Stephen Farrell Sent: Tuesday, June 17, 2014 1:05 PM To: Templin, Fred L; dtn@ietf.org Subject: Re: [dtn] Draft Charter Discussion Fred and others, I think I've asked this before so apologies if I just forget the good answe= r;-) We have the space use-case and some fairly well known niche terrestrial use= -cases, which are fine. But we've known these for years and the DTNRG didn'= t want to move to the standards track until now. I think it'd help the IESG to decide whether to approve a WG if there were = more information available about what has changed to motivate moving to the= standards track. If (say for Boeing) those are such that you can't say and there aren't any = others who can, then that's a pity, since it does make it harder to get why= a 5050bis on the standards track is attractive. I'm just noting this again because I think many recent successful BoFs have= tended to have this topic as part of the agenda, but it seems missing in y= ours, which just assumes that the room knows that RFC5050 needs a bit of wo= rk. (I'm exaggerating a bit there, but I hope you get what I mean.) S. On 17/06/14 18:40, Templin, Fred L wrote: > Please see below for an updated version of the draft charter based on=20 > list discussions, and post any further comments in follow-up. > (See also attached for diffs relative to the previous version.) >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > --- >=20 > Draft BoF Agenda (2.5hrs): > ************************** > 1) Problem statement (IETF wg motivation) - 30min >=20 > 2) RFC5050(bis) - 15min >=20 > 3) Streamlined Bundle Security Protocol (SBSP) - 15min >=20 > 4) Security Key Management - 10min >=20 > 5) Network Management - 10min >=20 > 6) Contact Graph Routing and Contact Plan Update Protocol - 10min >=20 > 7) Bundle-in-Bundle Encapsulation - 5min >=20 > 8) Registry for Service Identifiers - 5min >=20 > 9) Open Discussion - 50min >=20 >=20 > Draft working group charter: > **************************** > Working group name:=20 >=20 > Delay/Disruption Tolerant Networking Working Group (DTNWG) >=20 > Chair(s): >=20 > TBD >=20 > Area and Area Director(s): >=20 > Transport Area: ADs Spencer Dawkins , > Martin Stiemerling >=20 > Responsible Area Director: >=20 > TBD >=20 > Mailing list: >=20 > General Discussion: dtn at ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/dtn > Archive:=20 > http://www.ietf.org/mail-archive/web/dtn/current/maillist.html >=20 > Description of Working Group: >=20 > The Delay/Disruption Tolerant Network Working Group (DTNWG) specifi= es > mechanisms for data communications in the presence of long delays > and/or intermittent connectivity. The work is motivated by well kno= wn > limitations of standard Internet protocols that expect end-to-end > connectivity between communicating endpoints, sub-second transmissi= on > delays and robust packet delivery ratios. In environments where the= se > favorable conditions do not apply, existing mechanisms encounter pr= oblems=20 > such as reliable transport protocol handshakes timing out and routi= ng=20 > protocols failing to converge resulting in communication failures.= =20 > Furthermore, classical end-to-end security associations cannot be=20 > coordinated when communicating endpoints cannot conduct multi-messa= ge=20 > keying exchanges in a timely fashion. These limitations suggested t= he=20 > need for a new approach.=20 > =20 > Delay-Tolerant Networking (DTN) protocols have been the subject of > extensive research and development in the Delay-Tolerant Networking > Research Group (DTNRG) of the Internet Research Task Force since 20= 02. > The DTNRG has developed the Delay-Tolerant Networking Architecture= =20 > (RFC 4838) that the DTNWG uses as the basis for its work. The key= =20 > components of the this architecture are the bundle concept for=20 > encapsulating data units, the bundle transmission protocol and the= =20 > underlying convergence layer architecture. > =20 > The experimental DTN Bundle Protocol (RFC 5050) and Licklider > Transmission Protocol (RFC 5326) have been shown to address the > issues identified above in substantial fielded deployments in the s= pace=20 > sector [1]. RFC 5050 in conjunction with TCP- and UDP-based conver= gence=20 > layers has been used successfully in a number of experiments both i= n=20 > communications challenged environments around the edges of the Inte= rnet=20 > and as an Internet overlay where applications require delay- and/or= =20 > disruption-tolerance [refs needed]. =20 >=20 > The success of the BP over convergence layer protocol stack -- the = core=20 > protocols of the "DTN Architecture" described in RFC 4838 -- may be= =20 > attributed to the following fundamental design principles: >=20 > - There is never any expectation of contemporaneous end-to-end > connectivity between any two network nodes. >=20 > - Because end-to-end connectivity can never be assumed, each node > on the path between source and destination must be prepared to > handle incoming "bundles" of data that cannot immediately be > forwarded. >=20 > - Again because end-to-end connectivity can never be assumed, > end-to-end conversational data exchange can never be assumed to > complete in a timely manner; protocol features that rely on > timely conversational data exchange must be excluded from the > architecture. >=20 > The DTNWG believes that protocols adhering to these principles offe= r > opportunities for enhancing the functionality of the Internet,=20 > including >=20 > - facilitating the extension of the Internet into environments su= ch as=20 > the ocean floor and deep space in which the core Internet proto= cols=20 > operate sub-optimally for the reasons discussed earlier; >=20 > - extending the Internet into communications challenged terrestri= al=20 > environments where it is not possible to provide continuous, lo= w=20 > delay Internet connections; and >=20 > - supporting Internet applications that need DTN capabiliies. >=20 > We believe that the extensive research, demonstration, and > pilot operations performed to date using the DTNRG protocols provid= es > a firm basis for publishing Internet standards derived from that wo= rk. >=20 > Work items related to Delay/Disruption Tolerant Networking include: >=20 > o A mechanism for the exchange of protocol data units, termed > "bundles", that are designed to obviate conversational communications > by containing values for all potentially relevant configuration > parameters. These protocol data units are typically larger than > network-layer packets. We will derive this bundle exchange mechanism > from the DTN Bundle Protocol (BP) documented in RFC 5050 by publi= shing > a new document for which [2] is a proposed first draft (where > appendix A provides a summary of the proposed changes). >=20 > o A security protocol for ensuring that the network in which bundle= s > are exchanged is secured against unauthorized access and denial of > service attacks, and to ensure data integrity and confidentiality > in that network where necessary. We will derive this security > protocol from a "streamlined" adaptation of the DTN Bundle Security > Protocol documented in RFC 6257. >=20 > o A delay-tolerant security key management scheme that can protect > the integrity of a DTN network. >=20 > o A simple datagram convergence layer protocol for adaptation of th= e > bundle protocol to underlying internetworks. We expect to derive > this convergence layer protocol from the Datagram Convergence > protocol documented in RFC 7122. >=20 > o A protocol for remote status monitoring, configuration, and > administration of network nodes in the presence of long delays > and/or intermittent connectivity. >=20 > o A functional specification of Contact Graph Routing (CGR) specify= ing=20 > the inputs (global contact schedules, traffic demands, etc.) and= =20 > outputs (node specific transmission and reception schedules,=20 > notifications, etc.). CGR is a centralized, oracle-based bundle= =20 > transmission and reception scheduling scheme used in space segmen= t=20 > DTN deployments. >=20 > o An adjunct to the management protocol that will allow the contact= =20 > schedules generated by CGR to be distributed to nodes. This may = be=20 > based on the Contact Plan Update Protocol (CPUP) proposed in >=20 > o An encapsulation protocol for "tunneling" BP traffic within bundl= es > that are secured and/or routed in different way from the encapsulated > bundles. >=20 > o A registry for DTN Service Identifiers > =20 > The working group will consider extending the current milestones base= d on > new information and knowledge gained while working on the initial cha= rter, > as well as to accommodate new work items beyond the scope of the init= ial > phase. For example, we expect that transport protocols such as LTP a= nd > the Saratoga protocol are among the candidates for work in this phase= . > =20 > Goals and Milestones: > start+0mos - Accept 'Bundle Protocol Specification (RFC5050bis)' [2] as > a working group work item intended for Proposed Standard. > Start+0mos - Accept 'Streamlined Bundle Security Protocol (SBSP)' [3] a= s > a working group work item intended for Proposed Standard. > start+3mos - Accept 'Bundle In Bundle Encapsulation (BIBE)' [4] as a > working work item intended for Proposed Standard. > start+6mos - Working group getting concensus on changes to be implement= ed > in RFC 5050(bis). > start+9mos - Working group getting consensus on merging RFC5050bis, SBS= P, > BIBE etc. into a combined draft or keep as separate drafts= . > start+12mos - Accept 'CGR Functional Specification' as a working group= =20 > working group work item intended for Informational. > start+12mos - Accept 'Delay Tolerant Networking Security Key Management= ' > as a working group work item intended for Proposed Standa= rd. > start+15mos - Accept 'Contact Plan Update Protocol' as working group wo= rk > item intended for Proposed Standard. > start+18mos - Submit RFC5050bis, SBSP, BIBE and Key Mgmt to the IESG ei= ther > as a combined draft or as separate drafts. > start+18mos - Submit Network Management [5], Registry [6] and Simple > Convergence Layer [7] as working group documents. > start+20mos - Survey appropriate forums (e.g., DTNRG) for emerging > technologies (e.g., convergence layer protocols, dynamic > routing protocols, naming and addressing services, etc.) > ready for transition into IETF DTN Working Group. Publish > draft on survey results as independent submission related > to the WG. > start+24mos - Submit Network Management, Registry and Simple Convergenc= e > Layer to IESG > start+24mos - Recharter to accommodate new work items or close=20 > Working Group >=20 >=20 > [1] "BP/LTP deployment on EPOXI spacecraft" [2008], > http://committees.comsoc.org/tccc/ccw/2010/slides/DINET_CCW.pdf > [2] "Proposed Revised Bundle Protocol" [2014], > https://datatracker.ietf.org/doc/draft-burleigh-bpv7/ > [3] "Streamlined Bundle Security Protocol Specification" [2014], > https://datatracker.ietf.org/doc/draft-irtf-dtnrg-sbsp/ > [4] "Bundle-in-Bundle Encapsulation" [2013], > http://tools.ietf.org/id/draft-irtf-burleigh-bibe > [5] "Delay Tolerant Network Management Protocol" [2013], > http://tools.ietf.org/id/draft-irtf-dtnrg-dtnmp > [6] "Delay-Tolerant Networking Bundle Protocol IANA Registries" [2011], > https://datatracker.ietf.org/doc/rfc6255/ > [7] "Datagram Convergence Layers ..." [2014], > https://datatracker.ietf.org/doc/rfc7122/ > [8] "Towards Flexibility and Accuracy in Space DTN Communications", > Bezirgianndia et al, CHANTS 2012, > http://dl.acm.org/citation.cfm?id=3D2505499 [2012] >=20 >=20 >=20 > _______________________________________________ > dtn mailing list > dtn@ietf.org > https://www.ietf.org/mailman/listinfo/dtn >=20 _______________________________________________ dtn mailing list dtn@ietf.org https://www.ietf.org/mailman/listinfo/dtn From nobody Tue Jun 17 13:21:11 2014 Return-Path: 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 ; 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 ; 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 ; 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 ; 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" To: "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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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. From nobody Tue Jun 17 13:32:00 2014 Return-Path: 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 C557D1A011C for ; Tue, 17 Jun 2014 13:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 jL7xz8KBOLP2 for ; Tue, 17 Jun 2014 13:31:56 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 15F611A010C for ; Tue, 17 Jun 2014 13:31:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2C3B7BF1A; Tue, 17 Jun 2014 21:31:55 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWI372xvAfyV; Tue, 17 Jun 2014 21:31:52 +0100 (IST) Received: from [10.87.48.12] (unknown [86.46.21.97]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7B5C1BEDB; Tue, 17 Jun 2014 21:31:52 +0100 (IST) Message-ID: <53A0A5B8.1090802@cs.tcd.ie> Date: Tue, 17 Jun 2014 21:31:52 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Templin, Fred L" , "dtn@ietf.org" References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> <2134F8430051B64F815C691A62D983183048B3B6@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983183048DB80@XCH-BLV-512.nw.nos.boeing.com> <53A09F61.2030900@cs.tcd.ie> <2134F8430051B64F815C691A62D983183048DD9A@XCH-BLV-512.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983183048DD9A@XCH-BLV-512.nw.nos.boeing.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/gr-Kg_VGVSJRvVMZJS2KiUE-TUY Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 20:31:58 -0000 Hi Fred, On 17/06/14 21:12, Templin, Fred L wrote: > Hi Stephen, > >> -----Original Message----- >> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >> Sent: Tuesday, June 17, 2014 1:05 PM >> To: Templin, Fred L; dtn@ietf.org >> Subject: Re: [dtn] Draft Charter Discussion >> >> >> Fred and others, >> >> I think I've asked this before so apologies if I just forget >> the good answer;-) >> >> We have the space use-case and some fairly well known niche >> terrestrial use-cases, which are fine. But we've known these >> for years and the DTNRG didn't want to move to the standards >> track until now. > > Yes, a diverse set of use cases and not a single use case. That > means that in the early days there may be many purpose-built DTNs > that may at a later time be joined together to form larger DTNs. > A "DTN-of-DTNs" in the same way that the Internet is a "network- > of-networks". > > The whole reason the Internet was able to join together smaller > networks to form larger networks is that the Internet had > interoperable standards from the very beginning. It is now > time for us to do that for DTN. I'm familiar with DTN. But I find the above a pretty complete non-answer to the question asked (in that it answers no part of my question:-) So I'll try again, in a more direct fashion... I do not know why specifically Boeing want a standards track RFC5050bis, nor why you want it now. And I'm wondering and would like to know. I have not heard your use-case (or business case, whatever) explained so far. Nor have I heard someone say "can't/won't tell, sorry." So I'm curious. And I'll note once again that successful BoFs tend to involve explaining why this, now, specifically. As an IESG member it makes it much easier for me to evaluate proposals for forming a WG. (BTW, any answer that asks me to think like an acorn won't really work for this question, sorry:-) If someone else has a new answer to this question that would also be interesting. By new, I mean a use-case or business-case that hasn't previously been discussed in the DTNRG. Cheers, S. PS: In case there's confusion. My question is very much not the same as Will's, despite your answer being very similar. > > Thanks - Fred > fred.l.templin@boeing.com > >> I think it'd help the IESG to decide whether to approve a >> WG if there were more information available about what has >> changed to motivate moving to the standards track. >> >> If (say for Boeing) those are such that you can't say and >> there aren't any others who can, then that's a pity, since >> it does make it harder to get why a 5050bis on the standards >> track is attractive. >> >> I'm just noting this again because I think many recent >> successful BoFs have tended to have this topic as part of >> the agenda, but it seems missing in yours, which just >> assumes that the room knows that RFC5050 needs a bit of >> work. (I'm exaggerating a bit there, but I hope you get >> what I mean.) >> >> S. >> >> On 17/06/14 18:40, Templin, Fred L wrote: >>> Please see below for an updated version of the draft charter based >>> on list discussions, and post any further comments in follow-up. >>> (See also attached for diffs relative to the previous version.) >>> >>> Thanks - Fred >>> fred.l.templin@boeing.com >>> >>> --- >>> >>> Draft BoF Agenda (2.5hrs): >>> ************************** >>> 1) Problem statement (IETF wg motivation) - 30min >>> >>> 2) RFC5050(bis) - 15min >>> >>> 3) Streamlined Bundle Security Protocol (SBSP) - 15min >>> >>> 4) Security Key Management - 10min >>> >>> 5) Network Management - 10min >>> >>> 6) Contact Graph Routing and Contact Plan Update Protocol - 10min >>> >>> 7) Bundle-in-Bundle Encapsulation - 5min >>> >>> 8) Registry for Service Identifiers - 5min >>> >>> 9) Open Discussion - 50min >>> >>> >>> Draft working group charter: >>> **************************** >>> Working group name: >>> >>> Delay/Disruption Tolerant Networking Working Group (DTNWG) >>> >>> Chair(s): >>> >>> TBD >>> >>> Area and Area Director(s): >>> >>> Transport Area: ADs Spencer Dawkins , >>> Martin Stiemerling >>> >>> Responsible Area Director: >>> >>> TBD >>> >>> Mailing list: >>> >>> General Discussion: dtn at ietf.org >>> To Subscribe: https://www.ietf.org/mailman/listinfo/dtn >>> Archive: http://www.ietf.org/mail-archive/web/dtn/current/maillist.html >>> >>> Description of Working Group: >>> >>> The Delay/Disruption Tolerant Network Working Group (DTNWG) specifies >>> mechanisms for data communications in the presence of long delays >>> and/or intermittent connectivity. The work is motivated by well known >>> limitations of standard Internet protocols that expect end-to-end >>> connectivity between communicating endpoints, sub-second transmission >>> delays and robust packet delivery ratios. In environments where these >>> favorable conditions do not apply, existing mechanisms encounter problems >>> such as reliable transport protocol handshakes timing out and routing >>> protocols failing to converge resulting in communication failures. >>> Furthermore, classical end-to-end security associations cannot be >>> coordinated when communicating endpoints cannot conduct multi-message >>> keying exchanges in a timely fashion. These limitations suggested the >>> need for a new approach. >>> >>> Delay-Tolerant Networking (DTN) protocols have been the subject of >>> extensive research and development in the Delay-Tolerant Networking >>> Research Group (DTNRG) of the Internet Research Task Force since 2002. >>> The DTNRG has developed the Delay-Tolerant Networking Architecture >>> (RFC 4838) that the DTNWG uses as the basis for its work. The key >>> components of the this architecture are the bundle concept for >>> encapsulating data units, the bundle transmission protocol and the >>> underlying convergence layer architecture. >>> >>> The experimental DTN Bundle Protocol (RFC 5050) and Licklider >>> Transmission Protocol (RFC 5326) have been shown to address the >>> issues identified above in substantial fielded deployments in the space >>> sector [1]. RFC 5050 in conjunction with TCP- and UDP-based convergence >>> layers has been used successfully in a number of experiments both in >>> communications challenged environments around the edges of the Internet >>> and as an Internet overlay where applications require delay- and/or >>> disruption-tolerance [refs needed]. >>> >>> The success of the BP over convergence layer protocol stack -- the core >>> protocols of the "DTN Architecture" described in RFC 4838 -- may be >>> attributed to the following fundamental design principles: >>> >>> - There is never any expectation of contemporaneous end-to-end >>> connectivity between any two network nodes. >>> >>> - Because end-to-end connectivity can never be assumed, each node >>> on the path between source and destination must be prepared to >>> handle incoming "bundles" of data that cannot immediately be >>> forwarded. >>> >>> - Again because end-to-end connectivity can never be assumed, >>> end-to-end conversational data exchange can never be assumed to >>> complete in a timely manner; protocol features that rely on >>> timely conversational data exchange must be excluded from the >>> architecture. >>> >>> The DTNWG believes that protocols adhering to these principles offer >>> opportunities for enhancing the functionality of the Internet, including >>> >>> - facilitating the extension of the Internet into environments such as >>> the ocean floor and deep space in which the core Internet protocols >>> operate sub-optimally for the reasons discussed earlier; >>> >>> - extending the Internet into communications challenged terrestrial >>> environments where it is not possible to provide continuous, low >>> delay Internet connections; and >>> >>> - supporting Internet applications that need DTN capabiliies. >>> >>> We believe that the extensive research, demonstration, and >>> pilot operations performed to date using the DTNRG protocols provides >>> a firm basis for publishing Internet standards derived from that work. >>> >>> Work items related to Delay/Disruption Tolerant Networking include: >>> >>> o A mechanism for the exchange of protocol data units, termed >>> "bundles", that are designed to obviate conversational communications >>> by containing values for all potentially relevant configuration >>> parameters. These protocol data units are typically larger than >>> network-layer packets. We will derive this bundle exchange mechanism >>> from the DTN Bundle Protocol (BP) documented in RFC 5050 by publishing >>> a new document for which [2] is a proposed first draft (where >>> appendix A provides a summary of the proposed changes). >>> >>> o A security protocol for ensuring that the network in which bundles >>> are exchanged is secured against unauthorized access and denial of >>> service attacks, and to ensure data integrity and confidentiality >>> in that network where necessary. We will derive this security >>> protocol from a "streamlined" adaptation of the DTN Bundle Security >>> Protocol documented in RFC 6257. >>> >>> o A delay-tolerant security key management scheme that can protect >>> the integrity of a DTN network. >>> >>> o A simple datagram convergence layer protocol for adaptation of the >>> bundle protocol to underlying internetworks. We expect to derive >>> this convergence layer protocol from the Datagram Convergence >>> protocol documented in RFC 7122. >>> >>> o A protocol for remote status monitoring, configuration, and >>> administration of network nodes in the presence of long delays >>> and/or intermittent connectivity. >>> >>> o A functional specification of Contact Graph Routing (CGR) specifying >>> the inputs (global contact schedules, traffic demands, etc.) and >>> outputs (node specific transmission and reception schedules, >>> notifications, etc.). CGR is a centralized, oracle-based bundle >>> transmission and reception scheduling scheme used in space segment >>> DTN deployments. >>> >>> o An adjunct to the management protocol that will allow the contact >>> schedules generated by CGR to be distributed to nodes. This may be >>> based on the Contact Plan Update Protocol (CPUP) proposed in >>> >>> o An encapsulation protocol for "tunneling" BP traffic within bundles >>> that are secured and/or routed in different way from the encapsulated >>> bundles. >>> >>> o A registry for DTN Service Identifiers >>> >>> The working group will consider extending the current milestones based on >>> new information and knowledge gained while working on the initial charter, >>> as well as to accommodate new work items beyond the scope of the initial >>> phase. For example, we expect that transport protocols such as LTP and >>> the Saratoga protocol are among the candidates for work in this phase. >>> >>> Goals and Milestones: >>> start+0mos - Accept 'Bundle Protocol Specification (RFC5050bis)' [2] as >>> a working group work item intended for Proposed Standard. >>> Start+0mos - Accept 'Streamlined Bundle Security Protocol (SBSP)' [3] as >>> a working group work item intended for Proposed Standard. >>> start+3mos - Accept 'Bundle In Bundle Encapsulation (BIBE)' [4] as a >>> working work item intended for Proposed Standard. >>> start+6mos - Working group getting concensus on changes to be implemented >>> in RFC 5050(bis). >>> start+9mos - Working group getting consensus on merging RFC5050bis, SBSP, >>> BIBE etc. into a combined draft or keep as separate drafts. >>> start+12mos - Accept 'CGR Functional Specification' as a working group >>> working group work item intended for Informational. >>> start+12mos - Accept 'Delay Tolerant Networking Security Key Management' >>> as a working group work item intended for Proposed Standard. >>> start+15mos - Accept 'Contact Plan Update Protocol' as working group work >>> item intended for Proposed Standard. >>> start+18mos - Submit RFC5050bis, SBSP, BIBE and Key Mgmt to the IESG either >>> as a combined draft or as separate drafts. >>> start+18mos - Submit Network Management [5], Registry [6] and Simple >>> Convergence Layer [7] as working group documents. >>> start+20mos - Survey appropriate forums (e.g., DTNRG) for emerging >>> technologies (e.g., convergence layer protocols, dynamic >>> routing protocols, naming and addressing services, etc.) >>> ready for transition into IETF DTN Working Group. Publish >>> draft on survey results as independent submission related >>> to the WG. >>> start+24mos - Submit Network Management, Registry and Simple Convergence >>> Layer to IESG >>> start+24mos - Recharter to accommodate new work items or close Working Group >>> >>> >>> [1] "BP/LTP deployment on EPOXI spacecraft" [2008], >>> http://committees.comsoc.org/tccc/ccw/2010/slides/DINET_CCW.pdf >>> [2] "Proposed Revised Bundle Protocol" [2014], >>> https://datatracker.ietf.org/doc/draft-burleigh-bpv7/ >>> [3] "Streamlined Bundle Security Protocol Specification" [2014], >>> https://datatracker.ietf.org/doc/draft-irtf-dtnrg-sbsp/ >>> [4] "Bundle-in-Bundle Encapsulation" [2013], >>> http://tools.ietf.org/id/draft-irtf-burleigh-bibe >>> [5] "Delay Tolerant Network Management Protocol" [2013], >>> http://tools.ietf.org/id/draft-irtf-dtnrg-dtnmp >>> [6] "Delay-Tolerant Networking Bundle Protocol IANA Registries" [2011], >>> https://datatracker.ietf.org/doc/rfc6255/ >>> [7] "Datagram Convergence Layers ..." [2014], >>> https://datatracker.ietf.org/doc/rfc7122/ >>> [8] "Towards Flexibility and Accuracy in Space DTN Communications", >>> Bezirgianndia et al, CHANTS 2012, >>> http://dl.acm.org/citation.cfm?id=2505499 [2012] >>> >>> >>> >>> _______________________________________________ >>> 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 > > From nobody Tue Jun 17 14:13:14 2014 Return-Path: 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 3D7031A0168 for ; Tue, 17 Jun 2014 14:13:11 -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 HDqF8T9adWUh for ; Tue, 17 Jun 2014 14:13:06 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ABA81A0174 for ; Tue, 17 Jun 2014 14:13:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s5HLD5ht023453; Tue, 17 Jun 2014 14:13:05 -0700 Received: from XCH-PHX-107.sw.nos.boeing.com (xch-phx-107.sw.nos.boeing.com [137.136.238.10]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s5HLCutD023362 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 17 Jun 2014 14:12:56 -0700 Received: from XCH-BLV-112.nw.nos.boeing.com (137.136.239.105) by XCH-PHX-107.sw.nos.boeing.com (137.136.238.10) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 17 Jun 2014 14:12:55 -0700 Received: from XCH-BLV-512.nw.nos.boeing.com ([169.254.12.74]) by XCH-BLV-112.nw.nos.boeing.com ([169.254.11.47]) with mapi id 14.03.0181.006; Tue, 17 Jun 2014 14:12:55 -0700 From: "Templin, Fred L" To: Stephen Farrell , "dtn@ietf.org" Thread-Topic: [dtn] Draft Charter Discussion Thread-Index: Ac+GbO3wN7xIp4CqSFeVEjvJc65+vAAPLd8AAAy+SjAAJnyrgAC3CG0QABPXfIAADpF2cP//kwMAgABwdMA= Date: Tue, 17 Jun 2014 21:12:55 +0000 Message-ID: <2134F8430051B64F815C691A62D983183048DEE6@XCH-BLV-512.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> <2134F8430051B64F815C691A62D983183048B3B6@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983183048DB80@XCH-BLV-512.nw.nos.boeing.com> <53A09F61.2030900@cs.tcd.ie> <2134F8430051B64F815C691A62D983183048DD9A@XCH-BLV-512.nw.nos.boeing.com> <53A0A5B8.1090802@cs.tcd.ie> In-Reply-To: <53A0A5B8.1090802@cs.tcd.ie> 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/nI8rXBHP-FA0WFNkJLEj1ypFHtM Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 21:13:11 -0000 Hi Stephen, > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Tuesday, June 17, 2014 1:32 PM > To: Templin, Fred L; dtn@ietf.org > Subject: Re: [dtn] Draft Charter Discussion >=20 >=20 > Hi Fred, >=20 > On 17/06/14 21:12, Templin, Fred L wrote: > > Hi Stephen, > > > >> -----Original Message----- > >> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > >> Sent: Tuesday, June 17, 2014 1:05 PM > >> To: Templin, Fred L; dtn@ietf.org > >> Subject: Re: [dtn] Draft Charter Discussion > >> > >> > >> Fred and others, > >> > >> I think I've asked this before so apologies if I just forget > >> the good answer;-) > >> > >> We have the space use-case and some fairly well known niche > >> terrestrial use-cases, which are fine. But we've known these > >> for years and the DTNRG didn't want to move to the standards > >> track until now. > > > > Yes, a diverse set of use cases and not a single use case. That > > means that in the early days there may be many purpose-built DTNs > > that may at a later time be joined together to form larger DTNs. > > A "DTN-of-DTNs" in the same way that the Internet is a "network- > > of-networks". > > > > The whole reason the Internet was able to join together smaller > > networks to form larger networks is that the Internet had > > interoperable standards from the very beginning. It is now > > time for us to do that for DTN. >=20 > I'm familiar with DTN. But I find the above a pretty > complete non-answer to the question asked (in that it > answers no part of my question:-) So I'll try again, > in a more direct fashion... I am sorry you didn't find my answer helpful, but I am somewhat puzzled by that. The Internet was enabled by the bedrock standards (IP, TCP, etc.) that allowed for joining smaller networks together into larger ones without the need for complex gateway mechanisms at the borders. The same should be true for DTN. > I do not know why specifically Boeing want a standards > track RFC5050bis, nor why you want it now. >=20 > And I'm wondering and would like to know. I have not heard > your use-case (or business case, whatever) explained so far. > Nor have I heard someone say "can't/won't tell, sorry." > So I'm curious. I am not permitted to discuss my company's business plans on a public forum (i.e., "can't tell - sorry"). > And I'll note once again that successful BoFs tend to > involve explaining why this, now, specifically. As an > IESG member it makes it much easier for me to evaluate > proposals for forming a WG. I know you didn't like the answer, but let's say we had two DTNs - one for space based applications, and one for tracking the wildebeest migration across the plains of Africa - and we wanted to join the two DTNs together. It is easy if both DTNs are using the same protocols, and much harder if each DTN uses its own custom protocol (which Gnu would you put the complex border gateway function on?). > (BTW, any answer that asks me to think like an acorn > won't really work for this question, sorry:-) > > If someone else has a new answer to this question that > would also be interesting. By new, I mean a use-case > or business-case that hasn't previously been discussed > in the DTNRG. My company for one is large and with diverse business interests, as I'm sure many others are. Where those business interests intersect, we may wish to join multiple DTNs together seamlessly and without having to stand up complex gateways. That is why we need standard protocols. Thanks - Fred fred.l.templin@boeing.com =20 > Cheers, > S. >=20 > PS: In case there's confusion. My question is very much > not the same as Will's, despite your answer being very > similar. >=20 > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> I think it'd help the IESG to decide whether to approve a > >> WG if there were more information available about what has > >> changed to motivate moving to the standards track. > >> > >> If (say for Boeing) those are such that you can't say and > >> there aren't any others who can, then that's a pity, since > >> it does make it harder to get why a 5050bis on the standards > >> track is attractive. > >> > >> I'm just noting this again because I think many recent > >> successful BoFs have tended to have this topic as part of > >> the agenda, but it seems missing in yours, which just > >> assumes that the room knows that RFC5050 needs a bit of > >> work. (I'm exaggerating a bit there, but I hope you get > >> what I mean.) > >> > >> S. > >> > >> On 17/06/14 18:40, Templin, Fred L wrote: > >>> Please see below for an updated version of the draft charter based > >>> on list discussions, and post any further comments in follow-up. > >>> (See also attached for diffs relative to the previous version.) > >>> > >>> Thanks - Fred > >>> fred.l.templin@boeing.com > >>> > >>> --- > >>> > >>> Draft BoF Agenda (2.5hrs): > >>> ************************** > >>> 1) Problem statement (IETF wg motivation) - 30min > >>> > >>> 2) RFC5050(bis) - 15min > >>> > >>> 3) Streamlined Bundle Security Protocol (SBSP) - 15min > >>> > >>> 4) Security Key Management - 10min > >>> > >>> 5) Network Management - 10min > >>> > >>> 6) Contact Graph Routing and Contact Plan Update Protocol - 10min > >>> > >>> 7) Bundle-in-Bundle Encapsulation - 5min > >>> > >>> 8) Registry for Service Identifiers - 5min > >>> > >>> 9) Open Discussion - 50min > >>> > >>> > >>> Draft working group charter: > >>> **************************** > >>> Working group name: > >>> > >>> Delay/Disruption Tolerant Networking Working Group (DTNWG) > >>> > >>> Chair(s): > >>> > >>> TBD > >>> > >>> Area and Area Director(s): > >>> > >>> Transport Area: ADs Spencer Dawkins , > >>> Martin Stiemerling > >>> > >>> Responsible Area Director: > >>> > >>> TBD > >>> > >>> Mailing list: > >>> > >>> General Discussion: dtn at ietf.org > >>> To Subscribe: https://www.ietf.org/mailman/listinfo/dtn > >>> Archive: http://www.ietf.org/mail-archive/web/dtn/current/maill= ist.html > >>> > >>> Description of Working Group: > >>> > >>> The Delay/Disruption Tolerant Network Working Group (DTNWG) spe= cifies > >>> mechanisms for data communications in the presence of long dela= ys > >>> and/or intermittent connectivity. The work is motivated by well= known > >>> limitations of standard Internet protocols that expect end-to-e= nd > >>> connectivity between communicating endpoints, sub-second transm= ission > >>> delays and robust packet delivery ratios. In environments where= these > >>> favorable conditions do not apply, existing mechanisms encounte= r problems > >>> such as reliable transport protocol handshakes timing out and r= outing > >>> protocols failing to converge resulting in communication failur= es. > >>> Furthermore, classical end-to-end security associations cannot = be > >>> coordinated when communicating endpoints cannot conduct multi-m= essage > >>> keying exchanges in a timely fashion. These limitations suggest= ed the > >>> need for a new approach. > >>> > >>> Delay-Tolerant Networking (DTN) protocols have been the subject= of > >>> extensive research and development in the Delay-Tolerant Networ= king > >>> Research Group (DTNRG) of the Internet Research Task Force sinc= e 2002. > >>> The DTNRG has developed the Delay-Tolerant Networking Architect= ure > >>> (RFC 4838) that the DTNWG uses as the basis for its work. The = key > >>> components of the this architecture are the bundle concept for > >>> encapsulating data units, the bundle transmission protocol and = the > >>> underlying convergence layer architecture. > >>> > >>> The experimental DTN Bundle Protocol (RFC 5050) and Licklider > >>> Transmission Protocol (RFC 5326) have been shown to address the > >>> issues identified above in substantial fielded deployments in t= he space > >>> sector [1]. RFC 5050 in conjunction with TCP- and UDP-based co= nvergence > >>> layers has been used successfully in a number of experiments bo= th in > >>> communications challenged environments around the edges of the = Internet > >>> and as an Internet overlay where applications require delay- an= d/or > >>> disruption-tolerance [refs needed]. > >>> > >>> The success of the BP over convergence layer protocol stack -- = the core > >>> protocols of the "DTN Architecture" described in RFC 4838 -- ma= y be > >>> attributed to the following fundamental design principles: > >>> > >>> - There is never any expectation of contemporaneous end-to-end > >>> connectivity between any two network nodes. > >>> > >>> - Because end-to-end connectivity can never be assumed, each node > >>> on the path between source and destination must be prepared to > >>> handle incoming "bundles" of data that cannot immediately be > >>> forwarded. > >>> > >>> - Again because end-to-end connectivity can never be assumed, > >>> end-to-end conversational data exchange can never be assumed to > >>> complete in a timely manner; protocol features that rely on > >>> timely conversational data exchange must be excluded from the > >>> architecture. > >>> > >>> The DTNWG believes that protocols adhering to these principles = offer > >>> opportunities for enhancing the functionality of the Internet, = including > >>> > >>> - facilitating the extension of the Internet into environment= s such as > >>> the ocean floor and deep space in which the core Internet p= rotocols > >>> operate sub-optimally for the reasons discussed earlier; > >>> > >>> - extending the Internet into communications challenged terre= strial > >>> environments where it is not possible to provide continuous= , low > >>> delay Internet connections; and > >>> > >>> - supporting Internet applications that need DTN capabiliies. > >>> > >>> We believe that the extensive research, demonstration, and > >>> pilot operations performed to date using the DTNRG protocols pr= ovides > >>> a firm basis for publishing Internet standards derived from tha= t work. > >>> > >>> Work items related to Delay/Disruption Tolerant Networking incl= ude: > >>> > >>> o A mechanism for the exchange of protocol data units, termed > >>> "bundles", that are designed to obviate conversational communicat= ions > >>> by containing values for all potentially relevant configuration > >>> parameters. These protocol data units are typically larger than > >>> network-layer packets. We will derive this bundle exchange mechan= ism > >>> from the DTN Bundle Protocol (BP) documented in RFC 5050 by p= ublishing > >>> a new document for which [2] is a proposed first draft (where > >>> appendix A provides a summary of the proposed changes). > >>> > >>> o A security protocol for ensuring that the network in which bu= ndles > >>> are exchanged is secured against unauthorized access and denial o= f > >>> service attacks, and to ensure data integrity and confidentiality > >>> in that network where necessary. We will derive this security > >>> protocol from a "streamlined" adaptation of the DTN Bundle Securi= ty > >>> Protocol documented in RFC 6257. > >>> > >>> o A delay-tolerant security key management scheme that can pro= tect > >>> the integrity of a DTN network. > >>> > >>> o A simple datagram convergence layer protocol for adaptation o= f the > >>> bundle protocol to underlying internetworks. We expect to der= ive > >>> this convergence layer protocol from the Datagram Convergence > >>> protocol documented in RFC 7122. > >>> > >>> o A protocol for remote status monitoring, configuration, and > >>> administration of network nodes in the presence of long delay= s > >>> and/or intermittent connectivity. > >>> > >>> o A functional specification of Contact Graph Routing (CGR) spe= cifying > >>> the inputs (global contact schedules, traffic demands, etc.) = and > >>> outputs (node specific transmission and reception schedules, > >>> notifications, etc.). CGR is a centralized, oracle-based bun= dle > >>> transmission and reception scheduling scheme used in space se= gment > >>> DTN deployments. > >>> > >>> o An adjunct to the management protocol that will allow the con= tact > >>> schedules generated by CGR to be distributed to nodes. This = may be > >>> based on the Contact Plan Update Protocol (CPUP) proposed in > >>> > >>> o An encapsulation protocol for "tunneling" BP traffic within b= undles > >>> that are secured and/or routed in different way from the encapsul= ated > >>> bundles. > >>> > >>> o A registry for DTN Service Identifiers > >>> > >>> The working group will consider extending the current milestones = based on > >>> new information and knowledge gained while working on the initial= charter, > >>> as well as to accommodate new work items beyond the scope of the = initial > >>> phase. For example, we expect that transport protocols such as L= TP and > >>> the Saratoga protocol are among the candidates for work in this p= hase. > >>> > >>> Goals and Milestones: > >>> start+0mos - Accept 'Bundle Protocol Specification (RFC5050bis)' [2= ] as > >>> a working group work item intended for Proposed Standa= rd. > >>> Start+0mos - Accept 'Streamlined Bundle Security Protocol (SBSP)' [= 3] as > >>> a working group work item intended for Proposed Standa= rd. > >>> start+3mos - Accept 'Bundle In Bundle Encapsulation (BIBE)' [4] as = a > >>> working work item intended for Proposed Standard. > >>> start+6mos - Working group getting concensus on changes to be imple= mented > >>> in RFC 5050(bis). > >>> start+9mos - Working group getting consensus on merging RFC5050bis,= SBSP, > >>> BIBE etc. into a combined draft or keep as separate dr= afts. > >>> start+12mos - Accept 'CGR Functional Specification' as a working gr= oup > >>> working group work item intended for Informational. > >>> start+12mos - Accept 'Delay Tolerant Networking Security Key Manage= ment' > >>> as a working group work item intended for Proposed St= andard. > >>> start+15mos - Accept 'Contact Plan Update Protocol' as working grou= p work > >>> item intended for Proposed Standard. > >>> start+18mos - Submit RFC5050bis, SBSP, BIBE and Key Mgmt to the IES= G either > >>> as a combined draft or as separate drafts. > >>> start+18mos - Submit Network Management [5], Registry [6] and Simpl= e > >>> Convergence Layer [7] as working group documents. > >>> start+20mos - Survey appropriate forums (e.g., DTNRG) for emerging > >>> technologies (e.g., convergence layer protocols, dyna= mic > >>> routing protocols, naming and addressing services, et= c.) > >>> ready for transition into IETF DTN Working Group. Pub= lish > >>> draft on survey results as independent submission rel= ated > >>> to the WG. > >>> start+24mos - Submit Network Management, Registry and Simple Conver= gence > >>> Layer to IESG > >>> start+24mos - Recharter to accommodate new work items or close Work= ing Group > >>> > >>> > >>> [1] "BP/LTP deployment on EPOXI spacecraft" [2008], > >>> http://committees.comsoc.org/tccc/ccw/2010/slides/DINET_CCW.pdf > >>> [2] "Proposed Revised Bundle Protocol" [2014], > >>> https://datatracker.ietf.org/doc/draft-burleigh-bpv7/ > >>> [3] "Streamlined Bundle Security Protocol Specification" [2014], > >>> https://datatracker.ietf.org/doc/draft-irtf-dtnrg-sbsp/ > >>> [4] "Bundle-in-Bundle Encapsulation" [2013], > >>> http://tools.ietf.org/id/draft-irtf-burleigh-bibe > >>> [5] "Delay Tolerant Network Management Protocol" [2013], > >>> http://tools.ietf.org/id/draft-irtf-dtnrg-dtnmp > >>> [6] "Delay-Tolerant Networking Bundle Protocol IANA Registries" [2011= ], > >>> https://datatracker.ietf.org/doc/rfc6255/ > >>> [7] "Datagram Convergence Layers ..." [2014], > >>> https://datatracker.ietf.org/doc/rfc7122/ > >>> [8] "Towards Flexibility and Accuracy in Space DTN Communications", > >>> Bezirgianndia et al, CHANTS 2012, > >>> http://dl.acm.org/citation.cfm?id=3D2505499 [2012] > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 > > > > From nobody Tue Jun 17 14:24:26 2014 Return-Path: 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 168651A0177 for ; Tue, 17 Jun 2014 14:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.853 X-Spam-Level: X-Spam-Status: No, score=-4.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 Uy0f6KiOZUtF for ; Tue, 17 Jun 2014 14:24:19 -0700 (PDT) Received: from pilot.jhuapl.edu (pilot.jhuapl.edu [128.244.251.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51E821A0168 for ; Tue, 17 Jun 2014 14:24:18 -0700 (PDT) Received: from aplexcas2.dom1.jhuapl.edu (aplexcas2.dom1.jhuapl.edu [128.244.198.91]) by pilot.jhuapl.edu with smtp (TLS: TLSv1/SSLv3,128bits,RC4-MD5) id 1554_424b_45b11b25_37a8_478e_a849_5901c3bee155; Tue, 17 Jun 2014 17:24:09 -0400 Received: from aplesfreedom.dom1.jhuapl.edu ([128.244.198.204]) by aplexcas2.dom1.jhuapl.edu ([128.244.198.91]) with mapi; Tue, 17 Jun 2014 17:24:08 -0400 From: "Birrane, Edward J." To: Stephen Farrell , "Templin, Fred L" , "dtn@ietf.org" Date: Tue, 17 Jun 2014 17:24:08 -0400 Thread-Topic: [dtn] Draft Charter Discussion Thread-Index: Ac+KazKBPaLelvWKQSKWtp0yCQJGYAAATOuQ Message-ID: <329D879C76FDD04AAAE84BB1D89B397009572F23C8@aplesfreedom.dom1.jhuapl.edu> References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> <2134F8430051B64F815C691A62D983183048B3B6@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983183048DB80@XCH-BLV-512.nw.nos.boeing.com> <53A09F61.2030900@cs.tcd.ie> <2134F8430051B64F815C691A62D983183048DD9A@XCH-BLV-512.nw.nos.boeing.com> <53A0A5B8.1090802@cs.tcd.ie> In-Reply-To: <53A0A5B8.1090802@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/_0zdpEPYPcqOgTGPeEinXTK_K_U Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 21:24:23 -0000 Stephen, I certainly can't answer those questions for Boeing or for Fred, but I ha= ve my own answer that I'm willing to share. Having never been an acorn, I a= m not certain if I am thinking like one, but here goes. For years, there have been sample deployments and experiments that show t= he feasibility and functionality of DTN, specifically BP. There have also b= een a smaller set of experiments that identified limitations with BP. From= speaking with government, university, and small businesses my accumulated = opinions are as follows. So, why DTN in non-space cases? - Some like the protocol bits (blocks, custody xfer, queuing, reporting str= ucture) as a consolidated standard and not a layered set of standards and b= est practices. - Some like the automation for delay/disrupted and scaled deployments - it = cuts down on their one-off app point solutions. - Some feel that their analyses indicate DTN overlays can simplify complex = architectures such as TCP PEPs, including how to integrate differing networ= ks using different queuing models. - Some sensor networks behave quite similarly to space networks regarding d= isruption. Underwater scenarios also look similar in terms of delay. Not an exhaustive list, but the highlights from why people are interested i= n a standard that pulls these bits together. Separately, the line between space providers and space users is blurring. L= EO constellations that want to interact seamlessly with terrestrial infrast= ructure as first-class nodes in a network should not be lumped as "space" i= n the sense of deep space missions or older, sparser near-earth deployments= . So, why no scaled DTN deployments yet outside of NASA baselines? - The security mechanism looked overly complex and hard to verify. - There was no progress on management, especially in access-denied and open= -loop areas. - The protocol specs are described in experimental RFCs, with discussion of= a bis. So, why now? - There has been progress on simplifying the security implementations based= on lessons learned. - There is some promising progress (yes, through NASA, but not NASA centric= ) on disruption-scaling management concepts. - There is a set of lessons learned informing 5050bis/BPv7. To Fred's sche= dule, this can be resolved in relatively short order. I know of a few companies and some non-commercial entities that have no iss= ue with BP and are not worried about building a BPA. But an operational de= ployment needs a non-experimental spec, security, and management. There is = much more it needs in the general case, but these seem to be driving requir= ements. I am unsure of what is sufficient proof for your question. Does it have to = be 10 companies interested and not 8? 25 nodes instead of 18? 100? Is the d= eployment horizon 1 year and not 3? So, I naively ask the opposite question: why not standardize this work in t= he IETF? You have the community of people who are willing to do the work, with backi= ng from industry and government. The charter, as I see it, addresses clear = needs for operational deployment, and to Will's points, the DTNRG persists = to continue inspection of the fundamental research issues surrounding more = exotic deployments. -Ed --- Ed Birrane Principal Professional Staff, Space Department Johns Hopkins Applied Physics Laboratory (W) 443-778-7423 / (F) 443-228-3839 > -----Original Message----- > From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of Stephen Farrell > Sent: Tuesday, June 17, 2014 4:32 PM > To: Templin, Fred L; dtn@ietf.org > Subject: Re: [dtn] Draft Charter Discussion > > > Hi Fred, > > On 17/06/14 21:12, Templin, Fred L wrote: > > Hi Stephen, > > > >> -----Original Message----- > >> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > >> Sent: Tuesday, June 17, 2014 1:05 PM > >> To: Templin, Fred L; dtn@ietf.org > >> Subject: Re: [dtn] Draft Charter Discussion > >> > >> > >> Fred and others, > >> > >> I think I've asked this before so apologies if I just forget the good > >> answer;-) > >> > >> We have the space use-case and some fairly well known niche > >> terrestrial use-cases, which are fine. But we've known these for > >> years and the DTNRG didn't want to move to the standards track until > >> now. > > > > Yes, a diverse set of use cases and not a single use case. That means > > that in the early days there may be many purpose-built DTNs that may > > at a later time be joined together to form larger DTNs. > > A "DTN-of-DTNs" in the same way that the Internet is a "network- > > of-networks". > > > > The whole reason the Internet was able to join together smaller > > networks to form larger networks is that the Internet had > > interoperable standards from the very beginning. It is now time for us > > to do that for DTN. > > I'm familiar with DTN. But I find the above a pretty complete non-answer = to > the question asked (in that it answers no part of my question:-) So I'll = try > again, in a more direct fashion... > > I do not know why specifically Boeing want a standards track RFC5050bis, = nor > why you want it now. > > And I'm wondering and would like to know. I have not heard your use-case > (or business case, whatever) explained so far. > Nor have I heard someone say "can't/won't tell, sorry." > So I'm curious. > > And I'll note once again that successful BoFs tend to involve explaining = why > this, now, specifically. As an IESG member it makes it much easier for me= to > evaluate proposals for forming a WG. > > (BTW, any answer that asks me to think like an acorn won't really work fo= r > this question, sorry:-) > > If someone else has a new answer to this question that would also be > interesting. By new, I mean a use-case or business-case that hasn't > previously been discussed in the DTNRG. > > Cheers, > S. > > PS: In case there's confusion. My question is very much not the same as > Will's, despite your answer being very similar. > > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> I think it'd help the IESG to decide whether to approve a WG if there > >> were more information available about what has changed to motivate > >> moving to the standards track. > >> > >> If (say for Boeing) those are such that you can't say and there > >> aren't any others who can, then that's a pity, since it does make it > >> harder to get why a 5050bis on the standards track is attractive. > >> > >> I'm just noting this again because I think many recent successful > >> BoFs have tended to have this topic as part of the agenda, but it > >> seems missing in yours, which just assumes that the room knows that > >> RFC5050 needs a bit of work. (I'm exaggerating a bit there, but I > >> hope you get what I mean.) > >> > >> S. > >> > >> On 17/06/14 18:40, Templin, Fred L wrote: > >>> Please see below for an updated version of the draft charter based > >>> on list discussions, and post any further comments in follow-up. > >>> (See also attached for diffs relative to the previous version.) > >>> > >>> Thanks - Fred > >>> fred.l.templin@boeing.com > >>> > >>> --- > >>> > >>> Draft BoF Agenda (2.5hrs): > >>> ************************** > >>> 1) Problem statement (IETF wg motivation) - 30min > >>> > >>> 2) RFC5050(bis) - 15min > >>> > >>> 3) Streamlined Bundle Security Protocol (SBSP) - 15min > >>> > >>> 4) Security Key Management - 10min > >>> > >>> 5) Network Management - 10min > >>> > >>> 6) Contact Graph Routing and Contact Plan Update Protocol - 10min > >>> > >>> 7) Bundle-in-Bundle Encapsulation - 5min > >>> > >>> 8) Registry for Service Identifiers - 5min > >>> > >>> 9) Open Discussion - 50min > >>> > >>> > >>> Draft working group charter: > >>> **************************** > >>> Working group name: > >>> > >>> Delay/Disruption Tolerant Networking Working Group (DTNWG) > >>> > >>> Chair(s): > >>> > >>> TBD > >>> > >>> Area and Area Director(s): > >>> > >>> Transport Area: ADs Spencer Dawkins gmail.com>, > >>> Martin Stiemerling > >>> > >>> Responsible Area Director: > >>> > >>> TBD > >>> > >>> Mailing list: > >>> > >>> General Discussion: dtn at ietf.org > >>> To Subscribe: https://www.ietf.org/mailman/listinfo/dtn > >>> Archive: > >>> http://www.ietf.org/mail-archive/web/dtn/current/maillist.html > >>> > >>> Description of Working Group: > >>> > >>> The Delay/Disruption Tolerant Network Working Group (DTNWG) > specifies > >>> mechanisms for data communications in the presence of long dela= ys > >>> and/or intermittent connectivity. The work is motivated by well > known > >>> limitations of standard Internet protocols that expect end-to-e= nd > >>> connectivity between communicating endpoints, sub-second > transmission > >>> delays and robust packet delivery ratios. In environments where > these > >>> favorable conditions do not apply, existing mechanisms encounte= r > problems > >>> such as reliable transport protocol handshakes timing out and r= outing > >>> protocols failing to converge resulting in communication failur= es. > >>> Furthermore, classical end-to-end security associations cannot = be > >>> coordinated when communicating endpoints cannot conduct multi- > message > >>> keying exchanges in a timely fashion. These limitations suggest= ed the > >>> need for a new approach. > >>> > >>> Delay-Tolerant Networking (DTN) protocols have been the subject= of > >>> extensive research and development in the Delay-Tolerant > Networking > >>> Research Group (DTNRG) of the Internet Research Task Force sinc= e > 2002. > >>> The DTNRG has developed the Delay-Tolerant Networking > Architecture > >>> (RFC 4838) that the DTNWG uses as the basis for its work. The = key > >>> components of the this architecture are the bundle concept for > >>> encapsulating data units, the bundle transmission protocol and = the > >>> underlying convergence layer architecture. > >>> > >>> The experimental DTN Bundle Protocol (RFC 5050) and Licklider > >>> Transmission Protocol (RFC 5326) have been shown to address the > >>> issues identified above in substantial fielded deployments in t= he > space > >>> sector [1]. RFC 5050 in conjunction with TCP- and UDP-based > convergence > >>> layers has been used successfully in a number of experiments bo= th in > >>> communications challenged environments around the edges of the > Internet > >>> and as an Internet overlay where applications require delay- an= d/or > >>> disruption-tolerance [refs needed]. > >>> > >>> The success of the BP over convergence layer protocol stack -- = the > core > >>> protocols of the "DTN Architecture" described in RFC 4838 -- ma= y be > >>> attributed to the following fundamental design principles: > >>> > >>> - There is never any expectation of contemporaneous end-to-end > >>> connectivity between any two network nodes. > >>> > >>> - Because end-to-end connectivity can never be assumed, each node > >>> on the path between source and destination must be prepared to > >>> handle incoming "bundles" of data that cannot immediately be > >>> forwarded. > >>> > >>> - Again because end-to-end connectivity can never be assumed, > >>> end-to-end conversational data exchange can never be assumed to > >>> complete in a timely manner; protocol features that rely on > >>> timely conversational data exchange must be excluded from the > >>> architecture. > >>> > >>> The DTNWG believes that protocols adhering to these principles = offer > >>> opportunities for enhancing the functionality of the Internet, > >>> including > >>> > >>> - facilitating the extension of the Internet into environment= s such as > >>> the ocean floor and deep space in which the core Internet p= rotocols > >>> operate sub-optimally for the reasons discussed earlier; > >>> > >>> - extending the Internet into communications challenged terre= strial > >>> environments where it is not possible to provide continuous= , low > >>> delay Internet connections; and > >>> > >>> - supporting Internet applications that need DTN capabiliies. > >>> > >>> We believe that the extensive research, demonstration, and > >>> pilot operations performed to date using the DTNRG protocols > provides > >>> a firm basis for publishing Internet standards derived from tha= t work. > >>> > >>> Work items related to Delay/Disruption Tolerant Networking incl= ude: > >>> > >>> o A mechanism for the exchange of protocol data units, termed > >>> "bundles", that are designed to obviate conversational > communications > >>> by containing values for all potentially relevant configuration > >>> parameters. These protocol data units are typically larger than > >>> network-layer packets. We will derive this bundle exchange > mechanism > >>> from the DTN Bundle Protocol (BP) documented in RFC 5050 by > publishing > >>> a new document for which [2] is a proposed first draft (where > >>> appendix A provides a summary of the proposed changes). > >>> > >>> o A security protocol for ensuring that the network in which bu= ndles > >>> are exchanged is secured against unauthorized access and denial = of > >>> service attacks, and to ensure data integrity and confidentialit= y > >>> in that network where necessary. We will derive this security > >>> protocol from a "streamlined" adaptation of the DTN Bundle > Security > >>> Protocol documented in RFC 6257. > >>> > >>> o A delay-tolerant security key management scheme that can pro= tect > >>> the integrity of a DTN network. > >>> > >>> o A simple datagram convergence layer protocol for adaptation o= f the > >>> bundle protocol to underlying internetworks. We expect to der= ive > >>> this convergence layer protocol from the Datagram Convergence > >>> protocol documented in RFC 7122. > >>> > >>> o A protocol for remote status monitoring, configuration, and > >>> administration of network nodes in the presence of long delay= s > >>> and/or intermittent connectivity. > >>> > >>> o A functional specification of Contact Graph Routing (CGR) spe= cifying > >>> the inputs (global contact schedules, traffic demands, etc.) = and > >>> outputs (node specific transmission and reception schedules, > >>> notifications, etc.). CGR is a centralized, oracle-based bun= dle > >>> transmission and reception scheduling scheme used in space > segment > >>> DTN deployments. > >>> > >>> o An adjunct to the management protocol that will allow the con= tact > >>> schedules generated by CGR to be distributed to nodes. This = may be > >>> based on the Contact Plan Update Protocol (CPUP) proposed in > >>> > >>> o An encapsulation protocol for "tunneling" BP traffic within b= undles > >>> that are secured and/or routed in different way from the > encapsulated > >>> bundles. > >>> > >>> o A registry for DTN Service Identifiers > >>> > >>> The working group will consider extending the current milestones > based on > >>> new information and knowledge gained while working on the initial > charter, > >>> as well as to accommodate new work items beyond the scope of the > initial > >>> phase. For example, we expect that transport protocols such as L= TP > and > >>> the Saratoga protocol are among the candidates for work in this p= hase. > >>> > >>> Goals and Milestones: > >>> start+0mos - Accept 'Bundle Protocol Specification (RFC5050bis)' [2= ] as > >>> a working group work item intended for Proposed Standa= rd. > >>> Start+0mos - Accept 'Streamlined Bundle Security Protocol (SBSP)' [= 3] as > >>> a working group work item intended for Proposed Standa= rd. > >>> start+3mos - Accept 'Bundle In Bundle Encapsulation (BIBE)' [4] as = a > >>> working work item intended for Proposed Standard. > >>> start+6mos - Working group getting concensus on changes to be > implemented > >>> in RFC 5050(bis). > >>> start+9mos - Working group getting consensus on merging RFC5050bis, > SBSP, > >>> BIBE etc. into a combined draft or keep as separate dr= afts. > >>> start+12mos - Accept 'CGR Functional Specification' as a working gr= oup > >>> working group work item intended for Informational. > >>> start+12mos - Accept 'Delay Tolerant Networking Security Key > Management' > >>> as a working group work item intended for Proposed St= andard. > >>> start+15mos - Accept 'Contact Plan Update Protocol' as working grou= p > work > >>> item intended for Proposed Standard. > >>> start+18mos - Submit RFC5050bis, SBSP, BIBE and Key Mgmt to the IES= G > either > >>> as a combined draft or as separate drafts. > >>> start+18mos - Submit Network Management [5], Registry [6] and > Simple > >>> Convergence Layer [7] as working group documents. > >>> start+20mos - Survey appropriate forums (e.g., DTNRG) for emerging > >>> technologies (e.g., convergence layer protocols, dyna= mic > >>> routing protocols, naming and addressing services, et= c.) > >>> ready for transition into IETF DTN Working Group. Pub= lish > >>> draft on survey results as independent submission rel= ated > >>> to the WG. > >>> start+24mos - Submit Network Management, Registry and Simple > Convergence > >>> Layer to IESG > >>> start+24mos - Recharter to accommodate new work items or close > >>> Working Group > >>> > >>> > >>> [1] "BP/LTP deployment on EPOXI spacecraft" [2008], > >>> http://committees.comsoc.org/tccc/ccw/2010/slides/DINET_CCW.pdf > >>> [2] "Proposed Revised Bundle Protocol" [2014], > >>> https://datatracker.ietf.org/doc/draft-burleigh-bpv7/ > >>> [3] "Streamlined Bundle Security Protocol Specification" [2014], > >>> https://datatracker.ietf.org/doc/draft-irtf-dtnrg-sbsp/ > >>> [4] "Bundle-in-Bundle Encapsulation" [2013], > >>> http://tools.ietf.org/id/draft-irtf-burleigh-bibe > >>> [5] "Delay Tolerant Network Management Protocol" [2013], > >>> http://tools.ietf.org/id/draft-irtf-dtnrg-dtnmp > >>> [6] "Delay-Tolerant Networking Bundle Protocol IANA Registries" [2011= ], > >>> https://datatracker.ietf.org/doc/rfc6255/ > >>> [7] "Datagram Convergence Layers ..." [2014], > >>> https://datatracker.ietf.org/doc/rfc7122/ > >>> [8] "Towards Flexibility and Accuracy in Space DTN Communications", > >>> Bezirgianndia et al, CHANTS 2012, > >>> http://dl.acm.org/citation.cfm?id=3D2505499 [2012] > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 From nobody Tue Jun 17 14:29:22 2014 Return-Path: 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 F121F1A017D for ; Tue, 17 Jun 2014 14:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 3vrstaVupNdv for ; Tue, 17 Jun 2014 14:29:19 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 021D51A017C for ; Tue, 17 Jun 2014 14:29:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 647B6BF05; Tue, 17 Jun 2014 22:29:18 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rk-7JIE6uTzv; Tue, 17 Jun 2014 22:29:17 +0100 (IST) Received: from [10.87.48.12] (unknown [86.46.21.97]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4C0BDBEDA; Tue, 17 Jun 2014 22:29:17 +0100 (IST) Message-ID: <53A0B32C.9050408@cs.tcd.ie> Date: Tue, 17 Jun 2014 22:29:16 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Templin, Fred L" , "dtn@ietf.org" References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> <2134F8430051B64F815C691A62D983183048B3B6@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983183048DB80@XCH-BLV-512.nw.nos.boeing.com> <53A09F61.2030900@cs.tcd.ie> <2134F8430051B64F815C691A62D983183048DD9A@XCH-BLV-512.nw.nos.boeing.com> <53A0A5B8.1090802@cs.tcd.ie> <2134F8430051B64F815C691A62D983183048DEE6@XCH-BLV-512.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983183048DEE6@XCH-BLV-512.nw.nos.boeing.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/bUJFf9GWBk_WP0bX8Ec06RnfbOs Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 21:29:22 -0000 Hiya, On 17/06/14 22:12, Templin, Fred L wrote: > I am not permitted to discuss my company's business plans on > a public forum (i.e., "can't tell - sorry"). Thanks for the clear answer. I figured it might be that. And there's nothing weird with a business taking that approach, or with having it imposed on them by some customers. However, it does mean that there's essentially no new information for the IESG in answer to the "why this, and why now" question, except for the assertion that you'd like it to happen. As I say, sometimes we might have to live with that, but it doesn't make things easier to understand. For example, if we take the issue I raised where I believe I'm probably in the rough, the list/BoF/IETF can't use your use-case to figure out if a "minimal" 5050bis or a re-design is more reasonable. (I don't want to re-do that discussion on the list now, its just an example.) You of course can do that and tell us all what you've concluded but others on the list cannot, which is a pity since presumably your use-case is one that motivates a large industrial player into spending effort on this, so may well be more compelling that e.g. TCD running about after reindeer herders. But it is what it is I guess. Cheers, S. From nobody Tue Jun 17 14:43:02 2014 Return-Path: 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 2CE3B1A017F for ; Tue, 17 Jun 2014 14:42:59 -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 VCqXfMNHj1zs for ; Tue, 17 Jun 2014 14:42:57 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96DF41A017C for ; Tue, 17 Jun 2014 14:42:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s5HLgvp9022348; Tue, 17 Jun 2014 14:42:57 -0700 Received: from XCH-PHX-105.sw.nos.boeing.com (xch-phx-105.sw.nos.boeing.com [137.136.238.8]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s5HLgtPQ022317 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 17 Jun 2014 14:42:55 -0700 Received: from XCH-BLV-509.nw.nos.boeing.com (137.136.239.139) by XCH-PHX-105.sw.nos.boeing.com (137.136.238.8) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 17 Jun 2014 14:42:55 -0700 Received: from XCH-BLV-512.nw.nos.boeing.com ([169.254.12.74]) by XCH-BLV-509.nw.nos.boeing.com ([169.254.9.91]) with mapi id 14.03.0181.006; Tue, 17 Jun 2014 14:42:55 -0700 From: "Templin, Fred L" To: Stephen Farrell , "dtn@ietf.org" Thread-Topic: [dtn] Draft Charter Discussion Thread-Index: Ac+GbO3wN7xIp4CqSFeVEjvJc65+vAAPLd8AAAy+SjAAJnyrgAC3CG0QABPXfIAADpF2cP//kwMAgABwdMD//5+VAIAAdIPQ Date: Tue, 17 Jun 2014 21:42:54 +0000 Message-ID: <2134F8430051B64F815C691A62D983183048DFC5@XCH-BLV-512.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> <2134F8430051B64F815C691A62D983183048B3B6@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983183048DB80@XCH-BLV-512.nw.nos.boeing.com> <53A09F61.2030900@cs.tcd.ie> <2134F8430051B64F815C691A62D983183048DD9A@XCH-BLV-512.nw.nos.boeing.com> <53A0A5B8.1090802@cs.tcd.ie> <2134F8430051B64F815C691A62D983183048DEE6@XCH-BLV-512.nw.nos.boeing.com> <53A0B32C.9050408@cs.tcd.ie> In-Reply-To: <53A0B32C.9050408@cs.tcd.ie> 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/YKFKVRFNitYvCeBCQkJ-2cm-Qxo Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 21:42:59 -0000 Hi Stephen, > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Tuesday, June 17, 2014 2:29 PM > To: Templin, Fred L; dtn@ietf.org > Subject: Re: [dtn] Draft Charter Discussion >=20 >=20 > Hiya, >=20 > On 17/06/14 22:12, Templin, Fred L wrote: > > I am not permitted to discuss my company's business plans on > > a public forum (i.e., "can't tell - sorry"). >=20 > Thanks for the clear answer. >=20 > I figured it might be that. And there's nothing weird with > a business taking that approach, or with having it imposed > on them by some customers. OK, but please understand that questions about my company's business interests will always cause me to clam up rather than open up since business interests are competition-sensitive. But, I can say that I am here during working hours exerting energy in these discussions because my company finds it in their interest for me to do so. Thanks - Fred fred.l.templin@boeing.com=20 > However, it does mean that there's essentially no new > information for the IESG in answer to the "why this, and > why now" question, except for the assertion that you'd > like it to happen. As I say, sometimes we might have to > live with that, but it doesn't make things easier to > understand. >=20 > For example, if we take the issue I raised where I believe > I'm probably in the rough, the list/BoF/IETF can't use your > use-case to figure out if a "minimal" 5050bis or a re-design > is more reasonable. (I don't want to re-do that discussion > on the list now, its just an example.) You of course can > do that and tell us all what you've concluded but others > on the list cannot, which is a pity since presumably your > use-case is one that motivates a large industrial player > into spending effort on this, so may well be more compelling > that e.g. TCD running about after reindeer herders. >=20 > But it is what it is I guess. >=20 > Cheers, > S. From nobody Tue Jun 17 14:56:13 2014 Return-Path: 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 892F81A0188 for ; Tue, 17 Jun 2014 14:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.151 X-Spam-Level: X-Spam-Status: No, score=-1.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, 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 zNENyTRQ51ye for ; Tue, 17 Jun 2014 14:56:09 -0700 (PDT) Received: from mlbxsmtpout02.harris.com (mlbxsmtpout02.harris.com [192.52.234.93]) by ietfa.amsl.com (Postfix) with ESMTP id BECE11A017C for ; Tue, 17 Jun 2014 14:56:08 -0700 (PDT) X-AuditID: c034ea5c-f797f6d0000048f8-8a-53a0b97776da Received: from MLBMXCAHT20.cs.myharris.net (Unknown_Domain [10.64.224.22]) by mlbxsmtpout02.harris.com (mail) with SMTP id 2F.19.18680.779B0A35; Tue, 17 Jun 2014 17:56:07 -0400 (EDT) Received: from MLBMXUS21.cs.myharris.net ([169.254.2.109]) by MLBMXCAHT20.cs.myharris.net ([fe80::650f:939a:a673:2320%21]) with mapi id 14.02.0318.001; Tue, 17 Jun 2014 17:56:07 -0400 From: "Klish, Cypryan" To: "dtn@ietf.org" Thread-Topic: Draft Charter Discussion Thread-Index: Ac+KdvALGRqD+DcFSSyr6f5ak4ImyA== Date: Tue, 17 Jun 2014 21:56:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.224.66] Content-Type: multipart/alternative; boundary="_000_FCED75DD0F47C64BBF9E8A564417BC8A8367CA75MLBMXUS21csmyha_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsXC5fBATLd854Jgg86NRhbta1gcGD2WLPnJ FMAYxWWTkpqTWZZapG+XwJVxeOVPxoKZFhXv7lg0MJ4y6GLk5JAQMJH40d/ICmGLSVy4t56t i5GLQ0hgB6PEu8+PWCGc3YwSX6f/Zu9i5OBgE9CSaNrPB9IgIqAo8XXOPrBmYSD79Kd2Noi4 msSyFf+ZQMpFBPQkdrXIgIRZBFQlFjd0gk3hFQiQaFrjCxJmBFr7/dQaJhCbWUBc4taT+UwQ 5whILNlznhnCFpV4+fgfK0irhICCxKMVuRDl+RIzvjaDlfAKCEqcnPmEZQKj0Cwkk2YhKZuF pAwiriOxYPcnNghbW2LZwtfMMPaZA4+ZkMUXMLKvYhTNzUmqKM4tKTAw0stILCrKLNZLzs/d xAiMhAMmr2J2MK58ZX+IUYCDUYmHNyF/QbAQa2JZcWXuIUYJDmYlEd5zWUAh3pTEyqrUovz4 otKc1OJDjNIcLErivNWLgVIC6YklqdmpqQWpRTBZJg5OqQbGFSePtEtah/498nPb6uU/DzY9 O3k008jodGNbwoT4p0/ExSPmqempfzj4IlL1y6kcTt0Veo1+/l33F31dJ/Z+2bmG/XfiQ0M3 MakwzvhjuOHhj8ML9deUzJlwd5FKql/j2fzYG8XNHBVvL56YfMDjrcS/XWrSJ522aW3nr5p0 MkzR1JszKKR6iRJLcUaioRZzUXEiAJobkUGAAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/RYxl3o0JHzfzO6G65-NxPq10fms Subject: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 21:56:11 -0000 --_000_FCED75DD0F47C64BBF9E8A564417BC8A8367CA75MLBMXUS21csmyha_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As a long time lurker and foremost an implementer and developer of products= suggest a DTN WG charter should address the need to refine and further sta= ndardize the fine research done by the DTNRG so that it can be implemented = by practitioners/organizations with a reasonable expectation that it will b= e interoperable, secure, and perform within a range of boundaries and const= raints defined in the standards. What does this entail? Suggest some of the following would be relevant : * Generate/refine a reference architecture that is more up to date, c= omprehensive and complete than RFC4838; a model-based RA would be icing on = the cake * Better identify known constraints and limitations * Better define management aspects (e.g. MIBs or YANG models) * Provide multiple security model options - perhaps like SNMP's USM = and VACM * Consider layering aspects, particularly layer boundaries, enabling = independent/portable use of some features (e.g. bundling as a service?) * Consider defining profiles/modes/classes of operation/RA subsets tr= aceable to the use cases Hope this helps Kip Cypryan (Kip) T. Klish II Senior Scientist Government Communications Systems HARRIS AssuredCommunications* Post Office Box 37 Melbourne, FL 32902-0037 * 1 321 727 6348 * 1 321 298 0492 (mobile) *Note new mobile number* * cklish@harris.com Confidentiality Notice: This Email and any attachments may contain material= that is "HARRIS Proprietary Information," Confidential, Privileged, and/or= Attorney Work Product for the Sole Use of the Intended Recipient. Any Revi= ew, Reliance, Distribution, Disclosure, or Forwarding Without Expressed Per= mission is Strictly Prohibited. If you are not the Intended Recipient, Plea= se Contact the Sender and Delete All Copies Without Reading, Printing, or S= aving in any Manner. -- Thank You. --_000_FCED75DD0F47C64BBF9E8A564417BC8A8367CA75MLBMXUS21csmyha_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
As a long time lurker and foremost an implementer and developer of pro= ducts suggest a DTN WG charter should address the need to refine and furthe= r standardize the fine research done by the DTNRG so that it can be impleme= nted by practitioners/organizations with a reasonable expectation that it will be interoperable, secure, and pe= rform within a range of boundaries and constraints defined in the standards= .   
 
What does this entail? Suggest some of the following would be relevant= :
  • Generate/refine a reference architecture that is more up to date, compr= ehensive and complete than RFC4838; a model-based RA would be icing on the = cake
  • Better identify known constraints and limitations
  • Bett= er define management aspects (e.g. MIBs or YANG models)
  • Provide mul= tiple security model options  – perhaps like SNMP’s USM an= d VACM
  • Consider layering aspects, particularly layer boundaries, en= abling independent/portable use of some features (e.g. bundling as a servic= e?)
  • Consider defining profiles/modes/classes of operation/RA subset= s traceable to the use cases
 
Hope this helps
 
Kip
Cypryan (Kip) T= . Klish II
Senior Scientist
Government Communications Systems
HARRIS
AssuredCommunicationsÔ
Post Office Box 37
Melbourne, FL 32902-0037
( 1 321 727 6348
È 1 321 298 0492 (mobile) *Note new mobile number*
* <= /span>cklish@harris.com <= /div>
Conf= identiality Notice: This Email and any attachments may contain material tha= t is "HARRIS Proprietary Information," Confidential, Privileged, = and/or Attorney Work Product for the Sole Use of the Intended Recipient. Any Review, Reliance, Distribution, Disclosure, or = Forwarding Without Expressed Permission is Strictly Prohibited. If you are = not the Intended Recipient, Please Contact the Sender and Delete All Copies= Without Reading, Printing, or Saving in any Manner. -- Thank You.
 
 
 
 --_000_FCED75DD0F47C64BBF9E8A564417BC8A8367CA75MLBMXUS21csmyha_-- From nobody Tue Jun 17 14:58:21 2014 Return-Path: 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 752A71A019D for ; Tue, 17 Jun 2014 14:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 D4QKiGfUoCwy for ; Tue, 17 Jun 2014 14:58:14 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id B70E41A017C for ; Tue, 17 Jun 2014 14:58:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DB180BE79; Tue, 17 Jun 2014 22:58:12 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvZK0tmQXIRN; Tue, 17 Jun 2014 22:58:10 +0100 (IST) Received: from [10.87.48.12] (unknown [86.46.21.97]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 964CBBEE1; Tue, 17 Jun 2014 22:58:09 +0100 (IST) Message-ID: <53A0B9F1.30609@cs.tcd.ie> Date: Tue, 17 Jun 2014 22:58:09 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Birrane, Edward J." , "Templin, Fred L" , "dtn@ietf.org" References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> <2134F8430051B64F815C691A62D983183048B3B6@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983183048DB80@XCH-BLV-512.nw.nos.boeing.com> <53A09F61.2030900@cs.tcd.ie> <2134F8430051B64F815C691A62D983183048DD9A@XCH-BLV-512.nw.nos.boeing.com> <53A0A5B8.1090802@cs.tcd.ie> <329D879C76FDD04AAAE84BB1D89B397009572F23C8@aplesfreedom.dom1.jhuapl.edu> In-Reply-To: <329D879C76FDD04AAAE84BB1D89B397009572F23C8@aplesfreedom.dom1.jhuapl.edu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/kekvNOijOg4UKU4jvHDSOgUZr10 Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 21:58:19 -0000 Hi Ed, On 17/06/14 22:24, Birrane, Edward J. wrote: > Stephen, > > I certainly can't answer those questions for Boeing or for Fred, but I have my own answer that I'm willing to share. Having never been an acorn, I am not certain if I am thinking like one, but here goes. > > For years, there have been sample deployments and experiments that show the feasibility and functionality of DTN, specifically BP. There have also been a smaller set of experiments that identified limitations with BP. From speaking with government, university, and small businesses my accumulated opinions are as follows. > > So, why DTN in non-space cases? > > - Some like the protocol bits (blocks, custody xfer, queuing, reporting structure) as a consolidated standard and not a layered set of standards and best practices. > - Some like the automation for delay/disrupted and scaled deployments - it cuts down on their one-off app point solutions. > - Some feel that their analyses indicate DTN overlays can simplify complex architectures such as TCP PEPs, including how to integrate differing networks using different queuing models. > - Some sensor networks behave quite similarly to space networks regarding disruption. Underwater scenarios also look similar in terms of delay. > > Not an exhaustive list, but the highlights from why people are interested in a standard that pulls these bits together. > > Separately, the line between space providers and space users is blurring. LEO constellations that want to interact seamlessly with terrestrial infrastructure as first-class nodes in a network should not be lumped as "space" in the sense of deep space missions or older, sparser near-earth deployments. > > > So, why no scaled DTN deployments yet outside of NASA baselines? > > - The security mechanism looked overly complex and hard to verify. > - There was no progress on management, especially in access-denied and open-loop areas. > - The protocol specs are described in experimental RFCs, with discussion of a bis. The above is all well and good, but is mostly the kind of argument we've made over the years in the DTNRG. Not that its wrong or bad, but its not new. (You're very positive though, so not complete:-) > > So, why now? > > - There has been progress on simplifying the security implementations based on lessons learned. > - There is some promising progress (yes, through NASA, but not NASA centric) on disruption-scaling management concepts. > - There is a set of lessons learned informing 5050bis/BPv7. To Fred's schedule, this can be resolved in relatively short order. Sure. But nothing in the above provides a strong argument for a WG that I can see. > I know of a few companies and some non-commercial entities that have no issue with BP and are not worried about building a BPA. But an operational deployment needs a non-experimental spec, security, and management. There is much more it needs in the general case, but these seem to be driving requirements. That would be more interesting. > I am unsure of what is sufficient proof for your question. Does it have to be 10 companies interested and not 8? 25 nodes instead of 18? 100? Is the deployment horizon 1 year and not 3? Proof is the wrong word. From my POV the only new thing I've seen here so far is Fred saying Boeing would like this to happen (but not quite why). That they want it is a good thing. More folks and more detail would be better of course as that would give more confidence we're solving the right problem and our solution might get widely deployed. There are no hard and fast numbers but I don't believe we've seen new participants turning up saying that they want this and why. (I.e. not a bare "+1" mail, but something real.) We have seen known DTNRG participants saying that which is also good, but also not really new. And don't get me wrong, even though I would write a quite different charter, I'm still supportive of this one if we end up with it. But folks will be asking these questions. > So, I naively ask the opposite question: why not standardize this work in the IETF? The generic arguments are about costs and capacity and keeping to the knitting. Everything has a cost, and a WG imposes costs on others (e.g. the IESG, directorates, meetings etc.) not only on the direct participants. In this case, one might add a lack of clarity as to "why this, now" to the generic list. Then there's Lloyd's objections, with which I mostly do not agree. But I think he and I do have some common concerns as to whether this 5050bis is the right target, vs. e.g. exploring a more web like approach. There is after all only so much participant effort available and one WG of any sort will consume all of that. As I've said, I suspect I'm in the rough on that. > > You have the community of people who are willing to do the work, with backing from industry and government. So did OSI:-) > The charter, as I see it, addresses clear needs for operational deployment, and to Will's points, the DTNRG persists to continue inspection of the fundamental research issues surrounding more exotic deployments. Actually I don't buy that last. If the WG gets going it is my belief that the RG will (or should) go dormant, but that's for discussion elsewhere/when. S. > -Ed > > --- > Ed Birrane > Principal Professional Staff, Space Department > Johns Hopkins Applied Physics Laboratory > (W) 443-778-7423 / (F) 443-228-3839 > > > >> -----Original Message----- >> From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of Stephen Farrell >> Sent: Tuesday, June 17, 2014 4:32 PM >> To: Templin, Fred L; dtn@ietf.org >> Subject: Re: [dtn] Draft Charter Discussion >> >> >> Hi Fred, >> >> On 17/06/14 21:12, Templin, Fred L wrote: >>> Hi Stephen, >>> >>>> -----Original Message----- >>>> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >>>> Sent: Tuesday, June 17, 2014 1:05 PM >>>> To: Templin, Fred L; dtn@ietf.org >>>> Subject: Re: [dtn] Draft Charter Discussion >>>> >>>> >>>> Fred and others, >>>> >>>> I think I've asked this before so apologies if I just forget the good >>>> answer;-) >>>> >>>> We have the space use-case and some fairly well known niche >>>> terrestrial use-cases, which are fine. But we've known these for >>>> years and the DTNRG didn't want to move to the standards track until >>>> now. >>> >>> Yes, a diverse set of use cases and not a single use case. That means >>> that in the early days there may be many purpose-built DTNs that may >>> at a later time be joined together to form larger DTNs. >>> A "DTN-of-DTNs" in the same way that the Internet is a "network- >>> of-networks". >>> >>> The whole reason the Internet was able to join together smaller >>> networks to form larger networks is that the Internet had >>> interoperable standards from the very beginning. It is now time for us >>> to do that for DTN. >> >> I'm familiar with DTN. But I find the above a pretty complete non-answer to >> the question asked (in that it answers no part of my question:-) So I'll try >> again, in a more direct fashion... >> >> I do not know why specifically Boeing want a standards track RFC5050bis, nor >> why you want it now. >> >> And I'm wondering and would like to know. I have not heard your use-case >> (or business case, whatever) explained so far. >> Nor have I heard someone say "can't/won't tell, sorry." >> So I'm curious. >> >> And I'll note once again that successful BoFs tend to involve explaining why >> this, now, specifically. As an IESG member it makes it much easier for me to >> evaluate proposals for forming a WG. >> >> (BTW, any answer that asks me to think like an acorn won't really work for >> this question, sorry:-) >> >> If someone else has a new answer to this question that would also be >> interesting. By new, I mean a use-case or business-case that hasn't >> previously been discussed in the DTNRG. >> >> Cheers, >> S. >> >> PS: In case there's confusion. My question is very much not the same as >> Will's, despite your answer being very similar. >> >>> >>> Thanks - Fred >>> fred.l.templin@boeing.com >>> >>>> I think it'd help the IESG to decide whether to approve a WG if there >>>> were more information available about what has changed to motivate >>>> moving to the standards track. >>>> >>>> If (say for Boeing) those are such that you can't say and there >>>> aren't any others who can, then that's a pity, since it does make it >>>> harder to get why a 5050bis on the standards track is attractive. >>>> >>>> I'm just noting this again because I think many recent successful >>>> BoFs have tended to have this topic as part of the agenda, but it >>>> seems missing in yours, which just assumes that the room knows that >>>> RFC5050 needs a bit of work. (I'm exaggerating a bit there, but I >>>> hope you get what I mean.) >>>> >>>> S. >>>> >>>> On 17/06/14 18:40, Templin, Fred L wrote: >>>>> Please see below for an updated version of the draft charter based >>>>> on list discussions, and post any further comments in follow-up. >>>>> (See also attached for diffs relative to the previous version.) >>>>> >>>>> Thanks - Fred >>>>> fred.l.templin@boeing.com >>>>> >>>>> --- >>>>> >>>>> Draft BoF Agenda (2.5hrs): >>>>> ************************** >>>>> 1) Problem statement (IETF wg motivation) - 30min >>>>> >>>>> 2) RFC5050(bis) - 15min >>>>> >>>>> 3) Streamlined Bundle Security Protocol (SBSP) - 15min >>>>> >>>>> 4) Security Key Management - 10min >>>>> >>>>> 5) Network Management - 10min >>>>> >>>>> 6) Contact Graph Routing and Contact Plan Update Protocol - 10min >>>>> >>>>> 7) Bundle-in-Bundle Encapsulation - 5min >>>>> >>>>> 8) Registry for Service Identifiers - 5min >>>>> >>>>> 9) Open Discussion - 50min >>>>> >>>>> >>>>> Draft working group charter: >>>>> **************************** >>>>> Working group name: >>>>> >>>>> Delay/Disruption Tolerant Networking Working Group (DTNWG) >>>>> >>>>> Chair(s): >>>>> >>>>> TBD >>>>> >>>>> Area and Area Director(s): >>>>> >>>>> Transport Area: ADs Spencer Dawkins > gmail.com>, >>>>> Martin Stiemerling >>>>> >>>>> Responsible Area Director: >>>>> >>>>> TBD >>>>> >>>>> Mailing list: >>>>> >>>>> General Discussion: dtn at ietf.org >>>>> To Subscribe: https://www.ietf.org/mailman/listinfo/dtn >>>>> Archive: >>>>> http://www.ietf.org/mail-archive/web/dtn/current/maillist.html >>>>> >>>>> Description of Working Group: >>>>> >>>>> The Delay/Disruption Tolerant Network Working Group (DTNWG) >> specifies >>>>> mechanisms for data communications in the presence of long delays >>>>> and/or intermittent connectivity. The work is motivated by well >> known >>>>> limitations of standard Internet protocols that expect end-to-end >>>>> connectivity between communicating endpoints, sub-second >> transmission >>>>> delays and robust packet delivery ratios. In environments where >> these >>>>> favorable conditions do not apply, existing mechanisms encounter >> problems >>>>> such as reliable transport protocol handshakes timing out and routing >>>>> protocols failing to converge resulting in communication failures. >>>>> Furthermore, classical end-to-end security associations cannot be >>>>> coordinated when communicating endpoints cannot conduct multi- >> message >>>>> keying exchanges in a timely fashion. These limitations suggested the >>>>> need for a new approach. >>>>> >>>>> Delay-Tolerant Networking (DTN) protocols have been the subject of >>>>> extensive research and development in the Delay-Tolerant >> Networking >>>>> Research Group (DTNRG) of the Internet Research Task Force since >> 2002. >>>>> The DTNRG has developed the Delay-Tolerant Networking >> Architecture >>>>> (RFC 4838) that the DTNWG uses as the basis for its work. The key >>>>> components of the this architecture are the bundle concept for >>>>> encapsulating data units, the bundle transmission protocol and the >>>>> underlying convergence layer architecture. >>>>> >>>>> The experimental DTN Bundle Protocol (RFC 5050) and Licklider >>>>> Transmission Protocol (RFC 5326) have been shown to address the >>>>> issues identified above in substantial fielded deployments in the >> space >>>>> sector [1]. RFC 5050 in conjunction with TCP- and UDP-based >> convergence >>>>> layers has been used successfully in a number of experiments both in >>>>> communications challenged environments around the edges of the >> Internet >>>>> and as an Internet overlay where applications require delay- and/or >>>>> disruption-tolerance [refs needed]. >>>>> >>>>> The success of the BP over convergence layer protocol stack -- the >> core >>>>> protocols of the "DTN Architecture" described in RFC 4838 -- may be >>>>> attributed to the following fundamental design principles: >>>>> >>>>> - There is never any expectation of contemporaneous end-to-end >>>>> connectivity between any two network nodes. >>>>> >>>>> - Because end-to-end connectivity can never be assumed, each node >>>>> on the path between source and destination must be prepared to >>>>> handle incoming "bundles" of data that cannot immediately be >>>>> forwarded. >>>>> >>>>> - Again because end-to-end connectivity can never be assumed, >>>>> end-to-end conversational data exchange can never be assumed to >>>>> complete in a timely manner; protocol features that rely on >>>>> timely conversational data exchange must be excluded from the >>>>> architecture. >>>>> >>>>> The DTNWG believes that protocols adhering to these principles offer >>>>> opportunities for enhancing the functionality of the Internet, >>>>> including >>>>> >>>>> - facilitating the extension of the Internet into environments such as >>>>> the ocean floor and deep space in which the core Internet protocols >>>>> operate sub-optimally for the reasons discussed earlier; >>>>> >>>>> - extending the Internet into communications challenged terrestrial >>>>> environments where it is not possible to provide continuous, low >>>>> delay Internet connections; and >>>>> >>>>> - supporting Internet applications that need DTN capabiliies. >>>>> >>>>> We believe that the extensive research, demonstration, and >>>>> pilot operations performed to date using the DTNRG protocols >> provides >>>>> a firm basis for publishing Internet standards derived from that work. >>>>> >>>>> Work items related to Delay/Disruption Tolerant Networking include: >>>>> >>>>> o A mechanism for the exchange of protocol data units, termed >>>>> "bundles", that are designed to obviate conversational >> communications >>>>> by containing values for all potentially relevant configuration >>>>> parameters. These protocol data units are typically larger than >>>>> network-layer packets. We will derive this bundle exchange >> mechanism >>>>> from the DTN Bundle Protocol (BP) documented in RFC 5050 by >> publishing >>>>> a new document for which [2] is a proposed first draft (where >>>>> appendix A provides a summary of the proposed changes). >>>>> >>>>> o A security protocol for ensuring that the network in which bundles >>>>> are exchanged is secured against unauthorized access and denial of >>>>> service attacks, and to ensure data integrity and confidentiality >>>>> in that network where necessary. We will derive this security >>>>> protocol from a "streamlined" adaptation of the DTN Bundle >> Security >>>>> Protocol documented in RFC 6257. >>>>> >>>>> o A delay-tolerant security key management scheme that can protect >>>>> the integrity of a DTN network. >>>>> >>>>> o A simple datagram convergence layer protocol for adaptation of the >>>>> bundle protocol to underlying internetworks. We expect to derive >>>>> this convergence layer protocol from the Datagram Convergence >>>>> protocol documented in RFC 7122. >>>>> >>>>> o A protocol for remote status monitoring, configuration, and >>>>> administration of network nodes in the presence of long delays >>>>> and/or intermittent connectivity. >>>>> >>>>> o A functional specification of Contact Graph Routing (CGR) specifying >>>>> the inputs (global contact schedules, traffic demands, etc.) and >>>>> outputs (node specific transmission and reception schedules, >>>>> notifications, etc.). CGR is a centralized, oracle-based bundle >>>>> transmission and reception scheduling scheme used in space >> segment >>>>> DTN deployments. >>>>> >>>>> o An adjunct to the management protocol that will allow the contact >>>>> schedules generated by CGR to be distributed to nodes. This may be >>>>> based on the Contact Plan Update Protocol (CPUP) proposed in >>>>> >>>>> o An encapsulation protocol for "tunneling" BP traffic within bundles >>>>> that are secured and/or routed in different way from the >> encapsulated >>>>> bundles. >>>>> >>>>> o A registry for DTN Service Identifiers >>>>> >>>>> The working group will consider extending the current milestones >> based on >>>>> new information and knowledge gained while working on the initial >> charter, >>>>> as well as to accommodate new work items beyond the scope of the >> initial >>>>> phase. For example, we expect that transport protocols such as LTP >> and >>>>> the Saratoga protocol are among the candidates for work in this phase. >>>>> >>>>> Goals and Milestones: >>>>> start+0mos - Accept 'Bundle Protocol Specification (RFC5050bis)' [2] as >>>>> a working group work item intended for Proposed Standard. >>>>> Start+0mos - Accept 'Streamlined Bundle Security Protocol (SBSP)' [3] as >>>>> a working group work item intended for Proposed Standard. >>>>> start+3mos - Accept 'Bundle In Bundle Encapsulation (BIBE)' [4] as a >>>>> working work item intended for Proposed Standard. >>>>> start+6mos - Working group getting concensus on changes to be >> implemented >>>>> in RFC 5050(bis). >>>>> start+9mos - Working group getting consensus on merging RFC5050bis, >> SBSP, >>>>> BIBE etc. into a combined draft or keep as separate drafts. >>>>> start+12mos - Accept 'CGR Functional Specification' as a working group >>>>> working group work item intended for Informational. >>>>> start+12mos - Accept 'Delay Tolerant Networking Security Key >> Management' >>>>> as a working group work item intended for Proposed Standard. >>>>> start+15mos - Accept 'Contact Plan Update Protocol' as working group >> work >>>>> item intended for Proposed Standard. >>>>> start+18mos - Submit RFC5050bis, SBSP, BIBE and Key Mgmt to the IESG >> either >>>>> as a combined draft or as separate drafts. >>>>> start+18mos - Submit Network Management [5], Registry [6] and >> Simple >>>>> Convergence Layer [7] as working group documents. >>>>> start+20mos - Survey appropriate forums (e.g., DTNRG) for emerging >>>>> technologies (e.g., convergence layer protocols, dynamic >>>>> routing protocols, naming and addressing services, etc.) >>>>> ready for transition into IETF DTN Working Group. Publish >>>>> draft on survey results as independent submission related >>>>> to the WG. >>>>> start+24mos - Submit Network Management, Registry and Simple >> Convergence >>>>> Layer to IESG >>>>> start+24mos - Recharter to accommodate new work items or close >>>>> Working Group >>>>> >>>>> >>>>> [1] "BP/LTP deployment on EPOXI spacecraft" [2008], >>>>> http://committees.comsoc.org/tccc/ccw/2010/slides/DINET_CCW.pdf >>>>> [2] "Proposed Revised Bundle Protocol" [2014], >>>>> https://datatracker.ietf.org/doc/draft-burleigh-bpv7/ >>>>> [3] "Streamlined Bundle Security Protocol Specification" [2014], >>>>> https://datatracker.ietf.org/doc/draft-irtf-dtnrg-sbsp/ >>>>> [4] "Bundle-in-Bundle Encapsulation" [2013], >>>>> http://tools.ietf.org/id/draft-irtf-burleigh-bibe >>>>> [5] "Delay Tolerant Network Management Protocol" [2013], >>>>> http://tools.ietf.org/id/draft-irtf-dtnrg-dtnmp >>>>> [6] "Delay-Tolerant Networking Bundle Protocol IANA Registries" [2011], >>>>> https://datatracker.ietf.org/doc/rfc6255/ >>>>> [7] "Datagram Convergence Layers ..." [2014], >>>>> https://datatracker.ietf.org/doc/rfc7122/ >>>>> [8] "Towards Flexibility and Accuracy in Space DTN Communications", >>>>> Bezirgianndia et al, CHANTS 2012, >>>>> http://dl.acm.org/citation.cfm?id=2505499 [2012] >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 > > _______________________________________________ > dtn mailing list > dtn@ietf.org > https://www.ietf.org/mailman/listinfo/dtn > > From nobody Tue Jun 17 15:04:26 2014 Return-Path: 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 F17451A01B1 for ; Tue, 17 Jun 2014 15:04:22 -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 y9x5maEFDP54 for ; Tue, 17 Jun 2014 15:04:20 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1EAB1A01AA for ; Tue, 17 Jun 2014 15:04:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s5HM4Js7010444; Tue, 17 Jun 2014 15:04:19 -0700 Received: from XCH-PHX-402.sw.nos.boeing.com (xch-phx-402.sw.nos.boeing.com [137.136.239.38]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s5HM4Bn6010256 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 17 Jun 2014 15:04:12 -0700 Received: from XCH-BLV-510.nw.nos.boeing.com (137.136.239.141) by XCH-PHX-402.sw.nos.boeing.com (137.136.239.38) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 17 Jun 2014 15:04:11 -0700 Received: from XCH-BLV-512.nw.nos.boeing.com ([169.254.12.74]) by XCH-BLV-510.nw.nos.boeing.com ([169.254.10.32]) with mapi id 14.03.0181.006; Tue, 17 Jun 2014 15:04:10 -0700 From: "Templin, Fred L" To: Stephen Farrell , "Birrane, Edward J." , "dtn@ietf.org" Thread-Topic: [dtn] Draft Charter Discussion Thread-Index: Ac+GbO3wN7xIp4CqSFeVEjvJc65+vAAPLd8AAAy+SjAAJnyrgAC3CG0QABPXfIAADpF2cP//NdB1///++qA= Date: Tue, 17 Jun 2014 22:04:09 +0000 Message-ID: <2134F8430051B64F815C691A62D983183048E063@XCH-BLV-512.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> <2134F8430051B64F815C691A62D983183048B3B6@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983183048DB80@XCH-BLV-512.nw.nos.boeing.com> <53A09F61.2030900@cs.tcd.ie> <2134F8430051B64F815C691A62D983183048DD9A@XCH-BLV-512.nw.nos.boeing.com> <53A0A5B8.1090802@cs.tcd.ie> <329D879C76FDD04AAAE84BB1D89B397009572F23C8@aplesfreedom.dom1.jhuapl.edu> <53A0B9F1.30609@cs.tcd.ie> In-Reply-To: <53A0B9F1.30609@cs.tcd.ie> 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/i6KghAgzKxjTtUi1rjiTrwpVNps Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 22:04:23 -0000 Hi Stephen, > > You have the community of people who are willing to do the work, with b= acking from industry and > government. >=20 > So did OSI:-) But remember that OSI did not come from the IETF. We would like to see something that comes from the IETF. Thanks - Fred fred.l.templin@boeing.com From nobody Tue Jun 17 15:04:56 2014 Return-Path: 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 583F81A01C1 for ; Tue, 17 Jun 2014 15:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 q1J-ZvUITyiE for ; Tue, 17 Jun 2014 15:04:47 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id F24DF1A01AA for ; Tue, 17 Jun 2014 15:04:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CF6FCBEE2; Tue, 17 Jun 2014 23:04:44 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdOMx8jwTWwC; Tue, 17 Jun 2014 23:04:43 +0100 (IST) Received: from [10.87.48.12] (unknown [86.46.21.97]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2CB16BEE1; Tue, 17 Jun 2014 23:04:43 +0100 (IST) Message-ID: <53A0BB7A.7060307@cs.tcd.ie> Date: Tue, 17 Jun 2014 23:04:42 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Klish, Cypryan" , "dtn@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/Xwc13Ogzwh8i4WJNYNZsBopO5qQ Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 22:04:49 -0000 Hi Cypryan, Good stuff. Can you say some more about what you'd be using such an set of BP specs for? I think you're the first to suggest re-opening RFC4838 btw. Not sure I see much benefit in that to be honest. And some risk that the valid argument that 4838 is a bit too BP specific might win the day and, from a charter/milestones POV, de-rail the WG. Ta, S. On 17/06/14 22:56, Klish, Cypryan wrote: > As a long time lurker and foremost an implementer and developer of products suggest a DTN WG charter should address the need to refine and further standardize the fine research done by the DTNRG so that it can be implemented by practitioners/organizations with a reasonable expectation that it will be interoperable, secure, and perform within a range of boundaries and constraints defined in the standards. > > What does this entail? Suggest some of the following would be relevant : > * Generate/refine a reference architecture that is more up to date, comprehensive and complete than RFC4838; a model-based RA would be icing on the cake > * Better identify known constraints and limitations > * Better define management aspects (e.g. MIBs or YANG models) > * Provide multiple security model options - perhaps like SNMP's USM and VACM > * Consider layering aspects, particularly layer boundaries, enabling independent/portable use of some features (e.g. bundling as a service?) > * Consider defining profiles/modes/classes of operation/RA subsets traceable to the use cases > > Hope this helps > > Kip > > Cypryan (Kip) T. Klish II > Senior Scientist > Government Communications Systems > HARRIS > AssuredCommunications* > Post Office Box 37 > Melbourne, FL 32902-0037 > * 1 321 727 6348 > * 1 321 298 0492 (mobile) *Note new mobile number* > * cklish@harris.com > Confidentiality Notice: This Email and any attachments may contain material that is "HARRIS Proprietary Information," Confidential, Privileged, and/or Attorney Work Product for the Sole Use of the Intended Recipient. Any Review, Reliance, Distribution, Disclosure, or Forwarding Without Expressed Permission is Strictly Prohibited. If you are not the Intended Recipient, Please Contact the Sender and Delete All Copies Without Reading, Printing, or Saving in any Manner. -- Thank You. > > > > > > > _______________________________________________ > dtn mailing list > dtn@ietf.org > https://www.ietf.org/mailman/listinfo/dtn > From nobody Tue Jun 17 15:06:10 2014 Return-Path: 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 6A4E41A01BA for ; Tue, 17 Jun 2014 15:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 wENHbOI2puZN for ; Tue, 17 Jun 2014 15:06:02 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id B39641A01AA for ; Tue, 17 Jun 2014 15:06:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 26DFEBEE2; Tue, 17 Jun 2014 23:06:02 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-lHfdrF02nb; Tue, 17 Jun 2014 23:06:00 +0100 (IST) Received: from [10.87.48.12] (unknown [86.46.21.97]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C9230BEE1; Tue, 17 Jun 2014 23:06:00 +0100 (IST) Message-ID: <53A0BBC8.1090305@cs.tcd.ie> Date: Tue, 17 Jun 2014 23:06:00 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Templin, Fred L" , "Birrane, Edward J." , "dtn@ietf.org" References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> <2134F8430051B64F815C691A62D983183048B3B6@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983183048DB80@XCH-BLV-512.nw.nos.boeing.com> <53A09F61.2030900@cs.tcd.ie> <2134F8430051B64F815C691A62D983183048DD9A@XCH-BLV-512.nw.nos.boeing.com> <53A0A5B8.1090802@cs.tcd.ie> <329D879C76FDD04AAAE84BB1D89B397009572F23C8@aplesfreedom.dom1.jhuapl.edu> <53A0B9F1.30609@cs.tcd.ie> <2134F8430051B64F815C691A62D983183048E063@XCH-BLV-512.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983183048E063@XCH-BLV-512.nw.nos.boeing.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/oQz6HdYgt1gV-C6OZ0GZateYk9I Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 22:06:07 -0000 On 17/06/14 23:04, Templin, Fred L wrote: > Hi Stephen, > >>> You have the community of people who are willing to do the work, with backing from industry and >> government. >> >> So did OSI:-) > > But remember that OSI did not come from the IETF. We would like > to see something that comes from the IETF. Fair enough. BEEP then:-) BTW, only kidding we don't need to descend further down this rathole. S. > > Thanks - Fred > fred.l.templin@boeing.com > > _______________________________________________ > dtn mailing list > dtn@ietf.org > https://www.ietf.org/mailman/listinfo/dtn > > From nobody Tue Jun 17 15:24:05 2014 Return-Path: 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 65BAE1A0188 for ; Tue, 17 Jun 2014 15:24:03 -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 h-nRHhK3imGD for ; Tue, 17 Jun 2014 15:24:00 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB8DC1A017F for ; Tue, 17 Jun 2014 15:24:00 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp01.jpl.nasa.gov [128.149.137.148]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s5HMNxOT032204 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO) for ; Tue, 17 Jun 2014 15:24:00 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.217]) by ap-ehub-sp01.RES.AD.JPL ([169.254.3.182]) with mapi id 14.03.0174.001; Tue, 17 Jun 2014 15:23:59 -0700 From: "Burleigh, Scott C (312G)" To: "dtn@ietf.org" Thread-Topic: [dtn] Draft Charter Discussion Thread-Index: Ac+GbO3wN7xIp4CqSFeVEjvJc65+vAAPLd8AAAy+SjAAJnyrgAC3CG0QABPXfIAADpF2cP//kwMAgABi+uA= Date: Tue, 17 Jun 2014 22:23:58 +0000 Message-ID: References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> <2134F8430051B64F815C691A62D983183048B3B6@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983183048DB80@XCH-BLV-512.nw.nos.boeing.com> <53A09F61.2030900@cs.tcd.ie> <2134F8430051B64F815C691A62D983183048DD9A@XCH-BLV-512.nw.nos.boeing.com> <53A0A5B8.1090802@cs.tcd.ie> In-Reply-To: <53A0A5B8.1090802@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.113] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/-FyDf1vskaryqFlKoHNlESSV50U Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 22:24:03 -0000 Okay, taking another crack at this. I think there are two levels of question here, one implying the other, and = it might be helpful to address them separately. First the proximate question: given that DTN exists, why standardize it? W= hy not just use it as it is? What has changed? I think the answer there, to which Fred and Ed have alluded, is that there = are business entities that would now like to use DTN to solve some communic= ation problems (or exploit some opportunities) but won't risk doing so whil= e the protocols are not standards. I know Ed works with such entities on a= regular basis, and the fact that Boeing is willing to invest some time and= money in this BoF seems to suggest that they at least are another such ent= ity. So then the underlying question: what are those problems and opportunities = for which a standardized DTN would be used? As Fred has pointed out, organizations that hope to make money from these i= deas are not likely to disclose them here or in the BoF. But, just from my= own reading of the news, let me suggest a couple of potential DTN use case= s that go beyond the ISS and Saami deployments we're all familiar with. 1. The UAV industry is exploding. Nobody has any idea where the limits on= applications of UAVs are, but what we do know is that the information that= controls them is conveyed by radio, which is occasionally subject to disru= ption. Technology that could improve the safety and reliability of UAVs, w= hile reducing cost, could find a large market. 2. The speed of sound underwater is 1.5 km/sec, so the round-trip time bet= ween two underwater entities communicating by acoustic modem and separated = by a distance of 7.5 km is about equal to the round-trip time between Earth= and the Earth/Sun L2 Lagrange point. Since the data rates of acoustic mod= ems are low, efficient delay-tolerant networking is a pretty good way to es= tablish underwater communication. The market for underwater sensors and in= strumentation is already in the billions of dollars; revenue in the autonom= ous underwater vehicle manufacturing industry is growing at nearly 14% per = year. 3. The "space" use case is arguably still small if you restrict it to the = vehicles that are in orbit. If you extend the space communication use case= to users on Earth who will need to communicate with spacecraft over the ne= xt two decades, as Earth orbit becomes increasingly industrialized, then yo= u find yourself talking about a very large user community. And I am pretty sure there are more that I'm not aware of. The basic propo= sition is that the Internet is an outstanding communications solution for a= ll parts of Earth's surface that are relatively easy to get to, but there a= re business opportunities that are beyond its current reach. DTN can help = extend that outstanding communications solution to currently Internet-inhos= pitable parts of the Earth and near-Earth, benefiting a lot of people. Sta= ndardizing it will help make that happen. As Vint remarked in one of our c= onversations on this topic (I paraphrase freely), the Internet didn't get c= reated because somebody thought of a killer app; people thought of killer a= pps because there was an Internet. Scott -----Original Message----- From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of Stephen Farrell Sent: Tuesday, June 17, 2014 1:32 PM To: Templin, Fred L; dtn@ietf.org Subject: Re: [dtn] Draft Charter Discussion Hi Fred, On 17/06/14 21:12, Templin, Fred L wrote: > Hi Stephen, >=20 >> -----Original Message----- >> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >> Sent: Tuesday, June 17, 2014 1:05 PM >> To: Templin, Fred L; dtn@ietf.org >> Subject: Re: [dtn] Draft Charter Discussion >> >> >> Fred and others, >> >> I think I've asked this before so apologies if I just forget the good=20 >> answer;-) >> >> We have the space use-case and some fairly well known niche=20 >> terrestrial use-cases, which are fine. But we've known these for=20 >> years and the DTNRG didn't want to move to the standards track until=20 >> now. >=20 > Yes, a diverse set of use cases and not a single use case. That means=20 > that in the early days there may be many purpose-built DTNs that may=20 > at a later time be joined together to form larger DTNs. > A "DTN-of-DTNs" in the same way that the Internet is a "network-=20 > of-networks". >=20 > The whole reason the Internet was able to join together smaller=20 > networks to form larger networks is that the Internet had=20 > interoperable standards from the very beginning. It is now time for us=20 > to do that for DTN. I'm familiar with DTN. But I find the above a pretty complete non-answer to= the question asked (in that it answers no part of my question:-) So I'll t= ry again, in a more direct fashion... I do not know why specifically Boeing want a standards track RFC5050bis, no= r why you want it now. And I'm wondering and would like to know. I have not heard your use-case (o= r business case, whatever) explained so far. Nor have I heard someone say "can't/won't tell, sorry." So I'm curious. And I'll note once again that successful BoFs tend to involve explaining wh= y this, now, specifically. As an IESG member it makes it much easier for me= to evaluate proposals for forming a WG. (BTW, any answer that asks me to think like an acorn won't really work for = this question, sorry:-) If someone else has a new answer to this question that would also be intere= sting. By new, I mean a use-case or business-case that hasn't previously be= en discussed in the DTNRG. Cheers, S. PS: In case there's confusion. My question is very much not the same as Wil= l's, despite your answer being very similar. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 >> I think it'd help the IESG to decide whether to approve a WG if there=20 >> were more information available about what has changed to motivate=20 >> moving to the standards track. >> >> If (say for Boeing) those are such that you can't say and there=20 >> aren't any others who can, then that's a pity, since it does make it=20 >> harder to get why a 5050bis on the standards track is attractive. >> >> I'm just noting this again because I think many recent successful=20 >> BoFs have tended to have this topic as part of the agenda, but it=20 >> seems missing in yours, which just assumes that the room knows that=20 >> RFC5050 needs a bit of work. (I'm exaggerating a bit there, but I=20 >> hope you get what I mean.) >> >> S. >> >> On 17/06/14 18:40, Templin, Fred L wrote: >>> Please see below for an updated version of the draft charter based=20 >>> on list discussions, and post any further comments in follow-up. >>> (See also attached for diffs relative to the previous version.) >>> >>> Thanks - Fred >>> fred.l.templin@boeing.com >>> >>> --- >>> >>> Draft BoF Agenda (2.5hrs): >>> ************************** >>> 1) Problem statement (IETF wg motivation) - 30min >>> >>> 2) RFC5050(bis) - 15min >>> >>> 3) Streamlined Bundle Security Protocol (SBSP) - 15min >>> >>> 4) Security Key Management - 10min >>> >>> 5) Network Management - 10min >>> >>> 6) Contact Graph Routing and Contact Plan Update Protocol - 10min >>> >>> 7) Bundle-in-Bundle Encapsulation - 5min >>> >>> 8) Registry for Service Identifiers - 5min >>> >>> 9) Open Discussion - 50min >>> >>> >>> Draft working group charter: >>> **************************** >>> Working group name: >>> >>> Delay/Disruption Tolerant Networking Working Group (DTNWG) >>> >>> Chair(s): >>> >>> TBD >>> >>> Area and Area Director(s): >>> >>> Transport Area: ADs Spencer Dawkins , >>> Martin Stiemerling >>> >>> Responsible Area Director: >>> >>> TBD >>> >>> Mailing list: >>> >>> General Discussion: dtn at ietf.org >>> To Subscribe: https://www.ietf.org/mailman/listinfo/dtn >>> Archive:=20 >>> http://www.ietf.org/mail-archive/web/dtn/current/maillist.html >>> >>> Description of Working Group: >>> >>> The Delay/Disruption Tolerant Network Working Group (DTNWG) speci= fies >>> mechanisms for data communications in the presence of long delays >>> and/or intermittent connectivity. The work is motivated by well k= nown >>> limitations of standard Internet protocols that expect end-to-end >>> connectivity between communicating endpoints, sub-second transmis= sion >>> delays and robust packet delivery ratios. In environments where t= hese >>> favorable conditions do not apply, existing mechanisms encounter = problems >>> such as reliable transport protocol handshakes timing out and rou= ting >>> protocols failing to converge resulting in communication failures= . >>> Furthermore, classical end-to-end security associations cannot be >>> coordinated when communicating endpoints cannot conduct multi-mes= sage >>> keying exchanges in a timely fashion. These limitations suggested= the >>> need for a new approach. >>> >>> Delay-Tolerant Networking (DTN) protocols have been the subject o= f >>> extensive research and development in the Delay-Tolerant Networki= ng >>> Research Group (DTNRG) of the Internet Research Task Force since = 2002. >>> The DTNRG has developed the Delay-Tolerant Networking Architectur= e >>> (RFC 4838) that the DTNWG uses as the basis for its work. The ke= y >>> components of the this architecture are the bundle concept for >>> encapsulating data units, the bundle transmission protocol and th= e >>> underlying convergence layer architecture. >>> >>> The experimental DTN Bundle Protocol (RFC 5050) and Licklider >>> Transmission Protocol (RFC 5326) have been shown to address the >>> issues identified above in substantial fielded deployments in the= space >>> sector [1]. RFC 5050 in conjunction with TCP- and UDP-based conv= ergence >>> layers has been used successfully in a number of experiments both= in >>> communications challenged environments around the edges of the In= ternet >>> and as an Internet overlay where applications require delay- and/= or >>> disruption-tolerance [refs needed]. >>> >>> The success of the BP over convergence layer protocol stack -- th= e core >>> protocols of the "DTN Architecture" described in RFC 4838 -- may = be >>> attributed to the following fundamental design principles: >>> >>> - There is never any expectation of contemporaneous end-to-end >>> connectivity between any two network nodes. >>> >>> - Because end-to-end connectivity can never be assumed, each node >>> on the path between source and destination must be prepared to >>> handle incoming "bundles" of data that cannot immediately be >>> forwarded. >>> >>> - Again because end-to-end connectivity can never be assumed, >>> end-to-end conversational data exchange can never be assumed to >>> complete in a timely manner; protocol features that rely on >>> timely conversational data exchange must be excluded from the >>> architecture. >>> >>> The DTNWG believes that protocols adhering to these principles of= fer >>> opportunities for enhancing the functionality of the Internet,=20 >>> including >>> >>> - facilitating the extension of the Internet into environments = such as >>> the ocean floor and deep space in which the core Internet pro= tocols >>> operate sub-optimally for the reasons discussed earlier; >>> >>> - extending the Internet into communications challenged terrest= rial >>> environments where it is not possible to provide continuous, = low >>> delay Internet connections; and >>> >>> - supporting Internet applications that need DTN capabiliies. >>> >>> We believe that the extensive research, demonstration, and >>> pilot operations performed to date using the DTNRG protocols prov= ides >>> a firm basis for publishing Internet standards derived from that = work. >>> >>> Work items related to Delay/Disruption Tolerant Networking includ= e: >>> >>> o A mechanism for the exchange of protocol data units, termed >>> "bundles", that are designed to obviate conversational communicatio= ns >>> by containing values for all potentially relevant configuration >>> parameters. These protocol data units are typically larger than >>> network-layer packets. We will derive this bundle exchange mechanis= m >>> from the DTN Bundle Protocol (BP) documented in RFC 5050 by pub= lishing >>> a new document for which [2] is a proposed first draft (where >>> appendix A provides a summary of the proposed changes). >>> >>> o A security protocol for ensuring that the network in which bund= les >>> are exchanged is secured against unauthorized access and denial of >>> service attacks, and to ensure data integrity and confidentiality >>> in that network where necessary. We will derive this security >>> protocol from a "streamlined" adaptation of the DTN Bundle Security >>> Protocol documented in RFC 6257. >>> >>> o A delay-tolerant security key management scheme that can prote= ct >>> the integrity of a DTN network. >>> >>> o A simple datagram convergence layer protocol for adaptation of = the >>> bundle protocol to underlying internetworks. We expect to deriv= e >>> this convergence layer protocol from the Datagram Convergence >>> protocol documented in RFC 7122. >>> >>> o A protocol for remote status monitoring, configuration, and >>> administration of network nodes in the presence of long delays >>> and/or intermittent connectivity. >>> >>> o A functional specification of Contact Graph Routing (CGR) speci= fying >>> the inputs (global contact schedules, traffic demands, etc.) an= d >>> outputs (node specific transmission and reception schedules, >>> notifications, etc.). CGR is a centralized, oracle-based bundl= e >>> transmission and reception scheduling scheme used in space segm= ent >>> DTN deployments. >>> >>> o An adjunct to the management protocol that will allow the conta= ct >>> schedules generated by CGR to be distributed to nodes. This ma= y be >>> based on the Contact Plan Update Protocol (CPUP) proposed in >>> >>> o An encapsulation protocol for "tunneling" BP traffic within bun= dles >>> that are secured and/or routed in different way from the encapsulat= ed >>> bundles. >>> >>> o A registry for DTN Service Identifiers >>> >>> The working group will consider extending the current milestones ba= sed on >>> new information and knowledge gained while working on the initial c= harter, >>> as well as to accommodate new work items beyond the scope of the in= itial >>> phase. For example, we expect that transport protocols such as LTP= and >>> the Saratoga protocol are among the candidates for work in this pha= se. >>> >>> Goals and Milestones: >>> start+0mos - Accept 'Bundle Protocol Specification (RFC5050bis)' [2] = as >>> a working group work item intended for Proposed Standard= . >>> Start+0mos - Accept 'Streamlined Bundle Security Protocol (SBSP)' [3]= as >>> a working group work item intended for Proposed Standard= . >>> start+3mos - Accept 'Bundle In Bundle Encapsulation (BIBE)' [4] as a >>> working work item intended for Proposed Standard. >>> start+6mos - Working group getting concensus on changes to be impleme= nted >>> in RFC 5050(bis). >>> start+9mos - Working group getting consensus on merging RFC5050bis, S= BSP, >>> BIBE etc. into a combined draft or keep as separate draf= ts. >>> start+12mos - Accept 'CGR Functional Specification' as a working grou= p >>> working group work item intended for Informational. >>> start+12mos - Accept 'Delay Tolerant Networking Security Key Manageme= nt' >>> as a working group work item intended for Proposed Stan= dard. >>> start+15mos - Accept 'Contact Plan Update Protocol' as working group = work >>> item intended for Proposed Standard. >>> start+18mos - Submit RFC5050bis, SBSP, BIBE and Key Mgmt to the IESG = either >>> as a combined draft or as separate drafts. >>> start+18mos - Submit Network Management [5], Registry [6] and Simple >>> Convergence Layer [7] as working group documents. >>> start+20mos - Survey appropriate forums (e.g., DTNRG) for emerging >>> technologies (e.g., convergence layer protocols, dynami= c >>> routing protocols, naming and addressing services, etc.= ) >>> ready for transition into IETF DTN Working Group. Publi= sh >>> draft on survey results as independent submission relat= ed >>> to the WG. >>> start+24mos - Submit Network Management, Registry and Simple Converge= nce >>> Layer to IESG >>> start+24mos - Recharter to accommodate new work items or close=20 >>> Working Group >>> >>> >>> [1] "BP/LTP deployment on EPOXI spacecraft" [2008], >>> http://committees.comsoc.org/tccc/ccw/2010/slides/DINET_CCW.pdf >>> [2] "Proposed Revised Bundle Protocol" [2014], >>> https://datatracker.ietf.org/doc/draft-burleigh-bpv7/ >>> [3] "Streamlined Bundle Security Protocol Specification" [2014], >>> https://datatracker.ietf.org/doc/draft-irtf-dtnrg-sbsp/ >>> [4] "Bundle-in-Bundle Encapsulation" [2013], >>> http://tools.ietf.org/id/draft-irtf-burleigh-bibe >>> [5] "Delay Tolerant Network Management Protocol" [2013], >>> http://tools.ietf.org/id/draft-irtf-dtnrg-dtnmp >>> [6] "Delay-Tolerant Networking Bundle Protocol IANA Registries" [2011], >>> https://datatracker.ietf.org/doc/rfc6255/ >>> [7] "Datagram Convergence Layers ..." [2014], >>> https://datatracker.ietf.org/doc/rfc7122/ >>> [8] "Towards Flexibility and Accuracy in Space DTN Communications", >>> Bezirgianndia et al, CHANTS 2012, >>> http://dl.acm.org/citation.cfm?id=3D2505499 [2012] >>> >>> >>> >>> _______________________________________________ >>> dtn mailing list >>> dtn@ietf.org >>> https://www.ietf.org/mailman/listinfo/dtn >>> >=20 > _______________________________________________ > dtn mailing list > dtn@ietf.org > https://www.ietf.org/mailman/listinfo/dtn >=20 >=20 _______________________________________________ dtn mailing list dtn@ietf.org https://www.ietf.org/mailman/listinfo/dtn From nobody Tue Jun 17 15:37:51 2014 Return-Path: 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 831451A018A for ; Tue, 17 Jun 2014 15:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 SK1v9wRzc5rH for ; Tue, 17 Jun 2014 15:37:48 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 11F661A0188 for ; Tue, 17 Jun 2014 15:37:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6416FBF04; Tue, 17 Jun 2014 23:37:47 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxw4HXGpCr-5; Tue, 17 Jun 2014 23:37:45 +0100 (IST) Received: from [10.87.48.12] (unknown [86.46.21.97]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CE73CBEDF; Tue, 17 Jun 2014 23:37:45 +0100 (IST) Message-ID: <53A0C339.2040106@cs.tcd.ie> Date: Tue, 17 Jun 2014 23:37:45 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Burleigh, Scott C (312G)" , "dtn@ietf.org" References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> <2134F8430051B64F815C691A62D983183048B3B6@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983183048DB80@XCH-BLV-512.nw.nos.boeing.com> <53A09F61.2030900@cs.tcd.ie> <2134F8430051B64F815C691A62D983183048DD9A@XCH-BLV-512.nw.nos.boeing.com> <53A0A5B8.1090802@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/lMgs7wZRz9XNmbHnSjtMag_smt4 Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 22:37:50 -0000 On 17/06/14 23:23, Burleigh, Scott C (312G) wrote: > 1. The UAV industry is exploding. Nobody has any idea where the > limits on applications of UAVs are, but what we do know is that the > information that controls them is conveyed by radio, which is > occasionally subject to disruption. Technology that could improve > the safety and reliability of UAVs, while reducing cost, could find a > large market. Excellent example. Now if we knew that that was a focus of interest that'd be cool and we could discuss timing and contact requirements, development environments, tooling etc. and how DTN protocols might fit with e.g. telemetry/control. (Elwyn could even have fun with routing - we have an old unfunded proposal along those lines;-) I'm not saying its a fatal problem that we only have the already known use-cases, but new information such as a confirmation that your good example was real (and were we to have folks who work in that space involved), could make for a much more compelling BoF and likely successful WG. S. From nobody Tue Jun 17 15:48:04 2014 Return-Path: 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 0F7281A00FC for ; Tue, 17 Jun 2014 15:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 h_2fDN4KNfDz for ; Tue, 17 Jun 2014 15:47:55 -0700 (PDT) Received: from mail.ibr.cs.tu-bs.de (mail.ibr.cs.tu-bs.de [134.169.34.52]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 837CA1A008F for ; Tue, 17 Jun 2014 15:47:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.ibr.cs.tu-bs.de (Postfix) with ESMTP id 4A3291830D7; Wed, 18 Jun 2014 00:47:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ibr.cs.tu-bs.de; h=x-mailer:references:message-id:content-transfer-encoding:date :date:in-reply-to:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=key1; t= 1403045272; x=1404859673; bh=8fiQSNNL1tLMTQnpZy8gwl7QRiGu891TN5z GcerytZo=; b=Vu2g95eL6Xk+I1TwTKUQS42RTISr+2WBAnlvF7H2G1Yfi8f6aeC HtB2aofuE+mCBLZcAMmMghMQ2XvVVL+GFTWXJY+aJrocfM7hKNcr8pu6p8jvK7Wi t/rBttu03fZP/cZapNmdLqLIVVqUdt4UqU+ee/9PObN0Jd2l9BDpPbk4= X-Virus-Scanned: Debian amavisd-new at ibr.cs.tu-bs.de Received: from mail.ibr.cs.tu-bs.de ([127.0.0.1]) by localhost (mail.ibr.cs.tu-bs.de [127.0.0.1]) (amavisd-new, port 10026) with LMTP id yfm7a5QRxYiK; Wed, 18 Jun 2014 00:47:52 +0200 (CEST) Received: from defiant.fritz.box (brsg-4dbd7f28.pool.mediaWays.net [77.189.127.40]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schildt@ibr.cs.tu-bs.de) by mail.ibr.cs.tu-bs.de (Postfix) with ESMTPSA id 8D39F183097; Wed, 18 Jun 2014 00:47:51 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Sebastian Schildt In-Reply-To: <1403029476.99627.YahooMailNeo@web125106.mail.ne1.yahoo.com> Date: Wed, 18 Jun 2014 00:47:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9122BF64-6457-4CF6-A801-2BF34F3D25C1@ibr.cs.tu-bs.de> References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> <2134F8430051B64F815C691A62D983183048B3B6@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983183048DB80@XCH-BLV-512.nw.nos.boeing.com> <1403029476.99627.YahooMailNeo@web125106.mail.ne1.yahoo.com> To: William Ivancic X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/D8ALv0NAxzyyMWXFvpy8ky7-pAI Cc: "Templin, Fred L" , "dtn@ietf.org" Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 22:48:03 -0000 Hello *, I think this raises some interesting points, and from my standpoint I=92d = like to add something regarding scalabiliy and design targets. On 17 Jun 2014, at 20:24, William Ivancic = wrote: > Some thoughts: >=20 > I think we need some deep philosophical discussion at the BOF on what = we are trying to do with DTN. Most (actually ALL) deployments I am = aware of have been in the order of probably tens or less nodes - = certainly less than 100. Are we developing a standard for space systems = or looking at hundreds of thousands or millions of nodes?=20 Millions. At least. I think this is an important point, but as has been mentioned by other = replies, maybe scalability is not such a big problem: We can start small = and grow. Like IP currently there is nothing in the BP itself that = limits scalability. The main challenges wrt. scalability are=20 1. Routing. While I have lots of opinions on that, I will not open that = discussion again, and it is nothing in the =84core=93-protocol.=20 2. Storage: What to do, when there are millions of bundles around? Who = will store what and for how long? But a significant part of these may = also be implementation issues. So trusting, that there are no fundamental problems with scaling up, = when working with DTNs/BP I usually have large-scale systems in mind. I = have always seen DTN/BP as a - for a lack of a better word - "future = internet" approach. Not like the dream that many of the "real" future = internet project have: Switch off the old system, and the new one takes = over. I rather imagine some slow, organic growth, where more and more = applications, for which it makes sense, transition to DTN (which can be = transported over existing internet transports just fine). An obvious = appication area for which the transtion to DTN makes sense are Apps that = extend from the internet into fringe networks (internet-based services = focussed on mobile users). More importantly, I see the space and terrestrial use cases converging: = The original reason to have DTNs for IPNs are delays and disruptions. = Now, in the short term the applications that are deployed might be = control traffic for space craft and such things. But if we are thinking = about the middle-term we might have couple of (ten) thousand people = living on Mars or elsewhere in the neighbourhood, where we will have = communication delays. However, as far as I have followed developments, = we WILL have quite a bit of bandwidth(*1). Definitely we do not want to = have Mars-Intranet and Earth-Intranet. Or millions of = application-specific synchronization solutions (Facebook-Sync, = Twitter-Sync,...). Instead, I imagine applications that they are already = built in an asynchronous DTN using DTN protocols and thus will just = work. Granted, this might all only become relevant, after I have long = been recylced, but at least it is one of the images that guide me, when = I work on DTN problems. Think big! >=20 > I do know that some groups want to run DTN (RFC5050) at extremely high = rates (Gbps and higher). The current structure, while nice for research = with all the flexibility, is not very well suited for high-speed = deployments - particularly if you are considering space-based hardware = and processors. Do we address this? In principle, store-carry-and forward as implemented by the BP needs = more ressources then lets say TCP/IP. While some research software might = not be optimized for performance, this is largely an enigneering = problem. Over the last years we put some effort into improving the = performance of our own IBR-DTN implementation, and today it _can_ = saturate a GBit ethernet link using a normal PC (*2). When we started = optimizing, we were far from it. Now it is possible, and I am sure there = is much more potential for implementations focussing on this point. Regarding slower hardware, we built a BP implementation for an 8 Bit = microcontroller(*3). While this can not saturate a GBit link :), = throughput-wise it was in the same league as an IP implementation on the = same plattform. So I would say the current structure, while being more = complex than classical non-DTN protocols, does not necessarily limits = performance MfG Sebastian *1 = http://arstechnica.com/science/2014/05/wireless-broadband-can-reach-the-mo= on-and-maybe-mars/ *2 Wolf-Bastian P=F6ttner, Johannes Morgenroth, Sebastian Schildt and = Lars Wolf: An Empirical Performance Comparison of DTN Bundle Protocol = Implementations, Technische Universit=E4t Braunschweig, = Informatikbericht 2011-08, = https://www.ibr.cs.tu-bs.de/papers/poettner-tr201108.pdf Current tests: http://jenkins.ibr.cs.tu-bs.de/dtnperf/ *3 The =B5DTN project https://www.ibr.cs.tu-bs.de/projects/mudtn/ Wolf-Bastian P=F6ttner, Felix B=FCsching, Georg von Zengen and Lars = Wolf: Data Elevators: Applying the Bundle Protocol in Delay Tolerant = Wireless Sensor Networks, in The Ninth IEEE International Conference on = Mobile Ad-hoc and Sensor Systems (IEEE MASS 2012) From nobody Tue Jun 17 17:21:37 2014 Return-Path: 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 3080C1A01AB for ; Tue, 17 Jun 2014 17:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 Zo3-iai9xbCZ for ; Tue, 17 Jun 2014 17:21:28 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.106]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2458E1A01A5 for ; Tue, 17 Jun 2014 17:21:28 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp01.jpl.nasa.gov [128.149.137.148]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s5I0LQeX019732 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO) for ; Tue, 17 Jun 2014 17:21:27 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.217]) by ap-ehub-sp01.RES.AD.JPL ([169.254.3.182]) with mapi id 14.03.0174.001; Tue, 17 Jun 2014 17:19:14 -0700 From: "Burleigh, Scott C (312G)" To: "dtn@ietf.org" Thread-Topic: [dtn] Draft Charter Discussion Thread-Index: Ac+GbO3wN7xIp4CqSFeVEjvJc65+vAAPLd8AAAy+SjAAJnyrgAC3CG0QABBXewAADCj6oA== Date: Wed, 18 Jun 2014 00:19:13 +0000 Message-ID: References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> <2134F8430051B64F815C691A62D983183048B3B6@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983183048DB80@XCH-BLV-512.nw.nos.boeing.com> <1403029476.99627.YahooMailNeo@web125106.mail.ne1.yahoo.com> In-Reply-To: <1403029476.99627.YahooMailNeo@web125106.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.113] Content-Type: multipart/alternative; boundary="_000_A5BEAD028815CB40A32A5669CF737C3B423E02A5apembxsp40RESAD_" MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/nlTIP0LYMEgdIxvbU20AkR9aJVI Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 00:21:33 -0000 --_000_A5BEAD028815CB40A32A5669CF737C3B423E02A5apembxsp40RESAD_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A perfectly reasonable perspective, Will. Let me offer a different one. I don't know how it's possible to say that we don't really know what proble= m we are trying to solve with DTN, when that problem statement is laid out = in detail in section 2 of RFC 4838 and in the papers referenced in that tex= t. Let's set that aside. I agree, all deployments that I am aware of have encompassed fewer than 100= nodes. But this in itself doesn't suggest to me that DTN is structurally = unable to support a deployment of millions of nodes. It suggests to me tha= t nobody has yet chosen to deploy a larger DTN-based network. So, is the scalability of DTN an issue? I can think of two good ways to an= swer that question. One is to attempt to deploy a very large DTN-based net= work. If the attempt fails due to some structural defect in the DTN archit= ecture then yes, it's an issue; if not, then it apparently isn't. If someo= ne has the resources to take this on as an experiment, that would be great.= But it seems unlikely. The other would be by inspection: are there elements of required DTN functi= onality that we know a priori cannot be accomplished if the network compris= es a million nodes? If there are, then we should be able to enumerate them, yes? Do you have a= ny candidates? I'll agree that none of the routing systems deployed to date will scale up = to a million nodes; a system for federating routing "regions" (something a = bit like autonomous systems in the Internet) will very likely be needed. B= ut that's just development that hasn't happened yet, because nobody has req= uired it. It's not a structural defect, any more than the need to develop = BGP in order to enable the Internet to scale up to millions of nodes was a = structural defect. So what else? How to deal with a bundle for which you have no route is certainly a questi= on, and different implementations of DTN answer that question in different = ways. Is that a problem? If it is (and I am by no means convinced that it= is) then aren't we talking about writing two lines of specification to dea= l with it? That doesn't seem like a significant structural defect to me. Nor is high-rate operation an issue. As Sebastian notes, IBR DTN on a PC c= an already saturate a Gigabit Ethernet. ION runs a bit slower, in part bec= ause the implementation is designed to be able to survive an unplanned powe= r reset at any moment without losing state or compromising the integrity of= bundles at rest. Even so, ION's built-in benchmark tests show BP/LTP betw= een two nodes on the Linux box in my office running at about 390 Mbps for 1= -Megabyte bundles. (BP/TCP is faster, close to 3 Gbps for 10-Megabyte bundl= es.) Finally, to say that all of the DTN operations experience on ISS since 2009= , the METERON experiments in DTN-based telerobotics, the N4C experiments in= Slovenia and Sweden from 2008 to 2011, and the month-long DINET operations= on EPOXI over 10 million miles from Earth, with multi-day round trip times= , all amount to little more than a ping is simply false. So sure, there's still plenty of room for research on DTN. People still do= research on Internet issues, I believe. I don't think there's a problem h= ere. Scott From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of William Ivancic Sent: Tuesday, June 17, 2014 11:25 AM To: Templin, Fred L; dtn@ietf.org Subject: Re: [dtn] Draft Charter Discussion Some thoughts: I think we need some deep philosophical discussion at the BOF on what we ar= e trying to do with DTN. Most (actually ALL) deployments I am aware of hav= e been in the order of probably tens or less nodes - certainly less than 10= 0. Are we developing a standard for space systems or looking at hundreds o= f thousands or millions of nodes? I think the last time IETF worked a specific problem it was TCPSAT and, I b= elieve, the IETF decided that we would not do work on a specific deployment= area. (Fortunately, the TCP over Satellite actually had a more generic pr= oblem which was time/bandwidth.) If the end result is deploying over 100 n= odes (10 nodes in 10 deployments) in the next 5 years, I doubt we should be= considering a standard at this time. There has never been a "problem statement" written, so we don't really know= what problem we are trying to solve. Is Scalability an issue? I think so= . There is currently no document of which I am aware of that states what the= default operation of a forwarding agent is. For example, if you have no r= oute, do you drop a bundle even if it has not expired or do you hold it in = anticipation of perhaps having a route later? I do know that some groups want to run DTN (RFC5050) at extremely high rate= s (Gbps and higher). The current structure, while nice for research with a= ll the flexibility, is not very well suited for high-speed deployments - pa= rticularly if you are considering space-based hardware and processors. Do = we address this? "We believe that the extensive research, demonstration, and pilot operations performed to date using the DTNRG protocols provides a firm basis for publishing Internet standards derived from that work= ." Quite honestly, I cannot agree with this statement. I have seen very littl= e with regards to scalability, a mix of traffic, a mix of bundle lifetimes,= a mix of bundle sizes, complex networks, etc. If you do a PING, you can, = with high degree of confidence, conclude that you have connectivity, but no= t much else. To date, IMHO, we haven't done much more that the equivalent = of a PING with regard to DTN RFC5050 (and nearly everyone I've talked to ha= s realized that there system wasn't synced to the 30 second default in DTNP= ING.). I was attracted to this research group because there are so many areas ripe= for research. That hasn't changed in over 7 years or more. All categories= are still wide open for research. Will Ivancic Syzygy Engineering ________________________________ --_000_A5BEAD028815CB40A32A5669CF737C3B423E02A5apembxsp40RESAD_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A perfectly reasonable pe= rspective, Will.  Let me offer a different one.

 <= /p>

I don’t know how it= ’s possible to say that we don’t really know what problem we ar= e trying to solve with DTN, when that problem statement is laid out in deta= il in section 2 of RFC 4838 and in the papers referenced in that text.  = Let’s set that aside.

 <= /p>

I agree, all deployments = that I am aware of have encompassed fewer than 100 nodes.  But this in= itself doesn’t suggest to me that DTN is structurally unable to support a deployment of millions of nodes.  It suggests to me that= nobody has yet chosen to deploy a larger DTN-based network.

 <= /p>

So, is the scalability of= DTN an issue?  I can think of two good ways to answer that question.&= nbsp; One is to attempt to deploy a very large DTN-based network.  If the attempt fails due to some structural defect in the DTN architecture= then yes, it’s an issue; if not, then it apparently isn’t.&nbs= p; If someone has the resources to take this on as an experiment, that woul= d be great.  But it seems unlikely.

 <= /p>

The other would be by ins= pection: are there elements of required DTN functionality that we know a pr= iori cannot be accomplished if the network comprises a million nodes?

 <= /p>

If there are, then we sho= uld be able to enumerate them, yes?  Do you have any candidates?<= /o:p>

 <= /p>

I’ll agree that non= e of the routing systems deployed to date will scale up to a million nodes;= a system for federating routing “regions” (something a bit lik= e autonomous systems in the Internet) will very likely be needed.  But = that’s just development that hasn’t happened yet, because nobod= y has required it.  It’s not a structural defect, any more than = the need to develop BGP in order to enable the Internet to scale up to millions of nodes was a structural defect.

 <= /p>

So what else?<= /span>

 <= /p>

How to deal with a bundle= for which you have no route is certainly a question, and different impleme= ntations of DTN answer that question in different ways.  Is that a problem?  If it is (and I am by no means convinced that it = is) then aren’t we talking about writing two lines of specification t= o deal with it?  That doesn’t seem like a significant structural= defect to me.

 <= /p>

Nor is high-rate operatio= n an issue.  As Sebastian notes, IBR DTN on a PC can already saturate = a Gigabit Ethernet.  ION runs a bit slower, in part because the implementation is designed to be able to survive an unplanned power reset = at any moment without losing state or compromising the integrity of bundles= at rest.  Even so, ION’s built-in benchmark tests show BP/LTP b= etween two nodes on the Linux box in my office running at about 390 Mbps for 1-Megabyte bundles. (BP/TCP is faster, close= to 3 Gbps for 10-Megabyte bundles.)

 <= /p>

Finally, to say that all = of the DTN operations experience on ISS since 2009, the METERON experiments= in DTN-based telerobotics, the N4C experiments in Slovenia and Sweden from 2008 to 2011, and the month-long DINET operations on EPOXI= over 10 million miles from Earth, with multi-day round trip times, all amo= unt to little more than a ping is simply false.

 <= /p>

So sure, there’s st= ill plenty of room for research on DTN.  People still do research on I= nternet issues, I believe.  I don’t think there’s a proble= m here.

 <= /p>

Scott

 <= /p>

From: dtn [mai= lto:dtn-bounces@ietf.org] On Behalf Of William Ivancic
Sent: Tuesday, June 17, 2014 11:25 AM
To: Templin, Fred L; dtn@ietf.org
Subject: Re: [dtn] Draft Charter Discussion

 

Some thoughts:=

 

I think we need some deep philosophical discus= sion at the BOF on what we are trying to do with DTN.  Most (actually = ALL) deployments I am aware of have been in the order of probably tens or less nodes - certainly less than 100.  Are we developing a st= andard for space systems or looking at hundreds of thousands or millions of= nodes?

 

I think the last time IETF worked a specific p= roblem it was TCPSAT and, I believe, the IETF decided that we would not do = work on a specific deployment area.  (Fortunately, the TCP over Satellite actually had a more generic problem which was time/bandwidt= h.)  If the end result is deploying over 100 nodes (10 nodes in 10 dep= loyments) in the next 5 years, I doubt we should be considering a standard = at this time.

 

There has never been a "problem statement= " written, so we don't really know what problem we are trying to solve= .  Is Scalability an issue?  I think so.

 

There is currently  no document of which = I am aware of that states what the default operation of a forwarding agent = is.  For example, if you have no route, do you drop a bundle even if it has not expired or do you hold it in anticipation of perhaps ha= ving a route later? 

 

I do know that some groups want to run DTN (RF= C5050) at extremely high rates (Gbps and higher).  The current structu= re, while nice for research with all the flexibility, is not very well suited for high-speed deployments - particularly if you are cons= idering space-based hardware and processors.  Do we address this?=

 

"We believe that the extensive research, = demonstration, and
      pilot operations performed to date using the= DTNRG protocols provides
      a firm basis for publishing Internet standar= ds derived from that work."

 

Quite honestly, I cannot agree with this state= ment.  I have seen very little with regards to scalability, a mix of t= raffic, a mix of bundle lifetimes, a mix of bundle sizes, complex networks, etc.  If you do a PING, you can, with high degree of confid= ence, conclude that you have connectivity, but not much else.  To date= , IMHO, we haven't done much more that the equivalent of a PING with regard= to DTN RFC5050 (and nearly everyone I've talked to has realized that there system wasn't synced to the 30 second de= fault in DTNPING.).

 

I was attracted to this research group because= there are so many areas ripe for research.  That hasn't changed in ov= er 7 years or more. All categories are still wide open for research.

 

Will Ivancic

Syzygy Engineering

 

 

 

 

--_000_A5BEAD028815CB40A32A5669CF737C3B423E02A5apembxsp40RESAD_-- From nobody Wed Jun 18 05:56:06 2014 Return-Path: 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 61A681A01F7 for ; Wed, 18 Jun 2014 05:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 5wADTBG8q1Ci for ; Wed, 18 Jun 2014 05:55:55 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CBAA1A01F2 for ; Wed, 18 Jun 2014 05:55:54 -0700 (PDT) Received: from [195.245.230.131:56006] by server-14.bemta-3.messagelabs.com id 80/5F-30903-65C81A35; Wed, 18 Jun 2014 12:55:50 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-7.tower-78.messagelabs.com!1403096148!30693698!1 X-Originating-IP: [131.227.200.39] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30669 invoked from network); 18 Jun 2014 12:55:49 -0000 Received: from exht012p.surrey.ac.uk (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-7.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 18 Jun 2014 12:55:49 -0000 Received: from EXHY022V.surrey.ac.uk (131.227.201.104) by EXHT012P.surrey.ac.uk (131.227.200.39) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 18 Jun 2014 13:55:48 +0100 Received: from emea01-db3-obe.outbound.protection.outlook.com (131.227.201.241) by EXHY022v.surrey.ac.uk (131.227.201.104) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 18 Jun 2014 13:55:48 +0100 Received: from AMSPR06MB439.eurprd06.prod.outlook.com (10.242.23.19) by AMSPR06MB440.eurprd06.prod.outlook.com (10.242.23.24) with Microsoft SMTP Server (TLS) id 15.0.959.24; Wed, 18 Jun 2014 12:55:46 +0000 Received: from AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) by AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) with mapi id 15.00.0959.000; Wed, 18 Jun 2014 12:55:46 +0000 From: To: , Thread-Topic: [dtn] Draft Charter Discussion Thread-Index: Ac+GbO3wN7xIp4CqSFeVEjvJc65+vAAAgscAAAICPYAAMTi4gADF12kAAAUIgYAAAEJPAAAAr4kAAAPqQQAAHbCsKQ== Date: Wed, 18 Jun 2014 12:55:45 +0000 Message-ID: <1403096144400.15210@surrey.ac.uk> References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> <2134F8430051B64F815C691A62D983183048B3B6@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983183048DB80@XCH-BLV-512.nw.nos.boeing.com> <53A09F61.2030900@cs.tcd.ie> <2134F8430051B64F815C691A62D983183048DD9A@XCH-BLV-512.nw.nos.boeing.com> <53A0A5B8.1090802@cs.tcd.ie>, In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [124.149.114.231] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02462830BE x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(377454003)(189002)(243025005)(199002)(24454002)(13464003)(51704005)(479174003)(31966008)(81342001)(64706001)(92566001)(54356999)(74502001)(4396001)(74482001)(50986999)(85306003)(105586002)(15975445006)(74662001)(81542001)(19580395003)(86362001)(76176999)(19580405001)(79102001)(80022001)(15202345003)(20776003)(46102001)(101416001)(83072002)(99396002)(76482001)(21056001)(87936001)(66066001)(77982001)(83322001)(92726001)(85852003)(95666004)(2656002)(36756003)(579004); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR06MB440; H:AMSPR06MB439.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: surrey.ac.uk does not designate permitted sender hosts) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: AMSPR06MB440.eurprd06.prod.outlook.com X-CrossPremisesHeadersFiltered: EXHY022v.surrey.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/Ogl7b6KxlNwgngLgQ0oaqEtCmcw Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 12:56:04 -0000 > 1. The UAV industry is exploding.=0A= =0A= Q. What's the difference between an Al Qaeda convoy and a bus full of schoo= lchildren?=0A= =0A= A. I don't know, I only fly the drones.=0A= =0A= Exploding? Really, Scott? Wouldn't 'growing' have been enough?=0A= =0A= We previously pointed out, in=0A= Lloyd Wood, Peter Holliday, Daniel Floreani and Wesley M. Eddy,=0A= 'Sharing the dream: The consensual networking hallucination offered=0A= by the Bundle Protocol', Workshop on the Emergence of=0A= Delay-/Disruption-Tolerant Networks (E-DTN),=0A= International Conference on Ultra Modern Telecommunication=0A= (ICUMT), St. Petersburg, Russia, 14 October 2009.=0A= http://dx.doi.org/10.1109/ICUMT.2009.5345655=0A= =0A= that there was no obvious reason for reindeer herders to talk to deep space= probes.=0A= There is no shared killer app.=0A= So there's no obvious or compelling reason to build a bundle overlay=0A= connecting them. The separate communities do need to connect to the Interne= t - =0A= but for entirely different purposes.=0A= =0A= However, I'm surprised that some sort of DTN herders-talk-to-schoolchildren= -talk-to=0A= astronauts-on-the-ISS-using-the-Bundle-Protocol effort has not been manufac= tured.=0A= Perhaps for the next ExtremeCom?=0A= =0A= A key point here is that TCP/IP was in widespread use _before_ it was a sta= ndard.=0A= The standards track was retrofitted (RFC1310 is later than RFC761/768 et al= .) to=0A= apply to specifications that have not changed substantially since.=0A= =0A= Here, the Bundle Protocol is not in widespread use, and it seems that some= =0A= are hoping that pushing it onto the standards track will fix that. While=0A= grudgingly acknowledging that, yes, it also needs reworking in rather=0A= significant ways, while not acknowledging the drain on IETF resources=0A= and attention that this will be. =0A= =0A= This sounds a lot like the OSI committee work - write the standard, and onc= e it's a=0A= standard they will be forced to come, success assured. That consumed a =0A= _lot_ of standards body resources.=0A= =0A= Lloyd Wood=0A= http://sat-net.com/L.Wood/dtn=0A= ________________________________________=0A= From: dtn on behalf of Burleigh, Scott C (312G) =0A= Sent: Wednesday, 18 June 2014 8:23 AM=0A= To: dtn@ietf.org=0A= Subject: Re: [dtn] Draft Charter Discussion=0A= =0A= Okay, taking another crack at this.=0A= =0A= I think there are two levels of question here, one implying the other, and = it might be helpful to address them separately.=0A= =0A= First the proximate question: given that DTN exists, why standardize it? W= hy not just use it as it is? What has changed?=0A= =0A= I think the answer there, to which Fred and Ed have alluded, is that there = are business entities that would now like to use DTN to solve some communic= ation problems (or exploit some opportunities) but won't risk doing so whil= e the protocols are not standards. I know Ed works with such entities on a= regular basis, and the fact that Boeing is willing to invest some time and= money in this BoF seems to suggest that they at least are another such ent= ity.=0A= =0A= So then the underlying question: what are those problems and opportunities = for which a standardized DTN would be used?=0A= =0A= As Fred has pointed out, organizations that hope to make money from these i= deas are not likely to disclose them here or in the BoF. But, just from my= own reading of the news, let me suggest a couple of potential DTN use case= s that go beyond the ISS and Saami deployments we're all familiar with.=0A= =0A= 1. The UAV industry is exploding. Nobody has any idea where the limits on= applications of UAVs are, but what we do know is that the information that= controls them is conveyed by radio, which is occasionally subject to disru= ption. Technology that could improve the safety and reliability of UAVs, w= hile reducing cost, could find a large market.=0A= =0A= 2. The speed of sound underwater is 1.5 km/sec, so the round-trip time bet= ween two underwater entities communicating by acoustic modem and separated = by a distance of 7.5 km is about equal to the round-trip time between Earth= and the Earth/Sun L2 Lagrange point. Since the data rates of acoustic mod= ems are low, efficient delay-tolerant networking is a pretty good way to es= tablish underwater communication. The market for underwater sensors and in= strumentation is already in the billions of dollars; revenue in the autonom= ous underwater vehicle manufacturing industry is growing at nearly 14% per = year.=0A= =0A= 3. The "space" use case is arguably still small if you restrict it to the = vehicles that are in orbit. If you extend the space communication use case= to users on Earth who will need to communicate with spacecraft over the ne= xt two decades, as Earth orbit becomes increasingly industrialized, then yo= u find yourself talking about a very large user community.=0A= =0A= And I am pretty sure there are more that I'm not aware of. The basic propo= sition is that the Internet is an outstanding communications solution for a= ll parts of Earth's surface that are relatively easy to get to, but there a= re business opportunities that are beyond its current reach. DTN can help = extend that outstanding communications solution to currently Internet-inhos= pitable parts of the Earth and near-Earth, benefiting a lot of people. Sta= ndardizing it will help make that happen. As Vint remarked in one of our c= onversations on this topic (I paraphrase freely), the Internet didn't get c= reated because somebody thought of a killer app; people thought of killer a= pps because there was an Internet.=0A= =0A= Scott=0A= =0A= -----Original Message-----=0A= From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of Stephen Farrell=0A= Sent: Tuesday, June 17, 2014 1:32 PM=0A= To: Templin, Fred L; dtn@ietf.org=0A= Subject: Re: [dtn] Draft Charter Discussion=0A= =0A= =0A= Hi Fred,=0A= =0A= On 17/06/14 21:12, Templin, Fred L wrote:=0A= > Hi Stephen,=0A= >=0A= >> -----Original Message-----=0A= >> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]=0A= >> Sent: Tuesday, June 17, 2014 1:05 PM=0A= >> To: Templin, Fred L; dtn@ietf.org=0A= >> Subject: Re: [dtn] Draft Charter Discussion=0A= >>=0A= >>=0A= >> Fred and others,=0A= >>=0A= >> I think I've asked this before so apologies if I just forget the good=0A= >> answer;-)=0A= >>=0A= >> We have the space use-case and some fairly well known niche=0A= >> terrestrial use-cases, which are fine. But we've known these for=0A= >> years and the DTNRG didn't want to move to the standards track until=0A= >> now.=0A= >=0A= > Yes, a diverse set of use cases and not a single use case. That means=0A= > that in the early days there may be many purpose-built DTNs that may=0A= > at a later time be joined together to form larger DTNs.=0A= > A "DTN-of-DTNs" in the same way that the Internet is a "network-=0A= > of-networks".=0A= >=0A= > The whole reason the Internet was able to join together smaller=0A= > networks to form larger networks is that the Internet had=0A= > interoperable standards from the very beginning. It is now time for us=0A= > to do that for DTN.=0A= =0A= I'm familiar with DTN. But I find the above a pretty complete non-answer to= the question asked (in that it answers no part of my question:-) So I'll t= ry again, in a more direct fashion...=0A= =0A= I do not know why specifically Boeing want a standards track RFC5050bis, no= r why you want it now.=0A= =0A= And I'm wondering and would like to know. I have not heard your use-case (o= r business case, whatever) explained so far.=0A= Nor have I heard someone say "can't/won't tell, sorry."=0A= So I'm curious.=0A= =0A= And I'll note once again that successful BoFs tend to involve explaining wh= y this, now, specifically. As an IESG member it makes it much easier for me= to evaluate proposals for forming a WG.=0A= =0A= (BTW, any answer that asks me to think like an acorn won't really work for = this question, sorry:-)=0A= =0A= If someone else has a new answer to this question that would also be intere= sting. By new, I mean a use-case or business-case that hasn't previously be= en discussed in the DTNRG.=0A= =0A= Cheers,=0A= S.=0A= =0A= PS: In case there's confusion. My question is very much not the same as Wil= l's, despite your answer being very similar.=0A= =0A= >=0A= > Thanks - Fred=0A= > fred.l.templin@boeing.com=0A= >=0A= >> I think it'd help the IESG to decide whether to approve a WG if there=0A= >> were more information available about what has changed to motivate=0A= >> moving to the standards track.=0A= >>=0A= >> If (say for Boeing) those are such that you can't say and there=0A= >> aren't any others who can, then that's a pity, since it does make it=0A= >> harder to get why a 5050bis on the standards track is attractive.=0A= >>=0A= >> I'm just noting this again because I think many recent successful=0A= >> BoFs have tended to have this topic as part of the agenda, but it=0A= >> seems missing in yours, which just assumes that the room knows that=0A= >> RFC5050 needs a bit of work. (I'm exaggerating a bit there, but I=0A= >> hope you get what I mean.)=0A= >>=0A= >> S.=0A= >>=0A= >> On 17/06/14 18:40, Templin, Fred L wrote:=0A= >>> Please see below for an updated version of the draft charter based=0A= >>> on list discussions, and post any further comments in follow-up.=0A= >>> (See also attached for diffs relative to the previous version.)=0A= >>>=0A= >>> Thanks - Fred=0A= >>> fred.l.templin@boeing.com=0A= >>>=0A= >>> ---=0A= >>>=0A= >>> Draft BoF Agenda (2.5hrs):=0A= >>> **************************=0A= >>> 1) Problem statement (IETF wg motivation) - 30min=0A= >>>=0A= >>> 2) RFC5050(bis) - 15min=0A= >>>=0A= >>> 3) Streamlined Bundle Security Protocol (SBSP) - 15min=0A= >>>=0A= >>> 4) Security Key Management - 10min=0A= >>>=0A= >>> 5) Network Management - 10min=0A= >>>=0A= >>> 6) Contact Graph Routing and Contact Plan Update Protocol - 10min=0A= >>>=0A= >>> 7) Bundle-in-Bundle Encapsulation - 5min=0A= >>>=0A= >>> 8) Registry for Service Identifiers - 5min=0A= >>>=0A= >>> 9) Open Discussion - 50min=0A= >>>=0A= >>>=0A= >>> Draft working group charter:=0A= >>> ****************************=0A= >>> Working group name:=0A= >>>=0A= >>> Delay/Disruption Tolerant Networking Working Group (DTNWG)=0A= >>>=0A= >>> Chair(s):=0A= >>>=0A= >>> TBD=0A= >>>=0A= >>> Area and Area Director(s):=0A= >>>=0A= >>> Transport Area: ADs Spencer Dawkins ,=0A= >>> Martin Stiemerling =0A= >>>=0A= >>> Responsible Area Director:=0A= >>>=0A= >>> TBD=0A= >>>=0A= >>> Mailing list:=0A= >>>=0A= >>> General Discussion: dtn at ietf.org=0A= >>> To Subscribe: https://www.ietf.org/mailman/listinfo/dtn=0A= >>> Archive:=0A= >>> http://www.ietf.org/mail-archive/web/dtn/current/maillist.html=0A= >>>=0A= >>> Description of Working Group:=0A= >>>=0A= >>> The Delay/Disruption Tolerant Network Working Group (DTNWG) speci= fies=0A= >>> mechanisms for data communications in the presence of long delays= =0A= >>> and/or intermittent connectivity. The work is motivated by well k= nown=0A= >>> limitations of standard Internet protocols that expect end-to-end= =0A= >>> connectivity between communicating endpoints, sub-second transmis= sion=0A= >>> delays and robust packet delivery ratios. In environments where t= hese=0A= >>> favorable conditions do not apply, existing mechanisms encounter = problems=0A= >>> such as reliable transport protocol handshakes timing out and rou= ting=0A= >>> protocols failing to converge resulting in communication failures= .=0A= >>> Furthermore, classical end-to-end security associations cannot be= =0A= >>> coordinated when communicating endpoints cannot conduct multi-mes= sage=0A= >>> keying exchanges in a timely fashion. These limitations suggested= the=0A= >>> need for a new approach.=0A= >>>=0A= >>> Delay-Tolerant Networking (DTN) protocols have been the subject o= f=0A= >>> extensive research and development in the Delay-Tolerant Networki= ng=0A= >>> Research Group (DTNRG) of the Internet Research Task Force since = 2002.=0A= >>> The DTNRG has developed the Delay-Tolerant Networking Architectur= e=0A= >>> (RFC 4838) that the DTNWG uses as the basis for its work. The ke= y=0A= >>> components of the this architecture are the bundle concept for=0A= >>> encapsulating data units, the bundle transmission protocol and th= e=0A= >>> underlying convergence layer architecture.=0A= >>>=0A= >>> The experimental DTN Bundle Protocol (RFC 5050) and Licklider=0A= >>> Transmission Protocol (RFC 5326) have been shown to address the= =0A= >>> issues identified above in substantial fielded deployments in the= space=0A= >>> sector [1]. RFC 5050 in conjunction with TCP- and UDP-based conv= ergence=0A= >>> layers has been used successfully in a number of experiments both= in=0A= >>> communications challenged environments around the edges of the In= ternet=0A= >>> and as an Internet overlay where applications require delay- and/= or=0A= >>> disruption-tolerance [refs needed].=0A= >>>=0A= >>> The success of the BP over convergence layer protocol stack -- th= e core=0A= >>> protocols of the "DTN Architecture" described in RFC 4838 -- may = be=0A= >>> attributed to the following fundamental design principles:=0A= >>>=0A= >>> - There is never any expectation of contemporaneous end-to-end=0A= >>> connectivity between any two network nodes.=0A= >>>=0A= >>> - Because end-to-end connectivity can never be assumed, each node= =0A= >>> on the path between source and destination must be prepared to=0A= >>> handle incoming "bundles" of data that cannot immediately be=0A= >>> forwarded.=0A= >>>=0A= >>> - Again because end-to-end connectivity can never be assumed,=0A= >>> end-to-end conversational data exchange can never be assumed to= =0A= >>> complete in a timely manner; protocol features that rely on=0A= >>> timely conversational data exchange must be excluded from the=0A= >>> architecture.=0A= >>>=0A= >>> The DTNWG believes that protocols adhering to these principles of= fer=0A= >>> opportunities for enhancing the functionality of the Internet,=0A= >>> including=0A= >>>=0A= >>> - facilitating the extension of the Internet into environments = such as=0A= >>> the ocean floor and deep space in which the core Internet pro= tocols=0A= >>> operate sub-optimally for the reasons discussed earlier;=0A= >>>=0A= >>> - extending the Internet into communications challenged terrest= rial=0A= >>> environments where it is not possible to provide continuous, = low=0A= >>> delay Internet connections; and=0A= >>>=0A= >>> - supporting Internet applications that need DTN capabiliies.= =0A= >>>=0A= >>> We believe that the extensive research, demonstration, and=0A= >>> pilot operations performed to date using the DTNRG protocols prov= ides=0A= >>> a firm basis for publishing Internet standards derived from that = work.=0A= >>>=0A= >>> Work items related to Delay/Disruption Tolerant Networking includ= e:=0A= >>>=0A= >>> o A mechanism for the exchange of protocol data units, termed=0A= >>> "bundles", that are designed to obviate conversational communica= tions=0A= >>> by containing values for all potentially relevant configuration= =0A= >>> parameters. These protocol data units are typically larger than= =0A= >>> network-layer packets. We will derive this bundle exchange mecha= nism=0A= >>> from the DTN Bundle Protocol (BP) documented in RFC 5050 by pub= lishing=0A= >>> a new document for which [2] is a proposed first draft (where= =0A= >>> appendix A provides a summary of the proposed changes).=0A= >>>=0A= >>> o A security protocol for ensuring that the network in which bund= les=0A= >>> are exchanged is secured against unauthorized access and denial = of=0A= >>> service attacks, and to ensure data integrity and confidentialit= y=0A= >>> in that network where necessary. We will derive this security= =0A= >>> protocol from a "streamlined" adaptation of the DTN Bundle Secur= ity=0A= >>> Protocol documented in RFC 6257.=0A= >>>=0A= >>> o A delay-tolerant security key management scheme that can prote= ct=0A= >>> the integrity of a DTN network.=0A= >>>=0A= >>> o A simple datagram convergence layer protocol for adaptation of = the=0A= >>> bundle protocol to underlying internetworks. We expect to deriv= e=0A= >>> this convergence layer protocol from the Datagram Convergence= =0A= >>> protocol documented in RFC 7122.=0A= >>>=0A= >>> o A protocol for remote status monitoring, configuration, and=0A= >>> administration of network nodes in the presence of long delays= =0A= >>> and/or intermittent connectivity.=0A= >>>=0A= >>> o A functional specification of Contact Graph Routing (CGR) speci= fying=0A= >>> the inputs (global contact schedules, traffic demands, etc.) an= d=0A= >>> outputs (node specific transmission and reception schedules,=0A= >>> notifications, etc.). CGR is a centralized, oracle-based bundl= e=0A= >>> transmission and reception scheduling scheme used in space segm= ent=0A= >>> DTN deployments.=0A= >>>=0A= >>> o An adjunct to the management protocol that will allow the conta= ct=0A= >>> schedules generated by CGR to be distributed to nodes. This ma= y be=0A= >>> based on the Contact Plan Update Protocol (CPUP) proposed in=0A= >>>=0A= >>> o An encapsulation protocol for "tunneling" BP traffic within bun= dles=0A= >>> that are secured and/or routed in different way from the encapsu= lated=0A= >>> bundles.=0A= >>>=0A= >>> o A registry for DTN Service Identifiers=0A= >>>=0A= >>> The working group will consider extending the current milestones ba= sed on=0A= >>> new information and knowledge gained while working on the initial c= harter,=0A= >>> as well as to accommodate new work items beyond the scope of the in= itial=0A= >>> phase. For example, we expect that transport protocols such as LTP= and=0A= >>> the Saratoga protocol are among the candidates for work in this pha= se.=0A= >>>=0A= >>> Goals and Milestones:=0A= >>> start+0mos - Accept 'Bundle Protocol Specification (RFC5050bis)' [2] = as=0A= >>> a working group work item intended for Proposed Standard= .=0A= >>> Start+0mos - Accept 'Streamlined Bundle Security Protocol (SBSP)' [3]= as=0A= >>> a working group work item intended for Proposed Standard= .=0A= >>> start+3mos - Accept 'Bundle In Bundle Encapsulation (BIBE)' [4] as a= =0A= >>> working work item intended for Proposed Standard.=0A= >>> start+6mos - Working group getting concensus on changes to be impleme= nted=0A= >>> in RFC 5050(bis).=0A= >>> start+9mos - Working group getting consensus on merging RFC5050bis, S= BSP,=0A= >>> BIBE etc. into a combined draft or keep as separate draf= ts.=0A= >>> start+12mos - Accept 'CGR Functional Specification' as a working grou= p=0A= >>> working group work item intended for Informational.=0A= >>> start+12mos - Accept 'Delay Tolerant Networking Security Key Manageme= nt'=0A= >>> as a working group work item intended for Proposed Stan= dard.=0A= >>> start+15mos - Accept 'Contact Plan Update Protocol' as working group = work=0A= >>> item intended for Proposed Standard.=0A= >>> start+18mos - Submit RFC5050bis, SBSP, BIBE and Key Mgmt to the IESG = either=0A= >>> as a combined draft or as separate drafts.=0A= >>> start+18mos - Submit Network Management [5], Registry [6] and Simple= =0A= >>> Convergence Layer [7] as working group documents.=0A= >>> start+20mos - Survey appropriate forums (e.g., DTNRG) for emerging=0A= >>> technologies (e.g., convergence layer protocols, dynami= c=0A= >>> routing protocols, naming and addressing services, etc.= )=0A= >>> ready for transition into IETF DTN Working Group. Publi= sh=0A= >>> draft on survey results as independent submission relat= ed=0A= >>> to the WG.=0A= >>> start+24mos - Submit Network Management, Registry and Simple Converge= nce=0A= >>> Layer to IESG=0A= >>> start+24mos - Recharter to accommodate new work items or close=0A= >>> Working Group=0A= >>>=0A= >>>=0A= >>> [1] "BP/LTP deployment on EPOXI spacecraft" [2008],=0A= >>> http://committees.comsoc.org/tccc/ccw/2010/slides/DINET_CCW.pdf=0A= >>> [2] "Proposed Revised Bundle Protocol" [2014],=0A= >>> https://datatracker.ietf.org/doc/draft-burleigh-bpv7/=0A= >>> [3] "Streamlined Bundle Security Protocol Specification" [2014],=0A= >>> https://datatracker.ietf.org/doc/draft-irtf-dtnrg-sbsp/=0A= >>> [4] "Bundle-in-Bundle Encapsulation" [2013],=0A= >>> http://tools.ietf.org/id/draft-irtf-burleigh-bibe=0A= >>> [5] "Delay Tolerant Network Management Protocol" [2013],=0A= >>> http://tools.ietf.org/id/draft-irtf-dtnrg-dtnmp=0A= >>> [6] "Delay-Tolerant Networking Bundle Protocol IANA Registries" [2011],= =0A= >>> https://datatracker.ietf.org/doc/rfc6255/=0A= >>> [7] "Datagram Convergence Layers ..." [2014],=0A= >>> https://datatracker.ietf.org/doc/rfc7122/=0A= >>> [8] "Towards Flexibility and Accuracy in Space DTN Communications",=0A= >>> Bezirgianndia et al, CHANTS 2012,=0A= >>> http://dl.acm.org/citation.cfm?id=3D2505499 [2012]=0A= >>>=0A= >>>=0A= >>>=0A= >>> _______________________________________________=0A= >>> dtn mailing list=0A= >>> dtn@ietf.org=0A= >>> https://www.ietf.org/mailman/listinfo/dtn=0A= >>>=0A= >=0A= > _______________________________________________=0A= > dtn mailing list=0A= > dtn@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/dtn=0A= >=0A= >=0A= =0A= _______________________________________________=0A= dtn mailing list=0A= dtn@ietf.org=0A= https://www.ietf.org/mailman/listinfo/dtn=0A= =0A= _______________________________________________=0A= dtn mailing list=0A= dtn@ietf.org=0A= https://www.ietf.org/mailman/listinfo/dtn=0A= From nobody Wed Jun 18 06:00:37 2014 Return-Path: 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 8F2BA1A01EB for ; Wed, 18 Jun 2014 06:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fkojpGlV877Z for ; Wed, 18 Jun 2014 06:00:30 -0700 (PDT) Received: from ndjsnpf03.ndc.nasa.gov (ndjsnpf03.ndc.nasa.gov [IPv6:2001:4d0:a302:1100::103]) by ietfa.amsl.com (Postfix) with ESMTP id 88D471A01E8 for ; Wed, 18 Jun 2014 06:00:30 -0700 (PDT) Received: from ndjsppt102.ndc.nasa.gov (ndjsppt102.ndc.nasa.gov [198.117.1.196]) by ndjsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 6067C2D809C; Wed, 18 Jun 2014 08:00:29 -0500 (CDT) Received: from NDJSCHT103.ndc.nasa.gov (ndjscht103-pub.ndc.nasa.gov [198.117.1.203]) by ndjsppt102.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id s5ID0TC1015964; Wed, 18 Jun 2014 08:00:29 -0500 Received: from NDJSMBX203.ndc.nasa.gov ([169.254.2.164]) by NDJSCHT103.ndc.nasa.gov ([198.117.1.203]) with mapi id 14.03.0174.001; Wed, 18 Jun 2014 08:00:29 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: Stephen Farrell , "Burleigh, Scott C (JPL-312G)[Jet Propulsion Laboratory]" , "dtn@ietf.org" Thread-Topic: [dtn] Draft Charter Discussion Thread-Index: Ac+GbO3wN7xIp4CqSFeVEjvJc65+vAAK/PwAAAICPoAAMTi4gADF12gAAAUIgYAAAEJQAAAAr4kAAAPqQAAAAHs8gAAVwB4A Date: Wed, 18 Jun 2014 13:00:28 +0000 Message-ID: References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> <2134F8430051B64F815C691A62D983183048B3B6@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983183048DB80@XCH-BLV-512.nw.nos.boeing.com> <53A09F61.2030900@cs.tcd.ie> <2134F8430051B64F815C691A62D983183048DD9A@XCH-BLV-512.nw.nos.boeing.com> <53A0A5B8.1090802@cs.tcd.ie> <53A0C339.2040106@cs.tcd.ie> In-Reply-To: <53A0C339.2040106@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [139.88.242.146] Content-Type: text/plain; charset="us-ascii" Content-ID: <0DD2F2E6FD660F41A0D69861A5B6FA32@mail.nasa.gov> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-06-18_04:2014-06-17,2014-06-18,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/h4DPjiaLrxGTdUidG0sr3XGb3Ug Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 13:00:32 -0000 UAV applications sound good initially, but when you look at the regulations, it is a not starter. You must be in control of the aircraft at all times. There is not a pilot IN the aircraft, but there is one flying it! Air Traffic Control is all about Safety of Flight and Safety of Life. NASA Glenn Research Center is working the communications issues and technologies for integrating Unmanned Air Vehicles (UAVs) in the National Airspace System (NAS). DTN for UAVs - only after you have gained complete confidence in autonomous control for air craft avoidance. That isn't even being worked now. Maybe 50 years from now, but not for a long time. Will On 6/17/14 6:37 PM, "Stephen Farrell" wrote: > > >On 17/06/14 23:23, Burleigh, Scott C (312G) wrote: >> 1. The UAV industry is exploding. Nobody has any idea where the >> limits on applications of UAVs are, but what we do know is that the >> information that controls them is conveyed by radio, which is >> occasionally subject to disruption. Technology that could improve >> the safety and reliability of UAVs, while reducing cost, could find a >> large market. > >Excellent example. Now if we knew that that was a focus of interest >that'd be cool and we could discuss timing and contact requirements, >development environments, tooling etc. and how DTN protocols might >fit with e.g. telemetry/control. (Elwyn could even have fun with >routing - we have an old unfunded proposal along those lines;-) > >I'm not saying its a fatal problem that we only have the already >known use-cases, but new information such as a confirmation that >your good example was real (and were we to have folks who work >in that space involved), could make for a much more compelling >BoF and likely successful WG. > >S. > >_______________________________________________ >dtn mailing list >dtn@ietf.org >https://www.ietf.org/mailman/listinfo/dtn From nobody Wed Jun 18 06:02:50 2014 Return-Path: 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 636BA1A01F3 for ; Wed, 18 Jun 2014 06:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7zvhPLhnPedO for ; Wed, 18 Jun 2014 06:02:41 -0700 (PDT) Received: from mlbxsmtpout01.harris.com (mlbxsmtpout01.harris.com [192.52.234.91]) by ietfa.amsl.com (Postfix) with ESMTP id 27A741A01F7 for ; Wed, 18 Jun 2014 06:02:38 -0700 (PDT) X-AuditID: c034ea5a-f79796d00000184e-c3-53a18dec99f0 Received: from MLBMXCAHT20.cs.myharris.net (Unknown_Domain [10.64.224.22]) by mlbxsmtpout01.harris.com (mail) with SMTP id EF.32.06222.CED81A35; Wed, 18 Jun 2014 09:02:37 -0400 (EDT) Received: from MLBMXUS21.cs.myharris.net ([169.254.2.109]) by MLBMXCAHT20.cs.myharris.net ([fe80::650f:939a:a673:2320%21]) with mapi id 14.02.0318.001; Wed, 18 Jun 2014 09:02:36 -0400 From: "Klish, Cypryan" To: "dtn@ietf.org" Thread-Topic: [dtn] Draft Charter Discussion Thread-Index: Ac+KdvALGRqD+DcFSSyr6f5ak4ImyAAIrrsAABXUntA= Date: Wed, 18 Jun 2014 13:02:36 +0000 Message-ID: References: <53A0BB7A.7060307@cs.tcd.ie> In-Reply-To: <53A0BB7A.7060307@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.224.65] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsXC5fBATPdt78Jgg2PbWC3a17A4MHosWfKT KYAxissmJTUnsyy1SN8ugSvj+qSZLAVfNCp6puxnbWDsVOxi5OSQEDCR2Hj3GQuELSZx4d56 ti5GLg4hgR2MEkenvoNydjNKfP17hb2LkYODTUBLomk/H0iDiICixNc5+1hBbGEBbYm2d3cY IeI6Er+O3IWyrSQu3u8FW8AioCqxYcIVNhCbVyBAYsWj62BxIYF8ibt3GplAbE4BTYm2N7PB ehmBDvp+ag1YnFlAXOLWk/lMEIcKSCzZc54ZwhaVePn4HyuErSBxZ8lWRoh6HYkFuz+xQdja EssWvmaG2CsocXLmE5YJjKKzkIydhaRlFpKWWUhaFjCyrGIUzc1JqijOLSkwMNTLSCwqyizW S87P3cQIjIgDJq+idjAuf2V/iFGAg1GJhzchf0GwEGtiWXFl7iFGCQ5mJRHeY8ULg4V4UxIr q1KL8uOLSnNSiw8xSnOwKInzVi8GqhZITyxJzU5NLUgtgskycXBKNTBOfFV0fs6DN05HCh/q 5nA1JB1N//WkTLRv3eRXz5h+J1tN/vKq+c4CxdkVXU52TyWWO/OcX7JZ39/38LziIwzBf5SC VhwsN1LcumppxidtJb8vDbPPrZGZLDHld8I6RSZZ4foLN9kOX9r83kBp7a8DasFKL98by0mZ WEy48SM0u59xbWDdKY2lSizFGYmGWsxFxYkAXOFMQ4QCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/5RSOpCyqeXlvoKhA95QTyvP58PI Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 13:02:48 -0000 Thanks Stephen! With respect to how the specifications would be used, in general, the organ= ization I work for has capabilities that span most of the use cases that ha= ve been discussed. Mobile tactical edge networks, UAV/airborne sensor netw= orks, space networks, and other mission critical systems that operate over = bandwidth-limited and lossy networks are all relevant for us.=20 In my case specifically, I'm interested in assured delivery of user data ov= er heterogeneous networks that traverse a variety of physical network types= . I'd like to bound data loss and data delivery delay so that customers ca= n be offered an SLA-like agreement that quantifies these and other aspects = of assured delivery. This, I suggest, would involve not only up front char= acterization of DTN behaviors but also a robust performance monitoring capa= bility that could be used to validate fulfillment of the SLA-like agreement= , hence my suggestion that the charter include definition of management cap= abilities within the WG's activity scope.=20 As a future objective, mapping DTN mechanisms (speaking in broad terms here= ) directly to Carrier Ethernet over OTN, optical burst switching or optical= wavelength switching technologies is also relevant for me. This gives ris= e to my interest in layering and making DTN mechanisms portable to differen= t technologies. The benefit of doing would be freeing up bandwidth that is= consumed by protocols at intervening layers - an important consideration i= n the bandwidth/throughput limited networks I typically work with. With respect to RFC 4838,I mentioned it only because it is the one existing= RFC that attempts to address DTN architecture from a system-wide scope. I= perceive the lack of similar but up to date, current document that is more= formal in the sense of being a RA as a critical gap for this effort - acco= rdingly, suggest the need to generate and maintain a DTN RA would be worth = of inclusion in the charter. I agree that re-opening RFC 4838 itself would= not be beneficial - a new RA document that cites RFC 4838 as a historical = reference might be the better way to go. Lastly, any charter that doesn't target interoperability as a WG objective = would be deficient in my view. 'Hope this helps, welcome everyone's feedback. Kip (Cypryan) Klish Sr. Scientist Harris Corporation, Government Communications Systems -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]=20 Sent: Tuesday, June 17, 2014 6:05 PM To: Klish, Cypryan; dtn@ietf.org Subject: Re: [dtn] Draft Charter Discussion Hi Cypryan, Good stuff. Can you say some more about what you'd be using such an set of BP specs for? I think you're the first to suggest re-opening RFC4838 btw. Not sure I see much benefit in that to be honest. And some risk that the valid argument that 4838 is a bit too BP specific might win the day and, from a charter/milestones POV, de-rail the WG. Ta, S. On 17/06/14 22:56, Klish, Cypryan wrote: > As a long time lurker and foremost an implementer and developer of produc= ts suggest a DTN WG charter should address the need to refine and further s= tandardize the fine research done by the DTNRG so that it can be implemente= d by practitioners/organizations with a reasonable expectation that it will= be interoperable, secure, and perform within a range of boundaries and con= straints defined in the standards. >=20 > What does this entail? Suggest some of the following would be relevant : > * Generate/refine a reference architecture that is more up to date,= comprehensive and complete than RFC4838; a model-based RA would be icing o= n the cake > * Better identify known constraints and limitations > * Better define management aspects (e.g. MIBs or YANG models) > * Provide multiple security model options - perhaps like SNMP's US= M and VACM > * Consider layering aspects, particularly layer boundaries, enablin= g independent/portable use of some features (e.g. bundling as a service?) > * Consider defining profiles/modes/classes of operation/RA subsets = traceable to the use cases >=20 > Hope this helps >=20 > Kip >=20 > Cypryan (Kip) T. Klish II > Senior Scientist > Government Communications Systems > HARRIS > AssuredCommunications* > Post Office Box 37 > Melbourne, FL 32902-0037 > * 1 321 727 6348 > * 1 321 298 0492 (mobile) *Note new mobile number* > * cklish@harris.com > Confidentiality Notice: This Email and any attachments may contain materi= al that is "HARRIS Proprietary Information," Confidential, Privileged, and/= or Attorney Work Product for the Sole Use of the Intended Recipient. Any Re= view, Reliance, Distribution, Disclosure, or Forwarding Without Expressed P= ermission is Strictly Prohibited. If you are not the Intended Recipient, Pl= ease Contact the Sender and Delete All Copies Without Reading, Printing, or= Saving in any Manner. -- Thank You. >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > dtn mailing list > dtn@ietf.org > https://www.ietf.org/mailman/listinfo/dtn >=20 From nobody Wed Jun 18 06:18:31 2014 Return-Path: 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 6AB0D1A0213 for ; Wed, 18 Jun 2014 06:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 uN9FRHvtbWpP for ; Wed, 18 Jun 2014 06:18:29 -0700 (PDT) Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [IPv6:2001:4d0:8302:1100::101]) by ietfa.amsl.com (Postfix) with ESMTP id EBE5D1A0217 for ; Wed, 18 Jun 2014 06:18:28 -0700 (PDT) Received: from ndjsppt104.ndc.nasa.gov (ndjsppt104.ndc.nasa.gov [198.117.1.198]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 8EBB526013A; Wed, 18 Jun 2014 08:18:27 -0500 (CDT) Received: from NDJSCHT101.ndc.nasa.gov (ndjscht101-pub.ndc.nasa.gov [198.117.1.201]) by ndjsppt104.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id s5IDIRBR026208; Wed, 18 Jun 2014 08:18:27 -0500 Received: from NDJSMBX203.ndc.nasa.gov ([169.254.2.164]) by NDJSCHT101.ndc.nasa.gov ([198.117.1.201]) with mapi id 14.03.0174.001; Wed, 18 Jun 2014 08:18:26 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: "Templin, Fred L" , "dtn@ietf.org" Thread-Topic: [dtn] rfc5050(bis) proposed revisions Thread-Index: AQHPivfJ2O/x4+1RG0Stzkfn5ML73A== Date: Wed, 18 Jun 2014 13:18:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [139.88.242.146] Content-Type: text/plain; charset="us-ascii" Content-ID: <73F9A9C4B9639A49B8CEB4554F2D5AA9@mail.nasa.gov> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-06-18_05:2014-06-17,2014-06-18,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/oPXoR5k56WNph-Gyd41Shw_woMg Subject: Re: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 13:18:30 -0000 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" 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 From nobody Wed Jun 18 07:04:18 2014 Return-Path: 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 AEA121A0257 for ; Wed, 18 Jun 2014 07:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 JwpBuQ2OjoM0 for ; Wed, 18 Jun 2014 07:04:12 -0700 (PDT) Received: from b.b.painless.aa.net.uk (b.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B10601A0212 for ; Wed, 18 Jun 2014 07:03:07 -0700 (PDT) Received: from mightyatom.folly.org.uk ([81.187.254.250]) by b.painless.aa.net.uk with esmtp (Exim 4.72) (envelope-from ) id 1WxGS2-0002lg-Re; Wed, 18 Jun 2014 15:03:02 +0100 From: Elwyn Davies To: "Ivancic, William D. (GRC-RHN0)" In-Reply-To: References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> <2134F8430051B64F815C691A62D983183048B3B6@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983183048DB80@XCH-BLV-512.nw.nos.boeing.com> <53A09F61.2030900@cs.tcd.ie> <2134F8430051B64F815C691A62D983183048DD9A@XCH-BLV-512.nw.nos.boeing.com> <53A0A5B8.1090802@cs.tcd.ie> <53A0C339.2040106@cs.tcd.ie> Content-Type: text/plain Organization: Folly Consulting Date: Wed, 18 Jun 2014 15:02:57 +0100 Message-Id: <1403100177.2995.5059.camel@mightyatom> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/aF8Sy8rhPl6m66m0MJEA2rTWBak Cc: "Burleigh, Scott C \(JPL-312G\)\[Jet Propulsion Laboratory\]" , "dtn@ietf.org" , Stephen Farrell Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 14:04:15 -0000 One of the best worked out proposals for DTN routing that I know of is in the UAV space [1]. The proposal is intended for passing reconnaissance sensor data back through a swarm and is a geographic system that piggy backs on the expected GPS system in a UAV (clearly realistic unlike many other proposals where GPS is a must have). My instinct was that this system had actually been implemented and trialled - based entirely on gut feel and the way in which the expected practicalities were addressed. Using it directly for control is obviously another matter, but for data recovery it looked good. Regards, Elwyn [1] A framework for performance analysis of geographic delay-tolerant routing Erik Kuiper, Simin Nadjm-Tehrani, Di Yuan (2012) EURASIP Journal on Wireless Communications and Networking 2012 (1) p. 184 http://jwcn.eurasipjournals.com/content/2012/1/184 On Wed, 2014-06-18 at 13:00 +0000, Ivancic, William D. (GRC-RHN0) wrote: > UAV applications sound good initially, but when you look at the > regulations, it is a not starter. You must be in control of the aircraft > at all times. There is not a pilot IN the aircraft, but there is one > flying it! Air Traffic Control is all about Safety of Flight and Safety > of Life. > > NASA Glenn Research Center is working the communications issues and > technologies for integrating Unmanned Air Vehicles (UAVs) in the National > Airspace System (NAS). > > DTN for UAVs - only after you have gained complete confidence in > autonomous control for air craft avoidance. That isn't even being worked > now. Maybe 50 years from now, but not for a long time. > > Will > > > > > > On 6/17/14 6:37 PM, "Stephen Farrell" wrote: > > > > > > >On 17/06/14 23:23, Burleigh, Scott C (312G) wrote: > >> 1. The UAV industry is exploding. Nobody has any idea where the > >> limits on applications of UAVs are, but what we do know is that the > >> information that controls them is conveyed by radio, which is > >> occasionally subject to disruption. Technology that could improve > >> the safety and reliability of UAVs, while reducing cost, could find a > >> large market. > > > >Excellent example. Now if we knew that that was a focus of interest > >that'd be cool and we could discuss timing and contact requirements, > >development environments, tooling etc. and how DTN protocols might > >fit with e.g. telemetry/control. (Elwyn could even have fun with > >routing - we have an old unfunded proposal along those lines;-) > > > >I'm not saying its a fatal problem that we only have the already > >known use-cases, but new information such as a confirmation that > >your good example was real (and were we to have folks who work > >in that space involved), could make for a much more compelling > >BoF and likely successful WG. > > > >S. > > > >_______________________________________________ > >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 From nobody Wed Jun 18 08:04:38 2014 Return-Path: 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 28A261A0021 for ; Wed, 18 Jun 2014 08:04:36 -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 cplguBSbKyw3 for ; Wed, 18 Jun 2014 08:04:31 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB7641A005B for ; Wed, 18 Jun 2014 08:04:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s5IF4VaD030617; Wed, 18 Jun 2014 08:04:31 -0700 Received: from XCH-PHX-507.sw.nos.boeing.com (xch-phx-507.sw.nos.boeing.com [137.136.239.65]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s5IF4Pbx030503 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 18 Jun 2014 08:04:27 -0700 Received: from XCH-BLV-512.nw.nos.boeing.com ([169.254.12.74]) by XCH-PHX-507.sw.nos.boeing.com ([169.254.2.39]) with mapi id 14.03.0181.006; Wed, 18 Jun 2014 08:04:26 -0700 From: "Templin, Fred L" To: "Ivancic, William D. (GRC-RHN0)" , "Stephen Farrell" , "Burleigh, Scott C (JPL-312G)[Jet Propulsion Laboratory]" , "dtn@ietf.org" Thread-Topic: [dtn] Draft Charter Discussion Thread-Index: Ac+GbO3wN7xIp4CqSFeVEjvJc65+vAAK/PwAAAICPoAAMTi4gADF12gAAAUIgYAAAEJQAAAAr4kAAAPqQAAAAHs8gAAVwB4AAAE+hfA= Date: Wed, 18 Jun 2014 15:04:26 +0000 Message-ID: <2134F8430051B64F815C691A62D983183048EA82@XCH-BLV-512.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> <2134F8430051B64F815C691A62D983183048B3B6@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983183048DB80@XCH-BLV-512.nw.nos.boeing.com> <53A09F61.2030900@cs.tcd.ie> <2134F8430051B64F815C691A62D983183048DD9A@XCH-BLV-512.nw.nos.boeing.com> <53A0A5B8.1090802@cs.tcd.ie> <53A0C339.2040106@cs.tcd.ie> In-Reply-To: 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/E-AF70xLJWmIxa4wKLRZxZiLURU Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 15:04:36 -0000 Hi Will, > -----Original Message----- > From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of Ivancic, William D. = (GRC-RHN0) > Sent: Wednesday, June 18, 2014 6:00 AM > To: Stephen Farrell; Burleigh, Scott C (JPL-312G)[Jet Propulsion Laborato= ry]; dtn@ietf.org > Subject: Re: [dtn] Draft Charter Discussion >=20 > UAV applications sound good initially, but when you look at the > regulations, it is a not starter. You must be in control of the aircraft > at all times. There is not a pilot IN the aircraft, but there is one > flying it! Air Traffic Control is all about Safety of Flight and Safety > of Life. A recent NASA solicitation is asking for proposals for supporting single-pilot operations on commercial airplanes. If a single pilot becomes incapacitated, and if there is no ground controller, the plane becomes zero-pilot and needs to rely fully on automation. Remote UAV mission scenarios will eventually rely fully on automation. The US government has also posted the FAA Modernization and Reform Act of 2012 which calls for integration of UAVs into the national air space within this decade. Plus, we already have the google driverless car on the road today. Fully autonomous operation is coming. Technology will continue to move forward and regulations will change. Thanks - Fred fred.l.templin@boeing.com > NASA Glenn Research Center is working the communications issues and > technologies for integrating Unmanned Air Vehicles (UAVs) in the National > Airspace System (NAS). >=20 > DTN for UAVs - only after you have gained complete confidence in > autonomous control for air craft avoidance. That isn't even being worked > now. Maybe 50 years from now, but not for a long time. >=20 > Will >=20 >=20 >=20 >=20 >=20 > On 6/17/14 6:37 PM, "Stephen Farrell" wrote: >=20 > > > > > >On 17/06/14 23:23, Burleigh, Scott C (312G) wrote: > >> 1. The UAV industry is exploding. Nobody has any idea where the > >> limits on applications of UAVs are, but what we do know is that the > >> information that controls them is conveyed by radio, which is > >> occasionally subject to disruption. Technology that could improve > >> the safety and reliability of UAVs, while reducing cost, could find a > >> large market. > > > >Excellent example. Now if we knew that that was a focus of interest > >that'd be cool and we could discuss timing and contact requirements, > >development environments, tooling etc. and how DTN protocols might > >fit with e.g. telemetry/control. (Elwyn could even have fun with > >routing - we have an old unfunded proposal along those lines;-) > > > >I'm not saying its a fatal problem that we only have the already > >known use-cases, but new information such as a confirmation that > >your good example was real (and were we to have folks who work > >in that space involved), could make for a much more compelling > >BoF and likely successful WG. > > > >S. > > > >_______________________________________________ > >dtn mailing list > >dtn@ietf.org > >https://www.ietf.org/mailman/listinfo/dtn >=20 > _______________________________________________ > dtn mailing list > dtn@ietf.org > https://www.ietf.org/mailman/listinfo/dtn From nobody Wed Jun 18 08:32:59 2014 Return-Path: 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 15FAC1A0049 for ; Wed, 18 Jun 2014 08:32:58 -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 mBPX2MvdIF60 for ; Wed, 18 Jun 2014 08:32:56 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A4841A005B for ; Wed, 18 Jun 2014 08:32:56 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp01.jpl.nasa.gov [128.149.137.148]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s5IFWNfX027357 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO) for ; Wed, 18 Jun 2014 08:32:25 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.217]) by ap-ehub-sp01.RES.AD.JPL ([169.254.3.182]) with mapi id 14.03.0174.001; Wed, 18 Jun 2014 08:32:55 -0700 From: "Burleigh, Scott C (312G)" To: "dtn@ietf.org" Thread-Topic: [dtn] Draft Charter Discussion Thread-Index: Ac+GbO3wN7xIp4CqSFeVEjvJc65+vAAPLd8AAAy+SjAAJnyrgAC3CG0QABPXfIAADpF2cP//kwMAgABi+uD//8AxgIAA8QsAgABUFwA= Date: Wed, 18 Jun 2014 15:32:54 +0000 Message-ID: References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> <2134F8430051B64F815C691A62D983183048B3B6@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983183048DB80@XCH-BLV-512.nw.nos.boeing.com> <53A09F61.2030900@cs.tcd.ie> <2134F8430051B64F815C691A62D983183048DD9A@XCH-BLV-512.nw.nos.boeing.com> <53A0A5B8.1090802@cs.tcd.ie> <53A0C339.2040106@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.26] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/WJk25S7YsvQETHha9X8NOZmIDPw Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 15:32:58 -0000 Will, Fred is way more knowledgeable about UAVs than I am, so I'm happy to = go with his assessment. But in any case I don't think I said anything abou= t DTN being great only for pilot-less UAV operations. UAV operations, pilo= ted or not, rely on communications. Technology that can improve communicat= ions with UAVs makes them safer and more reliable. As I understand it, if = communication with a remotely piloted UAV is interrupted for any reason, th= e vehicle has to go into some sort of safe autonomous operational mode unti= l communication is restored; the more quickly and reliably that can happen = -- that is, the better the disruption can be handled -- the sooner the airc= raft can resume normal operations. Scott -----Original Message----- From: Ivancic, William D. (GRC-RHN0) [mailto:william.d.ivancic@nasa.gov]=20 Sent: Wednesday, June 18, 2014 6:00 AM To: Stephen Farrell; Burleigh, Scott C (312G); dtn@ietf.org Subject: Re: [dtn] Draft Charter Discussion UAV applications sound good initially, but when you look at the regulations= , it is a not starter. You must be in control of the aircraft at all times= . There is not a pilot IN the aircraft, but there is one flying it! Air T= raffic Control is all about Safety of Flight and Safety of Life. NASA Glenn Research Center is working the communications issues and technol= ogies for integrating Unmanned Air Vehicles (UAVs) in the National Airspace= System (NAS). DTN for UAVs - only after you have gained complete confidence in autonomous= control for air craft avoidance. That isn't even being worked now. Maybe= 50 years from now, but not for a long time. Will On 6/17/14 6:37 PM, "Stephen Farrell" wrote: > > >On 17/06/14 23:23, Burleigh, Scott C (312G) wrote: >> 1. The UAV industry is exploding. Nobody has any idea where the=20 >> limits on applications of UAVs are, but what we do know is that the=20 >> information that controls them is conveyed by radio, which is=20 >> occasionally subject to disruption. Technology that could improve=20 >> the safety and reliability of UAVs, while reducing cost, could find a=20 >> large market. > >Excellent example. Now if we knew that that was a focus of interest=20 >that'd be cool and we could discuss timing and contact requirements,=20 >development environments, tooling etc. and how DTN protocols might fit=20 >with e.g. telemetry/control. (Elwyn could even have fun with routing -=20 >we have an old unfunded proposal along those lines;-) > >I'm not saying its a fatal problem that we only have the already known=20 >use-cases, but new information such as a confirmation that your good=20 >example was real (and were we to have folks who work in that space=20 >involved), could make for a much more compelling BoF and likely=20 >successful WG. > >S. > >_______________________________________________ >dtn mailing list >dtn@ietf.org >https://www.ietf.org/mailman/listinfo/dtn From nobody Wed Jun 18 10:17:36 2014 Return-Path: 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 C33921A0283 for ; Wed, 18 Jun 2014 10:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.671 X-Spam-Level: X-Spam-Status: No, score=-0.671 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=no 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 G9-NB4hBOLZ3 for ; Wed, 18 Jun 2014 10:11:00 -0700 (PDT) Received: from mail.arces.unibo.it (mail.arces.unibo.it [137.204.143.6]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 853741A004A for ; Wed, 18 Jun 2014 10:11:00 -0700 (PDT) Received: from webmail.arces.unibo.it (web.arces.unibo.it [137.204.143.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.arces.unibo.it (Postfix) with ESMTP id 1708C412D77B for ; Wed, 18 Jun 2014 19:10:52 +0200 (CEST) MIME-Version: 1.0 Date: Wed, 18 Jun 2014 19:10:51 +0200 From: ccaini To: In-Reply-To: References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> <2134F8430051B64F815C691A62D983183048B3B6@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983183048DB80@XCH-BLV-512.nw.nos.boeing.com> <53A09F61.2030900@cs.tcd.ie> <2134F8430051B64F815C691A62D983183048DD9A@XCH-BLV-512.nw.nos.boeing.com> <53A0A5B8.1090802@cs.tcd.ie> <53A0C339.2040106@cs.tcd.ie> Message-ID: X-Sender: ccaini@arces.unibo.it User-Agent: RoundCube Webmail/0.2 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 X-Arces-MailScanner-Information: Please contact the ISP for more information X-Arces-MailScanner-ID: 1708C412D77B.65337 X-Arces-MailScanner: Found to be clean X-Arces-MailScanner-From: ccaini@arces.unibo.it Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/TU-OflSjsRXlLLWUqUOt8pKvjNs X-Mailman-Approved-At: Wed, 18 Jun 2014 10:17:32 -0700 Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 17:11:06 -0000 Dear All, I am not a UAV expert, but I have read some papers about DTN application to them and I am also aware of some research on this field. UAVs may, or may not, need a continous channel to be remotely controlled. In fact they can also fly in a completely autonomous way (I have seen some small UAVs flying this way) with the flight route precharged before launching. Of course, present regulations may or may not allow this, depending on countries. Anyway, the communication channel used to pilot them, if any, as well as being subject to possible disruption, as stated by Scott, does not need to be the same used for downloading data (e.g. pictures). The former can be a continous channel with scarce bandwidth but large coverage (e.g. that provided by a GEO satellite, or by a global LEO constallation, as Iridium), the latter can be a short range high bandwith link, characterized by an intermittent connectivity. For this link DTN seems of course the ideal choice. Moreover, communication can be integrated with flying control, and a UAV during the download of pictures to an earth station can keep hoovering or flying around until the reception of a BP custody acceptance from the node on the ground. Only after this reception the UAV is allowed to restart is normal flight. The same of course can be done with whatever DTN mule, not just UAVs. Not sure but maybe it was done with helicopters working as data mule in N4C. Maybe Stephen Farrell can confirm. Yours, Carlo Caini On Wed, 18 Jun 2014 15:32:54 +0000, "Burleigh, Scott C (312G)" wrote: > Will, Fred is way more knowledgeable about UAVs than I am, so I'm happy to > go with his assessment. But in any case I don't think I said anything > about DTN being great only for pilot-less UAV operations. UAV operations, > piloted or not, rely on communications. Technology that can improve > communications with UAVs makes them safer and more reliable. As I > understand it, if communication with a remotely piloted UAV is interrupted > for any reason, the vehicle has to go into some sort of safe autonomous > operational mode until communication is restored; the more quickly and > reliably that can happen -- that is, the better the disruption can be > handled -- the sooner the aircraft can resume normal operations. > > Scott > > -----Original Message----- > From: Ivancic, William D. (GRC-RHN0) [mailto:william.d.ivancic@nasa.gov] > Sent: Wednesday, June 18, 2014 6:00 AM > To: Stephen Farrell; Burleigh, Scott C (312G); dtn@ietf.org > Subject: Re: [dtn] Draft Charter Discussion > > UAV applications sound good initially, but when you look at the > regulations, it is a not starter. You must be in control of the aircraft > at all times. There is not a pilot IN the aircraft, but there is one > flying it! Air Traffic Control is all about Safety of Flight and Safety of > Life. > > NASA Glenn Research Center is working the communications issues and > technologies for integrating Unmanned Air Vehicles (UAVs) in the National > Airspace System (NAS). > > DTN for UAVs - only after you have gained complete confidence in > autonomous control for air craft avoidance. That isn't even being worked > now. Maybe 50 years from now, but not for a long time. > > Will > > > > > > On 6/17/14 6:37 PM, "Stephen Farrell" wrote: > >> >> >>On 17/06/14 23:23, Burleigh, Scott C (312G) wrote: >>> 1. The UAV industry is exploding. Nobody has any idea where the >>> limits on applications of UAVs are, but what we do know is that the >>> information that controls them is conveyed by radio, which is >>> occasionally subject to disruption. Technology that could improve >>> the safety and reliability of UAVs, while reducing cost, could find a >>> large market. >> >>Excellent example. Now if we knew that that was a focus of interest >>that'd be cool and we could discuss timing and contact requirements, >>development environments, tooling etc. and how DTN protocols might fit >>with e.g. telemetry/control. (Elwyn could even have fun with routing - >>we have an old unfunded proposal along those lines;-) >> >>I'm not saying its a fatal problem that we only have the already known >>use-cases, but new information such as a confirmation that your good >>example was real (and were we to have folks who work in that space >>involved), could make for a much more compelling BoF and likely >>successful WG. >> >>S. >> >>_______________________________________________ >>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 From nobody Wed Jun 18 10:39:28 2014 Return-Path: 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 140CE1A00D5 for ; Wed, 18 Jun 2014 10:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tdUGOAADgEYo for ; Wed, 18 Jun 2014 10:39:23 -0700 (PDT) Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [IPv6:2001:4d0:a302:1100::102]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEF61A02A5 for ; Wed, 18 Jun 2014 10:39:23 -0700 (PDT) Received: from ndjsppt103.ndc.nasa.gov (ndjsppt103.ndc.nasa.gov [198.117.1.197]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id C8590A80AC; Wed, 18 Jun 2014 12:39:22 -0500 (CDT) Received: from NDJSCHT111.ndc.nasa.gov (ndjscht111-pub.ndc.nasa.gov [198.117.1.211]) by ndjsppt103.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id s5IHdMwI029824; Wed, 18 Jun 2014 12:39:22 -0500 Received: from NDJSMBX203.ndc.nasa.gov ([169.254.2.164]) by NDJSCHT111.ndc.nasa.gov ([198.117.1.211]) with mapi id 14.03.0174.001; Wed, 18 Jun 2014 12:39:22 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: ccaini , "dtn@ietf.org" Thread-Topic: [dtn] Draft Charter Discussion Thread-Index: Ac+GbO3wN7xIp4CqSFeVEjvJc65+vAAK/PwAAAICPoAAMTi4gADF12gAAAUIgYAAAEJQAAAAr4kAAAPqQAAAAHs8gAAVwB4AAA20CAAAA2u+gP//xO4A Date: Wed, 18 Jun 2014 17:39:21 +0000 Message-ID: References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> <2134F8430051B64F815C691A62D983183048B3B6@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983183048DB80@XCH-BLV-512.nw.nos.boeing.com> <53A09F61.2030900@cs.tcd.ie> <2134F8430051B64F815C691A62D983183048DD9A@XCH-BLV-512.nw.nos.boeing.com> <53A0A5B8.1090802@cs.tcd.ie> <53A0C339.2040106@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [139.88.242.146] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-06-18_06:2014-06-17,2014-06-18,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/zytkLW40pAqgrXJI68uMpMeFWKg Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 17:39:26 -0000 Yes for payload data one could use DTN if it fit the deployment scenario. I say understand the deployment scenario because we looked at DTN and mobile-ip for the NASA Global Hawk flying over the poles. DTN provide no value because you were connect up to the 70+ degrees latitude, then disconnected until the return at which point you were connected again. The network was single-hop. LEO spacecraft have similar. Yes, you can use DTN, but there are other solutions that may be simpler. The group should beware of what we state the use cases are. At this point in time, if one were to indicate, without specifying payload data, that DTN could be used for UAVs, people working these policy programs and trying to integrate UAVs into the National and Global Airspace will probably not be happy. They have enough issues and hurdles without someone thinking large cargo UAVs are going to fly into San Diego with disrupted communications (FYI, one can literally walk from San Diego airport to the center of downtown San Diego in 20 to 30 minutes. That is how close those large aircraft fly to downtown.) Will ****************************** On 6/18/14 1:10 PM, "ccaini" wrote: >Dear All, > I am not a UAV expert, but I have read some papers about DTN application >to them and I am also aware of some research on this field. >UAVs may, or may not, need a continous channel to be remotely controlled. >In fact they can also fly in a completely autonomous way (I have seen some >small UAVs flying this way) with the flight route precharged before >launching. Of course, present regulations may or may not allow this, >depending on countries. Anyway, the communication channel used to pilot >them, if any, as well as being subject to possible disruption, as stated >by >Scott, does not need to be the same used for downloading data (e.g. >pictures). The former can be a continous channel with scarce bandwidth but >large coverage (e.g. that provided by a GEO satellite, or by a global LEO >constallation, as Iridium), the latter can be a short range high bandwith >link, characterized by an intermittent connectivity. For this link DTN >seems of course the ideal choice. Moreover, communication can be >integrated >with flying control, and a UAV during the download of pictures to an earth >station can keep hoovering or flying around until the reception of a BP >custody acceptance from the node on the ground. Only after this reception >the UAV is allowed to restart is normal flight. The same of course can be >done with whatever DTN mule, not just UAVs. Not sure but maybe it was done >with helicopters working as data mule in N4C. Maybe Stephen Farrell can >confirm. >Yours, > Carlo Caini > >On Wed, 18 Jun 2014 15:32:54 +0000, "Burleigh, Scott C (312G)" > wrote: >> Will, Fred is way more knowledgeable about UAVs than I am, so I'm happy >to >> go with his assessment. But in any case I don't think I said anything >> about DTN being great only for pilot-less UAV operations. UAV >operations, >> piloted or not, rely on communications. Technology that can improve >> communications with UAVs makes them safer and more reliable. As I >> understand it, if communication with a remotely piloted UAV is >interrupted >> for any reason, the vehicle has to go into some sort of safe autonomous >> operational mode until communication is restored; the more quickly and >> reliably that can happen -- that is, the better the disruption can be >> handled -- the sooner the aircraft can resume normal operations. >>=20 >> Scott >>=20 >> -----Original Message----- >> From: Ivancic, William D. (GRC-RHN0) [mailto:william.d.ivancic@nasa.gov] > >> Sent: Wednesday, June 18, 2014 6:00 AM >> To: Stephen Farrell; Burleigh, Scott C (312G); dtn@ietf.org >> Subject: Re: [dtn] Draft Charter Discussion >>=20 >> UAV applications sound good initially, but when you look at the >> regulations, it is a not starter. You must be in control of the >aircraft >> at all times. There is not a pilot IN the aircraft, but there is one >> flying it! Air Traffic Control is all about Safety of Flight and Safety >of >> Life. >>=20 >> NASA Glenn Research Center is working the communications issues and >> technologies for integrating Unmanned Air Vehicles (UAVs) in the >National >> Airspace System (NAS). >>=20 >> DTN for UAVs - only after you have gained complete confidence in >> autonomous control for air craft avoidance. That isn't even being >worked >> now. Maybe 50 years from now, but not for a long time. >>=20 >> Will >>=20 >>=20 >>=20 >>=20 >>=20 >> On 6/17/14 6:37 PM, "Stephen Farrell" wrote: >>=20 >>> >>> >>>On 17/06/14 23:23, Burleigh, Scott C (312G) wrote: >>>> 1. The UAV industry is exploding. Nobody has any idea where the >>>> limits on applications of UAVs are, but what we do know is that the >>>> information that controls them is conveyed by radio, which is >>>> occasionally subject to disruption. Technology that could improve >>>> the safety and reliability of UAVs, while reducing cost, could find a >>>> large market. >>> >>>Excellent example. Now if we knew that that was a focus of interest >>>that'd be cool and we could discuss timing and contact requirements, >>>development environments, tooling etc. and how DTN protocols might fit >>>with e.g. telemetry/control. (Elwyn could even have fun with routing - >>>we have an old unfunded proposal along those lines;-) >>> >>>I'm not saying its a fatal problem that we only have the already known >>>use-cases, but new information such as a confirmation that your good >>>example was real (and were we to have folks who work in that space >>>involved), could make for a much more compelling BoF and likely >>>successful WG. >>> >>>S. >>> >>>_______________________________________________ >>>dtn mailing list >>>dtn@ietf.org >>>https://www.ietf.org/mailman/listinfo/dtn >>=20 >>=20 >> _______________________________________________ >> 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 From nobody Wed Jun 18 11:00:39 2014 Return-Path: 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 A569D1A0280 for ; Wed, 18 Jun 2014 11:00:31 -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 YjrO28bX9E-9 for ; Wed, 18 Jun 2014 11:00:27 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F29621A0102 for ; Wed, 18 Jun 2014 11:00:26 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp01.jpl.nasa.gov [128.149.137.148]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s5IHxpra027336 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO) for ; Wed, 18 Jun 2014 10:59:56 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.217]) by ap-ehub-sp01.RES.AD.JPL ([169.254.3.182]) with mapi id 14.03.0174.001; Wed, 18 Jun 2014 11:00:23 -0700 From: "Burleigh, Scott C (312G)" To: "dtn@ietf.org" Thread-Topic: [dtn] Draft Charter Discussion Thread-Index: Ac+GbO3wN7xIp4CqSFeVEjvJc65+vAAPLd8AAAy+SjAAJnyrgAC3CG0QABPXfIAADpF2cP//kwMAgABi+uD//8AxgP//Tofg Date: Wed, 18 Jun 2014 18:00:22 +0000 Message-ID: References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> <2134F8430051B64F815C691A62D983183048B3B6@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983183048DB80@XCH-BLV-512.nw.nos.boeing.com> <53A09F61.2030900@cs.tcd.ie> <2134F8430051B64F815C691A62D983183048DD9A@XCH-BLV-512.nw.nos.boeing.com> <53A0A5B8.1090802@cs.tcd.ie> <53A0C339.2040106@cs.tcd.ie> In-Reply-To: <53A0C339.2040106@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.26] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/HRT5e2ZgqtZPBUA5nZI2N1NcHWw Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 18:00:32 -0000 Hi, Stephen. I figure you're not saying that Boeing (or anybody else) has = got to disclose proprietary information or forego business opportunities in= order to make the BoF more compelling and the WG more successful. What yo= u're really telling us is that it would be advantageous if the WG were simp= ly able to focus on some use case that is not an insignificant niche or a p= urely academic problem, correct? Not necessarily the specific use case(s) = that interest Boeing, that Fred can't discuss, but at least something with = potentially significant impact. In that context, maybe it would be helpful to look at a project I've been n= oodling with for the past few years. "Ring Road" would be a DTN-based comm= unication satellite network aimed (originally) at provided extremely low-co= st -- but high-latency -- network communication service to communities that= lack Internet access, typically because they're geographically isolated, e= conomically disadvantaged, and/or temporarily devastated by natural or poli= tical disaster. There's a summary presentation at http://ipnsig.org/wp-con= tent/uploads/2014/02/Ring-Road-applicationsRev1.pdf which I would be more t= han happy to discuss on this list or privately, with whoever is interested. I think that project constitutes the sort of focus we might be looking for,= as it's not a niche use case or a purely academic problem. Potential user= s would be in the hundreds of thousands, perhaps millions, so it's a sort o= f forcing function for scalability. It's an open architecture, so standard= ization is necessary. It's entirely deployable using DTN implementation so= ftware that can be downloaded off the Internet, with very little additional= development. A lot of the configuration details have already been worked = out, at least to the level of back-of-the-envelope numbers. And deployment of this sort of capability is entirely plausible. We've bee= n in conversations with the Media Development Investment Fund about infusin= g this architecture into a second stage of their Outernet project, which in= itially is aiming only at downloading content to subscribers but which may = want to expand into bidirectional networking once their constellation is de= ployed. Beyond this, though, it would constitute an inexpensive way for an= y large multinational entity -- a business, a group of collaborating NGOs -= - to construct its own entirely private worldwide communication network. It= could easily interconnect autonomous undersea vehicles in mid-ocean with o= perators in Tennessee or Latvia, using BP end-to-end. Alternatively, by so= mewhat increasing the size (and cost) of the satellites and using more powe= rful radios we could evolve it into a very low-cost, high-latency bulk data= transfer infrastructure, which would be quite good for large-scale multime= dia distribution. Lots of possibilities, I think. Scott -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]=20 Sent: Tuesday, June 17, 2014 3:38 PM To: Burleigh, Scott C (312G); dtn@ietf.org Subject: Re: [dtn] Draft Charter Discussion On 17/06/14 23:23, Burleigh, Scott C (312G) wrote: > 1. The UAV industry is exploding. Nobody has any idea where the=20 > limits on applications of UAVs are, but what we do know is that the=20 > information that controls them is conveyed by radio, which is=20 > occasionally subject to disruption. Technology that could improve the=20 > safety and reliability of UAVs, while reducing cost, could find a=20 > large market. Excellent example. Now if we knew that that was a focus of interest that'd = be cool and we could discuss timing and contact requirements, development e= nvironments, tooling etc. and how DTN protocols might fit with e.g. telemet= ry/control. (Elwyn could even have fun with routing - we have an old unfund= ed proposal along those lines;-) I'm not saying its a fatal problem that we only have the already known use-= cases, but new information such as a confirmation that your good example wa= s real (and were we to have folks who work in that space involved), could m= ake for a much more compelling BoF and likely successful WG. S. From nobody Wed Jun 18 11:22:15 2014 Return-Path: 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 359F11A0303 for ; Wed, 18 Jun 2014 11:22:13 -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 ncFgRme8CG_7 for ; Wed, 18 Jun 2014 11:22:11 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52AC51A0300 for ; Wed, 18 Jun 2014 11:22:11 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp01.jpl.nasa.gov [128.149.137.148]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s5IIMA2H018846 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO) for ; Wed, 18 Jun 2014 11:22:10 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.217]) by ap-ehub-sp01.RES.AD.JPL ([169.254.3.182]) with mapi id 14.03.0174.001; Wed, 18 Jun 2014 11:22:10 -0700 From: "Burleigh, Scott C (312G)" To: "dtn@ietf.org" Thread-Topic: [dtn] Draft Charter Discussion Thread-Index: Ac+GbO3wN7xIp4CqSFeVEjvJc65+vAAPLd8AAAy+SjAAJnyrgAC3CG0QABPXfIAADpF2cP//kwMAgABi+uD//8AxgP//Tofg//56BIA= Date: Wed, 18 Jun 2014 18:22:09 +0000 Message-ID: References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> <2134F8430051B64F815C691A62D983183048B3B6@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983183048DB80@XCH-BLV-512.nw.nos.boeing.com> <53A09F61.2030900@cs.tcd.ie> <2134F8430051B64F815C691A62D983183048DD9A@XCH-BLV-512.nw.nos.boeing.com> <53A0A5B8.1090802@cs.tcd.ie> <53A0C339.2040106@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.26] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/bMpvX2t4ck1zkO-b_OrlfWvIf5k Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 18:22:13 -0000 Sorry, I should have noted before that Ed Birrane, Aaron Rogers, and Chris = Krupiarz of the Johns Hopkins University Applied Physics Laboratory made ma= jor contributions to the "Ring Road" concept. Scott -----Original Message----- From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of Burleigh, Scott C (312= G) Sent: Wednesday, June 18, 2014 11:00 AM To: dtn@ietf.org Subject: Re: [dtn] Draft Charter Discussion Hi, Stephen. I figure you're not saying that Boeing (or anybody else) has = got to disclose proprietary information or forego business opportunities in= order to make the BoF more compelling and the WG more successful. What yo= u're really telling us is that it would be advantageous if the WG were simp= ly able to focus on some use case that is not an insignificant niche or a p= urely academic problem, correct? Not necessarily the specific use case(s) = that interest Boeing, that Fred can't discuss, but at least something with = potentially significant impact. In that context, maybe it would be helpful to look at a project I've been n= oodling with for the past few years. "Ring Road" would be a DTN-based comm= unication satellite network aimed (originally) at provided extremely low-co= st -- but high-latency -- network communication service to communities that= lack Internet access, typically because they're geographically isolated, e= conomically disadvantaged, and/or temporarily devastated by natural or poli= tical disaster. There's a summary presentation at http://ipnsig.org/wp-con= tent/uploads/2014/02/Ring-Road-applicationsRev1.pdf which I would be more t= han happy to discuss on this list or privately, with whoever is interested. I think that project constitutes the sort of focus we might be looking for,= as it's not a niche use case or a purely academic problem. Potential user= s would be in the hundreds of thousands, perhaps millions, so it's a sort o= f forcing function for scalability. It's an open architecture, so standard= ization is necessary. It's entirely deployable using DTN implementation so= ftware that can be downloaded off the Internet, with very little additional= development. A lot of the configuration details have already been worked = out, at least to the level of back-of-the-envelope numbers. And deployment of this sort of capability is entirely plausible. We've bee= n in conversations with the Media Development Investment Fund about infusin= g this architecture into a second stage of their Outernet project, which in= itially is aiming only at downloading content to subscribers but which may = want to expand into bidirectional networking once their constellation is de= ployed. Beyond this, though, it would constitute an inexpensive way for an= y large multinational entity -- a business, a group of collaborating NGOs -= - to construct its own entirely private worldwide communication network. It= could easily interconnect autonomous undersea vehicles in mid-ocean with o= perators in Tennessee or Latvia, using BP end-to-end. Alternatively, by so= mewhat increasing the size (and cost) of the satellites and using more powe= rful radios we could evolve it into a very low-cost, high-latency bulk data= transfer infrastructure, which would be quite good for large-scale multime= dia distribution. Lots of possibilities, I think. Scott -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] Sent: Tuesday, June 17, 2014 3:38 PM To: Burleigh, Scott C (312G); dtn@ietf.org Subject: Re: [dtn] Draft Charter Discussion On 17/06/14 23:23, Burleigh, Scott C (312G) wrote: > 1. The UAV industry is exploding. Nobody has any idea where the=20 > limits on applications of UAVs are, but what we do know is that the=20 > information that controls them is conveyed by radio, which is=20 > occasionally subject to disruption. Technology that could improve the=20 > safety and reliability of UAVs, while reducing cost, could find a=20 > large market. Excellent example. Now if we knew that that was a focus of interest that'd = be cool and we could discuss timing and contact requirements, development e= nvironments, tooling etc. and how DTN protocols might fit with e.g. telemet= ry/control. (Elwyn could even have fun with routing - we have an old unfund= ed proposal along those lines;-) I'm not saying its a fatal problem that we only have the already known use-= cases, but new information such as a confirmation that your good example wa= s real (and were we to have folks who work in that space involved), could m= ake for a much more compelling BoF and likely successful WG. S. _______________________________________________ dtn mailing list dtn@ietf.org https://www.ietf.org/mailman/listinfo/dtn From nobody Wed Jun 18 13:05:19 2014 Return-Path: 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 717D81A02F7 for ; Wed, 18 Jun 2014 13:05:16 -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=unavailable 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 NprJtzFYsHnH for ; Wed, 18 Jun 2014 13:05:04 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 266D11A0283 for ; Wed, 18 Jun 2014 13:05:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s5IK53Lc017685; Wed, 18 Jun 2014 15:05:03 -0500 Received: from XCH-PHX-401.sw.nos.boeing.com (xch-phx-401.sw.nos.boeing.com [137.136.239.36]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s5IK506A017093 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 18 Jun 2014 15:05:00 -0500 Received: from XCH-BLV-512.nw.nos.boeing.com ([169.254.12.74]) by XCH-PHX-401.sw.nos.boeing.com ([169.254.8.76]) with mapi id 14.03.0181.006; Wed, 18 Jun 2014 13:04:59 -0700 From: "Templin, Fred L" To: "Ivancic, William D. (GRC-RHN0)" , ccaini , "dtn@ietf.org" Thread-Topic: [dtn] Draft Charter Discussion Thread-Index: Ac+GbO3wN7xIp4CqSFeVEjvJc65+vAAK/PwAAAICPoAAMTi4gADF12gAAAUIgYAAAEJQAAAAr4kAAAPqQAAAAHs8gAAVwB4AAA20CAAAA2u+gP//xO4A///sZ1A= Date: Wed, 18 Jun 2014 20:04:59 +0000 Message-ID: <2134F8430051B64F815C691A62D983183048EF73@XCH-BLV-512.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> <2134F8430051B64F815C691A62D983183048B3B6@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983183048DB80@XCH-BLV-512.nw.nos.boeing.com> <53A09F61.2030900@cs.tcd.ie> <2134F8430051B64F815C691A62D983183048DD9A@XCH-BLV-512.nw.nos.boeing.com> <53A0A5B8.1090802@cs.tcd.ie> <53A0C339.2040106@cs.tcd.ie> In-Reply-To: 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/Y8RdATaLb-AaoW3v2aEXPUc80F4 Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 20:05:16 -0000 Hi Will, > -----Original Message----- > From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of Ivancic, William D. = (GRC-RHN0) > Sent: Wednesday, June 18, 2014 10:39 AM > To: ccaini; dtn@ietf.org > Subject: Re: [dtn] Draft Charter Discussion >=20 > Yes for payload data one could use DTN if it fit the deployment scenario. > I say understand the deployment scenario because we looked at DTN and > mobile-ip for the NASA Global Hawk flying over the poles. DTN provide no > value because you were connect up to the 70+ degrees latitude, then > disconnected until the return at which point you were connected again. > The network was single-hop. LEO spacecraft have similar. Yes, you can > use DTN, but there are other solutions that may be simpler. >=20 > The group should beware of what we state the use cases are. At this poin= t > in time, if one were to indicate, without specifying payload data, that > DTN could be used for UAVs, people working these policy programs and > trying to integrate UAVs into the National and Global Airspace will > probably not be happy. They have enough issues and hurdles without > someone thinking large cargo UAVs are going to fly into San Diego with > disrupted communications (FYI, one can literally walk from San Diego > airport to the center of downtown San Diego in 20 to 30 minutes. That is > how close those large aircraft fly to downtown.) No one is going to be flying a zero-pilot freighter into San Diego anytime soon, but you seem to be coming at this from a perspective of extremes. As in: "If the extremes (e.g., large-scale deployment, full UAV autonomy, etc.) aren't addressed in the first iteration then let's just forget the whole thing". But, that's not the way things work in real life. With that sort of thinking, the Internet (with its start-small grass-roots upbringing) never would have come into existence. Start with lots of limited-scale DTNs, then join them together to form larger DTNs - all of it supported by standard protocols. That is how the world works. Thanks - Fred fred.l.templin@boeing.com=20 =20 > Will >=20 > ****************************** >=20 >=20 >=20 >=20 >=20 >=20 > On 6/18/14 1:10 PM, "ccaini" wrote: >=20 > >Dear All, > > I am not a UAV expert, but I have read some papers about DTN applicati= on > >to them and I am also aware of some research on this field. > >UAVs may, or may not, need a continous channel to be remotely controlled= . > >In fact they can also fly in a completely autonomous way (I have seen so= me > >small UAVs flying this way) with the flight route precharged before > >launching. Of course, present regulations may or may not allow this, > >depending on countries. Anyway, the communication channel used to pilot > >them, if any, as well as being subject to possible disruption, as stated > >by > >Scott, does not need to be the same used for downloading data (e.g. > >pictures). The former can be a continous channel with scarce bandwidth b= ut > >large coverage (e.g. that provided by a GEO satellite, or by a global LE= O > >constallation, as Iridium), the latter can be a short range high bandwit= h > >link, characterized by an intermittent connectivity. For this link DTN > >seems of course the ideal choice. Moreover, communication can be > >integrated > >with flying control, and a UAV during the download of pictures to an ear= th > >station can keep hoovering or flying around until the reception of a BP > >custody acceptance from the node on the ground. Only after this receptio= n > >the UAV is allowed to restart is normal flight. The same of course can b= e > >done with whatever DTN mule, not just UAVs. Not sure but maybe it was do= ne > >with helicopters working as data mule in N4C. Maybe Stephen Farrell can > >confirm. > >Yours, > > Carlo Caini > > > >On Wed, 18 Jun 2014 15:32:54 +0000, "Burleigh, Scott C (312G)" > > wrote: > >> Will, Fred is way more knowledgeable about UAVs than I am, so I'm happ= y > >to > >> go with his assessment. But in any case I don't think I said anything > >> about DTN being great only for pilot-less UAV operations. UAV > >operations, > >> piloted or not, rely on communications. Technology that can improve > >> communications with UAVs makes them safer and more reliable. As I > >> understand it, if communication with a remotely piloted UAV is > >interrupted > >> for any reason, the vehicle has to go into some sort of safe autonomou= s > >> operational mode until communication is restored; the more quickly and > >> reliably that can happen -- that is, the better the disruption can be > >> handled -- the sooner the aircraft can resume normal operations. > >> > >> Scott > >> > >> -----Original Message----- > >> From: Ivancic, William D. (GRC-RHN0) [mailto:william.d.ivancic@nasa.go= v] > > > >> Sent: Wednesday, June 18, 2014 6:00 AM > >> To: Stephen Farrell; Burleigh, Scott C (312G); dtn@ietf.org > >> Subject: Re: [dtn] Draft Charter Discussion > >> > >> UAV applications sound good initially, but when you look at the > >> regulations, it is a not starter. You must be in control of the > >aircraft > >> at all times. There is not a pilot IN the aircraft, but there is one > >> flying it! Air Traffic Control is all about Safety of Flight and Safe= ty > >of > >> Life. > >> > >> NASA Glenn Research Center is working the communications issues and > >> technologies for integrating Unmanned Air Vehicles (UAVs) in the > >National > >> Airspace System (NAS). > >> > >> DTN for UAVs - only after you have gained complete confidence in > >> autonomous control for air craft avoidance. That isn't even being > >worked > >> now. Maybe 50 years from now, but not for a long time. > >> > >> Will > >> > >> > >> > >> > >> > >> On 6/17/14 6:37 PM, "Stephen Farrell" wrot= e: > >> > >>> > >>> > >>>On 17/06/14 23:23, Burleigh, Scott C (312G) wrote: > >>>> 1. The UAV industry is exploding. Nobody has any idea where the > >>>> limits on applications of UAVs are, but what we do know is that the > >>>> information that controls them is conveyed by radio, which is > >>>> occasionally subject to disruption. Technology that could improve > >>>> the safety and reliability of UAVs, while reducing cost, could find = a > >>>> large market. > >>> > >>>Excellent example. Now if we knew that that was a focus of interest > >>>that'd be cool and we could discuss timing and contact requirements, > >>>development environments, tooling etc. and how DTN protocols might fit > >>>with e.g. telemetry/control. (Elwyn could even have fun with routing - > >>>we have an old unfunded proposal along those lines;-) > >>> > >>>I'm not saying its a fatal problem that we only have the already known > >>>use-cases, but new information such as a confirmation that your good > >>>example was real (and were we to have folks who work in that space > >>>involved), could make for a much more compelling BoF and likely > >>>successful WG. > >>> > >>>S. > >>> > >>>_______________________________________________ > >>>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 >=20 > _______________________________________________ > dtn mailing list > dtn@ietf.org > https://www.ietf.org/mailman/listinfo/dtn From nobody Wed Jun 18 20:14:30 2014 Return-Path: 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 D66891A01D4 for ; Wed, 18 Jun 2014 20:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 njUd5onKa2Oy for ; Wed, 18 Jun 2014 20:14:25 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF9D61A01D0 for ; Wed, 18 Jun 2014 20:14:24 -0700 (PDT) Received: from [195.245.230.131:16666] by server-16.bemta-3.messagelabs.com id C7/2A-13481-F8552A35; Thu, 19 Jun 2014 03:14:23 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-5.tower-78.messagelabs.com!1403147662!34062556!1 X-Originating-IP: [131.227.200.35] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12207 invoked from network); 19 Jun 2014 03:14:22 -0000 Received: from exht021p.surrey.ac.uk (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-5.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 19 Jun 2014 03:14:22 -0000 Received: from EXHY012V.surrey.ac.uk (131.227.201.103) by EXHT021P.surrey.ac.uk (131.227.200.35) with Microsoft SMTP Server (TLS) id 8.3.348.2; Thu, 19 Jun 2014 04:14:22 +0100 Received: from emea01-am1-obe.outbound.protection.outlook.com (131.227.201.241) by EXHY012v.surrey.ac.uk (131.227.201.103) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 19 Jun 2014 04:14:22 +0100 Received: from AMSPR06MB439.eurprd06.prod.outlook.com (10.242.23.19) by AMSPR06MB439.eurprd06.prod.outlook.com (10.242.23.19) with Microsoft SMTP Server (TLS) id 15.0.959.24; Thu, 19 Jun 2014 03:14:21 +0000 Received: from AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) by AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) with mapi id 15.00.0959.000; Thu, 19 Jun 2014 03:14:21 +0000 From: To: , Thread-Topic: [dtn] Draft Charter Discussion Thread-Index: Ac+KdvALGRqD+DcFSSyr6f5ak4ImyAAATPYAAB9b2gAAAJeBCg== Date: Thu, 19 Jun 2014 03:14:20 +0000 Message-ID: <1403147657691.72591@surrey.ac.uk> References: <53A0BB7A.7060307@cs.tcd.ie>, In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [122.200.59.30] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02475B2A01 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(377454003)(479174003)(24454002)(199002)(189002)(13464003)(129404003)(51704005)(36304003)(21056001)(101416001)(95666004)(80022001)(105586002)(92726001)(85306003)(551944002)(85852003)(83072002)(66066001)(64706001)(86362001)(81342001)(36756003)(79102001)(20776003)(99396002)(50986999)(4396001)(74502001)(15975445006)(74662001)(31966008)(74482001)(19580395003)(83322001)(19580405001)(87936001)(92566001)(76482001)(81542001)(2656002)(77982001)(76176999)(54356999)(46102001); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR06MB439; H:AMSPR06MB439.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: surrey.ac.uk does not designate permitted sender hosts) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: AMSPR06MB439.eurprd06.prod.outlook.com X-CrossPremisesHeadersFiltered: EXHY012v.surrey.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/DtHjWGPdrpmmXXDYO5t6JmZywDs Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 03:14:29 -0000 Kip=0A= =0A= what is "RA"?=0A= =0A= thanks=0A= ________________________________________=0A= From: dtn on behalf of Klish, Cypryan =0A= Sent: Wednesday, 18 June 2014 11:02:36 PM=0A= To: dtn@ietf.org=0A= Subject: Re: [dtn] Draft Charter Discussion=0A= =0A= Thanks Stephen!=0A= =0A= With respect to how the specifications would be used, in general, the organ= ization I work for has capabilities that span most of the use cases that ha= ve been discussed. Mobile tactical edge networks, UAV/airborne sensor netw= orks, space networks, and other mission critical systems that operate over = bandwidth-limited and lossy networks are all relevant for us.=0A= =0A= In my case specifically, I'm interested in assured delivery of user data ov= er heterogeneous networks that traverse a variety of physical network types= . I'd like to bound data loss and data delivery delay so that customers ca= n be offered an SLA-like agreement that quantifies these and other aspects = of assured delivery. This, I suggest, would involve not only up front char= acterization of DTN behaviors but also a robust performance monitoring capa= bility that could be used to validate fulfillment of the SLA-like agreement= , hence my suggestion that the charter include definition of management cap= abilities within the WG's activity scope.=0A= =0A= As a future objective, mapping DTN mechanisms (speaking in broad terms here= ) directly to Carrier Ethernet over OTN, optical burst switching or optical= wavelength switching technologies is also relevant for me. This gives ris= e to my interest in layering and making DTN mechanisms portable to differen= t technologies. The benefit of doing would be freeing up bandwidth that is= consumed by protocols at intervening layers - an important consideration i= n the bandwidth/throughput limited networks I typically work with.=0A= =0A= With respect to RFC 4838,I mentioned it only because it is the one existing= RFC that attempts to address DTN architecture from a system-wide scope. I= perceive the lack of similar but up to date, current document that is more= formal in the sense of being a RA as a critical gap for this effort - acco= rdingly, suggest the need to generate and maintain a DTN RA would be worth = of inclusion in the charter. I agree that re-opening RFC 4838 itself would= not be beneficial - a new RA document that cites RFC 4838 as a historical = reference might be the better way to go.=0A= =0A= Lastly, any charter that doesn't target interoperability as a WG objective = would be deficient in my view.=0A= =0A= 'Hope this helps, welcome everyone's feedback.=0A= =0A= Kip (Cypryan) Klish=0A= Sr. Scientist=0A= Harris Corporation, Government Communications Systems=0A= =0A= -----Original Message-----=0A= From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]=0A= Sent: Tuesday, June 17, 2014 6:05 PM=0A= To: Klish, Cypryan; dtn@ietf.org=0A= Subject: Re: [dtn] Draft Charter Discussion=0A= =0A= =0A= Hi Cypryan,=0A= =0A= Good stuff. Can you say some more about what you'd be using such=0A= an set of BP specs for?=0A= =0A= I think you're the first to suggest re-opening RFC4838 btw. Not sure=0A= I see much benefit in that to be honest. And some risk that the valid=0A= argument that 4838 is a bit too BP specific might win the day and,=0A= from a charter/milestones POV, de-rail the WG.=0A= =0A= Ta,=0A= S.=0A= =0A= On 17/06/14 22:56, Klish, Cypryan wrote:=0A= > As a long time lurker and foremost an implementer and developer of produc= ts suggest a DTN WG charter should address the need to refine and further s= tandardize the fine research done by the DTNRG so that it can be implemente= d by practitioners/organizations with a reasonable expectation that it will= be interoperable, secure, and perform within a range of boundaries and con= straints defined in the standards.=0A= >=0A= > What does this entail? Suggest some of the following would be relevant := =0A= > * Generate/refine a reference architecture that is more up to date,= comprehensive and complete than RFC4838; a model-based RA would be icing o= n the cake=0A= > * Better identify known constraints and limitations=0A= > * Better define management aspects (e.g. MIBs or YANG models)=0A= > * Provide multiple security model options - perhaps like SNMP's US= M and VACM=0A= > * Consider layering aspects, particularly layer boundaries, enablin= g independent/portable use of some features (e.g. bundling as a service?)= =0A= > * Consider defining profiles/modes/classes of operation/RA subsets = traceable to the use cases=0A= >=0A= > Hope this helps=0A= >=0A= > Kip=0A= >=0A= > Cypryan (Kip) T. Klish II=0A= > Senior Scientist=0A= > Government Communications Systems=0A= > HARRIS=0A= > AssuredCommunications*=0A= > Post Office Box 37=0A= > Melbourne, FL 32902-0037=0A= > * 1 321 727 6348=0A= > * 1 321 298 0492 (mobile) *Note new mobile number*=0A= > * cklish@harris.com=0A= > Confidentiality Notice: This Email and any attachments may contain materi= al that is "HARRIS Proprietary Information," Confidential, Privileged, and/= or Attorney Work Product for the Sole Use of the Intended Recipient. Any Re= view, Reliance, Distribution, Disclosure, or Forwarding Without Expressed P= ermission is Strictly Prohibited. If you are not the Intended Recipient, Pl= ease Contact the Sender and Delete All Copies Without Reading, Printing, or= Saving in any Manner. -- Thank You.=0A= >=0A= >=0A= >=0A= >=0A= >=0A= >=0A= > _______________________________________________=0A= > dtn mailing list=0A= > dtn@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/dtn=0A= >=0A= =0A= _______________________________________________=0A= dtn mailing list=0A= dtn@ietf.org=0A= https://www.ietf.org/mailman/listinfo/dtn=0A= From nobody Wed Jun 18 20:38:12 2014 Return-Path: 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 E7A971A01D6 for ; Wed, 18 Jun 2014 20:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 eOFVoofhf6Y4 for ; Wed, 18 Jun 2014 20:38:07 -0700 (PDT) Received: from mlbxsmtpout01.harris.com (mlbxsmtpout01.harris.com [192.52.234.91]) by ietfa.amsl.com (Postfix) with ESMTP id EC3751A0076 for ; Wed, 18 Jun 2014 20:38:06 -0700 (PDT) X-AuditID: c034ea5a-f79766d000001ffd-3c-53a25b1dd4e5 Received: from MLBMXCAHT22.cs.myharris.net (mlbmxcaht22.cs.myharris.net [10.64.224.24]) by mlbxsmtpout01.harris.com (mail) with SMTP id 6A.22.08189.D1B52A35; Wed, 18 Jun 2014 23:38:06 -0400 (EDT) Received: from MLBMXUS21.cs.myharris.net ([169.254.2.109]) by MLBMXCAHT22.cs.myharris.net ([::1]) with mapi id 14.02.0318.001; Wed, 18 Jun 2014 23:38:05 -0400 From: "Klish, Cypryan" To: "l.wood@surrey.ac.uk" Thread-Topic: [dtn] Draft Charter Discussion Thread-Index: Ac+KdvALGRqD+DcFSSyr6f5ak4ImyAAIrrsAABXUntAAJ0ZSAP//w5S8 Date: Thu, 19 Jun 2014 03:38:05 +0000 Message-ID: References: <53A0BB7A.7060307@cs.tcd.ie>, , <1403147657691.72591@surrey.ac.uk> In-Reply-To: <1403147657691.72591@surrey.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsXC5fBAQlcuelGwwbk53Bbta1gsju/+yeTA 5LFkyU8mj6NTbjMFMEVx2aSk5mSWpRbp2yVwZfxomspSsFevYkXrbeYGxuuqXYwcHBICJhKb 77B0MXICmWISF+6tZ+ti5OIQEjjKKHG0bxYThLOIUeL9/tcsIA1sAloSTfv5QBpEBPQlJl/Z zA5iMwsoSvxv+MgMUiIsoC3x+bgcRImOxK8jdxkhbDeJN3MWs4OUsAioSsx6FAYS5hWwlejf 3cYKsek6o8Tqdx2sIAlOoPHN/06CjWcEuu37qTVMEKvEJW49mc8EcbOAxJI955khbFGJl4// sULU6Egs2P2JDcLWlli28DUzxDJBiZMzn7BMYBSdhWTULCQts5C0zELSsoCRZRWjaG5OUkVx bkmBgaFeRmJRUWaxXnJ+7iZGYIQcMHkVtYNx+Sv7Q4wCHIxKPLwLLi8MFmJNLCuuzD3EKMHB rCTCK/8LKMSbklhZlVqUH19UmpNafIhRmoNFSZy3ci1QSiA9sSQ1OzW1ILUIJsvEwSnVwGh9 sPuk1O3HS4TjDnXp7D1ZLGSk802+fzn/AcEvrp8dzRY/WskZx175XPrhLFX1E2c5Ai//sJvv LGX5eq/Hkrcu+2ts/29fLS8hm5mv+YXpW9sllb3tV/582NMkI2njc8RXpExeorJYz/tci+nU ZNEE03mfnQ90rup1Va9m972eefWktO7yiUosxRmJhlrMRcWJADALiiaMAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/g_ZaXP7z5qiMpvIsevwpLaasvDE Cc: "dtn@ietf.org" Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 03:38:10 -0000 RA =3D Reference Architecture Sent from my iPhone > On Jun 18, 2014, at 11:14 PM, "l.wood@surrey.ac.uk" = wrote: >=20 > Kip >=20 > what is "RA"? >=20 > thanks > ________________________________________ > From: dtn on behalf of Klish, Cypryan > Sent: Wednesday, 18 June 2014 11:02:36 PM > To: dtn@ietf.org > Subject: Re: [dtn] Draft Charter Discussion >=20 > Thanks Stephen! >=20 > With respect to how the specifications would be used, in general, the org= anization I work for has capabilities that span most of the use cases that = have been discussed. Mobile tactical edge networks, UAV/airborne sensor ne= tworks, space networks, and other mission critical systems that operate ove= r bandwidth-limited and lossy networks are all relevant for us. >=20 > In my case specifically, I'm interested in assured delivery of user data = over heterogeneous networks that traverse a variety of physical network typ= es. I'd like to bound data loss and data delivery delay so that customers = can be offered an SLA-like agreement that quantifies these and other aspect= s of assured delivery. This, I suggest, would involve not only up front ch= aracterization of DTN behaviors but also a robust performance monitoring ca= pability that could be used to validate fulfillment of the SLA-like agreeme= nt, hence my suggestion that the charter include definition of management c= apabilities within the WG's activity scope. >=20 > As a future objective, mapping DTN mechanisms (speaking in broad terms he= re) directly to Carrier Ethernet over OTN, optical burst switching or optic= al wavelength switching technologies is also relevant for me. This gives r= ise to my interest in layering and making DTN mechanisms portable to differ= ent technologies. The benefit of doing would be freeing up bandwidth that = is consumed by protocols at intervening layers - an important consideration= in the bandwidth/throughput limited networks I typically work with. >=20 > With respect to RFC 4838,I mentioned it only because it is the one existi= ng RFC that attempts to address DTN architecture from a system-wide scope. = I perceive the lack of similar but up to date, current document that is mo= re formal in the sense of being a RA as a critical gap for this effort - ac= cordingly, suggest the need to generate and maintain a DTN RA would be wort= h of inclusion in the charter. I agree that re-opening RFC 4838 itself wou= ld not be beneficial - a new RA document that cites RFC 4838 as a historica= l reference might be the better way to go. >=20 > Lastly, any charter that doesn't target interoperability as a WG objectiv= e would be deficient in my view. >=20 > 'Hope this helps, welcome everyone's feedback. >=20 > Kip (Cypryan) Klish > Sr. Scientist > Harris Corporation, Government Communications Systems >=20 > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Tuesday, June 17, 2014 6:05 PM > To: Klish, Cypryan; dtn@ietf.org > Subject: Re: [dtn] Draft Charter Discussion >=20 >=20 > Hi Cypryan, >=20 > Good stuff. Can you say some more about what you'd be using such > an set of BP specs for? >=20 > I think you're the first to suggest re-opening RFC4838 btw. Not sure > I see much benefit in that to be honest. And some risk that the valid > argument that 4838 is a bit too BP specific might win the day and, > from a charter/milestones POV, de-rail the WG. >=20 > Ta, > S. >=20 >> On 17/06/14 22:56, Klish, Cypryan wrote: >> As a long time lurker and foremost an implementer and developer of produ= cts suggest a DTN WG charter should address the need to refine and further = standardize the fine research done by the DTNRG so that it can be implement= ed by practitioners/organizations with a reasonable expectation that it wil= l be interoperable, secure, and perform within a range of boundaries and co= nstraints defined in the standards. >>=20 >> What does this entail? Suggest some of the following would be relevant : >> * Generate/refine a reference architecture that is more up to date= , comprehensive and complete than RFC4838; a model-based RA would be icing = on the cake >> * Better identify known constraints and limitations >> * Better define management aspects (e.g. MIBs or YANG models) >> * Provide multiple security model options - perhaps like SNMP's U= SM and VACM >> * Consider layering aspects, particularly layer boundaries, enabli= ng independent/portable use of some features (e.g. bundling as a service?) >> * Consider defining profiles/modes/classes of operation/RA subsets= traceable to the use cases >>=20 >> Hope this helps >>=20 >> Kip >>=20 >> Cypryan (Kip) T. Klish II >> Senior Scientist >> Government Communications Systems >> HARRIS >> AssuredCommunications* >> Post Office Box 37 >> Melbourne, FL 32902-0037 >> * 1 321 727 6348 >> * 1 321 298 0492 (mobile) *Note new mobile number* >> * cklish@harris.com >> Confidentiality Notice: This Email and any attachments may contain mater= ial that is "HARRIS Proprietary Information," Confidential, Privileged, and= /or Attorney Work Product for the Sole Use of the Intended Recipient. Any R= eview, Reliance, Distribution, Disclosure, or Forwarding Without Expressed = Permission is Strictly Prohibited. If you are not the Intended Recipient, P= lease Contact the Sender and Delete All Copies Without Reading, Printing, o= r Saving in any Manner. -- Thank You. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> dtn mailing list >> dtn@ietf.org >> https://www.ietf.org/mailman/listinfo/dtn >=20 > _______________________________________________ > dtn mailing list > dtn@ietf.org > https://www.ietf.org/mailman/listinfo/dtn >=20 From nobody Thu Jun 19 12:49:26 2014 Return-Path: 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 CF3B71A03E2 for ; Thu, 19 Jun 2014 12:49:23 -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 tMx8tEsKd8uc for ; Thu, 19 Jun 2014 12:49:21 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DE371A0302 for ; Thu, 19 Jun 2014 12:49:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s5JJnKHN004976; Thu, 19 Jun 2014 12:49:20 -0700 Received: from XCH-PHX-402.sw.nos.boeing.com (xch-phx-402.sw.nos.boeing.com [137.136.239.38]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s5JJnIMb004947 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 19 Jun 2014 12:49:19 -0700 Received: from XCH-BLV-512.nw.nos.boeing.com ([169.254.12.74]) by XCH-PHX-402.sw.nos.boeing.com ([169.254.7.196]) with mapi id 14.03.0181.006; Thu, 19 Jun 2014 12:49:18 -0700 From: "Templin, Fred L" To: "Klish, Cypryan" , "dtn@ietf.org" Thread-Topic: [dtn] Draft Charter Discussion Thread-Index: Ac+KdvALN7xIp4CqSFeVEjvJc65+vAAIrrsAABXUntAAQPVlMA== Date: Thu, 19 Jun 2014 19:49:17 +0000 Message-ID: <2134F8430051B64F815C691A62D983183048FAAF@XCH-BLV-512.nw.nos.boeing.com> References: <53A0BB7A.7060307@cs.tcd.ie> In-Reply-To: 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/Am_j58d2tykgftiJ4CGQepIo9JA Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 19:49:24 -0000 Hi Kip, > -----Original Message----- > From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of Klish, Cypryan > Sent: Wednesday, June 18, 2014 6:03 AM > To: dtn@ietf.org > Subject: Re: [dtn] Draft Charter Discussion >=20 > Thanks Stephen! >=20 > With respect to how the specifications would be used, in general, the org= anization I work for has > capabilities that span most of the use cases that have been discussed. M= obile tactical edge networks, > UAV/airborne sensor networks, space networks, and other mission critical = systems that operate over > bandwidth-limited and lossy networks are all relevant for us. I think it safe to say that my company's business interests also overlap with some of the use cases that have been discussed in this thread.=20 > In my case specifically, I'm interested in assured delivery of user data = over heterogeneous networks > that traverse a variety of physical network types. I'd like to bound dat= a loss and data delivery > delay so that customers can be offered an SLA-like agreement that quantif= ies these and other aspects > of assured delivery. This, I suggest, would involve not only up front ch= aracterization of DTN > behaviors but also a robust performance monitoring capability that could = be used to validate > fulfillment of the SLA-like agreement, hence my suggestion that the chart= er include definition of > management capabilities within the WG's activity scope. >=20 > As a future objective, mapping DTN mechanisms (speaking in broad terms he= re) directly to Carrier > Ethernet over OTN, optical burst switching or optical wavelength switchin= g technologies is also > relevant for me. This gives rise to my interest in layering and making D= TN mechanisms portable to > different technologies. The benefit of doing would be freeing up bandwid= th that is consumed by > protocols at intervening layers - an important consideration in the bandw= idth/throughput limited > networks I typically work with. >=20 > With respect to RFC 4838,I mentioned it only because it is the one existi= ng RFC that attempts to > address DTN architecture from a system-wide scope. I perceive the lack o= f similar but up to date, > current document that is more formal in the sense of being a RA as a crit= ical gap for this effort - > accordingly, suggest the need to generate and maintain a DTN RA would be = worth of inclusion in the > charter. I agree that re-opening RFC 4838 itself would not be beneficial= - a new RA document that > cites RFC 4838 as a historical reference might be the better way to go. Architecture documents are not functional specifications; they are typically targeted for Informational or Experimental category. We already have RFC4838, and the current work items in the draft charter are focused on functional specifications. So I am not sure anything new in this space needs to appear in the draft charter. =20 > Lastly, any charter that doesn't target interoperability as a WG objectiv= e would be deficient in my > view. It is understood by the community that IETF standards-track documents are produced for the purpose of guiding the development of independent interoperable implementations. Interoperable implementations are sometimes made available even before the document is published, but this is not required. In the case of the work produced by DTNRG, we already have multiple interoperable implementation that observe the specifications. Hence, there is no reason to doubt that interoperable implementations will naturally track along with the works produced by this prospective working group. Thanks - Fred fred.l.templin@boeing.com =20 =20 > 'Hope this helps, welcome everyone's feedback. >=20 > Kip (Cypryan) Klish > Sr. Scientist > Harris Corporation, Government Communications Systems >=20 > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Tuesday, June 17, 2014 6:05 PM > To: Klish, Cypryan; dtn@ietf.org > Subject: Re: [dtn] Draft Charter Discussion >=20 >=20 > Hi Cypryan, >=20 > Good stuff. Can you say some more about what you'd be using such > an set of BP specs for? >=20 > I think you're the first to suggest re-opening RFC4838 btw. Not sure > I see much benefit in that to be honest. And some risk that the valid > argument that 4838 is a bit too BP specific might win the day and, > from a charter/milestones POV, de-rail the WG. >=20 > Ta, > S. >=20 > On 17/06/14 22:56, Klish, Cypryan wrote: > > As a long time lurker and foremost an implementer and developer of prod= ucts suggest a DTN WG charter > should address the need to refine and further standardize the fine resear= ch done by the DTNRG so that > it can be implemented by practitioners/organizations with a reasonable ex= pectation that it will be > interoperable, secure, and perform within a range of boundaries and const= raints defined in the > standards. > > > > What does this entail? Suggest some of the following would be relevant = : > > * Generate/refine a reference architecture that is more up to dat= e, comprehensive and complete > than RFC4838; a model-based RA would be icing on the cake > > * Better identify known constraints and limitations > > * Better define management aspects (e.g. MIBs or YANG models) > > * Provide multiple security model options - perhaps like SNMP's = USM and VACM > > * Consider layering aspects, particularly layer boundaries, enabl= ing independent/portable use > of some features (e.g. bundling as a service?) > > * Consider defining profiles/modes/classes of operation/RA subset= s traceable to the use cases > > > > Hope this helps > > > > Kip > > > > Cypryan (Kip) T. Klish II > > Senior Scientist > > Government Communications Systems > > HARRIS > > AssuredCommunications* > > Post Office Box 37 > > Melbourne, FL 32902-0037 > > * 1 321 727 6348 > > * 1 321 298 0492 (mobile) *Note new mobile number* > > * cklish@harris.com > > Confidentiality Notice: This Email and any attachments may contain mate= rial that is "HARRIS > Proprietary Information," Confidential, Privileged, and/or Attorney Work = Product for the Sole Use of > the Intended Recipient. Any Review, Reliance, Distribution, Disclosure, o= r Forwarding Without > Expressed Permission is Strictly Prohibited. If you are not the Intended = Recipient, Please Contact the > Sender and Delete All Copies Without Reading, Printing, or Saving in any = Manner. -- Thank You. > > > > > > > > > > > > > > _______________________________________________ > > dtn mailing list > > dtn@ietf.org > > https://www.ietf.org/mailman/listinfo/dtn > > >=20 > _______________________________________________ > dtn mailing list > dtn@ietf.org > https://www.ietf.org/mailman/listinfo/dtn From nobody Fri Jun 20 12:16:12 2014 Return-Path: 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 7FEBF1B28B9 for ; Fri, 20 Jun 2014 12:16:11 -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 5w936CM0sihO for ; Fri, 20 Jun 2014 12:16:09 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7388E1A02AF for ; Fri, 20 Jun 2014 12:16:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s5KJG96l030993; Fri, 20 Jun 2014 12:16:09 -0700 Received: from XCH-PHX-404.sw.nos.boeing.com (xch-phx-404.sw.nos.boeing.com [137.136.239.42]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s5KJG6sY030979 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 20 Jun 2014 12:16:07 -0700 Received: from XCH-BLV-512.nw.nos.boeing.com ([169.254.12.74]) by XCH-PHX-404.sw.nos.boeing.com ([169.254.5.153]) with mapi id 14.03.0181.006; Fri, 20 Jun 2014 12:16:05 -0700 From: "Templin, Fred L" To: "Ivancic, William D. (GRC-RHN0)" , "dtn@ietf.org" Thread-Topic: [dtn] rfc5050(bis) proposed revisions Thread-Index: AQHPivfJ2O/x4+1RG0Stzkfn5ML73Jt6YNQQ Date: Fri, 20 Jun 2014 19:16:05 +0000 Message-ID: <2134F8430051B64F815C691A62D983183049098D@XCH-BLV-512.nw.nos.boeing.com> References: In-Reply-To: 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/Cd_nl_MbMeUYifKYWj3nIXy4DAI Subject: Re: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 19:16:11 -0000 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 >=20 > 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 i= s > premature to consider these implementations until a working group is or i= s > not formed (at which point we will know where those discussions should > occur). For now, IMHO, implementations issues are probably best addresse= d > 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 fred.l.templin@boeing.com > Will >=20 > ****************************** >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On 6/17/14 4:20 PM, "Templin, Fred L" wrote: >=20 > >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 From nobody Fri Jun 20 12:23:19 2014 Return-Path: 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 42C7D1B28E1 for ; Fri, 20 Jun 2014 12:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 O3zpR56LbVj4 for ; Fri, 20 Jun 2014 12:23:09 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5DF1B28BA for ; Fri, 20 Jun 2014 12:23:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 68FB4BEA4; Fri, 20 Jun 2014 20:23:08 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oj8ylhYwiY5c; Fri, 20 Jun 2014 20:23:06 +0100 (IST) Received: from [10.87.48.6] (unknown [86.44.75.216]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D1BD8BE98; Fri, 20 Jun 2014 20:23:05 +0100 (IST) Message-ID: <53A48A19.1010504@cs.tcd.ie> Date: Fri, 20 Jun 2014 20:23:05 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Templin, Fred L" , "Ivancic, William D. (GRC-RHN0)" , "dtn@ietf.org" References: <2134F8430051B64F815C691A62D983183049098D@XCH-BLV-512.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983183049098D@XCH-BLV-512.nw.nos.boeing.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/CWlTQPMk9L2UJngIwCGq6I_46tU Subject: Re: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 19:23:15 -0000 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" 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 > > From nobody Fri Jun 20 12:33:51 2014 Return-Path: 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 C05E31B28DC for ; Fri, 20 Jun 2014 12:33:49 -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 Lh9wfvhEcWvF for ; Fri, 20 Jun 2014 12:33:47 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C4E01B28D3 for ; Fri, 20 Jun 2014 12:33:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s5KJXkhn031800; Fri, 20 Jun 2014 14:33:46 -0500 Received: from XCH-PHX-402.sw.nos.boeing.com (xch-phx-402.sw.nos.boeing.com [137.136.239.38]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s5KJXcKO031145 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 20 Jun 2014 14:33:39 -0500 Received: from XCH-BLV-512.nw.nos.boeing.com ([169.254.12.74]) by XCH-PHX-402.sw.nos.boeing.com ([169.254.7.196]) with mapi id 14.03.0181.006; Fri, 20 Jun 2014 12:33:38 -0700 From: "Templin, Fred L" To: Stephen Farrell , "Ivancic, William D. (GRC-RHN0)" , "dtn@ietf.org" Thread-Topic: [dtn] rfc5050(bis) proposed revisions Thread-Index: AQHPivfJ2O/x4+1RG0Stzkfn5ML73Jt6YNQQgAB4s4D//41cMA== Date: Fri, 20 Jun 2014 19:33:38 +0000 Message-ID: <2134F8430051B64F815C691A62D98318304909D6@XCH-BLV-512.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983183049098D@XCH-BLV-512.nw.nos.boeing.com> <53A48A19.1010504@cs.tcd.ie> In-Reply-To: <53A48A19.1010504@cs.tcd.ie> 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/N1TGq3FBmFdnMsSAHX1JxAvtlbc Subject: Re: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 19:33:49 -0000 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 >=20 >=20 >=20 > 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.go= v] > >> 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 i= t is > >> premature to consider these implementations until a working group is o= r is > >> not formed (at which point we will know where those discussions should > >> occur). For now, IMHO, implementations issues are probably best addre= ssed > >> 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. >=20 > 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 =20 > After the BoF we can figure if something ought be here > or there, assuming there is a "here". >=20 > > > >> 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. >=20 > 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. >=20 > S. >=20 > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> Will > >> > >> ****************************** > >> > >> > >> > >> > >> > >> > >> > >> On 6/17/14 4:20 PM, "Templin, Fred L" wrot= e: > >> > >>> 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 multipl= e > >>> occurrences (providing possible support for the MITRE idea of > >>> multiple concurrent custodians, from several years ago); defin= e > >>> 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 > > > > >=20 > _______________________________________________ > dtn mailing list > dtn@ietf.org > https://www.ietf.org/mailman/listinfo/dtn From nobody Fri Jun 20 12:36:01 2014 Return-Path: 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 6EB5E1B28B1 for ; Fri, 20 Jun 2014 12:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 SeENLZMp6JVP for ; Fri, 20 Jun 2014 12:35:57 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCC8D1B28D3 for ; Fri, 20 Jun 2014 12:35:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s5KJZvHO005280; Fri, 20 Jun 2014 14:35:57 -0500 Received: from XCH-PHX-305.sw.nos.boeing.com (xch-phx-305.sw.nos.boeing.com [137.136.239.28]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s5KJZllK005190 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Fri, 20 Jun 2014 14:35:48 -0500 Received: from XCH-BLV-512.nw.nos.boeing.com ([169.254.12.74]) by XCH-PHX-305.sw.nos.boeing.com ([169.254.5.219]) with mapi id 14.03.0181.006; Fri, 20 Jun 2014 12:35:47 -0700 From: "Templin, Fred L" To: "dtn@ietf.org" Thread-Topic: RFC5050(bis) Proposed Revisions Thread-Index: Ac+MvtThH4Jkq5kFQJuG5/ssgQVAcw== Date: Fri, 20 Jun 2014 19:35:46 +0000 Message-ID: <2134F8430051B64F815C691A62D98318304909EB@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: multipart/alternative; boundary="_000_2134F8430051B64F815C691A62D98318304909EBXCHBLV512nwnosb_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/62e0PJyH4SoRCFyLTdKhIh1w7sc 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 19:36:00 -0000 --_000_2134F8430051B64F815C691A62D98318304909EBXCHBLV512nwnosb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Below are proposed revisions for RFC5050(bis). Please comment on this list (dtn@ietf.org). 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. --_000_2134F8430051B64F815C691A62D98318304909EBXCHBLV512nwnosb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Below are proposed revisions for RFC5050(bis). Pl= ease comment on

this list (dtn@ie= tf.org).

 

Thanks – Fred

fred.l.templin@boeing.com

 

---

 

Appendix A.      &n= bsp;           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

        custod= ian to an extension block, of which there can be multiple

        occurr= ences (providing possible support for the MITRE idea of

        multip= le concurrent custodians, from several years ago); define

        that b= lock in this spec.

     . Add the notion of &quo= t;embargoes", i.e., what do you do when a

        route = unexpectedly goes bad for a while?  This entails adding

        anothe= r extension block (Forwarding Anomaly) and another

        admini= strative record (Reopen Signal).

     . Incorporate the Compre= ssed Bundle Header Encoding [RFC6260]

        concep= ts into the base specification: nodes are explicitly

        identi= fied by node numbers, and operations that pertain to

        nodes = are described in terms of node numbers rather than

        endpoi= nt IDs.

     . Add basic ("imc&q= uot;) multicast to the BP spec.  This entails

        adding= another administrative record, Multicast Petition.

     . Add Destination EID ex= tension block for destinations that can't

        be exp= ressed in "ipn"-scheme and "imc"-scheme URIs.  Def= ine it

        in thi= s spec.

     . Incorporate the "= Extended Class of Service" features into the

        base s= pecification.

     . Restructure the primar= y block, making it immutable.  Add CRC.

        Remove= the dictionary.

     . Add optional Payload C= RC extension block, defined in this spec.

     . Add block ID number to= canonical block format (to support

        stream= lined Bundle Security Protocol).

     . Add bundle age extensi= on block, defined in this spec.

     . Define two other exten= sion blocks in this spec: previous node

        number= , hop count.

     . Clean up a conflict be= tween fragmentation and custody transfer

        that E= d Birrane pointed out.

     . Remove "DTN time&= quot; values from administrative records.

        Nanose= cond precision will not be meaningful among nodes whose

        clocks= are not closely synchronized, and absent that feature

        the ad= ministrative record's bundle creation time suffices to

        indica= te the time of occurrence of the reported event.

     . Note that CL protocols= are supposed to discard data that they

        find t= o have been corrupted.

 

--_000_2134F8430051B64F815C691A62D98318304909EBXCHBLV512nwnosb_-- From nobody Fri Jun 20 13:00:18 2014 Return-Path: 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 6A26E1B28E4 for ; Fri, 20 Jun 2014 13:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 PTJ-d-6BHdPv for ; Fri, 20 Jun 2014 13:00:14 -0700 (PDT) Received: from ndjsnpf03.ndc.nasa.gov (ndjsnpf03.ndc.nasa.gov [IPv6:2001:4d0:a302:1100::103]) by ietfa.amsl.com (Postfix) with ESMTP id 6A09E1B28DC for ; Fri, 20 Jun 2014 13:00:14 -0700 (PDT) Received: from ndjsppt105.ndc.nasa.gov (ndjsppt105.ndc.nasa.gov [198.117.1.199]) by ndjsnpf03.ndc.nasa.gov (Postfix) with ESMTP id AE8312D809C; Fri, 20 Jun 2014 15:00:13 -0500 (CDT) Received: from NDJSCHT110.ndc.nasa.gov (ndjscht110-pub.ndc.nasa.gov [198.117.1.210]) by ndjsppt105.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id s5KK0DLk017107; Fri, 20 Jun 2014 15:00:13 -0500 Received: from NDJSMBX203.ndc.nasa.gov ([169.254.2.164]) by NDJSCHT110.ndc.nasa.gov ([198.117.1.210]) with mapi id 14.03.0174.001; Fri, 20 Jun 2014 15:00:13 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: "Templin, Fred L" , "dtn@ietf.org" Thread-Topic: [dtn] rfc5050(bis) proposed revisions Thread-Index: AQHPivfJ2O/x4+1RG0Stzkfn5ML73Jt6YNQQgAAefQA= Date: Fri, 20 Jun 2014 20:00:12 +0000 Message-ID: References: <2134F8430051B64F815C691A62D983183049098D@XCH-BLV-512.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983183049098D@XCH-BLV-512.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [139.88.242.146] Content-Type: text/plain; charset="us-ascii" Content-ID: <0E34DDA968AA3E46855EFE680E10D315@mail.nasa.gov> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-06-20_07:2014-06-20,2014-06-20,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/QL5kE43XNJXQpzXfdF5CMJBVG6k Subject: Re: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 20:00:16 -0000 Fred, Implementations may not have been the best word choice, but there is a lot of "How" in bpv7. What I meant was that Scott's propose revisions probably do not belong on the BOF this list. It could quickly lead to discussions of specification changes and where pieces should go which is currently should occur on dtn-interest. Those should IMHO occur after the BOF, not before and not on the BOF list. Removing dictionary. Sort of specifying an addressing scheme (URL usage), Hop count as extension block, how to do bundle security, etc... are better served on dtn-interest at this point in time. Just my opinion. By the way, I'm not saying these are wrong, just that they do not belong on the BOF list. I think the BOF list is suppose to be about "What exactly and specifically should this group be working on if an IETF dtn working group is formed?" "Should IETF form a working group?", "Are the protocols at a state where they are ready for IETF standard or is there more work that should be done in IRTF?" "Is there sufficient energy to get meaningful work done?" So we should be addressing "What", not "How". FYI: Anyone list participant can get information on who subscribed to an IETF mail list if they remember their password (and you can ask for your password to be resent). These lists are setup to be open, so the participation list is not just available to the administrators. At least that is my recollection and it has always worked for me. Also, since anyone can sign up, basically, with minimal effort, anyone can see who subscribed to an IETF list. If you go to dtn-interest and compare to dtn, the dtn-interest as far more participants. Will >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 >>=20 >> 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 >fred.l.templin@boeing.com > >> Will >>=20 >> ****************************** >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On 6/17/14 4:20 PM, "Templin, Fred L" wrote: >>=20 >> >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: >> >.... From nobody Fri Jun 20 13:09:02 2014 Return-Path: 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 540631B2909 for ; Fri, 20 Jun 2014 13:08:58 -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 XzKdCa3vQ9nv for ; Fri, 20 Jun 2014 13:08:55 -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 11B4A1A0331 for ; Fri, 20 Jun 2014 13:08:11 -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 s5KK89Gx014484; Fri, 20 Jun 2014 15:08:09 -0500 Received: from XCH-PHX-303.sw.nos.boeing.com (xch-phx-303.sw.nos.boeing.com [137.136.239.24]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s5KK84HY014440 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 20 Jun 2014 15:08:04 -0500 Received: from XCH-BLV-512.nw.nos.boeing.com ([169.254.12.74]) by XCH-PHX-303.sw.nos.boeing.com ([169.254.6.13]) with mapi id 14.03.0181.006; Fri, 20 Jun 2014 13:08:04 -0700 From: "Templin, Fred L" To: "Ivancic, William D. (GRC-RHN0)" , "dtn@ietf.org" Thread-Topic: [dtn] rfc5050(bis) proposed revisions Thread-Index: AQHPivfJ2O/x4+1RG0Stzkfn5ML73Jt6YNQQgAAefQD///AXQA== Date: Fri, 20 Jun 2014 20:08:03 +0000 Message-ID: <2134F8430051B64F815C691A62D9831830490AB6@XCH-BLV-512.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983183049098D@XCH-BLV-512.nw.nos.boeing.com> In-Reply-To: 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/HE2pCYSxwABSJrmCMGulMO_ijZ8 Subject: Re: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 20:08:58 -0000 Hi Will, > -----Original Message----- > From: Ivancic, William D. (GRC-RHN0) [mailto:william.d.ivancic@nasa.gov] > Sent: Friday, June 20, 2014 1:00 PM > To: Templin, Fred L; dtn@ietf.org > Subject: Re: [dtn] rfc5050(bis) proposed revisions >=20 >=20 > Fred, >=20 > Implementations may not have been the best word choice, but there is a > lot of "How" in bpv7. What I meant was that Scott's propose revisions > probably do not belong on the BOF this list. It could quickly lead to > discussions of specification changes and where pieces should go which is > currently should occur on dtn-interest. Those should IMHO occur after th= e > BOF, not before and not on the BOF list. Removing dictionary. Sort of > specifying an addressing scheme (URL usage), Hop count as extension block= , > how to do bundle security, etc... are better served on dtn-interest at > this point in time. Just my opinion. By the way, I'm not saying these > are wrong, just that they do not belong on the BOF list. >=20 > I think the BOF list is suppose to be about > "What exactly and specifically should this group be working on if an IETF > dtn working group is formed?" > "Should IETF form a working group?", > "Are the protocols at a state where they are ready for IETF standard or i= s > there more work that should be done in IRTF?" > "Is there sufficient energy to get meaningful work done?" >=20 >=20 > So we should be addressing "What", not "How". I understand that this may be your opinion, but others have expressed a different opinion. > FYI: Anyone list participant can get information on who subscribed to a= n > IETF mail list if they remember their password (and you can ask for your > password to be resent). These lists are setup to be open, so the > participation list is not just available to the administrators. At least > that is my recollection and it has always worked for me. Also, since > anyone can sign up, basically, with minimal effort, anyone can see who > subscribed to an IETF list. That is fine; others who are curious about list membership can follow your instructions if they are interested. > If you go to dtn-interest and compare to dtn, the dtn-interest as far mor= e > participants. And, if they look, they will see that the dtn@ietf.org list membership is not insubstantial. Thanks - Fred fred.l.templin@boeing.com >=20 > Will >=20 >=20 >=20 > >Hi Will, > > > >> -----Original Message----- > >> From: Ivancic, William D. (GRC-RHN0) [mailto:william.d.ivancic@nasa.go= v] > >> 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 i= t > >>is > >> premature to consider these implementations until a working group is o= r > >>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 > >fred.l.templin@boeing.com > > > >> Will > >> > >> ****************************** > >> > >> > >> > >> > >> > >> > >> > >> On 6/17/14 4:20 PM, "Templin, Fred L" wrot= e: > >> > >> >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 liste= d > >> > below: > >> >.... From nobody Fri Jun 20 13:18:56 2014 Return-Path: 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 8C1E31B28F6 for ; Fri, 20 Jun 2014 13:18:53 -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 kdYqLhfirYzd for ; Fri, 20 Jun 2014 13:18:49 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.106]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AAF61B28E4 for ; Fri, 20 Jun 2014 13:18:49 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp02.jpl.nasa.gov [128.149.137.149]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s5KKIlE1021623 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO) for ; Fri, 20 Jun 2014 13:18:47 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.217]) by ap-ehub-sp02.RES.AD.JPL ([fe80::dd85:7b07:1e36:7e3c%15]) with mapi id 14.03.0174.001; Fri, 20 Jun 2014 13:18:47 -0700 From: "Burleigh, Scott C (312G)" To: "dtn@ietf.org" Thread-Topic: [dtn] rfc5050(bis) proposed revisions Thread-Index: AQHPivfJ2O/x4+1RG0Stzkfn5ML73Jt6YNQQgAAefQD///H0gA== Date: Fri, 20 Jun 2014 20:18:46 +0000 Message-ID: References: <2134F8430051B64F815C691A62D983183049098D@XCH-BLV-512.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.26] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/Wv2KR95z5mp9kgSI26l5u7DZQiI Subject: Re: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 20:18:53 -0000 Will, I certainly agree that it's unlikely that any decisions on any of the= se proposed revisions would emerge from conversations on this list, but it = seems reasonable to me at least to be open to explaining and discussing the= m. Wouldn't you agree that they fall under the heading of "What exactly an= d specifically should this group be working on if an IETF dtn working group= is formed?" This discussion might be especially helpful for people who ma= y be signed up to this list out of possible commercial interest, who may no= t be real familiar with all of the technical concepts we've been working wi= th over the past few years. Scott -----Original Message----- From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of Ivancic, William D. (G= RC-RHN0) Sent: Friday, June 20, 2014 1:00 PM To: Templin, Fred L; dtn@ietf.org Subject: Re: [dtn] rfc5050(bis) proposed revisions Fred, Implementations may not have been the best word choice, but there is a lot= of "How" in bpv7. What I meant was that Scott's propose revisions proba= bly do not belong on the BOF this list. It could quickly lead to discussion= s of specification changes and where pieces should go which is currently sh= ould occur on dtn-interest. Those should IMHO occur after the BOF, not before and not on the BOF list. Removing dictionary. Sort of specifying an addressing scheme (URL usage), Hop count as extension block, = how to do bundle security, etc... are better served on dtn-interest at this point in time. Just my opinion. By the way, I'm not saying these are wrong, just that they do not belong on the BOF list. I think the BOF list is suppose to be about "What exactly and specifically = should this group be working on if an IETF dtn working group is formed?" "Should IETF form a working group?", "Are the protocols at a state where they are ready for IETF standard or is = there more work that should be done in IRTF?" "Is there sufficient energy to get meaningful work done?" So we should be addressing "What", not "How". FYI: Anyone list participant can get information on who subscribed to an = IETF mail list if they remember their password (and you can ask for your pa= ssword to be resent). These lists are setup to be open, so the participatio= n list is not just available to the administrators. At least that is my rec= ollection and it has always worked for me. Also, since anyone can sign up,= basically, with minimal effort, anyone can see who subscribed to an IETF l= ist. If you go to dtn-interest and compare to dtn, the dtn-interest as far more = participants. Will >Hi Will, > >> -----Original Message----- >> From: Ivancic, William D. (GRC-RHN0)=20 >> [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 >>=20 >> While I appreciate Scott's work and taking time to write bpv7, I=20 >>think this list is not the place to discussion implementations and I=20 >>think it is premature to consider these implementations until a=20 >>working group is or is not formed (at which point we will know where=20 >>those discussions should occur). For now, IMHO, implementations=20 >>issues are probably best addressed on dtn-interest. > >I'm not sure why you say "implementations"; we are talking about=20 >specifications - not implementations. A discussion on the list of=20 >planned changes for RFC 5050(bis) I think is perfectly reasonable for=20 >this distribution. > >> Check the lists, there are far more subscribers on dtn-interest the=20 >> the dtn BOF list. > >List administrators have access to the list of subscribers and, while I=20 >can't say more, I can tell you that the membership of this list is not=20 >insubstantial. > >Thanks - Fred >fred.l.templin@boeing.com > >> Will >>=20 >> ****************************** >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On 6/17/14 4:20 PM, "Templin, Fred L" wrote: >>=20 >> >Hello, >> > >> >Below is a list of (proposed) revisions for rfc5050(bis) as found in=20 >> >Appendix A of 'draft-burleigh-bpv7'. Please post any comments or=20 >> >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: >> >.... _______________________________________________ dtn mailing list dtn@ietf.org https://www.ietf.org/mailman/listinfo/dtn From nobody Fri Jun 20 13:39:09 2014 Return-Path: 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 AF7C81B28F3 for ; Fri, 20 Jun 2014 13:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.149 X-Spam-Level: X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.651] 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 7QV1QKdwomoa for ; Fri, 20 Jun 2014 13:39:01 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0DA1B28AD for ; Fri, 20 Jun 2014 13:39:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9ED1BBE97; Fri, 20 Jun 2014 21:39:00 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHcGrJdO4hhq; Fri, 20 Jun 2014 21:38:58 +0100 (IST) Received: from [10.87.48.6] (unknown [86.44.75.216]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A1BBEBE8F; Fri, 20 Jun 2014 21:38:58 +0100 (IST) Message-ID: <53A49BE2.6010604@cs.tcd.ie> Date: Fri, 20 Jun 2014 21:38:58 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Burleigh, Scott C (312G)" , "dtn@ietf.org" References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> <2134F8430051B64F815C691A62D983183048B3B6@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983183048DB80@XCH-BLV-512.nw.nos.boeing.com> <53A09F61.2030900@cs.tcd.ie> <2134F8430051B64F815C691A62D983183048DD9A@XCH-BLV-512.nw.nos.boeing.com> <53A0A5B8.1090802@cs.tcd.ie> <53A0C339.2040106@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/SLzl51Nhvaji7XXCMgmNgNXtLeI Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 20:39:06 -0000 Hi Scott, On 18/06/14 19:00, Burleigh, Scott C (312G) wrote: > Hi, Stephen. I figure you're not saying that Boeing (or anybody > else) has got to disclose proprietary information or forego business > opportunities in order to make the BoF more compelling and the WG > more successful. Clearly. We can't force anyone to do anything. However, its pretty common that vendors do manage to say something about what it is they'd like to do with the IETF standard they want created. I can't think of any other case of "can't tell" from the main BoF proponent to be honest. (I do recall cases where what that proponent said wasn't very easy to believe, so Fred's doing better than that for sure:-) I also need to look at Kip's mail to see if there's more in that - its doesn't have to be Fred who offers use-cases. > What you're really telling us is that it would be > advantageous if the WG were simply able to focus on some use case > that is not an insignificant niche or a purely academic problem, > correct? Not necessarily the specific use case(s) that interest > Boeing, that Fred can't discuss, but at least something with > potentially significant impact. Not quite. Reality is what I'm after rather than plausible speculation - we've done quite a lot of the latter over the years in the RG and while that's well and good, its less good than reality. Cheers, S. PS: Didn't get into your reasonable scenario below on the basis of my argument above. Interesting stuff though. > > In that context, maybe it would be helpful to look at a project I've > been noodling with for the past few years. "Ring Road" would be a > DTN-based communication satellite network aimed (originally) at > provided extremely low-cost -- but high-latency -- network > communication service to communities that lack Internet access, > typically because they're geographically isolated, economically > disadvantaged, and/or temporarily devastated by natural or political > disaster. There's a summary presentation at > http://ipnsig.org/wp-content/uploads/2014/02/Ring-Road-applicationsRev1.pdf > which I would be more than happy to discuss on this list or > privately, with whoever is interested. > > I think that project constitutes the sort of focus we might be > looking for, as it's not a niche use case or a purely academic > problem. Potential users would be in the hundreds of thousands, > perhaps millions, so it's a sort of forcing function for scalability. > It's an open architecture, so standardization is necessary. It's > entirely deployable using DTN implementation software that can be > downloaded off the Internet, with very little additional development. > A lot of the configuration details have already been worked out, at > least to the level of back-of-the-envelope numbers. > > And deployment of this sort of capability is entirely plausible. > We've been in conversations with the Media Development Investment > Fund about infusing this architecture into a second stage of their > Outernet project, which initially is aiming only at downloading > content to subscribers but which may want to expand into > bidirectional networking once their constellation is deployed. > Beyond this, though, it would constitute an inexpensive way for any > large multinational entity -- a business, a group of collaborating > NGOs -- to construct its own entirely private worldwide communication > network. It could easily interconnect autonomous undersea vehicles in > mid-ocean with operators in Tennessee or Latvia, using BP end-to-end. > Alternatively, by somewhat increasing the size (and cost) of the > satellites and using more powerful radios we could evolve it into a > very low-cost, high-latency bulk data transfer infrastructure, which > would be quite good for large-scale multimedia distribution. Lots of > possibilities, I think. > > Scott > > -----Original Message----- From: Stephen Farrell > [mailto:stephen.farrell@cs.tcd.ie] Sent: Tuesday, June 17, 2014 3:38 > PM To: Burleigh, Scott C (312G); dtn@ietf.org Subject: Re: [dtn] > Draft Charter Discussion > > On 17/06/14 23:23, Burleigh, Scott C (312G) wrote: >> 1. The UAV industry is exploding. Nobody has any idea where the >> limits on applications of UAVs are, but what we do know is that the >> information that controls them is conveyed by radio, which is >> occasionally subject to disruption. Technology that could improve >> the safety and reliability of UAVs, while reducing cost, could find >> a large market. > > Excellent example. Now if we knew that that was a focus of interest > that'd be cool and we could discuss timing and contact requirements, > development environments, tooling etc. and how DTN protocols might > fit with e.g. telemetry/control. (Elwyn could even have fun with > routing - we have an old unfunded proposal along those lines;-) > > I'm not saying its a fatal problem that we only have the already > known use-cases, but new information such as a confirmation that your > good example was real (and were we to have folks who work in that > space involved), could make for a much more compelling BoF and likely > successful WG. > > S. > > _______________________________________________ dtn mailing list > dtn@ietf.org https://www.ietf.org/mailman/listinfo/dtn > > From nobody Fri Jun 20 13:48:15 2014 Return-Path: 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 BA6B71B2905 for ; Fri, 20 Jun 2014 13:48:11 -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 bASjTOrWR2F4 for ; Fri, 20 Jun 2014 13:48:08 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A47D31A02F8 for ; Fri, 20 Jun 2014 13:48:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s5KKm6EA025464; Fri, 20 Jun 2014 13:48:06 -0700 Received: from XCH-PHX-101.sw.nos.boeing.com (xch-phx-101.sw.nos.boeing.com [137.136.238.4]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s5KKluE7025373 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 20 Jun 2014 13:47:57 -0700 Received: from XCH-BLV-512.nw.nos.boeing.com ([169.254.12.74]) by XCH-PHX-101.sw.nos.boeing.com ([169.254.8.231]) with mapi id 14.03.0181.006; Fri, 20 Jun 2014 13:47:55 -0700 From: "Templin, Fred L" To: Stephen Farrell , "Burleigh, Scott C (312G)" , "dtn@ietf.org" Thread-Topic: [dtn] Draft Charter Discussion Thread-Index: Ac+GbO3wN7xIp4CqSFeVEjvJc65+vAAPLd8AAAy+SjAAJnyrgAC3CG0QABPXfIAADpF2cAB62GKTAAAz2XA= Date: Fri, 20 Jun 2014 20:47:55 +0000 Message-ID: <2134F8430051B64F815C691A62D9831830490B6A@XCH-BLV-512.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> <2134F8430051B64F815C691A62D983183048B3B6@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983183048DB80@XCH-BLV-512.nw.nos.boeing.com> <53A09F61.2030900@cs.tcd.ie> <2134F8430051B64F815C691A62D983183048DD9A@XCH-BLV-512.nw.nos.boeing.com> <53A0A5B8.1090802@cs.tcd.ie> <53A0C339.2040106@cs.tcd.ie> <53A49BE2.6010604@cs.tcd.ie> In-Reply-To: <53A49BE2.6010604@cs.tcd.ie> 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/JaQCO0BJ_Ao11ZnpW1yc_GIRjl4 Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 20:48:11 -0000 Hi Stephen, > -----Original Message----- > From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of Stephen Farrell > Sent: Friday, June 20, 2014 1:39 PM > To: Burleigh, Scott C (312G); dtn@ietf.org > Subject: Re: [dtn] Draft Charter Discussion >=20 >=20 > Hi Scott, >=20 > On 18/06/14 19:00, Burleigh, Scott C (312G) wrote: > > Hi, Stephen. I figure you're not saying that Boeing (or anybody > > else) has got to disclose proprietary information or forego business > > opportunities in order to make the BoF more compelling and the WG > > more successful. >=20 > Clearly. We can't force anyone to do anything. >=20 > However, its pretty common that vendors do manage to say > something about what it is they'd like to do with the IETF > standard they want created. I can't think of any other case of > "can't tell" from the main BoF proponent to be honest. (I do > recall cases where what that proponent said wasn't very easy > to believe, so Fred's doing better than that for sure:-) >=20 > I also need to look at Kip's mail to see if there's more > in that - its doesn't have to be Fred who offers use-cases. If you follow up on the thread Kip was posting to, you'll see that I gave it a +i (for some value of i between 0 an 1). Thanks - Fred fred.l.templin@boeing.com > > What you're really telling us is that it would be > > advantageous if the WG were simply able to focus on some use case > > that is not an insignificant niche or a purely academic problem, > > correct? Not necessarily the specific use case(s) that interest > > Boeing, that Fred can't discuss, but at least something with > > potentially significant impact. >=20 > Not quite. Reality is what I'm after rather than plausible > speculation - we've done quite a lot of the latter over the > years in the RG and while that's well and good, its less good > than reality. >=20 > Cheers, > S. >=20 > PS: Didn't get into your reasonable scenario below on the > basis of my argument above. Interesting stuff though. >=20 >=20 > > > > In that context, maybe it would be helpful to look at a project I've > > been noodling with for the past few years. "Ring Road" would be a > > DTN-based communication satellite network aimed (originally) at > > provided extremely low-cost -- but high-latency -- network > > communication service to communities that lack Internet access, > > typically because they're geographically isolated, economically > > disadvantaged, and/or temporarily devastated by natural or political > > disaster. There's a summary presentation at > > http://ipnsig.org/wp-content/uploads/2014/02/Ring-Road-applicationsRev1= .pdf > > which I would be more than happy to discuss on this list or > > privately, with whoever is interested. > > > > I think that project constitutes the sort of focus we might be > > looking for, as it's not a niche use case or a purely academic > > problem. Potential users would be in the hundreds of thousands, > > perhaps millions, so it's a sort of forcing function for scalability. > > It's an open architecture, so standardization is necessary. It's > > entirely deployable using DTN implementation software that can be > > downloaded off the Internet, with very little additional development. > > A lot of the configuration details have already been worked out, at > > least to the level of back-of-the-envelope numbers. > > > > And deployment of this sort of capability is entirely plausible. > > We've been in conversations with the Media Development Investment > > Fund about infusing this architecture into a second stage of their > > Outernet project, which initially is aiming only at downloading > > content to subscribers but which may want to expand into > > bidirectional networking once their constellation is deployed. > > Beyond this, though, it would constitute an inexpensive way for any > > large multinational entity -- a business, a group of collaborating > > NGOs -- to construct its own entirely private worldwide communication > > network. It could easily interconnect autonomous undersea vehicles in > > mid-ocean with operators in Tennessee or Latvia, using BP end-to-end. > > Alternatively, by somewhat increasing the size (and cost) of the > > satellites and using more powerful radios we could evolve it into a > > very low-cost, high-latency bulk data transfer infrastructure, which > > would be quite good for large-scale multimedia distribution. Lots of > > possibilities, I think. > > > > Scott > > > > -----Original Message----- From: Stephen Farrell > > [mailto:stephen.farrell@cs.tcd.ie] Sent: Tuesday, June 17, 2014 3:38 > > PM To: Burleigh, Scott C (312G); dtn@ietf.org Subject: Re: [dtn] > > Draft Charter Discussion > > > > On 17/06/14 23:23, Burleigh, Scott C (312G) wrote: > >> 1. The UAV industry is exploding. Nobody has any idea where the > >> limits on applications of UAVs are, but what we do know is that the > >> information that controls them is conveyed by radio, which is > >> occasionally subject to disruption. Technology that could improve > >> the safety and reliability of UAVs, while reducing cost, could find > >> a large market. > > > > Excellent example. Now if we knew that that was a focus of interest > > that'd be cool and we could discuss timing and contact requirements, > > development environments, tooling etc. and how DTN protocols might > > fit with e.g. telemetry/control. (Elwyn could even have fun with > > routing - we have an old unfunded proposal along those lines;-) > > > > I'm not saying its a fatal problem that we only have the already > > known use-cases, but new information such as a confirmation that your > > good example was real (and were we to have folks who work in that > > space involved), could make for a much more compelling BoF and likely > > successful WG. > > > > S. > > > > _______________________________________________ dtn mailing list > > dtn@ietf.org https://www.ietf.org/mailman/listinfo/dtn > > > > >=20 > _______________________________________________ > dtn mailing list > dtn@ietf.org > https://www.ietf.org/mailman/listinfo/dtn From nobody Fri Jun 20 13:58:38 2014 Return-Path: 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 9F6821B28ED for ; Fri, 20 Jun 2014 13:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 f6XtB-1V2131 for ; Fri, 20 Jun 2014 13:58:35 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 40ACE1B28E8 for ; Fri, 20 Jun 2014 13:58:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 94512BEAA; Fri, 20 Jun 2014 21:58:34 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzHbnc7TB5bJ; Fri, 20 Jun 2014 21:58:33 +0100 (IST) Received: from [10.87.48.6] (unknown [86.44.75.216]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7E47FBE98; Fri, 20 Jun 2014 21:58:33 +0100 (IST) Message-ID: <53A4A079.8060708@cs.tcd.ie> Date: Fri, 20 Jun 2014 21:58:33 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Ivancic, William D. (GRC-RHN0)" , "Templin, Fred L" , "dtn@ietf.org" References: <2134F8430051B64F815C691A62D983183049098D@XCH-BLV-512.nw.nos.boeing.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/r_p8XIQzjjM8m96X3h5cw1Yqegw Subject: Re: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 20:58:36 -0000 Hi Will, On 20/06/14 21:00, Ivancic, William D. (GRC-RHN0) wrote: > What I meant was that Scott's propose revisions > probably do not belong on the BOF this list. Gotta disagree with you again there. If discussion of the specific technology proposal were not allowed that'd be fairly mad. Discussion of whether to do it etc. is of course also needed and has been happening. S. From nobody Fri Jun 20 14:26:20 2014 Return-Path: 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 62AEA1B290F for ; Fri, 20 Jun 2014 14:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 9OGVZVJfGbav for ; Fri, 20 Jun 2014 14:26:08 -0700 (PDT) Received: from b.b.painless.aa.net.uk (b.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 036651B290E for ; Fri, 20 Jun 2014 14:26:07 -0700 (PDT) Received: from mightyatom.folly.org.uk ([81.187.254.250]) by b.painless.aa.net.uk with esmtp (Exim 4.72) (envelope-from ) id 1Wy6Jo-0001g5-Hf; Fri, 20 Jun 2014 22:26:00 +0100 From: Elwyn Davies To: "Templin, Fred L" In-Reply-To: <2134F8430051B64F815C691A62D983183049098D@XCH-BLV-512.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983183049098D@XCH-BLV-512.nw.nos.boeing.com> Content-Type: text/plain Organization: Folly Consulting Date: Fri, 20 Jun 2014 22:25:55 +0100 Message-Id: <1403299555.2995.5459.camel@mightyatom> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/5CQ5GEweMkAEjuY8Q8I1nXaOEKo Cc: "dtn@ietf.org" , "Ivancic, William D. \(GRC-RHN0\)" Subject: [dtn] List roster counts [was: Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 21:26:15 -0000 > > > 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 > fred.l.templin@boeing.com FYI There are currently 81 subscribers on dtn vs about 1100 on dtn-interest. All list subscribers can check the rosters. https://www.ietf.org/mailman/listinfo/dtn(-interest) using the password in your monthly reminder email if you can't remember. /Elwyn From nobody Fri Jun 20 14:57:56 2014 Return-Path: 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 5E1511A031C for ; Fri, 20 Jun 2014 14:57:54 -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 zzG7Zze3cM9C for ; Fri, 20 Jun 2014 14:57:52 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C80E1A0283 for ; Fri, 20 Jun 2014 14:57:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s5KLvp2U013258; Fri, 20 Jun 2014 14:57:51 -0700 Received: from XCH-PHX-303.sw.nos.boeing.com (xch-phx-303.sw.nos.boeing.com [137.136.239.24]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s5KLvftD012748 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 20 Jun 2014 14:57:42 -0700 Received: from XCH-BLV-210.nw.nos.boeing.com (137.136.239.111) by XCH-PHX-303.sw.nos.boeing.com (137.136.239.24) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 20 Jun 2014 14:57:41 -0700 Received: from XCH-BLV-512.nw.nos.boeing.com ([169.254.12.74]) by XCH-BLV-210.nw.nos.boeing.com ([169.254.10.120]) with mapi id 14.03.0181.006; Fri, 20 Jun 2014 14:57:40 -0700 From: "Templin, Fred L" To: Elwyn Davies Thread-Topic: List roster counts [was: Re: [dtn] rfc5050(bis) proposed revisions] Thread-Index: AQHPjNKnGmHSsyEpy0aJr3Sj20TOHw== Date: Fri, 20 Jun 2014 21:57:40 +0000 Message-ID: <2134F8430051B64F815C691A62D9831830490C30@XCH-BLV-512.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983183049098D@XCH-BLV-512.nw.nos.boeing.com> <1403299555.2995.5459.camel@mightyatom> In-Reply-To: <1403299555.2995.5459.camel@mightyatom> 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/TmuPPv-ibwgReFZOWDhY5yG_44o Cc: "dtn@ietf.org" , "Ivancic, William D. \(GRC-RHN0\)" Subject: Re: [dtn] List roster counts [was: Re: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 21:57:54 -0000 > -----Original Message----- > From: Elwyn Davies [mailto:elwynd@folly.org.uk] > Sent: Friday, June 20, 2014 2:26 PM > To: Templin, Fred L > Cc: Ivancic, William D. (GRC-RHN0); dtn@ietf.org > Subject: List roster counts [was: Re: [dtn] rfc5050(bis) proposed revisio= ns] >=20 >=20 > > > > > 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 > > fred.l.templin@boeing.com >=20 > FYI >=20 > There are currently 81 subscribers on dtn vs about 1100 on dtn-interest. >=20 > All list subscribers can check the rosters. > https://www.ietf.org/mailman/listinfo/dtn(-interest) >=20 > using the password in your monthly reminder email if you can't remember. Before anyone thinks I was trying to hide something, let me just clarify that I did not know this information was available to general users. I was being clueless - not devious. So, thanks to Elwyn for explaining this option that is available to all subscribers. So, Will is right that there are many more members on dtn-interest than dtn. And, I am also right that 81 is not an insubstantial number. And, Stephen is also right that numbers don't matter. Thanks - Fred fred.l.templin@boeing.com > /Elwyn >=20 From nobody Fri Jun 20 17:15:15 2014 Return-Path: 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 B828A1A041F for ; Fri, 20 Jun 2014 17:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no 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 tISeZOLwfqe2 for ; Fri, 20 Jun 2014 17:15:11 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E95F31A0319 for ; Fri, 20 Jun 2014 17:15:10 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id s7so2793687lbd.18 for ; Fri, 20 Jun 2014 17:15:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Q5ynloqJUdtIkXmJrfH625Sowmwc3aFqcOCfeyXwdwA=; b=tUJ3MySTmbFm+2e0BQj7KZ3ovbIJeFyLeR0TTn7eg8MHYT2jL7HcNDuiyX6MN3Bvoj 7aID6BfxrlO5X5vO1gMcC+nhL6jmiPVpuQV9CAJWvKgjJRQfC8qkMxJsqAoSjGA6h282 NMp594zKyxs5OLipM5e/VuiXRltdxMMUDLE8FU7DjlMKltl0QIoVixskdwAwRdva0lg/ QzFR7Zm0muatGQoYDeADRH1993jaxpx1LUjNjzw+0zYVkeQLeAt6MqL/HiPhLNMbuZug zAGupnUdgPNkxKuNYeRjA8J/zCX5qxxvpZ6d9rjnPqv8kyqHdQpjMT7R9sGlVdJowhgP 84Lg== MIME-Version: 1.0 X-Received: by 10.112.210.9 with SMTP id mq9mr4552544lbc.47.1403309709274; Fri, 20 Jun 2014 17:15:09 -0700 (PDT) Sender: jeferson.nobre@gmail.com Received: by 10.112.146.228 with HTTP; Fri, 20 Jun 2014 17:15:09 -0700 (PDT) Date: Fri, 20 Jun 2014 21:15:09 -0300 X-Google-Sender-Auth: XR7H4f6GknClgsFCK_cUwHR_VaI Message-ID: From: =?UTF-8?Q?J=C3=A9ferson_Campos_Nobre?= To: dtn@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/wBaVVtNOfktzCYAt5Gh_jEZessU Subject: [dtn] DTN Management Drafts X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jun 2014 00:15:13 -0000 Hi. With network management as an item of the DTN BoF, I think we should pay attention to the DTN management drafts.To my knowledge, all drafts are expired now. The requirements drafts (draft-ivancic-dtnrg-network-management and draft-clark-dtnrg-netman-req) are expired for a long time, but I think they can be important to define what to expect of network management features in a possible DTNWG. Concerning protocol ones (draft-irtf-dtnrg-dtnmp and draft-irtf-dtnrg-ding-network-management), only DTNMP has received attention recently, although I believe DING was mentioned in the last discussions (not sure if here or in the dtn-interest list). Returning to the DTN BoF: since we have these draft they could/should appear in the problem statement and solutions items? Cheers. J=C3=A9ferson Campos Nobre PhD Student Computer Networks Group - Institute of Informatics Federal University of Rio Grande do Sul http://www.inf.ufrgs.br/~jcnobre From nobody Fri Jun 20 18:02:04 2014 Return-Path: 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 ADE5A1B291A for ; Fri, 20 Jun 2014 18:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.853 X-Spam-Level: X-Spam-Status: No, score=-4.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 B8X-RaJvKY8B for ; Fri, 20 Jun 2014 18:01:55 -0700 (PDT) Received: from pilot.jhuapl.edu (pilot.jhuapl.edu [128.244.251.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 007021B2919 for ; Fri, 20 Jun 2014 18:01:54 -0700 (PDT) Received: from aplexcas2.dom1.jhuapl.edu (unknown [128.244.198.91]) by pilot.jhuapl.edu with smtp (TLS: TLSv1/SSLv3,128bits,RC4-MD5) id 400a_0e85_2f448bba_8cbf_4d97_87fe_db8205708ea7; Fri, 20 Jun 2014 21:01:44 -0400 Received: from aplesfreedom.dom1.jhuapl.edu ([128.244.198.204]) by aplexcas2.dom1.jhuapl.edu ([128.244.198.91]) with mapi; Fri, 20 Jun 2014 21:01:42 -0400 From: "Birrane, Edward J." To: Stephen Farrell , "Templin, Fred L" , "dtn@ietf.org" Date: Fri, 20 Jun 2014 21:01:42 -0400 Thread-Topic: [dtn] Draft Charter Discussion Thread-Index: Ac+Kdz4lVZ15II90TOSVI2i3Fkm9OACcO1Bm Message-ID: <329D879C76FDD04AAAE84BB1D89B39700957131B87@aplesfreedom.dom1.jhuapl.edu> References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> <2134F8430051B64F815C691A62D983183048B3B6@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983183048DB80@XCH-BLV-512.nw.nos.boeing.com> <53A09F61.2030900@cs.tcd.ie> <2134F8430051B64F815C691A62D983183048DD9A@XCH-BLV-512.nw.nos.boeing.com> <53A0A5B8.1090802@cs.tcd.ie> <329D879C76FDD04AAAE84BB1D89B397009572F23C8@aplesfreedom.dom1.jhuapl.edu>, <53A0B9F1.30609@cs.tcd.ie> In-Reply-To: <53A0B9F1.30609@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/guCH-ZVDHKuXGA2LRRfALGuKqAo Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jun 2014 01:02:02 -0000 Hi Stephen, Sorry for pruning, my web mail client is acting up... > > So, why DTN in non-space cases? > > > > - Some like the protocol bits (blocks, custody xfer, queuing, reporting= structure) as a consolidated standard and not a layered set of standards a= nd best practices. > > - Some like the automation for delay/disrupted and scaled deployments -= it cuts down on their one-off app point solutions. > > - Some feel that their analyses indicate DTN overlays can simplify comp= lex architectures such as TCP PEPs, including how to integrate differing ne= tworks using different queuing models. > > - Some sensor networks behave quite similarly to space networks regardi= ng disruption. Underwater scenarios also look similar in terms of delay. > > > > Not an exhaustive list, but the highlights from why people are interest= ed in a standard that pulls these bits together. > > > > > > So, why no scaled DTN deployments yet outside of NASA baselines? > > > > - The security mechanism looked overly complex and hard to verify. > > - There was no progress on management, especially in access-denied and = open-loop areas. > > - The protocol specs are described in experimental RFCs, with discussio= n of a bis. > > The above is all well and good, but is mostly the kind of argument > we've made over the years in the DTNRG. Not that its wrong or bad, > but its not new. (You're very positive though, so not complete:-) Agreed that the above benefits of the technology to potential deployments a= re not new. But we haven't attached a TTL on good ideas or desirable proper= ties.=20 > > > > So, why now? > > > > - There has been progress on simplifying the security implementations b= ased on lessons learned. > > - There is some promising progress (yes, through NASA, but not NASA cen= tric) on disruption-scaling management concepts. > > - There is a set of lessons learned informing 5050bis/BPv7. To Fred's = schedule, this can be resolved in relatively short order. >=20 > Sure. But nothing in the above provides a strong argument > for a WG that I can see. =20 We have a clever protocol to handle sticky connectivity situations. We have= a decade of experience with that protocol and other standards/protocols ar= ound it. We have entities wanting to implement these things as non-experime= ntal standards in operational networks. We have activity in areas necessary= to cover operational deployments, such as security and NM. We have identif= ied an important set of updates to the experimental standard and a communit= y of funded people willing to do the standards work. IMO, those are all true statements and, together, are a fine argument for d= oing the work. > Proof is the wrong word. From my POV the only new thing I've > seen here so far is Fred saying Boeing would like this to > happen (but not quite why). That they want it is a good thing. > More folks and more detail would be better of course as > that would give more confidence we're solving the right > problem and our solution might get widely deployed. > > There are no hard and fast numbers but I don't believe we've > seen new participants turning up saying that they want this > and why. (I.e. not a bare "+1" mail, but something real.) > We have seen known DTNRG participants saying that which is > also good, but also not really new. >=20 > And don't get me wrong, even though I would write a quite > different charter, I'm still supportive of this one if we > end up with it. But folks will be asking these questions. I do understand this. I have had many more conversations (sadly off list) = that have removed from my mind the question of commercial interest, partici= pation, and deployment. However, so much of it surrounds new deployment str= ategies, products, services, etc... that DTN considerations get pulled too = quickly behind the business proprietary curtain.=20 Besides Boeing and NASA, I know of at least 2 other companies that have fun= ded activity related to DTN deployed in their products. I am aware of 3 or = 4 others that have either addressed or advertised DTN in their proposals an= d marketing literature. I have been asked quite a few times "when will the = DTN protocols be ready for us to adopt", the implied question being "when w= ill the standard stop being experimental". I freely admit that is a bunch o= f hearsay, but it is what I can offer right now. -Ed From nobody Fri Jun 20 18:16:16 2014 Return-Path: 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 0A9AA1A02F9 for ; Fri, 20 Jun 2014 18:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.954 X-Spam-Level: X-Spam-Status: No, score=-2.954 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 I_V9W9xiU_x0 for ; Fri, 20 Jun 2014 18:16:07 -0700 (PDT) Received: from pilot.jhuapl.edu (pilot.jhuapl.edu [128.244.251.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E979D1A0178 for ; Fri, 20 Jun 2014 18:16:06 -0700 (PDT) Received: from aplexcas2.dom1.jhuapl.edu (unknown [128.244.198.91]) by pilot.jhuapl.edu with smtp (TLS: TLSv1/SSLv3,128bits,RC4-MD5) id 400a_1101_bd766fc3_9064_45a2_9e37_0895f43c5f88; Fri, 20 Jun 2014 21:15:55 -0400 Received: from aplesfreedom.dom1.jhuapl.edu ([128.244.198.204]) by aplexcas2.dom1.jhuapl.edu ([128.244.198.91]) with mapi; Fri, 20 Jun 2014 21:15:56 -0400 From: "Birrane, Edward J." To: "Burleigh, Scott C (312G)" , "dtn@ietf.org" Date: Fri, 20 Jun 2014 21:15:56 -0400 Thread-Topic: [dtn] Draft Charter Discussion Thread-Index: Ac+GbO3wN7xIp4CqSFeVEjvJc65+vAAPLd8AAAy+SjAAJnyrgAC3CG0QABPXfIAADpF2cP//kwMAgABi+uCABCqw4A== Message-ID: <329D879C76FDD04AAAE84BB1D89B39700957131B88@aplesfreedom.dom1.jhuapl.edu> References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> <2134F8430051B64F815C691A62D983183048B3B6@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983183048DB80@XCH-BLV-512.nw.nos.boeing.com> <53A09F61.2030900@cs.tcd.ie> <2134F8430051B64F815C691A62D983183048DD9A@XCH-BLV-512.nw.nos.boeing.com> <53A0A5B8.1090802@cs.tcd.ie>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/J0FazV4Rv9jYeeSxdBufN-A4xmQ Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jun 2014 01:16:12 -0000 We really can't stress point 3 enough. The industrialization of near-earth= space is growing. In doing so, it is also transitioning away from space a= gencies and large aerospace. The companies I have talked with want their gr= ound infrastructure, space infrastructure, and peers integrated in a single= end-to-end overlay. Ultimately, I have seen a commercial desire to make the Internet of Things = into the Internet of Moving Things. DTN is not a magical cure for that, but= it is seen as a reasonable part of the puzzle. -Ed ________________________________________ From: dtn [dtn-bounces@ietf.org] On Behalf Of Burleigh, Scott C (312G) [sco= tt.c.burleigh@jpl.nasa.gov] Sent: Tuesday, June 17, 2014 6:23 PM To: dtn@ietf.org Subject: Re: [dtn] Draft Charter Discussion Okay, taking another crack at this. I think there are two levels of question here, one implying the other, and = it might be helpful to address them separately. First the proximate question: given that DTN exists, why standardize it? W= hy not just use it as it is? What has changed? I think the answer there, to which Fred and Ed have alluded, is that there = are business entities that would now like to use DTN to solve some communic= ation problems (or exploit some opportunities) but won't risk doing so whil= e the protocols are not standards. I know Ed works with such entities on a= regular basis, and the fact that Boeing is willing to invest some time and= money in this BoF seems to suggest that they at least are another such ent= ity. So then the underlying question: what are those problems and opportunities = for which a standardized DTN would be used? As Fred has pointed out, organizations that hope to make money from these i= deas are not likely to disclose them here or in the BoF. But, just from my= own reading of the news, let me suggest a couple of potential DTN use case= s that go beyond the ISS and Saami deployments we're all familiar with. 1. The UAV industry is exploding. Nobody has any idea where the limits on= applications of UAVs are, but what we do know is that the information that= controls them is conveyed by radio, which is occasionally subject to disru= ption. Technology that could improve the safety and reliability of UAVs, w= hile reducing cost, could find a large market. 2. The speed of sound underwater is 1.5 km/sec, so the round-trip time bet= ween two underwater entities communicating by acoustic modem and separated = by a distance of 7.5 km is about equal to the round-trip time between Earth= and the Earth/Sun L2 Lagrange point. Since the data rates of acoustic mod= ems are low, efficient delay-tolerant networking is a pretty good way to es= tablish underwater communication. The market for underwater sensors and in= strumentation is already in the billions of dollars; revenue in the autonom= ous underwater vehicle manufacturing industry is growing at nearly 14% per = year. 3. The "space" use case is arguably still small if you restrict it to the = vehicles that are in orbit. If you extend the space communication use case= to users on Earth who will need to communicate with spacecraft over the ne= xt two decades, as Earth orbit becomes increasingly industrialized, then yo= u find yourself talking about a very large user community. And I am pretty sure there are more that I'm not aware of. The basic propo= sition is that the Internet is an outstanding communications solution for a= ll parts of Earth's surface that are relatively easy to get to, but there a= re business opportunities that are beyond its current reach. DTN can help = extend that outstanding communications solution to currently Internet-inhos= pitable parts of the Earth and near-Earth, benefiting a lot of people. Sta= ndardizing it will help make that happen. As Vint remarked in one of our c= onversations on this topic (I paraphrase freely), the Internet didn't get c= reated because somebody thought of a killer app; people thought of killer a= pps because there was an Internet. Scott -----Original Message----- From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of Stephen Farrell Sent: Tuesday, June 17, 2014 1:32 PM To: Templin, Fred L; dtn@ietf.org Subject: Re: [dtn] Draft Charter Discussion Hi Fred, On 17/06/14 21:12, Templin, Fred L wrote: > Hi Stephen, > >> -----Original Message----- >> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >> Sent: Tuesday, June 17, 2014 1:05 PM >> To: Templin, Fred L; dtn@ietf.org >> Subject: Re: [dtn] Draft Charter Discussion >> >> >> Fred and others, >> >> I think I've asked this before so apologies if I just forget the good >> answer;-) >> >> We have the space use-case and some fairly well known niche >> terrestrial use-cases, which are fine. But we've known these for >> years and the DTNRG didn't want to move to the standards track until >> now. > > Yes, a diverse set of use cases and not a single use case. That means > that in the early days there may be many purpose-built DTNs that may > at a later time be joined together to form larger DTNs. > A "DTN-of-DTNs" in the same way that the Internet is a "network- > of-networks". > > The whole reason the Internet was able to join together smaller > networks to form larger networks is that the Internet had > interoperable standards from the very beginning. It is now time for us > to do that for DTN. I'm familiar with DTN. But I find the above a pretty complete non-answer to= the question asked (in that it answers no part of my question:-) So I'll t= ry again, in a more direct fashion... I do not know why specifically Boeing want a standards track RFC5050bis, no= r why you want it now. And I'm wondering and would like to know. I have not heard your use-case (o= r business case, whatever) explained so far. Nor have I heard someone say "can't/won't tell, sorry." So I'm curious. And I'll note once again that successful BoFs tend to involve explaining wh= y this, now, specifically. As an IESG member it makes it much easier for me= to evaluate proposals for forming a WG. (BTW, any answer that asks me to think like an acorn won't really work for = this question, sorry:-) If someone else has a new answer to this question that would also be intere= sting. By new, I mean a use-case or business-case that hasn't previously be= en discussed in the DTNRG. Cheers, S. PS: In case there's confusion. My question is very much not the same as Wil= l's, despite your answer being very similar. > > Thanks - Fred > fred.l.templin@boeing.com > >> I think it'd help the IESG to decide whether to approve a WG if there >> were more information available about what has changed to motivate >> moving to the standards track. >> >> If (say for Boeing) those are such that you can't say and there >> aren't any others who can, then that's a pity, since it does make it >> harder to get why a 5050bis on the standards track is attractive. >> >> I'm just noting this again because I think many recent successful >> BoFs have tended to have this topic as part of the agenda, but it >> seems missing in yours, which just assumes that the room knows that >> RFC5050 needs a bit of work. (I'm exaggerating a bit there, but I >> hope you get what I mean.) >> >> S. >> >> On 17/06/14 18:40, Templin, Fred L wrote: >>> Please see below for an updated version of the draft charter based >>> on list discussions, and post any further comments in follow-up. >>> (See also attached for diffs relative to the previous version.) >>> >>> Thanks - Fred >>> fred.l.templin@boeing.com >>> >>> --- >>> >>> Draft BoF Agenda (2.5hrs): >>> ************************** >>> 1) Problem statement (IETF wg motivation) - 30min >>> >>> 2) RFC5050(bis) - 15min >>> >>> 3) Streamlined Bundle Security Protocol (SBSP) - 15min >>> >>> 4) Security Key Management - 10min >>> >>> 5) Network Management - 10min >>> >>> 6) Contact Graph Routing and Contact Plan Update Protocol - 10min >>> >>> 7) Bundle-in-Bundle Encapsulation - 5min >>> >>> 8) Registry for Service Identifiers - 5min >>> >>> 9) Open Discussion - 50min >>> >>> >>> Draft working group charter: >>> **************************** >>> Working group name: >>> >>> Delay/Disruption Tolerant Networking Working Group (DTNWG) >>> >>> Chair(s): >>> >>> TBD >>> >>> Area and Area Director(s): >>> >>> Transport Area: ADs Spencer Dawkins , >>> Martin Stiemerling >>> >>> Responsible Area Director: >>> >>> TBD >>> >>> Mailing list: >>> >>> General Discussion: dtn at ietf.org >>> To Subscribe: https://www.ietf.org/mailman/listinfo/dtn >>> Archive: >>> http://www.ietf.org/mail-archive/web/dtn/current/maillist.html >>> >>> Description of Working Group: >>> >>> The Delay/Disruption Tolerant Network Working Group (DTNWG) speci= fies >>> mechanisms for data communications in the presence of long delays >>> and/or intermittent connectivity. The work is motivated by well k= nown >>> limitations of standard Internet protocols that expect end-to-end >>> connectivity between communicating endpoints, sub-second transmis= sion >>> delays and robust packet delivery ratios. In environments where t= hese >>> favorable conditions do not apply, existing mechanisms encounter = problems >>> such as reliable transport protocol handshakes timing out and rou= ting >>> protocols failing to converge resulting in communication failures= . >>> Furthermore, classical end-to-end security associations cannot be >>> coordinated when communicating endpoints cannot conduct multi-mes= sage >>> keying exchanges in a timely fashion. These limitations suggested= the >>> need for a new approach. >>> >>> Delay-Tolerant Networking (DTN) protocols have been the subject o= f >>> extensive research and development in the Delay-Tolerant Networki= ng >>> Research Group (DTNRG) of the Internet Research Task Force since = 2002. >>> The DTNRG has developed the Delay-Tolerant Networking Architectur= e >>> (RFC 4838) that the DTNWG uses as the basis for its work. The ke= y >>> components of the this architecture are the bundle concept for >>> encapsulating data units, the bundle transmission protocol and th= e >>> underlying convergence layer architecture. >>> >>> The experimental DTN Bundle Protocol (RFC 5050) and Licklider >>> Transmission Protocol (RFC 5326) have been shown to address the >>> issues identified above in substantial fielded deployments in the= space >>> sector [1]. RFC 5050 in conjunction with TCP- and UDP-based conv= ergence >>> layers has been used successfully in a number of experiments both= in >>> communications challenged environments around the edges of the In= ternet >>> and as an Internet overlay where applications require delay- and/= or >>> disruption-tolerance [refs needed]. >>> >>> The success of the BP over convergence layer protocol stack -- th= e core >>> protocols of the "DTN Architecture" described in RFC 4838 -- may = be >>> attributed to the following fundamental design principles: >>> >>> - There is never any expectation of contemporaneous end-to-end >>> connectivity between any two network nodes. >>> >>> - Because end-to-end connectivity can never be assumed, each node >>> on the path between source and destination must be prepared to >>> handle incoming "bundles" of data that cannot immediately be >>> forwarded. >>> >>> - Again because end-to-end connectivity can never be assumed, >>> end-to-end conversational data exchange can never be assumed to >>> complete in a timely manner; protocol features that rely on >>> timely conversational data exchange must be excluded from the >>> architecture. >>> >>> The DTNWG believes that protocols adhering to these principles of= fer >>> opportunities for enhancing the functionality of the Internet, >>> including >>> >>> - facilitating the extension of the Internet into environments = such as >>> the ocean floor and deep space in which the core Internet pro= tocols >>> operate sub-optimally for the reasons discussed earlier; >>> >>> - extending the Internet into communications challenged terrest= rial >>> environments where it is not possible to provide continuous, = low >>> delay Internet connections; and >>> >>> - supporting Internet applications that need DTN capabiliies. >>> >>> We believe that the extensive research, demonstration, and >>> pilot operations performed to date using the DTNRG protocols prov= ides >>> a firm basis for publishing Internet standards derived from that = work. >>> >>> Work items related to Delay/Disruption Tolerant Networking includ= e: >>> >>> o A mechanism for the exchange of protocol data units, termed >>> "bundles", that are designed to obviate conversational communica= tions >>> by containing values for all potentially relevant configuration >>> parameters. These protocol data units are typically larger than >>> network-layer packets. We will derive this bundle exchange mecha= nism >>> from the DTN Bundle Protocol (BP) documented in RFC 5050 by pub= lishing >>> a new document for which [2] is a proposed first draft (where >>> appendix A provides a summary of the proposed changes). >>> >>> o A security protocol for ensuring that the network in which bund= les >>> are exchanged is secured against unauthorized access and denial = of >>> service attacks, and to ensure data integrity and confidentialit= y >>> in that network where necessary. We will derive this security >>> protocol from a "streamlined" adaptation of the DTN Bundle Secur= ity >>> Protocol documented in RFC 6257. >>> >>> o A delay-tolerant security key management scheme that can prote= ct >>> the integrity of a DTN network. >>> >>> o A simple datagram convergence layer protocol for adaptation of = the >>> bundle protocol to underlying internetworks. We expect to deriv= e >>> this convergence layer protocol from the Datagram Convergence >>> protocol documented in RFC 7122. >>> >>> o A protocol for remote status monitoring, configuration, and >>> administration of network nodes in the presence of long delays >>> and/or intermittent connectivity. >>> >>> o A functional specification of Contact Graph Routing (CGR) speci= fying >>> the inputs (global contact schedules, traffic demands, etc.) an= d >>> outputs (node specific transmission and reception schedules, >>> notifications, etc.). CGR is a centralized, oracle-based bundl= e >>> transmission and reception scheduling scheme used in space segm= ent >>> DTN deployments. >>> >>> o An adjunct to the management protocol that will allow the conta= ct >>> schedules generated by CGR to be distributed to nodes. This ma= y be >>> based on the Contact Plan Update Protocol (CPUP) proposed in >>> >>> o An encapsulation protocol for "tunneling" BP traffic within bun= dles >>> that are secured and/or routed in different way from the encapsu= lated >>> bundles. >>> >>> o A registry for DTN Service Identifiers >>> >>> The working group will consider extending the current milestones ba= sed on >>> new information and knowledge gained while working on the initial c= harter, >>> as well as to accommodate new work items beyond the scope of the in= itial >>> phase. For example, we expect that transport protocols such as LTP= and >>> the Saratoga protocol are among the candidates for work in this pha= se. >>> >>> Goals and Milestones: >>> start+0mos - Accept 'Bundle Protocol Specification (RFC5050bis)' [2] = as >>> a working group work item intended for Proposed Standard= . >>> Start+0mos - Accept 'Streamlined Bundle Security Protocol (SBSP)' [3]= as >>> a working group work item intended for Proposed Standard= . >>> start+3mos - Accept 'Bundle In Bundle Encapsulation (BIBE)' [4] as a >>> working work item intended for Proposed Standard. >>> start+6mos - Working group getting concensus on changes to be impleme= nted >>> in RFC 5050(bis). >>> start+9mos - Working group getting consensus on merging RFC5050bis, S= BSP, >>> BIBE etc. into a combined draft or keep as separate draf= ts. >>> start+12mos - Accept 'CGR Functional Specification' as a working grou= p >>> working group work item intended for Informational. >>> start+12mos - Accept 'Delay Tolerant Networking Security Key Manageme= nt' >>> as a working group work item intended for Proposed Stan= dard. >>> start+15mos - Accept 'Contact Plan Update Protocol' as working group = work >>> item intended for Proposed Standard. >>> start+18mos - Submit RFC5050bis, SBSP, BIBE and Key Mgmt to the IESG = either >>> as a combined draft or as separate drafts. >>> start+18mos - Submit Network Management [5], Registry [6] and Simple >>> Convergence Layer [7] as working group documents. >>> start+20mos - Survey appropriate forums (e.g., DTNRG) for emerging >>> technologies (e.g., convergence layer protocols, dynami= c >>> routing protocols, naming and addressing services, etc.= ) >>> ready for transition into IETF DTN Working Group. Publi= sh >>> draft on survey results as independent submission relat= ed >>> to the WG. >>> start+24mos - Submit Network Management, Registry and Simple Converge= nce >>> Layer to IESG >>> start+24mos - Recharter to accommodate new work items or close >>> Working Group >>> >>> >>> [1] "BP/LTP deployment on EPOXI spacecraft" [2008], >>> http://committees.comsoc.org/tccc/ccw/2010/slides/DINET_CCW.pdf >>> [2] "Proposed Revised Bundle Protocol" [2014], >>> https://datatracker.ietf.org/doc/draft-burleigh-bpv7/ >>> [3] "Streamlined Bundle Security Protocol Specification" [2014], >>> https://datatracker.ietf.org/doc/draft-irtf-dtnrg-sbsp/ >>> [4] "Bundle-in-Bundle Encapsulation" [2013], >>> http://tools.ietf.org/id/draft-irtf-burleigh-bibe >>> [5] "Delay Tolerant Network Management Protocol" [2013], >>> http://tools.ietf.org/id/draft-irtf-dtnrg-dtnmp >>> [6] "Delay-Tolerant Networking Bundle Protocol IANA Registries" [2011], >>> https://datatracker.ietf.org/doc/rfc6255/ >>> [7] "Datagram Convergence Layers ..." [2014], >>> https://datatracker.ietf.org/doc/rfc7122/ >>> [8] "Towards Flexibility and Accuracy in Space DTN Communications", >>> Bezirgianndia et al, CHANTS 2012, >>> http://dl.acm.org/citation.cfm?id=3D2505499 [2012] >>> >>> >>> >>> _______________________________________________ >>> 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 _______________________________________________ dtn mailing list dtn@ietf.org https://www.ietf.org/mailman/listinfo/dtn From nobody Fri Jun 20 18:16:48 2014 Return-Path: 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 E22281A02F9 for ; Fri, 20 Jun 2014 18:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 fcAMwzrynGJo for ; Fri, 20 Jun 2014 18:16:19 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 10BF11A0178 for ; Fri, 20 Jun 2014 18:16:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EB039BE98; Sat, 21 Jun 2014 02:16:17 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0LUibwwwBH3; Sat, 21 Jun 2014 02:16:15 +0100 (IST) Received: from [10.87.48.6] (unknown [86.44.75.216]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 43A8ABE79; Sat, 21 Jun 2014 02:16:15 +0100 (IST) Message-ID: <53A4DCDE.5040008@cs.tcd.ie> Date: Sat, 21 Jun 2014 02:16:14 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Birrane, Edward J." , "Templin, Fred L" , "dtn@ietf.org" References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> <2134F8430051B64F815C691A62D983183048B3B6@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983183048DB80@XCH-BLV-512.nw.nos.boeing.com> <53A09F61.2030900@cs.tcd.ie> <2134F8430051B64F815C691A62D983183048DD9A@XCH-BLV-512.nw.nos.boeing.com> <53A0A5B8.1090802@cs.tcd.ie> <329D879C76FDD04AAAE84BB1D89B397009572F23C8@aplesfreedom.dom1.jhuapl.edu>, <53A0B9F1.30609@cs.tcd.ie> <329D879C76FDD04AAAE84BB1D89B39700957131B87@aplesfreedom.dom1.jhuapl.edu> In-Reply-To: <329D879C76FDD04AAAE84BB1D89B39700957131B87@aplesfreedom.dom1.jhuapl.edu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/GXyiZPmG58-PXHS4DSSs8z5hH0o Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jun 2014 01:16:36 -0000 Hiya, On 21/06/14 02:01, Birrane, Edward J. wrote: > I do understand this. I have had many more conversations (sadly off > list) that have removed from my mind the question of commercial > interest, participation, and deployment. However, so much of it > surrounds new deployment strategies, products, services, etc... that > DTN considerations get pulled too quickly behind the business > proprietary curtain. So one reason I'm going on about this is that my experience with DTN projects (and failed proposals;-) has been that there are often ways to get enough DTN-like functionality for some specific purpose without the BP, and that those other ways will be chosen in preference to the BP in various cases. For example, based on lack of OS support, or if most code is UI code then the benefits from the BP are less and can be overwhelmed by the availability of a library, or if the delay/disruption on almost all paths is only experienced on one link, in which case e2e DTN isn't quite needed. Its not a knock-out argument by any means, but is real. If all that offlist discussion stays offlist then I am less confident that a WG will be able to have discussions based on what people really need and would be in danger of deciding based on the loudest voice on the list (which could be mine sometimes, and that'd be just as wrong or even more wrong than usual:-). And such bad decisions, if made, would be more likely to lead to a 5050bis that ends up not being used much, which would be a waste of all our efforts. That's my concern. Its not alleviated by plausible scenarios at all, nor by offlist discussions. S. From nobody Fri Jun 20 18:36:29 2014 Return-Path: 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 54C971A02E0 for ; Fri, 20 Jun 2014 18:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.553 X-Spam-Level: X-Spam-Status: No, score=-4.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 Vnbm-s6gZCs6 for ; Fri, 20 Jun 2014 18:36:24 -0700 (PDT) Received: from piper.jhuapl.edu (piper.jhuapl.edu [128.244.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2118B1A02DA for ; Fri, 20 Jun 2014 18:36:23 -0700 (PDT) Received: from aplexcas2.dom1.jhuapl.edu (unknown [128.244.198.91]) by piper.jhuapl.edu with smtp (TLS: TLSv1/SSLv3,128bits,RC4-MD5) id 2530_0a72_b471b418_8ef7_41de_bc84_efbd044c2977; Fri, 20 Jun 2014 21:36:11 -0400 Received: from aplesfreedom.dom1.jhuapl.edu ([128.244.198.204]) by aplexcas2.dom1.jhuapl.edu ([128.244.198.91]) with mapi; Fri, 20 Jun 2014 21:36:12 -0400 From: "Birrane, Edward J." To: =?iso-8859-1?Q?J=E9ferson_Campos_Nobre?= , "dtn@ietf.org" Date: Fri, 20 Jun 2014 21:36:11 -0400 Thread-Topic: [dtn] DTN Management Drafts Thread-Index: Ac+M5eJtB150em/dQcqsbRT1i19VMAACh5I8 Message-ID: <329D879C76FDD04AAAE84BB1D89B39700957131B8A@aplesfreedom.dom1.jhuapl.edu> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/8QIYM-wOUKO0GaVOBjWTfwTFqoE Subject: Re: [dtn] DTN Management Drafts X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jun 2014 01:36:26 -0000 Hello, I wrote up DTNMP and provided an initial (though not feature complete) re= ference implementation in ION. Yes, the DTNMP spec from September has expir= ed as an internet-draft, but the spec is under active development (I am hop= ing to have a new version ready before the BOF). There is funded work to co= ntinue DTNMP development and associated standards and plans for its operati= onal deployment. =20 I think that management is a requirement for operational deployment and a= gree that it should be part of the charter. -Ed ________________________________________ From: dtn [dtn-bounces@ietf.org] On Behalf Of J=E9ferson Campos Nobre [jcno= bre@inf.ufrgs.br] Sent: Friday, June 20, 2014 8:15 PM To: dtn@ietf.org Subject: [dtn] DTN Management Drafts Hi. With network management as an item of the DTN BoF, I think we should pay attention to the DTN management drafts.To my knowledge, all drafts are expired now. The requirements drafts (draft-ivancic-dtnrg-network-management and draft-clark-dtnrg-netman-req) are expired for a long time, but I think they can be important to define what to expect of network management features in a possible DTNWG. Concerning protocol ones (draft-irtf-dtnrg-dtnmp and draft-irtf-dtnrg-ding-network-management), only DTNMP has received attention recently, although I believe DING was mentioned in the last discussions (not sure if here or in the dtn-interest list). Returning to the DTN BoF: since we have these draft they could/should appear in the problem statement and solutions items? Cheers. J=E9ferson Campos Nobre PhD Student Computer Networks Group - Institute of Informatics Federal University of Rio Grande do Sul http://www.inf.ufrgs.br/~jcnobre _______________________________________________ dtn mailing list dtn@ietf.org https://www.ietf.org/mailman/listinfo/dtn From nobody Fri Jun 20 20:26:43 2014 Return-Path: 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 25DA01A049F for ; Fri, 20 Jun 2014 20:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.853 X-Spam-Level: X-Spam-Status: No, score=-4.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 4AtPK2diWNec for ; Fri, 20 Jun 2014 20:26:39 -0700 (PDT) Received: from pilot.jhuapl.edu (pilot.jhuapl.edu [128.244.251.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E12991A0496 for ; Fri, 20 Jun 2014 20:26:38 -0700 (PDT) Received: from aplexcas2.dom1.jhuapl.edu (unknown [128.244.198.91]) by pilot.jhuapl.edu with smtp (TLS: TLSv1/SSLv3,128bits,RC4-MD5) id 4001_158e_0e35bed9_1f5c_4c0e_90ef_a0c9ff7cfb20; Fri, 20 Jun 2014 23:26:26 -0400 Received: from aplesfreedom.dom1.jhuapl.edu ([128.244.198.204]) by aplexcas2.dom1.jhuapl.edu ([128.244.198.91]) with mapi; Fri, 20 Jun 2014 23:26:26 -0400 From: "Birrane, Edward J." To: Stephen Farrell , "Templin, Fred L" , "dtn@ietf.org" Date: Fri, 20 Jun 2014 23:26:25 -0400 Thread-Topic: [dtn] Draft Charter Discussion Thread-Index: Ac+M7mivPt1m+8H7TYyYhRLxJaboNgAA9BaF Message-ID: <329D879C76FDD04AAAE84BB1D89B39700957131B8B@aplesfreedom.dom1.jhuapl.edu> References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> <2134F8430051B64F815C691A62D983183048B3B6@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983183048DB80@XCH-BLV-512.nw.nos.boeing.com> <53A09F61.2030900@cs.tcd.ie> <2134F8430051B64F815C691A62D983183048DD9A@XCH-BLV-512.nw.nos.boeing.com> <53A0A5B8.1090802@cs.tcd.ie> <329D879C76FDD04AAAE84BB1D89B397009572F23C8@aplesfreedom.dom1.jhuapl.edu>, <53A0B9F1.30609@cs.tcd.ie> <329D879C76FDD04AAAE84BB1D89B39700957131B87@aplesfreedom.dom1.jhuapl.edu>, <53A4DCDE.5040008@cs.tcd.ie> In-Reply-To: <53A4DCDE.5040008@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/7E5ovmdTQnvIu_RmzctxG4Zp79I Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jun 2014 03:26:41 -0000 Stephen,=20 Yes, it would be an interesting data point if a company said something li= ke "we are deploying a DTN of purpose X and need a WG to help us with Y." = But that can't be the only way to assess the value of an IETF WG, right?=20 > So one reason I'm going on about this is that my experience > with DTN projects (and failed proposals;-) has been that > there are often ways to get enough DTN-like functionality for > some specific purpose without the BP, and that those other > ways will be chosen in preference to the BP in various cases. Projects use what is available because the focus of the project is... to do= whatever the project should be doing rather than developing telecom protoc= ols. If there was a non-experimental DTN implementation of a lessons-learne= d BPv7 with security and management, projects would integrate that - even i= f they just wanted 70% of the stack. This is what NASA, Boeing, Harris (Kip= ), Outernet, and other companies seem to be asserting here. Getting to the point where it is cheaper to adopt the DTN stack rather than= assemble an alternative is an implementation matter, is necessary, and (IM= O) requires non-experimental specs. > If all that offlist discussion stays offlist then I am > less confident that a WG will be able to have discussions > based on what people really need and would be in danger > of deciding based on the loudest voice on the list (which > could be mine sometimes, and that'd be just as wrong or > even more wrong than usual:-). DTN has a long history of experimentation, investment, and an interest list= with 1000+ people on it. ;) I would not discount the value of the existing= body of evidence - correcting for loudness - to successfully inform the WG= . Besides, needs can be discussed without delving into business practices. Fr= ed's charter certainly gives what I presume is Boeing's focus. I've focused= on the following for things like Outernet (which is a suitable stand in fo= r a variety of off-list efforts because in this way they are all roughly th= e same...) - Clever protocol bits about extension blocks, custody transfers, and stand= ardized queuing models consolidated in one spec. - An end-to-end overlay protocol to reduce gateways, proxies, and the compl= exities of configuration. - Automation enough to get the human-out-of-the-loop, either due to signal = propagation delays, link disruptions, or operator disruptions. - Interoperability over multiple existing transports without needing to red= o everything when integrating another network. IMO, the work Fred has outlined in the charter pretty much encompasses the = above.=20 -Ed= From nobody Sat Jun 21 12:20:31 2014 Return-Path: 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 7BBE31A04B9 for ; Sat, 21 Jun 2014 12:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no 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 RKfr-Yb5rNwI for ; Sat, 21 Jun 2014 12:20:28 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A06CF1A04B0 for ; Sat, 21 Jun 2014 12:20:27 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id s7so3188384lbd.30 for ; Sat, 21 Jun 2014 12:20:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=szdawwFvBLCxFnLv8JpN5bjqo0puE9/ea3+M065E9ko=; b=bZ3ffE/7K2vDM3eJrRI2T+0XIiCS0ElPdhX3zkmghyZxHgY5CVHYbHFeCq9SKcGkzf 97C11EQ6ljk2rRMTMYcoZaJUlgVW17Gs7wkift72VpJq2E1fIA4gvzIgm9f2fENgjrHT imVOESq4zYly0c4ZOGMYUKjgz+RryDiDLgNGGXY5lWYXsyaqG3BG+TIjuMa0GSIm2zfO h9wQFevmSE7ClP3K3P1u5irCqqM49RSZWw/+aTIPYY14a571ppgh8RATS22iiQJTc0bF 5eIC5X6RVXKFumE0WTMHSNzJ+vbvflXy+fuRpxlzKKDCGXrwA1BCAsMw3OHJzle54YQO XgMg== MIME-Version: 1.0 X-Received: by 10.152.45.37 with SMTP id j5mr2796170lam.58.1403378425881; Sat, 21 Jun 2014 12:20:25 -0700 (PDT) Sender: jeferson.nobre@gmail.com Received: by 10.112.146.228 with HTTP; Sat, 21 Jun 2014 12:20:25 -0700 (PDT) In-Reply-To: <329D879C76FDD04AAAE84BB1D89B39700957131B8A@aplesfreedom.dom1.jhuapl.edu> References: <329D879C76FDD04AAAE84BB1D89B39700957131B8A@aplesfreedom.dom1.jhuapl.edu> Date: Sat, 21 Jun 2014 16:20:25 -0300 X-Google-Sender-Auth: OxvbcGUanNfWWOPgdNt6bC7Av2U Message-ID: From: =?UTF-8?Q?J=C3=A9ferson_Campos_Nobre?= To: "Birrane, Edward J." , "dtn@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/LcrPu8ktpkbVuKSInb5rmLa4R6U Subject: Re: [dtn] DTN Management Drafts X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jun 2014 19:20:29 -0000 Hi Ed. Great news about DTNMP. It would be good to see the DTNMP draft and a revamped DTN management requirements in the charter. Best. J=C3=A9ferson Campos Nobre PhD Student Computer Networks Group - Institute of Informatics Federal University of Rio Grande do Sul http://www.inf.ufrgs.br/~jcnobre On Fri, Jun 20, 2014 at 10:36 PM, Birrane, Edward J. wrote: > Hello, > > I wrote up DTNMP and provided an initial (though not feature complete) = reference implementation in ION. Yes, the DTNMP spec from September has exp= ired as an internet-draft, but the spec is under active development (I am h= oping to have a new version ready before the BOF). There is funded work to = continue DTNMP development and associated standards and plans for its opera= tional deployment. > > I think that management is a requirement for operational deployment and= agree that it should be part of the charter. > > -Ed > > ________________________________________ > From: dtn [dtn-bounces@ietf.org] On Behalf Of J=C3=A9ferson Campos Nobre = [jcnobre@inf.ufrgs.br] > Sent: Friday, June 20, 2014 8:15 PM > To: dtn@ietf.org > Subject: [dtn] DTN Management Drafts > > Hi. > With network management as an item of the DTN BoF, I think we should > pay attention to the DTN management drafts.To my knowledge, all drafts > are expired now. > The requirements drafts (draft-ivancic-dtnrg-network-management and > draft-clark-dtnrg-netman-req) are expired for a long time, but I think > they can be important to define what to expect of network management > features in a possible DTNWG. > Concerning protocol ones (draft-irtf-dtnrg-dtnmp and > draft-irtf-dtnrg-ding-network-management), only DTNMP has received > attention recently, although I believe DING was mentioned in the last > discussions (not sure if here or in the dtn-interest list). > Returning to the DTN BoF: since we have these draft they could/should > appear in the problem statement and solutions items? > Cheers. > > J=C3=A9ferson Campos Nobre > PhD Student > Computer Networks Group - Institute of Informatics > Federal University of Rio Grande do Sul > http://www.inf.ufrgs.br/~jcnobre > > _______________________________________________ > 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 From nobody Sun Jun 22 14:00:45 2014 Return-Path: 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 EA6C31A0295 for ; Sun, 22 Jun 2014 14:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.149 X-Spam-Level: X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.651] 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 cAdEYD5P5lEn for ; Sun, 22 Jun 2014 14:00:41 -0700 (PDT) Received: from mx5.oit.ohio.edu (mx5.oit.ohio.edu [132.235.200.36]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90D8A1A0263 for ; Sun, 22 Jun 2014 14:00:41 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtEDAKxCp1OE6whkXGdsb2JhbABZFoNJg0enQgEBAQEBAQaRWRyHQAGBGAQYDQkHPIQDAQEBAQMBAQEgDwEFNgoRCxEEAQEBAgIFFgsCAgkDAgECARUcDAgTBgIBARYBiCcNqBKXZoVzF4EqhDmDY4U9gneBTASaTIFFhw2FDolhIS8 X-IPAS-Result: AtEDAKxCp1OE6whkXGdsb2JhbABZFoNJg0enQgEBAQEBAQaRWRyHQAGBGAQYDQkHPIQDAQEBAQMBAQEgDwEFNgoRCxEEAQEBAgIFFgsCAgkDAgECARUcDAgTBgIBARYBiCcNqBKXZoVzF4EqhDmDY4U9gneBTASaTIFFhw2FDolhIS8 Received: from mail.ohio.edu (HELO clarkg1-osx.local) ([132.235.8.100]) by mx5.oit.ohio.edu with ESMTP/TLS/DHE-RSA-AES128-SHA; 22 Jun 2014 17:00:39 -0400 Message-ID: <53A743F0.6070707@ohio.edu> Date: Sun, 22 Jun 2014 17:00:32 -0400 From: Gilbert Clark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dtn@ietf.org References: <329D879C76FDD04AAAE84BB1D89B39700957131B8A@aplesfreedom.dom1.jhuapl.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/sf9KWcuXSkrXXOhcqtKdbhF1zS0 Subject: Re: [dtn] DTN Management Drafts X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jun 2014 21:00:44 -0000 +1 that management is a requirement for operational deployment. With that said, I do also wonder if the inclusion of specific use-cases should be a requirement for including the development of any *specific network management protocol* as a part of this charter. Network management is going to necessarily involve discussing / deciding on a number of trade-offs that will impact not only the network conditions the protocol is best equipped to support, but also the hardware requirements necessary to support running the new protocol stack in the first place. Without context for such a conversation, I don't believe there will often be a good way to argue that a specific decision is either right *or* wrong. For what it's worth, Gilbert Clark On 6/21/14, 3:20 PM, Jéferson Campos Nobre wrote: > Hi Ed. > Great news about DTNMP. > It would be good to see the DTNMP draft and a revamped DTN management > requirements in the charter. > Best. > > Jéferson Campos Nobre > PhD Student > Computer Networks Group - Institute of Informatics > Federal University of Rio Grande do Sul > http://www.inf.ufrgs.br/~jcnobre > > On Fri, Jun 20, 2014 at 10:36 PM, Birrane, Edward J. > wrote: >> Hello, >> >> I wrote up DTNMP and provided an initial (though not feature complete) reference implementation in ION. Yes, the DTNMP spec from September has expired as an internet-draft, but the spec is under active development (I am hoping to have a new version ready before the BOF). There is funded work to continue DTNMP development and associated standards and plans for its operational deployment. >> >> I think that management is a requirement for operational deployment and agree that it should be part of the charter. >> >> -Ed >> >> ________________________________________ >> From: dtn [dtn-bounces@ietf.org] On Behalf Of Jéferson Campos Nobre [jcnobre@inf.ufrgs.br] >> Sent: Friday, June 20, 2014 8:15 PM >> To: dtn@ietf.org >> Subject: [dtn] DTN Management Drafts >> >> Hi. >> With network management as an item of the DTN BoF, I think we should >> pay attention to the DTN management drafts.To my knowledge, all drafts >> are expired now. >> The requirements drafts (draft-ivancic-dtnrg-network-management and >> draft-clark-dtnrg-netman-req) are expired for a long time, but I think >> they can be important to define what to expect of network management >> features in a possible DTNWG. >> Concerning protocol ones (draft-irtf-dtnrg-dtnmp and >> draft-irtf-dtnrg-ding-network-management), only DTNMP has received >> attention recently, although I believe DING was mentioned in the last >> discussions (not sure if here or in the dtn-interest list). >> Returning to the DTN BoF: since we have these draft they could/should >> appear in the problem statement and solutions items? >> Cheers. >> >> Jéferson Campos Nobre >> PhD Student >> Computer Networks Group - Institute of Informatics >> Federal University of Rio Grande do Sul >> http://www.inf.ufrgs.br/~jcnobre >> >> _______________________________________________ >> 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 From nobody Mon Jun 23 06:08:18 2014 Return-Path: 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 32CFA1B2AB5 for ; Mon, 23 Jun 2014 06:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 nXKKL7spdJG0 for ; Mon, 23 Jun 2014 06:07:55 -0700 (PDT) Received: from nm25-vm0.bullet.mail.ne1.yahoo.com (nm25-vm0.bullet.mail.ne1.yahoo.com [98.138.91.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 757EA1B2AB3 for ; Mon, 23 Jun 2014 06:07:52 -0700 (PDT) Received: from [98.138.100.118] by nm25.bullet.mail.ne1.yahoo.com with NNFMP; 23 Jun 2014 13:07:51 -0000 Received: from [98.138.101.170] by tm109.bullet.mail.ne1.yahoo.com with NNFMP; 23 Jun 2014 13:07:51 -0000 Received: from [127.0.0.1] by omp1081.mail.ne1.yahoo.com with NNFMP; 23 Jun 2014 13:07:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 617182.85319.bm@omp1081.mail.ne1.yahoo.com Received: (qmail 12194 invoked by uid 60001); 23 Jun 2014 13:07:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1403528871; bh=kfDrQAou0LDJUuQMDVVuFxcq4Fm5lzBD2jcW9D2pF84=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=icIWqHuQSBI+GCC4w1q4exMosuA+uYQaqVuj6Cso8BG06cx8gPJeIH1Bo2DJLFWu/Tdx/Nxo77URPHA+HTdE832GqXzOW8FChGyhPaZNT0I7ve8pTeAfEc90HYyv4K4G0l3KB9Gddc2dWWphUSJi9b5+5eG1ZtMQrRT5o3ZGkBY= X-YMail-OSG: 7PAgAUYVM1lNH0R1AVTC5oUnhIBiFslMc3FUnXmR97MNgpv BPpBtfwd709pQlD7rD9fSQITqFrOeQD0AkaRmNOH7j80csqAcBnNT6JjPSEx YIchIRmtMLSUk2C7S1lpPxIjLUsDl2lWwO4ZcCTxpF_Z3hwSFSqQISDS7pWd zrfss3PW4on88NYS3Em2SjnUbxEmOPumUMJ7EnkAHlNXVKzntogzj28Z.Kqy 426prHDOhetPN.NLcjv_C2AymsI8B14Unq4hX9A7OSyudi8PSO7LEoRobw.W 1IlwUBGI03Qd9N64nejUoOF.ZttV8AjwQuTvBE3rxvVHHa0FP20VYu02LZY_ XMasr_QlMvXW9zxDLX3QKuZMPNbzRagKN70l_.h9sFrrl6gsRroDCvg.EWfX O_xn2AnAm5XdTtOoc3f_u2Re40hpxW3WXMtdNsEric2MRJbOkc98GgES1oI2 NncUSpKQ_wFZKR8KOhpPn3rN8DSeL27_baZYuN2ecoesU9bOtzTjTYBrNhhJ uezkD3a6FEmVoCMsTaVtGrJk4WzxGUNjmS1jmJ3l6y4GBUhOKJXgYBzwnDO1 cDgGM6n5PPwY8CE5RJHePVkSti3rS9aA71FxarJwjXitoCIDqnNAfuIo3N3v xfOgq3w0C0JzVMcAyi_0- Received: from [128.156.10.80] by web125105.mail.ne1.yahoo.com via HTTP; Mon, 23 Jun 2014 06:07:51 PDT X-Rocket-MIMEInfo: 002.001, TG93IEVhcnRoIE9yYml0aW5nIChMRU8pIHNhdGVsbGl0ZSBuZXR3b3JrcyB0ZW5kIHRvIGJlwqAgc2luZ2xlIGhvcCBiZWZvcmUgeW91IGhpdCB0aGUgY29ubmVjdGVkIEludGVybmV0LsKgIFNvLCB5b3UgbmVlZCBlZmZpY2llbnQgdHJhbnNwb3J0IHByb3RvY29scyBpZiB5b3UgaGF2ZSBoaWdobHkgYXN5bW1ldHJpYyBsaW5rcywgYnV0IHlvdSBkbyBub3QgcmVhbGx5IG5lZWQgdGhlIGZlYXR1cmVzIG9mIFJGQzUwNTAuwqAgVW5sZXNzIHlvdSBoYXZlIGEgbXVsdGktaG9wIGRpc2Nvbm5lY3RlZCBuZXR3b3IBMAEBAQE- X-Mailer: YahooMailWebService/0.8.191.1 References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> <2134F8430051B64F815C691A62D983183048B3B6@XCH-BLV-512.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983183048DB80@XCH-BLV-512.nw.nos.boeing.com> <53A09F61.2030900@cs.tcd.ie> <2134F8430051B64F815C691A62D983183048DD9A@XCH-BLV-512.nw.nos.boeing.com> <53A0A5B8.1090802@cs.tcd.ie>, <329D879C76FDD04AAAE84BB1D89B39700957131B88@aplesfreedom.dom1.jhuapl.edu> Message-ID: <1403528871.11455.YahooMailNeo@web125105.mail.ne1.yahoo.com> Date: Mon, 23 Jun 2014 06:07:51 -0700 From: William Ivancic To: "Birrane, Edward J." , "Burleigh, Scott C \(312G\)" , "dtn@ietf.org" In-Reply-To: <329D879C76FDD04AAAE84BB1D89B39700957131B88@aplesfreedom.dom1.jhuapl.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="461871616-879225364-1403528871=:11455" Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/a-vTECAdWw1pjPNdLPdgfY_YH98 Subject: Re: [dtn] Draft Charter Discussion X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: William Ivancic List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 13:08:02 -0000 X-List-Received-Date: Mon, 23 Jun 2014 13:08:02 -0000 --461871616-879225364-1403528871=:11455 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Low Earth Orbiting (LEO) satellite networks tend to be=A0 single hop before= you hit the connected Internet.=A0 So, you need efficient transport protoc= ols if you have highly asymmetric links, but you do not really need the fea= tures of RFC5050.=A0 Unless you have a multi-hop disconnected network, RFC5= 050 doesn't buy you much and adds complexity and the routing protocols are = not necessarily there.=0A=0A=0ASkybox and Planet Lab were at AIAA SpaceOps = 2014 this May.=A0 I talked to both groups.=A0 Neither mentioned DTN.=A0 Sky= box said they simple consider their satellites as a server in the sky.=A0 O= ne of them, I think Skybox, is using 9P to communicate to there satellites.= =A0 RTT to a LEO is under 10 msec.=A0=A0=0A=0AWill=0A=0A=0A________________= ________________=0A From: "Birrane, Edward J." = =0ATo: "Burleigh, Scott C (312G)" ; "dtn@iet= f.org" =0ASent: Friday, June 20, 2014 9:15 PM=0ASubject: Re:= [dtn] Draft Charter Discussion=0A =0A=0AWe really can't stress point 3 eno= ugh.=A0 The industrialization of near-earth space is growing.=A0 In doing s= o, it is also transitioning away from space agencies and large aerospace. T= he companies I have talked with want their ground infrastructure, space inf= rastructure, and peers integrated in a single end-to-end overlay.=0A=0AUlti= mately, I have seen a commercial desire to make the Internet of Things into= the Internet of Moving Things. DTN is not a magical cure for that, but it = is seen as a reasonable part of the puzzle.=0A=0A-Ed=0A=0A_________________= _______________________=0AFrom: dtn [dtn-bounces@ietf.org] On Behalf Of Bur= leigh, Scott C (312G) [scott.c.burleigh@jpl.nasa.gov]=0ASent: Tuesday, June= 17, 2014 6:23 PM=0ATo: dtn@ietf.org=0ASubject: Re: [dtn] Draft Charter Dis= cussion=0A=0AOkay, taking another crack at this.=0A=0AI think there are two= levels of question here, one implying the other, and it might be helpful t= o address them separately.=0A=0AFirst the proximate question: given that DT= N exists, why standardize it?=A0 Why not just use it as it is?=A0 What has = changed?=0A=0AI think the answer there, to which Fred and Ed have alluded, = is that there are business entities that would now like to use DTN to solve= some communication problems (or exploit some opportunities) but won't risk= doing so while the protocols are not standards.=A0 I know Ed works with su= ch entities on a regular basis, and the fact that Boeing is willing to inve= st some time and money in this BoF seems to suggest that they at least are = another such entity.=0A=0ASo then the underlying question: what are those p= roblems and opportunities for which a standardized DTN would be used?=0A=0A= As Fred has pointed out, organizations that hope to make money from these i= deas are not likely to disclose them here or in the BoF.=A0 But, just from = my own reading of the news, let me suggest a couple of potential DTN use ca= ses that go beyond the ISS and Saami deployments we're all familiar with.= =0A=0A1.=A0 The UAV industry is exploding.=A0 Nobody has any idea where the= limits on applications of UAVs are, but what we do know is that the inform= ation that controls them is conveyed by radio, which is occasionally subjec= t to disruption.=A0 Technology that could improve the safety and reliabilit= y of UAVs, while reducing cost, could find a large market.=0A=0A2.=A0 The s= peed of sound underwater is 1.5 km/sec, so the round-trip time between two = underwater entities communicating by acoustic modem and separated by a dist= ance of 7.5 km is about equal to the round-trip time between Earth and the = Earth/Sun L2 Lagrange point.=A0 Since the data rates of acoustic modems are= low, efficient delay-tolerant networking is a pretty good way to establish= underwater communication.=A0 The market for underwater sensors and instrum= entation is already in the billions of dollars; revenue in the autonomous u= nderwater vehicle manufacturing industry is growing at nearly 14% per year.= =0A=0A3.=A0 The "space" use case is arguably still small if you restrict it= to the vehicles that are in orbit.=A0 If you extend the space communicatio= n use case to users on Earth who will need to communicate with spacecraft o= ver the next two decades, as Earth orbit becomes increasingly industrialize= d, then you find yourself talking about a very large user community.=0A=0AA= nd I am pretty sure there are more that I'm not aware of.=A0 The basic prop= osition is that the Internet is an outstanding communications solution for = all parts of Earth's surface that are relatively easy to get to, but there = are business opportunities that are beyond its current reach.=A0 DTN can he= lp extend that outstanding communications solution to currently Internet-in= hospitable parts of the Earth and near-Earth, benefiting a lot of people.= =A0 Standardizing it will help make that happen.=A0 As Vint remarked in one= of our conversations on this topic (I paraphrase freely), the Internet did= n't get created because somebody thought of a killer app; people thought of= killer apps because there was an Internet.=0A=0AScott=0A=0A-----Original M= essage-----=0AFrom: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of Stephen = Farrell=0ASent: Tuesday, June 17, 2014 1:32 PM=0ATo: Templin, Fred L; dtn@i= etf.org=0ASubject: Re: [dtn] Draft Charter Discussion=0A=0A=0AHi Fred,=0A= =0AOn 17/06/14 21:12, Templin, Fred L wrote:=0A> Hi Stephen,=0A>=0A>> -----= Original Message-----=0A>> From: Stephen Farrell [mailto:stephen.farrell@cs= .tcd.ie]=0A>> Sent: Tuesday, June 17, 2014 1:05 PM=0A>> To: Templin, Fred L= ; dtn@ietf.org=0A>> Subject: Re: [dtn] Draft Charter Discussion=0A>>=0A>>= =0A>> Fred and others,=0A>>=0A>> I think I've asked this before so apologie= s if I just forget the good=0A>> answer;-)=0A>>=0A>> We have the space use-= case and some fairly well known niche=0A>> terrestrial use-cases, which are= fine. But we've known these for=0A>> years and the DTNRG didn't want to mo= ve to the standards track until=0A>> now.=0A>=0A> Yes, a diverse set of use= cases and not a single use case. That means=0A> that in the early days the= re may be many purpose-built DTNs that may=0A> at a later time be joined to= gether to form larger DTNs.=0A> A "DTN-of-DTNs" in the same way that the In= ternet is a "network-=0A> of-networks".=0A>=0A> The whole reason the Intern= et was able to join together smaller=0A> networks to form larger networks i= s that the Internet had=0A> interoperable standards from the very beginning= . It is now time for us=0A> to do that for DTN.=0A=0AI'm familiar with DTN.= But I find the above a pretty complete non-answer to the question asked (i= n that it answers no part of my question:-) So I'll try again, in a more di= rect fashion...=0A=0AI do not know why specifically Boeing want a standards= track RFC5050bis, nor why you want it now.=0A=0AAnd I'm wondering and woul= d like to know. I have not heard your use-case (or business case, whatever)= explained so far.=0ANor have I heard someone say "can't/won't tell, sorry.= "=0ASo I'm curious.=0A=0AAnd I'll note once again that successful BoFs tend= to involve explaining why this, now, specifically. As an IESG member it ma= kes it much easier for me to evaluate proposals for forming a WG.=0A=0A(BTW= , any answer that asks me to think like an acorn won't really work for this= question, sorry:-)=0A=0AIf someone else has a new answer to this question = that would also be interesting. By new, I mean a use-case or business-case = that hasn't previously been discussed in the DTNRG.=0A=0ACheers,=0AS.=0A=0A= PS: In case there's confusion. My question is very much not the same as Wil= l's, despite your answer being very similar.=0A=0A>=0A> Thanks - Fred=0A> f= red.l.templin@boeing.com=0A>=0A>> I think it'd help the IESG to decide whet= her to approve a WG if there=0A>> were more information available about wha= t has changed to motivate=0A>> moving to the standards track.=0A>>=0A>> If = (say for Boeing) those are such that you can't say and there=0A>> aren't an= y others who can, then that's a pity, since it does make it=0A>> harder to = get why a 5050bis on the standards track is attractive.=0A>>=0A>> I'm just = noting this again because I think many recent successful=0A>> BoFs have ten= ded to have this topic as part of the agenda, but it=0A>> seems missing in = yours, which just assumes that the room knows that=0A>> RFC5050 needs a bit= of work. (I'm exaggerating a bit there, but I=0A>> hope you get what I mea= n.)=0A>>=0A>> S.=0A>>=0A>> On 17/06/14 18:40, Templin, Fred L wrote:=0A>>> = Please see below for an updated version of the draft charter based=0A>>> on= list discussions, and post any further comments in follow-up.=0A>>> (See a= lso attached for diffs relative to the previous version.)=0A>>>=0A>>> Thank= s - Fred=0A>>> fred.l.templin@boeing.com=0A>>>=0A>>> ---=0A>>>=0A>>> Draft = BoF Agenda (2.5hrs):=0A>>> **************************=0A>>> 1) Problem stat= ement (IETF wg motivation) - 30min=0A>>>=0A>>> 2) RFC5050(bis) - 15min=0A>>= >=0A>>> 3) Streamlined Bundle Security Protocol (SBSP) - 15min=0A>>>=0A>>> = 4) Security Key Management - 10min=0A>>>=0A>>> 5) Network Management - 10mi= n=0A>>>=0A>>> 6) Contact Graph Routing and Contact Plan Update Protocol - 1= 0min=0A>>>=0A>>> 7) Bundle-in-Bundle Encapsulation - 5min=0A>>>=0A>>> 8) Re= gistry for Service Identifiers - 5min=0A>>>=0A>>> 9) Open Discussion - 50mi= n=0A>>>=0A>>>=0A>>> Draft working group charter:=0A>>> ********************= ********=0A>>> Working group name:=0A>>>=0A>>>=A0 =A0 =A0 Delay/Disruption= Tolerant Networking Working Group (DTNWG)=0A>>>=0A>>> Chair(s):=0A>>>=0A>>= >=A0 =A0 =A0 TBD=0A>>>=0A>>> Area and Area Director(s):=0A>>>=0A>>>=A0 =A0= =A0 Transport Area: ADs Spencer Dawkins ,=0A>>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Martin Stiemer= ling =0A>>>=0A>>> Responsible Area Director:=0A>>>= =0A>>>=A0 =A0 =A0 TBD=0A>>>=0A>>> Mailing list:=0A>>>=0A>>>=A0 =A0 =A0 Ge= neral Discussion: dtn at ietf.org=0A>>>=A0 =A0 =A0 To Subscribe: https://w= ww.ietf.org/mailman/listinfo/dtn=0A>>>=A0 =A0 =A0 Archive:=0A>>> http://ww= w.ietf.org/mail-archive/web/dtn/current/maillist.html=0A>>>=0A>>> Descripti= on of Working Group:=0A>>>=0A>>>=A0 =A0 =A0 The Delay/Disruption Tolerant = Network Working Group (DTNWG) specifies=0A>>>=A0 =A0 =A0 mechanisms for da= ta communications in the presence of long delays=0A>>>=A0 =A0 =A0 and/or i= ntermittent connectivity. The work is motivated by well known=0A>>>=A0 =A0 = =A0 limitations of standard Internet protocols that expect end-to-end=0A>>= >=A0 =A0 =A0 connectivity between communicating endpoints, sub-second tran= smission=0A>>>=A0 =A0 =A0 delays and robust packet delivery ratios. In env= ironments where these=0A>>>=A0 =A0 =A0 favorable conditions do not apply, = existing mechanisms encounter problems=0A>>>=A0 =A0 =A0 such as reliable t= ransport protocol handshakes timing out and routing=0A>>>=A0 =A0 =A0 proto= cols failing to converge resulting in communication failures.=0A>>>=A0 =A0 = =A0 Furthermore, classical end-to-end security associations cannot be=0A>>= >=A0 =A0 =A0 coordinated when communicating endpoints cannot conduct multi= -message=0A>>>=A0 =A0 =A0 keying exchanges in a timely fashion. These limi= tations suggested the=0A>>>=A0 =A0 =A0 need for a new approach.=0A>>>=0A>>= >=A0 =A0 =A0 Delay-Tolerant Networking (DTN) protocols have been the subje= ct of=0A>>>=A0 =A0 =A0 extensive research and development in the Delay-Tol= erant Networking=0A>>>=A0 =A0 =A0 Research Group (DTNRG) of the Internet R= esearch Task Force since 2002.=0A>>>=A0 =A0 =A0 The DTNRG has developed th= e Delay-Tolerant Networking Architecture=0A>>>=A0 =A0 =A0 (RFC 4838) that = the DTNWG uses as the basis for its work.=A0 The key=0A>>>=A0 =A0 =A0 comp= onents of the this architecture are the bundle concept for=0A>>>=A0 =A0 =A0= encapsulating data units, the bundle transmission protocol and the=0A>>>= =A0 =A0 =A0 underlying convergence layer architecture.=0A>>>=0A>>>=A0 =A0 = =A0 The experimental DTN Bundle Protocol (RFC 5050) and Licklider=0A>>>=A0= =A0 =A0 Transmission Protocol (RFC 5326) have been shown to address the= =0A>>>=A0 =A0 =A0 issues identified above in substantial fielded deploymen= ts in the space=0A>>>=A0 =A0 =A0 sector [1].=A0 RFC 5050 in conjunction wi= th TCP- and UDP-based convergence=0A>>>=A0 =A0 =A0 layers has been used su= ccessfully in a number of experiments both in=0A>>>=A0 =A0 =A0 communicati= ons challenged environments around the edges of the Internet=0A>>>=A0 =A0 = =A0 and as an Internet overlay where applications require delay- and/or=0A= >>>=A0 =A0 =A0 disruption-tolerance [refs needed].=0A>>>=0A>>>=A0 =A0 =A0 = The success of the BP over convergence layer protocol stack -- the core=0A= >>>=A0 =A0 =A0 protocols of the "DTN Architecture" described in RFC 4838 -= - may be=0A>>>=A0 =A0 =A0 attributed to the following fundamental design p= rinciples:=0A>>>=0A>>>=A0 =A0 - There is never any expectation of contempo= raneous end-to-end=0A>>>=A0 =A0 =A0 =A0 =A0 connectivity between any two n= etwork nodes.=0A>>>=0A>>>=A0 =A0 - Because end-to-end connectivity can nev= er be assumed, each node=0A>>>=A0 =A0 =A0 on the path between source and d= estination must be prepared to=0A>>>=A0 =A0 =A0 handle incoming "bundles" = of data that cannot immediately be=0A>>>=A0 =A0 =A0 forwarded.=0A>>>=0A>>>= =A0 =A0 - Again because end-to-end connectivity can never be assumed,=0A>>= >=A0 =A0 =A0 end-to-end conversational data exchange can never be assumed = to=0A>>>=A0 =A0 =A0 complete in a timely manner; protocol features that re= ly on=0A>>>=A0 =A0 =A0 timely conversational data exchange must be exclude= d from the=0A>>>=A0 =A0 =A0 architecture.=0A>>>=0A>>>=A0 =A0 =A0 The DTNW= G believes that protocols adhering to these principles offer=0A>>>=A0 =A0 = =A0 opportunities for enhancing the functionality of the Internet,=0A>>> i= ncluding=0A>>>=0A>>>=A0 =A0 =A0 =A0 - facilitating the extension of the In= ternet into environments such as=0A>>>=A0 =A0 =A0 =A0 =A0 the ocean floor = and deep space in which the core Internet protocols=0A>>>=A0 =A0 =A0 =A0 = =A0 operate sub-optimally for the reasons discussed earlier;=0A>>>=0A>>>= =A0 =A0 =A0 =A0 - extending the Internet into communications challenged te= rrestrial=0A>>>=A0 =A0 =A0 =A0 =A0 environments where it is not possible t= o provide continuous, low=0A>>>=A0 =A0 =A0 =A0 =A0 delay Internet connecti= ons; and=0A>>>=0A>>>=A0 =A0 =A0 =A0 - supporting Internet applications tha= t need DTN capabiliies.=0A>>>=0A>>>=A0 =A0 =A0 We believe that the extensi= ve research, demonstration, and=0A>>>=A0 =A0 =A0 pilot operations performe= d to date using the DTNRG protocols provides=0A>>>=A0 =A0 =A0 a firm basis= for publishing Internet standards derived from that work.=0A>>>=0A>>>=A0 = =A0 =A0 Work items related to Delay/Disruption Tolerant Networking include= :=0A>>>=0A>>>=A0 =A0 =A0 o A mechanism for the exchange of protocol data u= nits, termed=0A>>>=A0 =A0 =A0 =A0 "bundles", that are designed to obviate c= onversational communications=0A>>>=A0 =A0 =A0 =A0 by containing values for = all potentially relevant configuration=0A>>>=A0 =A0 =A0 =A0 parameters. The= se protocol data units are typically larger than=0A>>>=A0 =A0 =A0 =A0 netwo= rk-layer packets. We will derive this bundle exchange mechanism=0A>>>=A0 = =A0 =A0 =A0 from the DTN Bundle Protocol (BP) documented in RFC 5050 by pu= blishing=0A>>>=A0 =A0 =A0 =A0 a new document for which [2] is a proposed f= irst draft (where=0A>>>=A0 =A0 =A0 =A0 appendix A provides a summary of th= e proposed changes).=0A>>>=0A>>>=A0 =A0 =A0 o A security protocol for ensu= ring that the network in which bundles=0A>>>=A0 =A0 =A0 =A0 are exchanged i= s secured against unauthorized access and denial of=0A>>>=A0 =A0 =A0 =A0 se= rvice attacks, and to ensure data integrity and confidentiality=0A>>>=A0 = =A0 =A0 =A0 in that network where necessary.=A0 We will derive this securit= y=0A>>>=A0 =A0 =A0 =A0 protocol from a "streamlined" adaptation of the DTN = Bundle Security=0A>>>=A0 =A0 =A0 =A0 Protocol documented in RFC 6257.=0A>>>= =0A>>>=A0 =A0 =A0 =A0 o A delay-tolerant security key management scheme tha= t can protect=0A>>>=A0 =A0 =A0 =A0 =A0 the integrity of a DTN network.=0A>>= >=0A>>>=A0 =A0 =A0 o A simple datagram convergence layer protocol for adap= tation of the=0A>>>=A0 =A0 =A0 =A0 bundle protocol to underlying internetw= orks. We expect to derive=0A>>>=A0 =A0 =A0 =A0 this convergence layer prot= ocol from the Datagram Convergence=0A>>>=A0 =A0 =A0 =A0 protocol documente= d in RFC 7122.=0A>>>=0A>>>=A0 =A0 =A0 o A protocol for remote status monit= oring, configuration, and=0A>>>=A0 =A0 =A0 =A0 administration of network n= odes in the presence of long delays=0A>>>=A0 =A0 =A0 =A0 and/or intermitte= nt connectivity.=0A>>>=0A>>>=A0 =A0 =A0 o A functional specification of Co= ntact Graph Routing (CGR) specifying=0A>>>=A0 =A0 =A0 =A0 the inputs (glob= al contact schedules, traffic demands, etc.) and=0A>>>=A0 =A0 =A0 =A0 outp= uts (node specific transmission and reception schedules,=0A>>>=A0 =A0 =A0 = =A0 notifications, etc.).=A0 CGR is a centralized, oracle-based bundle=0A>= >>=A0 =A0 =A0 =A0 transmission and reception scheduling scheme used in spa= ce segment=0A>>>=A0 =A0 =A0 =A0 DTN deployments.=0A>>>=0A>>>=A0 =A0 =A0 o= An adjunct to the management protocol that will allow the contact=0A>>>=A0= =A0 =A0 =A0 schedules generated by CGR to be distributed to nodes.=A0 Thi= s may be=0A>>>=A0 =A0 =A0 =A0 based on the Contact Plan Update Protocol (C= PUP) proposed in=0A>>>=0A>>>=A0 =A0 =A0 o An encapsulation protocol for "t= unneling" BP traffic within bundles=0A>>>=A0 =A0 =A0 =A0 that are secured a= nd/or routed in different way from the encapsulated=0A>>>=A0 =A0 =A0 =A0 bu= ndles.=0A>>>=0A>>>=A0 =A0 =A0 o A registry for DTN Service Identifiers=0A>= >>=0A>>>=A0 =A0 The working group will consider extending the current mile= stones based on=0A>>>=A0 =A0 new information and knowledge gained while wo= rking on the initial charter,=0A>>>=A0 =A0 as well as to accommodate new w= ork items beyond the scope of the initial=0A>>>=A0 =A0 phase.=A0 For examp= le, we expect that transport protocols such as LTP and=0A>>>=A0 =A0 the Sa= ratoga protocol are among the candidates for work in this phase.=0A>>>=0A>>= > Goals and Milestones:=0A>>>=A0 start+0mos - Accept 'Bundle Protocol Spec= ification (RFC5050bis)' [2] as=0A>>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 a worki= ng group work item intended for Proposed Standard.=0A>>>=A0 Start+0mos - A= ccept 'Streamlined Bundle Security Protocol (SBSP)' [3] as=0A>>>=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 a working group work item intended for Proposed Standa= rd.=0A>>>=A0 start+3mos - Accept 'Bundle In Bundle Encapsulation (BIBE)' [= 4] as a=0A>>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 working work item intended for= Proposed Standard.=0A>>>=A0 start+6mos - Working group getting concensus = on changes to be implemented=0A>>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 in RFC 50= 50(bis).=0A>>>=A0 start+9mos - Working group getting consensus on merging = RFC5050bis, SBSP,=0A>>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 BIBE etc. into a com= bined draft or keep as separate drafts.=0A>>>=A0 start+12mos - Accept 'CGR= Functional Specification' as a working group=0A>>>=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 working group work item intended for Informational.=0A>>>=A0 star= t+12mos - Accept 'Delay Tolerant Networking Security Key Management'=0A>>>= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 as a working group work item intended for = Proposed Standard.=0A>>>=A0 start+15mos - Accept 'Contact Plan Update Prot= ocol' as working group work=0A>>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 item inte= nded for Proposed Standard.=0A>>>=A0 start+18mos - Submit RFC5050bis, SBSP= , BIBE and Key Mgmt to the IESG either=0A>>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= as a combined draft or as separate drafts.=0A>>>=A0 start+18mos - Submit= Network Management [5], Registry [6] and Simple=0A>>>=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 Convergence Layer [7] as working group documents.=0A>>>=A0 st= art+20mos - Survey appropriate forums (e.g., DTNRG) for emerging=0A>>>=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 technologies (e.g., convergence layer protocol= s, dynamic=0A>>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 routing protocols, naming = and addressing services, etc.)=0A>>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ready = for transition into IETF DTN Working Group. Publish=0A>>>=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 draft on survey results as independent submission related= =0A>>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 to the WG.=0A>>>=A0 start+24mos - S= ubmit Network Management, Registry and Simple Convergence=0A>>>=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 Layer to IESG=0A>>>=A0 start+24mos - Recharter to acc= ommodate new work items or close=0A>>> Working Group=0A>>>=0A>>>=0A>>> [1] = "BP/LTP deployment on EPOXI spacecraft" [2008],=0A>>>=A0 =A0 http://committ= ees.comsoc.org/tccc/ccw/2010/slides/DINET_CCW.pdf=0A>>> [2] "Proposed Revis= ed Bundle Protocol" [2014],=0A>>>=A0 =A0 https://datatracker.ietf.org/doc/d= raft-burleigh-bpv7/=0A>>> [3] "Streamlined Bundle Security Protocol Specifi= cation" [2014],=0A>>>=A0 =A0 https://datatracker.ietf.org/doc/draft-irtf-dt= nrg-sbsp/=0A>>> [4] "Bundle-in-Bundle Encapsulation" [2013],=0A>>>=A0 =A0 h= ttp://tools.ietf.org/id/draft-irtf-burleigh-bibe=0A>>> [5] "Delay Tolerant = Network Management Protocol" [2013],=0A>>>=A0 =A0 http://tools.ietf.org/id/= draft-irtf-dtnrg-dtnmp=0A>>> [6] "Delay-Tolerant Networking Bundle Protocol= IANA Registries" [2011],=0A>>>=A0 =A0 https://datatracker.ietf.org/doc/rfc= 6255/=0A>>> [7] "Datagram Convergence Layers ..." [2014],=0A>>>=A0 =A0 http= s://datatracker.ietf.org/doc/rfc7122/=0A>>> [8] "Towards Flexibility and Ac= curacy in Space DTN Communications",=0A>>>=A0 =A0 Bezirgianndia et al, CHA= NTS 2012,=0A>>>=A0 =A0 http://dl.acm.org/citation.cfm?id=3D2505499 [2012]= =0A>>>=0A>>>=0A>>>=0A>>> _______________________________________________=0A= >>> dtn mailing list=0A>>> dtn@ietf.org=0A>>> https://www.ietf.org/mailman/= listinfo/dtn=0A>>>=0A>=0A> _______________________________________________= =0A> dtn mailing list=0A> dtn@ietf.org=0A> https://www.ietf.org/mailman/lis= tinfo/dtn=0A>=0A>=0A=0A_______________________________________________=0Adt= n mailing list=0Adtn@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/dtn= =0A=0A_______________________________________________=0Adtn mailing list=0A= dtn@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/dtn=0A=0A_____________= __________________________________=0Adtn mailing list=0Adtn@ietf.org=0Ahttp= s://www.ietf.org/mailman/listinfo/dtn --461871616-879225364-1403528871=:11455 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Low Earth Orbiting (LEO) sa= tellite networks tend to be  single hop before you hit the connected I= nternet.  So, you need efficient transport protocols if you have highl= y asymmetric links, but you do not really need the features of RFC5050.&nbs= p; Unless you have a multi-hop disconnected network, RFC5050 doesn't buy yo= u much and adds complexity and the routing protocols are not necessarily th= ere.

Skybox and Planet Lab were at AIAA SpaceOps 2014 th= is May.  I talked to both groups.  Neither mentioned DTN.  S= kybox said they simple consider their satellites as a server in the sky.&nb= sp; One of them, I think Skybox, is using 9P to communicate to there satellites.  RTT to a LEO is under 10 msec.  

Will
=
From: "Birran= e, Edward J." <Edward.Birrane@jhuapl.edu>
To: "Burleigh, Scott C (312G)" <scott.c.burlei= gh@jpl.nasa.gov>; "dtn@ietf.org" <dtn@ietf.org>
Sent: Friday, June 20, 2014 9:15 PM
= Subject: Re: [dtn] Draft Charter D= iscussion

We really c= an't stress point 3 enough.  The industrialization of near-earth space= is growing.  In doing so, it is also transitioning away from space ag= encies and large aerospace. The companies I have talked with want their gro= und infrastructure, space infrastructure, and peers integrated in a single = end-to-end overlay.

Ultimately, I have seen a commercial desire to m= ake the Internet of Things into the Internet of Moving Things. DTN is not a= magical cure for that, but it is seen as a reasonable part of the puzzle.<= br>
-Ed

________________________________________
From: dtn [dtn-bounces@ietf.org] On Behalf Of Burleigh, Scott C (312G) [scott.c.burleigh@jpl.nasa.go= v]
Sent: Tuesday, June 17, 2014 6:23 PM
To: dtn@ietf.org
Subject: Re:= [dtn] Draft Charter Discussion

Okay, taking another crack at this.<= br>
I think there are two levels of question here, one implying the othe= r, and it might be helpful to address them separately.

First the pro= ximate question: given that DTN exists, why standardize it?  Why not j= ust use it as it is?  What has changed?

I think the answer ther= e, to which Fred and Ed have alluded, is that there are business entities t= hat would now like to use DTN to solve some communication problems (or expl= oit some opportunities) but won't risk doing so while the protocols are not= standards.  I know Ed works with such entities on a regular basis, an= d the fact that Boeing is willing to invest some time and money in this BoF seems to suggest that they at least are another such entity.

So= then the underlying question: what are those problems and opportunities fo= r which a standardized DTN would be used?

As Fred has pointed out, o= rganizations that hope to make money from these ideas are not likely to dis= close them here or in the BoF.  But, just from my own reading of the n= ews, let me suggest a couple of potential DTN use cases that go beyond the = ISS and Saami deployments we're all familiar with.

1.  The UAV = industry is exploding.  Nobody has any idea where the limits on applic= ations of UAVs are, but what we do know is that the information that contro= ls them is conveyed by radio, which is occasionally subject to disruption.&= nbsp; Technology that could improve the safety and reliability of UAVs, whi= le reducing cost, could find a large market.

2.  The speed of s= ound underwater is 1.5 km/sec, so the round-trip time between two underwater entities communicating by acoustic modem and separated by a dis= tance of 7.5 km is about equal to the round-trip time between Earth and the= Earth/Sun L2 Lagrange point.  Since the data rates of acoustic modems= are low, efficient delay-tolerant networking is a pretty good way to estab= lish underwater communication.  The market for underwater sensors and = instrumentation is already in the billions of dollars; revenue in the auton= omous underwater vehicle manufacturing industry is growing at nearly 14% pe= r year.

3.  The "space" use case is arguably still small if you= restrict it to the vehicles that are in orbit.  If you extend the spa= ce communication use case to users on Earth who will need to communicate wi= th spacecraft over the next two decades, as Earth orbit becomes increasingl= y industrialized, then you find yourself talking about a very large user co= mmunity.

And I am pretty sure there are more that I'm not aware of.  The basic proposition is that the Internet is an outstandi= ng communications solution for all parts of Earth's surface that are relati= vely easy to get to, but there are business opportunities that are beyond i= ts current reach.  DTN can help extend that outstanding communications= solution to currently Internet-inhospitable parts of the Earth and near-Ea= rth, benefiting a lot of people.  Standardizing it will help make that= happen.  As Vint remarked in one of our conversations on this topic (= I paraphrase freely), the Internet didn't get created because somebody thou= ght of a killer app; people thought of killer apps because there was an Int= ernet.

Scott

-----Original Message-----
From: dtn [mailto:= dtn-bounces@ietf.org] On Behalf Of Stephen Farrell
Sent: Tuesda= y, June 17, 2014 1:32 PM
To: Templin, Fred L; dtn@ietf.org<= /a>
Subject: Re: [dtn] Draft Charter Discussion


Hi Fred,
<= br>On 17/06/14 21:12, Templin, Fred L wrote:
> Hi Stephen,
>>> -----Original Message-----
>> From: Stephen Farrell [mai= lto:stephen.farrell@cs.tcd.ie]
>> Sent: Tuesday= , June 17, 2014 1:05 PM
>> To: Templin, Fred L; dtn@ietf.org
>> = Subject: Re: [dtn] Draft Charter Discussion
>>
>>
>= > Fred and others,
>>
>> I think I've asked this befor= e so apologies if I just forget the good
>> answer;-)
>><= br>>> We have the space use-case and some fairly well known niche
= >> terrestrial use-cases, which are fine. But we've known these for
>> years and the DTNRG didn't want to move to the standards t= rack until
>> now.
>
> Yes, a diverse set of use cases= and not a single use case. That means
> that in the early days there= may be many purpose-built DTNs that may
> at a later time be joined = together to form larger DTNs.
> A "DTN-of-DTNs" in the same way that = the Internet is a "network-
> of-networks".
>
> The whole= reason the Internet was able to join together smaller
> networks to = form larger networks is that the Internet had
> interoperable standar= ds from the very beginning. It is now time for us
> to do that for DT= N.

I'm familiar with DTN. But I find the above a pretty complete non= -answer to the question asked (in that it answers no part of my question:-)= So I'll try again, in a more direct fashion...

I do not know why sp= ecifically Boeing want a standards track RFC5050bis, nor why you want it now.

And I'm wondering and would like to know. I have not h= eard your use-case (or business case, whatever) explained so far.
Nor ha= ve I heard someone say "can't/won't tell, sorry."
So I'm curious.
And I'll note once again that successful BoFs tend to involve explaining w= hy this, now, specifically. As an IESG member it makes it much easier for m= e to evaluate proposals for forming a WG.

(BTW, any answer that asks= me to think like an acorn won't really work for this question, sorry:-)
If someone else has a new answer to this question that would also be i= nteresting. By new, I mean a use-case or business-case that hasn't previous= ly been discussed in the DTNRG.

Cheers,
S.

PS: In case the= re's confusion. My question is very much not the same as Will's, despite yo= ur answer being very similar.

>
> Thanks - Fred
> fred.l.templin@boeing.com>
>> I think it'd help the IESG to decide whether to approve a= WG if there
>> were more information available about what has cha= nged to motivate
>> moving to the standards track.
>>
= >> If (say for Boeing) those are such that you can't say and there>> aren't any others who can, then that's a pity, since it does make= it
>> harder to get why a 5050bis on the standards track is attra= ctive.
>>
>> I'm just noting this again because I think m= any recent successful
>> BoFs have tended to have this topic as pa= rt of the agenda, but it
>> seems missing in yours, which just ass= umes that the room knows that
>> RFC5050 needs a bit of work. (I'm= exaggerating a bit there, but I
>> hope you get what I mean.)
= >>
>> S.
>>
>> On 17/06/14 18:40, Templin, Fred L wrote:
>>> Please see below for an updated ver= sion of the draft charter based
>>> on list discussions, and po= st any further comments in follow-up.
>>> (See also attached fo= r diffs relative to the previous version.)
>>>
>>> = Thanks - Fred
>>> fred.l.templin@boeing.com<= br>>>>
>>> ---
>>>
>>> Draft B= oF Agenda (2.5hrs):
>>> **************************
>>&= gt; 1) Problem statement (IETF wg motivation) - 30min
>>>
&g= t;>> 2) RFC5050(bis) - 15min
>>>
>>> 3) Strea= mlined Bundle Security Protocol (SBSP) - 15min
>>>
>>&= gt; 4) Security Key Management - 10min
>>>
>>> 5) N= etwork Management - 10min
>>>
>>> 6) Contact Graph Routing and Contact Plan Update Protocol - 10min
>>>
= >>> 7) Bundle-in-Bundle Encapsulation - 5min
>>>
&g= t;>> 8) Registry for Service Identifiers - 5min
>>>
&g= t;>> 9) Open Discussion - 50min
>>>
>>>
&g= t;>> Draft working group charter:
>>> *******************= *********
>>> Working group name:
>>>
>>&g= t;      Delay/Disruption Tolerant Networking Working Group = (DTNWG)
>>>
>>> Chair(s):
>>>
>&g= t;>      TBD
>>>
>>> Area and Ar= ea Director(s):
>>>
>>>      Transp= ort Area: ADs Spencer Dawkins <spencerdawkins.ietf at gmail.com>,
= >>>                  =         Martin Stiemerling <mls.ietf at gmail.com>
>>>
>>> Responsible Area Director:>>>
>>>      TBD
>>>
= >>> Mailing list:
>>>
>>>    &nb= sp; General Discussion: dtn at ietf.org
>>>     = ; To Subscribe: https://www.ietf.org/mailman/listinfo/dtn
>>>=       Archive:
>>> http://www= .ietf.org/mail-archive/web/dtn/current/maillist.html
>>>>>> Description of Working Group:
>>>
>>>=       The Delay/Disruption Tolerant Network Working Group (= DTNWG) specifies
>>>      mechanisms for data c= ommunications in the presence of long delays
>>>      and/or intermittent connectivity. The work is motivated by well kn= own
>>>      limitations of standard Internet p= rotocols that expect end-to-end
>>>      connec= tivity between communicating endpoints, sub-second transmission
>>= >      delays and robust packet delivery ratios. In envi= ronments where these
>>>      favorable conditi= ons do not apply, existing mechanisms encounter problems
>>>&nb= sp;     such as reliable transport protocol handshakes timing ou= t and routing
>>>      protocols failing to con= verge resulting in communication failures.
>>>    &nb= sp; Furthermore, classical end-to-end security associations cannot be
&= gt;>>      coordinated when communicating endpoints c= annot conduct multi-message
>>>     =20 keying exchanges in a timely fashion. These limitations suggested the
&= gt;>>      need for a new approach.
>>>>>>      Delay-Tolerant Networking (DTN) protoco= ls have been the subject of
>>>      extensive = research and development in the Delay-Tolerant Networking
>>>&n= bsp;     Research Group (DTNRG) of the Internet Research Task Fo= rce since 2002.
>>>      The DTNRG has develope= d the Delay-Tolerant Networking Architecture
>>>    &= nbsp; (RFC 4838) that the DTNWG uses as the basis for its work.  The = key
>>>      components of the this architectur= e are the bundle concept for
>>>      encapsula= ting data units, the bundle transmission protocol and the
>>>&n= bsp;     underlying convergence layer architecture.
>>>
>>>      The exp= erimental DTN Bundle Protocol (RFC 5050) and Licklider
>>> = ;     Transmission Protocol (RFC 5326) have been shown to addres= s the
>>>      issues identified above in subst= antial fielded deployments in the space
>>>     = sector [1].  RFC 5050 in conjunction with TCP- and UDP-based converg= ence
>>>      layers has been used successfully= in a number of experiments both in
>>>      co= mmunications challenged environments around the edges of the Internet
&g= t;>>      and as an Internet overlay where applicatio= ns require delay- and/or
>>>      disruption-to= lerance [refs needed].
>>>
>>>      = The success of the BP over convergence layer protocol stack -- the core
>>>      protocols of the "DTN Architectu= re" described in RFC 4838 -- may be
>>>      at= tributed to the following fundamental design principles:
>>>>>>    - There is never any expectation of contemporan= eous end-to-end
>>>          connecti= vity between any two network nodes.
>>>
>>>  &= nbsp; - Because end-to-end connectivity can never be assumed, each node>>>      on the path between source and destinati= on must be prepared to
>>>      handle incoming= "bundles" of data that cannot immediately be
>>>    =   forwarded.
>>>
>>>    - Again be= cause end-to-end connectivity can never be assumed,
>>>  &= nbsp;   end-to-end conversational data exchange can never be assumed to
>>>      complete in a timely manne= r; protocol features that rely on
>>>      time= ly conversational data exchange must be excluded from the
>>>&n= bsp;     architecture.
>>>
>>>  &nb= sp;   The DTNWG believes that protocols adhering to these principles = offer
>>>      opportunities for enhancing the = functionality of the Internet,
>>> including
>>>>>>        - facilitating the extension of t= he Internet into environments such as
>>>      &= nbsp;   the ocean floor and deep space in which the core Internet pro= tocols
>>>          operate sub-optim= ally for the reasons discussed earlier;
>>>
>>>&nbs= p;       - extending the Internet into communications challenged terrestrial
>>>      =     environments where it is not possible to provide continuous,= low
>>>          delay Internet conn= ections; and
>>>
>>>        - = supporting Internet applications that need DTN capabiliies.
>>>=
>>>      We believe that the extensive researc= h, demonstration, and
>>>      pilot operations= performed to date using the DTNRG protocols provides
>>> =     a firm basis for publishing Internet standards derived from= that work.
>>>
>>>      Work items= related to Delay/Disruption Tolerant Networking include:
>>>>>>      o A mechanism for the exchange of proto= col data units, termed
>>>        "bundles", that are designed to obviate conversational communications
&= gt;>>        by containing values for all potenti= ally relevant configuration
>>>        para= meters. These protocol data units are typically larger than
>>>=         network-layer packets. We will derive this bund= le exchange mechanism
>>>        from the = DTN Bundle Protocol (BP) documented in RFC 5050 by publishing
>>&g= t;        a new document for which [2] is a proposed f= irst draft (where
>>>        appendix A pr= ovides a summary of the proposed changes).
>>>
>>>&= nbsp;     o A security protocol for ensuring that the network in= which bundles
>>>        are exchanged is = secured against unauthorized access and denial of
>>>        service attacks, and to ensu= re data integrity and confidentiality
>>>      &= nbsp; in that network where necessary.  We will derive this security>>>        protocol from a "streamlined" ada= ptation of the DTN Bundle Security
>>>      &nbs= p; Protocol documented in RFC 6257.
>>>
>>>  &= nbsp;     o A delay-tolerant security key management scheme that = can protect
>>>          the integrity= of a DTN network.
>>>
>>>      o A= simple datagram convergence layer protocol for adaptation of the
>&g= t;>        bundle protocol to underlying internetwo= rks. We expect to derive
>>>        this c= onvergence layer protocol from the Datagram Convergence
>>>        protocol documente= d in RFC 7122.
>>>
>>>      o A pro= tocol for remote status monitoring, configuration, and
>>> = ;       administration of network nodes in the presence of = long delays
>>>        and/or intermittent= connectivity.
>>>
>>>      o A fun= ctional specification of Contact Graph Routing (CGR) specifying
>>= >        the inputs (global contact schedules, traf= fic demands, etc.) and
>>>        outputs = (node specific transmission and reception schedules,
>>>  =       notifications, etc.).  CGR is a centralized, ora= cle-based bundle
>>>        transmission a= nd reception scheduling scheme used in space segment
>>>        DTN deployments.
&g= t;>>
>>>      o An adjunct to the managem= ent protocol that will allow the contact
>>>     = ;   schedules generated by CGR to be distributed to nodes.  This= may be
>>>        based on the Contact Pl= an Update Protocol (CPUP) proposed in
>>>
>>> =     o An encapsulation protocol for "tunneling" BP traffic with= in bundles
>>>        that are secured and/= or routed in different way from the encapsulated
>>>  &nbs= p;     bundles.
>>>
>>>    &nbs= p; o A registry for DTN Service Identifiers
>>>
>>>= ;    The working group will consider extending the current miles= tones based on
>>>    new information and knowledge gained while working on the initial charter,
>>>&nbs= p;   as well as to accommodate new work items beyond the scope of the= initial
>>>    phase.  For example, we expect = that transport protocols such as LTP and
>>>    the = Saratoga protocol are among the candidates for work in this phase.
>&= gt;>
>>> Goals and Milestones:
>>>  start+= 0mos - Accept 'Bundle Protocol Specification (RFC5050bis)' [2] as
>&g= t;>                a working gro= up work item intended for Proposed Standard.
>>>  Start+0= mos - Accept 'Streamlined Bundle Security Protocol (SBSP)' [3] as
>&g= t;>                a working gro= up work item intended for Proposed Standard.
>>>  start+3= mos - Accept 'Bundle In Bundle Encapsulation (BIBE)' [4] as a
>>>                w= orking work item intended for Proposed Standard.
>>>  sta= rt+6mos - Working group getting concensus on changes to be implemented
&= gt;>>                in RFC 5= 050(bis).
>>>  start+9mos - Working group getting consens= us on merging RFC5050bis, SBSP,
>>>        =         BIBE etc. into a combined draft or keep as sepa= rate drafts.
>>>  start+12mos - Accept 'CGR Functional Sp= ecification' as a working group
>>>        =         working group work item intended for Informati= onal.
>>>  start+12mos - Accept 'Delay Tolerant Networkin= g Security Key Management'
>>>         = ;       as a working group work item intended for Proposed Standard.
>>>  start+15mos - Accept 'Contact Pl= an Update Protocol' as working group work
>>>    &nbs= p;           item intended for Proposed Standard.=
>>>  start+18mos - Submit RFC5050bis, SBSP, BIBE and Key= Mgmt to the IESG either
>>>          =       as a combined draft or as separate drafts.
>>= ;>  start+18mos - Submit Network Management [5], Registry [6] and = Simple
>>>              &nbs= p; Convergence Layer [7] as working group documents.
>>> = start+20mos - Survey appropriate forums (e.g., DTNRG) for emerging
>= ;>>                technolog= ies (e.g., convergence layer protocols, dynamic
>>>   = ;             routing protocols, naming and addressing services, etc.)
>>>      =           ready for transition into IETF DTN Work= ing Group. Publish
>>>           =     draft on survey results as independent submission related>>>                to t= he WG.
>>>  start+24mos - Submit Network Management, Regi= stry and Simple Convergence
>>>        &nbs= p;       Layer to IESG
>>>  start+24mos -= Recharter to accommodate new work items or close
>>> Working G= roup
>>>
>>>
>>> [1] "BP/LTP deployment= on EPOXI spacecraft" [2008],
>>>    http://committees.comsoc.org/tccc/ccw/2010/slides/DINET_= CCW.pdf
>>> [2] "Proposed Revised Bundle Protocol" [2014],<= br>>>>    https://datatracker.ietf.org/doc/dra= ft-burleigh-bpv7/
>>> [3] "Streamlined Bundle Security Prot= ocol Specification" [2014],
>>>    https:= //datatracker.ietf.org/doc/draft-irtf-dtnrg-sbsp/
>>> [4] "= Bundle-in-Bundle Encapsulation" [2013],
>>>    = http://tools.ietf.org/id/draft-irtf-burleigh-bibe
>>> [5] "= Delay Tolerant Network Management Protocol" [2013],
>>>  &= nbsp; http://tools.ietf.org/id/draft-irtf-dtnrg-dtnmp
&= gt;>> [6] "Delay-Tolerant Networking Bundle Protocol IANA Registries"= [2011],
>>>    https://datatracker.ietf.org/doc/rfc625= 5/
>>> [7] "Datagram Convergence Layers ..." [2014],
>= ;>>    https://datatracker.ietf.org/doc/rfc7122/
>&= gt;> [8] "Towards Flexibility and Accuracy in Space DTN Communications",=
>>>    Bezirgianndia et al, CHANTS 2012,
>>= ;>    http://dl.acm.org/citation.cfm?id=3D2505499 [2012]>>>
>>>
>>>
>>> ____________= ___________________________________
>>> dtn mailing list
>= ;>> dtn@ietf.o= rg
>>> https://www.ietf.org/mailman/listinfo/dtn
>&g= t;>
>
> _______________________________________________
&= gt; dtn mailing list
> dtn@ietf.org
> https://www.ietf.org/mailman/listin= fo/dtn
>
>

_________________________________________= ______
dtn mailing list
dtn@ietf.org
https://www.ietf.org/mailman/listinfo/d= tn

_______________________________________________
dtn mailin= g list
d= tn@ietf.org
https= ://www.ietf.org/mailman/listinfo/dtn

___________________________= ____________________
dtn mailing list
dtn@ietf.org
https://www.ietf.org/mail= man/listinfo/dtn


--461871616-879225364-1403528871=:11455-- From nobody Mon Jun 23 07:49:05 2014 Return-Path: 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 1074D1B2965 for ; Mon, 23 Jun 2014 07:49:03 -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 uUDIBta2umGm for ; Mon, 23 Jun 2014 07:48:58 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA6F81B296A for ; Mon, 23 Jun 2014 07:48:58 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp02.jpl.nasa.gov [128.149.137.149]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s5NEmvwL026580 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO) for ; Mon, 23 Jun 2014 07:48:58 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.217]) by ap-ehub-sp02.RES.AD.JPL ([fe80::dd85:7b07:1e36:7e3c%15]) with mapi id 14.03.0174.001; Mon, 23 Jun 2014 07:48:57 -0700 From: "Burleigh, Scott C (312G)" To: "dtn@ietf.org" Thread-Topic: [dtn] DTN Management Drafts Thread-Index: AQHPjOXi738joTNY0UCMTakpfIgn75t7PemAgAEpWICAAa5OAIAAsqaQ Date: Mon, 23 Jun 2014 14:48:56 +0000 Message-ID: References: <329D879C76FDD04AAAE84BB1D89B39700957131B8A@aplesfreedom.dom1.jhuapl.edu> <53A743F0.6070707@ohio.edu> In-Reply-To: <53A743F0.6070707@ohio.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.26] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/ZwGrkrruingZ2yu0s6rUppJ9Grw Subject: Re: [dtn] DTN Management Drafts X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 14:49:03 -0000 R2lsYmVydCwgY2FuIHlvdSBzYXkgYSBsaXR0bGUgbW9yZSBhYm91dCB0aGUga2luZHMgb2YgdHJh ZGUtb2ZmcyB5b3UncmUgdGhpbmtpbmcgb2YsIGFuZCBob3cgZGVjaXNpb25zIG9uIHRob3NlIHRy YWRlLW9mZnMgd291bGQgYWZmZWN0IHRoZSBkZXNpZ24gb2YgYSBuZXR3b3JrIG1hbmFnZW1lbnQg cHJvdG9jb2w/ICBXaGF0IGFyZSBzb21lIGV4YW1wbGVzPw0KDQpTY290dA0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogZHRuIFttYWlsdG86ZHRuLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBHaWxiZXJ0IENsYXJrDQpTZW50OiBTdW5kYXksIEp1bmUgMjIsIDIwMTQg MjowMSBQTQ0KVG86IGR0bkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtkdG5dIERUTiBNYW5hZ2Vt ZW50IERyYWZ0cw0KDQorMSB0aGF0IG1hbmFnZW1lbnQgaXMgYSByZXF1aXJlbWVudCBmb3Igb3Bl cmF0aW9uYWwgZGVwbG95bWVudC4NCg0KV2l0aCB0aGF0IHNhaWQsIEkgZG8gYWxzbyB3b25kZXIg aWYgdGhlIGluY2x1c2lvbiBvZiBzcGVjaWZpYyB1c2UtY2FzZXMgc2hvdWxkIGJlIGEgcmVxdWly ZW1lbnQgZm9yIGluY2x1ZGluZyB0aGUgZGV2ZWxvcG1lbnQgb2YgYW55ICpzcGVjaWZpYyBuZXR3 b3JrIG1hbmFnZW1lbnQgcHJvdG9jb2wqIGFzIGEgcGFydCBvZiB0aGlzIGNoYXJ0ZXIuICBOZXR3 b3JrIG1hbmFnZW1lbnQgaXMgZ29pbmcgdG8gbmVjZXNzYXJpbHkgaW52b2x2ZSBkaXNjdXNzaW5n IC8gZGVjaWRpbmcgb24gYSBudW1iZXIgb2YgdHJhZGUtb2ZmcyB0aGF0IHdpbGwgaW1wYWN0IG5v dCBvbmx5IHRoZSBuZXR3b3JrIGNvbmRpdGlvbnMgdGhlIHByb3RvY29sIGlzIGJlc3QgZXF1aXBw ZWQgdG8gc3VwcG9ydCwgYnV0IGFsc28gdGhlIGhhcmR3YXJlIHJlcXVpcmVtZW50cyBuZWNlc3Nh cnkgdG8gc3VwcG9ydCBydW5uaW5nIHRoZSBuZXcgcHJvdG9jb2wgc3RhY2sgaW4gdGhlIGZpcnN0 IHBsYWNlLiAgV2l0aG91dCBjb250ZXh0IGZvciBzdWNoIGEgY29udmVyc2F0aW9uLCBJIGRvbid0 IGJlbGlldmUgdGhlcmUgd2lsbCBvZnRlbiBiZSBhIGdvb2Qgd2F5IHRvIGFyZ3VlIHRoYXQgYSBz cGVjaWZpYyBkZWNpc2lvbiBpcyBlaXRoZXIgcmlnaHQgKm9yKiB3cm9uZy4NCg0KRm9yIHdoYXQg aXQncyB3b3J0aCwNCkdpbGJlcnQgQ2xhcmsNCg0KT24gNi8yMS8xNCwgMzoyMCBQTSwgSsOpZmVy c29uIENhbXBvcyBOb2JyZSB3cm90ZToNCj4gSGkgRWQuDQo+IEdyZWF0IG5ld3MgYWJvdXQgRFRO TVAuDQo+IEl0IHdvdWxkIGJlIGdvb2QgdG8gc2VlIHRoZSBEVE5NUCBkcmFmdCBhbmQgYSByZXZh bXBlZCBEVE4gbWFuYWdlbWVudCANCj4gcmVxdWlyZW1lbnRzIGluIHRoZSBjaGFydGVyLg0KPiBC ZXN0Lg0KPg0KPiBKw6lmZXJzb24gQ2FtcG9zIE5vYnJlDQo+IFBoRCBTdHVkZW50DQo+IENvbXB1 dGVyIE5ldHdvcmtzIEdyb3VwIC0gIEluc3RpdHV0ZSBvZiBJbmZvcm1hdGljcyBGZWRlcmFsIFVu aXZlcnNpdHkgDQo+IG9mIFJpbyBHcmFuZGUgZG8gU3VsIGh0dHA6Ly93d3cuaW5mLnVmcmdzLmJy L35qY25vYnJlDQo+DQo+IE9uIEZyaSwgSnVuIDIwLCAyMDE0IGF0IDEwOjM2IFBNLCBCaXJyYW5l LCBFZHdhcmQgSi4NCj4gPEVkd2FyZC5CaXJyYW5lQGpodWFwbC5lZHU+IHdyb3RlOg0KPj4gSGVs bG8sDQo+Pg0KPj4gICAgSSB3cm90ZSB1cCBEVE5NUCBhbmQgcHJvdmlkZWQgYW4gaW5pdGlhbCAo dGhvdWdoIG5vdCBmZWF0dXJlIGNvbXBsZXRlKSByZWZlcmVuY2UgaW1wbGVtZW50YXRpb24gaW4g SU9OLiBZZXMsIHRoZSBEVE5NUCBzcGVjIGZyb20gU2VwdGVtYmVyIGhhcyBleHBpcmVkIGFzIGFu IGludGVybmV0LWRyYWZ0LCBidXQgdGhlIHNwZWMgaXMgdW5kZXIgYWN0aXZlIGRldmVsb3BtZW50 IChJIGFtIGhvcGluZyB0byBoYXZlIGEgbmV3IHZlcnNpb24gcmVhZHkgYmVmb3JlIHRoZSBCT0Yp LiBUaGVyZSBpcyBmdW5kZWQgd29yayB0byBjb250aW51ZSBEVE5NUCBkZXZlbG9wbWVudCBhbmQg YXNzb2NpYXRlZCBzdGFuZGFyZHMgYW5kIHBsYW5zIGZvciBpdHMgb3BlcmF0aW9uYWwgZGVwbG95 bWVudC4NCj4+DQo+PiAgICBJIHRoaW5rIHRoYXQgbWFuYWdlbWVudCBpcyBhIHJlcXVpcmVtZW50 IGZvciBvcGVyYXRpb25hbCBkZXBsb3ltZW50IGFuZCBhZ3JlZSB0aGF0IGl0IHNob3VsZCBiZSBw YXJ0IG9mIHRoZSBjaGFydGVyLg0KPj4NCj4+IC1FZA0KPj4NCj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+IEZyb206IGR0biBbZHRuLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBKw6lmZXJzb24gQ2FtcG9zIE5vYnJlIA0KPj4gW2pjbm9icmVAaW5m LnVmcmdzLmJyXQ0KPj4gU2VudDogRnJpZGF5LCBKdW5lIDIwLCAyMDE0IDg6MTUgUE0NCj4+IFRv OiBkdG5AaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFtkdG5dIERUTiBNYW5hZ2VtZW50IERyYWZ0cw0K Pj4NCj4+IEhpLg0KPj4gV2l0aCBuZXR3b3JrIG1hbmFnZW1lbnQgYXMgYW4gaXRlbSBvZiB0aGUg RFROIEJvRiwgSSB0aGluayB3ZSBzaG91bGQgDQo+PiBwYXkgYXR0ZW50aW9uIHRvIHRoZSBEVE4g bWFuYWdlbWVudCBkcmFmdHMuVG8gbXkga25vd2xlZGdlLCBhbGwgDQo+PiBkcmFmdHMgYXJlIGV4 cGlyZWQgbm93Lg0KPj4gVGhlIHJlcXVpcmVtZW50cyBkcmFmdHMgKGRyYWZ0LWl2YW5jaWMtZHRu cmctbmV0d29yay1tYW5hZ2VtZW50IGFuZA0KPj4gZHJhZnQtY2xhcmstZHRucmctbmV0bWFuLXJl cSkgYXJlIGV4cGlyZWQgZm9yIGEgbG9uZyB0aW1lLCBidXQgSSANCj4+IHRoaW5rIHRoZXkgY2Fu IGJlIGltcG9ydGFudCB0byBkZWZpbmUgd2hhdCB0byBleHBlY3Qgb2YgbmV0d29yayANCj4+IG1h bmFnZW1lbnQgZmVhdHVyZXMgaW4gYSBwb3NzaWJsZSBEVE5XRy4NCj4+IENvbmNlcm5pbmcgcHJv dG9jb2wgb25lcyAoZHJhZnQtaXJ0Zi1kdG5yZy1kdG5tcCBhbmQgDQo+PiBkcmFmdC1pcnRmLWR0 bnJnLWRpbmctbmV0d29yay1tYW5hZ2VtZW50KSwgb25seSBEVE5NUCBoYXMgcmVjZWl2ZWQgDQo+ PiBhdHRlbnRpb24gcmVjZW50bHksIGFsdGhvdWdoIEkgYmVsaWV2ZSBESU5HIHdhcyBtZW50aW9u ZWQgaW4gdGhlIGxhc3QgDQo+PiBkaXNjdXNzaW9ucyAobm90IHN1cmUgaWYgaGVyZSBvciBpbiB0 aGUgZHRuLWludGVyZXN0IGxpc3QpLg0KPj4gUmV0dXJuaW5nIHRvIHRoZSBEVE4gQm9GOiBzaW5j ZSB3ZSBoYXZlIHRoZXNlIGRyYWZ0IHRoZXkgY291bGQvc2hvdWxkIA0KPj4gYXBwZWFyIGluIHRo ZSBwcm9ibGVtIHN0YXRlbWVudCBhbmQgc29sdXRpb25zIGl0ZW1zPw0KPj4gQ2hlZXJzLg0KPj4N Cj4+IErDqWZlcnNvbiBDYW1wb3MgTm9icmUNCj4+IFBoRCBTdHVkZW50DQo+PiBDb21wdXRlciBO ZXR3b3JrcyBHcm91cCAtICBJbnN0aXR1dGUgb2YgSW5mb3JtYXRpY3MgRmVkZXJhbCANCj4+IFVu aXZlcnNpdHkgb2YgUmlvIEdyYW5kZSBkbyBTdWwgaHR0cDovL3d3dy5pbmYudWZyZ3MuYnIvfmpj bm9icmUNCg== From nobody Mon Jun 23 12:20:22 2014 Return-Path: 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 3A3FF1B2C0C for ; Mon, 23 Jun 2014 12:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 aw37L1K5TL85 for ; Mon, 23 Jun 2014 12:20:19 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56DB01B2C0B for ; Mon, 23 Jun 2014 12:20:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s5NJKIY4030041; Mon, 23 Jun 2014 12:20:18 -0700 Received: from XCH-PHX-203.sw.nos.boeing.com (xch-phx-203.sw.nos.boeing.com [137.136.238.14]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s5NJK88h029032 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Mon, 23 Jun 2014 12:20:08 -0700 Received: from XCH-BLV-413.nw.nos.boeing.com (137.136.239.135) by XCH-PHX-203.sw.nos.boeing.com (137.136.238.14) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 23 Jun 2014 12:20:08 -0700 Received: from XCH-BLV-512.nw.nos.boeing.com ([169.254.12.74]) by XCH-BLV-413.nw.nos.boeing.com ([169.254.13.193]) with mapi id 14.03.0181.006; Mon, 23 Jun 2014 12:20:07 -0700 From: "Templin, Fred L" To: "dtn@ietf.org" Thread-Topic: Preliminary IETF90 Agenda Posted Thread-Index: Ac+PGCRGqbOcGy3uQFK7WxD6bZxP0Q== Date: Mon, 23 Jun 2014 19:20:07 +0000 Message-ID: <2134F8430051B64F815C691A62D9831830491F9B@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: multipart/alternative; boundary="_000_2134F8430051B64F815C691A62D9831830491F9BXCHBLV512nwnosb_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/sIdMkhH4mXOY7JnPVtQc8NRyaYE Subject: [dtn] Preliminary IETF90 Agenda Posted X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 19:20:21 -0000 --_000_2134F8430051B64F815C691A62D9831830491F9BXCHBLV512nwnosb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The preliminary agenda for IETF90 has been posted (agenda will be finalized June 27th): https://datatracker.ietf.org/meeting/90/agenda.html https://datatracker.ietf.org/meeting/90/agenda.txt The DTN BoF is currently scheduled for 1520-1650 on Wednesday, July 23rd. Thanks - Fred fred.l.templin@boeing.com --_000_2134F8430051B64F815C691A62D9831830491F9BXCHBLV512nwnosb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The preliminary agenda for IETF90 has been posted= (agenda

will be finalized June 27th):

 

https://datatracker.ietf.org/meeting/90/agenda.html=

https://datatracker.ietf.org/meeting/90/agenda.txt

 

The DTN BoF is currently scheduled for 1520-1650 on = Wednesday, July 23rd.

 

Thanks – Fred

fred.l.templin@boeing.com

--_000_2134F8430051B64F815C691A62D9831830491F9BXCHBLV512nwnosb_-- From nobody Mon Jun 23 23:18:14 2014 Return-Path: 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 7E18F1B283A for ; Mon, 23 Jun 2014 23:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.149 X-Spam-Level: X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.651] 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 7gNpFI-nvgnm for ; Mon, 23 Jun 2014 23:18:09 -0700 (PDT) Received: from mx5.oit.ohio.edu (mx5.oit.ohio.edu [132.235.200.36]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2460C1B2800 for ; Mon, 23 Jun 2014 23:18:08 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AugDAN0XqVOE6whkXGdsb2JhbABaFoNJg0enUQaRWRyHQAGBHQQYDQkHPIQDAQEBAQMBAQEgDwEFNgoNBAsRBAEBAQICBRQCCAMCAgkDAgECARUcAwkIEwYCAQEWAYgnDaY/mCmFUReBKoQ5g2OEbVAGgnGBTASaTIFFhw2FDolhIS+BAw X-IPAS-Result: AugDAN0XqVOE6whkXGdsb2JhbABaFoNJg0enUQaRWRyHQAGBHQQYDQkHPIQDAQEBAQMBAQEgDwEFNgoNBAsRBAEBAQICBRQCCAMCAgkDAgECARUcAwkIEwYCAQEWAYgnDaY/mCmFUReBKoQ5g2OEbVAGgnGBTASaTIFFhw2FDolhIS+BAw Received: from mail.ohio.edu (HELO clarkg1-osx.local) ([132.235.8.100]) by mx5.oit.ohio.edu with ESMTP/TLS/DHE-RSA-AES128-SHA; 24 Jun 2014 02:17:56 -0400 Message-ID: <53A91812.1010603@ohio.edu> Date: Tue, 24 Jun 2014 02:17:54 -0400 From: Gilbert Clark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dtn@ietf.org References: <329D879C76FDD04AAAE84BB1D89B39700957131B8A@aplesfreedom.dom1.jhuapl.edu> <53A743F0.6070707@ohio.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/yy_jxrsEy4gJtDfPPb_vhz6pfeo Subject: Re: [dtn] DTN Management Drafts X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 06:18:12 -0000 Hi Scott: No guarantees on coherence / intelligent discourse here, but a few thoughts ... * What's an acceptable level of overhead (both on the node and on the network) for a DTN network management protocol? Reducing node overhead might involve building a simpler protocol, deploying less sophisticated self-management capabilities, and / or giving the node better hardware. Reducing network overhead might involve sending fewer updates, sending less accurate updates (e.g. aggregate statistics instead of individual updates), or giving the node better hardware to support doing more elaborate things with the data (e.g. better compression). * Situational optimizations are usually going to require making assumptions. For example, if we know a device is going to continually be sending updates in a relatively fixed format, then it makes sense to find ways to cut metadata from the transmissions because said metadata is going to be redundant information. More generally, the less we *know* about the managed devices and / or the managed networks, the more information we'll be forced to encode / send across the wire. Also, the less we *know* about the managed devices and their capabilities, the more complex the resulting protocol is (probably) going to become. * Link characteristics are going to influence the kind of data the protocol can record and send. For example: With high delay, high capacity, and high reliability, the links become pretty effective storage buffers of their own: 8 minutes of delay (= 480 seconds) * 1 Mbps with no loss => the link is effectively a buffer / storage device for up to 480 million bits of information. This kind of link is probably going to work pretty well for streaming (possibly incremental) updates, but is also going to demand open-loop design / larger degrees of automation on the nodes due to the RTT involved. On the other hand, networks with links that are less predictable but with lower latency are going to require more flexibility with regard to both the type and quantity of data that is sent ... but maybe network links would flash into / out of existence often enough that there's a reasonable chance that a command will make it to a remote node in a reasonable amount of time. For these cases, maybe it would make sense to look at adapting a more MANET-like NM protocol to work with DTN. * Including some kind of support for existing infrastructure (e.g. support for IPFIX, SNMP, etc) into a DTN NM protocol might be a consideration. It could be that the WG would want to design a DTN NM protocol in a way such that it'd be marginally less efficient / effective for DTN operation, but would also have a more straightforward interaction with existing NM protocols. Offering the capability to re-use existing NM infrastructure for DTN monitoring and / or management might (or might not) be an attractive option for some. Maybe I'm missing something here and the above is way off-base and / or already completely obvious to everyone, but ... I do still believe that the more specifically we can define the goals for a network management protocol, the better the protocol is going to eventually turn out :) -Gilbert On 6/23/14, 10:48 AM, Burleigh, Scott C (312G) wrote: > Gilbert, can you say a little more about the kinds of trade-offs you're thinking of, and how decisions on those trade-offs would affect the design of a network management protocol? What are some examples? > > Scott > > -----Original Message----- > From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of Gilbert Clark > Sent: Sunday, June 22, 2014 2:01 PM > To: dtn@ietf.org > Subject: Re: [dtn] DTN Management Drafts > > +1 that management is a requirement for operational deployment. > > With that said, I do also wonder if the inclusion of specific use-cases should be a requirement for including the development of any *specific network management protocol* as a part of this charter. Network management is going to necessarily involve discussing / deciding on a number of trade-offs that will impact not only the network conditions the protocol is best equipped to support, but also the hardware requirements necessary to support running the new protocol stack in the first place. Without context for such a conversation, I don't believe there will often be a good way to argue that a specific decision is either right *or* wrong. > > For what it's worth, > Gilbert Clark > > On 6/21/14, 3:20 PM, Jéferson Campos Nobre wrote: >> Hi Ed. >> Great news about DTNMP. >> It would be good to see the DTNMP draft and a revamped DTN management >> requirements in the charter. >> Best. >> >> Jéferson Campos Nobre >> PhD Student >> Computer Networks Group - Institute of Informatics Federal University >> of Rio Grande do Sul http://www.inf.ufrgs.br/~jcnobre >> >> On Fri, Jun 20, 2014 at 10:36 PM, Birrane, Edward J. >> wrote: >>> Hello, >>> >>> I wrote up DTNMP and provided an initial (though not feature complete) reference implementation in ION. Yes, the DTNMP spec from September has expired as an internet-draft, but the spec is under active development (I am hoping to have a new version ready before the BOF). There is funded work to continue DTNMP development and associated standards and plans for its operational deployment. >>> >>> I think that management is a requirement for operational deployment and agree that it should be part of the charter. >>> >>> -Ed >>> >>> ________________________________________ >>> From: dtn [dtn-bounces@ietf.org] On Behalf Of Jéferson Campos Nobre >>> [jcnobre@inf.ufrgs.br] >>> Sent: Friday, June 20, 2014 8:15 PM >>> To: dtn@ietf.org >>> Subject: [dtn] DTN Management Drafts >>> >>> Hi. >>> With network management as an item of the DTN BoF, I think we should >>> pay attention to the DTN management drafts.To my knowledge, all >>> drafts are expired now. >>> The requirements drafts (draft-ivancic-dtnrg-network-management and >>> draft-clark-dtnrg-netman-req) are expired for a long time, but I >>> think they can be important to define what to expect of network >>> management features in a possible DTNWG. >>> Concerning protocol ones (draft-irtf-dtnrg-dtnmp and >>> draft-irtf-dtnrg-ding-network-management), only DTNMP has received >>> attention recently, although I believe DING was mentioned in the last >>> discussions (not sure if here or in the dtn-interest list). >>> Returning to the DTN BoF: since we have these draft they could/should >>> appear in the problem statement and solutions items? >>> Cheers. >>> >>> Jéferson Campos Nobre >>> PhD Student >>> Computer Networks Group - Institute of Informatics Federal >>> University of Rio Grande do Sul http://www.inf.ufrgs.br/~jcnobre > _______________________________________________ > dtn mailing list > dtn@ietf.org > https://www.ietf.org/mailman/listinfo/dtn From nobody Tue Jun 24 08:29:02 2014 Return-Path: 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 141261B2DB8 for ; Tue, 24 Jun 2014 08:28:57 -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 t5Luw5KpwuzM for ; Tue, 24 Jun 2014 08:28:46 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 542051B2DBD for ; Tue, 24 Jun 2014 08:25:26 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp02.jpl.nasa.gov [128.149.137.149]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s5OFOsTF014733 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO) for ; Tue, 24 Jun 2014 08:24:55 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.217]) by ap-ehub-sp02.RES.AD.JPL ([fe80::dd85:7b07:1e36:7e3c%15]) with mapi id 14.03.0174.001; Tue, 24 Jun 2014 08:25:25 -0700 From: "Burleigh, Scott C (312G)" To: "dtn@ietf.org" Thread-Topic: [dtn] DTN Management Drafts Thread-Index: AQHPjOXi738joTNY0UCMTakpfIgn75t7PemAgAEpWICAAa5OAIAAsqaQgAF7aQCAACN70A== Date: Tue, 24 Jun 2014 15:25:24 +0000 Message-ID: References: <329D879C76FDD04AAAE84BB1D89B39700957131B8A@aplesfreedom.dom1.jhuapl.edu> <53A743F0.6070707@ohio.edu> <53A91812.1010603@ohio.edu> In-Reply-To: <53A91812.1010603@ohio.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.26] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/TexjqJ7ln3hY5Od7AKi0wCbUN7c Subject: Re: [dtn] DTN Management Drafts X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 15:28:57 -0000 VGhhbmtzLCBHaWxiZXJ0LCB0aGlzIGlzIHZlcnkgaGVscGZ1bC4NCg0KU2NvdHQNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGR0biBbbWFpbHRvOmR0bi1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgR2lsYmVydCBDbGFyaw0KU2VudDogTW9uZGF5LCBKdW5lIDIzLCAy MDE0IDExOjE4IFBNDQpUbzogZHRuQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2R0bl0gRFROIE1h bmFnZW1lbnQgRHJhZnRzDQoNCkhpIFNjb3R0Og0KDQpObyBndWFyYW50ZWVzIG9uIGNvaGVyZW5j ZSAvIGludGVsbGlnZW50IGRpc2NvdXJzZSBoZXJlLCBidXQgYSBmZXcgdGhvdWdodHMgLi4uDQoN CiogV2hhdCdzIGFuIGFjY2VwdGFibGUgbGV2ZWwgb2Ygb3ZlcmhlYWQgKGJvdGggb24gdGhlIG5v ZGUgYW5kIG9uIHRoZQ0KbmV0d29yaykgZm9yIGEgRFROIG5ldHdvcmsgbWFuYWdlbWVudCBwcm90 b2NvbD8gIFJlZHVjaW5nIG5vZGUgb3ZlcmhlYWQgbWlnaHQgaW52b2x2ZSBidWlsZGluZyBhIHNp bXBsZXIgcHJvdG9jb2wsIGRlcGxveWluZyBsZXNzIHNvcGhpc3RpY2F0ZWQgc2VsZi1tYW5hZ2Vt ZW50IGNhcGFiaWxpdGllcywgYW5kIC8gb3IgZ2l2aW5nIHRoZSBub2RlIGJldHRlciBoYXJkd2Fy ZS4gIA0KUmVkdWNpbmcgbmV0d29yayBvdmVyaGVhZCBtaWdodCBpbnZvbHZlIHNlbmRpbmcgZmV3 ZXIgdXBkYXRlcywgc2VuZGluZyBsZXNzIGFjY3VyYXRlIHVwZGF0ZXMgKGUuZy4gYWdncmVnYXRl IHN0YXRpc3RpY3MgaW5zdGVhZCBvZiBpbmRpdmlkdWFsIHVwZGF0ZXMpLCBvciBnaXZpbmcgdGhl IG5vZGUgYmV0dGVyIGhhcmR3YXJlIHRvIHN1cHBvcnQgZG9pbmcgbW9yZSBlbGFib3JhdGUgdGhp bmdzIHdpdGggdGhlIGRhdGEgKGUuZy4gYmV0dGVyIGNvbXByZXNzaW9uKS4NCg0KKiBTaXR1YXRp b25hbCBvcHRpbWl6YXRpb25zIGFyZSB1c3VhbGx5IGdvaW5nIHRvIHJlcXVpcmUgbWFraW5nIGFz c3VtcHRpb25zLiAgRm9yIGV4YW1wbGUsIGlmIHdlIGtub3cgYSBkZXZpY2UgaXMgZ29pbmcgdG8g Y29udGludWFsbHkgYmUgc2VuZGluZyB1cGRhdGVzIGluIGEgcmVsYXRpdmVseSBmaXhlZCBmb3Jt YXQsIHRoZW4gaXQgbWFrZXMgc2Vuc2UgdG8gZmluZCB3YXlzIHRvIGN1dCBtZXRhZGF0YSBmcm9t IHRoZSB0cmFuc21pc3Npb25zIGJlY2F1c2Ugc2FpZCBtZXRhZGF0YSBpcyBnb2luZyB0byBiZSBy ZWR1bmRhbnQgaW5mb3JtYXRpb24uICBNb3JlIGdlbmVyYWxseSwgdGhlIGxlc3Mgd2UNCiprbm93 KiBhYm91dCB0aGUgbWFuYWdlZCBkZXZpY2VzIGFuZCAvIG9yIHRoZSBtYW5hZ2VkIG5ldHdvcmtz LCB0aGUgbW9yZSBpbmZvcm1hdGlvbiB3ZSdsbCBiZSBmb3JjZWQgdG8gZW5jb2RlIC8gc2VuZCBh Y3Jvc3MgdGhlIHdpcmUuICBBbHNvLCB0aGUgbGVzcyB3ZSAqa25vdyogYWJvdXQgdGhlIG1hbmFn ZWQgZGV2aWNlcyBhbmQgdGhlaXIgY2FwYWJpbGl0aWVzLCB0aGUgbW9yZSBjb21wbGV4IHRoZSBy ZXN1bHRpbmcgcHJvdG9jb2wgaXMgKHByb2JhYmx5KSBnb2luZyB0byBiZWNvbWUuDQoNCiogTGlu ayBjaGFyYWN0ZXJpc3RpY3MgYXJlIGdvaW5nIHRvIGluZmx1ZW5jZSB0aGUga2luZCBvZiBkYXRh IHRoZSBwcm90b2NvbCBjYW4gcmVjb3JkIGFuZCBzZW5kLiAgRm9yIGV4YW1wbGU6DQoNCldpdGgg aGlnaCBkZWxheSwgaGlnaCBjYXBhY2l0eSwgYW5kIGhpZ2ggcmVsaWFiaWxpdHksIHRoZSBsaW5r cyBiZWNvbWUgcHJldHR5IGVmZmVjdGl2ZSBzdG9yYWdlIGJ1ZmZlcnMgb2YgdGhlaXIgb3duOiA4 IG1pbnV0ZXMgb2YgZGVsYXkgKD0gNDgwDQpzZWNvbmRzKSAqIDEgTWJwcyB3aXRoIG5vIGxvc3Mg PT4gdGhlIGxpbmsgaXMgZWZmZWN0aXZlbHkgYSBidWZmZXIgLyBzdG9yYWdlIGRldmljZSBmb3Ig dXAgdG8gNDgwIG1pbGxpb24gYml0cyBvZiBpbmZvcm1hdGlvbi4gIFRoaXMga2luZCBvZiBsaW5r IGlzIHByb2JhYmx5IGdvaW5nIHRvIHdvcmsgcHJldHR5IHdlbGwgZm9yIHN0cmVhbWluZyAocG9z c2libHkNCmluY3JlbWVudGFsKSB1cGRhdGVzLCBidXQgaXMgYWxzbyBnb2luZyB0byBkZW1hbmQg b3Blbi1sb29wIGRlc2lnbiAvIGxhcmdlciBkZWdyZWVzIG9mIGF1dG9tYXRpb24gb24gdGhlIG5v ZGVzIGR1ZSB0byB0aGUgUlRUIGludm9sdmVkLg0KDQpPbiB0aGUgb3RoZXIgaGFuZCwgbmV0d29y a3Mgd2l0aCBsaW5rcyB0aGF0IGFyZSBsZXNzIHByZWRpY3RhYmxlIGJ1dCB3aXRoIGxvd2VyIGxh dGVuY3kgYXJlIGdvaW5nIHRvIHJlcXVpcmUgbW9yZSBmbGV4aWJpbGl0eSB3aXRoIHJlZ2FyZCB0 byBib3RoIHRoZSB0eXBlIGFuZCBxdWFudGl0eSBvZiBkYXRhIHRoYXQgaXMgc2VudCAuLi4gYnV0 IG1heWJlIG5ldHdvcmsgbGlua3Mgd291bGQgZmxhc2ggaW50byAvIG91dCBvZiBleGlzdGVuY2Ug b2Z0ZW4gZW5vdWdoIHRoYXQgdGhlcmUncyBhIHJlYXNvbmFibGUgY2hhbmNlIHRoYXQgYSBjb21t YW5kIHdpbGwgbWFrZSBpdCB0byBhIHJlbW90ZSBub2RlIGluIGEgcmVhc29uYWJsZSBhbW91bnQg b2YgdGltZS4gIEZvciB0aGVzZSBjYXNlcywgbWF5YmUgaXQgd291bGQgbWFrZSBzZW5zZSB0byBs b29rIGF0IGFkYXB0aW5nIGEgbW9yZSBNQU5FVC1saWtlIE5NIHByb3RvY29sIHRvIHdvcmsgd2l0 aCBEVE4uDQoNCiogSW5jbHVkaW5nIHNvbWUga2luZCBvZiBzdXBwb3J0IGZvciBleGlzdGluZyBp bmZyYXN0cnVjdHVyZSAoZS5nLiANCnN1cHBvcnQgZm9yIElQRklYLCBTTk1QLCBldGMpIGludG8g YSBEVE4gTk0gcHJvdG9jb2wgbWlnaHQgYmUgYSBjb25zaWRlcmF0aW9uLiAgSXQgY291bGQgYmUg dGhhdCB0aGUgV0cgd291bGQgd2FudCB0byBkZXNpZ24gYSBEVE4gTk0gcHJvdG9jb2wgaW4gYSB3 YXkgc3VjaCB0aGF0IGl0J2QgYmUgbWFyZ2luYWxseSBsZXNzIGVmZmljaWVudCAvIGVmZmVjdGl2 ZSBmb3IgRFROIG9wZXJhdGlvbiwgYnV0IHdvdWxkIGFsc28gaGF2ZSBhIG1vcmUgc3RyYWlnaHRm b3J3YXJkIGludGVyYWN0aW9uIHdpdGggZXhpc3RpbmcgTk0gcHJvdG9jb2xzLiAgT2ZmZXJpbmcg dGhlIGNhcGFiaWxpdHkgdG8gcmUtdXNlIGV4aXN0aW5nIE5NIGluZnJhc3RydWN0dXJlIGZvciBE VE4gbW9uaXRvcmluZyBhbmQgLyBvciBtYW5hZ2VtZW50IG1pZ2h0IChvciBtaWdodCBub3QpIGJl IGFuIGF0dHJhY3RpdmUgb3B0aW9uIGZvciBzb21lLg0KDQpNYXliZSBJJ20gbWlzc2luZyBzb21l dGhpbmcgaGVyZSBhbmQgdGhlIGFib3ZlIGlzIHdheSBvZmYtYmFzZSBhbmQgLyBvciBhbHJlYWR5 IGNvbXBsZXRlbHkgb2J2aW91cyB0byBldmVyeW9uZSwgYnV0IC4uLiBJIGRvIHN0aWxsIGJlbGll dmUgdGhhdCB0aGUgbW9yZSBzcGVjaWZpY2FsbHkgd2UgY2FuIGRlZmluZSB0aGUgZ29hbHMgZm9y IGEgbmV0d29yayBtYW5hZ2VtZW50IHByb3RvY29sLCB0aGUgYmV0dGVyIHRoZSBwcm90b2NvbCBp cyBnb2luZyB0byBldmVudHVhbGx5IHR1cm4gb3V0IDopDQoNCi1HaWxiZXJ0DQoNCk9uIDYvMjMv MTQsIDEwOjQ4IEFNLCBCdXJsZWlnaCwgU2NvdHQgQyAoMzEyRykgd3JvdGU6DQo+IEdpbGJlcnQs IGNhbiB5b3Ugc2F5IGEgbGl0dGxlIG1vcmUgYWJvdXQgdGhlIGtpbmRzIG9mIHRyYWRlLW9mZnMg eW91J3JlIHRoaW5raW5nIG9mLCBhbmQgaG93IGRlY2lzaW9ucyBvbiB0aG9zZSB0cmFkZS1vZmZz IHdvdWxkIGFmZmVjdCB0aGUgZGVzaWduIG9mIGEgbmV0d29yayBtYW5hZ2VtZW50IHByb3RvY29s PyAgV2hhdCBhcmUgc29tZSBleGFtcGxlcz8NCj4NCj4gU2NvdHQNCj4NCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogZHRuIFttYWlsdG86ZHRuLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBHaWxiZXJ0IENsYXJrDQo+IFNlbnQ6IFN1bmRheSwgSnVuZSAyMiwgMjAx NCAyOjAxIFBNDQo+IFRvOiBkdG5AaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtkdG5dIERUTiBN YW5hZ2VtZW50IERyYWZ0cw0KPg0KPiArMSB0aGF0IG1hbmFnZW1lbnQgaXMgYSByZXF1aXJlbWVu dCBmb3Igb3BlcmF0aW9uYWwgZGVwbG95bWVudC4NCj4NCj4gV2l0aCB0aGF0IHNhaWQsIEkgZG8g YWxzbyB3b25kZXIgaWYgdGhlIGluY2x1c2lvbiBvZiBzcGVjaWZpYyB1c2UtY2FzZXMgc2hvdWxk IGJlIGEgcmVxdWlyZW1lbnQgZm9yIGluY2x1ZGluZyB0aGUgZGV2ZWxvcG1lbnQgb2YgYW55ICpz cGVjaWZpYyBuZXR3b3JrIG1hbmFnZW1lbnQgcHJvdG9jb2wqIGFzIGEgcGFydCBvZiB0aGlzIGNo YXJ0ZXIuICBOZXR3b3JrIG1hbmFnZW1lbnQgaXMgZ29pbmcgdG8gbmVjZXNzYXJpbHkgaW52b2x2 ZSBkaXNjdXNzaW5nIC8gZGVjaWRpbmcgb24gYSBudW1iZXIgb2YgdHJhZGUtb2ZmcyB0aGF0IHdp bGwgaW1wYWN0IG5vdCBvbmx5IHRoZSBuZXR3b3JrIGNvbmRpdGlvbnMgdGhlIHByb3RvY29sIGlz IGJlc3QgZXF1aXBwZWQgdG8gc3VwcG9ydCwgYnV0IGFsc28gdGhlIGhhcmR3YXJlIHJlcXVpcmVt ZW50cyBuZWNlc3NhcnkgdG8gc3VwcG9ydCBydW5uaW5nIHRoZSBuZXcgcHJvdG9jb2wgc3RhY2sg aW4gdGhlIGZpcnN0IHBsYWNlLiAgV2l0aG91dCBjb250ZXh0IGZvciBzdWNoIGEgY29udmVyc2F0 aW9uLCBJIGRvbid0IGJlbGlldmUgdGhlcmUgd2lsbCBvZnRlbiBiZSBhIGdvb2Qgd2F5IHRvIGFy Z3VlIHRoYXQgYSBzcGVjaWZpYyBkZWNpc2lvbiBpcyBlaXRoZXIgcmlnaHQgKm9yKiB3cm9uZy4N Cj4NCj4gRm9yIHdoYXQgaXQncyB3b3J0aCwNCj4gR2lsYmVydCBDbGFyaw0KPg0KPiBPbiA2LzIx LzE0LCAzOjIwIFBNLCBKw6lmZXJzb24gQ2FtcG9zIE5vYnJlIHdyb3RlOg0KPj4gSGkgRWQuDQo+ PiBHcmVhdCBuZXdzIGFib3V0IERUTk1QLg0KPj4gSXQgd291bGQgYmUgZ29vZCB0byBzZWUgdGhl IERUTk1QIGRyYWZ0IGFuZCBhIHJldmFtcGVkIERUTiBtYW5hZ2VtZW50IA0KPj4gcmVxdWlyZW1l bnRzIGluIHRoZSBjaGFydGVyLg0KPj4gQmVzdC4NCj4+DQo+PiBKw6lmZXJzb24gQ2FtcG9zIE5v YnJlDQo+PiBQaEQgU3R1ZGVudA0KPj4gQ29tcHV0ZXIgTmV0d29ya3MgR3JvdXAgLSAgSW5zdGl0 dXRlIG9mIEluZm9ybWF0aWNzIEZlZGVyYWwgDQo+PiBVbml2ZXJzaXR5IG9mIFJpbyBHcmFuZGUg ZG8gU3VsIGh0dHA6Ly93d3cuaW5mLnVmcmdzLmJyL35qY25vYnJlDQo+Pg0KPj4gT24gRnJpLCBK dW4gMjAsIDIwMTQgYXQgMTA6MzYgUE0sIEJpcnJhbmUsIEVkd2FyZCBKLg0KPj4gPEVkd2FyZC5C aXJyYW5lQGpodWFwbC5lZHU+IHdyb3RlOg0KPj4+IEhlbGxvLA0KPj4+DQo+Pj4gICAgIEkgd3Jv dGUgdXAgRFROTVAgYW5kIHByb3ZpZGVkIGFuIGluaXRpYWwgKHRob3VnaCBub3QgZmVhdHVyZSBj b21wbGV0ZSkgcmVmZXJlbmNlIGltcGxlbWVudGF0aW9uIGluIElPTi4gWWVzLCB0aGUgRFROTVAg c3BlYyBmcm9tIFNlcHRlbWJlciBoYXMgZXhwaXJlZCBhcyBhbiBpbnRlcm5ldC1kcmFmdCwgYnV0 IHRoZSBzcGVjIGlzIHVuZGVyIGFjdGl2ZSBkZXZlbG9wbWVudCAoSSBhbSBob3BpbmcgdG8gaGF2 ZSBhIG5ldyB2ZXJzaW9uIHJlYWR5IGJlZm9yZSB0aGUgQk9GKS4gVGhlcmUgaXMgZnVuZGVkIHdv cmsgdG8gY29udGludWUgRFROTVAgZGV2ZWxvcG1lbnQgYW5kIGFzc29jaWF0ZWQgc3RhbmRhcmRz IGFuZCBwbGFucyBmb3IgaXRzIG9wZXJhdGlvbmFsIGRlcGxveW1lbnQuDQo+Pj4NCj4+PiAgICAg SSB0aGluayB0aGF0IG1hbmFnZW1lbnQgaXMgYSByZXF1aXJlbWVudCBmb3Igb3BlcmF0aW9uYWwg ZGVwbG95bWVudCBhbmQgYWdyZWUgdGhhdCBpdCBzaG91bGQgYmUgcGFydCBvZiB0aGUgY2hhcnRl ci4NCj4+Pg0KPj4+IC1FZA0KPj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4+IEZyb206IGR0biBbZHRuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBKw6lmZXJzb24gQ2FtcG9zIE5vYnJlIA0KPj4+IFtqY25vYnJlQGluZi51ZnJncy5icl0N Cj4+PiBTZW50OiBGcmlkYXksIEp1bmUgMjAsIDIwMTQgODoxNSBQTQ0KPj4+IFRvOiBkdG5AaWV0 Zi5vcmcNCj4+PiBTdWJqZWN0OiBbZHRuXSBEVE4gTWFuYWdlbWVudCBEcmFmdHMNCj4+Pg0KPj4+ IEhpLg0KPj4+IFdpdGggbmV0d29yayBtYW5hZ2VtZW50IGFzIGFuIGl0ZW0gb2YgdGhlIERUTiBC b0YsIEkgdGhpbmsgd2Ugc2hvdWxkIA0KPj4+IHBheSBhdHRlbnRpb24gdG8gdGhlIERUTiBtYW5h Z2VtZW50IGRyYWZ0cy5UbyBteSBrbm93bGVkZ2UsIGFsbCANCj4+PiBkcmFmdHMgYXJlIGV4cGly ZWQgbm93Lg0KPj4+IFRoZSByZXF1aXJlbWVudHMgZHJhZnRzIChkcmFmdC1pdmFuY2ljLWR0bnJn LW5ldHdvcmstbWFuYWdlbWVudCBhbmQNCj4+PiBkcmFmdC1jbGFyay1kdG5yZy1uZXRtYW4tcmVx KSBhcmUgZXhwaXJlZCBmb3IgYSBsb25nIHRpbWUsIGJ1dCBJIA0KPj4+IHRoaW5rIHRoZXkgY2Fu IGJlIGltcG9ydGFudCB0byBkZWZpbmUgd2hhdCB0byBleHBlY3Qgb2YgbmV0d29yayANCj4+PiBt YW5hZ2VtZW50IGZlYXR1cmVzIGluIGEgcG9zc2libGUgRFROV0cuDQo+Pj4gQ29uY2VybmluZyBw cm90b2NvbCBvbmVzIChkcmFmdC1pcnRmLWR0bnJnLWR0bm1wIGFuZCANCj4+PiBkcmFmdC1pcnRm LWR0bnJnLWRpbmctbmV0d29yay1tYW5hZ2VtZW50KSwgb25seSBEVE5NUCBoYXMgcmVjZWl2ZWQg DQo+Pj4gYXR0ZW50aW9uIHJlY2VudGx5LCBhbHRob3VnaCBJIGJlbGlldmUgRElORyB3YXMgbWVu dGlvbmVkIGluIHRoZSANCj4+PiBsYXN0IGRpc2N1c3Npb25zIChub3Qgc3VyZSBpZiBoZXJlIG9y IGluIHRoZSBkdG4taW50ZXJlc3QgbGlzdCkuDQo+Pj4gUmV0dXJuaW5nIHRvIHRoZSBEVE4gQm9G OiBzaW5jZSB3ZSBoYXZlIHRoZXNlIGRyYWZ0IHRoZXkgDQo+Pj4gY291bGQvc2hvdWxkIGFwcGVh ciBpbiB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgYW5kIHNvbHV0aW9ucyBpdGVtcz8NCj4+PiBDaGVl cnMuDQo+Pj4NCj4+PiBKw6lmZXJzb24gQ2FtcG9zIE5vYnJlDQo+Pj4gUGhEIFN0dWRlbnQNCj4+ PiBDb21wdXRlciBOZXR3b3JrcyBHcm91cCAtICBJbnN0aXR1dGUgb2YgSW5mb3JtYXRpY3MgRmVk ZXJhbCANCj4+PiBVbml2ZXJzaXR5IG9mIFJpbyBHcmFuZGUgZG8gU3VsIGh0dHA6Ly93d3cuaW5m LnVmcmdzLmJyL35qY25vYnJlDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IGR0biBtYWlsaW5nIGxpc3QNCj4gZHRuQGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZHRuDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkdG4gbWFpbGluZyBsaXN0DQpkdG5AaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZHRuDQo= From nobody Tue Jun 24 10:55:52 2014 Return-Path: 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 3CF361B2975 for ; Tue, 24 Jun 2014 10:55:47 -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 uLm0gha45802 for ; Tue, 24 Jun 2014 10:55:45 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F191B1B2982 for ; Tue, 24 Jun 2014 10:55:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s5OHteQq020511; Tue, 24 Jun 2014 10:55:40 -0700 Received: from XCH-PHX-210.sw.nos.boeing.com (xch-phx-210.sw.nos.boeing.com [130.247.25.65]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s5OHtY8L020068 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Tue, 24 Jun 2014 10:55:34 -0700 Received: from XCH-BLV-308.nw.nos.boeing.com (2002:82f7:19dc::82f7:19dc) by XCH-PHX-210.sw.nos.boeing.com (2002:82f7:1941::82f7:1941) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 24 Jun 2014 10:55:34 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.118]) by XCH-BLV-308.nw.nos.boeing.com ([169.254.8.96]) with mapi id 14.03.0181.006; Tue, 24 Jun 2014 10:55:33 -0700 From: "Templin, Fred L" To: "dtn@ietf.org" Thread-Topic: DTN BoF Agenda Posted Thread-Index: AQHPj9V+KEaQrr4eAUauUkE1adN2Fw== Date: Tue, 24 Jun 2014 17:55:33 +0000 Message-ID: <2134F8430051B64F815C691A62D9831830498ECC@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831830491F9B@XCH-BLV-512.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831830491F9B@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: [130.247.104.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/ZYZK0YMvy8CN1b4ugV9CqPm9CVM Subject: [dtn] DTN BoF Agenda Posted X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 17:55:47 -0000 The DTN BoF Agenda has been posted: https://datatracker.ietf.org/meeting/90/agenda/dtnwg/ Please send any comments to the list. Thanks - Fred fred.l.templin@boeing.com From nobody Thu Jun 26 14:22:10 2014 Return-Path: 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 731991B2E90 for ; Thu, 26 Jun 2014 14:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 DHHduHNtkxgb for ; Thu, 26 Jun 2014 14:22:06 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC1FA1B2E6F for ; Thu, 26 Jun 2014 14:22:05 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id q58so4339390wes.2 for ; Thu, 26 Jun 2014 14:22:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:date:subject:to :message-id:mime-version; bh=y84hK+2OD13RNFaMUJZSUot1EQUCDE4ecsg7beDf5Y4=; b=W7PtbJViErCpzjSk+AZcHPZDwv9w41wBCCQJCkrAF8wObKqLMR4Gaf8nNU2mlsBGr0 jl5qsgghskSJJm2hA6HB2YRUvj5gNPEndip3zBCH30HesQwK8KC0Lslmes1LNAzx/N7R iPKJVCSU3Yy+4YfcwwGzw5pl38dex39v93LIe+Ow/T6/kfElHh4G48rDmFO5obIWXqwR /x4dAQFjCxNaRigobTcXiaX/eIc6JrHEtxJ+A9FJfEzh57Bu07wd0UGmD562Byuz9zgQ NOIvN+xLX6SlOcLR//VJa1/3IYZ+y4MO4JWQVstxQG2tgKdZbcUCgNaPuE7UWXyYX8Xv HkZw== X-Received: by 10.194.89.168 with SMTP id bp8mr21054511wjb.73.1403817724309; Thu, 26 Jun 2014 14:22:04 -0700 (PDT) Received: from [192.168.1.2] (dsl-aaus56.dyn.edudsl.gr. [37.32.155.250]) by mx.google.com with ESMTPSA id bq7sm70019405wib.7.2014.06.26.14.22.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Jun 2014 14:22:03 -0700 (PDT) From: Nikolaos Bezirgiannidis Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Jun 2014 00:22:01 +0300 To: "dtn@ietf.org" Message-Id: <368FB574-103B-4942-9C7D-484BFF0F8FD3@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/nDNzPGGcXF3HaODR5Xn09K_P-tE Subject: [dtn] Contact Plan Update Protocol Draft X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 21:22:07 -0000 Hello, I won=92t be able to attend the Toronto meeting, but I would like to = note that I am willing to contribute to the Working Group charter with = the drafting of Contact Plan Update Protocol specification. Regards, Nikos= From nobody Fri Jun 27 09:12:41 2014 Return-Path: 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 662731B3008 for ; Fri, 27 Jun 2014 09:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 irdWq0F7uSeS for ; Fri, 27 Jun 2014 09:12:37 -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 AF4B11B2C1C for ; Fri, 27 Jun 2014 09:12:37 -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 s5RGCZXB020456; Fri, 27 Jun 2014 11:12:35 -0500 Received: from XCH-PHX-113.sw.nos.boeing.com (xch-phx-113.sw.nos.boeing.com [130.247.25.136]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s5RGCXfQ020442 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Fri, 27 Jun 2014 11:12:34 -0500 Received: from XCH-BLV-404.nw.nos.boeing.com (2002:82f7:199d::82f7:199d) by XCH-PHX-113.sw.nos.boeing.com (2002:82f7:1988::82f7:1988) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 27 Jun 2014 09:12:33 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.118]) by XCH-BLV-404.nw.nos.boeing.com ([169.254.4.24]) with mapi id 14.03.0181.006; Fri, 27 Jun 2014 09:12:33 -0700 From: "Templin, Fred L" To: "dtn@ietf.org" Thread-Topic: Remote conferencing requirements Thread-Index: Ac+SIpoPvkJRKkTYTVqKjcVychF3FQ== Date: Fri, 27 Jun 2014 16:12:33 +0000 Message-ID: <2134F8430051B64F815C691A62D983183049C7A1@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: multipart/alternative; boundary="_000_2134F8430051B64F815C691A62D983183049C7A1XCHBLV504nwnosb_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/fOBl9ftR-afuBlbxen3f0QqG-8k Subject: [dtn] Remote conferencing requirements X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 16:12:39 -0000 --_000_2134F8430051B64F815C691A62D983183049C7A1XCHBLV504nwnosb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Let me get a show of hands of those who will not be able to attend IETF90 b= ut would like to attend the DTN BoF via remote conferencing. Please respond to this message if remote conferencing services are desired. Thanks - Fred fred.l.templin@boeing.com --_000_2134F8430051B64F815C691A62D983183049C7A1XCHBLV504nwnosb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Let me get a show of hands of those who will not be = able to attend IETF90 but

would like to attend the DTN BoF via remote conferen= cing. Please respond to

this message if remote conferencing services are des= ired.

 

Thanks – Fred

fred.l.templin@boeing.com

--_000_2134F8430051B64F815C691A62D983183049C7A1XCHBLV504nwnosb_-- From nobody Fri Jun 27 09:18:34 2014 Return-Path: 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 4A0931B324F for ; Fri, 27 Jun 2014 09:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, 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 F41ZH5vbU0uZ for ; Fri, 27 Jun 2014 09:18:28 -0700 (PDT) Received: from smtp1.ist.utl.pt (smtp1.ist.utl.pt [IPv6:2001:690:2100:1::15]) by ietfa.amsl.com (Postfix) with ESMTP id 195771B30C8 for ; Fri, 27 Jun 2014 09:18:28 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp1.ist.utl.pt (Postfix) with ESMTP id 2E51F70004D5; Fri, 27 Jun 2014 17:18:27 +0100 (WEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at ist.utl.pt Received: from smtp1.ist.utl.pt ([127.0.0.1]) by localhost (smtp1.ist.utl.pt [127.0.0.1]) (amavisd-new, port 10025) with LMTP id jx7g9IGNfMfJ; Fri, 27 Jun 2014 17:18:26 +0100 (WEST) Received: from mail2.ist.utl.pt (mail.ist.utl.pt [IPv6:2001:690:2100:1::8]) by smtp1.ist.utl.pt (Postfix) with ESMTP id A3F9E70004D0; Fri, 27 Jun 2014 17:18:26 +0100 (WEST) Received: from VAIOSVS (kim.inesc-id.pt [146.193.48.20]) (Authenticated sender: ist166217) by mail2.ist.utl.pt (Postfix) with ESMTPSA id 39077200BB93; Fri, 27 Jun 2014 17:18:26 +0100 (WEST) From: "Naercio Magaia" To: "'Templin, Fred L'" , References: <2134F8430051B64F815C691A62D983183049C7A1@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983183049C7A1@XCH-BLV-504.nw.nos.boeing.com> Date: Fri, 27 Jun 2014 17:18:27 +0100 Message-ID: <004701cf9223$6de1a9d0$49a4fd70$@tecnico.ulisboa.pt> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0048_01CF922B.CFA79870" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQKpeTJqheBjorH97/2fq3SSLHEmoZnRU0cQ Content-Language: pt Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/Fp0_7paJOuH43SQc7mKxQ0x1sxc Subject: Re: [dtn] Remote conferencing requirements X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 16:18:33 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0048_01CF922B.CFA79870 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Fred,=20 =20 If possible I would like to attend the DTN BoF via remote conferencing. =20 Regards =20 Na=E9rcio Magaia=20 PhD Student in Electrical and Computer Engineering=20 INESC-ID/IST/ULISBOA=20 Rua Alves Redol, 9, Room 507=20 Email: naercio.magaia@tecnico.ulisboa.pt=20 Phone: +351 21 3100286 =20 From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of Templin, Fred L Sent: 27 de junho de 2014 17:13 To: dtn@ietf.org Subject: [dtn] Remote conferencing requirements =20 Let me get a show of hands of those who will not be able to attend = IETF90 but would like to attend the DTN BoF via remote conferencing. Please respond = to this message if remote conferencing services are desired. =20 Thanks =96 Fred fred.l.templin@boeing.com =20 ------=_NextPart_000_0048_01CF922B.CFA79870 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Fred, =

 

If possible I would = like to attend the DTN BoF via remote = conferencing.

 

Regards

 

Na=E9rcio Magaia =

PhD Student in = Electrical and Computer Engineering

INESC-ID/IST/ULISBOA =

Rua Alves Redol, 9, = Room 507

Email: = naercio.magaia@tecnico.ulisboa.pt

Phone:=A0=A0=A0 +351 = 21 3100286

 

From: dtn = [mailto:dtn-bounces@ietf.org] On Behalf Of Templin, Fred = L
Sent: 27 de junho de 2014 17:13
To: = dtn@ietf.org
Subject: [dtn] Remote conferencing = requirements

 

Let me get a show of hands of those who will not be able to = attend IETF90 but

would like to attend the DTN BoF via remote conferencing. = Please respond to

this message if remote conferencing services are = desired.

 

Thanks – Fred

fred.l.templin@boeing.com

------=_NextPart_000_0048_01CF922B.CFA79870-- From nobody Fri Jun 27 09:30:19 2014 Return-Path: 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 A20541B2D04 for ; Fri, 27 Jun 2014 09:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 pA7kEu5xpy7o for ; Fri, 27 Jun 2014 09:30:16 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2CA01B2992 for ; Fri, 27 Jun 2014 09:30:15 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id t60so5509821wes.28 for ; Fri, 27 Jun 2014 09:30:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=SZ5wuJJgxrydb2r04hSvkXTBQWl2tvS6nla8OTZEPrM=; b=wmh/M3oYWuHLUwBmw6/ZqWroG5jBpMiO7FlW5C4scENn36LvGu7wG4mOG6pwrfXFAg wN+p4QBiEyl6hX5kjOq7AawYY5uPhtC44aepBpopkkrjI1FBZlOsDSKcI1f6Dtdz09uk q6lMXsEZIYtyoINVHEuUGNicjuZ/1yMCwguIwkzR0D3xSbJBXIXZTgifUp5aoT57aRh6 PjsG0T9vrOkQD7Q5GO+cXphDQ1ow50nHG8+wdhkQkdfGOcyZIA9OfwVDrW0A5dg/lYZm pT5yVrAkI5FAUUA7lcxxlThJNTVRT/xAaje2oyZ3aBK4rLBRWbEFSQ0OudoqyLe/3c1I X6GA== MIME-Version: 1.0 X-Received: by 10.180.205.138 with SMTP id lg10mr6553954wic.49.1403886614351; Fri, 27 Jun 2014 09:30:14 -0700 (PDT) Received: by 10.216.202.132 with HTTP; Fri, 27 Jun 2014 09:30:14 -0700 (PDT) In-Reply-To: <004701cf9223$6de1a9d0$49a4fd70$@tecnico.ulisboa.pt> References: <2134F8430051B64F815C691A62D983183049C7A1@XCH-BLV-504.nw.nos.boeing.com> <004701cf9223$6de1a9d0$49a4fd70$@tecnico.ulisboa.pt> Date: Fri, 27 Jun 2014 13:30:14 -0300 Message-ID: From: "Juan A. Fraire" To: "Templin, Fred L" , dtn@ietf.org Content-Type: multipart/alternative; boundary=001a11c38594f4159404fcd3d2fa Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/RaNkWbtoqnZa5t5XbmBcK7qrtyc Subject: Re: [dtn] Remote conferencing requirements X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 16:30:17 -0000 --001a11c38594f4159404fcd3d2fa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Fred, I would also like to remotely join the IETF90 meeting. Regards, J.Fraire Universidad Nacional de C=C3=B3rdoba, Argentina Servicios Tecnol=C3=B3gicos Integrados S.R.L. On Fri, Jun 27, 2014 at 1:18 PM, Naercio Magaia < naercio.magaia@tecnico.ulisboa.pt> wrote: > Hi Fred, > > > > If possible I would like to attend the DTN BoF via remote conferencing. > > > > Regards > > > > Na=C3=A9rcio Magaia > > PhD Student in Electrical and Computer Engineering > > INESC-ID/IST/ULISBOA > > Rua Alves Redol, 9, Room 507 > > Email: naercio.magaia@tecnico.ulisboa.pt > > Phone: +351 21 3100286 > > > > *From:* dtn [mailto:dtn-bounces@ietf.org] *On Behalf Of *Templin, Fred L > *Sent:* 27 de junho de 2014 17:13 > *To:* dtn@ietf.org > *Subject:* [dtn] Remote conferencing requirements > > > > Let me get a show of hands of those who will not be able to attend IETF90 > but > > would like to attend the DTN BoF via remote conferencing. Please respond = to > > this message if remote conferencing services are desired. > > > > Thanks =E2=80=93 Fred > > fred.l.templin@boeing.com > > _______________________________________________ > dtn mailing list > dtn@ietf.org > https://www.ietf.org/mailman/listinfo/dtn > > --001a11c38594f4159404fcd3d2fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Fred,

I=C2=A0would also like to re= motely join the IETF90 meeting.

Regards,

J.Fraire
Universidad Nacional de C=C3=B3rdoba, Ar= gentina
Servicios Tecnol=C3=B3gicos Integrados S.R.L.


On Fri, Jun 27, 2014 at 1:= 18 PM, Naercio Magaia <naercio.magaia@tecnico.ulisboa.pt> wrote:

Hi Fred,

= =C2=A0

If possible I would like to attend the DTN BoF via remot= e conferencing.

= =C2=A0

Regards

<= span lang=3D"EN-US" style=3D"color:#1f497d">=C2=A0

Na=C3= =A9rcio Magaia

PhD Student in Electrical and Computer E= ngineering

INESC-ID/IST/ULISBOA <= u>

Rua Alves Redol, 9, Room 507

Email: naercio.magaia@tecnico.= ulisboa.pt

Phone:= =C2=A0=C2=A0=C2=A0 +351 21 3100286

=C2=A0

From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of Templin, Fred L
= Sent: 27 de junho de 2014 17:13
To: dtn@ietf.org
Subject: [dtn] Remote conferencing requirements<= /span>


____________________________________= ___________
dtn mailing list
dtn@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dtn


--001a11c38594f4159404fcd3d2fa-- From nobody Fri Jun 27 10:31:04 2014 Return-Path: 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 99F5C1B28F8 for ; Fri, 27 Jun 2014 10:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 HxIk9o7B1d2U for ; Fri, 27 Jun 2014 10:30:53 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 619141A037D for ; Fri, 27 Jun 2014 10:30:53 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id k14so5502531wgh.18 for ; Fri, 27 Jun 2014 10:30:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=qN5UySJxM2IHx0xtL+3EGmKBNUNGM88jzcx8kD1Bgt0=; b=VFwTw0zkbO4bSHYUmYR7seLbrSZKkdmSbM8zX5RIxNZT6n2wibZ4/oa6/YRCDjhunr qT1CG+Se5oiyRs21pN8cTVKcQDlx9YRzFKiKnFRfWiJHqSQD88Zpbwz8rja7O+m1hjpO ivE4g6Tc2y7i5hGqiIBSG1jhqF9CkXzjNRKM3RYjTFlRD5o7ixhJ8g4hUclXcXtn12W+ gDgMWm8tuZLTksVyw27qr4iIreA/Z8ERZ3RV8b+qoBBHkAYvP+UsO82WJNhU+fFkATTM NRtekpnNDeguFFsW0Y5mOoVdHGr++SNAlFcT/px9uSiOBveIRKWdcJNpvrYhhlsEgY2s JmXg== X-Received: by 10.180.12.137 with SMTP id y9mr12976313wib.46.1403890251872; Fri, 27 Jun 2014 10:30:51 -0700 (PDT) Received: from [192.168.1.2] (dsl-aaus56.dyn.edudsl.gr. [37.32.155.250]) by mx.google.com with ESMTPSA id o12sm80100760wiw.5.2014.06.27.10.30.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Jun 2014 10:30:51 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_FCF37B9A-CA33-43BC-BB6F-BB4F959DDFAC" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Nikolaos Bezirgiannidis In-Reply-To: Date: Fri, 27 Jun 2014 20:30:49 +0300 Message-Id: <23C00D0F-B3A7-4151-B426-8518F005A5B5@gmail.com> References: <2134F8430051B64F815C691A62D983183049C7A1@XCH-BLV-504.nw.nos.boeing.com> <004701cf9223$6de1a9d0$49a4fd70$@tecnico.ulisboa.pt> To: "Juan A. Fraire" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/uWk9FSyy6aQiWhXsAfXJwmflAEc Cc: "Templin, Fred L" , dtn@ietf.org Subject: Re: [dtn] Remote conferencing requirements X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 17:31:01 -0000 --Apple-Mail=_FCF37B9A-CA33-43BC-BB6F-BB4F959DDFAC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Fred, I would also like to remotely attend the DTN BoF meeting, if possible. Regards, Nikos On Jun 27, 2014, at 7:30 PM, Juan A. Fraire = wrote: > Dear Fred, >=20 > I would also like to remotely join the IETF90 meeting. >=20 > Regards, >=20 > J.Fraire > Universidad Nacional de C=F3rdoba, Argentina > Servicios Tecnol=F3gicos Integrados S.R.L. >=20 >=20 > On Fri, Jun 27, 2014 at 1:18 PM, Naercio Magaia = wrote: > Hi Fred, >=20 > =20 >=20 > If possible I would like to attend the DTN BoF via remote = conferencing. >=20 > =20 >=20 > Regards >=20 > =20 >=20 > Na=E9rcio Magaia >=20 > PhD Student in Electrical and Computer Engineering >=20 > INESC-ID/IST/ULISBOA >=20 > Rua Alves Redol, 9, Room 507 >=20 > Email: naercio.magaia@tecnico.ulisboa.pt >=20 > Phone: +351 21 3100286 >=20 > =20 >=20 > From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of Templin, Fred L > Sent: 27 de junho de 2014 17:13 > To: dtn@ietf.org > Subject: [dtn] Remote conferencing requirements >=20 > =20 >=20 > Let me get a show of hands of those who will not be able to attend = IETF90 but >=20 > would like to attend the DTN BoF via remote conferencing. Please = respond to >=20 > this message if remote conferencing services are desired. >=20 > =20 >=20 > Thanks =96 Fred >=20 > fred.l.templin@boeing.com >=20 >=20 > _______________________________________________ > dtn mailing list > dtn@ietf.org > https://www.ietf.org/mailman/listinfo/dtn >=20 >=20 > _______________________________________________ > dtn mailing list > dtn@ietf.org > https://www.ietf.org/mailman/listinfo/dtn --Apple-Mail=_FCF37B9A-CA33-43BC-BB6F-BB4F959DDFAC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi Fred,

I would = also like to remotely attend the DTN BoF meeting, if = possible.

Regards,
Nikos
On Jun 27, 2014, at 7:30 PM, Juan A. Fraire <juanfraire@gmail.com> = wrote:

Dear = Fred,

I would also like to remotely join the = IETF90 = meeting.

Regards,

J.Frai= re
Universidad Nacional de C=F3rdoba, Argentina
Servicios Tecnol=F3gicos Integrados S.R.L.


On Fri, Jun 27, = 2014 at 1:18 PM, Naercio Magaia <naercio.magaia@tecnico.ulisboa.pt> = wrote:

Hi Fred,

 

If = possible I would like to attend the DTN BoF via remote = conferencing.

 

Regards

 

Na=E9rcio= Magaia

PhD Student in Electrical and = Computer Engineering

INESC-ID/IST/ULISBOA =

Rua Alves Redol, 9, Room 507 =

Email: naercio.magaia@tecnico.ulisboa.pt =

Phone:    +351 21 = 3100286

 

From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of Templin, = Fred L
Sent: 27 de junho de 2014 17:13
To: dtn@ietf.org
Subject: [dtn] Remote = conferencing requirements

 

Let me get a show of hands of = those who will not be able to attend IETF90 = but

would like to attend the DTN BoF via remote conferencing. = Please respond to

this message if remote conferencing services are = desired.

 

Thanks =96 Fred

fred.l.templin@boeing.com


_______________________________________________
dtn mailing list
dtn@ietf.org
https://www.ietf.org/mailman/listinfo/dtn


_______________________________________________
dtn mailing = list
dtn@ietf.org
https://www.ietf.org/mail= man/listinfo/dtn

= --Apple-Mail=_FCF37B9A-CA33-43BC-BB6F-BB4F959DDFAC-- From nobody Fri Jun 27 12:21:48 2014 Return-Path: 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 C4E7F1A002F for ; Fri, 27 Jun 2014 12:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 h05IB1OXl1d5 for ; Fri, 27 Jun 2014 12:21:45 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 245761A000D for ; Fri, 27 Jun 2014 12:21:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s5RJLiRH012214; Fri, 27 Jun 2014 14:21:44 -0500 Received: from XCH-PHX-412.sw.nos.boeing.com (xch-phx-412.sw.nos.boeing.com [10.57.37.44]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s5RJLY8H011909 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Fri, 27 Jun 2014 14:21:35 -0500 Received: from XCH-BLV-205.nw.nos.boeing.com (10.57.37.61) by XCH-PHX-412.sw.nos.boeing.com (10.57.37.44) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 27 Jun 2014 12:21:34 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.118]) by XCH-BLV-205.nw.nos.boeing.com ([169.254.5.221]) with mapi id 14.03.0181.006; Fri, 27 Jun 2014 12:21:33 -0700 From: "Templin, Fred L" To: "dtn@ietf.org" Thread-Topic: [dtn] Remote conferencing requirements Thread-Index: AQHPkiUSvkJRKkTYTVqKjcVychF3FZuFM3+g Date: Fri, 27 Jun 2014 19:21:33 +0000 Message-ID: <2134F8430051B64F815C691A62D983183049C97D@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983183049C7A1@XCH-BLV-504.nw.nos.boeing.com> <004701cf9223$6de1a9d0$49a4fd70$@tecnico.ulisboa.pt> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: multipart/alternative; boundary="_000_2134F8430051B64F815C691A62D983183049C97DXCHBLV504nwnosb_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/ZJDBhEzmMFMyf6ALxLOAilMDL70 Subject: Re: [dtn] Remote conferencing requirements X-BeenThere: dtn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 19:21:46 -0000 --_000_2134F8430051B64F815C691A62D983183049C97DXCHBLV504nwnosb_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIHRoZXJlIGhhcyBiZWVuIGVub3VnaCBpbnRlcmVzdCBleHByZXNzZWQgKG9uIGFuZCBvZmYg bGlzdCkgc3VjaCB0aGF0IHRoZSBjaGFpcnMNCndpbGwgYXJyYW5nZSBmb3IgcmVtb3RlIGNvbmZl cmVuY2luZy4NCg0KVGhhbmtzIC0gRnJlZA0K --_000_2134F8430051B64F815C691A62D983183049C97DXCHBLV504nwnosb_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv QWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28t c3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SGksIHRoZXJlIGhhcyBiZWVuIGVub3VnaCBpbnRlcmVzdCBleHByZXNzZWQgKG9uIGFu ZCBvZmYgbGlzdCkgc3VjaCB0aGF0IHRoZSBjaGFpcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+d2lsbCBhcnJhbmdlIGZvciByZW1vdGUgY29uZmVyZW5jaW5nLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhh bmtzIC0gRnJlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_2134F8430051B64F815C691A62D983183049C97DXCHBLV504nwnosb_--