Hello,
I would like your support to clarify the usage of 'parent-reference' in the
schema-mount RFC 8528.
Let me take a simple example of a module 'profile-abc' that looks like this:
module: profile-abc
+--rw profile-abc
+--rw profile* [name]
+--rw name string
augment /if:interfaces/if:interface:
+--rw profile-abc-ref? -> /profile-abc/profile/name
Our NETCONF server implements a mount point, defined like this:
module mount-point-example {
...
container mount-point-example {
list mount-point {
key "name";
leaf name {
type string;
}
container root {
yangmnt:mount-point "root" {
description
"Root for example mount point.";
}
}
}
}
We are planning on supporting the module 'profile-abc' in both the parent
schema and the mounted schema:
* In the parent schema, clients will be able to create entries in the 'profile'
list.
* In the mounted schema, clients will be able to associate an interface with a
'profile' created in the parent schema.
In order to avoid clashes, our implementation will enforce that no 'profile'
list entries will be created under the mount-point.
For this mount-point, our NETCONF server will advertise parent-reference like
this:
{
"ietf-yang-schema-mount:schema-mounts": {
"namespace": [
{
"prefix": "pabc",
"uri": "urn:example:profile-abc"
},
],
"mount-point": [
{
"module": "mount-point-example",
"label": "root",
"shared-schema": {
"parent-reference": [
"/pabc:profile-abc/pabc:profile/pabc:name"
]
}
}
]
}
}
My question is the following:
Is the above implementation compliant with RFC8528? In other words, can the
same 'profile' list exists in the parent schema, which is accessible via
"parent-reference", and in the mounted schema, at the same time?
Note that the dummy module 'profile-abc' is in reality a standard module that
we cannot split in two parts.
RFC 8528 mentions: "This document allows mounting of complete data models only.
Other specifications may extend this model by defining additional mechanisms
such as mounting sub-hierarchies of a module.". Such mechanisms are not defined
(yet).
Regards,
Yves
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
