IETF Logo Mail Archive

Re: [Last-Call] [art] Artart last call review of draft-ietf-jmap-contacts-06

Carsten Bormann <cabo@tzi.org> Mon, 08 April 2024 14:16 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E0EC14CE24; Mon, 8 Apr 2024 07:16:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ddQbWjPazXi; Mon, 8 Apr 2024 07:16:38 -0700 (PDT)
Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19F46C14F5E8; Mon, 8 Apr 2024 07:16:34 -0700 (PDT)
Received: from smtpclient.apple (p5089a101.dip0.t-ipconnect.de [80.137.161.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4VCrk75HPszDCj5; Mon, 8 Apr 2024 16:16:31 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <48ACBF0C07D869A2B7CE1151@PSB>
Date: Mon, 08 Apr 2024 16:16:20 +0200
Cc: Bron Gondwana <brong=40fastmailteam.com@dmarc.ietf.org>, Peter Saint-Andre <stpeter@stpeter.im>, art@ietf.org, draft-ietf-jmap-contacts.all@ietf.org, IETF JMAP Mailing List <jmap@ietf.org>, last-call@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <BBAD5203-3C97-42CF-91B7-3795F495F9DE@tzi.org>
References: <171112316193.8644.5801107423421446407@ietfa.amsl.com> <1C02FE5D-624B-4BBE-A7F3-91EDF54CDE4F@tzi.org> <b5fac088-9eb3-4ede-a266-f943aeaab076@stpeter.im> <4E9A8148-9EFE-4448-B94E-96FBDB6A2B9A@tzi.org> <06c317c8-8d14-4d78-a4c9-9c44cfc3ec31@stpeter.im> <03ef2b74-19d2-43c1-9c5b-b0aa315c8738@dogfoodapp.fastmail.com> <5c10be7c-8913-46f5-a0bd-e28102624d88@stpeter.im> <C42C278BC5CB8F3EE2920E99@PSB> <521b092a-6490-4fe2-9126-961335a1892b@stpeter.im> <94FE04C6853F55BF4B1C1FFB@PSB> <58438804-1a10-4a86-8f87-d449c0db542a@betaapp.fastmail.com> <407F5BC2-BEFE-4F6B-872D-FB31934740A3@tzi.org> <48ACBF0C07D869A2B7CE1151@PSB>
To: John C Klensin <john-ietf@jck.com>
X-Mailer: Apple Mail (2.3774.500.171.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/MdI1BZFMi8sSyXzb5vDCt89lbGU>
Subject: Re: [Last-Call] [art] Artart last call review of draft-ietf-jmap-contacts-06
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Apr 2024 14:16:43 -0000

On 8. Apr 2024, at 15:56, John C Klensin <john-ietf@jck.com> wrote:
> 
> I think Bron covered the more substantive part of this but it seems
> to me that, if our model is that AD review after publication is
> requested followed by IETF Last Call are actually the first points at
> which we expect the IESG and the broader community to carefully
> review the document, this is no such thing as a too-heavy late change
> if those reviews spot a non-trivial deficiency or other problem. 

I wasn’t talking about this particular document (which indeed needs to be under IETF change control), but about the stack of documents derived from other documents which were derived from a third document describing a thriving ecosystem.
Significant fundamental new work cannot be started locally in one of the multi-level-derived documents, but must be scoped so it is beneficial for the entire ecosystem.

Grüße, Carsten

v2.23.0 | Report a Bug | By Email