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.
I'm not sure what would be best. I think I'd expect within a specified time interval. or "recently received", or somethingOr 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.