Hi Steve,
Thanks for the comments!
On 3/20/2019 11:21 AM, Stephen Kent via Datatracker wrote:
Reviewer: Stephen Kent
Review result: Has Nits
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written with the intent of improving security requirements and
considerations in IETF drafts. Comments not addressed in last call may be
included in AD reviews during the IESG review. Document editors and WG chairs
should treat these comments just like any other last call comments.
Review Summary: Ready with nits
This brief document defines and extension to DLEP That enables a modem to use
DLEP to pause and resume inbound traffic from a specific peer. DLEP (RFC 8175)
cites GTSM as a security mechanism, which is rather weak, but it says that
implementations SHOULD use TLS (1.2), which is fine.
The text states that “An example of when a modem might send this data item is
when an internal queue length exceeds a particular threshold.” However, all of
details of this data item seem to focus exclusively on queues. Thus it seems
likely that this is not just an example, but, rather, the primary motivation
for introducing the pause extension. A slight rewording of the text here seems
appropriate, or the authors could describe other (not-queue-based) examples.
fair point, how about:
OLD:
An example of when a modem might send
this data item is when an internal queue length exceeds a particular
threshold.
NEW:
The motivating use case is for this data item is when a modem's internal
queue length exceeds a particular threshold. Other use cases are
possible, e.g., when there a non queue related congestion points within
a modem, but such are not explicitly described in this document.
The Security Considerations section of 8175 addresses a reasonable range of
concerns. Thus it is appropriate that this document’s Security Considerations
section is very brief, as it cites the corresponding section in 8175. I suggest
a couple of minor change to the wording here:
“The extension does not inherently introduce any additional threats …
->
“The extension does not inherently introduce any additional vulnerabilities …”
“ … but this is not a substantively different threat by …”
->
“ … but this is not a substantively different attack by …”
There are numerous examples of awkward/poor phrasing throughout the document,
which I hope the RFC Editor will correct, e.g.,
Abstract:
“…to the DLEP protocol …” -> “… to DLEP …”
Hopefully these have already been corrected, if not I'm sure the editor
will help us out.
page 7:
“A modem can indicate that traffic is to be suppressed on a device wide or
destination specific basis.”
“A modem can indicate that traffic is to be suppressed on a device- wide or
destination-specific basis.”
Thanks.
“This includes that to indicate that transmission can resume to all
destinations …”
“Thus, to indicate that transmission can resume to all destinations, …”
I'm not sure thus is quite right, but will revise!
Thanks again!,
Lou
