I am reviewing this draft on behalf of the BGP Directorate. 

I think this document addresses a real problem in a reasonable way, but it is not ready for advancement yet.

I agree that we should say in our documentation set, somehow, that the route resolvability condition means "a route can't be resolved if you can't forward using the resolved route". Perhaps this document is the right way to achieve that, although the WG might also want to consider whether it's been overtaken by events and rfc4271bis should cover it instead (or as well) in some form.

I have some questions and comments below. These are listed roughly in order of (my idea of) their significance.

1. I'm concerned that Section 3 is written in a way that seems imprecise. In our specs, imprecision can lead to two different implementors coming to different conclusions and failing to interoperate correctly. (Consider the "It is envisioned" language, for instance.) 
  I'm not saying that making this tighter would be easy. The base BGP spec has always been imprecise about the interaction between BGP's routing tables and the underlying system forwarding tables; this was true even when the forwarding table was IPv4 forwarding and nothing more. However, just because it's hard doesn't mean we should perpetuate it.

2. Has anyone conducted an implementation survey to see if two or more implementations comply with this spec? On the one hand, given its age and the importance of the problem it addresses, it's hard to imagine most implementations don't cover the issue somehow. On the other hand, given my critique of Section 3, I wonder if an implementor would be able to look at this spec and their implementation, and say "yes we comply" with confidence. If they can, that's good evidence that my concern is unfounded. If they can't, that's good input to improving the document.

3. Section 3 says,

   1) The next-hop reachability (check) SHOULD be resolved in a
      forwarding database of a particular data plane protocol.

Under what circumstances would it be sensible for an implementor to ignore this requirement? If there are such circumstances, consider noting them. If there are no such circumstances, consider making the SHOULD a MUST.

4. Section 3 says,

                     Note that it is not necessary to trigger the data-
   plane liveness mechanism for a given next-hop as a consequence of
   this check, though it may be an option. 
   
I cannot understand what this sentence means. 

5. Please proofread the draft before progressing it. Any commonly available grammar checker should be able to suggest some improvements; at the very least, a spelling check should be run (for example, "neigbhor").

6. "Bestpath" is not a defined term in RFC 4271. Even "path" isn't, in the sense used in this document; 4271 calls this a "route". We do have at least one instance of a published RFC (5004) that uses the term. Still, I think it would be good to supply a definition to the effect of "in this document, when we say 'best path,' what is meant is what RFC 4271 calls the 'selected route'."

7. The "dial-up link" example in the appendix seems quite dated!