Elwyn, thanks for your review. Carsten, thanks for addressing Elwyn’s comments. I entered a No Objection ballot.
Alissa > On Sep 25, 2019, at 10:55 AM, Carsten Bormann <c...@tzi.org> wrote: > > Hi Elwyn, > > thank you for these comments. > These are now addressed in the editor’s copy on github, specifically in > https://github.com/cbor-wg/array-tags/commit/f63c0301c481ab773c16b96a9b0eb63456554049 > > <https://github.com/cbor-wg/array-tags/commit/f63c0301c481ab773c16b96a9b0eb63456554049> > Details below. > >> On Sep 6, 2019, at 21:33, Elwyn Davies via Datatracker <nore...@ietf.org> >> wrote: >> >> Reviewer: Elwyn Davies >> Review result: Ready with Nits >> >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair. Please treat these comments just >> like any other last call comments. >> >> For more information, please see the FAQ at >> >> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. >> >> Document: draft-ietf-cbor-array-tags-07 >> Reviewer: Elwyn Davies >> Review Date: 2019-09-06 >> IETF LC End Date: 2019-09-05 >> IESG Telechat date: Not scheduled for a telechat >> >> Summary: >> Ready with a couple of nits. Apologies for slightly late delivery. >> >> Major issues: >> None >> >> Minor issues: >> None >> >> Nits/editorial comments: >> s1, para 2: s/have received/has received/ >> >> s1, para 3: s/This also can/This can also/ >> >> s1.1, last para: s/whether that/as to whether that/ > > I put these in (oops, missed one, now in > https://github.com/cbor-wg/array-tags/commit/4490e8b6f9f157779783f645c2c4ee6f9e749f74 > > <https://github.com/cbor-wg/array-tags/commit/4490e8b6f9f157779783f645c2c4ee6f9e749f74> > ). > >> >> s2.1, 2nd para after Table 2 (top of page 5): >> OLD: >> It can be computed >> inversely to the previous formula from the length of the byte string >> in bytes: "bytelength >> (f + ll)". >> NEW: >> It can be computed from the length of the byte string comprising the >> representation of the array by inverting the previous formula: >> "bytelength >>>> (f + ll)". >> ENDS > > This misses the “in bytes”, which may be obvious to many, but should be said. > Now: > > It can be > computed from the length, in bytes, of the byte string comprising the > representation of the array by inverting the previous formula: > `bytelength >> (f + ll)`. > >> s2.1: The terms endianness, big endian and litle endian are jargon, if pretty >> well known jargon, but I don't know if they are considered to be adequately >> well understood to avoid the need for a reference or an explanation of what >> is >> meant. > > Very good point; we sometimes get too mired in our jargon. > > Now at the end of the terminology section: > > The terms "big endian" and "little endian" are used to indicate a most > significant byte first (MSB first) representation of integers, and a > least significant byte first (LSB first) representation, respectively. > > I think we can tolerate the one occurrence of “endianness” before that, as > that is just in a list of examples. > > Grüße, Carsten > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org <mailto:Gen-art@ietf.org> > https://www.ietf.org/mailman/listinfo/gen-art > <https://www.ietf.org/mailman/listinfo/gen-art>
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art