Kent Watsen wrote:
>
> > People want to use YANG to define the schema for an XML or JSON
> > representation of a stand-alone document.
>
> Agreed
>
>
> > The only data needed must be module + local-name.
>
> Or maybe: module + local-name + context, where context is one of:
>
> - data nodes
Hi All,
I plan to implement this draft and hence had some implementation related
clarifications.
1. I feel that there should be more text added about "origin" filtering
mechanism. I am not clear about some aspects of origin filtering.
RFC 8342 : NMDA RFC provides the below example
> People want to use YANG to define the schema for an XML or JSON
> representation of a stand-alone document.
Agreed
> The only data needed must be module + local-name.
Or maybe: module + local-name + context, where context is one of:
- data nodes
- RPC/actions
- notifications
- stand
On Mon, Apr 23, 2018 at 1:08 PM, Martin Bjorklund wrote:
> Andy Bierman wrote:
> > >
> > > >
> > > > I do not understand the need for a yang-data structure that
> represents
> > > data
> > > > that can be instantiated anywhere and everywhere.
> > >
> > > AFAIK noone is proposing that.
> > >
On Tue, 2018-04-24 at 16:36 +0200, Martin Bjorklund wrote:
> Ladislav Lhotka wrote:
> > Martin Bjorklund writes:
> >
> > > Hi,
> > >
> > > I am not sure what this statement tells us re. the issue in this email
> > > thread.
> >
> > It tells us that, in my view, the approach taken in this docume
Robert Wilton wrote:
>
>
> On 23/04/2018 21:08, Martin Bjorklund wrote:
> > Andy Bierman wrote:
> >>>
> I do not understand the need for a yang-data structure that represents
> >>> data
> that can be instantiated anywhere and everywhere.
> >>> AFAIK noone is proposing that.
> >>>
Ladislav Lhotka wrote:
> Robert Varga writes:
>
> > On 23/04/18 18:51, Juergen Schoenwaelder wrote:
> >> Some people will say that the cost of a new language version is high.
> >> (Well, when we did 1.1, some people said it will never be deployed.)
> >> Anyway, not bumping the YANG version numbe
Ladislav Lhotka wrote:
> Martin Bjorklund writes:
>
> > Hi,
> >
> > I am not sure what this statement tells us re. the issue in this email
> > thread.
>
> It tells us that, in my view, the approach taken in this document is a
> bad idea.
Do you mean that the WG shoud drop this document? And p
Martin Bjorklund writes:
> Hi,
>
> I am not sure what this statement tells us re. the issue in this email
> thread.
It tells us that, in my view, the approach taken in this document is a
bad idea.
Lada
>
>
> /martin
>
>
> Juergen Schoenwaelder wrote:
>> On Sun, Apr 22, 2018 at 02:56:51PM +020
Robert Varga writes:
> On 23/04/18 18:51, Juergen Schoenwaelder wrote:
>> Some people will say that the cost of a new language version is high.
>> (Well, when we did 1.1, some people said it will never be deployed.)
>> Anyway, not bumping the YANG version number but having instead several
>> (opt
Robert Wilton writes:
> [Renaming the thread because this doesn't seem to be directly applicable
> to the yang-data extension.]
>
> I think that extensions are great in the sense that they allow YANG to
> evolve more quickly without requiring a fork lift version upgrade that
> may take a long
Hi All,
Please find some comments for the draft.
1. If "config-filter" leaf is not given for whether we can add
explicit text that both config=true and config=false nodes will be selected.
2. In the YANG module description for "config-filter" , also it is not
clear about what hap
On 23/04/2018 21:08, Martin Bjorklund wrote:
Andy Bierman wrote:
I do not understand the need for a yang-data structure that represents
data
that can be instantiated anywhere and everywhere.
AFAIK noone is proposing that.
I do not want to break
existing tools that expect sibling da
[Renaming the thread because this doesn't seem to be directly applicable
to the yang-data extension.]
I think that extensions are great in the sense that they allow YANG to
evolve more quickly without requiring a fork lift version upgrade that
may take a long time to produce.
I agree that al
14 matches
Mail list logo