IETF Logo Mail Archive

Re: [Cellar] Robert Wilton's No Objection on draft-ietf-cellar-ffv1-17: (with COMMENT)

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 07 October 2020 18:39 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 F128E3A0F55; Wed, 7 Oct 2020 11:39:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 YDo79YgNDY0n; Wed, 7 Oct 2020 11:39:46 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A1613A0F50; Wed, 7 Oct 2020 11:39:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 0355A389E2; Wed, 7 Oct 2020 14:45:09 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id oy79imdXhr-G; Wed, 7 Oct 2020 14:45:08 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id F3721389C9; Wed, 7 Oct 2020 14:45:07 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 305EBF5; Wed, 7 Oct 2020 14:39:44 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Robert Wilton <rwilton@cisco.com>, The IESG <iesg@ietf.org>, draft-ietf-cellar-ffv1@ietf.org, cellar-chairs@ietf.org, Codec Encoding for LossLess Archiving and Realtime transmission <cellar@ietf.org>, "Peter B." <pb@das-werkstatt.com>
In-Reply-To: <CAKKJt-de6NfAFTv6GQQ6f=PfX7cQuCJY2nzgx98+mvA2zX02hg@mail.gmail.com>
References: <160190967658.31262.3611106747790904168@ietfa.amsl.com> <61aa6a30-a10a-0460-dbcb-aace9936a468@mediaarea.net> <CAKKJt-de6NfAFTv6GQQ6f=PfX7cQuCJY2nzgx98+mvA2zX02hg@mail.gmail.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Wed, 07 Oct 2020 14:39:44 -0400
Message-ID: <18667.1602095984@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/oe5Mfpl_Q-6EX_E2VAzs3R_mfLQ>
Subject: Re: [Cellar] Robert Wilton's No Objection on draft-ietf-cellar-ffv1-17: (with COMMENT)
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: Wed, 07 Oct 2020 18:39:49 -0000

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
    > Questions of what's obsoleted, or declared Historic, or otherwise done
    > to FFV1 version 0, 1 and 3, would be decided by the working group, AD,
    > and IESG when FFV1 version 4 is in IESG Evaluation, I think?

I understood that FFV1 version 0/1/3 was Informational.
I guess it could be marked Historic by the IESG at some point.
I didn't think that time would be when FFV1 v4 was published, but sure.

I thought that this was even in our charter somewhere, so I'm confused by
this thread.

This follows the pattern of publishing an RFC that is not within IETF
revision control that documents "current practice", and then publishing an
RFC on standards track, that is within IETF revision control.

Here "revision control" means we can change the bits-in-the-wire
(or in the file) in incompatible ways.


--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

v2.23.0 | Report a Bug | By Email