• Revised I-D Needed - Issue raised by WG
  • Awaiting Expert Review/Resolution of Issues Raised
  • Awaiting External Review/Resolution of Issues Raised
  • Awaiting Merge with Other Document
  • Author or Editor Needed
  • Waiting for Referenced Document
  • Waiting for Referencing Document
  • Revised I-D Needed - Issue raised by WGLC
  • Revised I-D Needed - Issue raised by AD
  • Revised I-D Needed - Issue raised by IESG
  • Doc Shepherd Follow-up Underway
  • Other - see Comment Log

IETF :: roll

Current state: WG Document

Viewing the last 20 entries. Show full log.

(System)

RFC published

Michael Richardson

Changed shepherd to JP Vasseur

(System)

IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor

Cindy Morgan

State changed to RFC Ed Queue from Approved-announcement sent

(System)

IANA Action state changed to Waiting on RFC Editor from Waiting on Authors

(System)

IANA Action state changed to Waiting on Authors from In Progress

(System)

IANA Action state changed to In Progress

Cindy Morgan

State changed to Approved-announcement sent from IESG Evaluation::AD Followup

Cindy Morgan

IESG has approved the document

Cindy Morgan

Closed "Approve" ballot

Cindy Morgan

Ballot approval text was generated

Adrian Farrel

Ballot approval text was changed

Adrian Farrel

Ballot approval text was generated

Adrian Farrel

Ballot writeup was changed

Ralph Droms

[Ballot 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?

Ralph Droms

Ballot comment text updated for Ralph Droms

Ralph Droms

[Ballot comment]

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?

Ralph Droms

[Ballot Position Update] Position for Ralph Droms has been changed to No Objection from Discuss

Brian Haberman

[Ballot Position Update] Position for Brian Haberman has been changed to No Objection from Discuss

Martin Stiemerling

[Ballot comment]
I have cleared and thank you for addressing my concerns.

Viewing the last 20 entries. Show full log.