Skip to main content

Last Call Review of draft-ietf-manet-olsrv2-dat-metric-08
review-ietf-manet-olsrv2-dat-metric-08-genart-lc-kyzivat-2015-11-20-00

Request Review of draft-ietf-manet-olsrv2-dat-metric
Requested revision No specific revision (document currently at 12)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2015-11-23
Requested 2015-11-05
Authors Henning Rogge , Emmanuel Baccelli
I-D last updated 2015-11-20
Completed reviews Genart Last Call review of -08 by Paul Kyzivat (diff)
Genart Telechat review of -10 by Paul Kyzivat (diff)
Secdir Last Call review of -08 by Dacheng Zhang (diff)
Opsdir Last Call review of -08 by Will (Shucheng) LIU (diff)
Assignment Reviewer Paul Kyzivat
State Completed
Request Last Call review on draft-ietf-manet-olsrv2-dat-metric by General Area Review Team (Gen-ART) Assigned
Reviewed revision 08 (document currently at 12)
Result Ready w/nits
Completed 2015-11-20
review-ietf-manet-olsrv2-dat-metric-08-genart-lc-kyzivat-2015-11-20-00
[In progress - not ready for sending]

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed by the
IESG for the IETF Chair. Please treat these comments just like any other
last call comments. For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-manet-olsrv2-dat-metric-08
Reviewer: Paul Kyzivat
Review Date: TBS
IETF LC End Date: 2015-11-23
IESG Telechat date: 2015-12-03

Summary:

This draft is basically ready for publication as an Experimental RFC,
but has nits that should be fixed before publication.

Major: 0
Minor: 0
Nits:  5

Nits:

* Section 1:

"Appendix A contains a few possible steps to improve the DAT metric."

This is the first occurrence of the "DAT" acronym. It took me a bit to
realize this must be referring to "Directional AirTime". Could you
please define the acronym *before* the first use? (Perhaps in the prior
paragraph where "Directional Airtime" is first used.)

* Section 2:

"These networks employ link layer retransmission to increase the
delivery probability and multiple unicast data rates."

I'm not sure how to parse this sentence. Is it intended to be:

"These networks employ link layer retransmission to increase (the
delivery probability) and (multiple unicast data rates)."

OR "These networks employ link layer retransmission to (increase the
delivery probability) and (multiple unicast data rates)."

Either way I don't understand what "multiple unicast data rates" means.
Can you clarify this?

* Section 7:

You call these *constants*, in contrast to the *parameters* defined in
section 6. But you then suggest conditions under which they could be
changed. Perhaps they should simply be included with the parameters, but
with strong warnings about diverging from the recommended values.

Else, it would be good to define these *before* the parameters, because
that would avoid the forward reference to DAT_MAXIMUM_LOSS.

* Section 9.3/9.4:

Are you considering these to be mutually exclusive? Or is a HELLO
message processed first by 9.3, and then by 9.4?

Since there is considerable overlap in processing between the two, and
it would presumably be wrong to do that twice, I guess you must assume
them to be mutually exclusive. But I presume HELLO messages arrive in
incoming packets, so 9.3 sounds like it ought to apply to them.

If I guessed right, then I suggest revising 9.3 to start "For each
incoming packet that is not a HELLO message, ..."

* Section 10.2:

IIUC steps 5.3 & 5.4 are just the hard way of saying:

   bitrate := MAX(L_DAT_rx_bitrate, DAT_MINIMUM_BITRATE)