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

[Michael Noisternig <mnoist@cosy.sbg.ac.at>]

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.