[netmod] yang-data-ext issues

Martin Bjorklund <mbj@tail-f.com> Mon, 16 April 2018 12:56 UTC

Return-Path: <mbj@tail-f.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 7E7C912D941 for <netmod@ietfa.amsl.com>; Mon, 16 Apr 2018 05:56:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 ChFo17FHKHPY for <netmod@ietfa.amsl.com>; Mon, 16 Apr 2018 05:56:23 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C340C120227 for <netmod@ietf.org>; Mon, 16 Apr 2018 05:56:22 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 6158C1AE00A0 for <netmod@ietf.org>; Mon, 16 Apr 2018 14:56:21 +0200 (CEST)
Date: Mon, 16 Apr 2018 14:56:17 +0200 (CEST)
Message-Id: <20180416.145617.1262098657698751846.mbj@tail-f.com>
To: netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/pZctP8TFgEF7ZtVkjOXCoCWMedo>
Subject: [netmod] yang-data-ext issues
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 16 Apr 2018 12:56:24 -0000

Hi,

While preparing draft-ietf-netmod-yang-data-ext-02, it turned out that
it is not clear what, if any, restrictions should be enforced for
yang-data structures.  Even among the authors we have different ideas
for how this should work.

Background:

In 8040, the original yang-data extension had a restriction that said
that a yang-data structure MUST have exactly one container, since it
wouldn't be possible to have a yang-data structure in an XML instance
document otherwise.

Since people want to use yang-data structures in other places, this
restriction was lifted in the new draft:

   There is no longer an assumption that a yang data structure can
   only be used as a top-level abstraction, instead of nested within
   some other data structure.


With this in mind, here's a use case that I think we ought to support:

  rpc my-first-rpc {
    description
      "Bla bla...
       If an error occurs, <error-info> will contain an instance of
       the yang-data structure 'my-first-rpc-error-info'.";
    ...
  }

  yang-data my-first-rpc-error-info {
    leaf reason { ... }
    container user-info { ... }
  }

  rpc my-second-rpc {
    description
      "Bla bla...
       If an error occurs, <error-info> will contain an instance of
       the yang-data structure 'my-second-rpc-error-info'.";
    ...
  }

  yang-data my-second-rpc-error-info {
    leaf reason { ... }
    leaf important-url { ... }
  }

(maybe in the future we could even have a YANG extension statement to
formalize the description:

   rpc my-first-rpc {
     ...
     opx:error-info-structure my-first-rpc-error-info;
   }

but this is not point now.)

In the example above, note that the leaf "reason" is present in both
structures.  IMO this is not a problem, since these structures are
used in different contexts.

My point is that I think we should impose as few restrictions as
possible to the yang-data extension.  It should be up to the user of
yang-data to ensure that the structure is defined in such a way so
that it can be used properly.  For example, a structure that is
supposed to describe an XML instance document cannot define two leafs
at the top level.

If the WG agrees with what I wrote above, we need to change the
augment-yang-data extension so that you would write for example:

  yx:augment-yang-data /ex:my-first-rpc-error-info/ex:user-info {
    ...
  }

Comments?



/martin