Re: [6lo] Warren Kumari's Discuss on draft-ietf-6lo-fragment-recovery-13: (with DISCUSS and COMMENT)

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 06 March 2020 18:57 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 268073A0496; Fri, 6 Mar 2020 10:57:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level:
X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=iYCkfTxF; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=eEtUPjub
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 zD7BgZ0QNQao; Fri, 6 Mar 2020 10:57:42 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 393453A046D; Fri, 6 Mar 2020 10:57:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4200; q=dns/txt; s=iport; t=1583521062; x=1584730662; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=pgS0TEB41eoOBn1OsMtZbPZHbmqawicZ2aMAOBlGVUQ=; b=iYCkfTxFhRsalA0NhAv0Ck/80Ts8/MGFjLbzGAPZrNg9YONxxnqyfDOy UFLg0ayfEp0O5fQbStlbgkL89cvgpyVZWlHFeibkHDq6KoJPdtcgLMWbF 6Jodaekdl3ZG8jWvwcVi9g1N6uOcyuDS2gN2tSGO2oMMCULe/PnEHqgFR M=;
IronPort-PHdr: 9a23:1uiwMBJnT/fpGDuwN9mcpTVXNCE6p7X5OBIU4ZM7irVIN76u5InmIFeBvKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUgMdz8AfngguGsmAXFXnLOPgYjYmNM9DT1RiuXq8NBsdFQ==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CYBQAvnGJe/5NdJa1kHAEBAQEBBwEBEQEEBAEBgXuBVFAFbFggBAsqhBWDRgOKaZp0gUKBEANUCQEBAQwBASMKAgQBAYRDAheBdyQ4EwIDAQELAQEFAQEBAgEFBG2FVgyFZAIBAxIREQwBATcBDwIBCBoCJgICAjAVEAIEAQkEDRqDBYJKAy4BDp1zAoE5iGJ1gTKCfwEBBYEzAoNQGIIMAwaBDiqFIYcHGoFBP4ERR4JNPoJkAgIagS8cgw8ygiyNc4J1j1Upjk9wCoI8lwKCSYghhE6CM4R9hE2OdptRAgQCBAUCDgEBBYFpIoFYcBWDJ1AYDYFSjEsJAxcVgzuFFIVBdIEpj04BAQ
X-IronPort-AV: E=Sophos;i="5.70,523,1574121600"; d="scan'208";a="443235538"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Mar 2020 18:57:40 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 026IveUD028837 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 6 Mar 2020 18:57:40 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 6 Mar 2020 12:57:40 -0600
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 6 Mar 2020 12:57:39 -0600
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 6 Mar 2020 13:57:39 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Biizy3EJlRG26QZXWTdC2vnRHkwZdkKGa724nxCALeYffhtaHhdDocZx2VAYylo5d/ZBbQ5JdeeaBojdLuUjK4UzpaNiFC+Il5XCARl2CBWP/E8Xj65sgaHaSA+Nv4JxdX6r63BY2kSpQyNjD1VWpgSGrcLBuS67QDlOUVedC/necMkdO68SS8mAasCl5ur4TK3JZ1ikGUzcQU0i7+lHykdjMV/6KwhjIt55VsAXofAJsg7/6paVe9PtudsAnxipMIfsJ3w/06h5xSwgswI4wUx5wVgrBm1fusz9AokxiRhgtuerFNc2/GBok+D/utKtrJTK0jwaoxKjjkeYXPhy1A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;bh=pgS0TEB41eoOBn1OsMtZbPZHbmqawicZ2aMAOBlGVUQ=; b=LC6U/mnuGG6kikLWGlAjKAVSuywPIfxd3zKeEZTDC77xGxPg7XOSoVWeXLJ1I6XOVTxx+tcR3U5f1GlvPaUkQ702z9DdPDpoxKBYEMqbKk5vuR7pi25K0oekXVif9lhnsZKFUR7OaXqgpUaOAF7x3UOZAxp2/ldJRHdB9nb7LiLuT2CAnTb/a4eQxDwxr412/2qm6pXys3iTroN3wOmBZeKmuYUoTaubYNMuMpZD7Yjfe+BoSWHBBkZikL4Vf22CbeWtCwY8+tXsjjCIJ1SUZxtRKBkHqxNo/twiYdsgZxwlVazi7kFG262KvA45fT33fTkY/kz5UuNbrRKz50MdsA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pgS0TEB41eoOBn1OsMtZbPZHbmqawicZ2aMAOBlGVUQ=; b=eEtUPjubnan6DUm45kH+dZeqBYwew7WBlrVCxbrPjcHhvQyhb8l1y+c6P2pIFTaC8PmUywsxT4Y+kPCs0sRD9tx+lH6G9IYnEMuP4QnTlBtTot3omtRyJZVTAMGngL7eK1LXywO0fwNsBRxutjbS0gkMAnFITgLYMJwR5giq8ts=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (2603:10b6:208:ea::31) by MN2PR11MB4533.namprd11.prod.outlook.com (2603:10b6:208:264::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.15; Fri, 6 Mar 2020 18:57:37 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::edba:2b0f:7341:2c24]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::edba:2b0f:7341:2c24%6]) with mapi id 15.20.2793.013; Fri, 6 Mar 2020 18:57:37 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Warren Kumari <warren@kumari.net>, The IESG <iesg@ietf.org>
CC: "draft-ietf-6lo-fragment-recovery@ietf.org" <draft-ietf-6lo-fragment-recovery@ietf.org>, Carles Gomez <carlesgo@entel.upc.edu>, "6lo-chairs@ietf.org" <6lo-chairs@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>
Thread-Topic: Warren Kumari's Discuss on draft-ietf-6lo-fragment-recovery-13: (with DISCUSS and COMMENT)
Thread-Index: AQHV525sPMTjj3R2oUOP8+TNzg2Bpqg7mkJQ
Date: Fri, 06 Mar 2020 18:56:19 +0000
Deferred-Delivery: Fri, 6 Mar 2020 12:47:35 +0000
Message-ID: <MN2PR11MB356554CBB1689BFC50363167D8E30@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <158214894500.17738.11622768395191956565.idtracker@ietfa.amsl.com>
In-Reply-To: <158214894500.17738.11622768395191956565.idtracker@ietfa.amsl.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com;
x-originating-ip: [2a01:cb1d:4ec:2200:fc31:4bd4:6411:8e6b]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 747ff28d-001a-47b0-4c9f-08d7c2003d29
x-ms-traffictypediagnostic: MN2PR11MB4533:
x-microsoft-antispam-prvs: <MN2PR11MB4533C79D7B28937CFBDD7DD9D8E30@MN2PR11MB4533.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0334223192
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(346002)(39860400002)(376002)(396003)(199004)(189003)(186003)(54906003)(9686003)(81166006)(52536014)(110136005)(81156014)(4326008)(71200400001)(316002)(6666004)(478600001)(55016002)(5660300002)(2906002)(66946007)(966005)(66446008)(6506007)(76116006)(66476007)(8936002)(8676002)(64756008)(7696005)(66556008)(86362001)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4533; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: CzNHMJKY8d+OfHc7LxGaMsiTD9er+gwoiSuUOau5JOalp/uIwByA9zsT+o3GLMNEBRXxer0a+SAo7XtDecMW33VniNCcrvCXK8Xz8BX4o2XPKKsPOQy18zj5bREFenjev1UsVwpZK3cKmCkvHlNOzRIMou1dITCHqv/t5iShDGpvlNnEmCOjux+hHdvRgGYlpPjQf9mcnrR1XWNIJfw25Y4v5Z+S4u3NCSMKrj6MMQK5U2LzFHyVgosELNmqB9yicI9VYfJzuKv5tDbwF5IvLSI/nn1B8VVJnoo8FwvCy/ploEVKlVpQp0ybRyQv26xDOVnClXk3zAF+zpw8VAWaCUJN0Oi3R0SyqQN8WotObBPRmIRutVocUtF9PJ5r6ER0z00vFjX+irpW5lEF/4tKjMU3Jxg3qDSaMvqxpNI2j59FYD7R7eyf0nEx/UEqnYDjBHj9icGZDRMfKD+soHctTc58bRCv5Ksu8sTuaa0BXu0J0oln8DexU+1+TFSluyxRYlDi6Ognhcgieba44LgSTg==
x-ms-exchange-antispam-messagedata: +2rEsMhJay8SsShVqBxJqC7MrE0lLKXRYXfb2hZ9lxx25X8O5LWo0czvFSu69qabk+Xo6WpofgUkvmYyB59ZG4QFceQ4CQRcLphkXJ1IY5pCnGLqPiqQqXNJrBKsajREKR3UABlcI9oAt7rlH5cgNs3yuYX4Ati1FU0qccvPeI5nNvqhXzac3siRzKaGO/XJFNLQAkRFkAXx39v0NCKXng==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 747ff28d-001a-47b0-4c9f-08d7c2003d29
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2020 18:57:37.7240 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: yy/JSwIJcSgsPptAIWNTC92P+vgmdSH4+cASEyTjLauIec7p56ehqsmIQdCjMVw6jZGVY0xmWrUF0J5vBhcC8g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4533
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com
X-Outbound-Node: rcdn-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/IXZOxJ816jzGIV15u5aig26ji-g>
Subject: Re: [6lo] Warren Kumari's Discuss on draft-ietf-6lo-fragment-recovery-13: (with DISCUSS and COMMENT)
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Mar 2020 18:57:44 -0000

Hello Warren

Many thanks for your review!

Please find the proposed changes discussed below in https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-fragment-recovery-14 

Let's see below:

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> [ Be ye not afraid - this should be easy to address.]
> "datagram_size: The size of the datagram in its Compressed Form before it is
> fragmented. The datagram_size is expressed in a unit that depends on the
> MAC layer technology, by default a byte." and: "Fragment_Size:  10-bit
> unsigned integer; the size of this fragment in a unit that depends on the MAC
> layer technology.  Unless overridden by a more specific specification, that
> unit is the octet, which allows fragments up to 1024 bytes."
> 
> I spent quite a while going though the document, looking at the 13 places
> where you use 'byte' and 3 where you use 'octet', trying to figure out if there
> is a reason that different terms are used. Normally I'd just say "meh, these
> are synonyms" and ignore it, but in this particular specification (because of
> the "by default" / "Unless overridden") I think it is actually important.... Can
> you standardize on one of the other, or provide more explanatory text if
> there is a reason?

Standardized to Byte, per Carsten's recommendation. As a Frenchman I preferred octet : )
Note that the definition is now removed from this document and inherited from I-D.ietf-6lo-minimal-fragment per Benjamin's review.

The end of appendix A becomes:
"

   Mechanisms such as TCP or application-layer segmentation could be
   used to support end-to-end reliable transport.  One option to support
   bulk data transfer over a frame-size-constrained LLN is to set the
   Maximum Segment Size to fit within the link maximum frame size.
   Doing so, however, can add significant header overhead to each
   802.15.4 frame and cause extraneous acknowledgements across the LLN.
"
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you for a useful and interesting read -- I really enjoyed this document.
> 
> I do also support Benjamins "I think we should be more clear about whether
> a "FULL bitmap" always has 32 bits set to one, or if "merely" having as many
> bits as the sender sent fragments set to one also counts as "FULL". "
> comment, and had something very similar drafted...
> 

Yes, I addressed this in Benjamin's review. But I did not really find the place that triggered the doubt.
There is new text now, I hope that fixes it. There is also a definition of FULL and NULL bitmaps:

"
   NULL bitmap:  Refers to a bitmap with all bits set to zero.

   FULL bitmap:  Refers to a bitmap with all bits set to one.

"
I hope it is clear enough, but happy to reword if needed.

Many thanks again for your review : )

Pascal