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

Dan Romascanu <> Wed, 09 January 2019 16:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 04D80130ED9; Wed, 9 Jan 2019 08:56:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P3g7YW3QbGgT; Wed, 9 Jan 2019 08:56:12 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E399A130F01; Wed, 9 Jan 2019 08:56:11 -0800 (PST)
Received: by with SMTP id v10so6525303ios.13; Wed, 09 Jan 2019 08:56:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gr2XKXkknDL+UML382xKsKvsLPO13UikIVXGKG2NO5s=; b=ZjM+pjwOONTwrFj1jhnfkyd7btiuXzj9I0Gdz8gDHtRgPEpq3n53iSF1mczanLtqma mgR0Zlhm0syj+EZEJEkHq/NpZLGixdqFl0ip9VmDdHXAOBfefJnBSxX02QCVlBhRbQgy VsEXzcBLgIYW2PYh8a5R0h1yuUZND4AYOs7eqBUanBrUOgqfr7dSVTjQFHD9blc9eivT nO4cSwaFAQmp6HKOJLOs0vYvhi5WtF8wjIseYODAstm4lK7zXgSvsAdkR2uZjeKDXl+T qOeOYoFJSPBy6m0Dvz8acui+/4VKUUVBmqu6lEdHDsqh+E7WxbDWIVwsBV2jE/4tksF6 5p1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gr2XKXkknDL+UML382xKsKvsLPO13UikIVXGKG2NO5s=; b=KSe1ly4eBUdWBR5dCOdUgjr5P9g11/x3u8O9N+TSVvRkV3d2+syLUBLi4XMrLOppDY qjWzHoYF9HK4SxezKCItUE/c8nJLJJicDTPkOAt6mJ3SJE7xZDaIEvVAmqzM/tmpnmRg nc+B+BvC2TXrPSHpGlHucQ8bLyaudo0zB6ki3Gsoppj/2BX4524QVR8Z+ekhoyMgKXKH ijELYrYVmsH46ltmtK+nt+xC7eVjNnAUKhLD5i0wuauOuK2sLkdu4TBq0kFXxqPAz/Vz hyAHqVuLRUvFjGmtW/YSUB+mpwA6FrdTJkgWN6SSz8Ma23JbJR1j2y7vX8v5GJCLXZMD MlkQ==
X-Gm-Message-State: AJcUuke6d/MOrfgwUubWpCqg+TGRBkgAWvtZj+r75qyGM6oGrqdE0eDv 9E0MX5uB4f3ISGG6HQxvVuBvw3Mhh4MwOXYz1oeM5g==
X-Google-Smtp-Source: ALg8bN5FK107p8hwgmA7L0piUUp3mnvCr2pdBI3sighxOY207rHhN9cA1m8bhc8zZg1MtcwGT9Gqd+rL9FvMKqum9s8=
X-Received: by 2002:a6b:e514:: with SMTP id y20mr4321782ioc.105.1547052971148; Wed, 09 Jan 2019 08:56:11 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Dan Romascanu <>
Date: Wed, 9 Jan 2019 18:55:58 +0200
Message-ID: <>
Subject: Re: [Extra] Opsdir last call review of draft-ietf-extra-sieve-fcc-08
To: Ned Freed <>
Cc: Alexey Melnikov <>,,, ietf <>,
Content-Type: multipart/alternative; boundary="000000000000cb49f4057f095682"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 Jan 2019 16:56:15 -0000

Hi Ned,

Thanks for your answer. I am leaving to the OPS ADs the judgment about how
important the clarification text would be. The OPS-DIR reviews are written
to help them in their evaluaton tasks.



On Wed, Jan 9, 2019 at 6:13 PM Ned Freed <>; wrote:

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