Another and somewhat radical idea is to think of 'yang-data' as defining a data
node, like a 'container', but not a config or opstate node. Yes, this is
different from rc:yang-data, which defines a transparent node, like 'choice',
but maybe it's okay if we can get the substitution groups part working. For
instance:
From draft-ietf-anima-voucher:
OLD:
rc:yang-data voucher-artifact {
container voucher {…}
}
NEW:
yd:yang-data voucher {
…
}
From draft-ietf-netconf-zerotouch:
OLD
rc:yang-data "zerotouch-information" {
choice information-type {
container redirect-information {…}
container onboarding-information {…}
}
}
NEW
yd:yang-data "redirect-information" {
yd:substitution-group zerotouch-information;
…
}
yd:yang-data "onboarding-information" {
yd:substitution-group zerotouch-information;
…
}
And for the error-info use-case:
yd:yang-data "error-info" {
choice error-type {
leaf my-error1 {…}
leaf my-error2 {…}
}
}
Thoughts?
Kent
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
