for operational data sources. =C2=A0The <config-source>

parameters were removed from ietf-system.yang because

a g= eneral solution was going to replace it.

The draft now addresses that issue.

Andy

---------- Forwarde= d message ----------
From: <internet-drafts@ie= tf.org>
Date: Tue, Oct 9, 2012 at 2:32 PM
Subject: I-D Action: draft-bierman-net= conf-get2-02.txt
To: i-d-announ= ce@ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : The = NETCONF <get2> Operation
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author(s) =C2=A0 =C2=A0 =C2=A0 : Andy Bierman =C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-bie= rman-netconf-get2-02.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 38 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 2012-10-09

Abstract:
=C2=A0 =C2=A0This document describes NETCONF protocol enhancements to impro= ve data
=C2=A0 =C2=A0retrieval capabilities.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bierman-netconf-get2<= /a>

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-bierman-netconf-get2-02
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-bierman-netcon= f-get2-02

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--047d7b67859c615ff204cba71b8b-- From lhotka@nic.cz Wed Oct 10 13:37:07 2012 Return-Path: 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 60DE611E80A2 for ; Wed, 10 Oct 2012 13:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.871 X-Spam-Level: X-Spam-Status: No, score=-1.871 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VSSx-3CknqH for ; Wed, 10 Oct 2012 13:37:06 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 82E7711E809C for ; Wed, 10 Oct 2012 13:37:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 713DD5405D2; Wed, 10 Oct 2012 22:37:04 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKp5+0ddT2gD; Wed, 10 Oct 2012 22:37:00 +0200 (CEST) Received: from localhost (unknown [10.107.191.189]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id CD5605400CF; Wed, 10 Oct 2012 22:36:55 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman , Netconf In-Reply-To: References: <20121009213214.25913.45601.idtracker@ietfa.amsl.com> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Date: Wed, 10 Oct 2012 22:36:34 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Netconf] Fwd: I-D Action: draft-bierman-netconf-get2-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 20:37:07 -0000 Hi, I read the draft, I think it contains a number of useful improvements over the existing and methods. Here are my comments: 1. The operational datastore contains some "config true" container and list nodes, which may lead to a situation where the operational and running datastores get out of sync. For example, what happens if an removes a list entry that's also present in the operational datastore? Two scenarios seem to make sense, and both can be in fact applicable to different entries of the same list: either the entry stays in the op. datastore or it is also deleted. The draft should address this. 2. Besides the "depth" parameter, a "length" parameter might be useful for limiting the number of returned list entries, such as routes. A related convenient feature would be some kind of paging. 3. Maybe "data-source" needs finer granularity because potentially it may result in huge output even if the client is only interested in the data source for one or few nodes. One way can be to allow the client to ask for or suppress data source info as a part of the filter, e.g.,

Lada Andy Bierman writes: > FYI, > > I updated the draft to include support > for operational data sources. The > parameters were removed from ietf-system.yang because > a general solution was going to replace it. > The draft now addresses that issue. > > > Andy > > > ---------- Forwarded message ---------- > From: > Date: Tue, Oct 9, 2012 at 2:32 PM > Subject: I-D Action: draft-bierman-netconf-get2-02.txt > To: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : The NETCONF Operation > Author(s) : Andy Bierman > Filename : draft-bierman-netconf-get2-02.txt > Pages : 38 > Date : 2012-10-09 > > Abstract: > This document describes NETCONF protocol enhancements to improve data > retrieval capabilities. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-bierman-netconf-get2 > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-bierman-netconf-get2-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-bierman-netconf-get2-02 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Wed Oct 10 19:40:10 2012 Return-Path: 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 8AA8821F8516 for ; Wed, 10 Oct 2012 19:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECYpsHj0-O0J for ; Wed, 10 Oct 2012 19:40:09 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8D68F21F8513 for ; Wed, 10 Oct 2012 19:40:09 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so2534640iec.31 for ; Wed, 10 Oct 2012 19:40:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=oMaSQbfzhCbr87wj9/PoOxo7VOsG2Pvw15V8N5k9lAI=; b=fpFOjTUtLX5QggRAEWiYyyTUVGBwXDBBVcxfbxMWHC+q7tV9249YRFMaXl5E5IAKNX MiitSechZjoPCplo4SSxpiVWcukxEsxXcv4gg+ucnlLIdP+4Nu69E0GwgKff/iyI0TQ1 ojlt6PzTfz1NI9UObddOyetR+w78mo4VMTKOjHA7zhe9v8zIV6KyMwbnLvJYLbo7jSTU TnrIYJWgzXOMy8s2nn2WpTVBKLOWMo++IAgjwG04KgtqcxToBWD5BZ6T5Hd3fVMqWC59 MhzRPNc4xrOFRZTd2MdhHrqmRFBJfHzwXLVsyHpd9QU4gEMfkcoPSCjpxG+VDX58VFUS 97KQ== MIME-Version: 1.0 Received: by 10.50.149.193 with SMTP id uc1mr7326789igb.60.1349923209036; Wed, 10 Oct 2012 19:40:09 -0700 (PDT) Received: by 10.50.182.194 with HTTP; Wed, 10 Oct 2012 19:40:09 -0700 (PDT) In-Reply-To: References: <20121009213214.25913.45601.idtracker@ietfa.amsl.com> Date: Wed, 10 Oct 2012 19:40:09 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=e89a8f22c6ff59427a04cbbf7d98 X-Gm-Message-State: ALoCoQnzMfNaG7K0jbX/4l9OKHgeiWDX8QhDX3sOwgwbR67VKKKv9IetVeE5F9fnzlVtOb1wFiQp Cc: Netconf Subject: Re: [Netconf] Fwd: I-D Action: draft-bierman-netconf-get2-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 02:40:10 -0000 --e89a8f22c6ff59427a04cbbf7d98 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 10, 2012 at 1:36 PM, Ladislav Lhotka wrote: > Hi, > > I read the draft, I think it contains a number of useful improvements over > the existing and methods. Here are my comments: > > 1. The operational datastore contains some "config true" container and > list nodes, which may lead to a situation where the operational and running > datastores get out of sync. For example, what happens if an > removes a list entry that's also present in the operational datastore? Two > scenarios seem to make sense, and both can be in fact applicable to > different entries of the same list: either the entry stays in the op. > datastore or it is also deleted. The draft should address this. > How can they get out of sync? You mean by skew from the polling implementation? The operational datastore needs to be consistent with the ancestor nodes and key leafs that provide context. Not a NETCONF-specific issue meaning any protocol that accesses both the config and operational datastores has this potential problem. > > 2. Besides the "depth" parameter, a "length" parameter might be useful for > limiting the number of returned list entries, such as routes. A related > convenient feature would be some kind of paging. > > I've talked to a couple NMS lead engineers who call this feature "Iterators". They really wanted it in NETCONF. You need a start index and a max-number of entries. Another approach is the Range from HTTP (borrowed in YANG-API). It can get complicated, so I left it out of . It probably needs its own draft. I agree it is a useful feature. 3. Maybe "data-source" needs finer granularity because potentially it may > result in huge output even if the client is only interested in the data > source for one or few nodes. One way can be to allow the client to ask for > or suppress data source info as a part of the filter, e.g., > > > ds:data-source="false"> > > > > > > > > IMO, having the client set individual attributes in the request and forcing the server to parse all the many combinations (just like the operation and insert attributes) is too complicated. You can limit the data returned with a subtree filter. This example would only return 3 possible data-source attributes. Only 1 YANG extension is used so only 1 attribute is sent. IMO the data-source extension should only be used if there is a demonstrated reason for the operator to care about the data source identifier for that node. Lada > Andy > > Andy Bierman writes: > > > FYI, > > > > I updated the draft to include support > > for operational data sources. The > > parameters were removed from ietf-system.yang because > > a general solution was going to replace it. > > The draft now addresses that issue. > > > > > > Andy > > > > > > ---------- Forwarded message ---------- > > From: > > Date: Tue, Oct 9, 2012 at 2:32 PM > > Subject: I-D Action: draft-bierman-netconf-get2-02.txt > > To: i-d-announce@ietf.org > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : The NETCONF Operation > > Author(s) : Andy Bierman > > Filename : draft-bierman-netconf-get2-02.txt > > Pages : 38 > > Date : 2012-10-09 > > > > Abstract: > > This document describes NETCONF protocol enhancements to improve data > > retrieval capabilities. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-bierman-netconf-get2 > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-bierman-netconf-get2-02 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-bierman-netconf-get2-02 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > --e89a8f22c6ff59427a04cbbf7d98 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Oct 10, 2012 at 1:36 PM, Ladisla= v Lhotka <lhotka@nic.cz> wrote:

2. Besides the "depth" parameter, a "length" parameter = might be useful for limiting the number of returned list entries, such as r= outes. A related convenient feature would be some kind of paging.

I've talked to a couple NMS lead e= ngineers who call this feature "Iterators".

They really= wanted it in NETCONF.

You need a start index and = a max-number of entries.

Another approach is the Range from HTTP (borrowed in YANG-API).

<= div>It can get complicated, so I left it out of <get2>.

It = probably needs its own draft. I agree it is a useful feature.

3. Maybe "data-source" needs finer granularity because potentiall= y it may result in huge output even if the client is only interested in the= data source for one or few nodes. One way can be to allow the client to as= k for or suppress data source info as a part of the filter, e.g.,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<subtree-filter>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<system xmlns=3D"urn:ietf:= params:xml:ns:yang:ietf-system"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ds:dat= a-source=3D"false"> 
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<clock>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<current-datetime= ds:data-source=3D"true"/>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</clock>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</system>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</subtree-filter>

IMO, having the client set individual = attributes in the request

and forcing the server to parse all the= many combinations (just like

the operation and insert attributes= ) is too complicated.

You can limit the data returned with a subtree filter.<= /div>

This example would only return 3 possible data-source attributes.=

Only 1 YANG extension is used so only 1 attribute is sent.

IMO the data-source extension should only be used if th= ere

is a demonstrated reason for the operator to care about the

data source identifier for that node.

Lada

Andy

=C2= =A0

Andy Bierman <andy@yumaworks.com> writes:

> FYI,
>
> I updated the <get2> draft to include support
> for operational data sources. =C2=A0The <config-source>
> parameters were removed from ietf-system.yang because
> a general solution was going to replace it.
> The draft now addresses that issue.
>
>
> Andy
>
>
> ---------- Forwarded message ----------
> From: <internet-drafts@= ietf.org>
> Date: Tue, Oct 9, 2012 at 2:32 PM
> Subject: I-D Action: draft-bierman-netconf-get2-02.txt
> To: i-d-announce@ietf.org=
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := The NETCONF <get2> Operation
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Author(s) =C2=A0 =C2=A0 =C2=A0 : Andy Bier= man
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draf= t-bierman-netconf-get2-02.txt
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 38
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: 2012-10-09
>
> Abstract:
> =C2=A0 =C2=A0This document describes NETCONF protocol enhancements to = improve data
> =C2=A0 =C2=A0retrieval capabilities.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-bierman-netconf-= get2
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-bierman-netconf-get2-02
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-bierman-n= etconf-get2-02
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

--e89a8f22c6ff59427a04cbbf7d98-- From lhotka@nic.cz Wed Oct 10 22:59:00 2012 Return-Path: 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 71A9021F8581 for ; Wed, 10 Oct 2012 22:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.273 X-Spam-Level: X-Spam-Status: No, score=-1.273 tagged_above=-999 required=5 tests=[AWL=-0.474, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSgUKngod6X8 for ; Wed, 10 Oct 2012 22:58:59 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5491E21F853A for ; Wed, 10 Oct 2012 22:58:59 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 67242140871; Thu, 11 Oct 2012 07:58:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1349935138; bh=1iTVoz4MY4HPNfzGYMbj/LhJ9raeW1A92YnrfKde/ww=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Emo1vhjhBumgldtCOlaChIj7jbejOReyPyeOGQttRTNeVZSXDGwir9Pm3SOZUgFv9 ZNSmGCRKAUPb6F2slfU4j9Q+Fs5TDY7xwPFKN72JJsaogpFahcL6RnGXFpzcLPCsRY kLicOXMnnt6eRSdVqQVdndftuVFBwI0eqDtAFTgk= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) From: Ladislav Lhotka In-Reply-To: Date: Thu, 11 Oct 2012 07:58:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0A941830-8C86-4E8C-9A96-08DF7250C9A7@nic.cz> References: <20121009213214.25913.45601.idtracker@ietfa.amsl.com> To: Andy Bierman X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Netconf Subject: Re: [Netconf] Fwd: I-D Action: draft-bierman-netconf-get2-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 05:59:00 -0000 On Oct 11, 2012, at 4:40 AM, Andy Bierman wrote: >=20 >=20 > On Wed, Oct 10, 2012 at 1:36 PM, Ladislav Lhotka = wrote: > Hi, >=20 > I read the draft, I think it contains a number of useful improvements = over the existing and methods. Here are my comments: >=20 > 1. The operational datastore contains some "config true" container and = list nodes, which may lead to a situation where the operational and = running datastores get out of sync. For example, what happens if an = removes a list entry that's also present in the = operational datastore? Two scenarios seem to make sense, and both can be = in fact applicable to different entries of the same list: either the = entry stays in the op. datastore or it is also deleted. The draft should = address this. >=20 > How can they get out of sync? You mean by skew from the polling = implementation? For an interface, we will have an entry = /if:interfaces/if:interface[if:name=3D'X'] in both "running" and = "operational", one with config=3Dtrue and the other with config=3Dfalse = data, if I understand it correctly. Now, if the client uses on "running" and deletes this = entry, what happens to the entry in "operational"? If X is a physical = interface, it should stay there, but if it is a configured tunnel, it = should be removed, too. Lada =20 > The operational datastore needs to be consistent with the ancestor = nodes and key leafs > that provide context. Not a NETCONF-specific issue meaning any = protocol that > accesses both the config and operational datastores has this potential = problem. >=20 > =20 >=20 > 2. Besides the "depth" parameter, a "length" parameter might be useful = for limiting the number of returned list entries, such as routes. A = related convenient feature would be some kind of paging. >=20 >=20 > I've talked to a couple NMS lead engineers who call this feature = "Iterators". > They really wanted it in NETCONF. >=20 > You need a start index and a max-number of entries. > Another approach is the Range from HTTP (borrowed in YANG-API). > It can get complicated, so I left it out of . > It probably needs its own draft. I agree it is a useful feature. >=20 >=20 > 3. Maybe "data-source" needs finer granularity because potentially it = may result in huge output even if the client is only interested in the = data source for one or few nodes. One way can be to allow the client to = ask for or suppress data source info as a part of the filter, e.g., >=20 > > ds:data-source=3D"false"> > > > > > > >=20 >=20 > IMO, having the client set individual attributes in the request > and forcing the server to parse all the many combinations (just like > the operation and insert attributes) is too complicated. >=20 > You can limit the data returned with a subtree filter. > This example would only return 3 possible data-source attributes. > Only 1 YANG extension is used so only 1 attribute is sent. >=20 > IMO the data-source extension should only be used if there > is a demonstrated reason for the operator to care about the > data source identifier for that node. >=20 >=20 > Lada >=20 >=20 > Andy > =20 >=20 > Andy Bierman writes: >=20 > > FYI, > > > > I updated the draft to include support > > for operational data sources. The > > parameters were removed from ietf-system.yang because > > a general solution was going to replace it. > > The draft now addresses that issue. > > > > > > Andy > > > > > > ---------- Forwarded message ---------- > > From: > > Date: Tue, Oct 9, 2012 at 2:32 PM > > Subject: I-D Action: draft-bierman-netconf-get2-02.txt > > To: i-d-announce@ietf.org > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : The NETCONF Operation > > Author(s) : Andy Bierman > > Filename : draft-bierman-netconf-get2-02.txt > > Pages : 38 > > Date : 2012-10-09 > > > > Abstract: > > This document describes NETCONF protocol enhancements to improve = data > > retrieval capabilities. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-bierman-netconf-get2 > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-bierman-netconf-get2-02 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-bierman-netconf-get2-02 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From iesg-secretary@ietf.org Mon Oct 15 14:44:41 2012 Return-Path: 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 19C6C21F8A14; Mon, 15 Oct 2012 14:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ch1501FT5kVC; Mon, 15 Oct 2012 14:44:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D28C21F89FF; Mon, 15 Oct 2012 14:44:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121015214439.23759.59977.idtracker@ietfa.amsl.com> Date: Mon, 15 Oct 2012 14:44:39 -0700 Cc: netconf mailing list , RFC Editor Subject: [Netconf] Protocol Action: 'Using NETCONF over the Simple Object Access Protocol (SOAP)' (RFC 4743) to Historic X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 21:44:41 -0000 The IESG has approved the following document: - 'Using NETCONF over the Simple Object Access Protocol (SOAP)' RFC 4743 as an Historic RFC. This document is the product of the Network Configuration Working Group. = A URL of this document is: https://datatracker.ietf.org/doc/rfc4743/ From iesg-secretary@ietf.org Mon Oct 15 14:53:15 2012 Return-Path: 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 6A50C21F8ADC; Mon, 15 Oct 2012 14:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5psUcA4-Vvtg; Mon, 15 Oct 2012 14:53:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA41621F8AD7; Mon, 15 Oct 2012 14:53:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121015215314.934.37091.idtracker@ietfa.amsl.com> Date: Mon, 15 Oct 2012 14:53:14 -0700 Cc: netconf mailing list , RFC Editor Subject: [Netconf] Protocol Action: 'Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP)' (RFC 4744) to Historic X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 21:53:15 -0000 The IESG has approved the following document: - 'Using the NETCONF Protocol over the Blocks Extensible Exchange = Protocol (BEEP)' RFC 4744 as an Historic RFC. This document is the product of the Network Configuration Working Group. = A URL of this document is: https://datatracker.ietf.org/doc/rfc4744/ From rohit.pobbathi@huawei.com Tue Oct 16 04:33:52 2012 Return-Path: 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 C572D21F8661 for ; Tue, 16 Oct 2012 04:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.148 X-Spam-Level: X-Spam-Status: No, score=-5.148 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_MIMEOLE=0.001, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTbDmt+JMKoh for ; Tue, 16 Oct 2012 04:33:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E6ACC21F863F for ; Tue, 16 Oct 2012 04:33:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKQ64985; Tue, 16 Oct 2012 11:33:51 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 16 Oct 2012 12:33:08 +0100 Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 16 Oct 2012 12:33:40 +0100 Received: from blrprnc10ns (10.18.96.99) by SZXEML414-HUB.china.huawei.com (10.82.67.153) with Microsoft SMTP Server id 14.1.323.3; Tue, 16 Oct 2012 19:33:35 +0800 From: Rohit Pobbathi To: Date: Tue, 16 Oct 2012 17:03:34 +0530 Organization: Htipl Message-ID: <000601cdab92$13e608f0$3bb21ad0$@pobbathi@huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CDABC0.2D9E44F0" X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Office Outlook 12.0 thread-index: Ac2rkhMb4OITT1ytR3CuXjtC4wc+hQ== Content-Language: en-us Importance: High X-Originating-IP: [10.18.96.99] X-CFilter-Loop: Reflected Subject: [Netconf] Idle timeout handling in NETCONF session with notification subscription X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: rohit.pobbathi@huawei.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 11:33:52 -0000 ------=_NextPart_000_0007_01CDABC0.2D9E44F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, What should be the behavior of SSH Idle Timeout for a NETCONF Session with notification subscription (without interleave) ? The time interval between the cannot be predicted. RFC 5277 is silent on the above issue. Regards, Rohit ------=_NextPart_000_0007_01CDABC0.2D9E44F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

What should = be the behavior of SSH Idle Timeout for a NETCONF Session with = notification subscription (without interleave) ?

The time interval between the <notification> = cannot be predicted.

RFC 5277 is = silent on the above issue.

Regards,

Rohit

------=_NextPart_000_0007_01CDABC0.2D9E44F0-- From andy@yumaworks.com Wed Oct 17 06:29:23 2012 Return-Path: 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 576BD21F8786 for ; Wed, 17 Oct 2012 06:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.712 X-Spam-Level: X-Spam-Status: No, score=-2.712 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TiOqZYFRmuWS for ; Wed, 17 Oct 2012 06:29:22 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 845C021F8772 for ; Wed, 17 Oct 2012 06:29:22 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so5734103lbo.31 for ; Wed, 17 Oct 2012 06:29:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=r+LCXgx2qRTIUYuTnd56Mu2BLc4Tfuodb9pUJUXt0zQ=; b=htJoy7ok/Q3InB/OUgYDTH7eJVHwRDslSnPR69ZsyL5WgDPxxbeJiNEBkzlcEGdIfY UM2Uu5cDfvsr/348n8pTu2WzMoJK/aSsC5LmBh46aWbXrFIvfae08/VYPr+1OdS8AdXY BANXWMwpxaIzcX10/yj7Altlhcl+g5/zRE0ybKsTwAAT7GnLe21qBVG/Daxcs46k5aFk 4vXhxi+/sBT478rxHGYiDbmpc1O/z9BuhMF+9vKlWjjjcwhvZI0CXxudMzxixjsJEzrh qZtl/zHFvVo2LJ/MJJoVNvb3CQPI8+14FdCB7MYyHsvEcJwuB199/sSS02QibUub+wY0 MNvg== MIME-Version: 1.0 Received: by 10.152.124.111 with SMTP id mh15mr15798298lab.20.1350480561414; Wed, 17 Oct 2012 06:29:21 -0700 (PDT) Received: by 10.112.108.198 with HTTP; Wed, 17 Oct 2012 06:29:21 -0700 (PDT) In-Reply-To: <507d4625.694a420a.48f4.786cSMTPIN_ADDED@mx.google.com> References: <507d4625.694a420a.48f4.786cSMTPIN_ADDED@mx.google.com> Date: Wed, 17 Oct 2012 06:29:21 -0700 Message-ID: From: Andy Bierman To: rohit.pobbathi@huawei.com Content-Type: multipart/alternative; boundary=f46d042f954e23a3ee04cc41424d X-Gm-Message-State: ALoCoQnnP/mxibIWHWy0HCnnKaL7wbmtqaKo+0vmwFEE9DONBHQa+IvPfGXlWVNdmJlJB517r2B4 Cc: netconf@ietf.org Subject: Re: [Netconf] Idle timeout handling in NETCONF session with notification subscription X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 13:29:23 -0000 --f46d042f954e23a3ee04cc41424d Content-Type: text/plain; charset=UTF-8 NETCONF is silent on all timeouts, except confirmed commit. We implement configurable hello-timeout and idle-timeout parameters. The default idle timeout is an hour, and any session with notifications active is not subject to an idle-timeout. NETCONF does not say you are allowed to drop idle sessions or sessions stuck in 'hello-wait' state. But the standard leaves out lots of stuff that real implementations have to deal with. Andy On Tue, Oct 16, 2012 at 4:33 AM, Rohit Pobbathi wrote: > Hi,**** > > ** ** > > What should be the behavior of SSH Idle Timeout for a NETCONF Session with > notification subscription (without interleave) ?**** > > The time interval between the cannot be predicted.**** > > ** ** > > RFC 5277 is silent on the above issue.**** > > ** ** > > Regards,**** > > Rohit**** > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --f46d042f954e23a3ee04cc41424d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable NETCONF is silent on all timeouts, except confirmed commit.

We implemen= t configurable hello-timeout and idle-timeout parameters.

The def= ault idle timeout is an hour, and any session with notifications

active is not subject to an idle-timeout.

NETCONF does not say you a= re allowed to drop idle sessions

or sessions stuck in 'hello-= wait' state. =C2=A0But the standard leaves out lots

of stuff = that real implementations have to deal with.

Andy

On Tue, Oct 16, 2012 at 4:33 AM, Rohit Pobbathi <rohit.pobbathi@huawei.com> wrote:

Hi,
=C2=A0

What should be the behavior of SSH Idle Timeout for = a NETCONF Session with notification subscription (without interleave) ?<= /u>
The time interval between the <noti= fication> cannot be predicted.

=C2=A0
RFC 5= 277 is silent on the above issue.
<= u>=C2=A0
Regards,
Rohit

____________________________________= ___________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

--f46d042f954e23a3ee04cc41424d-- From internet-drafts@ietf.org Mon Oct 22 10:09:48 2012 Return-Path: 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 6260611E80D3; Mon, 22 Oct 2012 10:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Eklv7OMUuXO; Mon, 22 Oct 2012 10:09:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BBF211E8097; Mon, 22 Oct 2012 10:09:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022170946.14634.46564.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 10:09:46 -0700 Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-rfc5539bis-01.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 17:09:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network Configuration Working Group of th= e IETF. Title : NETCONF Over Transport Layer Security (TLS) Author(s) : Mohamad Badra Alan Luchuk Juergen Schoenwaelder Filename : draft-ietf-netconf-rfc5539bis-01.txt Pages : 18 Date : 2012-10-22 Abstract: The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol to secure NETCONF exchanges. This document obsoletes RFC 5539. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-rfc5539bis-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mbadra@gmail.com Mon Oct 22 10:12:09 2012 Return-Path: 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 0315E11E80ED for ; Mon, 22 Oct 2012 10:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LarhomOLVJTH for ; Mon, 22 Oct 2012 10:12:01 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id F3ECE11E80A5 for ; Mon, 22 Oct 2012 10:11:58 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so2102673lbo.31 for ; Mon, 22 Oct 2012 10:11:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=TvVnuj/zaPxHeXJKupFydjxiYLEDFAzz6Px2cyWXEqo=; b=xIwjMN9aKN7oKYn7NZaKkl7cSuNSY4xqsb1smvbH5I4pUb26ujHxrASfoE89qXVcB/ AD4ZakDvr0e3qz8yQvzy1QyGuyycox6Hz9kfHZLgqoNn3cFNbcaphZrR5cCUUAhEzMQq UdN2uD5UvINny62mHncyNF88eoaH8H7GnrQeH1J/gJo8MuZGyDbc4RU254e8pbgriUeQ 1wj4MmR0Rk6bbuD7E2xZnBStymNfMLvG1kqx7i8CxflOwyEMsRXd7T+GgDZfjuiPQFXl OiuhSSTYG/VvW/0GZS194xab+mIcPofOg0p/cgdXTgO69nRrn5RXSzz3EBK7LpTLd69J mfyw== MIME-Version: 1.0 Received: by 10.152.47.112 with SMTP id c16mr8944452lan.50.1350925917449; Mon, 22 Oct 2012 10:11:57 -0700 (PDT) Received: by 10.114.37.202 with HTTP; Mon, 22 Oct 2012 10:11:57 -0700 (PDT) In-Reply-To: <20121022170946.14634.99705.idtracker@ietfa.amsl.com> References: <20121022170946.14634.99705.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 19:11:57 +0200 Message-ID: From: Mohamad Badra To: netconf@ietf.org Content-Type: multipart/alternative; boundary=bcaec55408266d6c1e04cca8f379 Subject: [Netconf] New Version Notification for draft-ietf-netconf-rfc5539bis-01.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 17:12:09 -0000 --bcaec55408266d6c1e04cca8f379 Content-Type: text/plain; charset=ISO-8859-1 Dear All, This is to inform you that a new revision of rfc5539bis is now available Comments are welcome! Best regards Bada ---------- Forwarded message ---------- From: Date: Mon, Oct 22, 2012 at 7:09 PM Subject: New Version Notification for draft-ietf-netconf-rfc5539bis-01.txt A new version of I-D, draft-ietf-netconf-rfc5539bis-01.txt has been successfully submitted by Mohamad Badra and posted to the IETF repository. Filename: draft-ietf-netconf-rfc5539bis Revision: 01 Title: NETCONF Over Transport Layer Security (TLS) Creation date: 2012-10-22 WG ID: netconf Number of pages: 18 URL: http://www.ietf.org/internet-drafts/draft-ietf-netconf-rfc5539bis-01.txt Status: http://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis Htmlized: http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc5539bis-01 Abstract: The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol to secure NETCONF exchanges. This document obsoletes RFC 5539. The IETF Secretariat --bcaec55408266d6c1e04cca8f379 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Dear All,

This is to inform you that a = new revision of rfc5539bis is now available

Commen= ts are welcome!

Best regards

Bada

---------- Forwarded message ----------
From: <= internet-drafts@ietf.org>
Date: Mon, Oct 22, 2012 at 7:09 = PM
Subject: New Version Notification for draft-ietf-netconf-rfc5539bis-01.txt<= br>
A new version of I-D, draft-ietf-netconf-rfc5539bis-01.txt
has been successfully submitted by Mohamad Badra and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-ietf-netconf-rfc5539bis
Revision: =A0 =A0 =A0 =A001
Title: =A0 =A0 =A0 =A0 =A0 NETCONF Over Transport Layer Security (TLS)
Creation date: =A0 2012-10-22
WG ID: =A0 =A0 =A0 =A0 =A0 netconf
Number of pages: 18
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.or= g/internet-drafts/draft-ietf-netconf-rfc5539bis-01.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc= /draft-ietf-netconf-rfc5539bis
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-ie= tf-netconf-rfc5539bis-01
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/rfc= diff?url2=3Ddraft-ietf-netconf-rfc5539bis-01

Abstract:
=A0 =A0The Network Configuration Protocol (NETCONF) provides mechanisms to<= br> =A0 =A0install, manipulate, and delete the configuration of network devices= .
=A0 =A0This document describes how to use the Transport Layer Security (TLS= )
=A0 =A0protocol to secure NETCONF exchanges. =A0This document obsoletes RFC=
=A0 =A05539.

The IETF Secretariat

--bcaec55408266d6c1e04cca8f379-- From mehmet.ersue@nsn.com Wed Oct 24 02:28:50 2012 Return-Path: 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 58B2F21F8BC5 for ; Wed, 24 Oct 2012 02:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.59 X-Spam-Level: X-Spam-Status: No, score=-106.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zf8BRGWgiDmb for ; Wed, 24 Oct 2012 02:28:49 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 1185121F8BC3 for ; Wed, 24 Oct 2012 02:28:48 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q9O9SgDn010463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 24 Oct 2012 11:28:43 +0200 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q9O9Sd8Z007051; Wed, 24 Oct 2012 11:28:42 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 24 Oct 2012 11:28:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Oct 2012 11:28:37 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A640455E03D@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft Agenda for Atlanta Meeting Thread-Index: Ac2xyfJh253HpTbwTuK+SrEx4rMnJQ== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 24 Oct 2012 09:28:38.0611 (UTC) FILETIME=[F2F22230:01CDB1C9] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 392 X-purgate-ID: 151667::1351070924-000048BF-6A636D5E/0-0/0-0 Subject: [Netconf] Draft Agenda for Atlanta Meeting X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 09:28:50 -0000 Dear NETCONF WG, below is the draft agenda for the NETCONF WG session in IETF 85: http://www.ietf.org/proceedings/85/agenda/agenda-85-netconf Please send us a note if there is any other topic we should address. FYI: We agreed with the NETMOD co-chairs to use the slots for "operational state" in both sessions jointly in sequence on Tuesday and Wednesday. Mehmet & Bert From jernej.tuljak@mg-soft.si Thu Oct 25 04:02:32 2012 Return-Path: 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 6218321F8916 for ; Thu, 25 Oct 2012 04:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.325 X-Spam-Level: X-Spam-Status: No, score=-1.325 tagged_above=-999 required=5 tests=[AWL=-1.141, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wJ6Dbo1I3eG for ; Thu, 25 Oct 2012 04:02:31 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 605E821F890D for ; Thu, 25 Oct 2012 04:02:30 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id q9PB2RGS029588 for ; Thu, 25 Oct 2012 13:02:28 +0200 Message-ID: <50891C42.101@mg-soft.com> Date: Thu, 25 Oct 2012 13:02:26 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Netconf Content-Type: multipart/alternative; boundary="------------040505060505000205030903" Subject: [Netconf] A data modeling question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 11:02:32 -0000 This is a multi-part message in MIME format. --------------040505060505000205030903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I have a question about the future of NETCONF in terms of servers exposing their data model to clients. I know RFC6241 states the data model is out of it's scope but will this always be the case? I've been following the discussions on both Netmod and Netconf mailing-lists for some time now and got the feeling that YANG and NETCONF are going to get coupled more closely together in the future. This makes sense since YANG represents the only standard way of exposing a server's data model (the only way I know of, except for base protocol capability URIs). Without it, NETCONF probably loses most of it's value. You could avoid YANG and resort to an XSD, RNG schema or something similar, since YANG is just a specialized XML schema anyways. But doing that automatically means you are doing things in a non-standard way. There's nothing written anywhere about how a server using XSD instead of YANG is supposed to announce it's capabilities, so implementers are bound to come up with different ways of handling this. Even in case of YANG, not everything about announcing conformance is clear, as some discussions have proven. And then there's also the differentiation between state and config data (and quite possibly other types soon). There's lots of ways you could achieve that with a general XML schema. The reason I'm writing this is that we recently had a feature request for our client to support XML schema along with YANG. Since our client is striving to be a generic one (bottom up approach according to RFC6244) and there's no standard way or even guidelines to handle such data models, it feels like implementing this would be a step in the wrong direction. It might even send a wrong signal to other users which could then easily assume that YANG is just another thing they don't need to bother with. But is this really the case? In the coming interop tests there is currently a small number of servers listed to join in and most of them are YANG-based or at least use YANG modules in their hello message (avoiding actual numbers here because I don't know if they can be discussed). What does that mean? I'm not trying to propose anything here. I'd just like to know what others think about the loose way of how NETCONF currently treats data models and how this might end up in the future. Jernej --------------040505060505000205030903 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hi,

I have a question about the future of NETCONF in terms of servers exposing their data model to clients. I know RFC6241 states the data model is out of it's scope but will this always be the case?

I've been following the discussions on both Netmod and Netconf mailing-lists for some time now and got the feeling that YANG and NETCONF are going to get coupled more closely together in the future. This makes sense since YANG represents the only standard way of exposing a server's data model (the only way I know of, except for base protocol capability URIs). Without it, NETCONF probably loses most of it's value. You could avoid YANG and resort to an XSD, RNG schema or something similar, since YANG is just a specialized XML schema anyways. But doing that automatically means you are doing things in a non-standard way. There's nothing written anywhere about how a server using XSD instead of YANG is supposed to announce it's capabilities, so implementers are bound to come up with different ways of handling this. Even in case of YANG, not everything about announcing conformance is clear, as some discussions have proven. And then there's also the differentiation between state and config data (and quite possibly other types soon). There's lots of ways you could achieve that with a general XML schema.

The reason I'm writing this is that we recently had a feature request for our client to support XML schema along with YANG. Since our client is striving to be a generic one (bottom up approach according to RFC6244) and there's no standard way or even guidelines to handle such data models, it feels like implementing this would be a step in the wrong direction. It might even send a wrong signal to other users which could then easily assume that YANG is just another thing they don't need to bother with. But is this really the case? In the coming interop tests there is currently a small number of servers listed to join in and most of them are YANG-based or at least use YANG modules in their hello message (avoiding actual numbers here because I don't know if they can be discussed). What does that mean?

I'm not trying to propose anything here. I'd just like to know what others think about the loose way of how NETCONF currently treats data models and how this might end up in the future.

Jernej

--------------040505060505000205030903-- From lhotka@nic.cz Thu Oct 25 04:45:16 2012 Return-Path: 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 D925E21F879E for ; Thu, 25 Oct 2012 04:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T+4pWjo62UG4 for ; Thu, 25 Oct 2012 04:45:16 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 2002521F8620 for ; Thu, 25 Oct 2012 04:45:15 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:1599:53f8:eb1a:518f] (unknown [IPv6:2001:1488:ac14:1400:1599:53f8:eb1a:518f]) by mail.nic.cz (Postfix) with ESMTPSA id 5B4F613FD97; Thu, 25 Oct 2012 13:45:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1351165514; bh=MZauXEdJ/Auf9BJ3VoTyxR2wsOuPk/ewZZo4+Mtt0yQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=YtcBdtQbmi2q0LZXMok4egzHKXbl7I1eEsGRsdPwvXsG9AKvcXdcVvz7OaA+8YBNX 9oGId7uguL8W2x2YzUPvWWMVdGQEU2rqrmkifnFCD1oIS175kYXYbFuEkj357Q9vEM ikU6cJoRQxTsUIeDGP4DgdRrfx1HhkjC3fwL8U+Y= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) From: Ladislav Lhotka In-Reply-To: <50891C42.101@mg-soft.com> Date: Thu, 25 Oct 2012 13:45:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7784DBE6-A638-4A75-B930-80FA29FB4A2B@nic.cz> References: <50891C42.101@mg-soft.com> To: Jernej Tuljak X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Netconf Subject: Re: [Netconf] A data modeling question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 11:45:17 -0000 Hi Jernej, did you check RFC 6022? Lada On Oct 25, 2012, at 1:02 PM, Jernej Tuljak = wrote: > Hi, > I have a question about the future of NETCONF in terms of servers = exposing their data model to clients. I know RFC6241 states the data = model is out of it's scope but will this always be the case? > I've been following the discussions on both Netmod and Netconf = mailing-lists for some time now and got the feeling that YANG and = NETCONF are going to get coupled more closely together in the future. = This makes sense since YANG represents the only standard way of exposing = a server's data model (the only way I know of, except for base protocol = capability URIs). Without it, NETCONF probably loses most of it's value. = You could avoid YANG and resort to an XSD, RNG schema or something = similar, since YANG is just a specialized XML schema anyways. But = doing that automatically means you are doing things in a non-standard = way. There's nothing written anywhere about how a server using XSD = instead of YANG is supposed to announce it's capabilities, so = implementers are bound to come up with different ways of handling this. = Even in case of YANG, not everything about announcing conformance is = clear, as some discussions have proven. And then there's also the = differentiation between state and config data (and quite possibly other = types soon). There's lots of ways you could achieve that with a general = XML schema. > The reason I'm writing this is that we recently had a feature request = for our client to support XML schema along with YANG. Since our client = is striving to be a generic one (bottom up approach according to = RFC6244) and there's no standard way or even guidelines to handle = such data models, it feels like implementing this would be a step in the = wrong direction. It might even send a wrong signal to other users which = could then easily assume that YANG is just another thing they don't need = to bother with. But is this really the case? In the coming interop tests = there is currently a small number of servers listed to join in and most = of them are YANG-based or at least use YANG modules in their hello = message (avoiding actual numbers here because I don't know if they can = be discussed). What does that mean? > I'm not trying to propose anything here. I'd just like to know what = others think about the loose way of how NETCONF currently treats data = models and how this might end up in the future. > Jernej > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jernej.tuljak@mg-soft.si Thu Oct 25 05:22:52 2012 Return-Path: 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 13B8A21F8AEC for ; Thu, 25 Oct 2012 05:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5z+V6q1vvK16 for ; Thu, 25 Oct 2012 05:22:51 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3E59C21F8AC6 for ; Thu, 25 Oct 2012 05:22:51 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id q9PCMn1C031566; Thu, 25 Oct 2012 14:22:49 +0200 Message-ID: <50892F17.9060103@mg-soft.com> Date: Thu, 25 Oct 2012 14:22:47 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ladislav Lhotka References: <50891C42.101@mg-soft.com> <7784DBE6-A638-4A75-B930-80FA29FB4A2B@nic.cz> In-Reply-To: <7784DBE6-A638-4A75-B930-80FA29FB4A2B@nic.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Netconf Subject: Re: [Netconf] A data modeling question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 12:22:52 -0000 Dne 25.10.2012 13:45, pi=9Ae Ladislav Lhotka: > Hi Jernej, > > did you check RFC 6022? Sure I did. So a standard way to expose an XSD/RNG based server data=20 model would be to implement ietf-netconf-monitoring? Jernej > > Lada > > On Oct 25, 2012, at 1:02 PM, Jernej Tuljak w= rote: > >> Hi, >> I have a question about the future of NETCONF in terms of servers expo= sing their data model to clients. I know RFC6241 states the data model is= out of it's scope but will this always be the case? >> I've been following the discussions on both Netmod and Netconf mailing= -lists for some time now and got the feeling that YANG and NETCONF are go= ing to get coupled more closely together in the future. This makes sense = since YANG represents the only standard way of exposing a server's data m= odel (the only way I know of, except for base protocol capability URIs). = Without it, NETCONF probably loses most of it's value. You could avoid YA= NG and resort to an XSD, RNG schema or something similar, since YANG is j= ust a specialized XML schema anyways. But doing that automatically = means you are doing things in a non-standard way. There's nothing written= anywhere about how a server using XSD instead of YANG is supposed to ann= ounce it's capabilities, so implementers are bound to come up with differ= ent ways of handling this. Even in case of YANG, not everything about ann= ouncing conformance is clear, as some discussions have proven. And then t= here's also the differentiation between state and config data (and quite = possibly other types soon). There's lots of ways you could achieve that w= ith a general XML schema. >> The reason I'm writing this is that we recently had a feature request = for our client to support XML schema along with YANG. Since our client is= striving to be a generic one (bottom up approach according to RFC6244) a= nd there's no standard way or even guidelines to handle such data m= odels, it feels like implementing this would be a step in the wrong direc= tion. It might even send a wrong signal to other users which could then e= asily assume that YANG is just another thing they don't need to bother wi= th. But is this really the case? In the coming interop tests there is cur= rently a small number of servers listed to join in and most of them are Y= ANG-based or at least use YANG modules in their hello message (avoiding a= ctual numbers here because I don't know if they can be discussed). What d= oes that mean? >> I'm not trying to propose anything here. I'd just like to know what ot= hers think about the loose way of how NETCONF currently treats data model= s and how this might end up in the future. >> Jernej >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From lhotka@nic.cz Thu Oct 25 05:26:56 2012 Return-Path: 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 CB20E21F8AC9 for ; Thu, 25 Oct 2012 05:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O83GSo4bZPhh for ; Thu, 25 Oct 2012 05:26:56 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A29EA21F8AB7 for ; Thu, 25 Oct 2012 05:26:55 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:1599:53f8:eb1a:518f] (unknown [IPv6:2001:1488:ac14:1400:1599:53f8:eb1a:518f]) by mail.nic.cz (Postfix) with ESMTPSA id 23C4613FD97; Thu, 25 Oct 2012 14:26:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1351168014; bh=rdQz6YOhTjWGoR30V+d/A7gSsG0B3qyy88Rhl7lVWy4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=mrJEfPnNKRQ2cvBjgOqZrQT1C7h6d//XLt5CGczO+MlJxjp0puFkvTVKF6iVRF04g NEbtBAsik62nn454GXv+Jv6XAZ7iUat7/Pv1xOI+144x0qD8a2Pdcc/bsRgb0l0Ts1 fiPyN+NCeMyxl2vK4FWi9iEDYAYp4a6oNtgOeIog= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) From: Ladislav Lhotka In-Reply-To: <50892F17.9060103@mg-soft.com> Date: Thu, 25 Oct 2012 14:26:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50891C42.101@mg-soft.com> <7784DBE6-A638-4A75-B930-80FA29FB4A2B@nic.cz> <50892F17.9060103@mg-soft.com> To: Jernej Tuljak X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Netconf Subject: Re: [Netconf] A data modeling question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 12:26:56 -0000 On Oct 25, 2012, at 2:22 PM, Jernej Tuljak = wrote: > Dne 25.10.2012 13:45, pi=9Ae Ladislav Lhotka: >> Hi Jernej, >>=20 >> did you check RFC 6022? >=20 > Sure I did. So a standard way to expose an XSD/RNG based server data = model would be to implement ietf-netconf-monitoring? I guess so. Lada >=20 > Jernej >=20 >>=20 >> Lada >>=20 >> On Oct 25, 2012, at 1:02 PM, Jernej Tuljak = wrote: >>=20 >>> Hi, >>> I have a question about the future of NETCONF in terms of servers = exposing their data model to clients. I know RFC6241 states the data = model is out of it's scope but will this always be the case? >>> I've been following the discussions on both Netmod and Netconf = mailing-lists for some time now and got the feeling that YANG and = NETCONF are going to get coupled more closely together in the future. = This makes sense since YANG represents the only standard way of exposing = a server's data model (the only way I know of, except for base protocol = capability URIs). Without it, NETCONF probably loses most of it's value. = You could avoid YANG and resort to an XSD, RNG schema or something = similar, since YANG is just a specialized XML schema anyways. But = doing that automatically means you are doing things in a non-standard = way. There's nothing written anywhere about how a server using XSD = instead of YANG is supposed to announce it's capabilities, so = implementers are bound to come up with different ways of handling this. = Even in case of YANG, not everything about announcing conformance is = clear, as some discussions have proven. And then there's also the = differentiation between state and config data (and quite possibly other = types soon). There's lots of ways you could achieve that with a general = XML schema. >>> The reason I'm writing this is that we recently had a feature = request for our client to support XML schema along with YANG. Since our = client is striving to be a generic one (bottom up approach according to = RFC6244) and there's no standard way or even guidelines to handle = such data models, it feels like implementing this would be a step in the = wrong direction. It might even send a wrong signal to other users which = could then easily assume that YANG is just another thing they don't need = to bother with. But is this really the case? In the coming interop tests = there is currently a small number of servers listed to join in and most = of them are YANG-based or at least use YANG modules in their hello = message (avoiding actual numbers here because I don't know if they can = be discussed). What does that mean? >>> I'm not trying to propose anything here. I'd just like to know what = others think about the loose way of how NETCONF currently treats data = models and how this might end up in the future. >>> Jernej >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From phil@juniper.net Thu Oct 25 06:04:18 2012 Return-Path: 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 CF63A21F86C8 for ; Thu, 25 Oct 2012 06:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id To6HivsWhe8p for ; Thu, 25 Oct 2012 06:04:18 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 41B2921F867C for ; Thu, 25 Oct 2012 06:04:17 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUIk40HPmMXwzOB2haco9gA+OrPZ92/vG@postini.com; Thu, 25 Oct 2012 06:04:18 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 25 Oct 2012 06:03:48 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q9PD3kh13455; Thu, 25 Oct 2012 06:03:47 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id q9PD3j4o039995; Thu, 25 Oct 2012 09:03:45 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201210251303.q9PD3j4o039995@idle.juniper.net> To: Jernej Tuljak In-Reply-To: <50891C42.101@mg-soft.com> Date: Thu, 25 Oct 2012 09:03:45 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: Netconf Subject: Re: [Netconf] A data modeling question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 13:04:18 -0000 Jernej Tuljak writes: >The reason I'm writing this is that we recently had a feature request >for our client to support XML schema along with YANG. Can you share something about your customer's motivations? Are they uncomfortable with YANG and more comfortable with XSD? Are they already modeling in XSD? Are they using tools that require (or already generate) XSD? Can you make XSD->YIN scripts suitable for translating their model from XSD into YANG? My overall suggestion would be to find a way to announce your XSD capabilities in such a way that it would be compatible with a near future when the customer's ever-growing love of YANG pushes them to start modeling in YANG and celebrate their freedom from XSD. Sure, it's an optimistic picture, but optimism is a mandatory requirement for life in the IETF. ;^) Thanks, Phil From jernej.tuljak@mg-soft.si Thu Oct 25 06:40:40 2012 Return-Path: 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 3204421F8973 for ; Thu, 25 Oct 2012 06:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oa4DgoIMZf+e for ; Thu, 25 Oct 2012 06:40:39 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9370A21F8971 for ; Thu, 25 Oct 2012 06:40:38 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id q9PDeS3I000630; Thu, 25 Oct 2012 15:40:28 +0200 Message-ID: <5089414A.5070709@mg-soft.com> Date: Thu, 25 Oct 2012 15:40:26 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ladislav Lhotka References: <50891C42.101@mg-soft.com> <7784DBE6-A638-4A75-B930-80FA29FB4A2B@nic.cz> <50892F17.9060103@mg-soft.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Netconf Subject: Re: [Netconf] A data modeling question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 13:40:40 -0000 Dne 25.10.2012 14:26, pi=9Ae Ladislav Lhotka: > On Oct 25, 2012, at 2:22 PM, Jernej Tuljak w= rote: > >> Dne 25.10.2012 13:45, pi=9Ae Ladislav Lhotka: >>> Hi Jernej, >>> >>> did you check RFC 6022? >> Sure I did. So a standard way to expose an XSD/RNG based server data m= odel would be to implement ietf-netconf-monitoring? > I guess so. That then solves the data model exposure problem. But there's still no=20 way for a generic client to interpret schema discovered this way. They=20 may describe NETCONF content but there's no standard way to determine=20 what kind. Data? RPC operation? Notification body? I don't see a good way of implementing support for this in a netconf=20 client. Hard-coding is of course not an option. Jernej > Lada > >> Jernej >> >>> Lada >>> >>> On Oct 25, 2012, at 1:02 PM, Jernej Tuljak = wrote: >>> >>>> Hi, >>>> I have a question about the future of NETCONF in terms of servers ex= posing their data model to clients. I know RFC6241 states the data model = is out of it's scope but will this always be the case? >>>> I've been following the discussions on both Netmod and Netconf maili= ng-lists for some time now and got the feeling that YANG and NETCONF are = going to get coupled more closely together in the future. This makes sens= e since YANG represents the only standard way of exposing a server's data= model (the only way I know of, except for base protocol capability URIs)= =2E Without it, NETCONF probably loses most of it's value. You could avoi= d YANG and resort to an XSD, RNG schema or something similar, since YANG = is just a specialized XML schema anyways. But doing that automatica= lly means you are doing things in a non-standard way. There's nothing wri= tten anywhere about how a server using XSD instead of YANG is supposed to= announce it's capabilities, so implementers are bound to come up with di= fferent ways of handling this. Even in case of YANG, not everything about= announcing conformance is clear, as some discussions have proven. And th= en there's also the differentiation between state and config data (and qu= ite possibly other types soon). There's lots of ways you could achieve th= at with a general XML schema. >>>> The reason I'm writing this is that we recently had a feature reques= t for our client to support XML schema along with YANG. Since our client = is striving to be a generic one (bottom up approach according to RFC6244)= and there's no standard way or even guidelines to handle such data= models, it feels like implementing this would be a step in the wrong dir= ection. It might even send a wrong signal to other users which could then= easily assume that YANG is just another thing they don't need to bother = with. But is this really the case? In the coming interop tests there is c= urrently a small number of servers listed to join in and most of them are= YANG-based or at least use YANG modules in their hello message (avoiding= actual numbers here because I don't know if they can be discussed). What= does that mean? >>>> I'm not trying to propose anything here. I'd just like to know what = others think about the loose way of how NETCONF currently treats data mod= els and how this might end up in the future. >>>> Jernej >>>> _______________________________________________ >>>> Netconf mailing list >>>> Netconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netconf >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> >> > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From jernej.tuljak@mg-soft.si Thu Oct 25 07:26:00 2012 Return-Path: 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 67FD621F8973 for ; Thu, 25 Oct 2012 07:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 725iaopPi2CL for ; Thu, 25 Oct 2012 07:26:00 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8AAE921F8971 for ; Thu, 25 Oct 2012 07:25:59 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id q9PEPwpb001174; Thu, 25 Oct 2012 16:25:58 +0200 Message-ID: <50894BF4.6030904@mg-soft.com> Date: Thu, 25 Oct 2012 16:25:56 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Phil Shafer References: <201210251303.q9PD3j4o039995@idle.juniper.net> In-Reply-To: <201210251303.q9PD3j4o039995@idle.juniper.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Netconf Subject: Re: [Netconf] A data modeling question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 14:26:00 -0000 Dne 25.10.2012 15:03, pi�e Phil Shafer: > Jernej Tuljak writes: >> The reason I'm writing this is that we recently had a feature request >> for our client to support XML schema along with YANG. > Can you share something about your customer's motivations? Are > they uncomfortable with YANG and more comfortable with XSD? Are > they already modeling in XSD? Are they using tools that require > (or already generate) XSD? Can you make XSD->YIN scripts suitable > for translating their model from XSD into YANG? > > My overall suggestion would be to find a way to announce your XSD > capabilities in such a way that it would be compatible with a near > future when the customer's ever-growing love of YANG pushes them > to start modeling in YANG and celebrate their freedom from XSD. > > Sure, it's an optimistic picture, but optimism is a mandatory > requirement for life in the IETF. ;^) These specific customers are probably developing a NETCONF server and want to avoid using YANG to model their content. I think they started off with XSD and want to keep it that way. We could probably manually create YANG based on their XSD, but that would not solve the problem in general. As far as I know XSD->YANG conversion is not trivial to implement so it can't cover every case. It would probably require heavy user interaction or some sort of annotations in the XSD itself. Such a tool would be quite useful though. I've actually seen people ditching NETCONF entirely, simply because they thought YANG was "unnecessary overhead". I personally don't agree with them and just wish everyone would go yang. That's also why I have doubts about supporting XSD. Jernej > > Thanks, > Phil From andy@yumaworks.com Thu Oct 25 08:05:59 2012 Return-Path: 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 E050F21F9152 for ; Thu, 25 Oct 2012 08:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.875 X-Spam-Level: X-Spam-Status: No, score=-1.875 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhgrgrZEWZ5i for ; Thu, 25 Oct 2012 08:05:59 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id C3CC921F9150 for ; Thu, 25 Oct 2012 08:05:58 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so1786204lam.31 for ; Thu, 25 Oct 2012 08:05:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=AufdUnj7U7/K1+jdFu4897ZCupv77Lx8KKV2z6zpKbQ=; b=BLFQDsFW0QBfy+RmDoN3ZpPqVYYdiRnvHy2Q21gz2mh5qGFoBi3P6B6K2Q6tvy5j7b u7vk/iPMkA2KmKB2gQhcjma5myndDVhWaNbiHvbqLeihgYLzrzhNU+g8Dg+4AsxpI5be ehSviWTBRJYasRN6LwlExaxvnRt0AzMwZibyh3UvysOujzXoyRgCTJgRZcBZ79QWzIty eLwxtRb4LxlsQX/a+XA1/IcV5v1viveaZimuTpWqE505y+/Wzxc0KL/xzFh1bw8VMAps v/hFVkgrKC7VE3UtbU5U+hU4eSbLYd2vX7Vyno+s13nHArwvDntU/LXwrtEB83ZgKh3l 7jTg== MIME-Version: 1.0 Received: by 10.112.87.167 with SMTP id az7mr8088923lbb.47.1351177557736; Thu, 25 Oct 2012 08:05:57 -0700 (PDT) Received: by 10.112.1.40 with HTTP; Thu, 25 Oct 2012 08:05:57 -0700 (PDT) In-Reply-To: <50894BF4.6030904@mg-soft.com> References: <201210251303.q9PD3j4o039995@idle.juniper.net> <50894BF4.6030904@mg-soft.com> Date: Thu, 25 Oct 2012 08:05:57 -0700 Message-ID: From: Andy Bierman To: Jernej Tuljak Content-Type: multipart/alternative; boundary=f46d0401f96d5b7d0704cce38ab9 X-Gm-Message-State: ALoCoQmXCeDqAzDnTi4OJtSjx9bUCcmqt4lr5WAvA0Ki6MYMH6sansUiRTs+MYq5ARhSOusaBuT3 Cc: Netconf Subject: Re: [Netconf] A data modeling question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 15:06:00 -0000 --f46d0401f96d5b7d0704cce38ab9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Your customer has engineers that prefer to author data models in XSD? Have they actually done this or it's all future work? The NETCONF WG failed miserably trying to get anybody to use XSD for NETCONF. That's why YANG got started in the first place. XSD cannot even distinguish which nodes are writable vs read-only, except with proprietary annotations. I don't see any evidence that YANG is a mistake and we should have stuck with XSD. Quite the opposite. IMO YANG will probably be around a lot longer than NETCONF. Andy On Thu, Oct 25, 2012 at 7:25 AM, Jernej Tuljak wr= ote: > Dne 25.10.2012 15:03, pi=C5=A1e Phil Shafer: > >> Jernej Tuljak writes: >> >>> The reason I'm writing this is that we recently had a feature request >>> for our client to support XML schema along with YANG. >>> >> Can you share something about your customer's motivations? Are >> they uncomfortable with YANG and more comfortable with XSD? Are >> they already modeling in XSD? Are they using tools that require >> (or already generate) XSD? Can you make XSD->YIN scripts suitable >> for translating their model from XSD into YANG? >> >> My overall suggestion would be to find a way to announce your XSD >> capabilities in such a way that it would be compatible with a near >> future when the customer's ever-growing love of YANG pushes them >> to start modeling in YANG and celebrate their freedom from XSD. >> >> Sure, it's an optimistic picture, but optimism is a mandatory >> requirement for life in the IETF. ;^) >> > > These specific customers are probably developing a NETCONF server and wan= t > to avoid using YANG to model their content. I think they started off with > XSD and want to keep it that way. > > We could probably manually create YANG based on their XSD, but that would > not solve the problem in general. As far as I know XSD->YANG conversion i= s > not trivial to implement so it can't cover every case. It would probably > require heavy user interaction or some sort of annotations in the XSD > itself. Such a tool would be quite useful though. > > I've actually seen people ditching NETCONF entirely, simply because they > thought YANG was "unnecessary overhead". I personally don't agree with th= em > and just wish everyone would go yang. That's also why I have doubts about > supporting XSD. > > Jernej > > >> Thanks, >> Phil >> > > ______________________________**_________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/**listinfo/netconf > --f46d0401f96d5b7d0704cce38ab9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Your customer has engineers that prefer to author

data models in XSD? = =C2=A0Have they actually done this

or it's all future work?

The NETCONF WG failed miserably trying to get anybo= dy

to use XSD for NETCONF. =C2=A0That's why YANG got started

in the first place. =C2=A0XSD cannot even distinguish which nodes

are writable vs read-only, except with proprietary annotations.

I don't see any evidence that YANG is a mistake and we shoul= d

have stuck with XSD. =C2=A0Quite the opposite. =C2=A0IMO YANG w= ill

probably be around a lot longer than NETCONF.

<= /div>

Andy

On Thu, Oct 25, 2012 at 7:25 AM, Jernej Tuljak <= jernej.tuljak@mg-soft.si> wrote:

Dne 25.10.2012 15:03, pi=C5=A1e Phil Shafer:=

Jernej Tuljak writes:

The reason I'm writing this is that we recently had a feature request for our client to support XML schema along with YANG.

Can you share something about your customer's motivations? =C2=A0Are they uncomfortable with YANG and more comfortable with XSD? =C2=A0Are
they already modeling in XSD? =C2=A0Are they using tools that require
(or already generate) XSD? =C2=A0Can you make XSD->YIN scripts suitable<= br> for translating their model from XSD into YANG?

My overall suggestion would be to find a way to announce your XSD
capabilities in such a way that it would be compatible with a near
future when the customer's ever-growing love of YANG pushes them
to start modeling in YANG and celebrate their freedom from XSD.

Sure, it's an optimistic picture, but optimism is a mandatory
requirement for life in the IETF. =C2=A0;^)

These specific customers are probably developing a NETCONF server and want = to avoid using YANG to model their content. I think they started off with X= SD and want to keep it that way.

We could probably manually create YANG based on their XSD, but that would n= ot solve the problem in general. As far as I know XSD->YANG conversion i= s not trivial to implement so it can't cover every case. It would proba= bly require heavy user interaction or some sort of annotations in the XSD i= tself. Such a tool would be quite useful though.

I've actually seen people ditching NETCONF entirely, simply because the= y thought YANG was "unnecessary overhead". I personally don't= agree with them and just wish everyone would go yang. That's also why = I have doubts about supporting XSD.

Jernej

Thanks,
=C2=A0 Phil

_______________________________________________
Netconf mailing list
Netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf

--f46d0401f96d5b7d0704cce38ab9-- From lhotka@nic.cz Thu Oct 25 08:19:30 2012 Return-Path: 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 2A7AA21F9126 for ; Thu, 25 Oct 2012 08:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3eZdo4Rz77A for ; Thu, 25 Oct 2012 08:19:29 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 3477E21F9124 for ; Thu, 25 Oct 2012 08:19:29 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:14b9:8c07:1336:653a] (unknown [IPv6:2001:1488:ac14:1400:14b9:8c07:1336:653a]) by mail.nic.cz (Postfix) with ESMTPSA id 34B5213F6A3; Thu, 25 Oct 2012 17:19:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1351178368; bh=KLNzWRpyHrmzTbmkC604niO/Xj316F8m3m9W2Ky3rfI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=NhcrQGtHo4G+dXWY6aiQXUSi0yFX6fTvqK+68Fd5ZKWfuhxr8wxFN1HhScPdU2xES 7gaxD/qvhyIj+EQPQDM28TUOPnhZaEv8pa5jJGvtZ04Wi25P5L+OBO8Nniy0BtZ0OS v+n5OJ7OP3L/mIjeDhvCRZtqyJh6AtJ2aZjy8+rk= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) From: Ladislav Lhotka In-Reply-To: Date: Thu, 25 Oct 2012 17:19:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6C645E8A-4F5A-43C2-90D3-A5FD33EFC814@nic.cz> References: <201210251303.q9PD3j4o039995@idle.juniper.net> <50894BF4.6030904@mg-soft.com> To: Andy Bierman X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Netconf Subject: Re: [Netconf] A data modeling question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 15:19:30 -0000 On Oct 25, 2012, at 5:05 PM, Andy Bierman wrote: > Your customer has engineers that prefer to author > data models in XSD? Have they actually done this > or it's all future work? >=20 > The NETCONF WG failed miserably trying to get anybody > to use XSD for NETCONF. That's why YANG got started > in the first place. XSD cannot even distinguish which nodes > are writable vs read-only, except with proprietary annotations. I think it's mainly (stupid) company rules - "We use industry = standards". In management circles, XSD has somehow been able to live = long past its clinical death. > I don't see any evidence that YANG is a mistake and we should > have stuck with XSD. Quite the opposite. IMO YANG will > probably be around a lot longer than NETCONF. +1. Lada >=20 >=20 > Andy >=20 >=20 >=20 > On Thu, Oct 25, 2012 at 7:25 AM, Jernej Tuljak = wrote: > Dne 25.10.2012 15:03, pi=9Ae Phil Shafer: > Jernej Tuljak writes: > The reason I'm writing this is that we recently had a feature request > for our client to support XML schema along with YANG. > Can you share something about your customer's motivations? Are > they uncomfortable with YANG and more comfortable with XSD? Are > they already modeling in XSD? Are they using tools that require > (or already generate) XSD? Can you make XSD->YIN scripts suitable > for translating their model from XSD into YANG? >=20 > My overall suggestion would be to find a way to announce your XSD > capabilities in such a way that it would be compatible with a near > future when the customer's ever-growing love of YANG pushes them > to start modeling in YANG and celebrate their freedom from XSD. >=20 > Sure, it's an optimistic picture, but optimism is a mandatory > requirement for life in the IETF. ;^) >=20 > These specific customers are probably developing a NETCONF server and = want to avoid using YANG to model their content. I think they started = off with XSD and want to keep it that way. >=20 > We could probably manually create YANG based on their XSD, but that = would not solve the problem in general. As far as I know XSD->YANG = conversion is not trivial to implement so it can't cover every case. It = would probably require heavy user interaction or some sort of = annotations in the XSD itself. Such a tool would be quite useful though. >=20 > I've actually seen people ditching NETCONF entirely, simply because = they thought YANG was "unnecessary overhead". I personally don't agree = with them and just wish everyone would go yang. That's also why I have = doubts about supporting XSD. >=20 > Jernej >=20 >=20 > Thanks, > Phil >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Thu Oct 25 08:27:52 2012 Return-Path: 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 5F02B21F88A9 for ; Thu, 25 Oct 2012 08:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tciE5O1l7s60 for ; Thu, 25 Oct 2012 08:27:51 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id E368021F85C0 for ; Thu, 25 Oct 2012 08:27:47 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so1813048lam.31 for ; Thu, 25 Oct 2012 08:27:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Td72T5gC79ps8+kRZrusdsnMRAFuxzNpgcS6qouJN4s=; b=f6pbfUgXxj3I9UGl61rRXxXbPkAXG9l2z0AsegSmCLEqXYjjIepKq2WVtI70sAGu0G mKIhLWPezhQy35SdEN+EsjtFHHtaznwW2GE8ZYVlb/IILuCzAPzcs8HE3s+h4Og8XBhv coNeGl+6gz5BUXb8oOI09OtRXlJ+vjmJE6QgIP05oeDaU+ONXAFzU3mQ7VrIZTrg+6O3 RJ6iYMBPh0fdWQqz9n/s+lWQsdhk2w/elFbaCs38pNBD5vLcQ8qwOBi0Dsa7IZrtkJeC 9L9RbU/g3rlJWQHkvLHmEumNUm6YG/TvhYADfx986AL7UbmskxKQKJNqh99Sw4XvGMpC iCaw== MIME-Version: 1.0 Received: by 10.112.44.132 with SMTP id e4mr8052686lbm.101.1351178866466; Thu, 25 Oct 2012 08:27:46 -0700 (PDT) Received: by 10.112.1.40 with HTTP; Thu, 25 Oct 2012 08:27:46 -0700 (PDT) In-Reply-To: <6C645E8A-4F5A-43C2-90D3-A5FD33EFC814@nic.cz> References: <201210251303.q9PD3j4o039995@idle.juniper.net> <50894BF4.6030904@mg-soft.com> <6C645E8A-4F5A-43C2-90D3-A5FD33EFC814@nic.cz> Date: Thu, 25 Oct 2012 08:27:46 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=bcaec55240b45d1e9504cce3d801 X-Gm-Message-State: ALoCoQnOoHbUfaeuqxvnWIODQEBpRQSJEu3vJadAe0ZhytF8PP3rBzjihKv34/9UUWCghB9kjTmu Cc: Netconf Subject: Re: [Netconf] A data modeling question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 15:27:52 -0000 --bcaec55240b45d1e9504cce3d801 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Oct 25, 2012 at 8:19 AM, Ladislav Lhotka wrote: > > On Oct 25, 2012, at 5:05 PM, Andy Bierman wrote: > > > Your customer has engineers that prefer to author > > data models in XSD? Have they actually done this > > or it's all future work? > > > > The NETCONF WG failed miserably trying to get anybody > > to use XSD for NETCONF. That's why YANG got started > > in the first place. XSD cannot even distinguish which nodes > > are writable vs read-only, except with proprietary annotations. > > I think it's mainly (stupid) company rules - "We use industry standards". > In management circles, XSD has somehow been able to live long past its > clinical death. > > If they already use XSD and know it, then it is not stupid. But even XSD folks have moved on to RelaxNG so it does seem that XSD is on its way out. This is just the usual business decision about when to update your technology. (One sign is when you can't find any vendors who want to support your technology anymore. ;-) Andy > I don't see any evidence that YANG is a mistake and we should > > have stuck with XSD. Quite the opposite. IMO YANG will > > probably be around a lot longer than NETCONF. > > +1. > > Lada > > > > > > > Andy > > > > > > > > On Thu, Oct 25, 2012 at 7:25 AM, Jernej Tuljak > wrote: > > Dne 25.10.2012 15:03, pi=C5=A1e Phil Shafer: > > Jernej Tuljak writes: > > The reason I'm writing this is that we recently had a feature request > > for our client to support XML schema along with YANG. > > Can you share something about your customer's motivations? Are > > they uncomfortable with YANG and more comfortable with XSD? Are > > they already modeling in XSD? Are they using tools that require > > (or already generate) XSD? Can you make XSD->YIN scripts suitable > > for translating their model from XSD into YANG? > > > > My overall suggestion would be to find a way to announce your XSD > > capabilities in such a way that it would be compatible with a near > > future when the customer's ever-growing love of YANG pushes them > > to start modeling in YANG and celebrate their freedom from XSD. > > > > Sure, it's an optimistic picture, but optimism is a mandatory > > requirement for life in the IETF. ;^) > > > > These specific customers are probably developing a NETCONF server and > want to avoid using YANG to model their content. I think they started off > with XSD and want to keep it that way. > > > > We could probably manually create YANG based on their XSD, but that > would not solve the problem in general. As far as I know XSD->YANG > conversion is not trivial to implement so it can't cover every case. It > would probably require heavy user interaction or some sort of annotations > in the XSD itself. Such a tool would be quite useful though. > > > > I've actually seen people ditching NETCONF entirely, simply because the= y > thought YANG was "unnecessary overhead". I personally don't agree with th= em > and just wish everyone would go yang. That's also why I have doubts about > supporting XSD. > > > > Jernej > > > > > > Thanks, > > Phil > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --bcaec55240b45d1e9504cce3d801 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Oct 25, 2012 at 8:19 AM, Ladisla= v Lhotka <lhotka@nic.cz> wrote:

andy@yumaworks.com> wrote:

> Your customer has engineers that prefer to author
> data models in XSD? =C2=A0Have they actually done this
> or it's all future work?
>
> The NETCONF WG failed miserably trying to get anybody
> to use XSD for NETCONF. =C2=A0That's why YANG got started
> in the first place. =C2=A0XSD cannot even distinguish which nodes
> are writable vs read-only, except with proprietary annotations.

I think it's mainly (stupid) company rules - "We use industry stan= dards". In management circles, XSD has somehow been able to live long = past its clinical death.

If they already use XSD and know it, t= hen it is not stupid.

But even XSD folks have moved on to RelaxNG= so it

does seem that XSD is on its way out.

This is just the usual business decision about when

to updat= e your technology. =C2=A0(One sign is when you

can't find any= vendors who want to support your

technology anymore. =C2=A0;-)

=C2=A0Andy

> I don't see any evidence that YANG is a mistake and we should
> have stuck with XSD. =C2=A0Quite the opposite. =C2=A0IMO YANG will
> probably be around a lot longer than NETCONF.

+1.

Lada

>
>
> Andy
>
>
>
> On Thu, Oct 25, 2012 at 7:25 AM, Jernej Tuljak <jernej.tuljak@mg-soft.si> wrote:
> Dne 25.10.2012 15:03, pi=C5=A1e Phil Shafer:
> Jernej Tuljak writes:
> The reason I'm writing this is that we recently had a feature requ= est
> for our client to support XML schema along with YANG.
> Can you share something about your customer's motivations? =C2=A0A= re
> they uncomfortable with YANG and more comfortable with XSD? =C2=A0Are<= br> > they already modeling in XSD? =C2=A0Are they using tools that require<= br> > (or already generate) XSD? =C2=A0Can you make XSD->YIN scripts suit= able
> for translating their model from XSD into YANG?
>
> My overall suggestion would be to find a way to announce your XSD
> capabilities in such a way that it would be compatible with a near
> future when the customer's ever-growing love of YANG pushes them > to start modeling in YANG and celebrate their freedom from XSD.
>
> Sure, it's an optimistic picture, but optimism is a mandatory
> requirement for life in the IETF. =C2=A0;^)
>
> These specific customers are probably developing a NETCONF server and = want to avoid using YANG to model their content. I think they started off w= ith XSD and want to keep it that way.
>
> We could probably manually create YANG based on their XSD, but that wo= uld not solve the problem in general. As far as I know XSD->YANG convers= ion is not trivial to implement so it can't cover every case. It would = probably require heavy user interaction or some sort of annotations in the = XSD itself. Such a tool would be quite useful though.
>
> I've actually seen people ditching NETCONF entirely, simply becaus= e they thought YANG was "unnecessary overhead". I personally don&= #39;t agree with them and just wish everyone would go yang. That's also= why I have doubts about supporting XSD.
>
> Jernej
>
>
> Thanks,
> =C2=A0 Phil
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

--bcaec55240b45d1e9504cce3d801-- From j.schoenwaelder@jacobs-university.de Thu Oct 25 08:43:39 2012 Return-Path: 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 2358D21F888D for ; Thu, 25 Oct 2012 08:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.228 X-Spam-Level: X-Spam-Status: No, score=-103.228 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoEN81wjMhlH for ; Thu, 25 Oct 2012 08:43:38 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD7D21F850B for ; Thu, 25 Oct 2012 08:43:38 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5BE3E20C24; Thu, 25 Oct 2012 17:43:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id hVscc0jFIiIF; Thu, 25 Oct 2012 17:43:37 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EA6C020C21; Thu, 25 Oct 2012 17:43:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6C8F8227FA65; Thu, 25 Oct 2012 17:43:36 +0200 (CEST) Date: Thu, 25 Oct 2012 17:43:36 +0200 From: Juergen Schoenwaelder To: Jernej Tuljak Message-ID: <20121025154336.GA86562@elstar.local> Mail-Followup-To: Jernej Tuljak , Netconf References: <201210251303.q9PD3j4o039995@idle.juniper.net> <50894BF4.6030904@mg-soft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50894BF4.6030904@mg-soft.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Netconf Subject: Re: [Netconf] A data modeling question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 15:43:39 -0000 On Thu, Oct 25, 2012 at 04:25:56PM +0200, Jernej Tuljak wrote: > > I've actually seen people ditching NETCONF entirely, simply because > they thought YANG was "unnecessary overhead". Any insights what people use who ditch NETCONF because they do not like learning YANG? (I assume it is the learning curve that scares people/organizations, I have a hard time to imagine that an engineer who started writing YANG modules ever wants to go back to XSD - but I am of course biased.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@yumaworks.com Thu Oct 25 09:06:26 2012 Return-Path: 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 4698121F89B2 for ; Thu, 25 Oct 2012 09:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUIbDtI5+6+4 for ; Thu, 25 Oct 2012 09:06:25 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3845121F8920 for ; Thu, 25 Oct 2012 09:06:25 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so837627bkc.31 for ; Thu, 25 Oct 2012 09:06:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=maLCS7FlsSPVs6C67iJu9QLie1jQwwsKpEB7ePSwuvM=; b=LPPu7Ehk5XyekdV6MCINSKFFvt7z06xitbH3E0tAt7L66SvSAHpVDR41hyuWexsQFn uly3mRmbWgUimjPgN1pQT67XWmdFmyp+AiTzttZIOqdnQFYVckC+48Wzi/wgz5aOPoXQ nAQ1jcCcfdzMhlS4ZAYwRpFaHtZVDaoFSuEAa+akjHcAeuOjNRSDoAy0ZYAk9zdD0DZJ co0CHgCIy5QDjGSz7Kz0K10sI2X9Jb16xk/WhcDPGQgocyO16747ZdgAXg9fMHT/zOB4 bfunH0KoOszZSCzdm3ASqgJ+e037+qSn3DjBY/N8ocTHodCa4Pau97L8P4QT4ZtKu/bW Wd4w== MIME-Version: 1.0 Received: by 10.112.87.167 with SMTP id az7mr8155657lbb.47.1351181184182; Thu, 25 Oct 2012 09:06:24 -0700 (PDT) Received: by 10.112.1.40 with HTTP; Thu, 25 Oct 2012 09:06:24 -0700 (PDT) In-Reply-To: <20121025154336.GA86562@elstar.local> References: <201210251303.q9PD3j4o039995@idle.juniper.net> <50894BF4.6030904@mg-soft.com> <20121025154336.GA86562@elstar.local> Date: Thu, 25 Oct 2012 09:06:24 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Jernej Tuljak , Netconf Content-Type: multipart/alternative; boundary=f46d0401f96d82a93904cce462cb X-Gm-Message-State: ALoCoQl3lRVnoD/AS6GLMvTFLgmhnwT5kJIbRvVKk4T0iRpRhSswsRHdwr8TrMjUZbX3Jn8uoxMa Subject: Re: [Netconf] A data modeling question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 16:06:26 -0000 --f46d0401f96d82a93904cce462cb Content-Type: text/plain; charset=UTF-8 On Thu, Oct 25, 2012 at 8:43 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Oct 25, 2012 at 04:25:56PM +0200, Jernej Tuljak wrote: > > > > I've actually seen people ditching NETCONF entirely, simply because > > they thought YANG was "unnecessary overhead". > > Any insights what people use who ditch NETCONF because they do not > like learning YANG? (I assume it is the learning curve that scares > people/organizations, I have a hard time to imagine that an engineer > who started writing YANG modules ever wants to go back to XSD - but > I am of course biased.) > > Perhaps they mean that the whole data abstraction thing is too much overhead. There are many protocols (proprietary and standard) which couple a data model to a protocol. SNMP and NETCONF do not do that. The protocol data is defined separately in modules with a formal language. The added value wrt/ tool automation that is gained by using a formal language and framework may not be obvious. /js > Andy --f46d0401f96d82a93904cce462cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Oct 25, 2012 at 8:43 AM, Juergen= Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

On Thu, Oct 25, 2012 at 04:25:56PM +0200, Je= rnej Tuljak wrote:
>
> I've actually seen people ditching NETCONF entirely, simply becaus= e
> they thought YANG was "unnecessary overhead".

Any insights what people use who ditch NETCONF because they do not
like learning YANG? (I assume it is the learning curve that scares
people/organizations, I have a hard time to imagine that an engineer
who started writing YANG modules ever wants to go back to XSD - but
I am of course biased.)

Perhaps they mean that the whole data abstraction th= ing
is too much overhead. =C2=A0There are many protocols (proprie= tary

and standard) which couple a data model to a protocol.

<= /div>
SNMP and NETCONF do not do that. =C2=A0The protocol data
is defined separately in modules with a formal language.
The ad= ded value wrt/ tool automation that is gained by

using a formal language and framework may not be obvious.

/js

Andy
=C2=A0=

--f46d0401f96d82a93904cce462cb-- From phil@juniper.net Thu Oct 25 11:26:34 2012 Return-Path: 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 F16F921F8952 for ; Thu, 25 Oct 2012 11:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+vxzEJQzyyz for ; Thu, 25 Oct 2012 11:26:29 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 9975321F86F6 for ; Thu, 25 Oct 2012 11:26:25 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUImEUd5tdFCjsf5AijXaOXfBjgK7gxoY@postini.com; Thu, 25 Oct 2012 11:26:26 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 25 Oct 2012 11:24:25 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q9PIOOh41951; Thu, 25 Oct 2012 11:24:25 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id q9PIONKj044377; Thu, 25 Oct 2012 14:24:23 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201210251824.q9PIONKj044377@idle.juniper.net> To: Jernej Tuljak In-Reply-To: <50894BF4.6030904@mg-soft.com> Date: Thu, 25 Oct 2012 14:24:23 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: Netconf Subject: Re: [Netconf] A data modeling question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 18:26:35 -0000 Jernej Tuljak writes: >We could probably manually create YANG based on their XSD, but that >would not solve the problem in general. As far as I know XSD->YANG >conversion is not trivial to implement so it can't cover every case. It >would probably require heavy user interaction or some sort of >annotations in the XSD itself. Such a tool would be quite useful though. Definitely not idea, and given the number of variation for representing data, likely custom work. >I've actually seen people ditching NETCONF entirely, simply because they >thought YANG was "unnecessary overhead". I personally don't agree with >them and just wish everyone would go yang. That's also why I have doubts >about supporting XSD. The key idea would be that XSD models a document, where YANG models a hierarchical database that can be presented as a document, but can be manipulated with NETCONF. Any key (to me at least) is that one can share infrastructure between the CLI and NETCONF to reduce the cost of maintenance. Thanks, Phil From dtorre@atomicfission.com Fri Oct 26 09:58:10 2012 Return-Path: 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 83A3D21F845D for ; Fri, 26 Oct 2012 09:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.489 X-Spam-Level: X-Spam-Status: No, score=-1.489 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWlPBNlXbqfD for ; Fri, 26 Oct 2012 09:58:09 -0700 (PDT) Received: from p3plex2out01.prod.phx3.secureserver.net (p3plex2out01.prod.phx3.secureserver.net [184.168.131.12]) by ietfa.amsl.com (Postfix) with ESMTP id B9D3321F845A for ; Fri, 26 Oct 2012 09:58:09 -0700 (PDT) Received: from P3PWEX3HT003.ex3.secureserver.net ([184.168.131.81]) by p3plex2out01.prod.phx3.secureserver.net with secureserver.net id Fsy81k0051lXQ8Q01sy8ex; Fri, 26 Oct 2012 09:58:08 -0700 Received: from P3PWEX3MB002.ex3.secureserver.net ([169.254.10.154]) by P3PWEX3HT003.ex3.secureserver.net ([184.168.131.81]) with mapi id 14.02.0318.001; Fri, 26 Oct 2012 09:58:08 -0700 From: David Torre To: Phil Shafer , Jernej Tuljak Thread-Topic: [Netconf] A data modeling question Thread-Index: AQHNsqBAkcKCnHRSlkmTojuzIT/rupfKcmyAgAAW9gCAAEKggIAA8fum Date: Fri, 26 Oct 2012 16:58:07 +0000 Message-ID: <33318FA29E6068408F8321DCFCA55C871BF8FE@P3PWEX3MB002.ex3.secureserver.net> References: <50894BF4.6030904@mg-soft.com>, <201210251824.q9PIONKj044377@idle.juniper.net> In-Reply-To: <201210251824.q9PIONKj044377@idle.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [69.36.131.254] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Netconf Subject: Re: [Netconf] A data modeling question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 16:58:10 -0000 For me, I suppose question is not whether YANG is "better" than XSD but whe= n manufacturers will support it, correct? =0A= =0A= I read the RFCs some time ago, and it seems the YANG modules need to be "co= mpiled" onto the device. It seems today mfgs like Cisco/Juniper only suppor= t XSDs, no?=0A= =0A= =0A= David Torre=0A= Owner, Atomic Fission=0A= www.atomicfission.com=0A= =0A= ________________________________________=0A= From: netconf-bounces@ietf.org [netconf-bounces@ietf.org] on behalf of Phil= Shafer [phil@juniper.net]=0A= Sent: Thursday, October 25, 2012 11:24 AM=0A= To: Jernej Tuljak=0A= Cc: Netconf=0A= Subject: Re: [Netconf] A data modeling question=0A= =0A= Jernej Tuljak writes:=0A= >We could probably manually create YANG based on their XSD, but that=0A= >would not solve the problem in general. As far as I know XSD->YANG=0A= >conversion is not trivial to implement so it can't cover every case. It=0A= >would probably require heavy user interaction or some sort of=0A= >annotations in the XSD itself. Such a tool would be quite useful though.= =0A= =0A= Definitely not idea, and given the number of variation for representing=0A= data, likely custom work.=0A= =0A= >I've actually seen people ditching NETCONF entirely, simply because they= =0A= >thought YANG was "unnecessary overhead". I personally don't agree with=0A= >them and just wish everyone would go yang. That's also why I have doubts= =0A= >about supporting XSD.=0A= =0A= The key idea would be that XSD models a document, where YANG models=0A= a hierarchical database that can be presented as a document, but can=0A= be manipulated with NETCONF. Any key (to me at least) is that one=0A= can share infrastructure between the CLI and NETCONF to reduce=0A= the cost of maintenance.=0A= =0A= Thanks,=0A= Phil=0A= _______________________________________________=0A= Netconf mailing list=0A= Netconf@ietf.org=0A= https://www.ietf.org/mailman/listinfo/netconf=0A= From phil@juniper.net Fri Oct 26 10:26:39 2012 Return-Path: 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 918E221F8634 for ; Fri, 26 Oct 2012 10:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2v-jWRno0JEU for ; Fri, 26 Oct 2012 10:26:39 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 29ED321F85AF for ; Fri, 26 Oct 2012 10:21:57 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKUIrGtboUh+7J8zT4Lza4tM4ZwIP5BeTj@postini.com; Fri, 26 Oct 2012 10:26:39 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 26 Oct 2012 10:20:26 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q9QHKDh57361; Fri, 26 Oct 2012 10:20:25 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id q9QHKBLO052294; Fri, 26 Oct 2012 13:20:12 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201210261720.q9QHKBLO052294@idle.juniper.net> To: David Torre In-Reply-To: <33318FA29E6068408F8321DCFCA55C871BF8FE@P3PWEX3MB002.ex3.secureserver.net> Date: Fri, 26 Oct 2012 13:20:11 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: Netconf Subject: Re: [Netconf] A data modeling question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 17:26:39 -0000 David Torre writes: >I read the RFCs some time ago, and it seems the YANG modules need to be "compiled" onto >the device. It seems today mfgs like Cisco/Juniper only support XSDs, no? We publish XSD files in a format that pre-dates YANG (and NETCONF), but really really need to start publishing this info in YANG. For us, it's a matter of development bandwidth, but we hope to get something out next year. Thanks, Phil From dtorre@atomicfission.com Fri Oct 26 14:40:02 2012 Return-Path: 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 39FFE21F8611 for ; Fri, 26 Oct 2012 14:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.744 X-Spam-Level: X-Spam-Status: No, score=-1.744 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAZpRFyDN5-P for ; Fri, 26 Oct 2012 14:40:01 -0700 (PDT) Received: from p3plex2out01.prod.phx3.secureserver.net (p3plex2out01.prod.phx3.secureserver.net [184.168.131.12]) by ietfa.amsl.com (Postfix) with ESMTP id 94F6321F8604 for ; Fri, 26 Oct 2012 14:40:01 -0700 (PDT) Received: from P3PWEX3HT002.ex3.secureserver.net ([184.168.131.80]) by p3plex2out01.prod.phx3.secureserver.net with secureserver.net id Fxg11k0011kDjo801xg1Ed; Fri, 26 Oct 2012 14:40:01 -0700 Received: from P3PWEX3MB002.ex3.secureserver.net ([169.254.10.154]) by P3PWEX3HT002.ex3.secureserver.net ([184.168.131.80]) with mapi id 14.02.0318.001; Fri, 26 Oct 2012 14:40:00 -0700 From: David Torre To: Phil Shafer Thread-Topic: [Netconf] A data modeling question Thread-Index: AQHNsqBAkcKCnHRSlkmTojuzIT/rupfKcmyAgAAW9gCAAEKggIAA8fumgACOaYD//9GBCA== Date: Fri, 26 Oct 2012 21:39:59 +0000 Message-ID: <33318FA29E6068408F8321DCFCA55C871BFC10@P3PWEX3MB002.ex3.secureserver.net> References: <33318FA29E6068408F8321DCFCA55C871BF8FE@P3PWEX3MB002.ex3.secureserver.net>, <201210261720.q9QHKBLO052294@idle.juniper.net> In-Reply-To: <201210261720.q9QHKBLO052294@idle.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [69.36.131.254] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Netconf Subject: Re: [Netconf] A data modeling question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 21:40:02 -0000 >but we hope to get something out next year.=0A= =0A= Looking forward to that...=0A= =0A= =0A= For Juniper, I wind up paring down the junos.xsd / config-XX.xsd anyway giv= en they're so incredibly massive. It would be awesome if I could just run J= AXB across those definitions and get Java POJOs in return. I instead have t= o pick & choose various elements to build SRX and EX-specifc data models :-= ( =0A= =0A= The goal for me is to build a network management system that doesn't need t= o be "trained" on every new device, but instead, (dynamically) learns from = the device itself-- be that an XSD, or some sort of "YANG capabilities exch= ange" etc. =0A= =0A= Regardless, eventual Juniper support for native YANG (or YIN) would be awes= ome. =0A= =0A= =0A= David Torre=0A= Owner, Atomic Fission=0A= www.atomicfission.com=0A= =0A= ________________________________________=0A= From: Phil Shafer [phil@juniper.net]=0A= Sent: Friday, October 26, 2012 10:20 AM=0A= To: David Torre=0A= Cc: Jernej Tuljak; Netconf=0A= Subject: Re: [Netconf] A data modeling question=0A= =0A= David Torre writes:=0A= >I read the RFCs some time ago, and it seems the YANG modules need to be "c= ompiled" onto=0A= >the device. It seems today mfgs like Cisco/Juniper only support XSDs, no?= =0A= =0A= We publish XSD files in a format that pre-dates YANG (and NETCONF),=0A= but really really need to start publishing this info in YANG. For=0A= us, it's a matter of development bandwidth=0A= =0A= Thanks,=0A= Phil=0A= From bclaise@cisco.com Tue Oct 30 09:04:52 2012 Return-Path: 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 0BFE621F8629; Tue, 30 Oct 2012 09:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.795 X-Spam-Level: X-Spam-Status: No, score=-8.795 tagged_above=-999 required=5 tests=[AWL=-1.743, BAYES_00=-2.599, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5e3TdDyWnvb; Tue, 30 Oct 2012 09:04:51 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF8121F8624; Tue, 30 Oct 2012 09:04:50 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9UG1JqV026360; Tue, 30 Oct 2012 17:01:20 +0100 (CET) Received: from [10.60.67.92] (ams-bclaise-89111.cisco.com [10.60.67.92]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9UG1Jji018135; Tue, 30 Oct 2012 17:01:19 +0100 (CET) Message-ID: <508FF9CF.2050902@cisco.com> Date: Tue, 30 Oct 2012 17:01:19 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: NETMOD Working Group , NETCONF Content-Type: multipart/alternative; boundary="------------040703080709090709040808" Cc: Adrian Farrel Subject: [Netconf] Please attend the IRS BoF X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 16:04:52 -0000 This is a multi-part message in MIME format. --------------040703080709090709040808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, I encourage you all to attend the IRS BoF, 1740-1940 Afternoon Session III Salon D RTG irs Interface to the Routing System BOF This BoF will!should be speaking about YANG for data modeling. Unfortunately, no agenda yet at https://datatracker.ietf.org/meeting/85/agenda.html The mailer is https://www.ietf.org/mailman/listinfo/irs-discuss Regards, Benoit. --------------040703080709090709040808 Content-Type: multipart/related; boundary="------------080106010402030208030902" --------------080106010402030208030902 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

I encourage you all to attend the IRS BoF, 1740-1940 Afternoon Session III

Salon D

RTG

irs

Interface to the Routing System BOF

This BoF will!should be speaking about YANG for data modeling.
Unfortunately, no agenda yet at https://datatracker.ietf.org/meeting/85/agenda.html
The mailer is https://www.ietf.org/mailman/listinfo/irs-discuss

Regards, Benoit.

--------------080106010402030208030902 Content-Type: image/gif; name="color-palette-4x4.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="color-palette-4x4.gif" R0lGODlhEAAQAMIDAAAA//8AAP//AP///6CgoP///////////yH5BAEKAAcALAAAAAAQABAA AAMreLrc/jA6Qmm4d1aCc9tcp1VdMFpiA6yr4LoO275CLNO1etM2i0vAoLCRAAA7 --------------080106010402030208030902-- --------------040703080709090709040808-- From phil@juniper.net Tue Oct 30 11:23:29 2012 Return-Path: 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 CE18821F860B; Tue, 30 Oct 2012 11:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQ-myOLCdekR; Tue, 30 Oct 2012 11:23:29 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id A007521F8607; Tue, 30 Oct 2012 11:23:26 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUJAbHikLJuK7NX1aHkIohcuokQKTjyFB@postini.com; Tue, 30 Oct 2012 11:23:28 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 30 Oct 2012 11:19:38 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q9UIJah85600; Tue, 30 Oct 2012 11:19:36 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id q9UIJYHD037109; Tue, 30 Oct 2012 14:19:35 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201210301819.q9UIJYHD037109@idle.juniper.net> To: Benoit Claise In-Reply-To: <508FF9CF.2050902@cisco.com> Date: Tue, 30 Oct 2012 14:19:34 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: Adrian Farrel , NETCONF , NETMOD Working Group Subject: Re: [Netconf] [netmod] Please attend the IRS BoF X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 18:23:29 -0000 Benoit Claise writes: >I encourage you all to attend the IRS BoF, 1740-1940 Afternoon Session III FYI: It's Monday (11/5). Thanks, Phil From adrian@olddog.co.uk Tue Oct 30 19:42:17 2012 Return-Path: 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 78F2421F85FF; Tue, 30 Oct 2012 19:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.589 X-Spam-Level: X-Spam-Status: No, score=-3.589 tagged_above=-999 required=5 tests=[AWL=-3.010, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NlrfGKRtqt1; Tue, 30 Oct 2012 19:42:16 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id BD15B21F85ED; Tue, 30 Oct 2012 19:42:15 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q9V2gBgK031954; Wed, 31 Oct 2012 02:42:11 GMT Received: from 950129200 (ip-64-134-100-50.public.wayport.net [64.134.100.50]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q9V2fp1X031870 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 31 Oct 2012 02:41:55 GMT From: "Adrian Farrel" To: "'Benoit Claise'" , "'NETMOD Working Group'" , "'NETCONF'" References: <508FF9CF.2050902@cisco.com> In-Reply-To: <508FF9CF.2050902@cisco.com> Date: Wed, 31 Oct 2012 01:41:51 -0000 Message-ID: <000001cdb708$ef460fe0$cdd22fa0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0001_01CDB708.EF56B1B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEDoCyoHvXiJdLSEk9D0EOlbqcWLZlmX20w Content-Language: en-gb Subject: Re: [Netconf] Please attend the IRS BoF X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 02:42:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01CDB708.EF56B1B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0002_01CDB708.EF56B1B0" ------=_NextPart_001_0002_01CDB708.EF56B1B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I shall be disappointed if this BoF talks about YANG for data modelling. The first draft of the charter posted on the IRS mailing list says: > The IRS working group works to develop a framework and > architecture that will enable specific use cases, and lead to > an understanding of the informational models and > requirements for encodings and protocols. ...and > The working group is chartered to work on the following items: > > 1. Architecture and framework for IRS including considerations of > policy and security > > 2. Tightly scoped key use cases for operational use of IRS. These > use cases will include at least: > - Interactions with the RIB > - Association of routing policies with routing state > - The ability to extract information about topology from the network. > Injection and creation of topology will not be considered as an initial > work item. > Other use cases may be adopted by the working group only after > milestones have been added to the charter page. > > 3. Abstract information models consistent with the use cases > > 4. Requirements for IRS protocols and encoding languages > > 5. An analysis of existing IETF and other protocols and encoding languages against the requirements. ...and > The working group is not currently chartered to develop protocols, > encoding languages, or data models. What is more, the BoF description posted on the wiki and forming part of the grant of the BoF says: > This BoF is to determine focus and support for work within the IETF > to specify abstract data information models, specific data models, > and protocols to operate the IRS. The BoF does not assume that new > data modeling languages or protocols will be required - that decision > is expected to form part of the analysis carried out by a working > group if one is formed. My disappointment if YANG is mentioned during the BoF will be because it will demonstrate that people have not understood the need to develop use cases and requirements *before* discussing whether existing protocols and encoding languages are suitable for the task at hand. It would be frankly as absurd to rule out Netconf as one of the protocols used in IRS as it would be to demand that it is used because we have currently no idea what function we are trying to provide. Similarly, it would be wrong to rule YANG in or out at this stage. So, I hope the BoF will talk about use cases and WG charter, and not about solution protocols and encoding languages. Nevertheless, I hope that we get lots of Ops clue in this meeting and encourage you to come along. Thanks, Adrian From: Benoit Claise [mailto:bclaise@cisco.com] Sent: 30 October 2012 16:01 To: NETMOD Working Group; NETCONF Cc: Adrian Farrel Subject: Please attend the IRS BoF Dear all, I encourage you all to attend the IRS BoF, 1740-1940 Afternoon Session III Salon D RTG irs Description: cid:part2.02000006.09090603@cisco.comInterface to the Routing System BOF This BoF will!should be speaking about YANG for data modeling. Unfortunately, no agenda yet at https://datatracker.ietf.org/meeting/85/agenda.html The mailer is https://www.ietf.org/mailman/listinfo/irs-discuss Regards, Benoit. ------=_NextPart_001_0002_01CDB708.EF56B1B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I shall be disappointed if = this BoF talks about YANG for data modelling.

The first draft of the charter = posted on the IRS mailing list says:

> The IRS working group = works to develop a framework and

> architecture that will = enable specific use cases, and lead to

> an understanding of the = informational models and

> requirements for = encodings and protocols.

...and

> The working group is = chartered to work on the following items:

> 1. Architecture and = framework for IRS including considerations of

> policy and = security

> 2. Tightly scoped key use = cases for operational use of IRS. These

> use cases will include at = least:

> - Interactions with the = RIB

> - Association of routing = policies with routing state

> - The ability to extract = information about topology from the network.

> Injection and = creation of topology will not be considered as an = initial

> work = item.

> Other use cases may be = adopted by the working group only after

> milestones have been = added to the charter page.

> 3. Abstract information = models consistent with the use cases

> 4. Requirements for IRS = protocols and encoding languages

> 5. An analysis of = existing IETF and other protocols and encoding languages against the = requirements.

...and

> The working group is not = currently chartered to develop protocols,

> encoding languages, or = data models.

What is more, the BoF = description posted on the wiki and forming part of the grant of the BoF = says:

> This BoF is to determine = focus and support for work within the IETF

> to specify abstract data = information models, specific data models,

> and protocols to operate = the IRS. The BoF does not assume that new

> data modeling languages = or protocols will be required - that decision

> is expected to form part = of the analysis carried out by a working

> group if one is = formed.

My disappointment if YANG is = mentioned during the BoF will be because it will demonstrate that people = have not understood the need to develop use cases and requirements = *before* discussing whether existing protocols and encoding languages = are suitable for the task at hand. It would be frankly as absurd to rule = out Netconf as one of the protocols used in IRS as it would be to demand = that it is used because we have currently no idea what function we are = trying to provide. Similarly, it would be wrong to rule YANG in or out = at this stage.

So, I hope the BoF will talk = about use cases and WG charter, and not about solution protocols and = encoding languages.

Nevertheless, I hope that we = get lots of Ops clue in this meeting and encourage you to come = along.

Thanks,

Adrian

From: = Benoit Claise [mailto:bclaise@cisco.com]
Sent: 30 October = 2012 16:01
To: NETMOD Working Group; NETCONF
Cc: = Adrian Farrel
Subject: Please attend the IRS = BoF

Dear all,

I = encourage you all to attend the IRS BoF, 1740-1940 Afternoon Session III =

Salon = D

RTG

irs

3D"Description: Interface to the = Routing System BOF

This BoF = will!should be speaking about YANG for data modeling.
Unfortunately, = no agenda yet at https://data= tracker.ietf.org/meeting/85/agenda.html
The mailer is https://www.ie= tf.org/mailman/listinfo/irs-discuss

Regards, Benoit.

------=_NextPart_001_0002_01CDB708.EF56B1B0-- ------=_NextPart_000_0001_01CDB708.EF56B1B0 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhEAAQAMIDAAAA//8AAP//AP///6CgoP///////////yH5BAEKAAcALAAAAAAQABAAAAMr eLrc/jA6Qmm4d1aCc9tcp1VdMFpiA6yr4LoO275CLNO1etM2i0vAoLCRAAA7 ------=_NextPart_000_0001_01CDB708.EF56B1B0-- From david.kessens@nsn.com Tue Oct 30 20:55:45 2012 Return-Path: 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 0AAD421F8D8C; Tue, 30 Oct 2012 20:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOPSiLvF+5t1; Tue, 30 Oct 2012 20:55:44 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 08E1121F8C96; Tue, 30 Oct 2012 20:55:43 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q9V3tcW0011192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 31 Oct 2012 04:55:40 +0100 Received: from P ([10.138.51.134]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q9V3tYg1032529; Wed, 31 Oct 2012 04:55:35 +0100 Received: from P (localhost.localdomain [127.0.0.1]) by P (8.14.5/8.14.5) with ESMTP id q9V3tWlI004710; Tue, 30 Oct 2012 20:55:32 -0700 Received: (from david@localhost) by P (8.14.5/8.14.5/Submit) id q9V3tTgT004706; Tue, 30 Oct 2012 20:55:29 -0700 Date: Tue, 30 Oct 2012 20:54:29 -0700 From: David Kessens To: Adrian Farrel Message-ID: <20121031035429.GA4553@nsn.com> References: <508FF9CF.2050902@cisco.com> <000001cdb708$ef460fe0$cdd22fa0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000001cdb708$ef460fe0$cdd22fa0$@olddog.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 747 X-purgate-ID: 151667::1351655740-000048BF-776B0602/0-0/0-0 X-Mailman-Approved-At: Wed, 31 Oct 2012 01:07:12 -0700 Cc: 'NETCONF' , 'NETMOD Working Group' Subject: Re: [Netconf] [netmod] Please attend the IRS BoF X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 03:55:45 -0000 Adrian, On Wed, Oct 31, 2012 at 01:41:51AM -0000, Adrian Farrel wrote: > > So, I hope the BoF will talk about use cases and WG charter, and not about > solution protocols and encoding languages. Exactly. In that context, I hope many Yang & netconf experts can make it to the bof in order to advise the Ops area director whether to insist that particular wording should be in the charter that encourages to take a look at and use of a particular existing technology or derivative, or whether a wider search for new or existing technology is appropriate. That might very well result in somebody mentioning the word netconf/yang and I sure hope that nobody will feel discouraged in doing so after your mail! David Kessens ---