A Protocol for Remotely Managing Sieve Scripts
draft-ietf-sieve-managesieve-09

Section 1.9., paragraph 0:

> 1.9.  Link Level
>
>    The ManageSieve protocol assumes a reliable data stream such as that
>    provided by TCP.

  I think you want to make TCP support for ManageSieve REQUIRED. (Also,
  nit, "Link Level" isn't the greatest section name for this - maybe
  "Transport"?)


Section 1.9., paragraph 1:
>    When TCP is used, a ManageSieve server typically
>    listens on port 2000. [[anchor7: IANA registration of port 2000 is
>    pending.]]

  Port 2000 is unavailable, but I see Chris is holding the DISCUSS.

2.3.  LOGOUT Command

   The client sends the LOGOUT command when it is finished with a
   connection and wishes to terminate it.  The server MUST reply with an
   OK response and terminate the connection.  The server MUST ignore
   commands issued by the client after the LOGOUT command.

       Example:

       C: Logout
       S: Ok
       <connection terminated>

To reduce the TCP Timed-wait loading on the server, wouldn't it be smarter to have the client close the TCP connection upon receiving the response?  

Section 4:

    number                = 1*DIGIT
                            ;; A 32-bit unsigned number.
                            ;; (0 <= n < 4,294,967,296)

Why isn't the number of digits restricted? Because clearly a 32-bit unsigned number will never need more than 10 DIGITs, thus the construct would make more sense as:

number                = 1*10DIGIT
                            ;; A 32-bit unsigned number.
                            ;; (0 <= n < 4,294,967,296)

[Sorry for the long winded comment that follows, but I noticed in the gen-art email thread
that this anchor was specifically left in to prompt my feedback. Just trying to be responsive!]

Anchor9 highlights Chris Newman's observation on differences between the specifications and
existing practice for wildcard matching when performing the server identity check.

The PKIX wg spent some time discussing this problem at the Philadelphia IETF.   To paraphrase
the minutes:

    Wildcards in DNS names in certificates are commonly supported, both in terms of
    certificates issued by some major CAs and in platforms processing them, but it has never
    been acknowledged in PKIX standards. 2818 allows wildcards, but inconsistently with some
    common platforms (e.g., Windows).  Note also that 2818 is Informational, not standards
    track.  Also, TLS is used in many other environments, and these environments can write
    standards to address this issue in their context.

Basically, I agree with Chris that wildcard matching is supported on many platforms, including
the scenario where the CN contains the server identity (Section 2.2.1, Rule 3.)  However, there 
is no specific standard to reference that accurately describes the behavior of existing clients,
since that processing is not uniform.  This is unfortunate, but there are so many legacy
implementations that developing a standard seems unlikely at this point.

Given that, the text (in sections 2.2.1 and 2.2.1.1) as written seems reasonable and complete.
It establishes clear and unambiguous expectations for this context.  I would also note that
the matching rule used here is less complicated than that in 2818.  (2818 permits matching
substrings in a domain name: "f*.com matches foo.com but not bar.com".  Personally, I do
not think that is a very useful feature.)

One change you *might* consider is relaxing rule 3 and permitting wildcard matches in the
CN, since this is permitted by 2818.

One last thing: I support Pasi's request for text in the Security Considerations highlighting
TRANSITION-NEEDED.