Re: [core] draft-ietf-core-comi-11 shepherd review

Ivaylo Petrov <ivaylo@ackl.io> Sun, 28 February 2021 22:09 UTC

Return-Path: <ivaylo@ackl.io>
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 E870D3A086E for <core@ietfa.amsl.com>; Sun, 28 Feb 2021 14:09:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.com
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 XHyV-TKCo2u9 for <core@ietfa.amsl.com>; Sun, 28 Feb 2021 14:09:34 -0800 (PST)
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88C5F3A085E for <core@ietf.org>; Sun, 28 Feb 2021 14:09:34 -0800 (PST)
Received: by mail-wm1-x336.google.com with SMTP id u187so9900549wmg.4 for <core@ietf.org>; Sun, 28 Feb 2021 14:09:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=FP3b/Aay9AHiAJmKAl/ZkMDX1Y6QdPdWU1RtHEBxIdg=; b=UvAo4ySD6pec9eUQRr0uEtIXD7Yv4OSHpkhHLSG48kgoFe+2FNQYSV/WWtOrAac0UB YAFMZz6EJTd3UGCu+jsNXUJaezHbcgpdAxBTlrAX5HYWmFoVkLf26E/BBSc7XsiOCqfZ ebAa7ZbW+XxXQ77Tg7pER42DdOuAHtlhoB+9GkfBiLom5dr77xO4kyK1Gs+ta6wc6r/D 4Yp0ZTDzHQYRFBytELEXAiYaXsw9Tuzs684tSu/GVnEfmoh8nbHEbxg+YGchwYhrsc6K a391VjdW/v6wm5fxXPnXpC8KOmtC8zHdrbRcM0FJIHSatW2Ldr1jHR3qKyyZWVAFVa+7 P8tg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=FP3b/Aay9AHiAJmKAl/ZkMDX1Y6QdPdWU1RtHEBxIdg=; b=XGYQr8e0qhYVDOUqDgsSZ4AC/ldlaf+DBgrkzbEsMCYhszgGQP15M9vPuZnfcWPSoM EuZ9sBK8Rh4ezwQmYjQAJqIKyt3cjgi0+zTlYM7rNxU+6fORJsrrMbL1ipvPVrOSXuMW w7/xt4oirwn29P25LJIxQi3xn4roLLEdGG/n9Z4NSwBjuLvXsZ0S5+CvT3CcBSvJRSYk BFJtBSYZP2jW1clsBy310suaWHR68jRpuN/l/UvMcA7AHbkPqxHmMgDtClvrS8IHcrgJ lg+C0TnT+pe648qZX+B9Fy0S7Ct5WxRyRCBanPsVjfjm9J+vtPcSHuagj9FJahIyKndX wfAw==
X-Gm-Message-State: AOAM533neZKvTl8kr6XUNsWBFHqWx2irtLoKRa+cZS1u0ZwEI7XAzJ8g JN+pFRa53XiVLgH1ZA2JuFr3RShAiRlPr69LjWnVZw==
X-Google-Smtp-Source: ABdhPJzjOTtf40vt+XiqN/4P1n8TyC1AvksgiFauK1wpx0PpL5SmzVO2PrrtUNFWF6KSjSF5IoeZv6IVDhnN841tHqw=
X-Received: by 2002:a7b:ca50:: with SMTP id m16mr2999410wml.113.1614550171779; Sun, 28 Feb 2021 14:09:31 -0800 (PST)
MIME-Version: 1.0
References: <B981A721-73BF-4F63-8A67-3666955452DF@tzi.org>
In-Reply-To: <B981A721-73BF-4F63-8A67-3666955452DF@tzi.org>
From: Ivaylo Petrov <ivaylo@ackl.io>
Date: Sun, 28 Feb 2021 23:09:05 +0100
Message-ID: <CAJFkdRxCNnuGf8U8jq++ZYVpj0jOj3_szgw+W7mcPb2BP-F6yw@mail.gmail.com>
To: Carsten Bormann <cabo@tzi.org>
Cc: "core@ietf.org WG (core@ietf.org)" <core@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/EoiOnFCTUSrZelCn_EJ-LZcqOys>
Subject: Re: [core] draft-ietf-core-comi-11 shepherd review
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: Sun, 28 Feb 2021 22:09:37 -0000

Hello Carsten,

Thank you for your review! Please find my answers below (prefixed with [IP]).

Best regards,
Ivaylo

On Thu, Feb 4, 2021 at 5:47 AM Carsten Bormann <cabo@tzi.org> wrote:
>
> In my shepherd review of draft-ietf-core-comi-11, I have found a few points that probably need some WG action before we can submit this draft to IESG.
> (I also have submitted a PR addressing some nits, https://github.com/core-wg/comi/pull/1 .)
>
> Specifically:
>
> # Major
>
> *** 5: This whole section is rather disappointing.  What does this
>     really do except for pointing at RFC 7959?  Is there any
>     recommendation in how to work around the race condition?  The
>     recommendation to use indefinite length is not solving any problem
>     (does not work except in very fortuitous cases).

[IP]: I understand your disappointment. It appears to me that we
should try to state more clearly the issue that is being discussed and
for me there are two separate ones that are mixed. The first one is
insufficient resources to send the response. It might be insufficient
bandwidth of the network (maybe can be solved with SCHC as well) or
insufficient memory on the server. If it is the latter, I am really
not certain if that is something we should be solving.

The second issue is obtaining a snapshot of a consistent snapshot of
the state. For me we can call this out as a possible issue, but indeed
recommending indefinite length arrays solves such a small part of the
issue, that probably it is better not mentioning it at all.

> *** 6.2.2 How does the pagination work, then?
>     This SHOULD is not actionable.

[IP]: If I understand correctly your objection is that we are not
prescribing anything concrete, therefore the SHOULD is not helping in
reality. If that is the case, do you still agree that this is a
problem worth solving? If so, should we specify in more details a
mechanism (or refer to one that is already well described elsewhere),
or can you think of better options.

> *** 7: This creates confusion between 4.01 and 4.03

[IP]: I will update the text to point to 4.01 as not having valid
authentication, not as forbidden as it currently sounds.

> # Minor
>
> *** 2.2: While it is not clear whether there will be a SID 0, the text
>      seems to imply that this would be encoded in the empty string.
>      Should it rather specify a single "A”?

[IP]: That sounds good to me.

> *** Appendix A:  Updated to reference RFC 8949 (see PR).
>      Do we need a new module version after this edit?

[IP]: I don't know what are the best practices for module versions
while writing the draft. I do not object to this.

>
> Grüße, Carsten
>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core