draft-ietf-ipdvb-sec-req-09 passed for publication as an RFC - corrections.
Gorry Fairhurst <email@example.com> Tue, 03 February 2009 22:42 UTC
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CFA43A67DF for <firstname.lastname@example.org>; Tue, 3 Feb 2009 14:42:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([18.104.22.168]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQCDZT+V1DnR for <email@example.com>; Tue, 3 Feb 2009 14:42:39 -0800 (PST)
Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id D5B6F3A67A5 for <firstname.lastname@example.org>; Tue, 3 Feb 2009 14:42:37 -0800 (PST)
Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n13MA9S2016370 for <email@example.com>; Tue, 3 Feb 2009 22:10:09 GMT
Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id n13MA9aH016369 for ipdvb-subscribed-users; Tue, 3 Feb 2009 22:10:09 GMT
X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to firstname.lastname@example.org using -f
Received: from Gorry-Fairhursts-Laptop-6.local (fgrpf.plus.com [22.214.171.124]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n13M9sep016351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <email@example.com>; Tue, 3 Feb 2009 22:09:55 GMT
Date: Tue, 03 Feb 2009 22:09:53 +0000
From: Gorry Fairhurst <firstname.lastname@example.org>
Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683.
User-Agent: Thunderbird 126.96.36.199 (Macintosh/20081209)
Subject: draft-ietf-ipdvb-sec-req-09 passed for publication as an RFC - corrections.
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-ERG-MailScanner: Found to be clean, Found to be clean
The security requirements document has been passed by IESG for publication as an RFC. The authors received comments during the Gen-ART review and also from the IESG, relating to the interoperability of the different mechanisms and specifically asking for guidance for implementors. The proposed changes below are in response to these comments. These changes also address IESG comments on the use of security databases in the Appendix. If accepted, these will be included in the published RFC. Please let the list (or me) know if you have any comments on these amendments. If I do not receive feedback by the 6th February, these will be passed to the RFC Editor. Best wishes, Gorry Faihurst (ipdvb Chair) --- In Abstract: OLD: The MPEG-2 standard defined by ISO 13818-1 supports a range of transmission methods for a range of services. ^^^^^ NEW: The MPEG-2 standard defined by ISO 13818-1 supports a range of transmission methods for a variety of services. ^^^^^^^ In Section 5, para 2, please update text by adding new text at the end of the paragraph: OLD: Security services may be grouped into profiles based on security requirements, e.g. a base profile (with payload encryption and identity protection), and a second profile that extends this to also provide source authentication and protection against replay attacks. ^ NEW: Security services may be grouped into profiles based on security requirements, e.g. a base profile (with payload encryption and identity protection), and a second profile that extends this to also provide source authentication and protection against replay attacks. Although the use of specific security techniques is optional, it is RECOMMENDED that receiver devices should implement all the techniques in Reqs 2-5 of section 4, to ensure interoperability of all profiles. In appendix A1.2. Please replace paragraph: OLD: The design of these two databases may be based on IPsec databases as defined in RFC4301 [RFC4301]. NEW: While traditionally link layer security has operated using simple policy mechanisms, it is envisaged that ULE security should provide flexibility comparable to IPsec. the above design is based on the two databases defined for IPsec [RFC4301]. These databases could be used to implement either simple policies (as in traditional link security services) or more complex policies (as in IPsec). --
- draft-ietf-ipdvb-sec-req-09 passed for publicatio… Gorry Fairhurst