Return-Path: <scott.c.burleigh@jpl.nasa.gov>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1])
 by ietfa.amsl.com (Postfix) with ESMTP id 57ABE1A0110;
 Sun, 19 Oct 2014 09:53:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.312
X-Spam-Level: 
X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5
 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001,
 T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44])
 by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id HB1w62l6oauw; Sun, 19 Oct 2014 09:53:08 -0700 (PDT)
Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.109])
 (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by ietfa.amsl.com (Postfix) with ESMTPS id 2A62A1A008A;
 Sun, 19 Oct 2014 09:53:08 -0700 (PDT)
Received: from mail.jpl.nasa.gov (ap-ehub-sp01.jpl.nasa.gov [128.149.137.148])
 by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
 ESMTP id s9JGr68k030901
 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO);
 Sun, 19 Oct 2014 09:53:07 -0700
Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.201]) by
 ap-ehub-sp01.RES.AD.JPL ([169.254.3.206]) with mapi id 14.03.0195.001; Sun,
 19 Oct 2014 09:53:06 -0700
From: "Burleigh, Scott C (312B)" <scott.c.burleigh@jpl.nasa.gov>
To: Jari Arkko <jari.arkko@piuha.net>, Lloyd Wood <lloyd.wood@yahoo.co.uk>
Subject: RE: [dtn] proposed DTN workgroup - what is process being followed?
Thread-Topic: [dtn] proposed DTN workgroup - what is process being followed?
Thread-Index: AQHP6t97IZ5hnS3BaUCEPTMP/zvPe5w2XtAAgAEBBwCAACLFUA==
Date: Sun, 19 Oct 2014 16:53:05 +0000
Message-ID: <A5BEAD028815CB40A32A5669CF737C3B5EE70794@ap-embx-sp40.RES.AD.JPL>
References: <1413638841.79127.YahooMailNeo@web28903.mail.ir2.yahoo.com>
 <1413642432.88432.YahooMailNeo@web28901.mail.ir2.yahoo.com>
 <0A52F329-C449-41CC-BB7A-534107F3A03C@piuha.net>
In-Reply-To: <0A52F329-C449-41CC-BB7A-534107F3A03C@piuha.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [128.149.137.114]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Source-Sender: scott.c.burleigh@jpl.nasa.gov
X-AUTH: Authorized
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/DJ-v2FkF0-zd7wlfDGAzM5-pIvw
X-Mailman-Approved-At: Mon, 20 Oct 2014 08:34:57 -0700
Cc: "ietf@ietf.org" <ietf@ietf.org>, "dtn@ietf.org" <dtn@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>,
 <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
 <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Oct 2014 16:53:11 -0000

Engaging with Lloyd on matters relating to DTN has in the past proven to be=
 a bottomless time sink.  In this instance, though, I worry that silence mi=
ght be construed as endorsement of his remarks.  This would be incorrect; t=
hey are without merit.

The DTN BoF was not told to go away and rethink the idea.  The consensus of=
 the BoF was "that the charter should be reviewed again to make it initiall=
y simpler".  As I recall, our responsible area director concurred.  That si=
mplified charter is what was presented to IETF.

The charter simplifications were discussed on the dtn mailing list and in a=
 conference call on 30 September.  In the course of those discussions the B=
oF also considered a radically different charter proposed by Stephen Farrel=
l.  We concluded that the ideas in that charter had appeal but that there w=
as not sufficient support in the BoF to address them in a working group.  T=
aking them up in the DTN Research Group was proposed, without dissent, exce=
pt for speculation that there might not be sufficient energy in the RG eith=
er.

There are no "political" issues.  National space agencies needed the DTN pr=
otocols in their current form documented as CCSDS standards in the near ter=
m so that they could be used for long-range flight mission planning.  The C=
CSDS Bundle Protocol (BP) Blue Book is a profile of RFC 5050; it does not m=
odify the Bundle Protocol.  Additional protocols are indeed defined in that=
 book as well; if IETF determines that those protocols might also be useful=
 in Internet DTN, then they too could be standardized for the Internet, but=
 obviously CCSDS isn't going to "force" IETF to do anything whatsoever.  An=
d the CCSDS standardization process easily accommodates revision; if IETF c=
hooses to standardize the DTN protocols, the future CCSDS BP standard will =
almost certainly be a profile of the IETF BP standard just as the current C=
CSDS BP standard is a profile of RFC 5050.  NASA and other space agencies w=
ill surely have an interest in making sure that revisions to BP as it is st=
andardized for the Internet don't diminish its utility in space flight oper=
ations, but I don't know of any resistance to this consideration within IET=
F.

Consequently there are no "procedural" issues.  Taking Lloyd's example: the=
 CCSDS standardization of SCPS doesn't seem to have in any way degraded the=
 operation of TCP/IP in the Internet.  That's because the deliberations of =
IETF are - and will certainly remain - completely distinct from those of CC=
SDS.

Again, NASA and other space agencies - like any other user community - will=
 have an interest in preserving BP's utility in space flight operations as =
the protocol is revised during standardization.  This interest will be expr=
essed through space agency employees' participation in the IETF DTN WG, jus=
t as the interests of user communities have always been expressed by their =
employees' participation in working groups.  There is nothing new here.

Finally, regarding technical issues: Lloyd characterizes the Bundle Protoco=
l as "problematic", a restatement of the position taken in papers that he a=
nd several colleagues have written over the years.  In the Results section =
of his 2011 paper on "Assessing and improving an approach to delay-tolerant=
 networking" (http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/=
CRS-2011/lloyd-wood-ccsr-crs-2011-dtn.pdf), for example, Lloyd identifies e=
xactly three deficiencies:

(1)	Security is commonly not deployed, in part because of the complexity of=
 the Bundle Security Protocol (BSP).  There seems to be rough consensus in =
the BoF that BSP is indeed too complex; a simplified BSP specification has =
been posted as an Internet Draft and a working prototype has been developed=
.

(2)	No data integrity check, apart from the keyed integrity checks defined =
in BSP, is included in the DTN architecture.  Adding such a check has long =
been identified as a proposed enhancement to BP, with no dissent within the=
 BoF that I'm aware of.

(3)	Rough clock synchronization among machines hosting BP agents is require=
d for some functions, but this is not possible in all circumstances.  Mitig=
ation of this problem has likewise long been recognized as a candidate DTN =
WG work item, with no dissent within the BoF that I'm aware of; an Internet=
 Draft addressing it was posted four years ago.

None of these issues have been significant enough to deter NASA from deploy=
ment of BP in International Space Station operations.  BP is not "problemat=
ic".

The frequently cited "Bundle of Problems" paper (2009) concludes with these=
 words:

"We hope that recounting those problems here will lead to them being addres=
sed in later versions of the DTN architecture and Bundle Protocol specifica=
tions, as research into delay-tolerant networking continues and these resea=
rch ideas are matured. Once these are addressed, the Bundle Protocol may on=
e day be ready for operational use."

While BP already is clearly ready for operational use, I believe the BoF we=
lcomes the opportunity to further realize the hope expressed here by Lloyd =
and his co-authors.

Scott

-----Original Message-----
From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of Jari Arkko
Sent: Saturday, October 18, 2014 10:47 PM
To: Lloyd Wood
Cc: ietf@ietf.org; dtn@ietf.org
Subject: Re: [dtn] proposed DTN workgroup - what is process being followed?

Lloyd,

Good question. It is customary that working groups being proposed to be cre=
ated (like DTN is) are given a slot in the schedule. If the working group c=
reation goes through before the meeting, the slot will be a regular working=
 group meeting. If it does not go through, depending on circumstances we'd =
either run the meeting as a BOF or cancel it.

That was the process part. I'll let others comment on the substance part of=
 your comments.

Jari

