"Bogaert, Bart (Nokia - BE)" wrote:
> -Original Message-
> From: Martin Bjorklund [mailto:m...@tail-f.com]
> Sent: 24 January 2017 11:37
> To: Bogaert, Bart (Nokia - BE)
> Cc: j.schoenwael...@jacobs-university.de; netmod@ietf.org
> Subject: Re: [netmod] I-D Action: draft-ietf-netmod-enti
Juergen Schoenwaelder wrote:
> Hi,
>
> my experience is that when writing YANG modules it is tremendously
> helpful to focus on the instance documents. I find it essential to
> write down example snippets of instance documents to see whether they
> look elegant or clumsy. This is often not easy t
Juergen Schoenwaelder wrote:
> On Fri, Mar 03, 2017 at 04:41:44PM +, Kent Watsen wrote:
> >
> > All,
> >
> > Lou and I were discussing how it seems unnecessary that every draft
> > has the same boilerplate text regarding how to interpret tree diagram
> > notations. It would be nice if draft
Robert Wilton wrote:
> in RFC 7950, The last paragraph, section 5.1.1 "Import and Include by
> Revision" states:
>
> "If a module is not imported with a specific revision, it is undefined
> which revision is used."
>
> But I was wondering if the above text is misleading, since section
> 5.6.5: "
Hi Sue,
First, please be aware that the next version of revised-datastores
draft further defines the control-plane datastore concept. This
includes providing guidelines that other WGs can follow to define
their own control-plane datastores, and includes an Appendix section
outlining the creation
Sounds good as a first approximation. Though we need to discuss the details
and agree.
It might be useful to plan a joint session on Tue or Wed in Chicago.
Cheers,
Mehmet
> -Original Message-
> From: Susan Hares [mailto:sha...@ndzh.com]
> Sent: Tuesday, March 7, 2017 7:27 PM
> To: 'Mehmet
Mehmet:
Thank you for the excellent question clarifying my questions. My questions
(b) - related to protocol extension for I2RS for RESTCONF, NETCONF or CoAP.
I have removed that one.
I restate my question below, and the [xx] indicates my understanding.
Does c and d state the following are h
Hi Sue,
AFAICS your question kind of mixes between "I2RS control plane protocol" and
"ephemeral additions to Yang".
I believe different WGs are responsible for the part they own.
E.g. protocol-specific part should be done in the WG owning the protocol.
Can you please differentiate in your questio
Kent and Lou:
Clarifying questions:
Does c) and d) include additions to include I2RS ephemeral state as part of
an I2RS control plane protocol? If not, which WG works on the I2RS
ephemeral additions to Yang for control plane data stores?
Sue
-Original Message-
From: netmod [ma
Dne 7.3.2017 v 15:35 William Lupton napsal(a):
> Inline. Thanks, W.
>
>> On 7 Mar 2017, at 09:49, Radek Krejčí wrote:
>>
>> Hi,
>> I think that the default approach should be to expect that, until explicitly
>> stated, the imported module is just imported, not implemented. But it is
>> fine to
Inline. Thanks, W.
> On 7 Mar 2017, at 09:49, Radek Krejčí wrote:
>
> Hi,
> I think that the default approach should be to expect that, until explicitly
> stated, the imported module is just imported, not implemented. But it is fine
> to me to add an option to force the implemented flag on all
Hi Kent,
I am missing two aspects in the charter.
One is the short description of planned WG items setting the target.
The other point is the intended status of the WG items.
To me without such definition it looks kind of incomplete.
Mehmet
> -Original Message-
> From: netmod [mailto:ne
Kent Watsen writes:
> Hi Benoit,
>
> You seem to know the ins and outs of many tools these days, maybe you
> can point me in the right direction...which tool is able to validate
> instance documents against YANG 1.1 modules?
Yangson can validate JSON documents:
https://github.com/CZ-NIC/yangson
Radek Krejčí writes:
> Hi,
> I think that the default approach should be to expect that, until explicitly
> stated, the imported module is just imported, not implemented. But it is fine
> to me to add an option to force the implemented flag on all the modules.
> Benoit can then use the flag in
Radek Krejčí writes:
> Hi Lada,
>
> Dne 7.3.2017 v 10:30 Ladislav Lhotka napsal(a):
>> Robert Wilton writes:
>>
>>> Hi William,
>>>
>>> I think that what yanglint is doing here is sane, i.e. I think that its
>>> interpretation/split between imported vs implemented modules is
>>> supported by t
Hi Kent,
yanglint should be able to do it for you. Preferably, use the current devel
branch (it should be merged into master within a few days).
https://github.com/CESNET/libyang
Regards,
Radek
Dne 6.3.2017 v 23:41 Kent Watsen napsal(a):
> Hi Benoit,
>
> You seem to know the ins and outs of ma
Another place in the draft that appears to be inconsistent with the
section 5.6.5 text below is in 7.1.5, last sentence of this paragraph:
When the optional "revision-date" substatement is present, any
typedef, grouping, extension, feature, and identity referenced by
definitions in the
Hi Lada,
Dne 7.3.2017 v 10:30 Ladislav Lhotka napsal(a):
> Robert Wilton writes:
>
>> Hi William,
>>
>> I think that what yanglint is doing here is sane, i.e. I think that its
>> interpretation/split between imported vs implemented modules is
>> supported by the YANG RFC.
>>
>> However, for val
Hi,
I think that the default approach should be to expect that, until explicitly
stated, the imported module is just imported, not implemented. But it is fine
to me to add an option to force the implemented flag on all the modules. Benoit
can then use the flag in his scripts.
However, I checked
Robert Wilton writes:
> Hi William,
>
> I think that what yanglint is doing here is sane, i.e. I think that its
> interpretation/split between imported vs implemented modules is
> supported by the YANG RFC.
>
> However, for validation purposes it seems that it would be useful if
> yanglint had
Could this be the default in the first of these two cases?
Usage:
yanglint [options] [-f { yang | yin | tree }] ...
Validates the YANG module in , and all its dependencies.
yanglint [options] [-f { xml | json }] ... ...
Validates the YANG modeled data in according to the
Hi,
while the use case is clear, I believe such rather fundamental changes
to YANG cannot be done through extensions because otherwise the value of
YANG as a standard will be lost.
Lada
Lyle Bertz writes:
> All,
>
> This is a small submission that allows a single augment statement to be
> used
22 matches
Mail list logo
