[netmod] yang-data issues

Martin Bjorklund <mbj@tail-f.com> Tue, 11 September 2018 08:44 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 038F7130E61 for <netmod@ietfa.amsl.com>; Tue, 11 Sep 2018 01:44:51 -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 9B6w80hcFgh8 for <netmod@ietfa.amsl.com>; Tue, 11 Sep 2018 01:44:49 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 764B8130E60 for <netmod@ietf.org>; Tue, 11 Sep 2018 01:44:49 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id F2E411AE03F5 for <netmod@ietf.org>; Tue, 11 Sep 2018 10:44:47 +0200 (CEST)
Date: Tue, 11 Sep 2018 10:44:47 +0200 (CEST)
Message-Id: <20180911.104447.2165943059473950359.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/05MjLr2MBLu1szZgtzo3kz6XCxo>
Subject: [netmod] yang-data issues
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: Tue, 11 Sep 2018 08:44:51 -0000

Hi,

The authors of draft-ietf-netmod-yang-data-ext have been discussing
the two remaining issues on this draft; the issue of whether a
yang-data structure must have unique top-level node names or not, and
the issue of the syntax for augment-yang-data.  We haven't been able
to find agreement with the current proposal, so I have a suggestion
for a slightly modified yang-data statement (which may have been
discussed before):

The idea is to encode a yang-data extension the same way as anydata,
i.e., as a container.  For example:

  yd:yang-data modify-subscription-datastore-error-info {
      description
        "This yang-data MAY be provided as part of a subscription's RPC
        error response when there is a failure of a
        'modify-subscription' RPC which has been made against a
        datastore.  This yang-data MUST be used if hints are to be
        provides back to the subscriber.";
      leaf reason {
        type identityref {
          base sn:modify-subscription-error;
        }
        description
          "Indicates the reason why the subscription has failed to
          be modified.";
      }
      uses hints;
    }

This would be encoded as:

  <modify-subscription-datastore-error-info>
    <reason>foo</reason>
    <period-hint>42</period-hint>
    ...
  </modify-subscription-datastore-error-info>


Since the structure is always encoded as a container, it follows that
it can have any data definition statement as substatement, with no
restriction on naming and type of statement.  An instance of this can
trivially be a complete instance document in XML w/o additional
context, works well with JSON, and can appear in an error-info
structure.

Such a structure can be augemented as:

  yd:augment-yang-data /sn:modify-subscription-datastore-error-info {
    leaf foo { ... }
  }

The drawback is that it forces the use of an extra container in the
encoding.  OTOH, most usages of current rc:yang-data follows this
pattern:

  rc:yang-data modify-subscription-datastore-error-info {
    container modify-subscription-datastore-error-info {
      ...
    }
  }
  



/martin