Hi Lou, thanks for the comment. I integrated them in the new version I’ll submit asap.
Thanks. s. > On Apr 24, 2017, at 6:15 PM, Lou Berger <lber...@labn.net> wrote: > > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review, and > sometimes on special request. The purpose of the review is to provide > assistance to the Routing ADs. For more information about the Routing > Directorate, please see > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF > Last Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-ietf-spring-resiliency-use-cases-08 > Reviewer: Lou Berger > Review Date: April 24 > Intended Status: Informational > > Summary: > > I have some minor comments about this document that I think would be > good, but not necessary, to be resolved before publication. > > Comments: > > This document is concise and clear. I only have minor/nit level issues > that could be addressed before publication, but I don't think it > critical as the document is being published as Informational. > > Major Issues: > > No major issues found. > > Minor Issues: > > - Section 2 mentions reversion, while sections 3 and 4 do not. > This leaves reversion requirements open to interpretation. > I suggest explicitly stating if reversion is a required > option or not in sections 3 and 4 as well. > > - Section 2 mentions 1:1 style path protection. Past/other work > on protection also allowed for / uses 1+1 style protection. Is > 1+1 intentionally omitted? If not, I suggest allowing for it. > > Nits: > >> referred to as local protection techniques or Fast Reroute >> techniques. > > References should be provided for each technique. > >> It is essential that the primary and backup path benefit from an end- >> to-end liveness monitoring/verification. The method and mechanisms >> that provide such liveness check are outside the scope of this >> document. > > Given the importance of liveness monitoring, I think it would be worth > mentioned an example of such. > > That's it! > Lou > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
