Ideally, you'd design your break points to happen only when they need to, based on your specific content. This is developing with a user-first kind of mentality: everything you do is geared towards providing the best, most highly-optimized experience for the user, no matter what.
This, however, takes a bit more care and development time. Also, it's not as easily maintained. If next month, you have to add another tab to your navigation, well now it might not fit very well on your medium screen size, so you'd have to adjust your break point or change your CSS just to handle that additional tab.
If you're okay with compromising slightly to gain several benefits, then using static breakpoints (like what you'll likely find already baked in to a grid framework) reduces development costs and allows you to develop more maintainable code. By sticking to static break points, you can more easily predict how things will lay out while developing. This leads to more rapid code production, with more predictable testing. The compromise here is that perhaps a couple pages are not as "custom-fit" to any given screen size without additional work.
(Personally, I opt for the latter, and special case only certain things that don't fit well within the predefined ranges.)