Re: draft-noisternig-ipdvb-sec-ext-00.txt (Editorial NiTs)

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Sat, 11 July 2009 20:37 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 F29833A682E for <ietfarch-ipdvb-archive@core3.amsl.com>; Sat, 11 Jul 2009 13:37:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.514
X-Spam-Level:
X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 SdlrsZWDGYgT for <ietfarch-ipdvb-archive@core3.amsl.com>; Sat, 11 Jul 2009 13:37:52 -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 9C3F73A677D for <ipdvb-archive@ietf.org>; Sat, 11 Jul 2009 13:37:50 -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 n6BKGlbd029709 for <ipdvb-subscribed-users@dee.erg.abdn.ac.uk>; Sat, 11 Jul 2009 21:16:47 +0100 (BST)
Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id n6BKGlpS029708 for ipdvb-subscribed-users; Sat, 11 Jul 2009 21:16:47 +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 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 n6BKGALx029695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 11 Jul 2009 21:16:10 +0100 (BST)
Message-ID: <4A58F30A.3030807@erg.abdn.ac.uk>
Date: Sat, 11 Jul 2009 21:16:10 +0100
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.22 (Macintosh/20090605)
MIME-Version: 1.0
To: ipdvb@erg.abdn.ac.uk
CC: 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> <4A5748AC.8070402@cosy.sbg.ac.at>
In-Reply-To: <4A5748AC.8070402@cosy.sbg.ac.at>
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

See in-line,

Gorry

Michael Noisternig wrote:
> 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?
> 
Sounds fine to me.

>> ---
>> /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?
> 
Also seems good.

>> ---
>> /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.
> 
That would be OK.

> Or we might introduce (in)feasibility. ;)
> 
>> ---
>> Page 7:
>> /received data is recent/
>>                ^^^^^^^^^
>> - could this be better phrased?
> 
> ...fresh?
> 
I'm not sure what would be best. I think I'd expect within a specified 
time interval. or "recently received", or something

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