Re: [dtn] Draft charter for review

["Templin, Fred L" <[e-mail]>]

Hi Will,

Sorry, I missed the IPv6 consideration per your earlier note. IPv6 ND and DHCPv6 are
methods for contact discovery that could be applied in a DTN realm in a way that is
not as well supported for IPv4. This also touches on a point raised by others with
vendor interests in DTN. So, maybe rewrite as:

      o An informational "DTN Advanced Features Survey" document including
        candidate recharter work items such as routing, IPv6-based neighbor (contact)
        discovery, security key management, network management, bundle-in
        -bundle encapsulation, reliable bundle delivery, etc.

Sound OK?

Thanks - Fred

From: Ivancic, William D. (GRC-LCA0) [mailto:[e-mail]]
Sent: Tuesday, August 19, 2014 10:58 AM
To: Nabil Benamar; Templin, Fred L
Cc: [e-mail]
Subject: Re: [dtn] Draft charter for review

I think a number of DTN implementations work with IPv6.  I don't think DTN2 does because of the colons and the way it was coded so it was just a question of was it worth it to fix DTN2 for IPv6 or rewrite like IBR-DTN.  So when I saw IPv6 I had no clue as to what that means.

If the issue is neighbor discovery, than I think the charter should say something about discovery.  Saying "IPV6" is very ambiguous.  IPv6 what?

Will

******************************
William D. Ivancic
Phone [phone]
Mobile [phone]
http://roland.grc.nasa.gov/~ivancic


From: Nabil Benamar <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, August 19, 2014 1:10 PM
To: "Templin, Fred L" <[e-mail]<mailto:[e-mail]>>
Cc: William Ivancic <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [dtn] Draft charter for review

Hi Fred,

I would like to say that the IPv6 reference in the draft charter should not be removed. It's important to mention IPv6 because of Neighbor Discovery Protocol and it's behavior when it comes to DTN context. Since this protocol relays on multi multicast messages to operate, it's legitimate to think how it will work with high delays !!


On Thu, Aug 7, 2014 at 5:16 PM, Templin, Fred L <[e-mail]<mailto:[e-mail]>> wrote:
Hi Will,

> -----Original Message-----
> From: Ivancic, William D. (GRC-LCA0) [mailto:[e-mail]<mailto:[e-mail]>]
> Sent: Thursday, August 07, 2014 8:18 AM
> To: Templin, Fred L; [e-mail]<mailto:[e-mail]>
> Subject: 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.
"Delay/Disruption" is a carry-over from the research group, where
long delays due to signal propagation were certainly subject for
study. Physical laws of signal propagation (speed of light, speed
of sound underwater, etc.) have not changed since that time; hence,
"Delay" needs to remain in the title.

> Are we going to standardize LTP here?  It is not stated as a deliverable
> below.  Should it be?
I believe the thinking is that this would come in as a recharter
item. So, maybe we should include it in the recharter document.

> >
> >Chair(s):
> >
> >      TBD
> >
> >Area and Area Director(s):
> >
> >      Transport Area: ADs Spencer Dawkins <spencerdawkins.ietf at
> >gmail.com<http://gmail.com>>,
> >                          Martin Stiemerling <mls.ietf at gmail.com<http://gmail.com>>
> >
> >Responsible Area Director:
> >
> >      Martin Steimerling <mls.ietf at gmail.com<http://gmail.com>>
> >
> >Mailing list:
> >
> >      General Discussion: dtn at ietf.org<http://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.
Perhaps change to:

  "...have been shown to address the issues identified about in substantial
   fielded deployments, e.g. in the space sector [1] and others."

> >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.
I think the paragraph as stated is fair. There is just too much research,
development and testing experience based on these technologies to justify
these claims.

> >      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.
You are welcome to write any document you'd like, but I do not believe
the one you are suggesting belongs in this charter.

> >      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.
The basis for forming the working group is to produce standards-track
documents on solutions that have received significant research and
development in the IRTF and from which we are now transitioning from
feasibility into practicality in the IETF. BP in particular has multiple
interoperable implementations, which is not even required for Proposed
Standard but always an indication of a mature technology.

> >      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.
Maybe a reword could be something line:

  "We will derive this security protocol from a "streamlined" adaptation
   of earlier works (e.g., 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.
>
> I don't understand the IPv6 reference here.
This was a late addition, and could potentially be removed.

> I suspect you may need bundle-in-bundle encapsulation to do a simplified
> bundle security specification.
I don't know whether that is true - can someone who will be working
on the security spec comment?

> >      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.
I don't understand that - can someone who would be working on the
registry comment?

> >    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.
The charter is to develop standards for Delay/Disruption Tolerant Networking
based on the mature technologies developed in the research group. There is
too much research, development and experimentation experience to suggest
that BP was somehow a mistake and should not be standardized.

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

> >  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.
Same comment as above.

> >  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.
I'm not sure I see the problem. The first item is a mid-course
checkpoint to determine the way forward for the standards-track
work, and the second item is a milestone for submitting the work
to the IESG.

Thanks - Fred
[e-mail]<mailto:[e-mail]>

> >  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]<mailto:[e-mail]>
> >https://www.ietf.org/mailman/listinfo/dtn

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



--
Best wishes
نبيل بنعمرو