Hi, My comments 2 and 3 are covered, thanks.
My first comment, that the introduction section is rather muddled / unclear, still holds. I don't see that this has been changed; I think all the text is in there, it just doesn't flow well (to me). Whether you change it, is up to you. I'd suggest if you do change it that the structure covers: the problem, the current tools that can be used, why/where those tools do not solve the problem, and then the solution defined in the document. Best wishes, Tim > On 31 Jan 2018, at 03:47, Shraddha Hegde <shrad...@juniper.net> wrote: > > Tim, > > Thanks for the review and comments. > Pls see inline for responses. > > -----Original Message----- > From: Tim Chown [mailto:tim.ch...@jisc.ac.uk] > Sent: Monday, January 22, 2018 8:25 PM > To: ops-...@ietf.org > Cc: ospf@ietf.org; draft-ietf-ospf-link-overload....@ietf.org > Subject: Opsdir telechat review of draft-ietf-ospf-link-overload-13 > > Reviewer: Tim Chown > Review result: Ready > > Hi, > > I have reviewed this document as part of the Operational directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written with the intent of improving the operational > aspects of the IETF drafts. Comments that are not addressed in last call may > be included in AD reviews during the IESG review. Document editors and WG > chairs should treat these comments just like any other last call comments. > > This document defines mechanism(s) to allow OSPF routers to indicate that a > specific link, rather than a whole node, is entering an imminent maintenance > state, to allow other devices that understand the protocol extension(s) to > more gracefully re-route traffic around the affected link. > > I believe the document is Ready for publication. I have only three minor > comments below, which the authors may choose to act on. > > Overall the document reads reasonably well. Not being overly familiar with > the material, I needed to read it through end-to-end more than once to better > understand its scope and intent. My first comment would be that perhaps the > introduction section could be better written; the abstract seemed clear on > the purpose of the draft, while the introduction felt a little muddled. > Sections 2, 3 and 4, which detail the motivations and extensions, were much > clearer. > <Shraddha> Added more text to introduction section in version -14. Pls check > if it looks better now. > > Secondly, there are some minor typographic errors throughout the document, > generally missing (in)definite articles. While the RFC Editor would pick > these up, it would be nice for the authors to have a final pass and fix those > before submission. > <Shraddha> Ack. > > Thirdly, the document does not give any advice on the timing of using the > extensions - how far in advance is it recommended to use the extensions? - or > on the return to 'normal' state once the maintenance is completed. So > perhaps consider adding a short section on this, maybe in Section 5. > <Shraddha> Added below details to section 5 > > When a link is ready to carry traffic, the Graceful-Lnk-Shutdown sub-TLV > should be removed from the Extended Link TLV/Router-Link TLV and the > corresponding > LSAs MUST be readvertised. > > Best wishes, > Tim > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
