Subject: [dtn] Draft charter for review

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 6 Aug 2014 23:48:26 +0000

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

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/

---

From: Sebastian Schildt <[email-masked]>
Date: Thu, 7 Aug 2014 13:26:57 +0200

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

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

---

From: Joerg Ott <[email-masked]>
Date: Thu, 07 Aug 2014 14:39:51 +0300

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

---

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

Apologies for the top post.

1. If this style of minimal change (*) charter is where we go,
then I really think a refinement of the over-long list that
Scott presented at the BoF has to happen before a wg is
formed. That'd change this charter text quite a bit I think
since e.g. there'd be no need for a problem statement RFC
then.

2. Separate to the above, I'm going to try one more time
to argue for a less minimal change. I think that I'm in
the rough on that, but after the BoF a bit less so than
I expected. And if, as I expect, I remain in the rough
there, then I'll shut up about it and be weakly supportive
of the minimal style charter Fred's proposing. I won't
get to proposing that for a week or so though.

Cheers,
S.

(*) "minimal" is not a pejorative term here, but as
previously discussed on the list is meant to denote the
amount of intended change from rfc5050.

---

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

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 [[email-masked]] on behalf of Joerg Ott [[email-masked]]
Sent: Thursday, August 07, 2014 4:39 AM
To: Sebastian Schildt; Templin, Fred L
Cc: [email-masked]
Subject: Re: [dtn] Draft charter for review

Hi,

Jörg

---

From: Wesley Eddy <[email-masked]>
Date: Fri, 08 Aug 2014 01:07:18 -0400

> Please send comments to the list so that we may have an open

Hi Fred, I have (at least) one confusion with this.

It starts by saying some actual use cases will be defined, but
then seems to assume that none of those use cases need anything
beyond the basic bundle format and some simple convergence layer.

Most of what people talked about (subs, UAVs, s/c) all will need
any standards that are created for them to cover:
- means for naming and configuring entities
- forwarding algorithms
- routing protocols
- KMP appropriate for the use case (or are you assuming that
  SBSP with preshared keys and some out-of-band means of
  rolling them is sufficient for all the use cases?)
- convergence layers actually suitable for their environment
- probably more ...

Are these things in scope or going to be tackled?  Do they need
separate working groups e.g. to do routing and KMP stuff?

Or is there an assumption that the people implementing and deploying
in each case understand that they need to create all these things on
their own, outside the standard?  That may be okay, if they say it's
all understood, but it seems to diminish the value of the standard
since the shared code or interoperability will be limited to a subset
of features that nobody actually can use.

Thanks for any clarification you have on this, or how you envision the
mostly "naked" standard being used in practice.

-- 
Wes Eddy
MTI Systems

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Fri, 8 Aug 2014 06:53:44 +0000

You raise a very good point, Wes.  My thought on this, FWIW, is that we should annotate each of the defined use cases with the mechanisms with which we propose to address them.  Some of those mechanisms might things that are not in the initial scope of work the WG (i.e., won't initially be Internet standards) but are defined in existing experimental RFCs.  I think that's okay so long as we're identifying an achievable way forward, but of course it would be up to our participating user organizations to say what would work for them and what would not.

There's a Catch-22 here that we must be careful not get caught up in.  If we expand the scope of the initial charter broadly enough to establish Internet standards for all the capabilities that might be needed for every relevant use case, the charter becomes too large to be approved for formation of the working group and nothing gets standardized at all.

Scott
________________________________________
From: dtn [[email-masked]] on behalf of Wesley Eddy [[email-masked]]
Sent: Thursday, August 07, 2014 10:07 PM
To: Templin, Fred L
Cc: [email-masked]
Subject: Re: [dtn] Draft charter for review

--
Wes Eddy
MTI Systems

---

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

Hi Wesley,

I think I would have to agree with what Scott said, and to give one
example of how this might go in the IETF the core DHCP protocols were
developed in the dhc working group in the very beginning, but vast
amounts of related technologies and mechanisms were brought in later
and through several recharters. In the beginning, the core DHCP specs
only allowed for assignment of addresses to individual hosts. Now,
we have Prefix Delegation, server load balancing, dynamic updates
to the DNS, etc.

I think if you look at many of these long-running IETF working groups,
you will find that they started with the core protocols and then
brought in additional work items through re-chartering - basically
the same model we are proposing here.

Thanks - Fred

> -----Original Message-----
> From: dtn [mailto:[email-masked]] On Behalf Of Burleigh, Scott C (312G)
> Sent: Thursday, August 07, 2014 11:54 PM
> To: Wesley Eddy; Templin, Fred L
> Cc: [email-masked]
> You raise a very good point, Wes.  My thought on this, FWIW, is that we should annotate each of the
> defined use cases with the mechanisms with which we propose to address them.  Some of those mechanisms
> might things that are not in the initial scope of work the WG (i.e., won't initially be Internet
> standards) but are defined in existing experimental RFCs.  I think that's okay so long as we're
> identifying an achievable way forward, but of course it would be up to our participating user
> organizations to say what would work for them and what would not.
> 
> There's a Catch-22 here that we must be careful not get caught up in.  If we expand the scope of the
> initial charter broadly enough to establish Internet standards for all the capabilities that might be
> needed for every relevant use case, the charter becomes too large to be approved for formation of the
> working group and nothing gets standardized at all.
> 
> Scott

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 8 Aug 2014 17:12:59 +0000

As if on cue, the dhc working group has just minutes ago announced
another recharter to bring in new work items:

https://mailarchive.ietf.org/arch/msg/ietf-announce/iZWA9otA3_WUxKlVn82BP2V3VkA

Dhc has been doing this for years - decades, really. And they are
just one example. That is just the way IETF working groups work.

Thanks - Fred

> From: dtn [mailto:[email-masked]] On Behalf Of Templin, Fred L
> Sent: Friday, August 08, 2014 8:28 AM
> To: Burleigh, Scott C (312G); Wesley Eddy
> Cc: [email-masked]

---

From: William Immerman <[email-masked]>
Date: Fri, 8 Aug 2014 15:46:17 -0400

Fred, Scott, Wesley--

Sounds like a punchline to an old joke, but you've all raised good points and it's tickling a frustration I've experienced listening to a lot of this process and trying to work with potential operational users of DTN, so maybe I'm venting:

Wesley correctly identifies a number of real technical issues that might be necessary for a full blown DTN to reach its potential in a standards compliant way.

Fred correctly identified the evolutionary nature of existing, practical working protocols.

He understated that point by quite a bit. I've just enumerated the windows and processes open in my laptop currently, and the work I've been doing in the last 30 minutes, and at least the following networking technologies and protocols were employed:
      Several MAC layers incl Ethernet, Wifi; ARP; DHCP; Private Networking (RFC 1918/6761/6890/mDNS/Bonjour); DNS; NTP; IP; TCP; UDP; BGP; OSPF; SSH; SSL; HTML; HTTP; SMTP; IMAP
This underestimates I'm sure, and each of these has evolved over time. It also doesn't consider the evolving multiple versions and implementations of each. Doesn't consider the administrative/less technical work needed to make it work as it now does (e.g., ICANN operation).

I think a lot of the technologies Wesley mentioned are equivalent to the range above (discovery, routing, name assignment, convergence layer). 

None of the above in the Internet world evolved at once, or were linked at the level of IETF working or research group, although clearly our Internet experience wouldn't be the same or possibly even exist if most of them had not evolved to meet the need they satisfy.

I can empathize with Wes's point, since many of these issues arise in one form or another trying to explain the value of doing this to potential users. The ones inclined to listen, and more knowledgeable, are full of questions that can't all be answered and make them question whether there's value in doing something. More users are less knowledgeable, and think it sounds like a good idea, and then expect to roll out working implementations as quickly as they can now order up an Internet connection.

If we weren't shooting ourselves in the foot with regard to getting to working operational applications, I would say that we could wait until many of the issues are researched before moving to standardize and operationalize any of it, but I don't believe that's the case. Despite many technical differences and technology gaps among participants, here are some things I think we would have substantial agreement on that make me think it's worth going ahead:

a) Almost all in the DTN research community understand that the conditions requiring disruption tolerance exist and are obstacles to traditional networking. Many potential users don't appreciate this.
b) Almost all in the DTN research community believe that there is some underlying commonality in these environments that can be exploited to achieve a partial common solution to create wide area networking that incorporates intermittently or poorly connected nodes. If not, they wouldn't be spending time on this.
c) The operational problems don't go away while being researched, and the nature of networking is that when needed, all or most of the underlying problems can be solved technically with single purpose stovepipes, at least for a single well-defined application. What can't be solved is the 80% case where each instance is solved with a common technology and a limited, shared set of protocols and good implementations. In today's funding environment, that means that many of the potential uses won't be solved at all, or solved well, or solved in a way that contributes to later or additional uses or interconnections
d) The window to get an 80% solution is closing if we do nothing. There's been a history in computer science where great early results led to later tries that had much lower return on investment than promised. No programming language after FORTRAN gave the order of magnitude improvement it gave over assembly language programming, even though inarguably later languages are huge improvements over FORTRAN.  So the applicability for DTN is much smaller than for IP, given the huge advance having IP provided. Once that more limited application need is satisfied, even if poorly, there won't be interest and resources to do something better. I keep hearing that potential users have no problem we can solve, because they have already invested in their cobbled together, limited, specialized solution. They don't have the time or money to think about their next application.

So the real question for this group should, I think, be: "is there enough agreement on specifics in (b) in the existing research to come up with a good enough working solution to enough of the needs in (a) that (c) will be satisfied at the 80% level to avoid (d)."

My observation in discussing with potential users: the biggest issue is not that they perceive the lack of each of these pieces of the puzzle. The biggest problem seems to be that many, even though technically very astute, don't really understand networking. Not DTN, networking as a whole. If you think about trying to explain what IP does (not what it enables, but what it means to have IP not just Ethernet, TCP, and HTTP ...) you see the problem explaining BP, for instance. It's pretty abstract, yet we know that while IP could have been designed in other ways, and while there were other networking ideas and architectures competing, the ability to have a wide spread network that justifies application protocols like HTTP and takes advantages of evolution in link protocols like Ethernet without requiring re-doing everything would not likely have occurred, or would have been very different, without this layer and protocol that most end users employ and benefit from but don't get, at all. 

When the realization hit that this was the case I had opportunity to ask Vint Cerf what he answered when explaining what IP would do for users when he was justifying that work, and he answered that they were never questioned that way. It's lucky for us I guess that was the case, but it's not the situation now. If I can't have a working, stable technology base for DTN and decent implementations to show useful, if limited application, users won't care at all. Part of my pitch has been that this is close to existing, and I hope I'm not lying. Hence interest in this group.

Thanks for letting me vent, if you've read this far,
Bill Immerman

---

From: "Clark, Gilbert" <[email-masked]>
Date: Fri, 8 Aug 2014 19:50:38 +0000

Hi Fred:

The idea that we won't be able to get to everything the first time around is common sense, I think.  What concerns me, however, is my perception that the response below is arguing that it's somehow okay to arbitrarily decide to push a work item to a future (re)charter for no better reason than "that is just the way IETF groups work".  I feel like such a statement discounts the often significant (and necessary) effort involved with establishing the limitations of a particular version of a protocol that make the *most* sense for the (hopefully well-defined) target audience and / or platform(s).

TL/DR: deciding what goes into a first charter and what may be reserved for a future charter is not a decision that should be made lightly, I think.

I'd imagine that I've simply read more into your e-mail than what was intended, but still thought I'd throw that out there :)

FWIW,
Gilbert Clark
________________________________________
From: dtn <[email-masked]> on behalf of Templin, Fred L <[email-masked]>
Sent: Friday, August 08, 2014 1:12 PM
To: Burleigh, Scott C (312G); Wesley Eddy
Cc: [email-masked]
Subject: Re: [dtn] Draft charter for review

Thanks - Fred

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 08 Aug 2014 21:58:41 +0100

Hi Fred,

DHCP is a highly successful protocol and that success
merits the maintenance of a long lived IETF WG. Even
so, there are folks who quite reasonably consider such
WGs a bad idea.

The BP is just nowhere near as successful, even though
its a fine thing that does solve a problem, so I figure
that your comparison isn't really apt.

But mostly, I have to say that for me the idea that a DTN
WG would start off planning to live for a decade before
approaching completion is very unappealing. I can feel my
weak enthusiasm for your proposed charter draining even
further as I think about it to be honest.

I think a "minimal" charter has to deliver some useful,
very specific and not hugely distant improvements to RFC5050.
If not, I'd question the planning being done here.

S.

PS: I still prefer a "non-minimal" charter but that's
another topic.

---

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Fri, 8 Aug 2014 21:16:06 +0000

I'M not crazy about the way this is headed so far as it seems to be no
room for thinking about how to improve the protocol to make it easier to
deploy.  It appears to be a force of what already is into a standard.

The reason for suggesting a requirements document and lessons learned is
to provide some guidance for improvements.

Do you need scaling?

Is the dictionary being used?

Is anyone using time in their routing?

So far, it appears most set a fixed bundle lifetime: be it hours, days,
weeks or some even set effectively infinity. So perhaps bundle lifetime is
not really needed.

Does one need to secure the payload or just authenticate the header?
After all, in email, the encryption is handled by the user, not the
network.

Are people (besides the space group) using the report to pieces of the
protocol or should this be separated out?  It seems like network
management related to me.

Reactive fragmentation has shown to be useful.

Should reactive fragmentation and security have to work together (a
requirement).

Do we really want SDNVs everywhere?  It adds complexity when trying to
operate at high speeds in space-based systems (prefer a FPGA
implementation as really high speed rad hard processors are hard to come
by.

Thinking about a lot of these things and lessons learned could greatly
simplify the protocol.

Will

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 8 Aug 2014 22:58:47 +0000

Hi Stephen,

OK, I think I get that we should not be planning to track along the
same decades-long path that dhc took to get to where it is today;
that would not satisfy near-term business needs. There will be lots
of things we will need to get to in the not too distant future, but
not all can be accommodated in an initial charter.

That said, we need to start with the core specs and Scott gave a
pretty thorough examination of the proposed changes in rfc5050(bis)
during the BoF. We need to start somewhere, and that is what the
draft charter is about.

Thanks - Fred

> From: dtn [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Friday, August 08, 2014 1:59 PM
> To: Templin, Fred L; Burleigh, Scott C (312G); Wesley Eddy
> Cc: [email-masked]

---

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

Hi Will

I think you are posing some useful questions, and I think many were
addressed by Scott's BoF presentation. They would be useful to
consider further in rfc5050(bis) list discussions. IETF working
group efforts are IMHO most successful when community input is
brought into consideration.

Thanks - Fred

> From: Ivancic, William D. (GRC-LCA0) [mailto:[email-masked]]
> Sent: Friday, August 08, 2014 2:16 PM
> To: Stephen Farrell; Templin, Fred L; Burleigh, Scott C (JPL-312G)[Jet Propulsion Laboratory]; Wesley
> Eddy
> Cc: [email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 09 Aug 2014 00:21:17 +0100

> during the BoF. We need to start somewhere, and that is what the

Sure. But Scott's list was tooooo looooong wasn't it?

S.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 8 Aug 2014 23:25:21 +0000

Hi Stephen,

> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Friday, August 08, 2014 4:21 PM

I'll try to stop making comparisons to other IETF activities,
but isn't it to be expected that such a list would be refined
based on wg input as the document progresses?

Thanks - Fred

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 09 Aug 2014 00:39:50 +0100

> based on wg input as the document progresses?

That depends on a bunch of stuff. In my case, as an AD, I
much prefer to start WGs with a small useful concrete list
of stuff to do. And when that's turned out well, then and
only then consider re-chartering to do more. Other ADs may
well operate differently but my approach would call for a
severe pruning of Scott's list down to something coherent
and useful and achievable before a WG were formed. You
ought chat with Martin about that though, its his call in
this case. (And I've not chatted with him about that.)

Cheers,
S.

---

From: <[email-masked]>
Date: Sat, 9 Aug 2014 09:17:35 +0000

Stephen,

what are your opinions on setting lists of stuff for RGs to do?

thanks

Lloyd Wood
http://sat-net.com/L.Wood/dtn
________________________________________
From: dtn <[email-masked]> on behalf of Stephen Farrell <[email-masked]>
Sent: Saturday, 9 August 2014 9:39:50 AM
To: Templin, Fred L; Burleigh, Scott C (312G); Wesley Eddy
Cc: [email-masked]
Subject: Re: [dtn] Draft charter for review

Cheers,
S.

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Sat, 9 Aug 2014 09:22:16 +0000

Stephen, in an earlier post you said 'a "minimal" charter has to deliver some useful, very specific and not hugely distant improvements to RFC5050'.  I agree with that, and I think it also ought to deliver whatever additional standardization is needed in order to enable our user community to move forward with pending and proposed DTN initiatives that want IETF standardization in place.  That's all we're trying to achieve with this charter.  We all know that there's plenty that could be done beyond this limited scope, and we certainly want to assure everyone that those additional items are not forgotten; the charter includes a work item for identifying those items, and that's about as much attention as we can afford to devote to them right now.

As to the RFC5050 improvements: in my "BPv7" draft I was trying to address specifically and in detail all the things that have emerged as issues over the past decade, and I guess that made the list of changes seem really loooooong.  But I don't think it was incoherent.  I don't think it was useless.  And I think it was completely achievable: all of the changes proposed in that draft are useful, none are hugely distant, almost all of them have already been prototyped, and almost all of them are already documented in past Internet Drafts or, in some cases, experimental RFCs.

That said, I'm well aware that some of those proposed changes are controversial.  But isn't the resolution of those low-level technical questions exactly the work that is the business of a WG rather than of a BoF?  I'm worried that we're looking at Zeno's working group here.

Scott
________________________________________
From: Stephen Farrell [[email-masked]]
Sent: Friday, August 08, 2014 4:39 PM
To: Templin, Fred L; Burleigh, Scott C (312G); Wesley Eddy
Cc: [email-masked]
Subject: Re: [dtn] Draft charter for review

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 09 Aug 2014 12:23:34 +0100

> what are your opinions on setting lists of stuff for RGs to do?

different:-)

S

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 09 Aug 2014 12:25:42 +0100

On 09/08/14 10:22, Burleigh, Scott C (312G) wrote:
> Stephen, in an earlier post you said 'a "minimal" charter has to
> deliver some useful, very specific and not hugely distant
> improvements to RFC5050'.  I agree with that, and I think it also
> ought to deliver whatever additional standardization is needed in
> order to enable our user community to move forward with pending and
> proposed DTN initiatives that want IETF standardization in place.
> That's all we're trying to achieve with this charter.  We all know
> that there's plenty that could be done beyond this limited scope, and
> we certainly want to assure everyone that those additional items are
> not forgotten; the charter includes a work item for identifying those
> items, and that's about as much attention as we can afford to devote
> to them right now.
> 
> As to the RFC5050 improvements: in my "BPv7" draft I was trying to
> address specifically and in detail all the things that have emerged
> as issues over the past decade, and I guess that made the list of
> changes seem really loooooong.  But I don't think it was incoherent.
> I don't think it was useless.  And I think it was completely
> achievable: all of the changes proposed in that draft are useful,
> none are hugely distant, almost all of them have already been
> prototyped, and almost all of them are already documented in past
> Internet Drafts or, in some cases, experimental RFCs.
> 
> That said, I'm well aware that some of those proposed changes are
> controversial.  But isn't the resolution of those low-level technical
> questions exactly the work that is the business of a WG rather than
> of a BoF?  I'm worried that we're looking at Zeno's working group
> here.

Well yes, but the list you presented at the BoF was
really too long though right, so some pruning is
needed, but sure, that ought be doable without Zeno.

S.

> Scott ________________________________________ From: Stephen Farrell
> [[email-masked]] Sent: Friday, August 08, 2014 4:39 PM To:
> Templin, Fred L; Burleigh, Scott C (312G); Wesley Eddy Cc:
> [email-masked] Subject: Re: [dtn] Draft charter for review
> 
>> I'll try to stop making comparisons to other IETF activities, but
>> isn't it to be expected that such a list would be refined based on
>> wg input as the document progresses?
> 
> That depends on a bunch of stuff. In my case, as an AD, I much prefer
> to start WGs with a small useful concrete list of stuff to do. And
> when that's turned out well, then and only then consider
> re-chartering to do more. Other ADs may well operate differently but
> my approach would call for a severe pruning of Scott's list down to
> something coherent and useful and achievable before a WG were formed.
> You ought chat with Martin about that though, its his call in this
> case. (And I've not chatted with him about that.)
> 
> Cheers, S.
>

---

From: Avri Doria <[email-masked]>
Date: Sat, 09 Aug 2014 07:54:39 -0400

Hi,

I tend to think of WG charters as needing to be restricted to things
that seem like they can be completed in a few years.

I think the middle space between the restricted so-called miniaml and
the wide open charter is one that includes one task that works on the
requirements beyond the minimal.  Once this is done, and the other work
items are well along in being done, then one can go back to the IESG to
get approved for further milestones.  This charter has that work item.
I am not sure it needs the detailed list of items to be covered in the
gathering of requirements.

I am also not sure that there is much one can or should remove from this
charter to make it even more minimalist.  The items on on seem to be the
ones that need to be completed to give DTN an engineered base to grow
on.  When I look at the list I don't see what could be removed and still
have the group complete a solid engineered protocol base for DTN.

Historically, I have noticed, a group that is successfully competing
work seems more likely to get to do more work.

The current charter seems to largely be of this character.  There is a
lot of work that optimistically gets done in 18 months. And other
requirements etc are collected over that time for further thought and
review.  My main issue with the charter is the optimism that all of this
get done in 18 months.  I would recommend stretching it out to 24 months
perhaps by using 4-5 month intervals for the milestone dates instead of
3 month intervals.

I also think it is good that the DTNRG keeps going as it can continue to
work on the stuff that is not yet ready for prime time and can feed work
into the WG when it is ready to move beyond research to engineering.
For example I still plan to work on the dtn routing issues, but it is
not in any way ready for prime time yet. And the charter covers that.

Except for the timeline optimism, I think it is a fine charter.

avri

ps. For a long time I have though it should be d2tn or ddtn. but that is
one of side comments i can unusually refrain from making.

---

From: Brian Haberman <[email-masked]>
Date: Sat, 09 Aug 2014 08:18:25 -0400

As another AD with interest in this space...

> this case. (And I've not chatted with him about that.)

I also think of WG charters in the terms that Stephen describes.  The
list of tasks that Scott proposed should be prioritized and then
assessed for "longness".  I also like Avri's suggestion of having a
charter work item that essentially describes what should be considered
(use cases + requirements?) as the "next step".

Regards,
Brian

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Sat, 9 Aug 2014 14:45:39 +0000

One clarification I'd like to offer:

At the BoF I presented a list of tasks that the WG might undertake; one of those tasks was revision of the Bundle Protocol specification, and I listed a number of specific revisions.  What we have done so far to revise the charter is to strike items off the list of tasks.  We could also consider striking items off the list of BP revisions.  I'm opposed to that for two reasons:

1. Scoping and prioritizing the individual BP revisions, unlike selecting high-level tasks, will entail the sort of detailed technical discussion that I think should be done in the working group rather than in a BoF.

2. Because all of these changes pertain to a single document (the BP spec), we will be wasting a good deal of time for everyone if we settle on a batch of them, then publish a BP RFC that will shortly be superseded, then settle on another batch, then publish another BP RFC that will shortly be superseded, etc. I think a better use of everyone's time would be to hash the revised specification out just one time.

So I agree completely with prioritizing the charter tasks and assessing them for longness, but I think there are good reasons for not treating individual BP revisions as separate tasks.  BP revision, taken as a single task, would be a large task.  But as documented in the Bpv7 I-D I posted, it is certainly not too large to address in the initial charter of this WG.  The changes simply are not that profound.

Scott
________________________________________
From: dtn [[email-masked]] on behalf of Brian Haberman [[email-masked]]
Sent: Saturday, August 09, 2014 5:18 AM
To: [email-masked]
Subject: Re: [dtn] Draft charter for review

Regards,
Brian