[Gen-art] Genart last call review of draft-kucherawy-rfc8478bis-03

Joel Halpern via Datatracker <noreply@ietf.org> Fri, 27 December 2019 01:16 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: gen-art@ietf.org
Delivered-To: gen-art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA9712009C; Thu, 26 Dec 2019 17:16:48 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Joel Halpern via Datatracker <noreply@ietf.org>
To: <gen-art@ietf.org>
Cc: last-call@ietf.org, draft-kucherawy-rfc8478bis.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.115.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Joel Halpern <jmh@joelhalpern.com>
Message-ID: <157740940842.25212.10128806838650474998@ietfa.amsl.com>
Date: Thu, 26 Dec 2019 17:16:48 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/IbpUNAKfFvPKx_iLlCpQngmTU-c>
Subject: [Gen-art] Genart last call review of draft-kucherawy-rfc8478bis-03
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Dec 2019 01:16:49 -0000

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.

For more information, please see the FAQ at


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?