RtgDir Early review: draft-ietf-rtgwg-routing-timer-param-sync-00.txt Hello I have been selected to do a routing directorate "early" review of this draft. https://datatracker.ietf.org/doc/draft-ietf-rtgwg-routing-timer-param-sync-00.txt The routing directorate will, on request from the working group chair, perform an "early" review of a draft before it is submitted for publication to the IESG. The early review can be performed at any time during the draft's lifetime as a working group document. The purpose of the early review depends on the stage that the document has reached. * As this document has recently been adopted by the working group, my focus for the review is on providing a new perspective on the work, with the intention of catching any issues early on in the document's life cycle. For more information about the Routing Directorate, please see =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Comments as I read: 1) while the table of contents hints that this is about ISIS and OSPF, and perhaps other link-state algorithms, this should probably go into the abstract and intro. 2) On first read, I think that the "routing convergence timer value" is not the same value as the "network wide convergence time value". Perhaps it is? 3) please give the Timer Param Sync protocol a clear name. Not crazy about that name. Followup comments: * While the document tried to describe the Timer Parameter functionality seperate from the first use of the parameter (fast-reroute), it failed to tell me anything about the new protocol other than bits on the wire. I would like the ISIS/OSPF diagrams to more cleary refer subtype to the new "Routing Timer Parameter Synchronization Registry". I'm unclear what a router does when it sees one of these parameters in the flood. Does it flood the same value? How does it's preference value interact with the value presented? I think that this document might be better split up into two documents, one explaining the Timer Parameter Sync protocol, and the other explaining how to use it to implement the fast-reroute value. I think that there are values where the converged value is MAX(values-seen), and some that might be MIN(values-seen), and both might have hard coded upper and lower bounds. I wonder if the Timer Param Sync shouldn't describe the parameter processing with another value? Would it be useful for intermediate routers to perform the MAX() or MIN() operation even if they don't understand the parameter being synchronized? Or should they drop these TLVs with unknown sub-types? I would feel happier with two documents as well because then for each parameter being synchronized, the security considerations could more reasonably explain what unreasonable values are, and how to recognize silly values. Security does not just defend against malicious actors, but also just mis-configured (fat-fingered) ones. Nits pg2: s/parameter is fraught for two reasons/ parameter is fraught with danger for two reasons/ pg3: Such consistency may be ensured by deploying automated means such as enforcing the new value by invoking the management interface of all involved routers. --> seems like a word might be missing? section5.1: s/new router in introduced/new router is introduced/