Every component parameter in RoIS 1.2 (and the RoIS 2.0 draft, if possible) must be instantiated and described in relation to the component.
As an example of detail missing for a PSM, there is a class named Direction with no properties or definitions for how a specific direction would be represented.

Revise the examples in Annex B and C to make them simple enough to understand the service scenario and restrictions described using RoSO. Consider using triple format instead of RDF/XML for easy understanding, but the machine-readable files need not be printed in the standard document.

In the scope section, Figure 1 and Figure 2 refer to the RoSO 1.0 RFP, which was issued in 2018. Figures and corresponding text to be update to refer to recent update such as OMG Commons 1.1.

Figures 1 and 2 are taken from the RoSO RFP, which was issued in 2018. The references to other standards need to be updated, and the main text in Section 1 (scope) and Section 3 (reference) need to be synchronized.

The name of AIST is to be corrected as 'National Institute of Advanced Industrial Science and Technology, Japan.'
That appears in section 6.1 and ontology metadata in section 7.

Avatar is conceptually not limited to a subclass of Robot. To be renamed to AvatarRobot.
The abstract concept of an Avatar is to be defined independently, based on the relationship with the Person.

Consider describing the relationship between classes using EquivalentClass, DisjointClass, etc. For example, Robot and Person seem to disjoint parts of Agent. References to Commons or CORA classes may use EquivalentClass.
IEEE RAS, however, does not provide CORA-owl officially. Is it possible to refer them in OWL?

Definitions of Commons are not included in the (non-normative) XMI.
Should a UML version of Commons be needed (not necessarily a bad idea), that should be achieved through an update to the Commons spec—which could be through the RTF or, at a pinch, by detailing the changes in this new submission in the Changes to Other Specifications section. In no circumstances should the Commons classes (or indeed lcc:Location or owl:Thing) be included in this XMI but referenced via hrefs.

None of the properties (association ends) are named, which is not allowed by MOF, e.g. 3 ownedAttributes of Action. It seems all the names are only on the Associations.
There are 3 instances of uml:Connector, which is not in the subset of UML supported by MOF.
Values are included for default values for upperValue, lowerValue, and isSubstitutable.

Section 3 has several references that are not required for this specification, e.g., Terminology Work, which might have been used to help author the definitions in the spec, but an implementor does not need access to those.