Re: [dtn] [EXTERNAL] Alexey Melnikov's Discuss on draft-ietf-dtn-bpbis-22: (with DISCUSS and COMMENT)

"Alexey Melnikov" <aamelnikov@fastmail.fm> Mon, 10 February 2020 11:40 UTC

Return-Path: <aamelnikov@fastmail.fm>
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 0340A120145; Mon, 10 Feb 2020 03:40:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=Qhpej1no; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=pkejCKCE
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 lCqcWdMgYG8O; Mon, 10 Feb 2020 03:40:02 -0800 (PST)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A10CF1200A4; Mon, 10 Feb 2020 03:40:02 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 073DB5E9; Mon, 10 Feb 2020 06:40:00 -0500 (EST)
Received: from imap21 ([10.202.2.71]) by compute7.internal (MEProxy); Mon, 10 Feb 2020 06:40:01 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type:content-transfer-encoding; s=fm2; bh=4Kb23 SBhoDDhQz/tnoYVPYltL9Gm+d35KnrWVS0b3Qo=; b=Qhpej1noQdK0sAuSZ7xao cO6AbWQCQ1qTYG8ZZTD/uGxdvnDBxBViyJ9VZrraZETLSKS0kEj0WnUXjsoyFMnX +evlsnfXLHtxH9aWp40VSq6sAFaKJrIAWpwJLVMlyrvPBl8CKl7lo2ZyG7p140Qc HdVtidhGvuBiySzzi8s0gv19yn5LR9QDh05uXk+06HARvmau5gIJTCeQAnRxuNlJ iABlZw7egxE+SrvoOOITE5yMxs/I7+OiBMQaqC/R80SxoZFwvMzzxdbBawDlCjCU GHMg1rSzLXUYhImUVOCipBHc5Hy/sMKHMBYu4wx23GNRfCelxtR8kZSyyhabAl+G g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=4Kb23SBhoDDhQz/tnoYVPYltL9Gm+d35KnrWVS0b3 Qo=; b=pkejCKCEP8xjuQc5BKPtMabmC5PL7K0Jb40IuC/PgyVXbyBmEx/8YGY7d aXoy612pVn+M5VfqsQSmwUbxbJDxWXY37QD7cjY2NoMKWujYWRTO74k6uguINk2r W97RqqKIiQ+n9LhUHubIsE+EhzTTRGd8gQDnfmAt/w/VsNOTdlbYKPgTOqqSZ9mw f4AXRwKRYbU8/jauBZsKr3tBxJtwxYrY+ODSMHdgCkASSFsjcmCuBKi8jsflyB1c 2fbz1bfTIxixxVWjojy3FIKYBMJ9Y7nhGmFptxI2Q5arVstldXR+4em0WluWLXX6 f3RLznI/KnPBMfdxR+OGgKYe/Vqgg==
X-ME-Sender: <xms:EEFBXpR0fkyTF-PRRlBTu1rz2bCFdqWRS5VE2_IXgstTOKmA6S-DQA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedriedugdeftdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep rggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhm
X-ME-Proxy: <xmx:EEFBXlCf0v07ow_VjgvCxeJFBli5_HtoxGbrHofWn9i5RHTxdhffDQ> <xmx:EEFBXhGR03Yas1W6iMvfLGyRmZuO206IYylQsGV6WxVx_uhCpbl1eA> <xmx:EEFBXnB4xbTdvQ4S8A191VTdgzHeeLu5Lfg08KOHfM3nY8qQxODQrg> <xmx:EEFBXgzViHHU5TKfGlsYo-5u6Se0EcTEjPmkekaPkmYJorSe7WpGMw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 09F4B660065; Mon, 10 Feb 2020 06:40:00 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-802-g7a41c81-fmstable-20200203v1
Mime-Version: 1.0
Message-Id: <cf2df2e0-7c28-40f5-8b7e-62877fb54668@www.fastmail.com>
In-Reply-To: <00dfa2dda9b344ebbd87705b34e74a79@jpl.nasa.gov>
References: <158108452583.11606.5428367878223035583.idtracker@ietfa.amsl.com> <b77a3734d0ae427c920962e438c16a60@jpl.nasa.gov> <32b82572-64ad-4b22-b4bc-9c2dd779172d@www.fastmail.com> <00dfa2dda9b344ebbd87705b34e74a79@jpl.nasa.gov>
Date: Mon, 10 Feb 2020 11:39:04 +0000
From: Alexey Melnikov <aamelnikov@fastmail.fm>
To: "Burleigh, Scott C (US 312B)" <scott.c.burleigh@jpl.nasa.gov>, The IESG <iesg@ietf.org>
Cc: "draft-ietf-dtn-bpbis@ietf.org" <draft-ietf-dtn-bpbis@ietf.org>, Fred Templin <fred.l.templin@boeing.com>, "dtn-chairs@ietf.org" <dtn-chairs@ietf.org>, "dtn@ietf.org" <dtn@ietf.org>, Benjamin Schwartz <bemasc@google.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/KU9EayyNAIRsdsozDuk81I4IE6k>
Subject: Re: [dtn] [EXTERNAL] Alexey Melnikov's Discuss on draft-ietf-dtn-bpbis-22: (with DISCUSS and COMMENT)
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 10 Feb 2020 11:40:04 -0000

Hi Scott,
Quickly replying to a single issue:

On Sat, Feb 8, 2020, at 12:45 AM, Burleigh, Scott C (US 312B) wrote:
> > ## Section 5.8
> > 
> > Clarity: The insistence, here and earlier, that a bundle is only 
> > fragmented into two packets, and that this can then be performed 
> > recursively, seems unhelpful.  Bundles can be fragmented into 
> > arbitrarily many pieces, and this binary subdivision concept is not 
> > actually present in the protocol.  I suggest removing it from the text 
> > as well.
> > 
> > 		Why is this unhelpful?  It's the formal procedure by which bundles 
> > are fragmented.  Let's not remove it.
> 
> I think saying that a bundle can only be fragmented into 2 pieces is a 
> lie, because the algorithm says that it can be fragmented into more 
> than 2. I found this text to be confusing as well. Just say that it can 
> be fragmented into 2 or more non overlapping fragments.
> 
> 	***	It is absolutely not a lie.  A bundle can be fragmented into 
> exactly 2 pieces, each of which is a bundle.  There is no defined 
> mechanism for fragmenting a single 		bundle into 3 pieces, or 4, other 
> than the recursive exercise of the binary fragmentation mechanism 
> defined in detail in section 5.8.  But I will try to make this 
> 		clearer in the text.

Think of it from the point of view of a receiving system: if there were several nodes before it, it can't rely on only being 2 fragments, it has to expect arbitrary number of them.

So the text you have is possibly helpful for the sending system, but not for the receiving one.

Best Regards,
Alexey