ReroutingManagement Class: definition or modeling lacks

the Class ReroutingManagement raise some doubts for management of this SituationRecord specialisation, it seems improvements are needed to achieve interoperable management.

in particular

- the attributes entry and exit which are String datatype seems better to be managed with Location Point reference than an undefined type as String, even if an exit Name or Number s String and a tesxtual description as MultilingualString for improving Exit / Entry understanding can help,  exact Location Information is more important. if this exact reference is embed to some other information it should better stated in the definition of further attributes
 

- as there is an option to have 0..* multeplicity for Itinerary, each having its own description reroutingItineraryDescription should be better associated to the alternativeRoute itself, i.e. it would be better an attribute of Itinerary.

- In the case in which the alternative route is not specified or only a Entrance e/o Exit point are stated  (as it is possible by issueing ReroutingManagementType as useExit, useEntry) there is a possible variety of options to set the Location Reference, setting the location as the advised/mandatory Exit/Entry Point itself seems the better option in this case to state information of Point to be used, without specifying the itinerary) but normally we would assume the Location addressed by Rerouting Management (as situation record group of Location / reference) is related to location for which the ReroutingManagement is applicable so it could be not only the single Exit/Entry decision point.