Christian Hopps writes:
> Juergen Schoenwaelder writes:
>
>> On Fri, Feb 03, 2017 at 08:40:06AM -0500, Christian Hopps wrote:
>>>
>>> Is it allowed for a server to implement a module that augments another
>>> module that it does not
On Wed, Feb 08, 2017 at 04:04:11PM -0500, Lou Berger wrote:
>
> I defer to Chris on us of RPCs in general, but an interesting use case
> that is supported with RPCs is tag modification in RO modules.
>
No, you are simply hiding configuration data behind RPCs. Somewhere
the tags need to be
Lou Berger wrote:
>
>
> On 2/8/2017 3:34 PM, Martin Bjorklund wrote:
> > Juergen Schoenwaelder wrote:
> >> On Wed, Feb 08, 2017 at 01:22:01PM -0500, Christian Hopps wrote:
> >>> Lou Berger writes:
> >>>
> On
Juergen Schoenwaelder wrote:
> On Wed, Feb 08, 2017 at 01:22:01PM -0500, Christian Hopps wrote:
> >
> > Lou Berger writes:
> >
> > > On February 8, 2017 10:16:14 AM Juergen Schoenwaelder
> > > wrote:
On Wed, Feb 08, 2017 at 01:22:01PM -0500, Christian Hopps wrote:
>
> Lou Berger writes:
>
> > On February 8, 2017 10:16:14 AM Juergen Schoenwaelder
> > wrote:
> > ...
> >>
> >> We should perhaps start a separate thread but I fail to see
Juergen Schoenwaelder writes:
> On Wed, Feb 08, 2017 at 09:06:19AM -0500, Christian Hopps wrote:
>>
>> We also went with the split route with our tags draft.
>>
>> https://datatracker.ietf.org/doc/draft-rtgyangdt-netmod-module-tags/
> Also note that
Lou Berger writes:
> On February 8, 2017 10:16:14 AM Juergen Schoenwaelder
> wrote:
> ...
>>
>> We should perhaps start a separate thread but I fail to see why tags
>> require new editing primitives.
>
> It was an intentional design
On February 8, 2017 10:16:14 AM Juergen Schoenwaelder
wrote:
...
We should perhaps start a separate thread but I fail to see why tags
require new editing primitives.
It was an intentional design choice/preference by one of the authors.
Basically,
On Wed, Feb 08, 2017 at 04:11:01PM +0100, Martin Bjorklund wrote:
> Juergen Schoenwaelder wrote:
> > On Wed, Feb 08, 2017 at 09:06:19AM -0500, Christian Hopps wrote:
> > >
> > > We also went with the split route with our tags draft.
> > >
> > >
Juergen Schoenwaelder wrote:
> On Wed, Feb 08, 2017 at 09:06:19AM -0500, Christian Hopps wrote:
> >
> > We also went with the split route with our tags draft.
> >
> > https://datatracker.ietf.org/doc/draft-rtgyangdt-netmod-module-tags/
> >
> > Features
On Wed, Feb 08, 2017 at 09:06:19AM -0500, Christian Hopps wrote:
>
> We also went with the split route with our tags draft.
>
> https://datatracker.ietf.org/doc/draft-rtgyangdt-netmod-module-tags/
>
> Features like deviations were not liked internally by the group. 2
> modules seemed like the
We also went with the split route with our tags draft.
https://datatracker.ietf.org/doc/draft-rtgyangdt-netmod-module-tags/
Features like deviations were not liked internally by the group. 2
modules seemed like the KISS approach.
Thanks,
Chris.
Balazs Lengyel
My earlier problem was that if I do not implement the augmented module
(modA) even if the augment is switched off by a feature, I still need to
have the NOT implemented augmented module (modA) in yang-library to
satisfy the import statement of the augmenting module (modB). So I
decided to
On Sat, Feb 4, 2017 at 9:27 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:
> On Sat, Feb 04, 2017 at 11:59:48AM -0500, Christian Hopps wrote:
> >
> > How does one check whether a feature is implemented or not? I couldn't
> > quite figure this out from reading the STD.
>
On Sat, Feb 04, 2017 at 11:59:48AM -0500, Christian Hopps wrote:
>
> How does one check whether a feature is implemented or not? I couldn't
> quite figure this out from reading the STD.
>
Since YANG 1.1, features are announced in /modules-state/module/feature
in ietf-yang-library defined RFC
Juergen Schoenwaelder writes:
> On Fri, Feb 03, 2017 at 11:30:42AM -0500, Christian Hopps wrote:
>>
>> Well sure it's odd for an augmenting only module. In my case I'm adding
>> a feature to another module that is not required for my module to be
>> useful.
On Fri, Feb 03, 2017 at 12:45:44PM -0500, Lou Berger wrote:
> Is it cleaner/preferable to do this or to have two models, one with the core
> definitions and one with the augmentations?
I do not think there is a clear cut rule for this.
/js
--
Juergen Schoenwaelder Jacobs University
Is it cleaner/preferable to do this or to have two models, one with the
core definitions and one with the augmentations?
Lou
On February 3, 2017 11:43:56 AM Juergen Schoenwaelder
wrote:
On Fri, Feb 03, 2017 at 11:30:42AM -0500, Christian Hopps wrote:
On Fri, Feb 3, 2017 at 8:43 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:
> On Fri, Feb 03, 2017 at 11:30:42AM -0500, Christian Hopps wrote:
> >
> > Well sure it's odd for an augmenting only module. In my case I'm adding
> > a feature to another module that is not
On Fri, Feb 03, 2017 at 11:30:42AM -0500, Christian Hopps wrote:
>
> Well sure it's odd for an augmenting only module. In my case I'm adding
> a feature to another module that is not required for my module to be
> useful. My module is quite simple, conversely the module it augments
> (yang
Juergen Schoenwaelder writes:
> On Fri, Feb 03, 2017 at 08:40:06AM -0500, Christian Hopps wrote:
>>
>> Is it allowed for a server to implement a module that augments another
>> module that it does not implement? My thinking was that the augment
>> would
On Fri, Feb 03, 2017 at 08:40:06AM -0500, Christian Hopps wrote:
>
> Is it allowed for a server to implement a module that augments another
> module that it does not implement? My thinking was that the augment
> would simply not be implemented in this case. Is that true or must the
> server
Hi,
Is it allowed for a server to implement a module that augments another
module that it does not implement? My thinking was that the augment
would simply not be implemented in this case. Is that true or must the
server implement any and all augmented modules referenced by a module?
Thanks,
23 matches
Mail list logo