Subject: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-instance-file-format-00.txt

From: Balázs Lengyel <[email-masked]>
Date: Tue, 6 Nov 2018 02:54:52 +0000

The first WG version of the document is stored. It is the same
as  draft-lengyel-netmod-yang-instance-data-05 except for the
change of title.

Balazs

-------- Forwarded Message --------

Subject:

New Version Notification for
draft-ietf-netmod-yang-instance-file-format-00.txt

Date:

Mon, 5 Nov 2018 18:12:04 -0800

From:

[email-masked]

To:

Benoit Claise <[email-masked]>, Balazs Lengyel
<[email-masked]>

A new version of I-D,
draft-ietf-netmod-yang-instance-file-format-00.txt

has been successfully submitted by Balazs Lengyel and posted to
the

IETF repository.

Name: draft-ietf-netmod-yang-instance-file-format

Revision: 00

Title: YANG Instance Data File Format

Document date: 2018-11-04

Group: netmod

Pages: 14

URL:
https://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-instance-file-format-00.txt

Status:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/

Htmlized:
https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-00

Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-format

Abstract:

There is a need to document data defined in YANG models without
the

need to fetch it from a live YANG server. Data is often needed

already in design time or needed by groups that do not have a live

running YANG server available. This document specifies a standard

file format for YANG Based Instance data, that is data that could
be

stored in a datastore and whose syntax and semantics is defined by

YANG models. Most important use cases foreseen include documenting

server capabilities, factory-default settings, or vendor provided

default configurations.

Please note that it may take a couple of minutes from the time of
submission

until the htmlized version and diff are available at
tools.ietf.org.

The IETF Secretariat

--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909 email: [email-masked]

---

From: Joe Clarke <[email-masked]>
Date: Mon, 5 Nov 2018 22:25:10 -0500

On 11/5/18 21:54, Balázs Lengyel wrote:
> The first WG version of the document is stored. It is the same as 
> draft-lengyel-netmod-yang-instance-data-05 except for the change of title.

Thanks, Balazs.  Here is an itemized review of this draft.  Thank you
for acknowledging my requirements around augmenting YANG data/structure.
 You will definitely need that when you start to document server
capabilities.

I agree with Lada and Rob that moving the use case examples to an
appendix would make it easier to get to the meat of the document.

===

In your terminology section, you define an instance data set as
essentially a set of instance data.  I might incorporate the text from
your abstract to call instance data, data that is returned from a YANG
server.  This, too, isn't ideal, but I think it's worth being a bit more
descriptive here.

===

You use "YANG Based Instance Data" as something that feels like a term
throughout the document, but you do not define this exactly.

===

Section 2.1.1

s/Capbilites/Capabilities/

s/capabilites/capabilities/g

You say, "While it is good practice to allow a client to query these
capabilities from the live YANG server, that is often not enough."

"Not enough" doesn't sound right.  I would say, "that is sometimes not
possible."  You may mention examples like the server is not currently
available or the code driving the server is not publicly available, etc.

You say that, "Often when a network node is released an associated NMS
is released with it."

I don't know that this coupling happens "often."  I'd say that when new
network element code is released, operators want to understand the
capabilities that come within that new code.  Other NMS/OSS vendors want
to be able to understand the model provided by the new code so they can
adjust their client code.

You go on to say, "Network operators often build their own home-grown
NMS systems that needs to be integrated with a vendor's network node."

Again, the word "often" doesn't resonate with me.  I do agree that there
are NMS vendors that need to understand how to modify their NMS to
support other vendors' network elements and there are some operators
that are building their own NMS/OSS.

===

Section 2.1.2

s/configurationp/configuration/

===

Section 2.1.3

s/Dcomenting/Documenting/

===

Section 3

s/returmed/returned/

s/configuraton/configuration/

You say, "It SHOULD NOT be used if the file is stored in a version
control system (e.g. git) because the change of file names will break
the connection between the different revisions of the file."

I think you should drop this requirement.  I can use "git mv" or create
tags if I want to retain history.  I wouldn't try and legislate what
people do with their VCS.

You use "meta data" in a number of locations.  Might I suggest
"metadata."  I think that is a more common way to write that term.

===

Section 6

With your datastore leaf, if I pull this off of a running YANG server,
serialize it and share it with my customer, why wouldn't I have the
actual datastore from which I retrieved it?  What I'm saying is that
this element may be missing, but if it is, I don't think you can assume
the source datastore for config=true nodes.

s/dtastore/datastore/

s/thats/that's/

s/Formated/Formatted/

===

Section 8

Do you have to register the ".yid" file extension as well?

Thanks.

Joe

> Subject: 	New Version Notification for
> Date: 	Mon, 5 Nov 2018 18:12:04 -0800
> From: 	[email-masked]
> To: 	Benoit Claise <[email-masked]>, Balazs Lengyel
> A new version of I-D, draft-ietf-netmod-yang-instance-file-format-00.txt
> has been successfully submitted by Balazs Lengyel and posted to the
> IETF repository.
> 
> There is a need to document data defined in YANG models without the
> file format for YANG Based Instance data, that is data that could be
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> -- 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 06 Nov 2018 11:51:26 +0700

> the source datastore for config=true nodes.

The description of the "datastore" leaf doesn't make much sense to
me. It says that for configuration data the default is "running" or
"candidate" if "running" isn't writable. Why should it matter whether
"running" is writable? It looks like it is assumed that the config data will
eventually be fed into the indicated datastore, but I don't see any
reason for such an assumption.

I can see that "datastore" can be occasionally useful as auxiliary
metadata but, in my view, this document addresses also instance data
that is not necessarily bound to any datastore.

Lada

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Joe Clarke <[email-masked]>
Date: Tue, 6 Nov 2018 01:26:10 -0500

> that is not necessarily bound to any datastore.

I agree.  In some cases, I won't have a datastore, and that shouldn't
mean the consumer assumes running (or candidate).

Joe

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 Nov 2018 07:36:48 +0100

I agree that

        leaf datastore {
          type ds:datastore-ref;
          description  "The identity of the datastore for which
            the instance data is documented for config=true data nodes.
            The leaf MAY be absent in which case the running dtastore or
            if thats not writable, the candidate datastore is implied.

            For config=false data nodes always the operational
            data store is implied.";
	}

is pretty confusing. It should be something like this:

        leaf datastore {
          type ds:datastore-ref;
          description  "The identity of the datastore holding
            the instance data. If the instance data is not associated
	    with a datastore, then this leaf MUST be absent.";
	}

I am against merging data from different datastores together, which
the last sentence of the original text seems to imply.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Joe Clarke <[email-masked]>
Date: Tue, 6 Nov 2018 01:51:36 -0500

> the last sentence of the original text seems to imply.

This is better.

In the case where the data does come from a datastore would this leaf
need to be there?  Meaning, is there an assumption that when it's not
present then the data did NOT come from a DS?

And it seems like you could provide instance data from <operational> to
merge ct and cf nodes even without merging DSes.

Joe

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 Nov 2018 09:45:13 +0100

> present then the data did NOT come from a DS?

I would prefer to have the datastore leaf mandatory when data is
associated with a specific datastore. If we do not mandate this, we
need a way to distinguish "I do not know what this is" from "this is
not datastore instance data".
 
> merge ct and cf nodes even without merging DSes.

The <operational> datastore does contain ct and cf data and the ct
data is the ct data that is operationally used (which can be different
from the ct data in <intended>. We went through quite some pain to
sort all of this out as part of the NMDA work and this document should
be consistent with NMDA.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 06 Nov 2018 16:36:09 +0700

>             the instance data. If the instance data is not associated

Or rather the datastore that the instance data was extracted from. After that,
the data exists on its own and the originating datastore may later be holding
something else.

> 	    with a datastore, then this leaf MUST be absent.";

RFC 2119 language would make sense if there is anything that could break if that
MUST isn't observed. But we even didn't know what the data is going to be used
for.

I would treat the "datastore" item as a purely optional information that, if
present, was provided for some reason. If it is false, what can we do?

> the last sentence of the original text seems to imply.

Both config true and config false data may come from <operational>, so it
doesn't necessarily mean any mixing of datastores. But then again, I think that
the datastore information isn't in most cases that interesting.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 06 Nov 2018 10:41:57 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> Or rather the datastore that the instance data was extracted from.

I prefer "associated with".  There are other uses cases than just
holding data "extracted from", e.g., data that is supposed to "be
inserted into" a datastore.  "associated with" is less resrictive.

> After that,
> I would treat the "datastore" item as a purely optional information

I agree.

/martin

> that, if

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 06 Nov 2018 17:03:22 +0700

> inserted into" a datastore.  "associated with" is less resrictive.

It unclear what "associated with" means in this context.

Lada

---

From: Balázs Lengyel <[email-masked]>
Date: Fri, 23 Nov 2018 12:48:40 +0000

Thanks for the comments. Details below.

Balazs

On 2018. 11. 06. 4:25, Joe Clarke
wrote:

BALAZS: OK

BALAZS: OK.

yang _BASED_ instance data is removed as it led to confusion. I
revert to the more simple "yang instance data".

Added definition for Yang Instance data

Section 2.1.1

BALAZS: OK

BALAZS: OK, changed

BALAZS: If we think about independent NMS
vendors they may release the NMS update after the new network node
version is released.

My point is that, many operators will not wait for the NMS to be
developed over some time. They require the NMS on day 1.

Anyway this is only an appendix now.

Section 2.1.2

BALAZS: OK

Section 2.1.3

BALAZS: OK

Section 3

s/returmed/returned/

BALAZS: OK

BALAZS: OK, although I still think it is
better to avoid using the date.

BALAZS: OK

Section 6

BALAZS: This should be a default value.
However as the default is a simple value, but

here it really depends on the config=true/false and the existence
of writable-running

I put it into the description statement. If you need something
else, like in your example, go ahead specify it.

Reworded from imply to default.

s/dtastore/datastore/

s/thats/that's/

s/Formated/Formatted/

BALAZS: OK

Section 8

BALAZS: Is there a registry for file
extensions? I was not aware.

Thanks.

Joe

Balazs

-------- Forwarded Message --------

Abstract:

The IETF Secretariat

---

From: Balázs Lengyel <[email-masked]>
Date: Fri, 23 Nov 2018 13:21:23 +0000

BALAZS: "Instance data associated with a datastore" may mean many
things, that's why this relatively loose term is used. It may
mean:

Data was read from that datastore

Data is intended to be fed into that datastore

Something else ???

This can be useful if data is read from a datastore, but in a
number of cases it is not useful:

Preloading configuration data: datastore may be running or
candidate.

Preloading mixed config and state data: We do have state data
that is very stable and thus it is documented as instance data,
and the instance data file is actually used to feed the state
data into the SW. So datastore is: running, candidate +
operational if NMDA is supported or state datastore (whatever
that is) if NMDA is not supported

regards Balazs

On 2018. 11. 06. 11:03, Ladislav Lhotka
wrote:

I agree that

leaf datastore {
type ds:datastore-ref;

leaf datastore {
type ds:datastore-ref;

Lada

After that,
the data exists on its own and the originating datastore may later be

holding

something else.

RFC 2119 language would make sense if there is anything that could break if

that

MUST isn't observed. But we even didn't know what the data is going to be

used

for.

I agree.

/martin

that, if

}

Both config true and config false data may come from <operational>, so it
doesn't necessarily mean any mixing of datastores. But then again, I think

that

Lada

/js

===

Section 6

With your datastore leaf, if I pull this off of a running YANG server,
serialize it and share it with my customer, why wouldn't I have the
actual datastore from which I retrieved it? What I'm saying is that
this element may be missing, but if it is, I don't think you can

assume

The description of the "datastore" leaf doesn't make much sense to
me. It says that for configuration data the default is "running" or
"candidate" if "running" isn't writable. Why should it matter whether
"running" is writable? It looks like it is assumed that the config data

will

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 23 Nov 2018 16:49:51 +0100

On Fri, Nov 23, 2018 at 01:21:23PM +0000, Balázs Lengyel wrote:
>    BALAZS: "Instance data associated with a datastore" may mean many things,
>    that's why this relatively loose term is used. It may mean:
> 
>      * Data was read from that datastore
>      * Data is intended to be fed into that datastore
>      * Something else ???
> 
>    This can be useful if data is read from a datastore, but in a number of
>    cases it is not useful:
> 
>      * Preloading configuration data: datastore may be running or candidate.
>      * Preloading mixed config and state data: We do have state data that is
>        very stable and thus it is documented as instance data, and the
>        instance data file is actually used to feed the state data into the
>        SW. So datastore is: running, candidate + operational if NMDA is
>        supported or state datastore (whatever that is) if NMDA is not
>        supported
> 
>    regards Balazs
>

I do not buy this story. Your software needs to decide somehow what
instance data means. A config true leaf in candidate means something
different than the same config true leaf in running and this yet again
means something different than the same config true leaf in operational.

/js

---

From: Balázs Lengyel <[email-masked]>
Date: Tue, 27 Nov 2018 17:11:07 +0000

Hello Jurgen,

As we had many misunderstandings around the datastore parameter, and I 
am still not clear what you would like, could you propose a description 
text for the datastore parameter.

regards Balazs

---

From: Balázs Lengyel <[email-masked]>
Date: Wed, 28 Nov 2018 09:41:12 +0000

> means something different than the same config true leaf in operational.

BALAZS: As I understood the WG decided that this draft should only be 
about the format of the yang instance data. What the SW does with it is 
out of scope. So considerations whether instance data should be loaded 
into running or candidate or not at all, are outside the scope.

I want to provide a datastore indicator, but how that should be used 
(and thus what is exactly means) is out of scope.

Anyway in some cases it would be problematic to define a single 
datastore parameter. E.g. the draft allows the real world use case of 
putting config and state data in the same file. In this case state data 
is associated with operational while config data is with 
running/candidate. In the non-NMDA case I do not even know what the 
correct daatastore is for state data.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 28 Nov 2018 11:20:50 +0100

On Wed, Nov 28, 2018 at 09:41:12AM +0000, Balázs Lengyel wrote:
> BALAZS: As I understood the WG decided that this draft should only be about
> the format of the yang instance data. What the SW does with it is out of
> scope. So considerations whether instance data should be loaded into running
> or candidate or not at all, are outside the scope.

If you do not know what the instance data means, any attempt to use it
is kind of broken.
 
> I want to provide a datastore indicator, but how that should be used (and
> thus what is exactly means) is out of scope.

I disagree. The datastore indicator is needed to understand what the
data means, i.e., to do anything meaningful with it.

> Anyway in some cases it would be problematic to define a single datastore
> parameter. E.g. the draft allows the real world use case of putting config
> and state data in the same file. In this case state data is associated with
> operational while config data is with running/candidate. In the non-NMDA
> case I do not even know what the correct daatastore is for state data.

We created NMDA because mixing <running> with <operational> is broken
in a number of cases. I am fine to accept that the datastore indicator
may be absent paired with a clear warning that in this case it is
undefined what the data means. (And I will hope that robust
implementations will avoid working with data that has unclear
semantics or at least generate warnings.)

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 28 Nov 2018 11:26:09 +0100

On Tue, Nov 27, 2018 at 05:11:07PM +0000, Balázs Lengyel wrote:
> Hello Jurgen,
> 
> As we had many misunderstandings around the datastore parameter, and I am
> still not clear what you would like, could you propose a description text
> for the datastore parameter.
>

Here is a start...

OLD

        leaf datastore {
          type ds:datastore-ref;

NEW

        leaf datastore {
          type ds:datastore-ref;
          description  "The identity of the datastore to which
            the instance data belongs.

            If this leaf is absent, then the datastore to which the
	    instance data belongs is undefined. This means that in
	    particular the meaning of 'config true' data is not well
	    defined.";
	}

/js

PS: I am not a big fan of the indentation style but that is a minor
    issue.

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 28 Nov 2018 12:00:44 +0100 (CET)

Juergen Schoenwaelder <[email-masked]> wrote:

[...]

> PS: I am not a big fan of the indentation style but that is a minor

Since the RFC editor will ensure that the indentation style is
consistent with other RFCs, it is better to fix this now.

/martin

---

From: Joe Clarke <[email-masked]>
Date: Wed, 28 Nov 2018 09:35:55 -0500

On 11/23/18 07:48, Balázs Lengyel wrote:
> BALAZS: Is there a registry for file extensions? I was not aware.

RFC6020 section 14 registers media types that include file extensions
for .yin and .yang.  I am asking are you proposing to do the same and
registering something like application/yang-instance-data with a .yid
extension?

Joe

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 28 Nov 2018 15:48:08 +0100

> registering something like application/yang-instance-data with a .yid

Isn't this just json and xml? If we need specific media types, I think
it would be two.

In theory, it would be even nicer if the document would be written in
such a way that it works with any (future) encoding. The way things
are defined today, by referring to responses of specific protocol
operations, is a bit odd. Does it matter whether the XML is returned
by a NETCONF <get-data> or RESTCONF/HTTP GET? Ideally, the format of
the instance files would be coming out of the data encoding
specifications (plus the architectural framework of datastores).

/js

---

From: Robert Wilton <[email-masked]>
Date: Wed, 28 Nov 2018 15:27:26 +0000

> data means, i.e., to do anything meaningful with it.

I think that a datastore indicator is useful sometimes.  E.g. it might 
be helpful in some cases to know that the data was associated with a 
particular datastore.

But in the general case I think that this is just "data at rest", and 
probably the key thing to know is whether (i) the data relates to 
configuration, or (ii) the data relates to operational state.

This could potentially be inferred from a datastore leaf, or perhaps 
this distinction could more explicitly be made by a separate field, 
which I would make an enumeration or identity, since there might be 
other types of data in future, such as capability information or 
diagnostics.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 28 Nov 2018 16:32:15 +0100

On Wed, Nov 28, 2018 at 03:27:26PM +0000, Robert Wilton wrote:
> I think that a datastore indicator is useful sometimes.  E.g. it might be
> helpful in some cases to know that the data was associated with a particular
> datastore.
> 
> This could potentially be inferred from a datastore leaf, or perhaps this
> distinction could more explicitly be made by a separate field, which I would
> make an enumeration or identity, since there might be other types of data in
> future, such as capability information or diagnostics.
>

I do not understand why a datastore leaf is not sufficient and why we
need yet something new. If ever needed, NMDA does allow us to define
new datastores.

/js

---

From: Robert Wilton <[email-masked]>
Date: Wed, 28 Nov 2018 15:43:01 +0000

> need yet something new. If ever needed, NMDA does allow us to define

Because a distinction between "candidate" vs "running" vs "intended" 
won't necessarily be that useful.  Although knowing "running" vs 
"intended" would allow the client to know whether it is pre/post 
template expansion and that might be useful.

The second reason is that I don't know whether things like capabilities 
and diagnostics will be new datastores or just part of operational.  I 
don't think that either of these two areas have really been properly 
worked out yet.  I presume that they will come over time, once more 
network management becomes more automated.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 28 Nov 2018 17:03:27 +0100

On Wed, Nov 28, 2018 at 03:43:01PM +0000, Robert Wilton wrote:
> Because a distinction between "candidate" vs "running" vs "intended" won't
> necessarily be that useful.  Although knowing "running" vs "intended" would
> allow the client to know whether it is pre/post template expansion and that
> might be useful.

I think it is. I would also assume that the need to save <candidate>
instance data in a file is rare. So its likely <running> or <intended>
and for some systems the difference is small, for others it may not be
small. My point is we have a way to distinguish things and we should
use that instead of creating something new that lumps things together
again.
 
> The second reason is that I don't know whether things like capabilities and
> diagnostics will be new datastores or just part of operational.  I don't
> think that either of these two areas have really been properly worked out
> yet.  I presume that they will come over time, once more network management
> becomes more automated.

By default this is all <operational>. The schema (aka YANG library)
exists in <operational> already today. I do not know what your
definition of 'diagnostics' is but until we have something else, I
assume this is in <operational>. And yes, if systems have other
creative datastores, we have a way to deal with that as well. Its all
there and I am afraid that creating yet another way to classify data
just adds pain and brings back ambiguity.

/js

---

From: Qin Wu <[email-masked]>
Date: Thu, 29 Nov 2018 01:53:42 +0000

The abbreviation of YANG instance data yid may confuse with YANG identitifer short name
"
   YANG Identifier:  Numeric object identifier, which is a fixed-length
      numeric value that represents a particular schema node within a
      YANG module schema tree.  The length and format of a YANG
      identifier are defined in the YANG Identifier Registry.  Also
      called a "YID".
"
I believe they are not same thing.

-Qin
-----邮件原件-----
发件人: netmod [mailto:[email-masked]] 代表 Joe Clarke
发送时间: 2018年11月28日 22:36
收件人: Balázs Lengyel; [email-masked]
主题: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-instance-file-format-00.txt

> BALAZS: Is there a registry for file extensions? I was not aware.

RFC6020 section 14 registers media types that include file extensions for .yin and .yang.  I am asking are you proposing to do the same and registering something like application/yang-instance-data with a .yid extension?

Joe

---

From: Balázs Lengyel <[email-masked]>
Date: Fri, 30 Nov 2018 12:48:48 +0000

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 XML; it is
yang instance data in XML format.  Alternatives:

Use the .yid file extension (my favorite)

Use 2 separate file extensions: .yidxml, .yidjson

just use .xml and .json

What is the rule, do I need to register a file extension as a
media-type? Is that optional? Is that needed?

regards Balazs

On 2018. 11. 28. 15:48, Juergen
Schoenwaelder wrote:

/js

---

From: Balázs Lengyel <[email-masked]>
Date: Fri, 30 Nov 2018 13:00:01 +0000

Hello Qin,

Do you have a better suggestion for the file extension?

regards Balazs

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 30 Nov 2018 16:17:48 +0100

On Fri, Nov 30, 2018 at 12:48:48PM +0000, 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 the file extension that this
>    is not just any plain old XML; it is yang instance data in XML format.�
>    Alternatives:
> 
>     1. Use the .yid file extension (my favorite)
>     2. Use 2 separate file extensions: .yidxml, .yidjson
>     3. just use .xml and .json
>

I would have used .json or .xml; the content of the file after all is
self-describing and tools like 'file' might learn how to recognize the
content. Extensions like .yidxml and .yidjson looks a bit horrible to
me and so far I never had any real problems using .json and .xml for
arbitrary json and xml files (and .json and .xml helps generic tools
so calling it .yid means that I have to go and teach tools that .yid
is either .json and .xml). Try loading .json and .xml in your
favourite editor and then load a .yid file. Big difference for my
editor. So from my perspective, do nothing (and then people and tools
will likely use option 3).

/js

---

From: Balázs Lengyel <[email-masked]>
Date: Fri, 30 Nov 2018 15:54:57 +0000

OK, so lets go with option 3.
balazs

---

From: Balázs Lengyel <[email-masked]>
Date: Fri, 30 Nov 2018 16:06:17 +0000

On 2018. 11. 28. 16:43, Robert Wilton wrote:
>>> this
> The second reason is that I don't know whether things like 
> capabilities and diagnostics will be new datastores or just part of 
> operational.  I don't think that either of these two areas have really 
> been properly worked out yet.  I presume that they will come over 
> time, once more network management becomes more automated.
>
> Thanks,
> Rob

BALAZS: You are right, that these areas are not worked out. That is 
exactly why they are out of scope. This is only about the format, and 
not about the usage. As we already have about 10 use cases with 
different needs, none of which are specified exactly, I want to avoid 
defining specific metadata for use cases we don't fully understand. 
Note: it is possible and documented that the metadata can be 
extended/augmented.

regards balazs