draft-ietf-ipdvb-sec-req-09 passed for publication as an RFC - corrections.

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Tue, 03 February 2009 22:42 UTC

Return-Path: <owner-ipdvb@erg.abdn.ac.uk>
X-Original-To: ietfarch-ipdvb-archive@core3.amsl.com
Delivered-To: ietfarch-ipdvb-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CFA43A67DF for <ietfarch-ipdvb-archive@core3.amsl.com>; Tue, 3 Feb 2009 14:42:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQCDZT+V1DnR for <ietfarch-ipdvb-archive@core3.amsl.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 <ipdvb-archive@ietf.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 <ipdvb-subscribed-users@dee.erg.abdn.ac.uk>; 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 owner-ipdvb@erg.abdn.ac.uk using -f
Received: from Gorry-Fairhursts-Laptop-6.local (fgrpf.plus.com [212.159.18.54]) (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 <ipdvb@erg.abdn.ac.uk>; Tue, 3 Feb 2009 22:09:55 GMT
Message-ID: <4988C0B1.1060904@erg.abdn.ac.uk>
Date: Tue, 03 Feb 2009 22:09:53 +0000
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683.
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: ipdvb@erg.abdn.ac.uk
Subject: draft-ietf-ipdvb-sec-req-09 passed for publication as an RFC - corrections.
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ERG-MailScanner: Found to be clean, Found to be clean
Sender: owner-ipdvb@erg.abdn.ac.uk
Precedence: bulk
Reply-To: ipdvb@erg.abdn.ac.uk
X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk

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

--