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

Robert Wilton via Datatracker <noreply@ietf.org> Wed, 02 June 2021 09:59 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 B801A3A3D2F; Wed, 2 Jun 2021 02:59:37 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Robert Wilton 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: Robert Wilton <rwilton@cisco.com>
Message-ID: <162262797725.18003.2285062248812997933@ietfa.amsl.com>
Date: Wed, 02 Jun 2021 02:59:37 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/XwTbwKbLLiT7mLBV0HpA8yEldt0>
Subject: [core] Robert Wilton'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 09:59:38 -0000

Robert Wilton 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:
https://datatracker.ietf.org/doc/draft-ietf-core-senml-versions/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi,

Thanks for the this document.   Just a couple of minor comments.

It looked like the equation in section 2 was mucked up in the text version of
the doc.  Presumably this will get fixed during the editing process:

I.e.,
              __ 52                       fc
   version = \         present(fc)&nbsp;⋅&nbsp;2
             /__ fc = 0

   Quantitatively, the expert could for instance steer the allocation to
   not allocate more than 10 % of the remaining set per year.

Rather than setting this is a limit, I would suggest that it is better to set
this as a target.  E.g., if it turns out that there is a good justification for
an extension, it would be a shame if it had to be delayed by a year merely to
fit into a somewhat arbitrary rate limiting scheme.

Besides, if you end up with 53 different optional extensions, then I suspect
that the bigger problem will be that there are too many variants of what is
supported by different implementations which will reduce interop, and you'll
probably want to end up with batches of extensions that are expected to be
supported together, i.e., some sort of hybrid between completely independent
extensions and a strict linear version scheme.

Rob