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

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-extra-imap4rev2-26: No Objection

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



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

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

** 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”?

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

** Section 5.1.2.  Editorial.  s/manager to grant to their secretary access
rights/manager to grant to their administrative support staff access rights/

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

** 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”?

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

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

** Section 7.1.  Other than a clear text connection, under what circumstances
would PRIVACYREQUIRED be returned?  I ask because the statement “The operation
is not permitted due to a lack of privacy” seems rather generic and might
benefit from tighter scoping of what “lack of privacy” means.

** 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)?

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

** Section 11.1.  Per “Other TLS cipher suites recommended in RFC 7525 are
RECOMMENDED …”, seems as if RFC7525 needs to be an explicit reference.

** Section 11.2.  Per “For this reason, IMAP4rev2 clients SHOULD try both ports
993 and 143 (and both IPv4 and IPv6) concurrently by default, unless overriden
[sic] by either user configuration or DNS SRV records [RFC6186]”, is there any
further guidance needed here to guide if say both 993 and 143 respond; or you
get responses across address families?

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

-- Section 11.3.  s/(or a man-in-the-middle attacker)/ (or an on-path attacker)/

** Typos:
-- Section 11.2. s/overriden/overridden/

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