[lp-wan] Magnus Westerlund's Discuss on draft-ietf-lpwan-coap-static-context-hc-13: (with DISCUSS and COMMENT)
Magnus Westerlund via Datatracker <noreply@ietf.org> Thu, 12 March 2020 10:00 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: lp-wan@ietf.org
Delivered-To: lp-wan@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 10AF43A082D; Thu, 12 Mar 2020 03:00:49 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Magnus Westerlund via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-lpwan-coap-static-context-hc@ietf.org, lpwan-chairs@ietf.org, lp-wan@ietf.org, Pascal Thubert <pthubert@cisco.com>, pthubert@cisco.com
X-Test-IDTracker: no
X-IETF-IDTracker: 6.120.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-ID: <158400724904.18264.11973989758327952003@ietfa.amsl.com>
Date: Thu, 12 Mar 2020 03:00:49 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/lp-wan/LP_AAevDmCckz863-SreO59af9c>
Subject: [lp-wan] Magnus Westerlund's Discuss on draft-ietf-lpwan-coap-static-context-hc-13: (with DISCUSS and COMMENT)
X-BeenThere: lp-wan@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" <lp-wan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lp-wan>, <mailto:lp-wan-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lp-wan/>
List-Post: <mailto:lp-wan@ietf.org>
List-Help: <mailto:lp-wan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lp-wan>, <mailto:lp-wan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Mar 2020 10:00:49 -0000
Magnus Westerlund has entered the following ballot position for draft-ietf-lpwan-coap-static-context-hc-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lpwan-coap-static-context-hc/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Reviewing this document and its application to compress case two and three stacks in Figure 1, i.e. with some end-to-end encryption appears to significantly change an assumption from the SCHC for IPv6/UDP. Namely, the assumption about context establishment. In normal SCHC the contexts are established between the Device and the NGW. In these end-to-end encrypted case the context establishing party for the COAP compression is the APP and the APP layer in the device. This difference appear completely ignored in this document. I think this is a significant difference as having the device and NGW run a protocol for establishing context over the L2 or L3 with the local context knowledge is fairly straightforward. However, in this case when the COAP peer on the internet side of the NGW this determination and configuration is a different matter. >From my perspective some more discussion of the fact that this is a different context and that it have different challenges in establishing the context should be made clear in the document. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I would also note that the TSV-ART review did find an issue with the an underlying assumption in draft-ietf-lpwan-ipv6-static-context-hc which is not yet published. The issue is that the assumption that the UDP length field is redundant will not be true when https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ gets approved. Thus the question arises if this assumption should be amended or not in the underlying technology. I note this here primarily so that it is discussed by the WG and the responsible AD.
- [lp-wan] Magnus Westerlund's Discuss on draft-iet… Magnus Westerlund via Datatracker
- Re: [lp-wan] Magnus Westerlund's Discuss on draft… Ana Minaburo
- Re: [lp-wan] Magnus Westerlund's Discuss on draft… Magnus Westerlund
- Re: [lp-wan] Magnus Westerlund's Discuss on draft… Ana Minaburo
- Re: [lp-wan] Magnus Westerlund's Discuss on draft… Magnus Westerlund