Re: [dtn] Draft charter for review

[Nabil Benamar <[e-mail]>]

Sounds ok for me Fred...and I am with the idea of the survey! Are there
some volunteers for writing this one ?

sent from my smartphone
On Aug 19, 2014 7:17 PM, "Templin, Fred L" <[e-mail]>
wrote:

>  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]>
> *Date: *Tuesday, August 19, 2014 1:10 PM
> *To: *"Templin, Fred L" <[e-mail]>
> *Cc: *William Ivancic <[e-mail]>, "[e-mail]" <
> [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]>
> wrote:
>
> Hi Will,
>
>
> > -----Original Message-----
> > From: Ivancic, William D. (GRC-LCA0) [mailto:[e-mail]]
> > Sent: Thursday, August 07, 2014 8:18 AM
> > To: Templin, Fred L; [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>,
> > >                          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.
>
> 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]
>
>
> > >  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
>
>
>
>
>
> --
>
> *Best wishes*
>
>  *نبيل بنعمرو*
>
>
>
>
>