Skip to main content

Telechat Review of draft-ietf-ospf-link-overload-10
review-ietf-ospf-link-overload-10-genart-telechat-halpern-2017-12-21-00

Request Review of draft-ietf-ospf-link-overload
Requested revision No specific revision (document currently at 16)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2018-01-23
Requested 2017-12-19
Authors Shraddha Hegde , Pushpasis Sarkar , Hannes Gredler , Mohan Nanduri , Luay Jalil
Draft last updated 2017-12-21
Completed reviews Rtgdir Last Call review of -09 by Martin Vigoureux (diff)
Genart Telechat review of -10 by Joel M. Halpern (diff)
Secdir Telechat review of -11 by Sean Turner (diff)
Opsdir Telechat review of -13 by Tim Chown (diff)
Genart Last Call review of -11 by Joel M. Halpern (diff)
Genart Telechat review of -12 by Joel M. Halpern (diff)
Assignment Reviewer Joel M. Halpern
State Completed Snapshot
Review review-ietf-ospf-link-overload-10-genart-telechat-halpern-2017-12-21
Reviewed revision 10 (document currently at 16)
Result Almost Ready
Completed 2017-12-21
review-ietf-ospf-link-overload-10-genart-telechat-halpern-2017-12-21-00
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 wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-ospf-link-overload-10
Reviewer: Joel Halpern
Review Date: 2017-12-21
IETF LC End Date: None
IESG Telechat date: 2018-01-25

Summary: This document is almost ready for publication as a Proposed Standard.

Major issues:
     If a remote IPv4 address is needed in some cases for link identification,
     then does it not follow that for IPv6 usage with OSPFv3, a remote IPv6
     address is also needed?

Minor issues:
    Why is the remote IPv4 address TLV being defined here?  It is not specific
    to link maintenance.  If this is the first place it is needed, could the
    text at least be clearer that this is a general purpose sub-TLV, not
    specific to the link maintenance indication?

Nits/editorial comments:
    Given that this document specifically states that the problem to be solved
    is the desire to take a link out of service, I would strongly prefer that
    the option being defined by named to match the goal.  The link being
    modified is not overloaded.  Could this be renamed the link
    pending-maintenance indication or something along those lines?  I realize
    the working group knows what it means.  But the point of naming is so that
    folks looking later can understand or find the item.