Re: [dtn] Draft charter for review

[Sebastian Schildt <[e-mail]>]

Hi,

I am a bit at a loss here: What happened after the IETF BoF session (I did attend remotely) , or what do we still expect to happen? Will there maybe or definitely a WG? Is this to refine the charter further, or is this a rewrite for a "second try"? It has been a bit silent here after the BoF._If_ there might be a WG, what needs to be done now (except polishing the charter)?


Sebastian



Am 07.08.2014 um 01:48 schrieb Templin, Fred L <[e-mail]>:

> Hello,
> 
> Please see below for a revised draft charter for public review.
> Please send comments to the list so that we may have an open
> discussion.
> 
> Thanks - Fred
> [e-mail]
> 
> 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 <spencerdawkins.ietf at gmail.com>,
>                          Martin Stiemerling <mls.ietf at gmail.com>
> 
> Responsible Area Director:
> 
>      Martin Steimerling <mls.ietf at gmail.com>
> 
> 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 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 therefore be excluded
>       from the architecture or coupled with DTN-aware proxies.
> 
>      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 use cases that need DTN capabilities.
> 
>      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 An informational "Problem Statement, Use Cases and Requirements"
>        document - to be co-authored by industry partners with interest
>        in progression of the working group standards-track work items.
> 
>      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 An informational "DTN Advanced Features Survey" document including
>        candidate recharter work items such as routing, neighbor (contact)
>        discovery, security key management, network management, bundle-in
>        -bundle encapsulation, reliable bundle delivery, IPv6, etc. 
> 
>      o Simple convergence layer protocols for adaptation of the bundle
>        protocol to underlying internetworks. We expect to derive these
>        convergence layer protocols from the Datagram Convergence protocol
>        documented in RFC 7122 and the TCP Convergence-Layer Protocol
>        documented in RFC 7242.
> 
>      o A registry for DTN Service Identifiers
> 
>    The working group will consider adding supplementary work items 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.
> 
> Goals and Milestones:
>  start+0mos - Accept 'DTN Problem Statement, Use Cases and Requirements' as
>               a working group work item intended for Informational.
>  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+6mos - Working group getting concensus on changes to be implemented
>               in RFC 5050(bis).
>  start+6mos - Accept 'DTN Advanced Features Survey' as a working group work
>               item intended for Informational.
>  start+9mos - Working group getting consensus on merging RFC5050bis and
>               SBSP into a combined draft or keep as separate drafts.
>  start+12mos - Submit RFC5050bis and SBSP to the IESG either as a combined
>                draft or as separate drafts.
>  start+15mos - Submit Registry [4] and Simple Convergence Layer [5][6] as
>                working group documents.
>  start+16mos - 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 Registry and Simple Convergence Layer to IESG
>  start+18mos - 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] "Delay-Tolerant Networking Bundle Protocol IANA Registries" [2011],
>    https://datatracker.ietf.org/doc/rfc6255/
> [5] "Datagram Convergence Layers ..." [2014],
>    https://datatracker.ietf.org/doc/rfc7122/
> [6] "TCP Convergence-Layer Protocol..." [2014],
>    https://datatracker.ietf.org/doc/rfc7242/
> 
> _______________________________________________
> dtn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtn