On 27/06/2018 09:09, Balazs Lengyel wrote:
On 6/26/2018 5:55 PM, Robert Wilton wrote:
- a version number refering to a specific software release of a server
I see this "version" as file level meta-data information, in the same
category as name, contact, description, organization meta-data
On Wed, Jun 27, 2018 at 10:15:10AM +0200, Balazs Lengyel wrote:
>
>BALAZS: The current draft really says two things:
>
> 1. this is the format for instance data
> 2. instance-data SHOULD be used to document server capabilities
>
>IMHO both are important. I fear that if we
On 6/26/2018 5:44 PM, Juergen Schoenwaelder wrote:
On Tue, Jun 26, 2018 at 05:31:27PM +0200, Balazs Lengyel wrote:
Hello Juergen,
Sorry the wording was misleading. I want these capabilities both as state
data AND as instance-data-files, because
there is a
On 6/26/18 11:38, Balazs Lengyel wrote:
> Any opinions on Rob's suggestion about a free-text versioning string?
> I am neutral on this.
Like I mentioned, I would use this for YANG Catalog input, and I would
want MD around yang-library instance data. That MD would include the
vendor, platform,
On Tue, Jun 26, 2018 at 04:55:32PM +0100, Robert Wilton wrote:
>
> Another field that may be generically useful is the time/date stamp
> of when the instance data was generated. Although perhaps the
> timestamp of the file is sufficient for this purpose.
I support adding a time/date stamp. (The
Juergen Schoenwaelder wrote:
> On Tue, Jun 26, 2018 at 05:31:27PM +0200, Balazs Lengyel wrote:
> > Hello Juergen,
> >
> > Sorry the wording was misleading. I want these capabilities both as state
> > data AND as instance-data-files, because
> > there is a need to know this information before you
On 26/06/2018 16:44, Juergen Schoenwaelder wrote:
On Tue, Jun 26, 2018 at 05:31:27PM +0200, Balazs Lengyel wrote:
Hello Juergen,
Sorry the wording was misleading. I want these capabilities both as state
data AND as instance-data-files, because
there is a need to know this information before
On 26/06/2018 16:41, Juergen Schoenwaelder wrote:
On Tue, Jun 26, 2018 at 05:38:10PM +0200, Balazs Lengyel wrote:
Any opinions on Rob's suggestion about a free-text versioning string?
I am neutral on this.
It needs to be clear _what_ is versioned. I have seen conflicting
views. I
On Tue, 2018-06-26 at 17:34 +0200, Balazs Lengyel wrote:
> Hello Lada,
>
> Maybe you are right. It is probably only important in case of mixed
> modules. However as Rob proposed the usage of yang-data-ext I will put
> it up as an open issue in Montreal. OK?
Sure, this is only a marginal
Note, adding it to the meta-data YANG definition does not mean that
everyone has to populate this, it just ensures that it has a consistent
name and semantics for clients/servers that do want to use it.
Thanks,
Rob
On 26/06/2018 16:38, Balazs Lengyel wrote:
Any opinions on Rob's suggestion
On Tue, Jun 26, 2018 at 05:31:27PM +0200, Balazs Lengyel wrote:
> Hello Juergen,
>
> Sorry the wording was misleading. I want these capabilities both as state
> data AND as instance-data-files, because
> there is a need to know this information before you ever see the real
> network node. How
On Tue, Jun 26, 2018 at 05:38:10PM +0200, Balazs Lengyel wrote:
>Any opinions on Rob's suggestion about a free-text versioning string?
>I am neutral on this.
>
It needs to be clear _what_ is versioned. I have seen conflicting
views. I have heard so far:
- the YANG version context once
Any opinions on Rob's suggestion about a free-text versioning
string?
I am neutral on this.
regards Balazs
On 6/26/2018 5:31 PM, Robert Wilton
wrote:
On 26/06/2018 16:20, Balazs Lengyel
wrote:
On 6/26/2018
My plain text email reader fails on the quoting and this is usually
where I drop out of discussions since I can't follow anymore.
On Tue, Jun 26, 2018 at 05:09:56PM +0200, Balazs Lengyel wrote:
>
>BALAZS: I did not find anything about leading/trailing whitespace e.g. for
>an integer in
Hello Lada,
Maybe you are right. It is probably only important in case of mixed
modules. However as Rob proposed the usage of yang-data-ext I will put
it up as an open issue in Montreal. OK?
regards Balazs
On 6/26/2018 5:30 PM, Ladislav Lhotka wrote:
On Tue, 2018-06-26 at 15:58 +0200,
Hello Juergen,
Sorry the wording was misleading. I want these capabilities both as
state data AND as instance-data-files, because
there is a need to know this information before you ever see the real
network node. How about the following?
"YANG servers SHOULD document server capabilities
On 26/06/2018 16:20, Balazs Lengyel wrote:
On 6/26/2018 4:07 PM, Robert Wilton wrote:
7) It might want to include a semantic version number for an
instance-data-set, depending on whether the YANG
versioning discussions
ends up.
BALAZS: Yes I would like to.
On Tue, 2018-06-26 at 15:58 +0200, Balazs Lengyel wrote:
> Hello Lada,
> I don't insist on using yang-data-ext, but I like it. Isn't this the exact
> use case for it: defining yang structured data that will never be loaded into
> a datastore. In this case the structure of the instance-data-set
On 6/26/2018 4:07 PM, Robert Wilton
wrote:
7) It
might want to include a semantic version number for an
instance-data-set, depending on whether the YANG
On 6/26/2018 3:52 PM, Juergen
Schoenwaelder wrote:
On Tue, Jun 26, 2018 at 02:37:21PM +0100, Robert Wilton wrote:
On 26/06/2018 13:11, Juergen Schoenwaelder wrote:
On Tue, Jun 26, 2018 at 01:58:44PM +0200, Balazs
On Tue, Jun 26, 2018 at 04:05:16PM +0200, Balazs Lengyel wrote:
>Hello Martin,
>
>IMHO it would be good to recommend as a general practice that YANG servers
>SHOULD document their capabilities using instance data. Even though "the
>set of server capabilities to be documented will
On 6/26/2018 2:11 PM, Juergen
Schoenwaelder wrote:
On Tue, Jun 26, 2018 at 01:58:44PM +0200, Balazs Lengyel wrote:
Thanks for the comments and support. See answers below.
Balazs
On 6/13/2018 4:40 PM, Robert Wilton wrote:
On 26/06/2018 14:52, Juergen Schoenwaelder wrote:
On Tue, Jun 26, 2018 at 02:37:21PM +0100, Robert Wilton wrote:
On 26/06/2018 13:11, Juergen Schoenwaelder wrote:
On Tue, Jun 26, 2018 at 01:58:44PM +0200, Balazs Lengyel wrote:
Thanks for the comments and support. See answers below.
Hello Martin,
IMHO it would be good to recommend as a general practice that
YANG servers SHOULD document their capabilities using instance
data. Even though "the
set of server capabilities to be documented will be defined by
other standards and
On Tue, Jun 26, 2018 at 01:58:44PM +0200, Balazs Lengyel wrote:
>Thanks for the comments and support. See answers below.
>Balazs
>
>On 6/13/2018 4:40 PM, Robert Wilton wrote:
>
> Hi,
>
> I would support this draft (if/when a call for adoption is made).
>
> A few
As I stated at the mic at 101, I support this work (and would support
its WG adoption). In particular, the YANG Catalog can make use of
instance-data in how we capture a server's capabilities to describe what
modules a server (at a specific software revision) implements.
To that end, we would
Hi,
I think this useful work, and I support it. However, I have some
comments on the current draft. My main concern is that it mixes the
very useful specification of instance data with requirements on the
server. Specifically, I think section 4 should be re-written to be an
example of what can
] On Behalf Of Balazs Lengyel
Sent: Wednesday, June 13, 2018 7:07 AM
To: netmod@ietf.org
Subject: [netmod] Fwd: New Version Notification for
draft-lengyel-netmod-yang-instance-data-01.txt
Hello,
I submitted a new version of the yang-instance-data draft updated with comments
from the last IETF
Hi,
I support the adoption of this I-D as a workgroup item and my plan is to
implement it.
However, my suggestion is to avoid the use of yang-data-ext. It is
absolutely useless in this case and only complicates things that are
otherwise pretty trivial.
Lada
Balazs Lengyel writes:
> Hello,
>
On Wed, Jun 13, 2018 at 03:40:31PM +0100, Robert Wilton wrote:
>
> 5) I'm wondering whether there needs to be some sort of identifier about
> what type data is held. E.g. does it represent data that can be consumed as
> part of one of the configuration datastores, or does it represent the
>
Hi,
I would support this draft (if/when a call for adoption is made).
A few comments from a quick review :
1) I think that it would be useful to allow a file to contain multiple
"instance data sets". I could easily imagine that multiple different
blocks of instance data may need to be
Hello,
I submitted a new version of the yang-instance-data draft updated
with comments from the last IETF and others. I would like to get
this adopted as a workgroup item. Please review it and if you like
it please indicate that you support it as a workgroup
Hello,
I submitted a new version of the yang-instance-data draft updated
with comments from the last IETF and others. I would like to get
this adopted as a workgroup item. Please review it and if you like
it please indicate that you support it as a workgroup
33 matches
Mail list logo
