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 protected]> 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 > > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
