Re: [dtn] Draft charter for review

["Burleigh, Scott C (312G)" <[e-mail]>]

That's my understanding too: as noted in the minutes of the meeting, there was a general consensus that the charter should be reviewed again to make it initially simpler.  That's what this email thread is about.

Scott

From: dtn [[e-mail]] on behalf of Joerg Ott [[e-mail]]
Sent: Thursday, August 07, 2014 4:39 AM
To: Sebastian Schildt; Templin, Fred L
Cc: [e-mail]
Subject: Re: [dtn] Draft charter for review

Hi,
there is nothing decided at this point and my hunch is that if we want
to proceed there will be another BOF (or email discussion) until people
can agree on the charter.  I would consider a second BOF not unlikely.

But forming a working group requires consensus on what it shall do,
hence the continued charter discussion.

Jörg

On 07.08.2014 14:26, Sebastian Schildt wrote:
> 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
>
>
>
> _______________________________________________
> dtn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtn
>

_______________________________________________
dtn mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dtn