Hi, I'm sending updated document of MDM circuit monitoring. Aaron, Jason, all, you can find a simplified version of client access algorithm (section 5.3.2) but it still supports that one that you formulated some time ago and we all accepted. It is simplified because some assumptions have been made in the use case with AutoBAHN (see the picture in 5.3.2). Please, take a look at the examples of messages for this algorithm but also for the workflow presented in 5.2.1. Check if massages from and to the MA(at)/MA(t) are compatible with those for the pS-PS TS. Also take a look at the example of massage that is sent from the hLS to the gLS (section 9.2.3). Some time ago we were talking about capabilities and dropping the service type field in the lookup information. I found it very useful while working on the examples of messages. Although the MA services (MA(at) and MA(t)) store the topology information they can be treated as the pS-PS TS if they support topology storage functionality and register that with the hLS. Take a look at the examples of LSRegisterRequest type (I've used the parameter eventType but probably normal eventType element would be more suitable; but first I'd like to see your comments). So far I've proposed 6 capabilities: http://ggf.org/ns/nmwg/ops/storage/measurement/2.0 (for MA) http://ggf.org/ns/nmwg/ops/storage/measurement/aggregated/autobahn/2.0 (for MA with data aggregated by AutoBAHN) http://ggf.org/ns/nmwg/ops/creation/measurement/2.0 (for MP) http://ggf.org/ns/nmwg/ops/integration/autobahn/2.0 (for SIP which connects pS with AutoBAHN) http://ggf.org/ns/nmwg/ops/storage/topology/2.0 (for TS or MA(t) which store topology information) http://ggf.org/ns/nmwg/ops/storage/topology/aggregated/autobahn/2.0 (for TS or MA (at) which store the topology information aggregated by AutoBAHN) waiting for your comments Cheers, Roman