Re: [apps-discuss] Moving ahead with draft-ietf-appsawg-mdn-3798bis

John C Klensin <john-ietf@jck.com> Thu, 04 August 2016 16:11 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B5D12B007 for <apps-discuss@ietfa.amsl.com>; Thu, 4 Aug 2016 09:11:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.187
X-Spam-Level:
X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] 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 vwNNMt1PVO3m for <apps-discuss@ietfa.amsl.com>; Thu, 4 Aug 2016 09:11:17 -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 0F9D512D5EB for <apps-discuss@ietf.org>; Thu, 4 Aug 2016 09:11:15 -0700 (PDT)
Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1bVLEm-000AV7-RK; Thu, 04 Aug 2016 12:11:12 -0400
Date: Thu, 04 Aug 2016 12:11:07 -0400
From: John C Klensin <john-ietf@jck.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <47872C0B5B5198E8126F5469@JcK-HP8200>
In-Reply-To: <bfc181aa-0086-582c-c54f-ad5820366a9e@isode.com>
References: <CAL0qLwaPNr5ptb0UGD0_TorqYRuH_6PSSwtNuQ0wGCKbDuxKgw@mail.gmail.com> <E4AA7EB24E12F5FAE7D4C50B@JcK-HP8200> <bfc181aa-0086-582c-c54f-ad5820366a9e@isode.com>
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/apps-discuss/r3Pr51Ze4kRFLUX7gs3Fesh8KHI>
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Moving ahead with draft-ietf-appsawg-mdn-3798bis
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Aug 2016 16:11:20 -0000

Alexey,

Some quick responses below (I'm on a call and about to head to a
meeting... might change my mind with more thought)...

--On Thursday, August 04, 2016 16:12 +0100 Alexey Melnikov
<alexey.melnikov@isode.com> wrote:

>...
>> It seems to me that it is inappropriate to advance this
>> document before those relationship issues are carefully and
>> openly explored and discussed.  While the two sets of
>> documents (EAI-produced and this AppsAWG work) all lie within
>> the same Area and, for MDNs, even have overlapping authorship,
>> coordination among the various pieces of work so far makes it
>> seem much closer to a cross-area situation, so I think it is
>> up to the leadership of the present group and the AD(s) to
>> decide whether it is best to hold that discussion now or on
>> IETF LC.

> Will you be Ok with having rfc6533-bis draft and some broad
> agreement between authors about the possible way forward with
> it? My preference is to get draft-ietf-appsawg-mdn-3798bis
> done (I would like to free up my time to do other IETF things)
> and proceed with rfc6533-bis in parallel.

Makes me _very_ nervous, especially against the background of
some things being handled on the basis of such agreements and
then having the revised document stall for nearly forever.  I
really do see a threat to SMTPUTF8 deployment and adoption in
this work and way of handling things.  Questions of how serious
that threat is and whether it is acceptable really should be
matters of community consensus (including the EAI community),
not just an agreement among authors.

If your goal is simply to get this out of your queue (something
with which I'm very sympathetic), then post rfc6533-bis, if
necessary even with placeholder content, put a normative
reference to it in 3798bis, process the latter and then let it
sit in the RFC Editor queue until we have actually addressed the
issues.  The is noot my favorite approach, but is certainly a
possibility.

best,
   john