Subject: Re: [Last-Call] [Gen-art] Genart last call review of draft-kucherawy-rfc8478bis-03

From: Alissa Cooper <[email-masked]>
Date: Wed, 19 Feb 2020 23:58:32 -0500

Joel, thanks for your review. Yann, thanks for your response. I entered a No Objection ballot. One comment below.

> On Dec 30, 2019, at 2:19 PM, Yann Collet <[email-masked]> wrote:
> 
>> I assume that the "last block" flag is the least significant bit of the first byte of the block header?  
> 
> Yes, this is correct
> 
>> And Literals_Block_Type is the least significant two bits of the first byte of the Literals_Section_Header?
> 
> Yes, this is correct too.
> 
>> Should this be stated more explicitly? 
> 
> In both cases, the bitfield is preceded by the mention "little-endian" :
> 
> - " Block_Header uses 3 bytes, written using little-endian convention. It contains 3 fields "
> - Literals_Section_Header: "It's a byte-aligned variable-size bitfield, ranging from 1 to 5 bytes, using little-endian convention."
> 
> "Little-endian" was presumed a "good enough" indication that the first byte is the lowest one.
> After that, the "lowest bit" becomes the least significant bit of the first byte.
> 
> Nevertheless, if this is deemed not clear enough, 
> some additional statement could be added to make the specification more explicit.

I think this is clear enough in the spec.

Thanks,
Alissa

> 
> 
> 
> On 12/26/19, 17:16, "Joel Halpern via Datatracker" <[email-masked]> wrote:
> 
>    Reviewer: Joel Halpern
>    Review result: Ready
> 
>    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.
> 
>    Document: draft-kucherawy-rfc8478bis-03
>    Reviewer: Joel Halpern
>    Review Date: 2019-12-26
>    IETF LC End Date: 2020-01-17
>    IESG Telechat date: Not scheduled for a telechat
> 
>    Summary: This review primarily focused on the differences, which seem
>    appropriate, from the RFC.
> 
>    Major issues: N/A
> 
>    Minor issues: N/A
> 
>    Nits/editorial comments:
>        I presume that bits within a byte are still interpreted in the normal
>        fashions since we do not work in terms of the serialization of bits on a
>        wire, and in fact different wires may do it differently.  This does leave
>        the question of how bit fields are interpreted when they describe bits
>        within a byte.  Thus, I assume that the "last block" flag is the least
>        significant bit of the first byte of the block header?  And
>        Literals_Block_Type is the least significant two bits of the first byte of
>        the Literals_Section_Header?  (I presume that the use of little-endian
>        encoding is due to existing practice, and therefore presume it is what this
>        needs to describe.)   Should this be stated more explicitly?
> 
> 
> 
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art