Re: [Netconf] Draft Charter Proposal for NETCONF WG

Alexander Clemm <alexander.clemm@huawei.com> Fri, 03 March 2017 18:45 UTC

Return-Path: <alexander.clemm@huawei.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 217C4129987 for <netconf@ietfa.amsl.com>; Fri, 3 Mar 2017 10:45:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.222
X-Spam-Level:
X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 GxkFt6lHma3Z for <netconf@ietfa.amsl.com>; Fri, 3 Mar 2017 10:45:26 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E95CE129986 for <netconf@ietf.org>; Fri, 3 Mar 2017 10:45:25 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml709-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DIG24589; Fri, 03 Mar 2017 18:44:20 +0000 (GMT)
Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 3 Mar 2017 18:44:19 +0000
Received: from SJCEML703-CHM.china.huawei.com ([169.254.5.69]) by SJCEML702-CHM.china.huawei.com ([169.254.4.133]) with mapi id 14.03.0235.001; Fri, 3 Mar 2017 10:44:09 -0800
From: Alexander Clemm <alexander.clemm@huawei.com>
To: Ladislav Lhotka <lhotka@nic.cz>, "Eric Voit (evoit)" <evoit@cisco.com>, Andy Bierman <andy@yumaworks.com>, Kent Watsen <kwatsen@juniper.net>, Lou Berger <lberger@labn.net>, "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <rwilton@cisco.com>
Thread-Topic: [Netconf] Draft Charter Proposal for NETCONF WG
Thread-Index: AdKROeE3Cc7ORdXbRmOFzdaoTO5UHAAUAz4AADp8tuoAFK6oAAAIWK6AABh7IYAAFNf1AAAH4l2AADC9MAAADM+4wA==
Date: Fri, 03 Mar 2017 18:44:06 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF842A3@SJCEML703-CHM.china.huawei.com>
References: <014101d2913a$3db72870$b9257950$@gmail.com> <20170227221434.GB68878@elstar.local> <026f01d29273$5d57dfa0$4001a8c0@gateway.2wire.net> <F1EB9C98-BB1C-410D-9D6D-1777A96148C6@nic.cz> <CABCOCHTVZxPyT_LSX2GjnNKFCz3857HAOA_GS5iTaxLejno8RQ@mail.gmail.com> <bc6813b038094a1eac1fc9df68f3205c@XCH-RTP-013.cisco.com> <m2pohzpznf.fsf@birdie.labs.nic.cz> <e2cd792fb1734d04b5d0340617ff39e9@XCH-RTP-013.cisco.com> <m2bmti8gcd.fsf@birdie.labs.nic.cz>
In-Reply-To: <m2bmti8gcd.fsf@birdie.labs.nic.cz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.213.48.147]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.58B9B9C4.0033, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.69, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 1809d283cf2658cca22cf4d3fd86be9b
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/e1qsAjrqvMxbpc-3QMzvDA8SEeM>
Cc: Netconf <netconf@ietf.org>
Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Mar 2017 18:45:28 -0000


-----Original Message-----
...
>
> An operator doesn't want external systems to individually address 
> every control plane VM.  Rather they want a YANG model for this
> logical+physical combination.  In this case each VM might use Peer
> (data) Mount to build a multi-device abstraction.  BTW: doing it this 
> way also allows the same mounted YANG object data to be addressably 
> exposed for each VM without requiring another YANG model to be made.

I think this can be mostly accomplished with the "inline" approach of schema mount (which in fact is a data mount and probably very similar to the concept of peer mount).

<ALEX> While schema mount was triggered by and in some way originated from earlier discussions surrounding peer mount, they are not the same.  They accomplish something different.  With schema mount, you can reuse / incorporate earlier definitions.  It is about extending definitions and being able to reuse models defined earlier, but how to implement and populate the data is up to the implementation.  With peer-mount, the population of the data is very much part of the concept and can be inherently provided by the framework (as the mount target and authoritative source of the data will be managed as part of the mountpoint).  
</ALEX>