bgp capabilities...

have at it... as if there wasn't enough already... this is borderline trivia...

https://tools.ietf.org/html/rfc5492

This specification defines an Optional Parameter and processing rules
   that allow BGP speakers to communicate capabilities in an OPEN
   message.  A pair of BGP speakers that supports this specification can
   establish the peering even when presented with unrecognized
   capabilities, so long as all capabilities required to support the
   peering are supported.

which means they're not a peer breaker...

note: route refresh appears as a capability in an open message, but it is also a message, type 5...

open, update, notification, keepalive and route refresh. in numerical order by type...

bgp notification...

to get a notification message, there needs to be an error... changing the neighbor remote-as will effect such an error...

look at the message types in rfc4271:

Type:

         This 1-octet unsigned integer indicates the type code of the
         message.  This document defines the following type codes:

                              1 - OPEN
                              2 - UPDATE
                              3 - NOTIFICATION
                              4 - KEEPALIVE

 open
   After a TCP connection is established, the first message sent by each
   side is an OPEN message.  If the OPEN message is acceptable, a
   KEEPALIVE message confirming the OPEN is sent back.

 UPDATE messages are used to transfer routing information between BGP
   peers. 

 An UPDATE message MAY simultaneously
   advertise a feasible route and withdraw multiple unfeasible routes
   from service.

 A NOTIFICATION message is sent when an error condition is detected.
   The BGP connection is closed immediately after it is sent.

Keepalive 

 BGP does not use any TCP-based, keep-alive mechanism to determine if
   peers are reachable.  Instead, KEEPALIVE messages are exchanged
   between peers often enough not to cause the Hold Timer to expire.