Lou,
Thanks for the quick reply. Your proposed edits look fine.
Steve
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
