Re: [Extra] Opsdir last call review of draft-ietf-extra-sieve-fcc-08

ned+ietf@mauve.mrochek.com Wed, 09 January 2019 16:13 UTC

Return-Path: <ned+ietf@mauve.mrochek.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7744A130EC1 for <ietf@ietfa.amsl.com>; Wed, 9 Jan 2019 08:13:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=unavailable 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 Fz4SvmMs-7v2 for <ietf@ietfa.amsl.com>; Wed, 9 Jan 2019 08:13:46 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.218.59.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AC65130EC7 for <ietf@ietf.org>; Wed, 9 Jan 2019 08:13:46 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1SUQJKQWG00DK9V@mauve.mrochek.com> for ietf@ietf.org; Wed, 9 Jan 2019 08:08:42 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1N39ADWKW00004L@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf@ietf.org; Wed, 9 Jan 2019 08:08:32 -0800 (PST)
From: ned+ietf@mauve.mrochek.com
Cc: Alexey Melnikov <aamelnikov@fastmail.fm>, extra@ietf.org, ops-dir@ietf.org, ietf <ietf@ietf.org>, draft-ietf-extra-sieve-fcc.all@ietf.org
Message-id: <01R1SUQEDQD200004L@mauve.mrochek.com>
Date: Wed, 09 Jan 2019 07:58:32 -0800 (PST)
Subject: Re: [Extra] Opsdir last call review of draft-ietf-extra-sieve-fcc-08
In-reply-to: "Your message dated Wed, 09 Jan 2019 13:27:34 +0200" <CAFgnS4VK=FS89pYdcYv=PpQbzVrg-BaMMKy+f1Qy-7z9bRvokw@mail.gmail.com>
References: <154702622280.7446.9285138848727921959@ietfa.amsl.com> <1547031913.1905154.1629702968.4FBE79B8@webmail.messagingengine.com> <CAFgnS4VK=FS89pYdcYv=PpQbzVrg-BaMMKy+f1Qy-7z9bRvokw@mail.gmail.com>
To: Dan Romascanu <dromasca@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/MJPq3RvGQBp9_YUbtPLcmyQoWC0>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Jan 2019 16:13:48 -0000

> Thanks for the answer. It helps indeed. It would help better if this is
> documented with one paragraph in the text of the document. While developers
> know well the details, users and operators may be less familiar with these.

I'm going to push back on this a bit. It's effectively axiomatic that in order
to understand a protocol extension you first need to understand the protocol
and it's extension mechanism. Having every extension reiterate a subset of how
the extension mechanism works seems pointless at best and more likely
counterproductive - covering only a subset of the mechanism, which is
all you're be able to do without repeating a significant amount of
RFC 5228 will give the (incorrect) impression that it's all you need to know.

Now, it would be one thing if there was a section in RFC 5228 that
describes the extension mechanism - if that were the case we could
just reference it. But for better or worse RFC 5228 isn't constructed that
way. Perhaps more than any other protocol, Sieve is designed to be extended
easily, and the discussion of how that works appears throughout the
document.

Finally, if we're going to talk about implementation and use issues in regards
to this extension - and I'm not saying we should - such text would be better
spent on discussing the interplay between this extension and where sieves are
evaluated.

				Ned