Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-6lo-fragment-recovery-13: (with DISCUSS and COMMENT)
"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 18 March 2020 12:43 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 841153A1500; Wed, 18 Mar 2020 05:43:51 -0700 (PDT)
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=Cew1k4W1; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=LDCBJV64
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 Iwmovp35Yx2x; Wed, 18 Mar 2020 05:43:49 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 527703A14FD; Wed, 18 Mar 2020 05:43:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14226; q=dns/txt; s=iport; t=1584535429; x=1585745029; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=HaKOdoZqUDnGr5plJbnKmYWbrvXGFMvpHVwol2fxJM0=; b=Cew1k4W1mtCpOIypZiHi863Eihgh8tFu7VdNNDlxICmtOf6jq7k80WK9 0ad7J7xYpIGkFg9IMwU2JNygRR94kGFCbKG5gZ7bQ7EE2DDX5ejR8tmKY 9ncMzNK+oms5YxFIslMg0SYxvo7bcJgl05twXruZn6O3nXuO/136JWtf2 s=;
IronPort-PHdr: 9a23:5iYg1R18HvHmAOvDsmDT+zVfbzU7u7jyIg8e44YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSwdDjMwXmwI6B8vQEVH7MfTndTASF8VZX1gj9Ha+YgBY
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BkCAAXFnJe/4YNJK1mDg8BAQEJAREFBQGBe4FUJCwFbFAIIAQLKoQWg0UDinKCX5gYgUKBEANUCQEBAQwBASMKAgQBAYRDAheBfiQ4EwIDAQELAQEFAQEBAgEFBG2FVgyFYwEBAQECARIREQwBASUSAQQLAgEGAhoCJgICAjAVEAIEDg0agwWCSgMOIAEOkhqQZwKBOYhidYEygn8BAQWBMwKDTRiCDAMGgQ4qhSCHDhqBQT+BEUeCTT6CZAEBA4EtAQsHAQgbFYJ6MoIsjXuCPDuGGpk5CoI8h1eFTolwgkqIKJBXmAiSXQIEAgQFAg4BAQWBaSJncXAVgydQGA2OHQwXFYM7hRSFBD10gSmLaYJDAQE
X-IronPort-AV: E=Sophos;i="5.70,567,1574121600"; d="scan'208";a="473773198"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Mar 2020 12:43:48 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 02IChmuL015978 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 18 Mar 2020 12:43:48 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 18 Mar 2020 07:43:47 -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; Wed, 18 Mar 2020 07:43:47 -0500
Received: from NAM12-BN8-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; Wed, 18 Mar 2020 07:43:47 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YLF4a7UJX0Dt13PgUXevhc+btU8r/PdJcdrrePcdAp1PYEvOqN803CcGd0U8Iu/sboc1dhqSszKxpsaatNWxntGHSIFJ0vf8dwvCvEZBUtvmG3y0uWWGEDcyxy8BP2be4nSDT54l36c7bsqG+F3oJ0KmbgMRS6rA2NdrBjhJbYxaWPvYR0KxXfAfUhcVJFhWvV9f9ZLD0n9iIm/QSktdmhNCKjtPWvve6b76lsU+SYHis9SiTdqOtqNjU2pXHBaqybrKUioiP9SyUnYWso2whhMnblagMmA07I4L33zC3mTsV96spir9eo9YvbAeRqfFxBoK4aRqsNWW/iEp1kDVgA==
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=HaKOdoZqUDnGr5plJbnKmYWbrvXGFMvpHVwol2fxJM0=; b=R3gqQitfNNVD3FwnQh+mG/++4wc1LeWC6DptsPpNE9Qx8k1CU5eqBaYzRAVzSho685mIKnWiFVF/6ZTiY3uHMTQCzQl0+v/YjOTMjNB0331UwjbQ4GtKXcpJ82VLBN7vrurTfJEk8/jp/x5XvNlEarU4FYtNyCG+QUQxrTFLrjxUSZ4dEGGSM9WhMnEfD43npaQ7Yel+0wXNZQkYmXpJyl15QJVar5aKBAAW9xWvVLgPA5AnrD3vQCNg8VxmlhI+RN2HO9EIcR8QQ9+mTXfbSi+L1nmnX90w8p+N3yDK4TFfiUZS+SjeoQG2STFV2LL0hxJvGVj8uD3W7LfFCEl8Jw==
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=HaKOdoZqUDnGr5plJbnKmYWbrvXGFMvpHVwol2fxJM0=; b=LDCBJV64o31qnSpftqkg+AA6hMrScwMxZKrSXRNKBXVd9tOCebPBwSo4tHAK2KLmUvP2bjMt9FNQj4rqGBC7cWDgv/gycPDrghr7boP4U8Lz5i7BRCnw2uFIRIFnb6iTTvfxv/kpUPTHvyzuXjSy2KjVoOae83nib+x0GktT44g=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (2603:10b6:208:ea::31) by MN2PR11MB3776.namprd11.prod.outlook.com (2603:10b6:208:ee::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.22; Wed, 18 Mar 2020 12:43:46 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::113b:3127:ef12:ea7]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::113b:3127:ef12:ea7%7]) with mapi id 15.20.2814.021; Wed, 18 Mar 2020 12:43:46 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: The IESG <iesg@ietf.org>, "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: Benjamin Kaduk's Discuss on draft-ietf-6lo-fragment-recovery-13: (with DISCUSS and COMMENT)
Thread-Index: AQHV5qmSETNNZhFgTkSkAXRci24lSKg6Q5OAgBNksYCAALAlEA==
Date: Wed, 18 Mar 2020 12:43:23 +0000
Deferred-Delivery: Wed, 18 Mar 2020 12:43:16 +0000
Message-ID: <MN2PR11MB3565286A8713E6EFD8345926D8F70@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <158206439305.14061.7338782223976480544.idtracker@ietfa.amsl.com> <MN2PR11MB35658F7AB34FA68C20A7FD77D8E20@MN2PR11MB3565.namprd11.prod.outlook.com> <20200318001849.GV50174@kduck.mit.edu>
In-Reply-To: <20200318001849.GV50174@kduck.mit.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: [2a01:cb1d:4ec:2200:5549:5ee1:795c:1e25]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: dbd874b2-43d2-46f2-6763-08d7cb39ffe5
x-ms-traffictypediagnostic: MN2PR11MB3776:
x-microsoft-antispam-prvs: <MN2PR11MB3776CC18F4954F6FB4A78D03D8F70@MN2PR11MB3776.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 03468CBA43
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(396003)(376002)(39860400002)(366004)(199004)(966005)(478600001)(316002)(52536014)(6666004)(71200400001)(8936002)(54906003)(8676002)(81166006)(7696005)(4326008)(81156014)(66556008)(66476007)(64756008)(66446008)(76116006)(66574012)(66946007)(33656002)(186003)(2906002)(6916009)(6506007)(55016002)(9686003)(86362001)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3776; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A: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: tkoKOR+D23n0+Zgy4CXoVrAirjks3qieTZT1TP74TLzYvWWnxiCJhEfGdfpbbV2TDEAnPDCy8t7IDr9BZiyNdiMpsFkYQOVwnT32s1+JJhl1ReJUKRWTJyrYJ2WLToND3rikQfYCN2lqVZKEBrB238AmpbspgWmj5pICeYhnTl+LZO2kNsVHbilBnsuvTY1WMc222y8Or1Qxjr/jYFsvGqIyMxFrOFvUZoGGhjS8ESgigPZ9UaA9A/ZCejfJQqd7UQAvJlghBeGLKk/NsVvwcJjD9Q/q6CcHiS7gPHiO77H+xXvN/qaZO1RfUWTgGqOUqV0lDqGlqH9aUNovmS6SyrRqRnzZBkGH7aowxMQkjjA3CniUOx4v2ig3Y9wx2s1z+YI01ZCZNFm15RTAfvXv9O1ERaec4q8/Qu5cp5ps+3z8sFG21RrvPPZ2ZGe/Qi5N16mP6BuElBcSz1Y6BTnN5IkN0j6wWFW7tlS9hxv0jSzSpiajzNeCi/Ti0+ReZRW8NMLVjiQC5oddJf0mhiawGg==
x-ms-exchange-antispam-messagedata: Mu9AQ4/kVdXdSAWyuswdQaoDpEbgw1lxBI8Vh2T5zll7GH0jFhZstqNxKYgSSI9MDEebJ9WYtY2PYn5nhjNjPyff8sUetQpC9zrivHcUSfFx0yje8G/phOWgZeo7kO7GBzvW8mVTaUIngji10Y1C4q1WqGLtGtRDOFPu81cZqzO7OTMHrpkTGkNBxH/rowKjGu741vKHpsGOxpAogm6kfQ==
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: dbd874b2-43d2-46f2-6763-08d7cb39ffe5
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Mar 2020 12:43:46.1254 (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: dhM1VZnJqatvzUoeHoeGBMQVv1DnZLwxpeGaDFysZA2yg9dx+cxe2FL0XA10MgyVBaG7mW+shqCFOL2ATbJqZw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3776
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com
X-Outbound-Node: alln-core-12.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/uVnsdsTjwTjF1R1EDzGWiF9XcEg>
Subject: Re: [6lo] Benjamin Kaduk'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: Wed, 18 Mar 2020 12:43:52 -0000
Hello Benjamin: Again and again, many thanks, it's really a pleasure to work on your reviews. My plan is a single publication for all 3 emails. I'm merging the 2 mails on the same thread and removing all the items for which we reached an agreement, I hope that helps. Let's see 😊 > I guess this means that a recipient of a "bitmap with as many bits set as > fragments have been sent but not all bits set" has to assume that > refragmentation has occurred and that the full datagram is not acknowledged > yet, which is fine. If the recipient is an intermediate node, it is not supposed to maintain a map of the datagram so it cannot know what constitutes a full coverage by fragments. The fact that all the fragments that it saw are acknowledged does not mean that it's the full datagram. The sender may operate with a window of one and only send the next fragment when the previous was acknowledged. If the recipient is the fragmenting node, it may infer that the datagram is received in full from the bitmap but we do not ask him to do so. Fine if he does and raises an alert when it thinks that the reassembling node should have sent a FULL bitmap, but that's extra code that we cannot mandate for a constrained device. > > > What's the transition/backwards-compatibility story? That is, how > > > does a sender know that all nodes on the path support the RFRAG > > > dispatch types, and what happens if they are sent anyway and get to > > > a node that doesn't implement them? > > > > It has to be management and configuration or alliance games. There is no > negotiation. > > There is no overarching 6LoWPAN protocol that can advertise capabilities > though we're building one for RPL. > > Same goes for all the prior changes to 6LoWPAN, e.g., RFC 8025. > > In practice there is no 6LoWPAN network. There's an ISA100.11a network, a > ZigbeeIP network, a Thread network, or a WiSUN network. Those alliances > specify a particular bundle of functionalities from a bunch of RFCs and build > their compliance tests on that. If Thread decides that the RFRAGs are used, > then all the nodes are capable of it. > > But that's a long story to make in the RFC just to say we do nothing. Do we > really want that? > > I see your point, but we are also in theory supposed to consider the IAB's > guidance from RFC 8170, including among other things incremental > deployability. So my inclination is to include a brief note that since > deployments are expected to be managed and homogeneous, incremental > transition requires a flag day. I used your wording as the last sentence of the introduction. > It did occur to me while reading the diff that we do treat the fragment with > sequence 0 specially, and I didn't fully think through the possibilities if it is that > first packet that is "too long" and needs to be subdivided. There may be > special considerations for the initial fragment where it gets some special > handling, and though I suspect that there are not any real problems here, and > in any case the datagram itself could be re-sent, I mention it just in case there > are some new problems (e.g., we get stuck in a case where we have to send > something that gets treated as a reset even if we don't want it to). Not sure I get you. Tentative answers: 1) The first fragment even when retried carries the Datagram_Size in the Fragment_Offset so it is not zero and not confused with a reset. 2) This may enter PMTU discovery land... does it? We could use the first fragment for that, but that will be another specification. > > > > > ---------------------------------------------------------------------- > > > COMMENT: (merged email) > > > ---------------------------------------------------------------------- > > > > > What about > > > > " > > > > There is no requirement on the reassembling endpoint to check that > > the received fragments are consecutive and non-overlapping. > > > > " > > That seems to cover it, though of course there are the usual potential > security considerations if it doesn't check, which IIRC are in the > companion document now. For memory the companion doc https://tools.ietf.org/html/draft-ietf-6lo-minimal-fragment-14 says " * Overlapping fragment attacks are possible with 6LoWPAN fragments but there is no known firewall operation that would work on 6LoWPAN fragments at the time of this writing, so the exposure is limited. An implementation of a firewall SHOULD NOT forward fragments but instead should recompose the IP packet, check it in the uncompressed form, and then forward it again as fragments if necessary. Overlapping fragments are acceptable as long as they contain the same payload. The firewall MUST drop the whole packet if overlapping fragments are encountered that result in different data at the same offset. " > > > > > > > > > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |1 1 1 0 1 0 1|E| Datagram_Tag | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | RFRAG Acknowledgment Bitmap (32 bits) | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > I think we need to explicitly say here that the Datagram_Tag, in a reversal > of > > > the previous usage, is scoped to the link-layer *recipient* of the > RFRAG_ACK > > > frame. > > > > It is indeed. Added: > > " > > Datagram_Tag: 8 bits; an identifier of the datagram that is locally > > unique to the Link-Layer recipient. > > > > " > > Hmm, the -16 is showing this still as "sender", not "recipient" (maybe > conflicting edits in intermediate versions?). Confusing isn't it? I guess you're looking at the wrong place 😊 We're talking about the acknowledgment. The text page 12 is correct: " Datagram_Tag: 8 bits; an identifier of the datagram that is locally unique to the Link-Layer recipient. " The text page 10 is about the fragment going the forward way, so it is the sender's namespace " Datagram_Tag: 8 bits; an identifier of the datagram that is locally unique to the Link-Layer sender. " > > "if" was meant to say " in case ", replacing. This can happen. E.g., the window > may be smaller than the capacity of the network (related to the nb of hops). > > > > (even more after Mirja's review) I do not want to dig into flow control and > this is borderline. I just wanted to leave the door open for future mechanisms > that are out of scope and that would do it. > > > > Okay, I will not insist on it. Thanks a bunch, slippery slope. > > " > > This specification extends the Virtual Reassembly Buffer (VRB) > > technique to forward fragments with no intermediate reconstruction of > > the entire packet. It inherits operations like Datagram_Tag > > switching and using a timer to clean the VRB once the traffic ceases. > > The first fragment carries the IP header and creates a path from the > > fragmenting endpoint to the reassembling endpoint that all the other > > fragments follow. > > > > " > > Sounds good ("creating the path" is important; "in-order" less so). For this spec that's fully correct. Note that for the LWIG VRB draft, fragments have to be processed in order because of the leftover game even if they are not received in order. > > " > > In addition, the router also forms a reverse LSP state indexed by the > > interface to the next hop, the Link-Layer address the router uses as > > source for that datagram, and the swapped Datagram_Tag. This reverse > > LSP state enables matching the (next interface, destination Link- > > Layer address, swapped_Datagram_Tag) found in an RFRAG > Acknowledgment > > to the abstract forwarding information (previous interface, previous > > Link-Layer address, Datagram_Tag) used to forward the Fragment > > Acknowledgment (RFRAG-ACK) back to the fragmenting endpoint. > > > > " > > Ah, that makes sense. I think I had envisoned the datagram_tag as being > global to the node, across all interfaces and MAC addresses, but there's > not a reason to do so (and in fact reason to not do so, as you discuss > somewhere about how to cope with the limited 8-bit space). The initial text was buggy and your comments made me see it and fix it. Please never refrain from making them! There can be a lot of dust behind a carpet of lack of clarity. > > I cannot see that? Logically that one would have been sent before and > received after. > > Once the FULL is achieved the fragmenting node knows that the > reassembling endpoint is done. > > I couldn't see anything either, but it resembles an edge case that we like > to double-check. So, thanks for double-checking :) Same as above, please keep doing it. > > In addition to the threats detailed therein, an attacker that is on- > > path can prematurely end the transmission of a datagram by sending a > > RFRAG Acknowledgment to the fragmenting endpoint. It can also cause > > extra transmissions of fragments by resetting bits in the RFRAG > > Acknowledgment bitmap, and of RFRAG Acknowledgments by forcing the > > Ack-Request bit in fragments that it forwards. As indicated in > > [FRAG-FWD], Secure joining and the Link-Layer security are REQUIRED > > to protect against those attacks. > > " > > > > Do we want more? > > That looks good. The only thing I'd consider adding is another clause at > the very end, ", as the fragmentation protocol does not include any native > security mechanisms". But it's up to you. Picked > > > Section 7.1 > > Me who thought that the physics exams were behind! > > :) > Must be my chemistry degree at work... I guess that the right (or wrong) molecule can take you anywhere ; ) > I will go reballot now; I had a few more nits that I saw while reading the > diff. Very cool. I'll answer it separately and publish as usual. I should have a stamp to say thanks by now... Pascal
- [6lo] Benjamin Kaduk's Discuss on draft-ietf-6lo-… Benjamin Kaduk via Datatracker
- Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-… Pascal Thubert (pthubert)
- Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-… Pascal Thubert (pthubert)
- Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-… Pascal Thubert (pthubert)