[Extra] Ben Campbell's Yes on draft-ietf-extra-sieve-fcc-08: (with COMMENT)

Ben Campbell <ben@nostrum.com> Fri, 11 January 2019 18:10 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Ben Campbell <ben@nostrum.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-extra-sieve-fcc@ietf.org, Jiankang Yao <yaojk@cnnic.cn>, extra-chairs@ietf.org, yaojk@cnnic.cn, extra@ietf.org
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154723020267.21974.8842298989488055017.idtracker@ietfa.amsl.com>
Date: Fri, 11 Jan 2019 10:10:02 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/wzyXKWrX2hkp7zGpMsesdVUtP8s>
Subject: [Extra] Ben Campbell's Yes on draft-ietf-extra-sieve-fcc-08: (with COMMENT)

Ben Campbell has entered the following ballot position for
draft-ietf-extra-sieve-fcc-08: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-fcc/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I am clearing my DISCUSS, since conversation seems to be going in the right
direction. I've included the DISCUSS text below for documentation purposes.

<old-discuss>
The security considerations say that this extension adds no new considerations
not already present in [RFC5228], [RFC5230], [RFC5435], and [RFC6131]. I'm not
sure that that is true.

It seems like the ability to insert a copy of message into a mailbox might have
security and/or privacy considerations. This seems analogous to the "fileinto"
action. I looked for security considerations for that in RFC 5228. All I found
was a statement that "fileinfo" can be dangerous, but no elaboration on the
nature of the danger or how it might be mitigated. So while I agree that fcc
would have similar considerations as "fileinfo", I'm not sure those
considerations have been adequately documented.  (I expect people will point me
to something I missed, or where some other analogous feature is documented, in
which case I will clear.)

</old-discuss>

§1, last paragraph (nit): Should "each action" be "each new action"?

§3.2, construction for FCC-OPTS: There is no extension point among the options,
which would seem to require any new options update this RFC. Would it be
reasonable to add one?

[Extra] Ben Campbell's Yes on draft-ietf-extra-si… Ben Campbell