It all depends on the definition of responsibility and how that definition is going to impact maintenance of your code. Everything boils down to one thing and that is how your design is going to help you in maintaining your code.
And Like someone said "Walking on water and designing software from given specs is easy, provided both are frozen" .
So, if we are defining responsibility in more concrete way, then we don't need to change it.
Sometimes responsibilities will be glaringly obvious, but sometimes it might be subtle and we need to judiciously decide.
Suppose, we add another responsibility to Dog class named catchThief(). Now it might be leading towards an additional different responsibility. Tomorrow, if the way Dog is catching thief has to be changed by Police Dept, then Dog class will have to be changed. It would be better to create another subclass in this case and name it ThiefCathcerDog. But in a different view, if we are sure that it is not going to change in any circumstance, or the way catchThief has been implemented is dependent on some external parameter, then it is perfectly ok to have this responsibility. If responsibilities are not strikingly odd then we have to decide it judiciously based on the use case.