I doubt it makes sense to carry an entire yang library schema with the
instance data. The modules are actually known via the namespaces. If
you want to capture the schema, dump the relevant yang library into
another instance file.
/js
On Fri, Nov 30, 2018 at 07:07:03PM +, Robert Wilton
I also think that the instance data header needs to have a way of
indicating which modules (and versions/revisions) the instance data
applies to.
It can be optional, so producers that know it is not required can leave
it out. But I think that it is required, at least for situations where
Hi,
I don't see much standards value in this draft so far.
It seems the parser of the file needs to know the YANG library information
for the instance file data in some out-of-scope non-standard manner.
This is what we already have today just by naming the file in a specific
way.
Is the intent
On 2018. 11. 30. 13:48, Juergen
Schoenwaelder wrote:
PS: I am also concerned about the revision being not fine grained
enough to be useful. I would love to have a much more precise
timestamp telling me when the instance data was recorded. I would
On 2018. 11. 28. 16:43, Robert Wilton wrote:
On 28/11/2018 15:32, Juergen Schoenwaelder wrote:
On Wed, Nov 28, 2018 at 03:27:26PM +, Robert Wilton wrote:
On 28/11/2018 10:20, Juergen Schoenwaelder wrote:
On Wed, Nov 28, 2018 at 09:41:12AM +, Balázs Lengyel wrote:
I do not buy this
OK, so lets go with option 3.
balazs
On 2018. 11. 30. 16:17, Juergen Schoenwaelder wrote:
On Fri, Nov 30, 2018 at 12:48:48PM +, Balázs Lengyel wrote:
Hello, Joe, Jurgen,
RFC6020 doesn't really register� file extensions, but rather media types.
I don't feel we need a new
On Fri, Nov 30, 2018 at 12:48:48PM +, Balázs Lengyel wrote:
>Hello, Joe, Jurgen,
>
>RFC6020 doesn't really register� file extensions, but rather media types.
>I don't feel we need a new mediatype for this as we really use json and
>xml. However I see it useful to document in
Hello Qin,
Do you have a better suggestion for the file extension?
regards Balazs
On 2018. 11. 29. 2:53, Qin Wu wrote:
The abbreviation of YANG instance data yid may confuse with YANG identitifer
short name
"
YANG Identifier: Numeric object identifier, which is a fixed-length
Hello, Joe, Jurgen,
RFC6020 doesn't really register file extensions, but rather
media types. I don't feel we need a new mediatype for this as we
really use json and xml. However I see it useful to document in
the file extension that this is not just any plain old
On Fri, Nov 30, 2018 at 12:28:09PM +, Balázs Lengyel wrote:
>Hello Jurgen,
>
>Thanks for the comments. See answers below.
>
>regards Balazs
>
>On 2018. 11. 28. 11:01, Juergen Schoenwaelder wrote:
>
> draft-ietf-netmod-yang-instance-file-format-00.txt says:
>
> The
Hello Jurgen,
Thanks for the comments. See answers below.
regards Balazs
On 2018. 11. 28. 11:01, Juergen
Schoenwaelder wrote:
draft-ietf-netmod-yang-instance-file-format-00.txt says:
The JSON format SHALL follow the format of the reply returmed
This is already on my list (was already proposed by Balázs).
/js
On Fri, Nov 30, 2018 at 11:25:44AM +0100, Martin Bjorklund wrote:
> Balázs Lengyel wrote:
> > Hello,
> >
> > In a similar manner we found multiple uses for the
> > ietf-netconf-acm:node-instance-identifier. We
> > imported nacm
Balázs Lengyel wrote:
> Hello,
>
> In a similar manner we found multiple uses for the
> ietf-netconf-acm:node-instance-identifier. We
> imported nacm just to reuse this type.
> Anyone else interested?
Yes, this is a useful type that is not just NACM-specific. We also
use in various places.
Hello,
In a similar manner we found multiple uses for the ietf-netconf-acm:node-instance-identifier.
We imported nacm just to reuse this type.
Anyone else interested?
regards Balazs
On 2018. 11. 29. 12:03, Robert Wilton
wrote:
Hi
14 matches
Mail list logo
