Re: [dtn] Draft charter for review

COMMENTS IN LINE

>
>Draft working group charter:
>****************************
>Working group name:
>
>      Delay/Disruption Tolerant Networking Working Group (DTNWG)

I suggest going with Disruption Tolerant Networking.  Propagation delay is
a transport problem.  IMHO, This is really a store and forward problem.
Actually, LTP  is really a transport protocol - mainly used for scheduled,
predictive links.

Are we going to standardize LTP here?  It is not stated as a deliverable
below.  Should it be?

>
>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 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]. 

Regarding reference to [1] I don't know if I would call this substantial.
I think bundles were limited t 64K.  If so, that really doesn't stress
LTP.  However, I think LTP was done with larger files or streams in long
delays (but with deployments in ground systems.

>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.

Personally, I don't agree with the above paragraph.  I would prefer to
strike the above.

>
>      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.

I think a lessons learned document would be very useful. This probably
should be done regardless and could be done in the DTNRG.  I'll think
about this and see if there is interest.

>
>      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).

Strike "for which [2] is a proposed first draft (where appendix A provides
a summary of the proposed changes)."  I don't think this belongs in a
charter.  IMHO, this point to a solution prior to identifying the problem
and requirements.

>
>      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.

Strike: "We will derive this security
	   protocol from a "streamlined" adaptation of the DTN Bundle Security
	   Protocol documented in RFC 6257."

I see know reason to restrict yourself to RFC6257 particularly since 6257
is based on RFC5050 formats which are likely to change.

>
>      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.

I don't understand the IPv6 reference here.

I suspect you may need bundle-in-bundle encapsulation to do a simplified
bundle security specification.

> 
>
>      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

As suggested before, MIME may fit this need.

>  
>    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.

As stated previously, stating we are working to standardize reference 2 is
premature.  Unless, of course that is the intent of this working group.
If so, then just make that the charter.

>  Start+0mos - Accept 'Streamlined Bundle Security Protocol (SBSP)' [3] as
>               a working group work item intended for Proposed Standard.

Again Premature.

>  start+6mos - Working group getting concensus on changes to be
>implemented
>               in RFC 5050(bis).

IMHO, This and the problems statement and lessons learned need to be the
first items.  Only after this are in firm agreement, should we be
considering solutions.

>  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.

I don't think the previously two items belong in the charter as is.  These
have already been covered as Items 2 and 3.

>  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
>dtn@ietf.org
>https://www.ietf.org/mailman/listinfo/dtn