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
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
