Re: [Roll] Ralph Droms' No Objection on draft-ietf-roll-minrank-hysteresis-of-11: (with COMMENT)

[Omprakash Gnawali <[e-mail]>]

We can work with the RFC editor on those comments from Ralf. Thanks.

- om_p

On Tue, Jul 10, 2012 at 1:57 PM, Adrian Farrel <[e-mail]> wrote:
> Authors,
>
> Although the Discusses are now cleared thanks to your latest revision, it would be good if you could look at the comments that Ralph has raised.
>
> Are there changes you would like to make to address these comments? Will you spin a new revisions or can you express them in RFC Editor notes?
>
> Thanks,
> Adrian
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of Ralph
>> Droms
>> Sent: 08 July 2012 01:29
>> To: The IESG
>> Cc: roll; [e-mail]; roll-
>> [e-mail]
>> Subject: Ralph Droms' No Objection on draft-ietf-roll-minrank-hysteresis-of-11:
>> (with COMMENT)
>>
>> Ralph Droms has entered the following ballot position for
>> draft-ietf-roll-minrank-hysteresis-of-11: No Objection
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> 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?
>
>