[secdir] SECDIR review of draft-ietf-lemonade-profile-bis-12.txt
"Hannes Tschofenig" <Hannes.Tschofenig@gmx.net> Wed, 11 March 2009 07:55 UTC
Return-Path: <Hannes.Tschofenig@gmx.net>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF1BE3A6A1F for <secdir@core3.amsl.com>; Wed, 11 Mar 2009 00:55:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.243
X-Spam-Level:
X-Spam-Status: No, score=-1.243 tagged_above=-999 required=5 tests=[AWL=-0.604, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRh6-IEg79uV for <secdir@core3.amsl.com>; Wed, 11 Mar 2009 00:55:54 -0700 (PDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id B2D0E3A69EC for <secdir@ietf.org>; Wed, 11 Mar 2009 00:55:53 -0700 (PDT)
Received: (qmail invoked by alias); 11 Mar 2009 07:56:28 -0000
Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp014) with SMTP; 11 Mar 2009 08:56:28 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1/3DKY9e7f3hDhYSLhPOCSfJT3LWPe+dXrW+nCrK0 srzTrr085BcVg/
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
To: 'SECDIR' <secdir@ietf.org>, draft-ietf-lemonade-profile-bis@tools.ietf.org
Date: Wed, 11 Mar 2009 09:57:33 +0200
Message-ID: <085d01c9a21f$0a20afd0$0201a8c0@nsnintra.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcmiHwjo2XhVgLVNQWeDit9U2h4CzQ==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.57
Subject: [secdir] SECDIR review of draft-ietf-lemonade-profile-bis-12.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Mar 2009 07:55:55 -0000
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines a profile of IMAP, mail submission and Sieve protocol for usage of performance constraints devices. This document does not define new security mechanisms (or other extensions). It points to the security related aspects associated with the profiled version (e.g., the pawn ticket -- a fancy name for a simple concept). This is a good document. Only a few minor editor comments and a question regarding the IANA consideration section: The RFC Editor always edits my documents to have a capitalized subject headers. E.g.: s/Summary of the required support/Summary of the Required Support s/Message size declaration/Message Size Declaration s/Lemonade Submission Servers MUST provide a service as described in [SUBMIT], and MUST support the following./ Lemonade Submission Servers MUST provide a service as described in [SUBMIT], and MUST support the following extensions. s/Lemonade Message Stores MUST provide a service as described in [IMAP], and MUST support the following./Lemonade Message Stores MUST provide a service as described in [IMAP], and MUST support the following extensions. s/(See [SMTP-BURL] for more details)./(see [SMTP-BURL] for more details). s/Therefore /Therefore, s/Server-to-client notifications transforms/server-to-client notifications transforms s/the Notification filter generates/the notification filter generates First occurance of OMA write Open Mobile Alliance (OMA) "When clients submit new messages, link protection such as [TLS] guards against an eavesdropper seeing the contents of the submitted message." Maybe use "confidentially protection, such as TLS [TLS]," instead of link protection The IANA consideration section says "This document defines the URL-PARTIAL IMAP capability Section 5.7.1. IANA is requested to add this extension to the IANA IMAP Capability registry.". Section 5.7.1 only references another specification where this capability is defined, at least that's my reading. This document only defines a profile and does not require any IANA considerations. Here is what Section 5.7.1 says: " 5.7.1. Support for PARTIAL in CATENATE and URLAUTH [IMAP-URL] introduced a new syntactic element for referencing a byte range of a message/body part. This is done using the ;PARTIAL= field. If an IMAP server supports PARTIAL in IMAP URL used in CATENATE and URLAUTH extensions, then it MUST advertise the URL- PARTIAL capability in the CAPABILITY response/response code. " Ciao Hannes
- [secdir] SECDIR review of draft-ietf-lemonade-pro… Hannes Tschofenig
- Re: [secdir] SECDIR review of draft-ietf-lemonade… Dave Cridland
- Re: [secdir] SECDIR review of draft-ietf-lemonade… Hannes Tschofenig
- Re: [secdir] SECDIR review of draft-ietf-lemonade… Alexey Melnikov