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

[Carsten Bormann <[e-mail]>]

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 <[e-mail]> 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).
> 
> *** 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
> 
>