IETF Logo Mail Archive

Re: [dtn] custody transfer I-D

William Ivancic <ivancic@syzygyengineering.com> Fri, 23 June 2017 03:34 UTC

Return-Path: <ivancic@syzygyengineering.com>
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 061E11293FD for <dtn@ietfa.amsl.com>; Thu, 22 Jun 2017 20:34:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.397
X-Spam-Level:
X-Spam-Status: No, score=-5.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yahoo.com
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 C1s8JQfrEBK4 for <dtn@ietfa.amsl.com>; Thu, 22 Jun 2017 20:34:13 -0700 (PDT)
Received: from smtp104.biz.mail.bf1.yahoo.com (smtp104.biz.mail.bf1.yahoo.com [98.139.221.63]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EABC51241FC for <dtn@ietf.org>; Thu, 22 Jun 2017 20:34:12 -0700 (PDT)
Received: (qmail 79858 invoked from network); 23 Jun 2017 03:34:11 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1498188851; bh=D70vU3ffbZfYl35M7FTW4km0v9WHsD3TXeow793xjaE=; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; b=pJrM6MHqdKUOIHlUxW/6LkhnPfUwQ0nmfG0w5W8P0vL42kZSNcwhYVQ8kmATPw1YrI7/A6GzAnvb0FLu9qnUmM8FlcnRUC86Fiq2+0ISlXx//lZ21Wvf6OuTdwgb/7GwI7h7fXTllpaylpmF+VNFrutf90G+fIRqzRMkqLVElJE=
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: t1Thv_0VM1mJaGSxb.uwlSDkwyGWw14GauvK.TzAkmNcOi6 90Y0iSZewKt6Mtg6dS3LCvcM2waTmWoPVDq4fkCG0D2S60NcWZD4ZUmwfEqI 4h_7Bmf0cgAGCgeqwNiYYxDVqzeaeMdjARysAAaEzfAOXR3cM3Ns1KTMTDPt LJpjEXQSyknGyhNiRI.uA.5yd14LiWcK03KHHMlVSK98ZbxDx9tAaZMDlbhn UckxaGtoEaiQBs8P4iBNQtR5fjwR9er10JcJA260xBiWbk.nfAlfcw6FuHa8 Hffa4yFggQm8bxJ5l2Ne6HXDqnX7ZPG1gw5QwUTwvO4BX2xo3rmmLJ6wgVuX 8T.1gQcMh6RGnteapgWIpnUF84jmZIpnqTJPwGKfK57iKZrPoZExS1YtOSWf GGXW.0V1kCSpe6Gh3D.E7gT9JUFddyVRK9JIKl_kZR64aWWtpTsH8Z25ggVZ uZKJ8q3_zzW4XORWSarWfJyYHigQp2670ixMzpc_11E4M3USMvMxwFTDAhdG i6BSIxOuNBosi8ki0gMR7JwGdf8AkiDSLeYG3Yi9_mIL3VpBIPWAhRSM5iQY gH4n.kbg-
X-Yahoo-SMTP: 8oAoZxqswBCLMwr8oLfpmeSVcF8-
User-Agent: Microsoft-MacOutlook/f.20.0.170309
Date: Thu, 22 Jun 2017 23:34:07 -0400
From: William Ivancic <ivancic@syzygyengineering.com>
To: "Burleigh, Scott C (312B)" <scott.c.burleigh@jpl.nasa.gov>, "dtn@ietf.org" <dtn@ietf.org>
Message-ID: <1C39C4D9-1FDB-4AAF-B996-744BEA2CB42C@syzygyengineering.com>
Thread-Topic: [dtn] custody transfer I-D
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3581019251_1721794961"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/f4XgE2Ax_rKTlzKgO0hL0nqfJ1o>
Subject: Re: [dtn] custody transfer I-D
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Jun 2017 03:34:15 -0000

 

 

From: dtn <dtn-bounces@ietf.org> on behalf of "Burleigh, Scott C (312B)" <scott.c.burleigh@jpl.nasa.gov>
Date: Thursday, June 22, 2017 at 8:04 PM
To: "dtn@ietf.org" <dtn@ietf.org>
Subject: [dtn] custody transfer I-D

 

(custody refusal actually indicates  #1: successful data arrival,  #2: just at an incapable forwarding point)

 

I don’t believe either 1 or 2 are necessarily correct.   

 

Regarding #2:  A node may not want the responsibility of a custodian but still store and forward the bundle.  In that case, the node is certainly capable of forwarding and has even done so.

 

Regarding #1:  Why wouldn’t a node refuse custody as soon as possible?  For Example, Why wait to receive and entire 20 Mbyte bundle over a low rate wireless link before telling the sender, “Don’t bother. You have no service level agreement with me.”  

 

Unfortunately, the operational concepts where not thought through and documented prior to designing this protocol.  

 

---------------

Will

v2.23.0 | Report a Bug | By Email