Re: draft-noisternig-ipdvb-sec-ext-00.txt (Editorial NiTs)
Michael Noisternig <mnoist@cosy.sbg.ac.at> Fri, 10 July 2009 14:25 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 274E63A68CC for <ietfarch-ipdvb-archive@core3.amsl.com>; Fri, 10 Jul 2009 07:25:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.084
X-Spam-Level:
X-Spam-Status: No, score=-0.084 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_AT=0.745, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1]
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 EXZkkkyF6KCN for <ietfarch-ipdvb-archive@core3.amsl.com>; Fri, 10 Jul 2009 07:25:08 -0700 (PDT)
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 A1C7928C35B for <ipdvb-archive@ietf.org>; Fri, 10 Jul 2009 07:24:43 -0700 (PDT)
Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n6ADvF7I018765 for <ipdvb-subscribed-users@dee.erg.abdn.ac.uk>; Fri, 10 Jul 2009 14:57:15 +0100 (BST)
Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id n6ADvFl1018764 for ipdvb-subscribed-users; Fri, 10 Jul 2009 14:57:15 +0100 (BST)
X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f
Received: from puma.cosy.sbg.ac.at (puma.cosy.sbg.ac.at [IPv6:2001:628:408:102::30:0]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n6ADv4oB018749; Fri, 10 Jul 2009 14:57:04 +0100 (BST)
Received: from [192.168.1.2] (d83-187-170-40.cust.tele2.at [83.187.170.40]) by puma.cosy.sbg.ac.at (Postfix) with ESMTP id E6C112286A2; Fri, 10 Jul 2009 15:57:04 +0200 (CEST)
Message-ID: <4A5748AC.8070402@cosy.sbg.ac.at>
Date: Fri, 10 Jul 2009 15:57:00 +0200
From: Michael Noisternig <mnoist@cosy.sbg.ac.at>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: ipdvb@erg.abdn.ac.uk
Cc: gorry@erg.abdn.ac.uk, H.Cruickshank@surrey.ac.uk, Prashant Pillai <P.Pillai@Bradford.ac.uk>
Subject: Re: draft-noisternig-ipdvb-sec-ext-00.txt (Editorial NiTs)
References: <1244702672.4a30a7d0b5839@webmail.brad.ac.uk> <4A50542A.20001@erg.abdn.ac.uk> <4A505DE1.80009@erg.abdn.ac.uk>
In-Reply-To: <4A505DE1.80009@erg.abdn.ac.uk>
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
Hi Gorry, thanks again. Please see a few comments inline. Michael Gorry Fairhurst schrieb: > > Authors, I dent some comments and questions on the draft in a previous > email. This email contains a few minor comments on editorial issues, > that may improve the next version of this draft. > > Best wishes, > > Gorry > > --- > /Another feature provided is called identity protection./ > - This reads oddly, I suggest something like: > /The method also provides identity protection./ The problem was that 'identity protection' normally refers to something else. How about "The extension also supports what is called 'identity protection' in this specification."? Any better suggestion? > --- > /processing continues as usually/ > - this should be /continues with the usual processing/, although it > would be better to also cite a reference to indicate what this is. > > --- > /On securing the ULE SNDUs, security is provided at the link layer as > opposed to existing higher-layer mechanisms like IPsec [8] or TLS > [11]. This allows them to be used in/ > - This reads oddly. Is it possible to say something like: > /This document provides security for ULE SNDUs at the link layer, iin > contrast to higher-layer mechanisms, such as IPsec [8] or TLS > [11]. This design allows higher-layer mechanisms to be used in/ > --- > /The security extension may use and benefit f/ > - This isn't quite so, you would would need to update these mechanisms, > a forward reference to the appropriate section where this is discussed. I agree. We may remove that, and instead add the following paragraph after the one talking about the processing: "Key management protocols assuming similar processing functionality, such as the MSEC Group Domain of Interpretation (GDOI) [9] and the Group Secure Association Key Management Protocol (GSAKMP) [7], may be adapted for the ULE scenario. Simple configurations are supported using manual keying (i.e., pre-shared keys)." Is this more clear, should we still provide a forward reference? > --- > /The ULE security extension is designed to cope with both bi- > directional and unidirectional links, as well as unicast and > multicast settings./ > - Could you replace /to cope with/ by /for/ > - This would be a good place to identify the framework [RFC 4259] > --- > Please add abbreviations: > GSE > VPN > SID > etc. > --- > /Some of the main security services > (mandatory or optional) that the security extension for ULE aims to > provide are:/ > - delete /aims to provide/? and say /provides/? > --- > /even if it got hold of the transmitted data./ > ^^^^^^^^^^^^^^^ > - Can you rephrase in more formal English? > --- > /arguably the most important step on providing/ > - Is it possible to say something like: > /an important step in providing/ > --- > /While one > solution for this is to use temporary addresses.... > - is this text needed? (see other comments). > --- > Page 6: > /digital signatures, may be used in order to assure source/ > - I misread this. I don't think this talks about ordering, and so it > would be better in this case to remove /in order/. > --- > / will not be able to derive a correct one./ > ^^^^^^^^^^^^^^^^^^^^^^^ > - True, it will be statistically hard, bit not impossible. ...will unlikely be able to derive a correct one. Or we might introduce (in)feasibility. ;) > --- > Page 7: > /received data is recent/ > ^^^^^^^^^ > - could this be better phrased? ...fresh? > --- > Page 8: > /After the ULE base header, the security extension header follows./ > - May be better as: > /The security extension header follows the ULE base header./ > --- > Page 11: > / In order to support > shared SAs permitting bi-directional communication, an SAD should/ > - May be better as: > / To support shared SAs for bi-directional communication, an SAD should/ > --- > / Each set of Security Parameters contains information about:/ > - May be better as: > / Each set of Security Parameters contains:/ > ---- > /no security services at all,/ > ^^^^^^ > - delete /at all/? > --- > /Note that we do not describe/ > - better, perhaps as: > /This document does not describe/ > --- > /, as this is regarded implementation specific details./ > - better, perhaps as: > /. This is regarded as implementation-specific detail./ > --- > Section 7.3: > / Such protocol should/ > ^ > - insert /a/. > --- > /Link-level security is commonly used in broadcast/radio links to > supplement end-to-end security, and may not be treated as a > substitute./ > - A substitute for what? > --- > /A device may receive data from different MPEG-2 > multiplexes, which both may allocate PID values independently./ > - cite reference to another RFC? > > --- > References: > > Some references are uncited, e.g. [5]. > > It may be helpful to consider citing [10] and [4] as informational > background to issues they consider. These are already published and > citing them where appropriate would help the reader understand issues > that have already been discussed. > > --- > > Finally, > The following word appears in several place: /Illegitimate/ This has > some additional meanings that are not intended here - could you replace > by unauthoried or unintended or something similar? I agree with all other suggestions.
- draft-noisternig-ipdvb-sec-ext-00.txt Gorry Fairhurst
- Re: draft-noisternig-ipdvb-sec-ext-00.txt (Editor… Gorry Fairhurst
- Re: draft-noisternig-ipdvb-sec-ext-00.txt (Editor… Michael Noisternig
- Re: draft-noisternig-ipdvb-sec-ext-00.txt Michael Noisternig
- Re: draft-noisternig-ipdvb-sec-ext-00.txt (Editor… Gorry Fairhurst