I think this is a good strategy.
I have two comments:
1) As already mentionned by Vishal, we cannot,
IMHO, decorrelate 6 from 1, 2 3 and 5.
-The support of additional functions may require important
modifications, if they are not taken into account during the
initial step of specifications.
-Path Reoptimization is a MUST requirement and Path diversity is a
SHOULD requirement ( inter-area and inter-as reqt drafts). So we
should not address them as advanced functions, but rather as base
functions of the inter-area/AS tool-kit.
2) I'm not sure to well understand what do you put in 3. What do you exaclty mean by routing model, and how do you distinguish it from the path computation model ?
Requirement drafts clearly point out that routing (IGP, EGP) extensions should be avoided, except some minor extensions to advertise static parameters such as PCS capabilities for instance (addressed in point 5).
Hope this will help.