Hello,
 I like short, to the point, text, protocol specs and charters. So, please consider below as an individual contribution for a charter. As you will see, shortened version. ;-)

Marc.

==============================
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 Stiemerling <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. 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 key documents are the « DTN Architecture » (RFC 4838), the 
     Bundle Protocol (RFC 5050), Licklider Transmission Protocol (RFC 5326)
     and convergence layers (RFC 7122, 7242). Multiple independent implementations
     exist for these technologies and multiple deployments in space and terrestrial
     environments. There is an increase interest in the commercial world for these 
     technologies, for similar and different use cases, such as unmanned air vehicles.
     In this context, there is a need to update the base specifications based on the 
     deployment and implementation experience as well as the new use cases. Moreover,
     there is also a need to have standards track documents for the market. 

     Therefore, the purpose of the working group is to document the new use cases and 
     requirements and to update the base specifications. The group shall not endeavour to
     change the underlying architecture or the bundle protocol principle.

     Work items are:

     o An informational « DTN Problem Statement, Use Cases and Requirements"
       document

     o Updates to RFC5050, convergence layer RFCs, security(RFC6257), as standard track documents.

     o A registry for DTN Service Identifiers

     Work such as routing, neighbor/contact discovery, security key management, 
     network management, bundle-in-bundle encapsulation and reliable bundle delivery
     are currently out of scope.

     Before the updates of the protocol specifications are endeavoured, the Problem statement should
     be agreed within the working group and with the IESG, specially on what the updates will be. 

Goals and Milestones:

TBD