Re: [Extra] Roman Danyliw's No Objection on draft-ietf-extra-imap4rev2-26: (with COMMENT)

Roman Danyliw <rdd@cert.org> Tue, 02 February 2021 18:58 UTC

Return-Path: <rdd@cert.org>
X-Original-To: extra@ietfa.amsl.com
Delivered-To: extra@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 763C13A1056; Tue, 2 Feb 2021 10:58:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
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 rT76zGkAhcmH; Tue, 2 Feb 2021 10:58:32 -0800 (PST)
Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 C8CFC3A1052; Tue, 2 Feb 2021 10:58:31 -0800 (PST)
Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 112IwRgM015105; Tue, 2 Feb 2021 13:58:27 -0500
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 112IwRgM015105
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1612292308; bh=tWXu0Pey6hKedSV3UeQgd8uuNl90wVVc9GteOWBsnUw=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=Kc5StCSDiesB/WpqbJzXLGPBQY7hPUK0va4E8kZKKyGpcguw3jsOb6Bu5U7Z6T+/a VjFwWr13xEMCB5jStLUa5esObIgalp86yFoDgeIeCvxSTwReDoab/h0mTK9OIXZa7C 5CEe9L90u9ki2NRQ2h+pjN3WQxwAV1YOQGEAbh+Q=
Received: from MORRIS.ad.sei.cmu.edu (morris.ad.sei.cmu.edu [147.72.252.46]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 112IwPGH040625; Tue, 2 Feb 2021 13:58:25 -0500
Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MORRIS.ad.sei.cmu.edu (147.72.252.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Tue, 2 Feb 2021 13:58:25 -0500
Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.2106.002; Tue, 2 Feb 2021 13:58:25 -0500
From: Roman Danyliw <rdd@cert.org>
To: Alexey Melnikov <alexey.melnikov@isode.com>, The IESG <iesg@ietf.org>
CC: "extra@ietf.org" <extra@ietf.org>, "brong@fastmailteam.com" <brong@fastmailteam.com>, "draft-ietf-extra-imap4rev2@ietf.org" <draft-ietf-extra-imap4rev2@ietf.org>, "extra-chairs@ietf.org" <extra-chairs@ietf.org>
Thread-Topic: [Extra] Roman Danyliw's No Objection on draft-ietf-extra-imap4rev2-26: (with COMMENT)
Thread-Index: AQHW+XZCTrqolprXI0KoFo+FtpNglKpFbOKA///JYUA=
Date: Tue, 2 Feb 2021 18:58:24 +0000
Message-ID: <82d4aa2b83474756b664dd21a50f0058@cert.org>
References: <161227892696.22043.1613107216198518224@ietfa.amsl.com> <d11c48d6-bbe4-156f-30a8-d5206557d82d@isode.com>
In-Reply-To: <d11c48d6-bbe4-156f-30a8-d5206557d82d@isode.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.202.236]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/L7FxWjxnuoL6xUgL4q7xjxnv-XM>
Subject: Re: [Extra] Roman Danyliw's No Objection on draft-ietf-extra-imap4rev2-26: (with COMMENT)
X-BeenThere: extra@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email mailstore and eXtensions To Revise or Amend <extra.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/extra>, <mailto:extra-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/extra/>
List-Post: <mailto:extra@ietf.org>
List-Help: <mailto:extra-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/extra>, <mailto:extra-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Feb 2021 18:58:35 -0000

Hi Alexey!

Thanks for the quick turn around with all of the edits and the few places where you explained that a changed isn't appropriate.  A bit more inline ...

> -----Original Message-----
> From: iesg <iesg-bounces@ietf.org> On Behalf Of Alexey Melnikov
> Sent: Tuesday, February 2, 2021 12:08 PM
> To: Roman Danyliw <rdd@cert.org>rg>; The IESG <iesg@ietf.org>
> Cc: extra@ietf.org; brong@fastmailteam.com; draft-ietf-extra-
> imap4rev2@ietf.org; extra-chairs@ietf.org
> Subject: Re: [Extra] Roman Danyliw's No Objection on draft-ietf-extra-
> imap4rev2-26: (with COMMENT)
> 
> Hi Roman,
> 
> Thank you for your comments. Replying to most of your comments (I will reply
> to the rest separately):
> 
> On 02/02/2021 15:15, Roman Danyliw via Datatracker wrote:
> > ** Section 1.3.  What are the “unpublished IMAP2bis protocols”?  Even
> > if there were unpublished, is there any pointer/reference that can be
> > provided, say like https://tools.ietf.org/html/draft-ietf-imap-imap2bis-02?
> Yes, this looks like a reasonable informative reference.
> > ** Section 2.3.1.1.  Step #4.  Should “In particular, the internal
> > date, [RFC-5322] size, envelope, body structure, and message texts
> > (all BODY[...] fetch data items) must never change)”, use the normative
> “MUST never change”?
> Sure.

Thanks.

> > ** Section 2.3.3.  The text for $Forwarded notes that “Once set, the
> > flag SHOULD NOT be cleared.”  Should the same guidance apply to
> $MDNSent?
> $MDNSet description points to RFC 3503, which states "MUST NOT be
> cleared". I would rather not copy the text into this draft, if that is Ok with you?

I hadn't actually checked RFC3503.  If that's in there, no need to repeat here.

> > ** Section 5.1.2.  Editorial.  s/manager to grant to their secretary
> > access rights/manager to grant to their administrative support staff
> > access rights/
> Ok.
> > ** Section 6.3.1.  Per “However, servers cannot send those unsolicited
> > responses (with the exception of response codes (see Section 7.1)
> > included in tagged or untagged OK/NO/BAD responses, which can always
> > be sent) until they know that the clients support such extensions and
> > thus won't choke on the extension response data”, what is the more precise
> definition of “choke” here.
> > Is it that the client doesn’t understand the extension or that it
> > won’t be able to process it?
> The former. I think it was intended as a shortcut for "crash and misbehave in
> other surprising ways".

Ok.

> > ** Section 6.3.9.3.  Step 3.  Per “Attributes returned in the same
> > LIST response must be treated additively”, should this be a normative
> “MUST”?
> I think MUST is going to be a bit silly here, as the whole set is specified in a
> single LIST response. I will change this to "are treated additively".
> > ** Section 6.3.12 and Section 8.  The examples here have a few “non
> example”
> > domains (e.g., @Blurdybloop.com, @owatagu.siam.edu,
> > @cac.washington.edu)
> Yes, this comes from RFC 3501. I can change these if this is a big deal to people,
> but this will cause literal size changes in various places, so this is more work
> than just search & replace everywhere in the document.
> > ** Section 6.4.4.4.  Editorial.  In this section the inline annotation
> > of the
> > C: and S: examples are with a “//”.  In Section 6.3.10, these
> > annotations are made via “< … >”.  I’d recommend consistency.
> 
> Ok. Murray has pointed out the same thing. I will discuss with RFC Editor about
> the best way of representing comments.

Ok.

>   [snip]
> 
> > ** Section 7.1.4.  Per “For this reason PREAUTH response SHOULD only
> > be returned by servers on connections that are protected by TLS (such
> > as on implicit TLS port [RFC8314]) or protected through other means
> > such as IPSec”, what is the corner case in mind that motives a SHOULD
> (instead of a MUST)?
> I was thinking about loopback interface or something like Unix domain socket
> (the latter is technically out of scope for this document).
> > ** Section 11.  There are both confidentiality and integrity issues
> > with sending of IMAP in the clear.
> >
> > OLD
> > IMAP4rev2 protocol transactions, including electronic mail data, are
> > sent in the clear over the network unless protection from snooping is
> > negotiated.
> >
> > NEW
> > IMAP4rev2 protocol transactions, including electronic mail data, are
> > sent in the clear over the network exposing them to possible
> > eavesdropping and manipulation unless protections are negotiated.
> I used your text, thank you.
> > ** Section 11.1.  Per “Other TLS cipher suites recommended in RFC 7525
> > are RECOMMENDED …”, seems as if RFC7525 needs to be an explicit
> reference.
> 
> Good point. Added.
> 
>   [snip]
> 
> > ** In the spirit of inclusive language, consider something like the following:
> >
> > -- Section 6.2.1.  s/to protect against man-in-the-middle attackers
> > which alter/to protect against an on-path attacker which could alter/
> >
> > -- Section 11.1
> > OLD
> > … as presented in the server Certificate message, in order to prevent
> > man-in-the-middle attacks.
> >
> > NEW
> > … as presented in the server Certificate message, in order to prevent
> > on-path attackers attempting to masquerade as the server.
> Changed, thank you.
> > -- Section 11.3.  s/(or a man-in-the-middle attacker)/ (or an on-path
> > attacker)/
> Changed.
> > ** Typos:
> > -- Section 11.2. s/overriden/overridden/
> Fixed, thanks.
> > ** From idnits:
> >    -- The draft header indicates that this document obsoletes RFC3501, but the
> >       abstract doesn't seem to mention this, which it should.
> >
> >    -- There are a number of reference warnings which should be confirmed as
> not
> >    being problematic (not mentioned in the shepherd write-up)
> 
> Will do. I think all of them were covered by the IETF LC announcement, but I
> will double check.

Thanks for all of the above changes.

Regards,
Roman

> Best Regards,
> 
> Alexey
>