> On 02 Aug 2016, at 18:35, Balazs Lengyel wrote:
>
> Hello,
> If we allow foo and foo-state for opstate, mounting models atop such a multi
> rooted yang module will be fun.
> mount modB-config-part onto modA-config-part
> mount modB-state-part onto modA-state-part
> One mount becomes two and y
All,
The NETMOD Working Group has formed the Updated YANG Datastore Design Team.
The mandate for the DT is to build on the drafts [1] and [2] and
discussions related to using a conceptual datastore-based approach to
support vs configuration, and deliver a baseline
individual draft for discu
Balazs,
> On 2 Aug, 2016, at 10:29 AM, Balazs Lengyel
> wrote:
> I prefer a tight definition so even if we allow both 1) and 2) we should
> state that other combinations e.g. trees spliting close to the leaves or a
> mix of 1) and 2) in the same module are not allowed (VER STRONGLY
> dis
I don't know if we can make them a rule, but IMHO single-rooted
modules are definitely easier to use. E.g. just as a single
example: we only need one set of access control rules. Similar
double handling is needed often. I don't like foo-state trees.
Balazs
Hello,
If we allow foo and foo-state for opstate, mounting models atop such a
multi rooted yang module will be fun.
mount modB-config-part onto modA-config-part
mount modB-state-part onto modA-state-part
One mount becomes two and you have to maintain parallel mounts otherwise
you are mounting h
Hello,
Later I will try to provide a text proposal as well, but some
points:
I prefer a tight definition so even if we allow both 1) and
2) we should state that other combinations e.g. trees spliting
close to the leaves or a mix of 1) and 2) in the s
On Tue, Aug 02, 2016 at 01:12:34PM +0200, Ladislav Lhotka wrote:
>
> Yes, but if the YANG version is bumped, the client can immediately see
> that it is not compatible, and disconnect. In contrast, sec. 6.3.1 says
> that an extension "MAY be ignored in its entirety". According to the
> RFC 2119 se
Balazs Lengyel writes:
> Hello Lada,
>
> I see 2 statements in your mail:
>
> "Yes, but a client that doesn't understand them can still safely work
> with an NACM-aware server."
> IMHO simply ignoring security information is not acceptable in any
> way. So the nacm extensions are not "optional"
Hello Lada,
I see 2 statements in your mail:
"Yes, but a client that doesn't understand them can still
safely work with an NACM-aware server."
IMHO simply ignoring security information is not acceptable in any
way. So the nacm extensions are not "optional" e
