Re: [6lo] Review of draft-ietf-6lo-fragment-recovery-03
"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 11 June 2019 16:33 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 9FD29120199 for <6lo@ietfa.amsl.com>; Tue, 11 Jun 2019 09:33:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.49
X-Spam-Level:
X-Spam-Status: No, score=-14.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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=OnoGPQrt; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=qcYv0qse
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 Yu90qHItmd6w for <6lo@ietfa.amsl.com>; Tue, 11 Jun 2019 09:33:24 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B2E612011E for <6lo@ietf.org>; Tue, 11 Jun 2019 09:33:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=88038; q=dns/txt; s=iport; t=1560270804; x=1561480404; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=nifToDw0CeWh0ojD5NzgrMLEafmYJ3Ab9x0f2dk7QXU=; b=OnoGPQrtjlh9a1l4s3P9L41WV3mDfDgCG/hqxSDoMEYalFK0OZ9yz+c6 JtNQHkvcXkFySWNwhoQ6P3LHdcyoxhe6734UL6/6YR8PMgjjQ4ca5LWm2 VpZ8vTT5RHfHYMLwenyAGtrlUlrRW2VomnEmUfaUxZlcXUbYEpGbS+Hjc 8=;
IronPort-PHdr: 9a23:OpRETBKr3e8M7daxwdmcpTVXNCE6p7X5OBIU4ZM7irVIN76u5InmIFeBvKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUgMdz8AfngguGsmAXFXnLOPgYjYmNM9DT1RiuXq8NBsdFQ==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BIAAAa1/9c/4cNJK1mDg4BAQEEAQEHBAEBgVEHAQELAYEOLyknA2pVIAQLKAqEC4NHA4RSig2CV36WNYEuFIEQA1QJAQEBDAEBIwoCAQGEQAIXgmcjNAkOAQMBAQQBAQIBBG0cDIVKAQEBAwESCAkEBhMBASUSAQQLAgEGAjgBCQICAjAlAgQODRMHgjVMgR1NAw4PAQIMjX2QYAKBOIhfcX4zgnkBAQWBNgKDThiCDwMGgTQBi1wXgUA/gRFGgU5JNT6CYQEBA4E4DgsPK4JdMoImi2CCSoRwiEGNWgkCghCGRY0bgiWGfYoBgmeBGJQqjysCBAIEBQIOAQEFgU84gVhwFYMngg+DcIUUhQQ7coEpjGoBJIELAYEgAQE
X-IronPort-AV: E=Sophos;i="5.63,362,1557187200"; d="scan'208,217";a="573026227"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Jun 2019 16:33:21 +0000
Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x5BGXLEv016608 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 11 Jun 2019 16:33:21 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 11 Jun 2019 11:33:20 -0500
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 11 Jun 2019 11:33:19 -0500
Received: from NAM04-BN3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 11 Jun 2019 11:33:19 -0500
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=nifToDw0CeWh0ojD5NzgrMLEafmYJ3Ab9x0f2dk7QXU=; b=qcYv0qseDrggHgcFFLLmSLzFH5+wA2ilft2A5AHIiBMB2jndGyAjwTXauFvXhHzn2p7GMlSUU++Wb+WMAPlvBzGwcyNZNJoXwxZgBTYT+HuaKZ+stPV/EiGX+BZyJg3h1A/Xoi66S+LIj/YBb3OXPg3zXWLrP75gckSio3dU2Hg=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4125.namprd11.prod.outlook.com (20.179.150.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.14; Tue, 11 Jun 2019 16:33:18 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::7cc2:b440:8820:f0fc]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::7cc2:b440:8820:f0fc%7]) with mapi id 15.20.1965.017; Tue, 11 Jun 2019 16:33:18 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Carles Gomez Montenegro <carlesgo@entel.upc.edu>
CC: "6lo@ietf.org" <6lo@ietf.org>
Thread-Topic: Review of draft-ietf-6lo-fragment-recovery-03
Thread-Index: AQHVHUm8f+qRVU25H0mqy/BeYPev16aWaJFw
Date: Tue, 11 Jun 2019 16:32:52 +0000
Deferred-Delivery: Tue, 11 Jun 2019 16:32:27 +0000
Message-ID: <MN2PR11MB3565A20906F9E56016FFC5F8D8ED0@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <0dbe57929fb7cc5c07f48fdba9f9df46.squirrel@webmail.entel.upc.edu>
In-Reply-To: <0dbe57929fb7cc5c07f48fdba9f9df46.squirrel@webmail.entel.upc.edu>
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: [173.38.220.38]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0515d9b0-0c90-4158-89e0-08d6ee8a826a
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4125;
x-ms-traffictypediagnostic: MN2PR11MB4125:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <MN2PR11MB4125EA04A9A6F9D56CB8D39CD8ED0@MN2PR11MB4125.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 006546F32A
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(376002)(396003)(366004)(136003)(189003)(199004)(81166006)(81156014)(74316002)(8676002)(2171002)(55016002)(966005)(68736007)(5660300002)(30864003)(66574012)(6916009)(7736002)(229853002)(52536014)(25786009)(86362001)(66066001)(7696005)(71200400001)(606006)(99286004)(790700001)(256004)(6116002)(478600001)(8936002)(76116006)(66556008)(316002)(561944003)(3846002)(2906002)(64756008)(71190400001)(76176011)(6436002)(66446008)(446003)(476003)(14454004)(6246003)(11346002)(236005)(73956011)(9686003)(102836004)(186003)(486006)(53936002)(33656002)(6666004)(14444005)(66476007)(6506007)(54896002)(6306002)(53946003)(26005)(66946007)(4326008)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4125; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: SLHJOjV1VUnz4LUQUExKTfvSz3OR8rahqIhE+Y5VQEMaY/kFFWu/r6aXyKll4G9X5ms3YCTMi1kJxqDRmoa77eJ8ctr01LCO8M8g0moTpQZQ5EcYSIP+LOfYKKTWBg9WmmdH0n9updLJFDjcGx1HLtvyzmr0byqxCr3SN/zhqu/NZlYQdgyLWFLu6NH78e8LAKIj3cllipwxouxI75p7g62Fx2voj6p2wyrCtCN1j8by8jR+Bhsf8EbrfipZKmSnAv94cJTN0aj/mVo7HwqfQWS2Kl50O9qarHsL5UY0QMIqK+RRaCKZMmgL8Gk3NHjNuMQsxfTrxmLS7F45qL24IE9qyozA3O3EU5A2bJKTzJryZRX5RsMysNyqCgcpX+LhJqufA9IDXztzgodBvIBOVClJ4XFD8TiW1AOKbEJTTkw=
Content-Type: multipart/alternative; boundary="_000_MN2PR11MB3565A20906F9E56016FFC5F8D8ED0MN2PR11MB3565namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 0515d9b0-0c90-4158-89e0-08d6ee8a826a
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2019 16:33:17.8482 (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: pthubert@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4125
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.22, xch-aln-012.cisco.com
X-Outbound-Node: alln-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/yEfEGNUm0Mkh2IuENVbMlbkf4gA>
Subject: Re: [6lo] Review of draft-ietf-6lo-fragment-recovery-03
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: Tue, 11 Jun 2019 16:33:28 -0000
Many Thanks Carles! Please see below > -------------- Review -------------- > > - Page 2: "in all cases" can be removed > done > - Page 2: "a firmware upgrades" -> perhaps remove "a" (or apply other > changes) > done > - Page 3: "10Kbytes" -> "10 kbyte" > Separated the 10 and spelled out kilobytes. See https://en.wikipedia.org/wiki/Kilobyte > - Page 3: "requires to reassemble the full packet at each hop". > > The sentence should probably be modified. At least, "requires" is > probably not the right verb here. As e.g. stated in > draft-ietf-6lo-minimal-fragment: "it may be beneficial for a > forwarder not to have to reassemble each packet in its entirety > before forwarding it. This has always been possible with the > original fragmentation design of RFC4944". > The sentence is about the "original design" specifically to contrast with minimal. Minimal fragment updates that design as you mention. The next sentence says so. I think we're good there. > - Page 3: "... and trigger the retransmission of the full datagram". > > Perhaps "... potentially triggering" the retransmission..." (since > datagram retransmission will only happen if an upper layer > protocol requires so). > done > - Section 2.2: "in the following documents" --> "in the following document" done > > - Section 2.4: "miss-associated" -> "misassociated" done > > - Section 2.4, last paragraph: "MLPS" --> "MPLS" done > > - Section 3, first paragraph: "A new format for fragment is introduces" > > --> "A new format for fragments is introduced" done > > - Section 3, last paragraph: "... consistently with in Section 2" > > --> "... consistently with Section 2" done > > - Section 4.1, 2nd paragraph: "the fragment number". > > This term appears here for the first time. Perhaps some forward > reference might help the reader. > You right. I changed to a sequence number, which does not need to be defined. > - Section 4.2, 2nd paragraph: "is required protect" > > --> "is required to protect" done > > - Section 4.2, 2nd paragraph: "progressing alon" > > --> "progressing along" > done > - Section 4.3: "The compression of the Hop Limit, of the source and > destination addresses" > > --> Perhaps mention that these are IPv6 header fields (even if it > might seem obvious)? Sure, done > > - Section 4.3, 1st paragraph: "datagram_size" > > --> Perhaps add a forward reference to section where this field is > defined? Added in terminology > > - Section 5, 2nd paragraph: "the node that is the source MAC address" > > --> "the node that corresponds to the source MAC address" > "That owns the source MAC address " is OK I think > - Section 5, 2nd paragraph: "the selected tag" > > --> Perhaps better sticking to "Datagram_tag" done > > - The line above Fig. 1: "page" --> "Page" (as defined in RFC 8025) done > > - Section 5, last paragraph of intro: "datagram-tag" -> "Datagram_tag" done > > - Several instances: "recomposition" --> "reassembly" ? done > > - Section 5.1. The text before Fig. 2 uses terms such as "the sequence > field" that have not yet been introduced. Perhaps indicate they are > introduced later (e.g. in Fig. 2), or some other solution. What about ... The format of the fragment header is shown in Figure 2. It is the same for all fragments. The format has a length and an offset, as well as a sequence field. This would be redundant if the offset was computed as the product of the sequence by the length, but this is not the case. ... > > - Section 5.1, 2nd paragraph: "seem be" --> "seem to be" Removed, see above > > - Page 9: "Fragment_size" field. I was wondering whether this field is > actually needed. Is this used just in case a lower layer technology uses > padding? No, fragments can be of different sizes, in particular to adapt to variation of MTU. Unsurprisingly, this showed up with Laurent's review : ) > > - Page 9: "this field indicates the datagram_size of the compressed > datagram" > > --> "... of the *potentially* compressed datagram" (or some similar > approach), as perhaps in some (rare) cases, a packet will > not be compressed? You are correct, I fixed here and there. Here fixed to In this specification, if the packet is compressed then the size and offset of the fragments are expressed on the Compressed Form of the packet form as opposed to the uncompressed - native - packet form. > > - Page 10, first lines: "may store" --> "may be stored" done > > - Page 10, 2nd bullet: "When the Sequence is not 0, this field indicates the > offset of the fragment **in the compressed form**." > > --> I was wondering what is the meaning of "in the compressed form" > in the previous sentence. Which is the expected representation > of the offset of the fragment? I added "Compressed Form" of the datagram to the terminology Actually added all the below: <t hangText="6LoWPAN endpoints"> The LLN nodes in charge of generating or expanding a 6LoWPAN header from/to a full IPv6 packet. The 6LoWPAN endpoints are the points where fragmentation and reassembly take place. </t> <t hangText="Compressed Form"> This specification uses the generic term Compressed Form to refer to the format of a datagram after the action of <xref target="RFC6282"/> and possibly <xref target="RFC8138"/> for RPL <xref target="RFC6550"/> artifacts. </t> <t hangText="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. </t> <t hangText="fragment_offset:"> The offset of a particular fragment of a datagram in its Compressed Form. The fragment_offset is expressed in a unit that depends on the MAC layer technology and is by default a byte. </t> <t hangText="datagram_tag:"> An identifier of a datagram that is locally unique to the Layer-2 sender. Associated with the MAC address of the sender, this becomes a globally unique identifier for the datagram. </t> <t hangText="RFRAG:">Recoverable Fragment </t> <t hangText="RFRAG-ACK:">Recoverable Fragment Acknowledgement </t> <t hangText="RFRAG Acknowledgment Request:">An RFRAG with the Acknowledgement Request flag ("X" flag) set. </t> <t hangText="All 0's:">Refers to a bitmap with all bits set to zero. </t> <t hangText="All 1's:">Refers to a bitmap with all bits set to one. </t> > > - End of 5.1: "If the fragment cannot be forwarded or routed, then an abort > RFRAG-ACK is sent back to the source." > > --> Perhaps add a forward reference where the concept of "abort > RFRAG-ACK" is defined. done > > - Page 11: there is no explicit text about "Datagram_tag" in the RFRAG > Acknowledgment subsection, below Figure 5. added datagram_tag: 16 bits; an identifier of the datagram that is locally unique to the sender. > > - Page 12, 1st paragraph. The terms "All 0's" and "All 1's" may be well > known for LPWANners. :) But I was wondering if perhaps it might be clearer > to say something like "A bitmap with all bits set to 0...", etc. You right π π π added a definition in the terminology > > - If a datagram is carried by 20 fragments, and all fragments are > successfully received, is the FULL bitmap the only way to indicate so? Or > would a bitmap with the first 20 bits set to 1 and the remaining bits set > to 0 also work? You want the full bitmap because the intermediate hops do not need to remember the sequences. A full bitmap makes it easy to them. That means done, clean up. > > - Section 6, 3rd line: "a one or more fragments" -> "one or more fragments" done > > - Section 6, 4th line: "a standalone header" > > --> Does this mean "without a payload"? If yes, perhaps something > along these lines could be added for extra clarity. added > > - Section 6, end of 1st paragraph: "by reversing the MPLS operation" > > --> "MPLS-like"? Yes, done > > - Section 6, 2nd paragraph: "Te maximum number" --> "The maximum number" > done > - Section 6, 2nd paragraph: "the 6LoWPAN endpoint that reassembles > the packets at 6LoWPAN level (the receiver)" > > --> Swap with "it" in the previous sentence? Done > > - Section 6, 3rd paragraph: "a ARQ timer" --> "an ARQ timer" Or just "a timer" > > - Section 6, 3rd paragraph. A reader may wonder which are the names and > values for the parameters for number of retries, timers, etc. Perhaps a > reference to Section 7 could be added. done > > - Page 13, 2nd paragraph: "last fragment of a series" > > --> Is this the same as "Last fragment of a window"? If yes, perhaps > use "window" (which has been introduced before). done > > - Page 13, 2nd paragraph: "RFRAG Acknowledgment Request" and > "acknowledgment request" are not defined terms, whereas "Ack-Request bit" > is defined. Added to terminology > > - Page 13, 2nd paragraph, last sentence: does "it" refer to "Delaying the > acknowledgment" or to the "round trip delay computation" ? > Hard to fix. Proposal: Because it might defeat the round trip delay computation, delaying the acknowledgment should be configurable and not enabled by default. > - In some instances, "cancel" is used. I was wondering if "abort" refers to > the same. If yes, then perhaps just stick to one term? > Generalized to "abort" > - Page 14. "alternate routes not possible" -> "alternate routes are not > possible" Fixed to As a consequence, the next fragments can only follow the path that was set up by the first fragment and cannot follow an alternate rout > > - I understand that the document has been designed with Route-Over in mind, > but I was wondering if the document might also work in Mesh-Under. Any > thoughts? Probably does, yes. No need to forward fragments, so all the MPLS-like / reverse MPLS is moot. > > - Page 15, last paragraph: "to the previous router" > > --> "to the previous node" (since perhaps the previous node could be a > host?) Reworded as To achieve this, each hop that performed an MPLS-like operation on fragments reverses that operation for the RFRAG_ACK by sending a frame from the next hop to the previous hop as known by its MAC address in the VRB. The datagram_tag in the RFRAG_ACK is unique to the receiver and is enough information for an intermediate hop to locate the VRB that contains the datagram_tag used by the previous hop and the Layer-2 information associated to it (interface and MAC address). > > - Section 6.2, 2nd paragraph. "until" -> "Until" Done > > - Section 6.2, 3rd paragraph. If the minimal MTU that decreases is in one of > the intermediate hops (i.e. not the first hop), how does the sender detect > such event? PMTUD I guess. Or configuration change. I added: Note that Path MTU Discovery is out of scope for this document. > > - Section 7.1, 1st paragraph: "as echoing ECN should always be on" > > --> "as echoing ECN is always on" (or is the opposite possible?) done > > - Section 7.1, 1st paragraph: "to the sender that is in control" > > --> "to the sender, which is in control" Done > > - Section 7.1. Should there be default values for the parameters defined? Hard, depends on the tech and number of hops. > > - Section 7.1. There are two UseECN entries! fixed > > - Section 7.2. "The management system should monitor..." > > --> Any hint on how this could be done? E.g. each node self-monitors > its performance? An external NMS system collects such information > and makes decisions? > Open to suggestions : ) > - Section 8. Some of the content of Section 7 in > https://tools.ietf.org/html/draft-ietf-core-cocoa-03 may apply here. > Excellent suggestion, added a link. > - Page 22: "all fragments are resent" --> "all fragments would need to be > resent..." done > > - Page 22, 4th paragraph. "Mesh Addressing" and "Mesh-Under" are > mentioned. > Since the document focuses on Route-Over, are these needed? I'd say yes as a comparison point. This is annex anyway. > > - I understand that the document has been designed with Route-Over in mind, > but I was wondering if the document might also enable the same > functionality for Mesh-Under (not sure if with perhaps minor adaptations). > Any thoughts? Well I guess it could be used there too. The fragment forwarding is not useful but the ARQ might be. If the group wants we could add a section. Many thanks Carles, that was huge! I'll be publishing 04 now. Pascal
- [6lo] Review of draft-ietf-6lo-fragment-recovery-β¦ Carles Gomez Montenegro
- Re: [6lo] Review of draft-ietf-6lo-fragment-recov⦠Pascal Thubert (pthubert)