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

[Gorry Fairhurst <[e-mail]>]

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