Subject: Re: [dtn] Draft charter for review

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Thu, 7 Aug 2014 15:18:27 +0000

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 7 Aug 2014 16:16:30 +0000

Hi Will,

> -----Original Message-----
> From: Ivancic, William D. (GRC-LCA0) [mailto:[email-masked]]
> Sent: Thursday, August 07, 2014 8:18 AM
> To: Templin, Fred L; [email-masked]
> Subject: Re: [dtn] Draft charter for review
> 
> 
> 
> COMMENTS IN LINE
> 
> 
> 
> >

"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

I believe the thinking is that this would come in as a recharter
item. So, maybe we should include it in the recharter document.

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

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

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.

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

> charter.  IMHO, this point to a solution prior to identifying the problem

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.

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

> I don't understand the IPv6 reference here.

This was a late addition, and could potentially be removed.

> bundle security specification.

I don't know whether that is true - can someone who will be working
on the security spec comment?

> As suggested before, MIME may fit this need.

I don't understand that - can someone who would be working on the
registry comment?

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

> >               a working group work item intended for Proposed Standard.

Same comment as above.

> first items.  Only after this are in firm agreement, should we be

Same comment as above.
 
> 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
[email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 07 Aug 2014 18:00:25 +0100

On 07/08/14 17:16, Templin, Fred L wrote:
> I think bundles were limited t 64K.

Huh? We've sent 400 MB bundles. Or did you just
mean ION?

S.

---

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Thu, 7 Aug 2014 17:06:45 +0000

The ION DINET reference.  If we are going to reference in a charter, than
perhaps two or three to backup the claim.

Will

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Thu, 7 Aug 2014 21:02:21 +0000

I think that comment was Will's, and it is almost true, sort of.  As I recall, we were using AMS as the BP application and AMS messages are limited to 64 KB, but BP and LTP themselves would have been happy with bundles of any size.  Transmission of 1GB bundles is part of every ION benchmark script.

Using AMS as the data source resulted in the transmission of bundles that were not large, but that was in fact desirable for this exercise: the DINET uplink data rates were very low, so sending smallish bundles was the only way to ensure the transmission of multiple bundles, which was necessary in order to exercise a number of BP features. Sending big bundles wouldn't have proven anything in particular; as Stephen notes, big bundles are transmitted routinely.

Scott 
________________________________________
From: dtn [[email-masked]] on behalf of Stephen Farrell [[email-masked]]
Sent: Thursday, August 07, 2014 10:00 AM
To: Templin, Fred L; Ivancic, William D. (GRC-LCA0); [email-masked]
Subject: Re: [dtn] Draft charter for review

S.

---

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Mon, 11 Aug 2014 14:34:18 +0000

I am just saying pick a few more references to show the larger bundle
transfers.

Will

******************************
William D. Ivancic
Phone 216-433-3494
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic

On 8/7/14 5:02 PM, "Burleigh, Scott C (312G)"
<[email-masked]> wrote:

>I think that comment was Will's, and it is almost true, sort of.  As I
>recall, we were using AMS as the BP application and AMS messages are
>limited to 64 KB, but BP and LTP themselves would have been happy with
>bundles of any size.  Transmission of 1GB bundles is part of every ION
>benchmark script.
>
>Using AMS as the data source resulted in the transmission of bundles that
>were not large, but that was in fact desirable for this exercise: the
>DINET uplink data rates were very low, so sending smallish bundles was
>the only way to ensure the transmission of multiple bundles, which was
>necessary in order to exercise a number of BP features. Sending big
>bundles wouldn't have proven anything in particular; as Stephen notes,
>big bundles are transmitted routinely.
>
>Scott

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 15 Aug 2014 00:03:25 +0000

The draft charter thread has seen significant discussion with many excellent
points raised. Based on list feedback, there seems to be consensus to start
with a minimal charter rather than attempt to address too many work items in
the first iteration. As to scoping the work, several have suggested that the
list of candidate work items for RFC5050(bis) be prioritized to determine what
can be accommodated within the schedule. It was also suggested to extend the
schedule to 24months (from its current 18month format).

As an initial charter item, a "DTN Advanced Features Survey" document will
list candidate work items that were not included in the initial charter as
items to address in a re-charter. It is then expected that work will begin
on advanced features with drafts submitted with the name "draft-ietf-dtnwg-*'
to show their relation to the working group.

Does anyone want to offer any additional comments before we make the next
round of modifications to the draft charter?

Thanks - Fred

---

From: <[email-masked]>
Date: Fri, 15 Aug 2014 00:36:49 +0000

Fred,

Is this solely addressing the Bundle Protocol, despite feedback from various people suggesting otherwise?

Thanks

Lloyd Wood
http://sat-net.com/L.Wood/dtn
________________________________________
From: dtn <[email-masked]> on behalf of Templin, Fred L <[email-masked]>
Sent: Friday, 15 August 2014 10:03:25 AM
To: [email-masked]
Subject: Re: [dtn] Draft charter for review

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 15 Aug 2014 15:13:11 +0000

Hi Lloyd,

The bundle protocol and its associated security extensions are in the
initial charter items, yes.

Thanks - Fred

> From: dtn [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Thursday, August 14, 2014 5:37 PM

---

From: <[email-masked]>
Date: Sat, 16 Aug 2014 00:30:04 +0000

Fred,

That doesn't answer my question.

Also, submitting -dtnwg- drafts before a workgroup is created, in the expectation that a wg is formed, would look like an attempt to artificially astroturf a workgroup into existence and to camouflage lack of widespread grassroots support.

I wouldn't be in favour of this.

Lloyd Wood
http://sat-net.com/L.Wood/dtn
________________________________________
From: dtn <[email-masked]> on behalf of Templin, Fred L <[email-masked]>
Sent: Saturday, 16 August 2014 1:13:11 AM
To: Wood L  Dr (Electronic Eng); [email-masked]
Subject: Re: [dtn] Draft charter for review

Hi Lloyd,

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 18 Aug 2014 20:30:11 +0000

See below for the updated draft charter based on feedback we have received
on the list (see also attached diffs from the previous version). Can we
now move forward with this version?

Thanks - Fred

---

Chair(s):

      TBD

      Transport Area: ADs Spencer Dawkins <spencerdawkins.ietf at gmail.com>,
                          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

      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:

      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 

      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.

      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 an extensive summary of the proposed changes
        to be prioritized).

  
    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+16mos - Submit Registry [4] and Simple Convergence Layer [5][6] as
                working group documents.
  start+20mos - 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+20mos - Submit Registry and Simple Convergence Layer to IESG
  start+24mos - Recharter to accommodate new work items or close Working Group

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 19 Aug 2014 16:25:30 +0000

Lloyd,

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, August 15, 2014 5:30 PM
> Subject: RE: [dtn] Draft charter for review
> 
> Fred,
> 

The bundle protocol and it's associated security protocol have been listed
as initial working group items beginning with the first version of the draft
charter. And, several people have since voiced their support of more recent
versions of the charter.

> Also, submitting -dtnwg- drafts before a workgroup is created, in the expectation that a wg is formed,
> would look like an attempt to artificially astroturf a workgroup into existence and to camouflage lack
> of widespread grassroots support.

No one said anything about submitting -dtnwg- drafts before a wg is created,
and to infer that there is some sort of conspiracy planned is incorrect.

Thanks - Fred

---

From: Nabil Benamar <[email-masked]>
Date: Tue, 19 Aug 2014 18:10:55 +0100

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

-- 

*Best wishes*

*نبيل بنعمرو*

---

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Tue, 19 Aug 2014 17:57:44 +0000

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

From: Nabil Benamar <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, August 19, 2014 1:10 PM
To: "Templin, Fred L" <[email-masked]<mailto:[email-masked]>>
Cc: William Ivancic <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Will,

> From: Ivancic, William D. (GRC-LCA0) [mailto:[email-masked]<mailto:[email-masked]>]
> To: Templin, Fred L; [email-masked]<mailto:[email-masked]>

> >gmail.com<http://gmail.com>>,
> >                          Martin Stiemerling <mls.ietf at gmail.com<http://gmail.com>>
> >
> >      Martin Steimerling <mls.ietf at gmail.com<http://gmail.com>>
> >
> >Mailing list:
> >
> >      General Discussion: dtn at ietf.org<http://ietf.org>

Perhaps change to:

Same comment as above.

Same comment as above.

Thanks - Fred
[email-masked]<mailto:[email-masked]>

> >[email-masked]<mailto:[email-masked]>

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

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 19 Aug 2014 18:17:13 +0000

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:[email-masked]]
Sent: Tuesday, August 19, 2014 10:58 AM
To: Nabil Benamar; Templin, Fred L
Cc: [email-masked]
Subject: Re: [dtn] Draft charter for review

Will

Hi Fred,

Perhaps change to:

Same comment as above.

Same comment as above.

Thanks - Fred

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

---

From: Nabil Benamar <[email-masked]>
Date: Tue, 19 Aug 2014 23:02:05 +0100

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" <[email-masked]>
wrote:

> *From:* Ivancic, William D. (GRC-LCA0) [mailto:[email-masked]]
>
> *Sent:* Tuesday, August 19, 2014 10:58 AM
> *To:* Nabil Benamar; Templin, Fred L
> *Cc:* [email-masked]
> *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
>
>
>
> *From: *Nabil Benamar <[email-masked]>
> *Date: *Tuesday, August 19, 2014 1:10 PM
> *To: *"Templin, Fred L" <[email-masked]>
> *Cc: *William Ivancic <[email-masked]>, "[email-masked]" <
> [email-masked]>
> *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 !!
>
>
>
>
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 26 Aug 2014 14:51:21 +0000

Here is the latest draft charter that includes the change that was
discussed for IPv6 Neighbor Discovery (diffs attached).

Fred

---

Chair(s):

      TBD

Mailing list:

      

      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. 

  
    
Goals and Milestones:

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 26 Aug 2014 12:00:18 -0400

On 8/19/2014 2:17 PM, Templin, Fred L wrote:
>         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.
> 

IMHO, most of those aren't particularly "advanced" features;
many are simply required in order to deploy and build systems.
For an Internet standard, there's an expectation of multiple
vendors being able to build systems that work together out of
the box and do something useful.

Some use cases mentioned were for mission critical and safety
critical systems.  Those are not going to be satisfied by the
work described in the charter.

-- 
Wes Eddy
MTI Systems

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 26 Aug 2014 16:55:26 +0000

Hi Wes,

> From: dtn [mailto:[email-masked]] On Behalf Of Wesley Eddy
> Sent: Tuesday, August 26, 2014 9:00 AM
> To: Templin, Fred L; Ivancic, William D. (GRC-LCA0); Nabil Benamar
> Cc: [email-masked]

I can agree that the title of that work item may not match the
exact meaning it was intending to convey. Maybe something like:

  "DTN Next Step Work Items" ?

> the box and do something useful.

Right; the proposed working group would be chartered to work
on standards.

> work described in the charter.

I would rather say it as the use cases are not going to be
satisfied *without* the work described in the charter. We
have to start somewhere, and the draft charter is the
proposed starting point.

Thanks - Fred