Definition of "Ready" not in the Scrum-Guide

Yes, this is intentional as the Definition of Ready is not defined as part of Scrum, it is a complimentary practice, but not something that must be done in Scrum, therefore not addressed in the Guide.  The Scrum Guide provides the core concepts of Scrum as defined as what is to be accomplished with Scrum. As a framework, process evolves on top of Scrum based on the right practices for you and your team.  There are thousands of complimentary practices that can be applied on top of Scrum and some are good for one team, but not right for the others, hence only putting the framework content in the Scrum Guide.  Definition of Ready is one such practice.

"Ready" can be thought of as a function of the Definition of Done. The Scrum Guide says: "Product Backlog items that can be "Done" by the Development Team within one Sprint are deemed "Ready" for selection in a Sprint Planning".

"Definition of Ready" can be taken too far at times, and I am not a fan of this complimentary practice. I have seen it become a contract between the Development Team and Product Owner. Some folks even call it a gate. As an example, if everything isn't perfect for a Product Backlog item and every box isn't checked, then the Dev Team refuses to bring it into the Sprint Backlog. How agile is that?

The DoR used properly is a good thing. Used wrongly, it is absolutely not agile. "Ready" can be as simple as a state of mind or a check list to go through in refinement. The important thing, like Chris mentioned, if the a DoR becomes a gate or is weaponized in any way; throw it out. "How can that be weaponized" you say? Easier than you think. 

The Dev team can use it against the PO "Yeah, Mr PO, I get that this feature is super important but it doesn't meet the DoR so we are not going to bring it into the sprint at all". 

Stakeholders, management, or even the PO can weaponize it. "You didn't complete the items you brought into the sprint? Did they meet the DoR? Why would you bring something in that didn't meet the DoR?" 

It can be twisted in many different ways so you must be careful when using it. One thing that I've found as a good guide is too look at the INVEST criteria and consider that a DoR. It isn't iron clad, it's really just a reminder for the team to consider during refinement and/or planning.

A Definition of Done helps everyone understand when the work they are doing becomes a potentially releasable increment of value. A Defintion of Ready is a gate to being able to get work started.  Too often the Defintion of Ready becomes an excuse to fully design something before you start to work which is very much a waterfall practice.  Those types Definitions of Ready remove the ability to inspect and adapt as you work.  

I coach that you do not want a Definition of Ready because it becomes a "contract".  Instead you want to have a common agreement that everyone knows enough to get started on the work and as new information is found, they will adapt. 

In Scrum Guide, under Product Backlog you will find the following phrase. Please read about the Product Backlog and PBR (Product backlog refinement) to understand what "ready " means in the contest of a PBI being ready considered into the next Sprint Planning meeting.

"Product Backlog items that can be "Done" by the Development Team within one Sprint are deemed "Ready" for selection in a Sprint Planning. Product Backlog items usually acquire this degree of transparency through the above described refining activities." - Scrum Guide