[Cellar] auth48 coordination of XML files

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 12 June 2021 15:33 UTC

Return-Path: <mcr@sandelman.ca>
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 F17973A173B for <cellar@ietfa.amsl.com>; Sat, 12 Jun 2021 08:33:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id o04qLi6RzQ_4 for <cellar@ietfa.amsl.com>; Sat, 12 Jun 2021 08:33:38 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 267203A14D2 for <cellar@ietf.org>; Sat, 12 Jun 2021 08:33:38 -0700 (PDT)
Received: from dooku.sandelman.ca (unknown []) by relay.sandelman.ca (Postfix) with ESMTPS id C60E41F47B; Sat, 12 Jun 2021 15:33:36 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 746AD1A0D1B; Sat, 12 Jun 2021 11:33:35 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Dave Rice <dave@dericed.com>, cellar@ietf.org
In-reply-to: <E2E55F81-2DA6-4776-BCA6-AF66A59EF725@dericed.com>
References: <31695.1623507191@dooku> <E2E55F81-2DA6-4776-BCA6-AF66A59EF725@dericed.com>
Comments: In-reply-to Dave Rice <dave@dericed.com> message dated "Sat, 12 Jun 2021 10:24:34 -0400."
X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Sat, 12 Jun 2021 11:33:35 -0400
Message-ID: <34407.1623512015@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/NQVTKEVKB33ozi7Fbk9wMkGP5ho>
Subject: [Cellar] auth48 coordination of XML files
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, 12 Jun 2021 15:33:43 -0000

Dave Rice <dave@dericed.com> wrote:
    >>>> So I think you might be working too hard here.
    >>> Could you clarify: is it the work itself or the efficiency of the work
    >>> that you’re commenting upon?
    >> efficiency: I think that you might be causing yourself undo pain.

    > Mind if we move this conversation back on list?I’m happy to step back
    > from this but would prefer this conversation occur with the other
    > authors.

The RFC editor has FFV1 in AUTH48.  They have edited our *XML* directly to
put it into their format, which ignores our history of creating it via mmark
and some of the table driven efforts.

Dave seemed to trying to bring our XML (via mmark) into sync with what the
RFC-editor was doing.  I worried that Dave was expending a lot of effort

Most WGs do not attempt to bring their "source" code inline with what the
RFC-editor produces.  The XML goes into the RFC-editor, and is transformed,
and that's that.
For WGs that have edited in XML, one can get the XML from from the rfc-editor
at the end, and just go with that if one will do a "bis" in a few years.

Dave pointed out that the things that the editor was doing would also apply
to ffv1-v4!  Ah, I say, GOOD POINT.

    >> Most drafts, once they are with the RFC editor, are no longer maintained in
    >> git.  (although i've argued that the rfc-editor should be sending a pull
    >> request back to authors, that isn't happening yet).

    > I would like some consensus on this. We’ve been working with a shared
    > base for the two documents nearly back to the working groups origins.

I would say that at this point, the ffv1 (not-v4) direction is dead.
We shouldn't think that we can make changes that matter to that direction.

]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [