[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.