[core] Benjamin Kaduk's No Objection on draft-ietf-core-senml-versions-03: (with COMMENT)

Benjamin Kaduk via Datatracker <noreply@ietf.org> Wed, 02 June 2021 18:11 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: core@ietf.org
Delivered-To: core@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BCFE93A155A; Wed, 2 Jun 2021 11:11:20 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-core-senml-versions@ietf.org, core-chairs@ietf.org, core@ietf.org, jaime@iki.fi, jaime@iki.fi
X-Test-IDTracker: no
X-IETF-IDTracker: 7.30.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <162265748074.13521.4368551591199171477@ietfa.amsl.com>
Date: Wed, 02 Jun 2021 11:11:20 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/YRkdzWlXWQTvsyOlu1ZCj6xEha8>
Subject: [core] Benjamin Kaduk's No Objection on draft-ietf-core-senml-versions-03: (with COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Jun 2021 18:11:21 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-core-senml-versions-03: No Objection

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 DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


Thanks, this is nicely written and a reasonable approach.

Section 3

I think I'm supposed to interpret this as being "the exact bit pattern
1010 in the last four bits indicates support for the base SenML version
defined in RFC 8428; any other bitstring in that position cannot be
taken as an indication of support for the base version".  In other
words, we're still getting a one-bit signal, just encoded in four bits.
Is that right?  Or maybe just "it's an error to see any other values for
those four bits"?  (If so, do we reject the entire pack?)

Section 5

I'd consider adding a sentence "the assignment of new feature bits is
done in a backwards-compatible manner, so existing implementations will
not erroneously assume support for a version (feature) that is defined
in the future" in the vein of an avoided security consideration.