The Minimum Rank with Hysteresis Objective Function
Note: This ballot was opened for revision 09 and is now closed.
(Stewart Bryant) Yes
(Adrian Farrel) Yes
(Ron Bonica) No Objection
(Gonzalo Camarillo) No Objection
Benoit Claise No Objection
(Ralph Droms) (was Discuss) No Objection
Thank you for addressing my Discuss points in the most recent rev of this document. I've cleared my Discuss. While these comments are non-blocking, they should be considered carefully as they are based on implementation experience with this draft. 1. The second component of the path cost in section 3.1: 2. The value of the selected metric in the metric container in the DIO sent by that neighbor. is incompletely described. While an implementor should realize from section 3.5 that the rank advertised by the neighbor is an approximation for ETX and should be used here, the text as written is incomplete. 2. Also for completeness, the document should specify the representation used for ETX to be used in path cost computation; e.g., as specified for the ETX sub-object in RFC 6551. 3. Related to point 2, explanation of the relationship between the representation used for ETX and rank should be explained, especially considering what I think will be unexpected side effects of the value of DEFAULT_MIN_HOP_RANK_INCREASE defined to be 256 in RFC 6550 interacting with the (presumed) default representation of ETX as defines in RFC 6551. 4. In section 3.4: If ETX is the selected metric, a node SHOULD NOT advertise it in a metric container. s/SHOULD NOT/MUST NOT/ (and this text is redundant relative to the last sentence of section 3.5). 5. Are the parameter values in section 5 recommended only for use when the selected metric is ETX; seems to me MAX_LINK_METRIC, MAX_PATH_COST and PARENT_SWITCH_THRESHOLD depend on the selected metric and the recommended values wouldn't make much sense for, e.g., hop count. These comments are purely editorial and offered to improve the clarity of the document. 1. The paragraph immediately following table seems superfluous. The list of metrics for which the rank is undefined is not complete (from RFC 6551). The paragraph begs the question "why would the deployment choose a metric for which the rank is undefined?" 2. Readability would be improved by writing the details of the special-case treatment of ETX (currently in section 3.5) to the point at which that special-case treatment modifies other behavior specified in the document; e.g., the second component of the path cost cited above. 3. The second sentence of section 6 is pretty opaque. Is the point that the "List of supported metrics" from section 18.2.3 need not be supported if MRHOF is used? 4. Isn't the last paragraph of section 6.1 true for any selected metric?
(Wesley Eddy) No Objection
Comment (2012-05-09 for -10)
I support point 2 of Brian's DISCUSS.
(Stephen Farrell) No Objection
Comment (2012-05-09 for -10)
- Hysteresis could do with a definition - many non-native English speakers (and native speakers!) might have to go look it up so why not save them the trouble? - ETX is used without expansion of reference in the intro. Link color is used in 3.3 but not defined. It'd be good to be clearer that those are defined in 6551. - This smells experimental to me. I wondered if it had already been implemented/tested. (Not a requirement for PS, so I'm just asking.) - You RECOMMEND use of security mechanisms if there is a risk. Can't you be more specific on which security mechanism you mean (e.g. referring to the right bit of 6550, maybe 10.6)? I've not made this a discuss since I hold one on the security framework and perhaps the inability to pick something concrete here will be resolved as a side-effect of that.
(Brian Haberman) (was Discuss) No Objection
(Russ Housley) No Objection
Comment (2012-05-06 for -10)
Please consider the editorial issues raise in the Gen-ART Review by Miguel Garcia on 27-Mar-2012. The review can be found here: http://www.ietf.org/mail-archive/web/gen-art/current/msg07303.html
(Barry Leiba) No Objection
Comment (2012-04-29 for -10)
Substantive comments; please adopt or respond to these: Nice, easy-to-read document. Only one substantive comment, about 2119 language: -- Section 3.2.1 -- The use of SHOULD and MAY here is inconsistent -- the MAY turns the SHOULD into something more optional than a SHOULD ought to be. I suggest not using MAY, and rephrasing this way (unless I misunderstand the meaning here): NEW If, despite the above, it is necessary to defer the parent selection until a later time, note that doing so can delay the use of better paths available in the network. ======== Editorial suggestions. No need to respond to these; take them or modify them as you please: -- Section 1 -- Because MRHOF seeks to minimize path costs as described by metrics, it can only be used with additive metrics. MRHOF ignores metrics that are not additive. Is it really "ignores"? Or "does not support"? -- Section 2 -- OLD Path cost is obtained by summing up the selected metric of the links or nodes along the path. NEW Path cost is obtained by summing up the values of the selected metric for the links or nodes along the path.
(Pete Resnick) No Objection
(Robert Sparks) No Objection
Comment (2012-05-07 for -10)
I made the same observations in my review that Barry reports in his comments. Please also consider clarifying that no one node sums up the values of the selected metrics in the definition of path cost - rather, each node adds to the cost reported by the parent (section 3.1) resulting in a total for the path.
(Martin Stiemerling) (was Discuss) No Objection
I have cleared and thank you for addressing my concerns.