[Cellar] Sample draft for updating RFC 8794

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Sat, 19 June 2021 17:19 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: cellar@ietfa.amsl.com
Delivered-To: cellar@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 2EFFB3A196C for <cellar@ietfa.amsl.com>; Sat, 19 Jun 2021 10:19:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 6WnjhQOOTbwL for <cellar@ietfa.amsl.com>; Sat, 19 Jun 2021 10:18:59 -0700 (PDT)
Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 18EF63A196E for <cellar@ietf.org>; Sat, 19 Jun 2021 10:18:58 -0700 (PDT)
Received: by mail-qk1-x733.google.com with SMTP id bj15so17585289qkb.11 for <cellar@ietf.org>; Sat, 19 Jun 2021 10:18:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=tjlXmuuTb5ziJrh2pkCtEf7FE8x4U2G9SjZ0Jdeu04M=; b=fNfuppMF1ZbyHiiQM5fWAJEszfgpVntr9m7TyvNOtKlpQJeQSScucr9r5VNdxryMas KBK4ZPDDzcvL4aCBHeI8nX4g4alLB6HbDIX12vPN9v/fC0BDpq1yJTEmKazhNAREZtff Pk9pp5afOQc/eAgk4M25bR01BgdxsuICxX6atQjtZgNQS0gJ9Cw+HuvcsYFxqqGXTiVk bTi9AdojRW5vKY3xpi1m1FbxQrE6AqnCZot+Tc663cJQLUWCjaERRC5O/TzXyE5v/Emd XYEngvnr2FH23zXhsy2ifx7joKVOG6KotKham8KAOhqF+3kyqp4jf5Rd5Ss9Zhn/q0/v 2kFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=tjlXmuuTb5ziJrh2pkCtEf7FE8x4U2G9SjZ0Jdeu04M=; b=sB7vUqCSCWwX9su5+4SWOJmJsgwqb/rYyn6QUx/g/WvVOTNv5TO+plnzsYI09hflav UTQOfJdWwPc1EMlda9q4TDs9IsDqZDngtKQi5sXRUukk441C2tiwn1oQv4ZCffDs2VR/ BT5aGcfBExM9X2WEk8Y31prjTU0kZByFqXzJC//Y1YEcphIid5ksIVVnfqZB4DVzT81U ZDhGsCjRwN7L+S6L+JEnFf30BCi6FcF1fr1Jsuw1AqaaJl8CwtNHiJgkPRd01W0CSVfv g/E3CdKrcLIiC1RTxlAz4/EozgBQc5jwOn6ctxoHARFMvZyALTr2EPo7SX/KbP34vYAG 2HzQ==
X-Gm-Message-State: AOAM5320tokMPGEE3cBtlu5fB6Rmt34G+TSMLIv7V0slmyPQGbvFh+30 iExmxXj/T9ytPX3jQlc6LJUTGerRNbaycVfDW4bAgotW0U+k4w==
X-Google-Smtp-Source: ABdhPJwLd+Ux6Dm1md/SbTV93xUB3e0qJce5V0781gyDr9UaX7RTgk/GyJ/8sRtTsYBMOq/g0irijPjB3LlD43XwN8Q=
X-Received: by 2002:a25:f446:: with SMTP id p6mr21724636ybe.288.1624123135796; Sat, 19 Jun 2021 10:18:55 -0700 (PDT)
MIME-Version: 1.0
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Sat, 19 Jun 2021 12:18:29 -0500
Message-ID: <CAKKJt-fnDpjD0-pgOrnJhc8=1DTMGfoe2=FkvpXjAWVWfyh3Ag@mail.gmail.com>
To: Codec Encoding for LossLess Archiving and Realtime transmission <cellar@ietf.org>
Cc: Murray Kucherawy <superuser@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000094a99b05c521a255"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/sB3_kx2ccVrxJoaLJBcqNzgyOKo>
Subject: [Cellar] Sample draft for updating RFC 8794
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: Sat, 19 Jun 2021 17:19:04 -0000

Dear Jerome,

I had an action after our last virtual meeting to provide a pointer to an
RFC that updated another RFC, without replacing the previous RFC.

The one I am most familiar with, is
https://www.rfc-editor.org/rfc/rfc8540.html. I was the responsible AD for
that RFC when it was printed.

Based on my experience with that RFC (details on request, but
https://datatracker.ietf.org/doc/rfc8540/ballot/ would give you some ideas),*
here's what I'm suggesting that Cellar do differently* when we are updating

   - Use something like "Extensible Binary Meta Language: Errata and
   Corrections for RFC 8794" as the title.
      - If we call this something like " Extensible Binary Meta Language:
      Corrections to RFC 8794" At some point, someone would ask about the
      relationship between the corrections in this draft and the corresponding
      errata in
      (and there aren't any), so I'd avoid the use of the term
"errata" anywhere
      in this draft in this draft.
      - I'd make clear early in this draft where these errors WERE reported
      to the working group - is it correct that they were all raised as issues
      in ietf-wg-cellar/ebml-specification?
   - Target standards-track, not Informational, so that this draft can
   update RFC 8794, which is also standards-track, and include "Updates: 8794"
   as part of the document header.
   - Use a three-part format for each correction - "text in RFC 8794",
   "what's incorrect or unclear in that text", and "replacement text for RFC
   8794". If you include the strings "OLD" and "NEW" in front of the original
   text and replacement text, everyone will understand what you're doing.

If you'd like for me to take a look at a rough outline for this draft
before you start chewing on it in earnest, I'm happy to do that.

When you've got a rough outline, please let me/Michael know - we will want
to create a milestone for this draft in the datatracker, with an estimated
date, and ask Murray to approve it.

If this draft turns out to contain more than 8-10 corrections, we'll be
talking seriously with our AD about whether making the changes in a
replacement for RFC 8794 would be more appropriate, but we can trip over
that boulder if we get to it.

Does that make sense to you (and to the working group)?