Nice feature:-), but I believe it’s a bug - according to RFC 6241, there should be one RPC inside
<rpc>...</rpc> - an obvious problem with the above is seen in the reply:
You actually made two RPC invocations, but got only one result.
Other than this “trick”/bug, there is indeed no way to have multiple subscriptions in one session, i.e. you can’t do two
<rpc><create-subscription>...</create-subscription></rpc> in one session - see https://tools.ietf.org/html/rfc5277#section-6.5 (ConfD supports the :interleave capability, but it only allows for other RPCs).
I’m not sure about the rationale for this restriction, but one problem with having multiple subscriptions in one session is that there is no way for the client to know which stream the individual notifications “belong to”. In any case it shouldn’t be a problem for a capable client, it just needs to open another SSH “channel” (becomes a separate NETCONF session) within the same SSH connection for each additional subscription.