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 <c...@fb.com> 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" <nore...@ietf.org> 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
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Reply via email to