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

From: Carsten Bormann <[email-masked]>
Date: Thu, 4 Feb 2021 05:47:39 +0100

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).

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

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

# 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”?

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

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 22 Feb 2021 15:27:56 +0100

Please note an interesting discussion over at netmod.

Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Yj7KvGvXlekWxKlu4JgqwXssIBM> and up.

It seems we a converging to a conclusion that means that the table at the top of page 14 in draft-ietf-core-comi-11.txt [1] is not wrong (it would make certain updates of a YANG module a non-backwards compatible change in the way we build URIs from that).

[1]: https://tools.ietf.org/html/draft-ietf-core-comi-11#page-14

That said, maybe we still want to look at why uint and int coding are so (unnecessarily?) different in their URL encodings.

Grüße, Carsten

> On 2021-02-04, at 05:47, Carsten Bormann <[email-masked]> wrote:
>

---

From: Ivaylo Petrov <[email-masked]>
Date: Sun, 28 Feb 2021 23:09:05 +0100

Hello Carsten,

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

Best regards,
Ivaylo

>     (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.

>     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.

>      Should it rather specify a single "A”?

[IP]: That sounds good to me.

>      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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Ivaylo Petrov <[email-masked]>
Date: Sun, 28 Feb 2021 23:09:25 +0100

Hello Carsten,

Best regards,
Ivaylo

> That said, maybe we still want to look at why uint and int coding are so (unnecessarily?) different in their URL encodings.

[IP]: It sounds better to me to harmonize this. I will try to see if
any of the other authors have specific reasons not to do that.

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 28 Feb 2021 23:26:03 +0100

> issue, that probably it is better not mentioning it at all.

I think my point was that this is a set of problems that all applications that use block-wise transfer have.  RFC 7959 has some brief guidance in its section 7.1, but I agree that a more extensive treatment should be written up.
Just not here…

I believe there should not be a section 5, and the one sentence or so that points out the issue can maybe merged with the item down below.

> or can you think of better options.

Resource-directory actually went ahead and put in a basic form of pagination.

But, again, this is a general YANG problem, and we should defer to that being solved for YANG, e.g., as in
https://tools.ietf.org/html/draft-wwlh-netconf-list-pagination-nc-01 (*)
Putting in a SHOULD for something that isn’t defined yet is not the right approach here, but we could very well mention that future additions to YANG/*CONF for pagination could be used to mitigate the problem.

Grüße, Carsten

(*) Does anyone know what happened to this draft?