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
- [core] draft-ietf-core-comi-11 shepherd review Carsten Bormann
- Re: [core] draft-ietf-core-comi-11 shepherd review Carsten Bormann
- Re: [core] draft-ietf-core-comi-11 shepherd review Ivaylo Petrov
- Re: [core] draft-ietf-core-comi-11 shepherd review Ivaylo Petrov
- Re: [core] draft-ietf-core-comi-11 shepherd review Carsten Bormann