Re: [6lo] Éric Vyncke's No Objection on draft-ietf-6lo-fragment-recovery-13: (with COMMENT)

"Eric Vyncke (evyncke)" <evyncke@cisco.com> Fri, 06 March 2020 20:50 UTC

Return-Path: <evyncke@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 31E493A0A96; Fri, 6 Mar 2020 12:50:56 -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=HJMtjFyf; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Y3FCc7Ee
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 MIdSduFZ4iRt; Fri, 6 Mar 2020 12:50:54 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2C0B3A0A7A; Fri, 6 Mar 2020 12:50:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9480; q=dns/txt; s=iport; t=1583527853; x=1584737453; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=EDCmo4Ptho5ftBGKfwn5v0Z7DRHhK+B0Uex9X9/76ZM=; b=HJMtjFyf8XX+xRWyFuh+/KcrSxgyjsJOnoABCvy6/cGWJoG0M9Umm7N7 tx116t3ZhFMLtDLylJl+oACk0pWA7Wzt2u7Hm1ciKBMfT1C921u3L6Xvp N82OA2nLWiynulsdGmEe8nuz/qdtIlyVAbkckPN/aDwys402wViwCDg5R c=;
IronPort-PHdr: =?us-ascii?q?9a23=3AmgeuMhPaH5gOnuBD9skl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu60/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBj2Mu/sZC83NM9DT1RiuXq8NBsdFQ=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CjBQACt2Je/4gNJK1kHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuBVCQsBWxYIAQLKoQVg0YDimqCX4EBlxSCUgNUCQEBAQwBASM?= =?us-ascii?q?KAgQBAYRDAheBdyQ4EwIDAQELAQEFAQEBAgEFBG2FVgyFYwEBAQEDEhERDAE?= =?us-ascii?q?BNwELBAIBCBEDAQIDAiYCAgIwFQUDCAIEAQ0FIoMEAYJKAy4BDp1zAoE5iGJ?= =?us-ascii?q?1gTKCfwEBBYEzAoNPGIIMAwaBDiqFIYcHGoFBP4ERJyCCGDU+gmQCAhqBIYM?= =?us-ascii?q?5MoIsjXOCdY9+jk9wCoI8lmYcgkmIIYROhzCETYNMiyqZCoJHAgQCBAUCDgE?= =?us-ascii?q?BBYFpIoFYcBVlAYJBUBgNV41GCQMXFYM7hRSFQXSBKY0MgkIBAQ?=
X-IronPort-AV: E=Sophos;i="5.70,523,1574121600"; d="scan'208";a="451629969"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Mar 2020 20:50:52 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 026KoqKG005387 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 6 Mar 2020 20:50:52 GMT
Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 6 Mar 2020 14:50:52 -0600
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 6 Mar 2020 14:50:52 -0600
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 6 Mar 2020 14:50:51 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; =?utf-8?q?b=3DQOtGpNB6yV/8YfTdyS5hsXbJWUrBqvuLFqUhg9w0Yg+ApHng9DBapu5RRlY2V?= =?utf-8?q?Ek99LDs4JNGGSH4e5v1vArzoLwXvawhN07lHMicviFkSIIjEj9z/+peS1Sgs//GSe?= =?utf-8?q?nucX6wJ+WNDXu4TQCbBTRnxlIZetMobxqS/UMXC6VeufJJdcJV8Tydq6ZC5iWqg3Z?= =?utf-8?q?TQ6Czn34u7Cw5mec7wy6AqBHqcymPYJACHGNIMrBaVhtENIdofHkgGRTZP9hd1ogx?= =?utf-8?q?b5qCKTd9muKFSbjQuX1+OT7wKF0Io7pNFnnRjIyQ86/cmcFqQvecIwy2zVqVWEUjG?= =?utf-8?q?+n6UcSnfGUYUk5ESNOjSg=3D=3D?=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AMessage-ID=3ACont?= =?utf-8?q?ent-Type=3AMIME-Version=3AX-MS-Exchange-SenderADCheck=3B?= =?utf-8?q?bh=3DEDCmo4Ptho5ftBGKfwn5v0Z7DRHhK+B0Uex9X9/76ZM=3D=3B_b=3DjShqwM?= =?utf-8?q?gbLHC0YlNP+Hkr74nFWMFXiiqHtTI6+JtJEJE3mlh5n2P4B+v/gN9ZIGLLUckHJYp?= =?utf-8?q?k5j9QwOf5HTRktFgjDt0DfwL6gENlZI0urCTjRF/+zfE69wvB4jdERVQcUWqrewHr?= =?utf-8?q?6TxK4JdQJFUrJ2eGmMgplJsadfsTjNBqnhANKkhry0AoT28CuD3mI73Hep+4JdSND?= =?utf-8?q?7XIkjpJXIAY5K+Uds6Kqlu8v3OtZMqbpqW0SXt5rWtsq0VHHjSkpzQbLpDRqGSrCK?= =?utf-8?q?X75K8+AQAtGpr0fyc4QD0iiavrWoN6xEnM/NKXpkBL8pJu9wPqj/5NirCoAO2YaDF?= =?utf-8?q?u7gdTP85Vvg=3D=3D?=
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; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AM?= =?utf-8?q?essage-ID=3AContent-Type=3AMIME-Version=3AX-MS-Exchange-SenderADC?= =?utf-8?q?heck=3B_bh=3DEDCmo4Ptho5ftBGKfwn5v0Z7DRHhK+B0Uex9X9/76ZM=3D=3B_b?= =?utf-8?q?=3DY3FCc7Eekgvd9YdwgyUB6sf6oVVMNj86L1aFBUYTogWH5wceMKcC/xsU3YhdV8?= =?utf-8?q?WluYlcMNt9hhp9ksGTZJxMz1mrhiu0i6yVZliXQ/A8WTc4Ek7zRwy6vx/R7JSLPyr?= =?utf-8?q?1dGqMwGE/vRCpPRoed4uaU3Pv952IyF10clIzp04XwHc=3D?=
Received: from DM5PR11MB1753.namprd11.prod.outlook.com (2603:10b6:3:10d::13) by DM5PR11MB1660.namprd11.prod.outlook.com (2603:10b6:4:4::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.14; Fri, 6 Mar 2020 20:50:49 +0000
Received: from DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::680d:e22e:72d5:67ca]) by DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::680d:e22e:72d5:67ca%3]) with mapi id 15.20.2772.019; Fri, 6 Mar 2020 20:50:49 +0000
From: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-6lo-fragment-recovery@ietf.org" <draft-ietf-6lo-fragment-recovery@ietf.org>, "6lo-chairs@ietf.org" <6lo-chairs@ietf.org>, "carlesgo@entel.upc.edu" <carlesgo@entel.upc.edu>, "6lo@ietf.org" <6lo@ietf.org>
Thread-Topic: [6lo] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-6lo-fragment-recovery-13=3A?= (with COMMENT)
Thread-Index: AQHV5yWD5Xj09hNHsEicT3TqKQcwBag6KyEwgAIJKwA=
Date: Fri, 6 Mar 2020 20:50:49 +0000
Message-ID: <87255E31-C63B-42BF-B6D7-E9B1AC03EC1E@cisco.com>
References: <158211762351.23776.5618697293473954460.idtracker@ietfa.amsl.com> =?utf-8?q?=3CMN2PR11MB356508B020B4D2F877E91107D8E30=40MN2PR11MB3565=2Enampr?= =?utf-8?q?d11=2Eprod=2Eoutlook=2Ecom=3E?=
In-Reply-To: =?utf-8?q?=3CMN2PR11MB356508B020B4D2F877E91107D8E30=40MN2PR11MB?= =?utf-8?q?3565=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?=
Accept-Language: fr-BE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.22.0.200209
authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com;
x-originating-ip: [2001:420:c0c1:36:11c6:93af:55d9:ad7]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1ef40bce-7244-4bd1-4a3d-08d7c2100d4e
x-ms-traffictypediagnostic: DM5PR11MB1660:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: =?utf-8?q?=3CDM5PR11MB1660DE4D3AD7B143F4CAA10BA9E?= =?utf-8?q?30=40DM5PR11MB1660=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?=
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0334223192
x-forefront-antispam-report: SFV:NSPM; =?utf-8?q?SFS=3A=2810009020=29=284636?= =?utf-8?b?MDA5KSgzNjYwMDQpKDM3NjAwMikoMTM2MDAzKSgzOTYwMDMpKDM5ODYwNDAw?= =?utf-8?b?MDAyKSgzNDYwMDIpKDE5OTAwNCkoMTg5MDAzKSg2NjU1NjAwOCkoNjQ3NTYwMDgp?= =?utf-8?q?=2866476007=29=282906002=29=2876116006=29=2866946007=29=285660300?= =?utf-8?q?002=29=2891956017=29=28186003=29=2836756003=29=2871200400001=29?= =?utf-8?q?=2866446008=29=2854906003=29=28110136005=29=2886362001=29=2822430?= =?utf-8?b?MzAwMykoNTM1NDYwMTEpKDY1MDYwMDcpKDY0ODYwMDIpKDg5MzYwMDIpKDgx?= =?utf-8?b?MTY2MDA2KSg5NjYwMDUpKDQ3ODYwMDAwMSkoMjYxNjAwNSkoNDMyNjAwOCko?= =?utf-8?q?6512007=29=28316002=29=2833656002=29=2881156014=29=3B?= DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR11MB1660; H:DM5PR11MB1753.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: =?utf-8?q?SBvxqs/yAQXfJoj6a1zk11YPXW4m7m9?= =?utf-8?q?tv/5Fi8LTA9YsDxOZW6Uk1ishoR7FspMtRJBaxQrLCy30lnZcPtoYyZscHiNmc9A9?= =?utf-8?q?eQVJj8Ni/izBrhXIL6m7j4t5GymG1oIQE8BUWYmMu3ugQrT4LDffMRvgWgmn1eC7y?= =?utf-8?q?fPEHaGS+T13jIY4vHcRX/hGxzC1ph2B7U/T3vrXmCcUYQ9QhizdxTgsAIM+g/BZbo?= =?utf-8?q?GlN47MmL6/6NWctG8yx/xMXlrA7Zuls+R/Le9Q3TxhrmbUr/wMOwvGK0DlHYWsKj8?= =?utf-8?q?OcMrZSjQlH/OC6ezURlb46s111gu1BcY0DjkTw6uGIxUu6Q5HAFHb45m254VrxzaZ?= =?utf-8?q?5KdUoW7sdCowshpBrtaOMtLssic2NuGy8oaqSjYum+9GGCk0M/ttFyu7AExTSsnjm?= =?utf-8?q?IdmuWfsd5RYsTKkLv95u1mAZC0yDmNJ0j281O8XMQXMpqx2yPqnMPpmV3wimBrXNd?= =?utf-8?q?lPVXnoQ3TfoNQBNfi4wSttz46tUQ3tDSwofbrFqSVoQqXhmw=3D=3D?=
x-ms-exchange-antispam-messagedata: =?utf-8?q?sN1A7dgiuVklzdvInycvbhdPeyYVy5?= =?utf-8?q?k9+aia3y94ptbO+MIsn4ICa2dL6ngnhY6bLX4khWvRCu61AbEkIJ2vDkaA6myPea8?= =?utf-8?q?Cgkv2teR5hQEqWTNLVN9uCvmK3K8BxfXRtFgjLxl42yaWJWrOW7PXXFMPzwlnZ66C?= =?utf-8?q?whQGTguX9kGp35sfo/gllKBAydVH4uwNa9pZzyR6lpmKjhiP0lQWTg=3D=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <A3BF222FF3457743965D02FE5A93E8D8@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 1ef40bce-7244-4bd1-4a3d-08d7c2100d4e
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2020 20:50:49.0936 (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: =?utf-8?q?5of+NK1UdZta7BdKW2hiS?= =?utf-8?q?hAsNtf5xjsdqAct8Z2UIkClZecg/SqOdg/YYyDXCgz4qJI0LKsFNb/aCbLPd9qzZA?= =?utf-8?q?=3D=3D?=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1660
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/84QStz9gy2bZcnRYZDPlE5yvzJI>
Subject: Re: [6lo] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf-?= =?utf-8?q?6lo-fragment-recovery-13=3A_=28with_COMMENT=29?=
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 20:51:01 -0000

Pascal,

Merci very much for your response and changes in the text. While my COMMENT were non blocking, I am happy to see that you took the opportunity to improve the document.

Regards (and do not forget the deadline of Monday __)

-éric



-----Original Message-----
From: Pascal Thubert <pthubert@cisco.com>
Date: Friday, 6 March 2020 at 19:58
To: Eric Vyncke <evyncke@cisco.com>om>, The IESG <iesg@ietf.org>
Cc: "draft-ietf-6lo-fragment-recovery@ietf.org" <draft-ietf-6lo-fragment-recovery@ietf.org>rg>, "6lo-chairs@ietf.org" <6lo-chairs@ietf.org>rg>, "carlesgo@entel.upc.edu" <carlesgo@entel.upc.edu>du>, "6lo@ietf.org" <6lo@ietf.org>
Subject: RE: [6lo] Éric Vyncke's No Objection on draft-ietf-6lo-fragment-recovery-13: (with COMMENT)

    Hello Eric:
    
    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  that I just published 
    
    Let's see below, and please let me know if the proposed changes work:
    
    > 
    > 
    > ----------------------------------------------------------------------
    > COMMENT:
    > ----------------------------------------------------------------------
    > 
    > == COMMENTS ==
    > 
    > A generic question is whether RFC 7112 "Implications of Oversized IPv6 Header
    > Chains" is applicable ?
    > 
    > -- Section 4.2 and Section 7.1 --
    > Should default values for the inter-frame gap be given ?
    
    We discussed this in the minimal fragment review. Initially there was no other draft so this really introduced the concept. Now all the normative text moved to minimal.
    So it makes sense to make a change here:
    
    before
    
       This specification introduces a concept of an inter-frame gap, which
       is a configurable interval of time between transmissions to the same
       next hop.  In the case of half duplex interfaces, this inter-frame
       gap ensures that the next hop has completed processing of the
       previous frame and is capable of receiving the next one.
    	
    After
    
       [I-D.ietf-6lo-minimal-fragment] requires that a configurable interval
       of time is inserted between transmissions to the same next hop and in
       particular between fragments of a same datagram.  In the case of half
       duplex interfaces, this inter-frame gap ensures that the next hop is
       done forwarding the previous frame and is capable of receiving the
       next one.
    
    end
    
    
    
    > 
    > -- Section 5.1 --
    > With 8 bits in the Datagram_Tag, this means that a node can only
    > transmit/forward 256 packets over a link. While this seems suffisant, did the
    > author make some investigation on this limit? The text should also state what
    > to do when the 8 bits are not enough.
    > 
    
    A typical 6LoWPAN node have memory for one or a few packets. Having 256 packets that transit in the fragmented form over a same hop at the same time seems very far from the capabilities of current 6LoWPAN nodes. The trend for new MACs is to support the IPv6 Min MTU, making 6LoWPAN fragmentation a thing of the past. So I believe we're good. 
    
    I'm adding the last sentences of the following text in the introduction:
    "
       "LLN Minimal Fragment Forwarding" [I-D.ietf-6lo-minimal-fragment]
       specifies the general behavior that all FF techniques including this
       specification follow, and presents the associated caveats.  In
       particular, the routing information is fully indicated in the first
       fragment, which is always forwarded first.  A state is formed and
       used to forward all the next fragments along the same path.  The
       Datagram_Tag is locally significant to the Layer-2 source of the
       packet and is swapped at each hop, more in Section 6.  With this
       specification the Datagram_Tag is encoded in one byte, and will
       saturate if there are more than 256 datagram that transit in the
       fragmented form over a same hop at the same time.  This is not
       realistic at the time of this writing.  Should this happen in a new
       6LoWPAN technology, a node will need to use several Link-Layer
       addresses to increase its indexing capacity.
    "
    
    
    > -- Section 5.2 --
    > I suggest to mention that the use of the Datagram_Tag field will be described
    > in section 6.
    
    Works for me. In fact, I pushed that up to the introduction, see the text above.
    
    
    > 
    > -- Section 6 --
    > I find it weird to read in the same paragraph "The RFRAG Acknowledgment can
    > optionally carry an ECN" and later "MUST echo that information by setting the
    > 'E'". I am not a native English speaker but may I suggest to replace the first part
    > with "The RFRAG Acknowledgment has a ECN"
    
    Yes, done.
    
    > 
    > -- Section 6.1.2 --
    > "An implementation may receive overlapping fragments as the result of retries
    > after an MTU change." Is this a security risk (RFC 8200 forbids overlapping
    > fragments but this is a different layers) ? I also suggest to make it a normative
    > "MAY" or "MUST accept".
    
    I got a similar comment in Ben's review on this : )
    
    "
    
       [I-D.ietf-6lo-minimal-fragment] indicates that the receiving endpoint
       stores "the actual packet data from the fragments received so far, in
       a form that makes it possible to detect when the whole packet has
       been received and can be processed or forwarded".  How this is
       computed is implementation specific but relies on receiving all the
       bytes up to the Datagram_Size indicated in the first fragment.  An
       implementation may receive overlapping fragments as the result of
       retries after an MTU change.
    
    "
    
    
    > 
    > -- Section 7.2 --
    > Should the network observation installs global states or per destination states
    > ? E.g., typical IP implementations maintain a per destination Path MTU cache.
    
    I guess the same here, this is per destination for each sender and per sender for each destination.
    
    "
       The management system should monitor the number of retries
        and of ECN settings that can be observed from the perspective of
        both the sender and the receiver with regards to the other end-point.
    
    "
    > == NITS ==
    > 
    > -- Section 7 --
    > Is it "Kbps" or "kbps" ?
    
    Long as the b is lowercase (indicating bit) I believe we're safe. But back to SI, Kilo is uppercase (because it is a multiple of the unlike milli or micro) so I favor Kbps. 
    
    Please let me know if we're good with the above,
    
    Again many thanks, Eric!
    
    Pascal