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

John C Klensin <john-ietf@jck.com> Mon, 08 April 2024 16:37 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: jmap@ietfa.amsl.com
Delivered-To: jmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C15C151545; Mon, 8 Apr 2024 09:37: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 aK8p1PqDjrYd; Mon, 8 Apr 2024 09:37:42 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DF65C151090; Mon, 8 Apr 2024 09:37:41 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1rtrzu-0008tX-UZ; Mon, 08 Apr 2024 12:37:30 -0400
Date: Mon, 08 Apr 2024 12:37:24 -0400
From: John C Klensin <john-ietf@jck.com>
To: Carsten Bormann <cabo@tzi.org>
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
Message-ID: <C7BD794D4CA959AAE6EF9EA4@PSB>
In-Reply-To: <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> <BBAD5203-3C97-42CF-91B7-3795F495F9DE@tzi.org>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/LtMIUS1QoZxXuPCetLCcMw630Uo>
Subject: Re: [Jmap] [art] [Last-Call] Artart last call review of draft-ietf-jmap-contacts-06
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: JSON Message Access Protocol <jmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jmap>, <mailto:jmap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jmap/>
List-Post: <mailto:jmap@ietf.org>
List-Help: <mailto:jmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jmap>, <mailto:jmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Apr 2024 16:37:43 -0000


--On Monday, April 8, 2024 16:16 +0200 Carsten Bormann <cabo@tzi.org>
wrote:

> 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.

As I think I said earlier in this thread, I don't have any problem
with that but believe that an IETF specification, especially a
standards track one, should (must?) be clear about those connections.
I hope that does not need any new formalism: a few sentences that
explain the relationships, why they dictated certain provisions of
the IETF spec, and, preferably, where people should go if they
disagree with those external specifications would be more than
adequate.  

best,
   john