Re: [core] Lars Eggert's No Objection on draft-ietf-core-senml-versions-03: (with COMMENT)

Carsten Bormann <cabo@tzi.org> Wed, 26 May 2021 14:14 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9983A2FE1; Wed, 26 May 2021 07:14:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_FAIL=0.001, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJliN-sDEA1y; Wed, 26 May 2021 07:14:14 -0700 (PDT)
Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [IPv6:2001:638:708:32::19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 455933A2FE4; Wed, 26 May 2021 07:14:14 -0700 (PDT)
Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4FqtH71PT9z316N; Wed, 26 May 2021 16:14:11 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <162203242344.29582.10148358869813812866@ietfa.amsl.com>
Date: Wed, 26 May 2021 16:14:10 +0200
Cc: The IESG <iesg@ietf.org>, draft-ietf-core-senml-versions@ietf.org, core-chairs@ietf.org, "core@ietf.org WG" <core@ietf.org>, jaime@iki.fi
X-Mao-Original-Outgoing-Id: 643731250.333391-7806e01e61e1bdee4c70be78c1e44b67
Content-Transfer-Encoding: quoted-printable
Message-Id: <BC5B034D-DB53-480A-B6A6-C9C7F1FFCA0E@tzi.org>
References: <162203242344.29582.10148358869813812866@ietfa.amsl.com>
To: Lars Eggert <lars@eggert.org>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/S1AlW-LkPGaiFiCpPzkRKOVa9MM>
Subject: Re: [core] Lars Eggert's No Objection on draft-ietf-core-senml-versions-03: (with COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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, 26 May 2021 14:14:19 -0000

Hi Lars,

thank you for these details!

> On 2021-05-26, at 14:33, Lars Eggert via Datatracker <noreply@ietf.org> wrote:
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Section 7.1, paragraph 4, comment:
>>   [IANA.senml]
>>              IANA, "Sensor Measurement Lists (SenML)",
>>              <http://www.iana.org/assignments/senml>.
> 
> Not sure if a normative reference to an IANA registry page is technically OK; it
> should probably cite the RFC that created that registry instead, and maybe add
> an informative reference to the registry page?

I find dozens of recent RFCs with normative references to IANA registries, and I do believe this practice is both OK and makes a lot of sense (in particular for registries like the present one that have been set up successively over time in multiple RFCs — even if those RFCs are also being references normatively, as they are here).
If you think we should change this practice, I think some guidance by the IESG would be useful.

The nits are fixed in the editor copy; except for the http:// URI — I have written a note to tools-discuss about the generation of http:// URIs in bibxml8.

Grüße, Carsten


> 
> -------------------------------------------------------------------------------
> All comments below are about very minor potential issues that you may choose to
> address in some way - or ignore - as you see fit. Some were flagged by
> automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
> will likely be some false positives. There is no need to let me know what you
> did with these suggestions.
> 
> Section 2.1, paragraph 4, nit:
> -    decimal numbers, e.g. 26 (0b11010, 0x1a) for a version that adds the
> +    decimal numbers, e.g., 26 (0b11010, 0x1a) for a version that adds the
> +                         +
> 
> The text version of this document contains these HTML entities, which might
> indicate issues with its XML source: &nbsp;
> 
> Section 1, paragraph 2, nit:
>> es additional features over time. However in the case of SenML it is expecte
>>                                  ^^^^^^^
> Did you forget a comma after a conjunctive/linking adverb?
> 
> Section 3, paragraph 2, nit:
>> secondary unit names [RFC8798] MAY be be used in the "u" field of SenML Reco
>>                                    ^^^^^
> Possible typo: you repeated a word
> 
> These URLs in the document can probably be converted to HTTPS:
> * http://www.iana.org/assignments/senml
> 
> 
>