[lp-wan] Iotdir last call review of draft-ietf-lpwan-coap-static-context-hc-11

Stephen Farrell via Datatracker <noreply@ietf.org> Fri, 29 November 2019 15:23 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 6A7D81201DC; Fri, 29 Nov 2019 07:23:07 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stephen Farrell via Datatracker <noreply@ietf.org>
To: Iot-dir@ietf.org
Cc: lp-wan@ietf.org, last-call@ietf.org, draft-ietf-lpwan-coap-static-context-hc.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.111.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Message-ID: <157504098736.4738.369701137511782310@ietfa.amsl.com>
Date: Fri, 29 Nov 2019 07:23:07 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/lp-wan/ATO4OYEQs0Oa21ceGte-eo3MF8I>
Subject: [lp-wan] Iotdir last call review of draft-ietf-lpwan-coap-static-context-hc-11
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: Fri, 29 Nov 2019 15:23:07 -0000

Reviewer: Stephen Farrell
Review result: Almost Ready

Hiya,

I noted only one issue that might need fixing:

- If two entities are using this scheme and have an agreed set of 
  rules, don't you need to say that packets that don't match any
  rule(s) should be sent unmodified?

I also noticed a couple of nits:

- Intro: "There is no risk to lock a device in a particular version
  of CoAP." I'm not fully sure what that's trying to say but a) "no
  risk" is a major claim that's not justified:-) and b) SCHC (by 
  design) does inherently risk being less effective if protocols or
  patterns of protocol usage change.  I'd say just delete the
  sentence.

- section 2: "SCHC C/D" is used without being defined.

- 7.2: Typo: "The Inner Plaintext contains sensible information 
  which is not necessary for proxy operation." s/sensible/sensitive/
  I guess.