[netmod] draft-ietf-netmod-yang-instance-file-format-01 terminology

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Thu, 07 February 2019 15:32 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
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 7AA02124C04 for <netmod@ietfa.amsl.com>; Thu, 7 Feb 2019 07:32:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 rsEhZLnxlEXZ for <netmod@ietfa.amsl.com>; Thu, 7 Feb 2019 07:32:16 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1C6D12008F for <netmod@ietf.org>; Thu, 7 Feb 2019 07:32:15 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 8D7916A2 for <netmod@ietf.org>; Thu, 7 Feb 2019 16:32:14 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id odzBOelfBUCu for <netmod@ietf.org>; Thu, 7 Feb 2019 16:32:14 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS for <netmod@ietf.org>; Thu, 7 Feb 2019 16:32:14 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6DD3820053 for <netmod@ietf.org>; Thu, 7 Feb 2019 16:32:14 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id geN49C5_IL50 for <netmod@ietf.org>; Thu, 7 Feb 2019 16:32:14 +0100 (CET)
Received: from exchange.jacobs-university.de (sxchmb04.jacobs.jacobs-university.de [10.70.0.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 1ACA220051 for <netmod@ietf.org>; Thu, 7 Feb 2019 16:32:13 +0100 (CET)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Thu, 7 Feb 2019 16:32:13 +0100
Received: by anna.localdomain (Postfix, from userid 501) id D1A0530063960A; Thu, 7 Feb 2019 16:32:12 +0100 (CET)
Date: Thu, 07 Feb 2019 16:32:12 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: netmod@ietf.org
Message-ID: <20190207153212.wttlorfwpoy6mpe6@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: netmod@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB01.jacobs.jacobs-university.de (10.70.0.120) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/h-gT2jg5Z5aREXTD-E7Yx6oi7PE>
Subject: [netmod] draft-ietf-netmod-yang-instance-file-format-01 terminology
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 07 Feb 2019 15:32:18 -0000

Hi,

I just stumbled across the terminology defined in
draft-ietf-netmod-yang-instance-file-format-01 and I have several
questions:

   Design time: A time during which a YANG model and the implementation
   behind it is created.  Sometimes in other documents this period is
   divided into design and implementation time.

Assuming that design time and implementation time are the same seems
to be odd. In the IETF, it is quite common that there is a significant
difference between design time and implementation time. So what is
mean here? Since the term is rarely used (I found two occurances),
perhaps clarify what is meant where this term is used and do not
introduce a new term. However, if the term is defined, then I suggest
that we use semantics that align with the common use of the term.

   Instance Data Set: A named set of data items that can be used as
   instance data in a YANG data tree.

Why do we need this term? How is this different from data tree defined
in RFC 7950?

   o  data tree: An instantiated tree of any data modeled with YANG,
      e.g., configuration data, state data, combined configuration and
      state data, RPC or action input, RPC or action output, or
      notification.

In which sense is this a 'named set'? Or is the intention here to
define a named set of YANG data trees? If a term is needed, would
'Instance Data' not be simpler and align better with Instance Data
File? Also note that 'instance data' is defined later as 'data that
could be stored in a datastore and whose syntax and semantics is
defined by YANG models'. So how does 'instance data' related to
'instance data set' and 'data tree'? Can we simplify things?

   Target YANG Module: A YANG module for which the instance data set
   contains instance data, like ietf-yang-library in the examples.

I am not sure I like 'target'. It seems to me that instance data is
expected to conform to a schema defined by a collection of YANG
modules and you probably want to express that (but 'target' I find
misleading - data does not target a module).  Whatever we choose at
the end, we need to make sure that the terminology across related
documents (YANG, NMDA, YANG Library, ...) is consistent.

The leaf target-ptr triggers questions as well. If there is a choice
between two things, perhaps using a YANG choice is a more natural way
of expressing this than inventing special notations. I am also not
sure if it is a good idea to hardcode the name ietf-yang-library. Why
can I not just refer to any schema defining YANG modules? This way, we
have the freedom to create ietf-yang-library-2 if we ever want to. Do
implementations have to follow target-ptr arbitrarily deep? Do they
have to detect circular references (well they better do I guess).

/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/>