Re: [Cellar] Genart last call review of draft-ietf-cellar-ffv1-16

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Thu, 16 July 2020 15:18 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: cellar@ietfa.amsl.com
Delivered-To: cellar@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 614F93A0AC2; Thu, 16 Jul 2020 08:18:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVcXEhTIH4Dk; Thu, 16 Jul 2020 08:18:00 -0700 (PDT)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80D553A0AC1; Thu, 16 Jul 2020 08:18:00 -0700 (PDT)
Received: by mail-lf1-x12f.google.com with SMTP id o4so3570396lfi.7; Thu, 16 Jul 2020 08:18:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XUrK4p3B5xvhkEZqzGwJvecpmfrTbToXuTKF7cZK3iI=; b=OWcVpXHpqsK1wTsse9cQ9/Zfz4adxQCbdSeY4bQLSfJ/XWc31XFs6kNbr3SwyQwLum I2Iqscb7A9sr9HNzkL5A6XZ0VGOfZghcC2iuC5DieHDcqiIJTqD7oMlSij65QzfDS7qN 7Ke+Y/jdbrFFCxq/CAcJzx5FQFy3ZZrWrzvLr/BtGBHL7jy8ymfO0JsdywywooMJEYGD 33UdvHqIvzkHgJNoEMSmhHRcWF5WwiHUFJ9GrkPBn2xBBvF4spGTOVQwpTwRy+KJuHKp 5KOJF45BjbfIUwf3AyW8yNIwxb1CUV2B8PuzneLquBYChjqlLtx4PuWnZV9mQ8Us6gHH AscQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XUrK4p3B5xvhkEZqzGwJvecpmfrTbToXuTKF7cZK3iI=; b=gYtsozRIMdF0xFDuH6Cx6eJe+KIHi/+XYtmUodE6K1JMAlFHwM1+0v642mvxMAEaI7 9T6mQDprwcuXEl7a1ZqFCOTB3a68hgQLvNtqxxwt+5fW0rjZwAtr/bcAU40hjK/ykedm gW46XCsKiDlzUpR6RxPP2w8LPQz2coYtq7Hpz/fZTnGLpP1myMD1IuUQQz6RMH4xoP5H YVRXGC+dK/Ta8pzuyuazV2wER4GB2BuClgvfGsKUneehOVA6AQBfmDD0VLZ9KLRf/Fdd /bFmwEaDDrqonNaG/sloR4MN40JoFZBv3gkCa4AjwXmh1JFPxXYD4+LCwbaOXIXUb38/ lFvA==
X-Gm-Message-State: AOAM532VfoZcbGG7YZYFS8yXTzoEPw58xshNnk9IFz9CdNgOE/oO4jW4 59S/gxVuDd+tICaw9aaiXJqCW1um1C44KoxZxp4FBg==
X-Google-Smtp-Source: ABdhPJxektFbtjV2LjiSBOBXbz+q0ThksuS0Z/qCA+JPjON4vN7oVlxVl+j2fN9O3HPsInFgjYEnvox7pUAakyAOQ5Y=
X-Received: by 2002:ac2:5f6d:: with SMTP id c13mr2314806lfc.53.1594912678537; Thu, 16 Jul 2020 08:17:58 -0700 (PDT)
MIME-Version: 1.0
References: <159470027331.24170.16229303627582288772@ietfa.amsl.com>
In-Reply-To: <159470027331.24170.16229303627582288772@ietfa.amsl.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Thu, 16 Jul 2020 10:17:32 -0500
Message-ID: <CAKKJt-diqzeNh1jw8M+GKYRWX_1g73LH1tDpQTSW40W1K8bF1Q@mail.gmail.com>
To: Joel Halpern <jmh@joelhalpern.com>
Cc: gen-art <gen-art@ietf.org>, Codec Encoding for LossLess Archiving and Realtime transmission <cellar@ietf.org>, last-call@ietf.org, draft-ietf-cellar-ffv1.all@ietf.org
Content-Type: multipart/alternative; boundary="000000000000a6eea605aa908b6f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/KsBrTcVwnyVGuSrVAXXyeWjliuU>
Subject: Re: [Cellar] Genart last call review of draft-ietf-cellar-ffv1-16
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Codec Encoding for LossLess Archiving and Realtime transmission <cellar.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cellar>, <mailto:cellar-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cellar/>
List-Post: <mailto:cellar@ietf.org>
List-Help: <mailto:cellar-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cellar>, <mailto:cellar-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jul 2020 15:18:02 -0000

Hi, Joel,

On Mon, Jul 13, 2020 at 11:17 PM Joel Halpern via Datatracker <
noreply@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.
>
> For more information, please see the FAQ at
>
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>
> Document: draft-ietf-cellar-ffv1-16
> Reviewer: Joel Halpern
> Review Date: 2020-07-13
> IETF LC End Date: 2020-07-16
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: This document appears to be ready for publication as an
> Informational
> RFC.
>
> *I would have raised question about the intended status, but it appears
> that
> this is an established IETF convention and I see no reason to argue.)
>
> Major issues:
>
> Minor issues:
>     Section 3.4 (Context) introduces the notation Q_{#}[ subscript }.  As
> that
>     is the first reference to Q_{#}, it is rather confusing to the
> reader.  I
>     grant that the term is defined in the next section (3.5).  Couldn't
> they be
>     reversed?
>
>     Section 3.8.1.1 refers to C(i), C_{i}, and C_i.  Are these all the same
>     thing.
>
>     Section 3.8.1.2 refers to get-rac (which is treated as a function in
> the
>     pseudo-code) as being the process described in section 3.8.1.1.  The
> text
>     in 3.8.1.1 does not call out any of its computed values as an explicit
>     result or return.  While I would guess that the intention is to use the
>     byte stream (B()), the text does not actually say that.  If that is the
>     intention, could the last line of 3.8.1.1 be "get_rac() returns
> sequential
>     bytes from the Byte Stream (B()) as computed by the computation
> described
>     in section 3.8.1.1"?
>
> Nits/editorial comments:
>

Thanks for the review! We'll work through these comments.

Best,

Spencer