Re: [dtn] Draft charter for review

[Stephen Farrell <[e-mail]>]

Apologies for the top post.

1. If this style of minimal change (*) charter is where we go,
then I really think a refinement of the over-long list that
Scott presented at the BoF has to happen before a wg is
formed. That'd change this charter text quite a bit I think
since e.g. there'd be no need for a problem statement RFC
then.

2. Separate to the above, I'm going to try one more time
to argue for a less minimal change. I think that I'm in
the rough on that, but after the BoF a bit less so than
I expected. And if, as I expect, I remain in the rough
there, then I'll shut up about it and be weakly supportive
of the minimal style charter Fred's proposing. I won't
get to proposing that for a week or so though.

Cheers,
S.

(*) "minimal" is not a pejorative term here, but as
previously discussed on the list is meant to denote the
amount of intended change from rfc5050.

On 07/08/14 00:48, Templin, Fred L wrote:
> 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
> 
>