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

Robert Wilton <rwilton@cisco.com> Tue, 26 June 2018 13:37 UTC

Return-Path: <rwilton@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A89BF13103B for <netmod@ietfa.amsl.com>; Tue, 26 Jun 2018 06:37:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ac7C3xNFQVBU for <netmod@ietfa.amsl.com>; Tue, 26 Jun 2018 06:37:34 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B872131030 for <netmod@ietf.org>; Tue, 26 Jun 2018 06:37:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7073; q=dns/txt; s=iport; t=1530020254; x=1531229854; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=oT6LcezgPhNB7Ia85zyAAnxTz14K5E6IfDUw4Ym5U/E=; b=GwQW+Y/qSxZchD72rtG2wawxMZdFi4v9Sd5VqusSXs0ZSdKQwmcL5zH9 WlP1SJuVwYFXeZyuzt/Mm+Sm0zOmkpE9zU3+f0GGBzfLbqrE3tJhcjnrR urTdaNenrcW21BFvJYYtfrTgQXB7ie2k4PfhEDYuGSdrBzHNuJgNgIeXW A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0B8AQBaQTJb/xbLJq1cGQEBAQEBAQEBAQEBAQcBAQEBAYMfCwEBAQGBcBKEIYhkjUEqlSmBZguEbAKDNDgUAQIBAQEBAQECbSiFNgEBAQMBHQYPAQUvEBILGAICJgICVwYBDAgBAReDCoF4CKx8ghyEW4NrgRqBC4k4P4EPJ4JohGKDGYJVAoxHjGoJjw4GgUCEB4JGhT2MJYVMgVghgVIzGggbFTuCaoJKaQEIjRU+jWsrghsBAQ
X-IronPort-AV: E=Sophos;i="5.51,274,1526342400"; d="scan'208";a="4785372"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jun 2018 13:37:22 +0000
Received: from [10.63.23.83] (dhcp-ensft1-uk-vla370-10-63-23-83.cisco.com [10.63.23.83]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w5QDbLQm001643; Tue, 26 Jun 2018 13:37:21 GMT
To: Balazs Lengyel <balazs.lengyel@ericsson.com>, "netmod@ietf.org" <netmod@ietf.org>
References: <152889763632.15168.12247537431295038165.idtracker@ietfa.amsl.com> <75383a97-d08b-b202-70a6-eab064963af8@ericsson.com> <b58d21a9-d27e-c8b3-e8e3-483dd6942c9e@cisco.com> <f946ca96-1cb2-e032-9adc-7df00702e216@ericsson.com> <20180626121156.fq5ioq2gh5sy3v7n@anna.jacobs.jacobs-university.de>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <e50fdff6-caa2-aada-011e-534b14ffdcf1@cisco.com>
Date: Tue, 26 Jun 2018 14:37:21 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <20180626121156.fq5ioq2gh5sy3v7n@anna.jacobs.jacobs-university.de>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/ES_nyMQvETEIvSKoJEPeeb4n1Tk>
Subject: Re: [netmod] Fwd: New Version Notification for draft-lengyel-netmod-yang-instance-data-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jun 2018 13:37:37 -0000


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.
>>     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.
An example could be wanting to provide a single file that holds the 
capabilities for all different linecard types for a particular type of 
device, rather than providing them as a set of files.

Of course, this could also be achieved using a meta YANG module (e.g. 
the top level module could have a list of linecard types, which each 
linecard type contains the capabilities for that linecard).  Whether 
this make sense probably depends on the underlying YANG modules and how 
they are constructed.

Of just using separate files, in which case the meta information can 
just be managed into the file name, and the file can be provided as a zip.


>
>>       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
>>     BEGINS> we could call it <INSTANCE DATA BEGINS> <INSTANCE DATA ENDS>
>>     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
> enough?
If the draft has text about it following the encoding (e.g. as proposed 
below, then this may not be required at all), although it be useful to 
explicitly highlight that whitespace is also coded by the encoding.  It 
seems like something that could possibly be overlooked otherwise.

>
>>       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
> etc.
Agreed, although I still think that explicitly mentioning whitespace 
might be helpful.  I'm not sure that I care too strongly on this point.

E.g.

    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.  Whitespace must also be handled as
    defined by the encoding rules.



>
>>       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.
Probably I don't mean semantic version.  But often files have 
versioning, or revision, information associated with them.  This can be 
muxed into the file name/path, but it also seems like potentially useful 
metadata, and being able to handle this generically in a consistent way 
might be beneficial.

As an example, perhaps the capability information related to S/W release 
1.2.4, etc.

Thanks,
Rob


>
> /js
>