Re: [netmod] Fwd: New Version Notification for draft-lengyel-netmod-yang-instance-data-01.txt

Juergen Schoenwaelder <> Tue, 26 June 2018 12:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A2473130DCD for <>; Tue, 26 Jun 2018 05:12:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6nMAULHpEh-i for <>; Tue, 26 Jun 2018 05:11:59 -0700 (PDT)
Received: from anna.localdomain ( [IPv6:2001:638:709:5::7]) by (Postfix) with ESMTP id B09C8130DC2 for <>; Tue, 26 Jun 2018 05:11:58 -0700 (PDT)
Received: by anna.localdomain (Postfix, from userid 501) id 8711122B3C2C; Tue, 26 Jun 2018 14:11:56 +0200 (CEST)
Date: Tue, 26 Jun 2018 14:11:56 +0200
From: Juergen Schoenwaelder <>
To: Balazs Lengyel <>
Cc: Robert Wilton <>, "" <>
Message-ID: <>
Reply-To: Juergen Schoenwaelder <>
Mail-Followup-To: Balazs Lengyel <>, Robert Wilton <>, "" <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: NeoMutt/20180622
Archived-At: <>
Subject: Re: [netmod] Fwd: New Version Notification for draft-lengyel-netmod-yang-instance-data-01.txt
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 26 Jun 2018 12:12:02 -0000

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 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 provided and allowing these to be
>      carried within a single file seems helpful.
>    BALAZS: We allow multiple YANG modules in a file, but I have never seen it
>    used. Actually my model/tool designers asked me to prohibit multiple YANG
>    modules (YAMs) in one file at least within Ericsson. So if the group
>    decides so it can be allowed, however I think it is not a good idea.

What exactly is "multiple YANG modules in a file"? I am confused and
you may be talking past each other.

>      2) I wonder whether these instance-data blocks could be used to hold
>      examples in drafts/RFCs.  It would be nice if the examples could be
>      automatically extracted and validated.  Possibly this draft could help
>      with this, although I appreciate it is not its main focus.
>    BALAZS: It could be easily added. All we need is a pair of tags like <CODE
>    After that we need to create the tools to extract and validate the
>    instance data.

Why is instance data node code? Why do we need new tags? The tags are
there to extract 'stuff' - what 'stuff' is should be clear from
'stuff'. (RFC 7950 uses CODE BEGINS for yang.abnf for example.)

>      3) Possibly a comment should be made about whitespace, although I think
>      that it is fairly obvious how whitespace would be handled, i.e. as
>      defined by the encoding.
>    BALAZS: OK. How about:
>    Leading and trailing whitespace before and after the actual value MUST NOT
>    be present for data based on types string or binary, but MAY be present
>    for data based on integer types, decimal64, boolean,  enumeration, bits,
>    identityref, instance-identifier. For leafrefs leading or trailing
>    whitespace MAY or MUST NOT be present based on the referenced data type.
>    For data based on a union type leading or trailing whitespace MUST NOT be
>    present if it is not allowed for any of the member types.

Why do we need new rules? Should the artwork wrapping solution not be good

>      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 equivalent of operational state, or is it data for an RPC,
>      etc.
>    BALAZS: For config=false data that's trivial.
>    For config=true data I don't see a use-case for providing operational
>    state data.  IMHO  If we just say that config=true data can be loaded into
>    the running/candidate datastore that is enough.  We had a similar debate
>    with Jurgen (?) but I still do not see the use case. Maybe if there will
>    be dynamic datastores it would be more meaningful. If you see a use-case
>    that needs this please describe it.

Trivial use case is an example that shows how content of <running> and
<operational> can differ. I see use cases where you snapshot the
status of <operational> and <running> for post mortem analysis. It is
easy to come up with use cases. We have datastores, so we should be
clear to which datastore instance data relates.

>      6) If this data is to be stored in a file, should it state that it must
>      be stored as UTF-8 character encoding?
>    BALAZS: Good idea. Maybe a more general statement like:
>    Instance data MUST follow the XML and JSON encoding rules defined in
>    RFC7950 and 7951. Data MUST be present in canonical form or where that is
>    not defined in lexical representation.
>    It is more then just UTF-8. All stuff about encoding the different
>    statements and types also applies.

So we do not need all the rules you mentioned above concerning white space

>      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. However I am not exactly clear on what does
>    backwards compatibility mean for instance data.
>    Data MAY NOT be removed or changed only added.  ???
>    Who would use the semver numbers ???

What does the version number mean? Every change of instance data in an
instacne-data-set leads to a new version number? What is a bug fix in
this sense? What is a non-backwards compatible change of instance data?
I am left a bit puzzled.


Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <>