Hi Joel, Thanks for the detailed review and comments. Pls see inline for replies. Rgds Shraddha -----Original Message----- From: Joel Halpern [mailto:jmh@xxxxxxxxxxxxxxx] Sent: Friday, December 22, 2017 5:04 AM To: gen-art@xxxxxxxx Cc: ospf@xxxxxxxx; ietf@xxxxxxxx; draft-ietf-ospf-link-overload.all@xxxxxxxx Subject: Genart telechat review of draft-ietf-ospf-link-overload-10 Reviewer: Joel Halpern Review result: Almost Ready 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://urldefense.proofpoint.com/v2/url?u=https-3A__trac.ietf.org_trac_gen_wiki_GenArtfaq&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=fPKCOPH32Vci8T4s7-Yd5jWslV2IjabEYm3R9_DaoFQ&s=NNAuYrMTe14MTajL9m6rdqAlGdBWqVvLAYWuh1dJW28&e=>. 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? <Shraddha>OSPFv3 already has mechanisms to identify the remote side link as it already has Interface-ID and Neighbor's Interface ID in its link description. I have added a detailed Section 4.5 which describes the need for Remote-IPv4 address in OSPFv2 and also covers why its not needed for OSPFv3. Pls see revision -11 for details. 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? <Shraddha> New section added with the reasoning as described above. 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. <Shraddha> I think overload is common terminology used for maintenance operations. Similar feature for taking out Nodes from network is called "overload" in ISIS. The same feature Is called "stub router" in OSPF. "stub link" has a different meaning in OSPF so the best choice Was to use "link-overload".