IETF Logo Mail Archive

Re: [Netconf] Draft Charter Proposal for NETCONF WG

Alexander Clemm <alexander.clemm@huawei.com> Fri, 03 March 2017 18:27 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 9894812959D for <netconf@ietfa.amsl.com>; Fri, 3 Mar 2017 10:27:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 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, 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 8hBC56oLTLMl for <netconf@ietfa.amsl.com>; Fri, 3 Mar 2017 10:27:37 -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 2D074129519 for <netconf@ietf.org>; Fri, 3 Mar 2017 10:27:37 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DIG23204; Fri, 03 Mar 2017 18:27:35 +0000 (GMT)
Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 3 Mar 2017 18:27:35 +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:27:31 -0800
From: Alexander Clemm <alexander.clemm@huawei.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "Eric Voit (evoit)" <evoit@cisco.com>
Thread-Topic: [Netconf] Draft Charter Proposal for NETCONF WG
Thread-Index: AdKROeE3Cc7ORdXbRmOFzdaoTO5UHAAUAz4AADp8tuoAFK6oAAAIWK6AABh7IYAAFNf1AAAH4l2AAACc6QAAAeMxMAAfCE8AAAOOA4AAAZ6zAAADHY/Q
Date: Fri, 03 Mar 2017 18:27:29 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF84052@SJCEML703-CHM.china.huawei.com>
References: <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> <CABCOCHQ7zymX=0qtT9_ihamxDHiokkP9bE2bac-8Y=eU+bcXoQ@mail.gmail.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF83D7A@SJCEML703-CHM.china.huawei.com> <20170303092406.GA2790@elstar.local> <0ba776220d76471abcfb1b3b9a956421@XCH-RTP-013.cisco.com> <20170303115216.GA2992@elstar.local>
In-Reply-To: <20170303115216.GA2992@elstar.local>
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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.58B9B597.02D7, 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/ommuGD4SzxUu2UtwpLalA7yewAY>
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:27:38 -0000

Hi Jurgen,

I responded to the earlier message without seeing this. 

Quick comment below, <ALEX>

--- Alex

-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] 
Sent: Friday, March 03, 2017 3:52 AM
To: Eric Voit (evoit) <evoit@cisco.com>
Cc: Alexander Clemm <alexander.clemm@huawei.com>; Andy Bierman <andy@yumaworks.com>; Netconf <netconf@ietf.org>
Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG

On Fri, Mar 03, 2017 at 11:05:53AM +0000, Eric Voit (evoit) wrote:
> 
> 
> > From: Juergen Schoenwaelder, March 3, 2017 4:24 AM
> > 
> > On Fri, Mar 03, 2017 at 01:01:10AM +0000, Alexander Clemm wrote:
> > >
> > > 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.
> > >
> > 
> > My question since the very beginning is: Is the idea to run 
> > configuration editing transactions across mount points?
> 
> My position is that there is huge value in read only access.  I have no desire to champion edit operations. 
>

Reading data of course has value but then NETCONF has this little 'CONF' in its name...

<ALEX>This does not prevent network to have operational state (and applied datastore) in its scope... </ALEX>

Anyway, if the peer mount is designed as a read-only access mechanism, how are the VMs then configured? I suppose there then needs to be a different addressing mechanism to access the VM's configuration data, e.g., something Andy was hinting at. Or how does this work?

<ALEX> The authoritative owner is still the mount server, i.e. the system from which information is mounted.  I agree with Eric, no desire to champion cross-network edit operations/transaction, and still a lot of value in having read access from other systems.  </ALEX>

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

v2.23.0 | Report a Bug | By Email