Do you care that schema mount extension isn't a node?

Lou Berger <lberger@labn.net> Tue, 29 August 2017 16:54 UTC

Return-Path: <lberger@labn.net>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0487132D59 for <rtgwg@ietfa.amsl.com>; Tue, 29 Aug 2017 09:54:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 gf4l_hQzMq0W for <rtgwg@ietfa.amsl.com>; Tue, 29 Aug 2017 09:54:25 -0700 (PDT)
Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04D50132C4D for <rtgwg@ietf.org>; Tue, 29 Aug 2017 09:54:25 -0700 (PDT)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id BF8CB1E064E for <rtgwg@ietf.org>; Tue, 29 Aug 2017 10:54:23 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id 34uK1w01S2SSUrH014uNA9; Tue, 29 Aug 2017 10:54:23 -0600
X-Authority-Analysis: v=2.2 cv=fJ5J5dSe c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=KeKAF7QvOSUA:10 a=Hsoq25NeZv6fqVdDJ98A:9 a=8GDItUJANxTe_aPZ:21 a=0_fy-1t0hktONJUn:21 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Cc:Subject:From:To:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=QFJ9hS4/jdeZcTfd5nLEKxjFq2xPn41+ens9CoWMz64=; b=AB4T+o7TJGJOwiMP9NODvYz2c0 4qdGK7E2ChQ35hc02Ue2JJ81uefAPgXrBm3Imzfsd8TbgVnBLLFnwRficFWVvCHLc6vpBpyABCvf4 Tpet/oit3eqP8x3l0P8MAMO0T;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:44356 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <lberger@labn.net>) id 1dmjmN-000DoZ-OC; Tue, 29 Aug 2017 10:54:19 -0600
To: Routing WG <rtgwg@ietf.org>
From: Lou Berger <lberger@labn.net>
Subject: Do you care that schema mount extension isn't a node?
Cc: "draft-ietf-rtgwg-ni-model@ietf.org" <draft-ietf-rtgwg-ni-model@ietf.org>, "draft-ietf-rtgwg-lne-model@ietf.org" <draft-ietf-rtgwg-lne-model@ietf.org>
Message-ID: <cea6095f-4363-5da6-fa28-46d2a83640ed@labn.net>
Date: Tue, 29 Aug 2017 12:54:10 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dmjmN-000DoZ-OC
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:44356
X-Source-Auth: lberger@labn.net
X-Email-Count: 6
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/gC6MouIj-_m_id3lwuvyCv2bQyA>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Aug 2017 16:54:27 -0000

Hi,

    I'm not sure how many folks are tacking the netmod list, so I wanted
to raise a point here based on a discussion going on there.  It looks
like we (authors of the NI and LNE docs) understood the
draft-ietf-netmod-schema-mount defined extension mount-point  as
defining a node, similar to a container, in the data tree *but* the
schema-mount authors intended the extension to not define a node and to
just identify that the node containing the extension was where mounted
modules exist.  This isn't too big a deal, but it does mean we now need
to put each mount point in its own container.  The tree representation
won't materially change, but the yang module will.  An example is
provided below.

So the question is does anyone care about this?  If not, the
module/document updates are fairly straight forward.  If you do care,
now is the time to speak up, preferably by joining the netmod discussion.

Lou

(as contributor)

For example in draft-ietf-rtgwg-ni-model:

OLD
    choice root-type {
      description
        "Well known mount points.";
      yangmnt:mount-point "vrf-root" {
        description
          "Root for L3VPN type models. This will typically
           not be an inline type mount point.";
      }
      yangmnt:mount-point "vsi-root" {
        description
          "Root for L2VPN type models. This will typically
           not be an inline type mount point.";
      }
      yangmnt:mount-point "vv-root" {
        description
          "Root models that support both L2VPN type bridging
           and L3VPN type routing. This will typically
           not be an inline type mount point.";
      }

NEW

    choice root-type {
      description
        "Well known mount points.";
        container vrf-root {
          description
            "Container for mount point.";
          yangmnt:mount-point "vrf-root" {
            description
              "Root for L3VPN type models. This will typically
               not be an inline type mount point.";
          }
        }
        container vsi-root {
          description
            "Container for mount point.";
          yangmnt:mount-point "vsi-root" {
            description
              "Root for L2VPN type models. This will typically
               not be an inline type mount point.";
          }
        }
        container vv-root {
          description
            "Container for mount point.";
          yangmnt:mount-point "vv-root" {
            description
              "Root models that support both L2VPN type bridging
               and L3VPN type routing. This will typically
               not be an inline type mount point.";
          }
        }
    }