Re: [Gen-art] Gen-ART review of draft-ietf-dime-e2e-sec-req-04.txt

[Christer Holmberg <[e-mail]>]

Hi Jouni,

I am happy with your clarifications and change suggestions.

Thanks!

Regards,

Christer



On 02/06/16 17:58, "Jouni Korhonen" <[e-mail]> wrote:

>Thanks Christer,
>
>And sorry for not responding earlier.. See my comments inline.
>
>5/7/2016, 7:48 AM, Christer Holmberg kirjoitti:
>>
>>
>> I am the assigned Gen-ART reviewer for this draft. For background on
>> Gen-ART, please see the FAQ at
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
>>
>>
>>
>> Document:       
>>draft-ietf-dime-e2e-sec-req-04
>>
>> Reviewer:                                        Christer Holmberg
>>
>> Review Date:                                7 May2016
>>
>> IETF LC End Date:                        12 April 2016
>>
>> IETF Telechat Date:                    N/A
>>
>> Summary:                                      The document is well
>> written, and almost ready for publication is informational RFC. However,
>> I have a few editorial issues, related to the Introduction, that I ask
>> the authors to address.
>>
>> Major Issues:                                None
>>
>> Minor Issues:                                None
>>
>> Editorial Issues:
>>
>>
>>
>> Q_ABSTRACT_1:
>>
>>
>>
>> The text says that the draft ³discusses² requirements. In my opinion it
>> should say ³defines² or ³specifies².
>
>Ack. "specifies" sounds as a good choice.
>
>>
>> Q_INTRODUCTION_1:
>>
>> Please add references for TLS (for TCP) and DTLS (for SCTP).
>>
>
>Ack.
>
>>
>> Q_INTRODUCTION_2:
>>
>> The text says: ³Šor alternative security mechanisms independent of
>> Diameter (e.g., IPsec) is used.²
>>
>> 2A: I guess it should be ³are used²?
>>
>
>Yes.. the whole sentence IMO reads badly, so I have some overall
>rewording proposals.
>
>OLD:
>    The Diameter base protocol specification [2] offers security
>    protection between neighboring Diameter peers and mandates that peer
>    connections must be protected by TLS (for TCP), DTLS (for SCTP) or
>    alternative security mechanisms independent of Diameter (e.g., IPsec)
>    is used.
>
>NEW:
>    The Diameter base protocol specification [RFC6733] defineds security
>    protection between neighboring Diameter peers. The Diameter
>    mandates that peer connections must be protected by TLS [RFC5246]
>    (for TCP), DTLS [RFC6083] (for SCTP) or using security mechanisms
>    that are independent of Diameter such as IPsec [RFC4301].
>
>> 2B: I am not sure I understand what ³independent of Diameter² means.
>>
>
>It is actually quite direct quotation from base protocol RFC6733 text.
>Basically meaning when using (D)TLS the Diameter node itself has to
>implement/terminate the security, while with IPsec it does not
>necessarily need to do anything (e.g., when site-to-site IPsec is in
>place).
>
>
>>
>> Q_INTRODUCTION_3:
>>
>> The text talks about security between non-neighbour nodes, while the
>> draft name includes ³e2e². However, when reading Section 4,
>> non-neighbour does not necessarily mean end-to-end. I think it would be
>> good to explicitly clarify that in the Introduction.
>>
>
>Ok. This terminology issue was brought up also in two other review
>afair. I would actually propose rewording the document name, since that
>seems to be the only place where "e2e" is really misplaced and the
>document name is goofy in any case.
>
>OLD:
>Diameter AVP Level Security End-to-End Security: Scenarios and
>                               Requirements
>NEW:
>AVP Level Security for Non-neighboring Diameter Nodes: Scenarios and
>                               Requirements
>
>and also..
>
>OLD:
>Diameter End-to-End Security
>
>NEW:
>Diameter AVP Level Security
>
>>
>> Q_INTRODUCTION_4:
>>
>> The text says: ³This document collects requirements for developing a
>> solution to protect Diameter AVPs.²
>>
>> 2A: It needs to be clear that it¹s about protecting AVPs between
>> non-neighbour nodes.
>>
>
>Ok.
>
>> 2B: Instead of ³collect², please use the same terminology as in the
>> Abstract.
>
>Ok. That will be 'specifies' then.
>
>> Q_INTRODUCTION_5:
>>
>>               Please enhance AVP on first occurrence. Currently it¹s not
>> done until Section 3.
>>
>
>Ack.
>
>Thanks,
>	Jouni
>
>>
>> _______________________________________________
>> Gen-art mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/gen-art
>>