From mehmet.ersue@nsn.com Fri Mar 1 05:33:09 2013 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 F189E21F8FE6 for ; Fri, 1 Mar 2013 05:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.569 X-Spam-Level: X-Spam-Status: No, score=-106.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 O8uY3-1+g0ke for ; Fri, 1 Mar 2013 05:33:08 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 2106C21F900D for ; Fri, 1 Mar 2013 05:33:07 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r21DX1M7011600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Mar 2013 14:33:02 +0100 Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r21DX0Z6016297 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Mar 2013 14:33:00 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.216]) by DEMUHTC001.nsn-intra.net ([10.159.42.32]) with mapi id 14.02.0328.009; Fri, 1 Mar 2013 14:32:59 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: ext Teramoto Yasuhiro , "netconf@ietf.org" Thread-Topic: [Netconf] draft-teramoto-experience-network-management-01 Thread-Index: AQHOFk7fuCpeQvqGNEucrTce0SQRs5iQ1PWQ Date: Fri, 1 Mar 2013 13:32:58 +0000 Message-ID: References: <20130225212537.8997.433.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.126] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: 1894 X-purgate-ID: 151667::1362144782-00001023-799B0765/0-0/0-0 Cc: Yasuo Okabe Subject: Re: [Netconf] draft-teramoto-experience-network-management-01 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, 01 Mar 2013 13:33:09 -0000 Hi All, I read the draft and found it valuable. Does the WG want to discuss on this draft in the NETCONF session? Should we plan a slot? Cheers,=20 Mehmet=20 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behal= f Of ext > Teramoto Yasuhiro > Sent: Friday, March 01, 2013 8:32 AM > To: netconf@ietf.org > Cc: Yasuo Okabe > Subject: [Netconf] draft-teramoto-experience-network-management-01 >=20 > Dear all, >=20 > We submitted this I-D that describes the experience from creating > a local area network management system. >=20 > This document includes a discussion about my thought on the NETCONF proto= col. > We think this may give some information to you. >=20 > > Title: Experience of Designing Network Management System > > Creation date: 2013-02-26 > > Number of pages: 10 > > URL: http://www.ietf.org/internet-drafts/draft-teramoto-exp= erience- > network-management-01.txt > > Status: http://datatracker.ietf.org/doc/draft-teramoto-experie= nce-network- > management > > Htmlized: http://tools.ietf.org/html/draft-teramoto-experience-n= etwork- > management-01 > > > > Abstract: > > This document describes our experiences from designing and > > implementing a large-scale local area network management system using > > mainly NETCONF. We designed the data models for device > > configurations and implemented NETCONF client to centrally control > > multiple devices of various vendors. The document provides insight > > on strong and weak points of current NETCONF approach. The document > > also makes some recommendations about NETCONF and future network > > management protocols. > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From andy@yumaworks.com Fri Mar 1 06:16:31 2013 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 4E56621F8FE6 for ; Fri, 1 Mar 2013 06:16:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=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 7U4ymzqYmJR9 for ; Fri, 1 Mar 2013 06:16:30 -0800 (PST) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id AD10021E809F for ; Fri, 1 Mar 2013 06:15:42 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id 16so3587286iea.36 for ; Fri, 01 Mar 2013 06:15:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=bSdTVrDXTYx1fd1127wgQ3vIG6Y7Wi+aGgu8sqxCTTo=; b=OmZSdnzzYRcy0KBXJMHqbB+rJJoXsmYNGfelUmLgaPoNnEeYc0PPLO7FqxdDPaD/c+ 8WrZX9SVdqVQv5FEUPRrEiXgL0P3DHIWYa0AqXLzPIIIHfXNW9EnkxwJs1DToKcx6kSO xROh1pHlQj7kH5PLWANk4sYOmGdTVNSR8R3jySxbXM3JeRhTOaFOn/3yQgkZxLED1qea OgBHd6Mhso6NQdpFrNG6w5qH9j/myY2l7oqbjofDqD8TqWOaRjiAnUtGtZF6y0UhqIO9 y9B9W4ESLHwhZBUj8RXK+tIJ3ZbQiATbb9RjqAr7I02IgSpxsBq6UrV/SpPCBCYxupfO Cb1g== MIME-Version: 1.0 X-Received: by 10.50.17.131 with SMTP id o3mr6729430igd.112.1362147336623; Fri, 01 Mar 2013 06:15:36 -0800 (PST) Received: by 10.231.93.6 with HTTP; Fri, 1 Mar 2013 06:15:36 -0800 (PST) In-Reply-To: References: Date: Fri, 1 Mar 2013 06:15:36 -0800 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=14dae934049f21ae8f04d6dda457 X-Gm-Message-State: ALoCoQmdh4rtXe5ZOClyv7wUDOxmxDRlCwYoBvgiNxAqzBTXH1/oiUUkUpJvwZ9Kr918uhUtATBg Cc: "netconf@ietf.org" Subject: Re: [Netconf] draft-kwatsen-conditional-enablement-00 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, 01 Mar 2013 14:16:31 -0000 --14dae934049f21ae8f04d6dda457 Content-Type: text/plain; charset=UTF-8 Hi, The example does not make it clear that it is a client who is sending and that the set of variables (e.g. 'enabled') and their semantics are completely unspecified and undiscoverable by the clients. Ditto for the variables used in the RHS of the expression. It is also unclear how multiple independent client applications manage the same server. It seems they have to retrieve and parse these expressions and make sure no other client has changed the expression, added or deleted expressions, etc. I think all protocol content needs a schema definition in order to be workable as a standard. Conditional activation outside the schema, plus conditional instances defined inside the schema seems broken to me. Andy On Tue, Feb 26, 2013 at 4:38 PM, Kent Watsen wrote: > > Hi Andy, > > Thanks for your comments and biting first ;) > > I think the with YANG's when-statement is that it applies to the schema > as a whole, whereas this solution works on distinct data elements. For > instance, envision a list of interfaces, we may want some (but not all) > interfaces to enabled conditionally, and then, perhaps with different > policies. > > Thanks, > Kent > > > From: Andy Bierman > Date: Tuesday, February 26, 2013 5:43 PM > To: Kent Watsen > Cc: NetConf > Subject: Re: [Netconf] draft-kwatsen-conditional-enablement-00 > > Hi Kent, > > I'll bite first ;-) > > YANG can already do this with when-stmt and XPath. > I know when-stmt for config=true can only point to other config=true, > but I look at the "platform config" an an access control issue, and > it is just more config that is only set by a privileged system user. > > groups { > my-group-g1 { > system { > hostname xyz; > } > when { > model tx1000; > routing-engine re0; > time 2am to 4am; > } > } > } > > > > If the 'model', routine-engine', and range begin/end variables were YANG leafs > then when-stmt can be used to describe the condition. > > IMO, inventing a new expression syntax when we already have 1 is not needed. > > > Andy > > > On Tue, Feb 26, 2013 at 2:00 PM, Kent Watsen wrote: > >> NETCONF WG, >> >> The following draft has been submitted for your consideration: >> >> http://tools.ietf.org/html/draft-kwatsen-conditional-enablement-00 >> >> Thanks, >> Kent >> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> >> > --14dae934049f21ae8f04d6dda457 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi,

The example does not make it clear that it is a clie= nt who is sending
<foo enabled=3D"custom-expression"= /> and that the set of variables (e.g. 'enabled')
and= their semantics are completely unspecified and =C2=A0undiscoverable by the= clients.

Ditto for the variables used in the RHS of the expressi= on. =C2=A0It is also unclear how multiple
independent client appl= ications manage the same server. =C2=A0It seems they have to
retr= ieve and parse these expressions and make sure no other client has changed<= /div>
the expression, added or deleted expressions, etc.

I think all protocol content needs a schema definition in order to be=
workable as a standard. Conditional activation outside the schem= a,
plus conditional instances defined inside the schema seems broken to m= e.


Andy


On Tue, Feb 26, 2013 at 4:38 PM, Kent Watsen <kwatsen@= juniper.net> wrote:

Hi Andy,

Thanks for your comments and biting first =C2=A0;)

I think the with YANG's when-statement is that it applies to the s= chema as a whole, whereas this solution works on distinct data elements. = =C2=A0For instance, envision a list of interfaces, we may want some (but no= t all) =C2=A0interfaces to enabled conditionally, and then, perhaps with different policies.

Thanks,
Kent


From: Andy Bierman <andy@yumaworks.com>
Date: Tuesday, February 26, 2013 5:= 43 PM
To: Kent Watsen <kwatsen@juniper.net>
Cc: NetConf <netconf@ietf.org>
Subject: Re: [Netconf] draft-kwatse= n-conditional-enablement-00

Hi Kent,

I'll bite first ;-)

YANG can already do this with when-stmt and XPath.
I know when-stmt for config=3Dtrue can only point to other config=3Dtr= ue,
but I look at the "platform config" an an access control iss= ue, and
it is just more config that is only set by a privileged system user. 

     groups {
           my-group-g1 {
               system {
                   hostname xyz;
               }
           when {
               model tx1000;
               routing-engine re0;
               time 2am to 4am;
           }
         }
       }

               
If the 'model', routine-engine', and range beg=
in/end variables were YANG leafs
then when-stmt can be used to describe the cond=
ition.
IMO, inventing a new expression syntax when we already have 1=
 is not needed.

Andy

On Tue, Feb 26, 2013 at 2:00 PM, Kent Watsen <kwatsen@junipe= r.net> wrote:
NETCONF WG,

The following draft has been submitt= ed for your consideration:


Thanks,
Kent


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



--14dae934049f21ae8f04d6dda457-- From andy@yumaworks.com Fri Mar 1 06:51:51 2013 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 D60D621F91FF for ; Fri, 1 Mar 2013 06:51:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.486 X-Spam-Level: X-Spam-Status: No, score=-1.486 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=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 lc+7figef6Rz for ; Fri, 1 Mar 2013 06:51:45 -0800 (PST) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA9921F91EB for ; Fri, 1 Mar 2013 06:51:44 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id k14so3585723iea.41 for ; Fri, 01 Mar 2013 06:51:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=OSn4bfyVq70EYdIXC35PbaN6qAjpEv862sfgvR0SYeo=; b=JxafZ+eE7nEZwJsN9WTjv7vTtSnru/3YE8UIlD6FScqFNYdIYbXzEEyniHm5A6OrrR dYKb0YuUFLbQX1qS86sSfscGOAz0RZIiCj2MSNVrctgUnERGNNMjMS0B3Tinl5Hqni2s CepZ4d9hvqrRbuTBLlM6GLuyEo3DKstMjGQQyms6wW9l1MMxlnMqGySyc+StHwqjpKf3 g0esOSETRz5WfuAuRJzpS0/68LIUYkq1ro8d/pUnrRW9kdWBTTrOV9DcCKgSba9NFJ1l /TcHdzZ97WV8ejiUMnGInuuTHwigOoL4KjPDhjLE826+g6fg2VdhPaJvBiYeXOpiWe98 UkuQ== MIME-Version: 1.0 X-Received: by 10.50.153.198 with SMTP id vi6mr13178122igb.112.1362149503199; Fri, 01 Mar 2013 06:51:43 -0800 (PST) Received: by 10.231.93.6 with HTTP; Fri, 1 Mar 2013 06:51:43 -0800 (PST) In-Reply-To: References: Date: Fri, 1 Mar 2013 06:51:43 -0800 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=e89a8f22c68145074b04d6de2526 X-Gm-Message-State: ALoCoQlgKHVl+/kb6sIbEY5oxBomHNCCfvR8KwxfMtcHfNgQYkNb+xhx8PdjucrJ/CZ2ki2IIaCj Cc: "netconf@ietf.org" Subject: Re: [Netconf] draft-kwatsen-conditional-enablement-00 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, 01 Mar 2013 14:51:51 -0000 --e89a8f22c68145074b04d6de2526 Content-Type: text/plain; charset=UTF-8 Hi After reading the motivation section again I have another comment... 3.1 . Explicit Nodes Defined in NETMOD Drafts Two separate drafts presented during the NETMOD meeting and IETF 85 had data-models with explicit "enabled" leaves (see examples below). One of the questions asked during the sessions was if cross-cutting concerns, such as if a node were enabled, wouldn't be better supported via meta-data, to which there was general agreement. Example of an "enabled" leaf from draft-ietf-netmod-routing-cfg-06.txt : leaf enabled { type boolean; default "true"; description "Enable/disable the router instance. If this parameter is false, the parent router instance is disabled, despite any other configuration that might be present."; } The problem is not that this is done with a YANG leaf, but rather that this is ad-hoc and no 2 'enabled' leafs will be the same. Moving the mechanism to meta-data does not fix the problem if it is even more ad-hoc than YANG leafs. We have a simple solution in YANG called groupings -- just create 1 standard "enabled" leaf in a grouping (new module) and put uses-stmts in the 2 modules that are defining their own leafs. A simple boolean is good enough. These enabled flags need to be available to must/when statements and XPath select in get operations. Andy On Fri, Mar 1, 2013 at 6:15 AM, Andy Bierman wrote: > Hi, > > The example does not make it clear that it is a client who is sending > and that the set of variables (e.g. > 'enabled') > and their semantics are completely unspecified and undiscoverable by the > clients. > > Ditto for the variables used in the RHS of the expression. It is also > unclear how multiple > independent client applications manage the same server. It seems they > have to > retrieve and parse these expressions and make sure no other client has > changed > the expression, added or deleted expressions, etc. > > I think all protocol content needs a schema definition in order to be > workable as a standard. Conditional activation outside the schema, > plus conditional instances defined inside the schema seems broken to me. > > > Andy > > > On Tue, Feb 26, 2013 at 4:38 PM, Kent Watsen wrote: > >> >> Hi Andy, >> >> Thanks for your comments and biting first ;) >> >> I think the with YANG's when-statement is that it applies to the schema >> as a whole, whereas this solution works on distinct data elements. For >> instance, envision a list of interfaces, we may want some (but not all) >> interfaces to enabled conditionally, and then, perhaps with different >> policies. >> >> Thanks, >> Kent >> >> >> From: Andy Bierman >> Date: Tuesday, February 26, 2013 5:43 PM >> To: Kent Watsen >> Cc: NetConf >> Subject: Re: [Netconf] draft-kwatsen-conditional-enablement-00 >> >> Hi Kent, >> >> I'll bite first ;-) >> >> YANG can already do this with when-stmt and XPath. >> I know when-stmt for config=true can only point to other config=true, >> but I look at the "platform config" an an access control issue, and >> it is just more config that is only set by a privileged system user. >> >> groups { >> my-group-g1 { >> system { >> hostname xyz; >> } >> when { >> model tx1000; >> routing-engine re0; >> time 2am to 4am; >> } >> } >> } >> >> >> >> If the 'model', routine-engine', and range begin/end variables were YANG leafs >> then when-stmt can be used to describe the condition. >> >> IMO, inventing a new expression syntax when we already have 1 is not needed. >> >> >> Andy >> >> >> On Tue, Feb 26, 2013 at 2:00 PM, Kent Watsen wrote: >> >>> NETCONF WG, >>> >>> The following draft has been submitted for your consideration: >>> >>> http://tools.ietf.org/html/draft-kwatsen-conditional-enablement-00 >>> >>> Thanks, >>> Kent >>> >>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>> >>> >> > --e89a8f22c68145074b04d6de2526 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi

After reading the motivation section again I have ano= ther comment...



3.1.  E=
xplicit Nodes Defined in NETMOD Drafts



   Two separate drafts presented during the NETMOD meeting and IETF 85
   had data-models with explicit "enabled" leaves (see examples b=
elow).
   One of the questions asked during the sessions was if cross-cutting
   concerns, such as if a node were enabled, wouldn't be better
   supported via meta-data, to which there was general agreement.

   Example of an "enabled" leaf from
   draft-ietf-netmod-routing-cfg-06.txt:

       leaf enabled {
           type boolean;
           default "true";
           description
               "Enable/disable the router instance.

               If this parameter is false, the parent router instance is
               disabled, despite any other configuration that might be
               present.";
       }


The problem is not that this is do= ne with a YANG leaf, but rather that
this is ad-hoc and no 2 '= ;enabled' leafs will be the same. =C2=A0Moving the
mechanism = to meta-data does not fix the problem if it is even more ad-hoc
than YANG leafs.

We have a simple solution in= YANG called groupings -- just create 1 standard
"enabled&qu= ot; leaf in a grouping (new module) and put uses-stmts in the 2
modules that are defining their own leafs. =C2=A0A simple boolean is good e= nough.
These enabled flags need to be available to must/when stat= ements and
XPath select in get operations.


Andy




<= div class=3D"gmail_quote">On Fri, Mar 1, 2013 at 6:15 AM, Andy Bierman <a= ndy@yumaworks.com> wrote:
Hi,

The example does not = make it clear that it is a client who is sending
<foo enabled= =3D"custom-expression" /> and that the set of variables (e.g. = 'enabled')
and their semantics are completely unspecified and =C2=A0undiscoverabl= e by the clients.

Ditto for the variables used in the RHS of the expressi= on. =C2=A0It is also unclear how multiple
independent client appl= ications manage the same server. =C2=A0It seems they have to
retr= ieve and parse these expressions and make sure no other client has changed<= /div>
the expression, added or deleted expressions, etc.

I think all protocol content needs a schema definition in order to be=
workable as a standard. Conditional activation outside the schem= a,
plus conditional instances defined inside the schema seems broken to m= e.


Andy


On Tue, Feb 26, 2013 at 4:38 PM, Kent Watsen <kwatsen@= juniper.net> wrote:

Hi Andy,

Thanks for your comments and biting first =C2=A0;)

I think the with YANG's when-statement is that it applies to the s= chema as a whole, whereas this solution works on distinct data elements. = =C2=A0For instance, envision a list of interfaces, we may want some (but no= t all) =C2=A0interfaces to enabled conditionally, and then, perhaps with different policies.

Thanks,
Kent


From: Andy Bierman <andy@yumaworks.com>
Date: Tuesday, February 26, 2013 5:= 43 PM
To: Kent Watsen <kwatsen@juniper.net>
Cc: NetConf <netconf@ietf.org>
Subject: Re: [Netconf] draft-kwatse= n-conditional-enablement-00

Hi Kent,

I'll bite first ;-)

YANG can already do this with when-stmt and XPath.
I know when-stmt for config=3Dtrue can only point to other config=3Dtr= ue,
but I look at the "platform config" an an access control iss= ue, and
it is just more config that is only set by a privileged system user. 

     groups {
           my-group-g1 {
               system {
                   hostname xyz;
               }
           when {
               model tx1000;
               routing-engine re0;
               time 2am to 4am;
           }
         }
       }

               
If the 'model', routine-engine', and range beg=
in/end variables were YANG leafs
then when-stmt can be used to describe the cond=
ition.
IMO, inventing a new expression syntax when we already have 1=
 is not needed.

Andy

On Tue, Feb 26, 2013 at 2:00 PM, Kent Watsen <kwatsen@junipe= r.net> wrote:
NETCONF WG,

The following draft has been submitt= ed for your consideration:


Thanks,
Kent


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




--e89a8f22c68145074b04d6de2526-- From ietfc@btconnect.com Fri Mar 1 07:09:07 2013 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 7A11D21F93A6 for ; Fri, 1 Mar 2013 07:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.302 X-Spam-Level: X-Spam-Status: No, score=-5.302 tagged_above=-999 required=5 tests=[AWL=1.297, 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 ZfKn03b5eSvB for ; Fri, 1 Mar 2013 07:09:06 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id ADDF621F9397 for ; Fri, 1 Mar 2013 07:09:06 -0800 (PST) Received: from mail17-co9-R.bigfish.com (10.236.132.248) by CO9EHSOBE005.bigfish.com (10.236.130.68) with Microsoft SMTP Server id 14.1.225.23; Fri, 1 Mar 2013 15:08:56 +0000 Received: from mail17-co9 (localhost [127.0.0.1]) by mail17-co9-R.bigfish.com (Postfix) with ESMTP id 91C79380327; Fri, 1 Mar 2013 15:08:56 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.254.181; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0711HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: PS-21(zz9371I936eI542I1432I14ffIzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dh8275bhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h304l1155h) Received: from mail17-co9 (localhost.localdomain [127.0.0.1]) by mail17-co9 (MessageSwitch) id 1362150534282344_17225; Fri, 1 Mar 2013 15:08:54 +0000 (UTC) Received: from CO9EHSMHS019.bigfish.com (unknown [10.236.132.225]) by mail17-co9.bigfish.com (Postfix) with ESMTP id 37F4D10027D; Fri, 1 Mar 2013 15:08:54 +0000 (UTC) Received: from DBXPRD0711HT001.eurprd07.prod.outlook.com (157.56.254.181) by CO9EHSMHS019.bigfish.com (10.236.130.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 1 Mar 2013 15:08:52 +0000 Received: from DB3PRD0210HT005.eurprd02.prod.outlook.com (157.56.253.69) by pod51017.outlook.com (10.255.178.34) with Microsoft SMTP Server (TLS) id 14.16.263.1; Fri, 1 Mar 2013 15:08:51 +0000 Message-ID: <00da01ce168e$2ffe86e0$4001a8c0@gateway.2wire.net> From: t.petch To: "Ersue, Mehmet (NSN - DE/Munich)" , ext Teramoto Yasuhiro , References: <20130225212537.8997.433.idtracker@ietfa.amsl.com> Date: Fri, 1 Mar 2013 15:05:07 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.253.69] X-OriginatorOrg: btconnect.com Cc: Yasuo Okabe Subject: Re: [Netconf] draft-teramoto-experience-network-management-01 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, 01 Mar 2013 15:09:08 -0000 I notice that the I-D was announced to at least three different IETF WG mailing lists which makes me .. well, make your mind up first, and then I will decide if I want to engage:-( The reference to future management protocols would incline me not to discuss it on Netconf. Tom Petch ----- Original Message ----- From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Teramoto Yasuhiro" ; Cc: "Yasuo Okabe" Sent: Friday, March 01, 2013 1:32 PM > Hi All, > > I read the draft and found it valuable. > > Does the WG want to discuss on this draft in the NETCONF session? > Should we plan a slot? > > Cheers, > Mehmet > > > > -----Original Message----- > > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ext > > Teramoto Yasuhiro > > Sent: Friday, March 01, 2013 8:32 AM > > To: netconf@ietf.org > > Cc: Yasuo Okabe > > Subject: [Netconf] draft-teramoto-experience-network-management-01 > > > > Dear all, > > > > We submitted this I-D that describes the experience from creating > > a local area network management system. > > > > This document includes a discussion about my thought on the NETCONF protocol. > > We think this may give some information to you. > > > > > Title: Experience of Designing Network Management System > > > Creation date: 2013-02-26 > > > Number of pages: 10 > > > URL: http://www.ietf.org/internet-drafts/draft-teramoto-experience- > > network-management-01.txt > > > Status: http://datatracker.ietf.org/doc/draft-teramoto-experience-network- > > management > > > Htmlized: http://tools.ietf.org/html/draft-teramoto-experience-network- > > management-01 > > > > > > Abstract: > > > This document describes our experiences from designing and > > > implementing a large-scale local area network management system using > > > mainly NETCONF. We designed the data models for device > > > configurations and implemented NETCONF client to centrally control > > > multiple devices of various vendors. The document provides insight > > > on strong and weak points of current NETCONF approach. The document > > > also makes some recommendations about NETCONF and future network > > > management protocols. > > From james.huy.nguyen@gmail.com Fri Mar 1 10:39:02 2013 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 1DBCF21E809E for ; Fri, 1 Mar 2013 10:39:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 mbm-r642RPqa for ; Fri, 1 Mar 2013 10:39:01 -0800 (PST) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id BEA1B21E8047 for ; Fri, 1 Mar 2013 10:39:00 -0800 (PST) Received: by mail-la0-f48.google.com with SMTP id fq13so3270553lab.35 for ; Fri, 01 Mar 2013 10:38:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=YhkYs2EhwfwdZg5zuOZrgl3/CpPzOAJGyCUBB+K0wNo=; b=G/8VXpb9nRJ7Nx1Px7kgMU+LdD6E0RJQHUttxtbKyLmtqXPswtkQFjZiQm6Om6H30i opVvN/gUcRY6pYU6Ao5H4m6lVDVUhi/Kj9jgD2g4a46Wn8iiqHUoGURuyCMOa0jDrLo5 xp9X4HZ6x2Gabc1SMpIIMZxkOc8TqQKBJc3JQTJ5EyojhXG14VqgsgB7lhTVkE8cRCU+ IxLqdClYo9WHSDIfyJVV2G1s4ffm735eT/sRFF2gO8nakYVko9Awd0TfRl3QlvTDbFIL tqfmCy2kZ2V6PqbyFgjjxURqDML9wOhnPYJfg8XMjrYRQi62A2IryMXw1WrycV97V+6A kJow== MIME-Version: 1.0 X-Received: by 10.112.49.66 with SMTP id s2mr1145836lbn.16.1362163139691; Fri, 01 Mar 2013 10:38:59 -0800 (PST) Received: by 10.112.24.70 with HTTP; Fri, 1 Mar 2013 10:38:59 -0800 (PST) In-Reply-To: References: <20130225212537.8997.433.idtracker@ietfa.amsl.com> Date: Fri, 1 Mar 2013 13:38:59 -0500 Message-ID: From: James Nguyen To: "Ersue, Mehmet (NSN - DE/Munich)" Content-Type: multipart/alternative; boundary=f46d0401677d114f1604d6e15297 Cc: "netconf@ietf.org" , Yasuo Okabe Subject: Re: [Netconf] draft-teramoto-experience-network-management-01 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, 01 Mar 2013 18:39:02 -0000 --f46d0401677d114f1604d6e15297 Content-Type: text/plain; charset=UTF-8 +1 This draft is interesting. I'd love to hear more from the authors and the WG. James On Fri, Mar 1, 2013 at 8:32 AM, Ersue, Mehmet (NSN - DE/Munich) < mehmet.ersue@nsn.com> wrote: > Hi All, > > I read the draft and found it valuable. > > Does the WG want to discuss on this draft in the NETCONF session? > Should we plan a slot? > > Cheers, > Mehmet > > > > -----Original Message----- > > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of ext > > Teramoto Yasuhiro > > Sent: Friday, March 01, 2013 8:32 AM > > To: netconf@ietf.org > > Cc: Yasuo Okabe > > Subject: [Netconf] draft-teramoto-experience-network-management-01 > > > > Dear all, > > > > We submitted this I-D that describes the experience from creating > > a local area network management system. > > > > This document includes a discussion about my thought on the NETCONF > protocol. > > We think this may give some information to you. > > > > > Title: Experience of Designing Network Management System > > > Creation date: 2013-02-26 > > > Number of pages: 10 > > > URL: > http://www.ietf.org/internet-drafts/draft-teramoto-experience- > > network-management-01.txt > > > Status: > http://datatracker.ietf.org/doc/draft-teramoto-experience-network- > > management > > > Htmlized: > http://tools.ietf.org/html/draft-teramoto-experience-network- > > management-01 > > > > > > Abstract: > > > This document describes our experiences from designing and > > > implementing a large-scale local area network management system using > > > mainly NETCONF. We designed the data models for device > > > configurations and implemented NETCONF client to centrally control > > > multiple devices of various vendors. The document provides insight > > > on strong and weak points of current NETCONF approach. The document > > > also makes some recommendations about NETCONF and future network > > > management protocols. > > _______________________________________________ > > 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 > -- James Nguyen Email: james.huy.nguyen@gmail.com --f46d0401677d114f1604d6e15297 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1

This draft is interesting.=C2=A0 I'd love to hear more from t= he authors and the WG.=C2=A0

James

On Fri, Mar 1, 2013 at 8:32 AM, Ersue, Mehmet (NSN - DE/Munich) <mehm= et.ersue@nsn.com> wrote:
Hi All,

I read the draft and found it valuable.

Does the WG want to discuss on this draft in the NETCONF session?
Should we plan a slot?

Cheers,
Mehmet


> -----Original Message-----
> From: netconf-bounces@ietf= .org [mailto:netconf-bounce= s@ietf.org] On Behalf Of ext
> Teramoto Yasuhiro
> Sent: Friday, March 01, 2013 8:32 AM
> To: netconf@ietf.org
> Cc: Yasuo Okabe
> Subject: [Netconf] draft-teramoto-experience-network-management-01
>
> Dear all,
>
> We submitted this I-D that describes the experience from creating
> a local area network management system.
>
> This document includes a discussion about my thought on the NETCONF pr= otocol.
> We think this may give some information to you.
>
> > Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Experienc= e of Designing Network Management System
> > Creation date: =C2=A0 =C2=A0 =C2=A0 2013-02-26
> > Number of pages: 10
> > URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = http://www.ietf.org/internet-drafts/draft-teramoto-experience-
> network-management-01.txt
> > Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0h= ttp://datatracker.ietf.org/doc/draft-teramoto-experience-network-
> management
> > Htmlized: =C2=A0 =C2=A0 =C2=A0 =C2=A0http://tool= s.ietf.org/html/draft-teramoto-experience-network-
> management-01
> >
> > Abstract:
> > =C2=A0 This document describes our experiences from designing and=
> > =C2=A0 implementing a large-scale local area network management s= ystem using
> > =C2=A0 mainly NETCONF. =C2=A0We designed the data models for devi= ce
> > =C2=A0 configurations and implemented NETCONF client to centrally= control
> > =C2=A0 multiple devices of various vendors. =C2=A0The document pr= ovides insight
> > =C2=A0 on strong and weak points of current NETCONF approach. =C2= =A0The document
> > =C2=A0 also makes some recommendations about NETCONF and future n= etwork
> > =C2=A0 management protocols.
> _______________________________________________
> 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



--
James Nguye= n
Email: james.huy.nguyen@= gmail.com --f46d0401677d114f1604d6e15297-- From teramoto@net.ist.i.kyoto-u.ac.jp Sat Mar 2 05:17:44 2013 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 1B0CF21F9077 for ; Sat, 2 Mar 2013 05:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 3xqt7KAKcFr2 for ; Sat, 2 Mar 2013 05:17:43 -0800 (PST) Received: from smtp-auth.kuins.kyoto-u.ac.jp (smtp-auth.kuins.kyoto-u.ac.jp [133.3.248.237]) by ietfa.amsl.com (Postfix) with ESMTP id 44BB021F9076 for ; Sat, 2 Mar 2013 05:17:42 -0800 (PST) Received: from smtp-auth.kuins.kyoto-u.ac.jp (smtp-auth.kuins.kyoto-u.ac.jp [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A66B6100AA; Sat, 2 Mar 2013 22:17:40 +0900 (JST) Received: from [10.4.206.41] (s2013221.xgsspn.imtp.tachikawa.spmode.ne.jp [49.96.13.221]) by smtp-auth.kuins.kyoto-u.ac.jp (Postfix) with ESMTP id ACC22100A9; Sat, 2 Mar 2013 22:17:34 +0900 (JST) Date: Sat, 02 Mar 2013 22:17:29 +0900 Message-ID: <269aqieclksbjnxserxfow2y.1362229235733@email.android.com> From: Yasuhiro Teramoto To: netconf@ietf.org, "Ersue, Mehmet (NSN - DE/Munich)" , netconf-chairs@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: Yasuo Okabe Subject: Re: [Netconf] draft-teramoto-experience-network-management-01 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: Sat, 02 Mar 2013 13:17:44 -0000 SGkgQWxsLAoKVGhhbmtzIGZvciBjb21tZW50cyEKCkknbSBnb2luZyB0byBhdHRlbmQgdGhpcyBJ RVRGIG1lZXRpbmcuCkkgY2FuIHRhbGsgYWJvdXQgdGhpcyBJLUQgaWYgSSBoYXZlIGEgc2xvdC4K ClRoYW5rcy4KCgoiRXJzdWUsIE1laG1ldCAoTlNOIC0gREUvTXVuaWNoKSIgPG1laG1ldC5lcnN1 ZUBuc24uY29tPjogCgo+SGkgQWxsLAo+Cj5JIHJlYWQgdGhlIGRyYWZ0IGFuZCBmb3VuZCBpdCB2 YWx1YWJsZS4KPgo+RG9lcyB0aGUgV0cgd2FudCB0byBkaXNjdXNzIG9uIHRoaXMgZHJhZnQgaW4g dGhlIE5FVENPTkYgc2Vzc2lvbj8KPlNob3VsZCB3ZSBwbGFuIGEgc2xvdD8KPgo+Q2hlZXJzLCAK Pk1laG1ldCAKPgo+Cj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4+IEZyb206IG5ldGNv bmYtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIGV4dAo+PiBUZXJhbW90byBZYXN1aGlybwo+PiBTZW50OiBGcmlkYXksIE1hcmNo IDAxLCAyMDEzIDg6MzIgQU0KPj4gVG86IG5ldGNvbmZAaWV0Zi5vcmcKPj4gQ2M6IFlhc3VvIE9r YWJlCj4+IFN1YmplY3Q6IFtOZXRjb25mXSBkcmFmdC10ZXJhbW90by1leHBlcmllbmNlLW5ldHdv cmstbWFuYWdlbWVudC0wMQo+PiAKPj4gRGVhciBhbGwsCj4+IAo+PiBXZSBzdWJtaXR0ZWQgdGhp cyBJLUQgdGhhdCBkZXNjcmliZXMgdGhlIGV4cGVyaWVuY2UgZnJvbSBjcmVhdGluZwo+PiBhIGxv Y2FsIGFyZWEgbmV0d29yayBtYW5hZ2VtZW50IHN5c3RlbS4KPj4gCj4+IFRoaXMgZG9jdW1lbnQg aW5jbHVkZXMgYSBkaXNjdXNzaW9uIGFib3V0IG15IHRob3VnaHQgb24gdGhlIE5FVENPTkYgcHJv dG9jb2wuCj4+IFdlIHRoaW5rIHRoaXMgbWF5IGdpdmUgc29tZSBpbmZvcm1hdGlvbiB0byB5b3Uu Cj4+IAo+PiA+IFRpdGxlOgkJIEV4cGVyaWVuY2Ugb2YgRGVzaWduaW5nIE5ldHdvcmsgTWFuYWdl bWVudCBTeXN0ZW0KPj4gPiBDcmVhdGlvbiBkYXRlOgkgMjAxMy0wMi0yNgo+PiA+IE51bWJlciBv ZiBwYWdlczogMTAKPj4gPiBVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LXRlcmFtb3RvLWV4cGVyaWVuY2UtCj4+IG5ldHdvcmstbWFuYWdl bWVudC0wMS50eHQKPj4gPiBTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtdGVyYW1vdG8tZXhwZXJpZW5jZS1uZXR3b3JrLQo+PiBtYW5hZ2VtZW50 Cj4+ID4gSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10 ZXJhbW90by1leHBlcmllbmNlLW5ldHdvcmstCj4+IG1hbmFnZW1lbnQtMDEKPj4gPgo+PiA+IEFi c3RyYWN0Ogo+PiA+ICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgb3VyIGV4cGVyaWVuY2VzIGZy b20gZGVzaWduaW5nIGFuZAo+PiA+ICAgaW1wbGVtZW50aW5nIGEgbGFyZ2Utc2NhbGUgbG9jYWwg YXJlYSBuZXR3b3JrIG1hbmFnZW1lbnQgc3lzdGVtIHVzaW5nCj4+ID4gICBtYWlubHkgTkVUQ09O Ri4gIFdlIGRlc2lnbmVkIHRoZSBkYXRhIG1vZGVscyBmb3IgZGV2aWNlCj4+ID4gICBjb25maWd1 cmF0aW9ucyBhbmQgaW1wbGVtZW50ZWQgTkVUQ09ORiBjbGllbnQgdG8gY2VudHJhbGx5IGNvbnRy b2wKPj4gPiAgIG11bHRpcGxlIGRldmljZXMgb2YgdmFyaW91cyB2ZW5kb3JzLiAgVGhlIGRvY3Vt ZW50IHByb3ZpZGVzIGluc2lnaHQKPj4gPiAgIG9uIHN0cm9uZyBhbmQgd2VhayBwb2ludHMgb2Yg Y3VycmVudCBORVRDT05GIGFwcHJvYWNoLiAgVGhlIGRvY3VtZW50Cj4+ID4gICBhbHNvIG1ha2Vz IHNvbWUgcmVjb21tZW5kYXRpb25zIGFib3V0IE5FVENPTkYgYW5kIGZ1dHVyZSBuZXR3b3JrCj4+ ID4gICBtYW5hZ2VtZW50IHByb3RvY29scy4KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KPj4gTmV0Y29uZiBtYWlsaW5nIGxpc3QKPj4gTmV0Y29uZkBp ZXRmLm9yZwo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYK Pgo= From mehmet.ersue@nsn.com Sat Mar 2 07:59:26 2013 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 E651D21F84C8 for ; Sat, 2 Mar 2013 07:59:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.57 X-Spam-Level: X-Spam-Status: No, score=-106.57 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 p7dpRmQkfpWY for ; Sat, 2 Mar 2013 07:59:26 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id E3FF321F84C6 for ; Sat, 2 Mar 2013 07:59:19 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r22FxGlG013170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 2 Mar 2013 16:59:16 +0100 Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r22FxFe9011939 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 2 Mar 2013 16:59:15 +0100 Received: from DEMUHTC009.nsn-intra.net (10.159.42.40) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.2.328.9; Sat, 2 Mar 2013 16:59:14 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.216]) by DEMUHTC009.nsn-intra.net ([10.159.42.40]) with mapi id 14.02.0328.009; Sat, 2 Mar 2013 16:59:14 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: Updated Agenda for IETF #86 Thread-Index: AQHOF17iuPYYTHwqwUCpKSqpnaY1bQ== Date: Sat, 2 Mar 2013 15:59:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.118] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F80536B9DEMUMBX005nsnintr_" MIME-Version: 1.0 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: 4630 X-purgate-ID: 151667::1362239956-00001023-274D5F6F/0-0/0-0 Subject: [Netconf] Updated Agenda for IETF #86 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: Sat, 02 Mar 2013 15:59:27 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F80536B9DEMUMBX005nsnintr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, please find below the updated agenda. http://www.ietf.org/proceedings/86/agenda/agenda-86-netconf Cheers, Mehmet --_000_E4DE949E6CE3E34993A2FF8AE79131F80536B9DEMUMBX005nsnintr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft Agenda for IETF #74 NETCONF Session

Hi All,

 

please find below the update= d agenda.

 

http://www.ietf.org/proceedings= /86/agenda/agenda-86-netconf

 

Cheers,
Mehmet

 

--_000_E4DE949E6CE3E34993A2FF8AE79131F80536B9DEMUMBX005nsnintr_-- From lhotka@nic.cz Mon Mar 4 00:37:50 2013 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 5886221F892D for ; Mon, 4 Mar 2013 00:37:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.095 X-Spam-Level: X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQqJfAJLJbcK for ; Mon, 4 Mar 2013 00:37:49 -0800 (PST) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id F362A21F8934 for ; Mon, 4 Mar 2013 00:37:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 5FAAF540766; Mon, 4 Mar 2013 09:37:36 +0100 (CET) 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 JJOy3GICE7NY; Mon, 4 Mar 2013 09:37:29 +0100 (CET) Received: from localhost (unknown [172.29.2.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 5E6705401E0; Mon, 4 Mar 2013 09:37:21 +0100 (CET) From: Ladislav Lhotka To: "Ersue\, Mehmet \(NSN - DE\/Munich\)" , ext Teramoto Yasuhiro , "netconf\@ietf.org" In-Reply-To: References: <20130225212537.8997.433.idtracker@ietfa.amsl.com> User-Agent: Notmuch/0.15.1+15~gd037040 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Date: Mon, 04 Mar 2013 09:37:18 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Yasuo Okabe Subject: Re: [Netconf] draft-teramoto-experience-network-management-01 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, 04 Mar 2013 08:37:50 -0000 "Ersue, Mehmet (NSN - DE/Munich)" writes: > Hi All, > > I read the draft and found it valuable. > > Does the WG want to discuss on this draft in the NETCONF session? > Should we plan a slot? +1, because the I-D raises a number of issues regarding NETCONF. The draft also has a section about YANG and data modelling but, honestly, I don't understand the objections therein. Yasuhiro et al., could you please explain them in more detail, preferably in the NETMOD mailing list? Thanks, Lada > > Cheers, > Mehmet > > >> -----Original Message----- >> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ext >> Teramoto Yasuhiro >> Sent: Friday, March 01, 2013 8:32 AM >> To: netconf@ietf.org >> Cc: Yasuo Okabe >> Subject: [Netconf] draft-teramoto-experience-network-management-01 >> >> Dear all, >> >> We submitted this I-D that describes the experience from creating >> a local area network management system. >> >> This document includes a discussion about my thought on the NETCONF protocol. >> We think this may give some information to you. >> >> > Title: Experience of Designing Network Management System >> > Creation date: 2013-02-26 >> > Number of pages: 10 >> > URL: http://www.ietf.org/internet-drafts/draft-teramoto-experience- >> network-management-01.txt >> > Status: http://datatracker.ietf.org/doc/draft-teramoto-experience-network- >> management >> > Htmlized: http://tools.ietf.org/html/draft-teramoto-experience-network- >> management-01 >> > >> > Abstract: >> > This document describes our experiences from designing and >> > implementing a large-scale local area network management system using >> > mainly NETCONF. We designed the data models for device >> > configurations and implemented NETCONF client to centrally control >> > multiple devices of various vendors. The document provides insight >> > on strong and weak points of current NETCONF approach. The document >> > also makes some recommendations about NETCONF and future network >> > management protocols. >> _______________________________________________ >> 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 From lhotka@nic.cz Mon Mar 4 02:32:24 2013 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 6D44021F892B for ; Mon, 4 Mar 2013 02:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.095 X-Spam-Level: X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHlQ2W3auvkv for ; Mon, 4 Mar 2013 02:32:24 -0800 (PST) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id DE77B21F892A for ; Mon, 4 Mar 2013 02:32:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id A8D2C540766; Mon, 4 Mar 2013 11:32:21 +0100 (CET) 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 QlLN9TznQb78; Mon, 4 Mar 2013 11:32:10 +0100 (CET) Received: from localhost (unknown [172.29.2.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 2C6475401E0; Mon, 4 Mar 2013 11:32:04 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman , Kent Watsen In-Reply-To: References: User-Agent: Notmuch/0.15.1+15~gd037040 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Date: Mon, 04 Mar 2013 11:32:04 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "netconf@ietf.org" Subject: Re: [Netconf] draft-kwatsen-conditional-enablement-00 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, 04 Mar 2013 10:32:24 -0000 Andy Bierman writes: > > IMO, inventing a new expression syntax when we already have 1 is not needed. Indeed, XPath should be suitable for this purpose - unlike YANG's when statement, in fact. This could also include the time-based enablement via current-time in ietf-system, but this would require at least an XPath expression function for comparing time values. Also, the draft uses features in a way that is not directly supported by RFC 6020. We had this discussion before in another context and I don't rememeber whether there was any conclusion. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Mon Mar 4 07:03:56 2013 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 0A7CF21F8826 for ; Mon, 4 Mar 2013 07:03:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ne6lhzvmNvhS for ; Mon, 4 Mar 2013 07:03:55 -0800 (PST) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D9F3021F87DF for ; Mon, 4 Mar 2013 07:03:54 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id k10so6119264iea.5 for ; Mon, 04 Mar 2013 07:03:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=IvlsfMby/0Xu0k6vF6Hoc4e3/tlE6KLxqkLS8kTuI30=; b=kUHCh95quUeIoiIMHdoSe27CE6TMAzMJAZUXd5HFXMVzHfMRsAhSAoHysNzgdH4N2v hK8S8R2mmgxGeaJXwbggwarmV0yjBkhJtmtEpdCJHfJN+Ok7AA4V8mfu5ODG/ww/jVpq AD0sHopTBdsJlkIyA50AsuQHcNCFthSV9LX/fjY8yTy9LuZEdJd9RRWKZRGUShQ7TB4I nglIS2hB1aOREV+8A2ZlQRy7G//biWHzp7iZF2RkXrlH1zctye1ZB/WOjkVF4HswzrQc QJvIgk4bpADkjkY4tBrIBCvAT937BLE3BgUJU2FaNOUb2POslF+0b4gfEqxge+gjhVsu Xong== MIME-Version: 1.0 X-Received: by 10.50.37.239 with SMTP id b15mr2681817igk.69.1362409434331; Mon, 04 Mar 2013 07:03:54 -0800 (PST) Received: by 10.231.93.6 with HTTP; Mon, 4 Mar 2013 07:03:54 -0800 (PST) In-Reply-To: References: <20130225212537.8997.433.idtracker@ietfa.amsl.com> Date: Mon, 4 Mar 2013 07:03:54 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=f46d044795a35f9e6e04d71aaae0 X-Gm-Message-State: ALoCoQkKLo8Yo2/eKIwdv4bDsThgu6X1z9g9vkL66SrJtsnMIWmNmP4+6JbddBhH+lfRYwM+9SQm Cc: "netconf@ietf.org" , Yasuo Okabe Subject: Re: [Netconf] draft-teramoto-experience-network-management-01 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, 04 Mar 2013 15:03:56 -0000 --f46d044795a35f9e6e04d71aaae0 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 4, 2013 at 12:37 AM, Ladislav Lhotka wrote: > "Ersue, Mehmet (NSN - DE/Munich)" writes: > > > Hi All, > > > > I read the draft and found it valuable. > > > > Does the WG want to discuss on this draft in the NETCONF session? > > Should we plan a slot? > > +1, because the I-D raises a number of issues regarding NETCONF. > > +/- 0 I have read the issues section (3.1 - 3.5) and I don't see any clear issues or problems with the specification yet. In 3.1 - 3.3, you do not say what implementation problems you had connecting with SSH or completing the exchange. Normally developers creating a client implementation have access to the server logs during development. Returning XML comments for implementations in progress may be nice to have, but not generally needed. I am more interested in knowing what text in RFCs 6241 and 6242 is too unclear to produce a correct implementation. Getting rid of the SSH transport because implementing SSH from scratch does not seem actionable. Implementing NETCONF correctly is also hard. Starting from scratch is neither practical or necessary. I do not understand sec. 3.4. You observe that commit is optional. Are you suggesting :candidate capability be mandatory to implement? What problem with the protocol is described in this section? I also do not agree that notifications are too complicated. If you can support optional :interleave at all, then transitioning from replay to live notifications is trivial. In sec. 4 you suggest that YANG is a bug not a feature, and: The same approaches of YANG often causes variability of configuration model and also causes too large and complex data schema. Furthermore YANG defines only the model schema, therefore the way to construct model data is owed to the developer. We think the fundamental model data, that is frequently used in configuration such as VLANs and Interfaces, should be defined by NETCONF core specification like SNMP in order to avoid such problems. I assume this means we should be using SMIv2 instead of YANG? I disagree that SMIv2 or SNMP simplifies CM for complex devices. IMO it makes it much worse, which is why we use NEETCONF/YANG instead. The draft also has a section about YANG and data modelling but, honestly, I > don't understand the objections therein. Yasuhiro et al., could you please > explain them in more detail, preferably in the NETMOD mailing list? > > Thanks, Lada > > > > > Cheers, > > Mehmet > > > Andy > > > >> -----Original Message----- > >> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of ext > >> Teramoto Yasuhiro > >> Sent: Friday, March 01, 2013 8:32 AM > >> To: netconf@ietf.org > >> Cc: Yasuo Okabe > >> Subject: [Netconf] draft-teramoto-experience-network-management-01 > >> > >> Dear all, > >> > >> We submitted this I-D that describes the experience from creating > >> a local area network management system. > >> > >> This document includes a discussion about my thought on the NETCONF > protocol. > >> We think this may give some information to you. > >> > >> > Title: Experience of Designing Network Management System > >> > Creation date: 2013-02-26 > >> > Number of pages: 10 > >> > URL: > http://www.ietf.org/internet-drafts/draft-teramoto-experience- > >> network-management-01.txt > >> > Status: > http://datatracker.ietf.org/doc/draft-teramoto-experience-network- > >> management > >> > Htmlized: > http://tools.ietf.org/html/draft-teramoto-experience-network- > >> management-01 > >> > > >> > Abstract: > >> > This document describes our experiences from designing and > >> > implementing a large-scale local area network management system > using > >> > mainly NETCONF. We designed the data models for device > >> > configurations and implemented NETCONF client to centrally control > >> > multiple devices of various vendors. The document provides insight > >> > on strong and weak points of current NETCONF approach. The document > >> > also makes some recommendations about NETCONF and future network > >> > management protocols. > >> _______________________________________________ > >> 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 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --f46d044795a35f9e6e04d71aaae0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Mar 4, 2013 at 12:37 AM, Ladisla= v Lhotka <lhotka@nic.cz> wrote:
mehmet.ersue@nsn.com> writes:

> Hi All,
>
> I read the draft and found it valuable.
>
> Does the WG want to discuss on this draft in the NETCONF session?
> Should we plan a slot?

+1, because the I-D raises a number of issues regarding NETCONF.


+/- 0

I have = read the issues section (3.1 - 3.5) and I don't see any clear issues
or problems with the specification yet.

In 3.1 - 3.3, you do not say what implementation problems you had
connecting with SSH or completing the <hello> exchange. =C2=A0Normal= ly developers
creating a client implementation have access to the= server logs during
development. =C2=A0Returning XML comments for implementations in progr= ess
may be nice to have, but not generally needed. =C2=A0I am mor= e interested
in knowing what text in RFCs 6241 and 6242 is too un= clear to produce a correct
implementation.

Getting rid of the SSH transp= ort because implementing SSH from scratch
does not seem actionabl= e. =C2=A0Implementing NETCONF correctly is
also hard. =C2=A0Start= ing from scratch is neither practical or necessary.

I do not understand sec. 3.4. =C2=A0You observe that co= mmit is optional.
Are you suggesting :candidate capability be man= datory to implement?
What problem with the protocol is described = in this section?

I also do not agree that notifications are too complica= ted.
If you can support optional :interleave at all, then transit= ioning from
replay to live notifications is trivial.

In sec. 4 you suggest that YANG is a bug not a feature, and:= 

   The same app=
roaches of YANG often causes variability of configuration
   model and also causes too large and complex data schema.  Furthermore
   YANG defines only the model schema, therefore the way to construct
   model data is owed to the developer.  We think the fundamental model
   data, that is frequently used in configuration such as VLANs and
   Interfaces, should be defined by NETCONF core specification like SNMP
   in order to avoid such problems.


I =C2=A0assume this means we should be using SMIv=
2 instead of YANG?
I disagree that SMIv2 or SNMP simplifies= CM for complex devices.
IMO it makes it much worse, which is why= we use NEETCONF/YANG instead.




The draft also has a section about YANG and data modelling but, honestly, I= don't understand the objections therein. Yasuhiro et al., could you pl= ease explain them in more detail, preferably in the NETMOD mailing list?
Thanks, Lada

>
> Cheers,
> Mehmet
>

Andy

=C2= =A0
>
>> -----Original Message-----
>> From: netconf-bounces@= ietf.org [mailto:netconf-bo= unces@ietf.org] On Behalf Of ext
>> Teramoto Yasuhiro
>> Sent: Friday, March 01, 2013 8:32 AM
>> To: netconf@ietf.org
>> Cc: Yasuo Okabe
>> Subject: [Netconf] draft-teramoto-experience-network-management-01=
>>
>> Dear all,
>>
>> We submitted this I-D that describes the experience from creating<= br> >> a local area network management system.
>>
>> This document includes a discussion about my thought on the NETCON= F protocol.
>> We think this may give some information to you.
>>
>> > Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Experi= ence of Designing Network Management System
>> > Creation date: =C2=A0 =C2=A0 =C2=A02013-02-26
>> > Number of pages: 10
>> > URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/internet-drafts/draft-teramoto-experience-
>> network-management-01.txt
>> > Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://datatracker.ietf.org/doc/draft-teramoto-experience-network- >> management
>> > Htmlized: =C2=A0 =C2=A0 =C2=A0 =C2=A0http://= tools.ietf.org/html/draft-teramoto-experience-network-
>> management-01
>> >
>> > Abstract:
>> > =C2=A0 This document describes our experiences from designing= and
>> > =C2=A0 implementing a large-scale local area network manageme= nt system using
>> > =C2=A0 mainly NETCONF. =C2=A0We designed the data models for = device
>> > =C2=A0 configurations and implemented NETCONF client to centr= ally control
>> > =C2=A0 multiple devices of various vendors. =C2=A0The documen= t provides insight
>> > =C2=A0 on strong and weak points of current NETCONF approach.= =C2=A0The document
>> > =C2=A0 also makes some recommendations about NETCONF and futu= re network
>> > =C2=A0 management protocols.
>> _______________________________________________
>> 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
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

--f46d044795a35f9e6e04d71aaae0-- From j.schoenwaelder@jacobs-university.de Mon Mar 4 07:18:53 2013 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 7610021F87FF for ; Mon, 4 Mar 2013 07:18:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLlo9H4AmWbz for ; Mon, 4 Mar 2013 07:18:52 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id AD6F121F8700 for ; Mon, 4 Mar 2013 07:18:52 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B5CA320BFC; Mon, 4 Mar 2013 16:18:51 +0100 (CET) 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 82iviZLwuC-4; Mon, 4 Mar 2013 16:18:51 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 351C020BFA; Mon, 4 Mar 2013 16:18:50 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0A2AA24D3C67; Mon, 4 Mar 2013 16:19:02 +0100 (CET) Date: Mon, 4 Mar 2013 16:19:01 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20130304151901.GA8148@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , "netconf@ietf.org" , Yasuo Okabe References: <20130225212537.8997.433.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Yasuo Okabe , "netconf@ietf.org" Subject: Re: [Netconf] draft-teramoto-experience-network-management-01 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: Mon, 04 Mar 2013 15:18:53 -0000 On Mon, Mar 04, 2013 at 07:03:54AM -0800, Andy Bierman wrote: > > In sec. 4 you suggest that YANG is a bug not a feature, and: > > The same approaches of YANG often causes variability of configuration > model and also causes too large and complex data schema. Furthermore > YANG defines only the model schema, therefore the way to construct > model data is owed to the developer. We think the fundamental model > data, that is frequently used in configuration such as VLANs and > Interfaces, should be defined by NETCONF core specification like SNMP > in order to avoid such problems. > > I assume this means we should be using SMIv2 instead of YANG? > I disagree that SMIv2 or SNMP simplifies CM for complex devices. > IMO it makes it much worse, which is why we use NEETCONF/YANG instead. My interpretation of the paragraph was that they see a lack of standard YANG modules. Yes, back in SNMP days, everything was done in one go - you got SNMP, the SMI, and basic MIB modules. Now everything comes serialized, first NETCONF, then YANG, then data models. Serialization apparently takes a lot of time and leaves people with something incomplete. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Mon Mar 4 07:27:06 2013 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 D900A21F8C1A for ; Mon, 4 Mar 2013 07:27:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXCbPphJDxEu for ; Mon, 4 Mar 2013 07:27:06 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A553C21F8BFD for ; Mon, 4 Mar 2013 07:27:05 -0800 (PST) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id C34A2141048; Mon, 4 Mar 2013 16:27:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1362410824; bh=o9+njq+t6QbASQQSfHLXD3+KH1o/fQlkxmzFocecFzQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=O3alHy0yeTmdePttirvaih29/+W169O7BiMewkijpC3kZX2IUXwpAwirAtQRQtpL9 xeLi3j+IZD92/sWej+d26ijAMnfCW7LZJyvZprLNUpv0LG0rXnFyVOX3nLXj5YkCLR TgxDduNASiyIVGrGrjhU4WWx/tPgAo+qvH5XrZCA= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: <20130304151901.GA8148@elstar.local> Date: Mon, 4 Mar 2013 16:26:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4A4B42D1-2D8F-4329-9966-BF96BF540BEF@nic.cz> References: <20130225212537.8997.433.idtracker@ietfa.amsl.com> <20130304151901.GA8148@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Yasuo Okabe , "netconf@ietf.org" Subject: Re: [Netconf] draft-teramoto-experience-network-management-01 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, 04 Mar 2013 15:27:07 -0000 On Mar 4, 2013, at 4:19 PM, Juergen Schoenwaelder = wrote: > On Mon, Mar 04, 2013 at 07:03:54AM -0800, Andy Bierman wrote: >>=20 >> In sec. 4 you suggest that YANG is a bug not a feature, and: >>=20 >> The same approaches of YANG often causes variability of = configuration >> model and also causes too large and complex data schema. = Furthermore >> YANG defines only the model schema, therefore the way to construct >> model data is owed to the developer. We think the fundamental = model >> data, that is frequently used in configuration such as VLANs and >> Interfaces, should be defined by NETCONF core specification like = SNMP >> in order to avoid such problems. >>=20 >> I assume this means we should be using SMIv2 instead of YANG? >> I disagree that SMIv2 or SNMP simplifies CM for complex devices. >> IMO it makes it much worse, which is why we use NEETCONF/YANG = instead. >=20 > My interpretation of the paragraph was that they see a lack of > standard YANG modules. Yes, back in SNMP days, everything was done in > one go - you got SNMP, the SMI, and basic MIB modules. Now everything > comes serialized, first NETCONF, then YANG, then data models. = Serialization > apparently takes a lot of time and leaves people with something = incomplete. Well, even if we already had all the YANG data models available, they = would still essentially define model schema, so I don't get the "model = data" part. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Mon Mar 4 07:38:39 2013 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 0795521F898B for ; Mon, 4 Mar 2013 07:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.816 X-Spam-Level: X-Spam-Status: No, score=-102.816 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsFf36xx7L8b for ; Mon, 4 Mar 2013 07:38:38 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDBC21F8967 for ; Mon, 4 Mar 2013 07:38:38 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 95E0F20BE8; Mon, 4 Mar 2013 16:38:37 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id aO6uVBFo3Og6; Mon, 4 Mar 2013 16:38:37 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2658920BDB; Mon, 4 Mar 2013 16:38:36 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 05AA524D3E9C; Mon, 4 Mar 2013 16:38:47 +0100 (CET) Date: Mon, 4 Mar 2013 16:38:47 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20130304153847.GB8232@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , "netconf@ietf.org" , Yasuo Okabe References: <20130225212537.8997.433.idtracker@ietfa.amsl.com> <20130304151901.GA8148@elstar.local> <4A4B42D1-2D8F-4329-9966-BF96BF540BEF@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A4B42D1-2D8F-4329-9966-BF96BF540BEF@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Yasuo Okabe , "netconf@ietf.org" Subject: Re: [Netconf] draft-teramoto-experience-network-management-01 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: Mon, 04 Mar 2013 15:38:39 -0000 On Mon, Mar 04, 2013 at 04:26:54PM +0100, Ladislav Lhotka wrote: > > On Mar 4, 2013, at 4:19 PM, Juergen Schoenwaelder wrote: > > > On Mon, Mar 04, 2013 at 07:03:54AM -0800, Andy Bierman wrote: > >> > >> In sec. 4 you suggest that YANG is a bug not a feature, and: > >> > >> The same approaches of YANG often causes variability of configuration > >> model and also causes too large and complex data schema. Furthermore > >> YANG defines only the model schema, therefore the way to construct > >> model data is owed to the developer. We think the fundamental model > >> data, that is frequently used in configuration such as VLANs and > >> Interfaces, should be defined by NETCONF core specification like SNMP > >> in order to avoid such problems. > >> > >> I assume this means we should be using SMIv2 instead of YANG? > >> I disagree that SMIv2 or SNMP simplifies CM for complex devices. > >> IMO it makes it much worse, which is why we use NEETCONF/YANG instead. > > > > My interpretation of the paragraph was that they see a lack of > > standard YANG modules. Yes, back in SNMP days, everything was done in > > one go - you got SNMP, the SMI, and basic MIB modules. Now everything > > comes serialized, first NETCONF, then YANG, then data models. Serialization > > apparently takes a lot of time and leaves people with something incomplete. > > Well, even if we already had all the YANG data models available, they would still essentially define model schema, so I don't get the "model data" part. > Trying to take words literally won't help. This was the only meaningful interpretation I could come up with. Perhaps there are others. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From phil@juniper.net Mon Mar 4 07:41:58 2013 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 84E8821F8A7B for ; Mon, 4 Mar 2013 07:41:58 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+X6+XcXFB8M for ; Mon, 4 Mar 2013 07:41:57 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1B421F8A1C for ; Mon, 4 Mar 2013 07:41:54 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUTTAwQI1xbQRnxdZwMAfdjY3uduyevXC@postini.com; Mon, 04 Mar 2013 07:41:57 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 4 Mar 2013 07:40:43 -0800 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 r24Fed353493; Mon, 4 Mar 2013 07:40:42 -0800 (PST) (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 r24FdMX1087527; Mon, 4 Mar 2013 10:39:43 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201303041539.r24FdMX1087527@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20130304151901.GA8148@elstar.local> Date: Mon, 4 Mar 2013 10:39:22 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: Yasuo Okabe , "netconf@ietf.org" Subject: Re: [Netconf] draft-teramoto-experience-network-management-01 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, 04 Mar 2013 15:41:58 -0000 Juergen Schoenwaelder writes: >My interpretation of the paragraph was that they see a lack of >standard YANG modules. Yes, back in SNMP days, everything was done in >one go - you got SNMP, the SMI, and basic MIB modules. Now everything >comes serialized, first NETCONF, then YANG, then data models. Serialization >apparently takes a lot of time and leaves people with something incomplete. Worse if they are expecting network-oriented models, instead of our current device-centric view. Thanks, Phil From andy@yumaworks.com Mon Mar 4 07:58:57 2013 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 A201521F85BB for ; Mon, 4 Mar 2013 07:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAKJoZNedMNy for ; Mon, 4 Mar 2013 07:58:56 -0800 (PST) Received: from mail-ia0-x22c.google.com (mail-ia0-x22c.google.com [IPv6:2607:f8b0:4001:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 8E68721F85AC for ; Mon, 4 Mar 2013 07:58:56 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id l29so4980496iag.31 for ; Mon, 04 Mar 2013 07:58:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=NaACQB4DVl8n6Cp4P/+n55tcqHFB1voPVtutHiTxGZo=; b=OZbA/+rbzo1dckQfNeevChxySAngcHCZO7Ckkq5OuexUcRPhKlxeok1oZzgQsVUIj2 t7Ci5/v3bVNyd/vg3F9VBbntzWmi2yTmx1N5gkzFjyvuVfMZpRkCaSDpiVCqEoZfJwyE IgB1B8OI0RiBu0Gq1v+kL7XGpOGsE72E3sES2oz5YlAMrSyY6OQBEXTX0IlDp14vvjWL QC8jCqapRvF2ZmDRI65koZeMFhWIWUY/MftfkQJRvvhXtEVZfB223RlTwaYCf5b4fGcC ZSSCuiOdZ4RNmdaIA/FRxk8T1k0N3hVOgkLAqyyM1afywTe6jAmI+o/R5jqgdGT7HLHC yndw== MIME-Version: 1.0 X-Received: by 10.50.12.137 with SMTP id y9mr2749195igb.57.1362412735524; Mon, 04 Mar 2013 07:58:55 -0800 (PST) Received: by 10.231.93.6 with HTTP; Mon, 4 Mar 2013 07:58:55 -0800 (PST) In-Reply-To: <20130304151901.GA8148@elstar.local> References: <20130225212537.8997.433.idtracker@ietfa.amsl.com> <20130304151901.GA8148@elstar.local> Date: Mon, 4 Mar 2013 07:58:55 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Ladislav Lhotka , "netconf@ietf.org" , Yasuo Okabe Content-Type: multipart/alternative; boundary=14dae93409512389e904d71b6fcd X-Gm-Message-State: ALoCoQnIM0h+hdzsxUEsTPSVF0a4g1YqixWK8eGK41RxGyl8yxAhQV4Bpfs66mJG8XGwJoDClzQF Subject: Re: [Netconf] draft-teramoto-experience-network-management-01 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, 04 Mar 2013 15:58:57 -0000 --14dae93409512389e904d71b6fcd Content-Type: text/plain; charset=UTF-8 On Mon, Mar 4, 2013 at 7:19 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Mar 04, 2013 at 07:03:54AM -0800, Andy Bierman wrote: > > > > In sec. 4 you suggest that YANG is a bug not a feature, and: > > > > The same approaches of YANG often causes variability of configuration > > model and also causes too large and complex data schema. Furthermore > > YANG defines only the model schema, therefore the way to construct > > model data is owed to the developer. We think the fundamental model > > data, that is frequently used in configuration such as VLANs and > > Interfaces, should be defined by NETCONF core specification like SNMP > > in order to avoid such problems. > > > > I assume this means we should be using SMIv2 instead of YANG? > > I disagree that SMIv2 or SNMP simplifies CM for complex devices. > > IMO it makes it much worse, which is why we use NEETCONF/YANG instead. > > My interpretation of the paragraph was that they see a lack of > standard YANG modules. Yes, back in SNMP days, everything was done in > one go - you got SNMP, the SMI, and basic MIB modules. Now everything > comes serialized, first NETCONF, then YANG, then data models. Serialization > apparently takes a lot of time and leaves people with something incomplete. > > It actually took many years to get all those things in SNMP. If by "all at once", you mean "after the first decade", then I agree ;-) > /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --14dae93409512389e904d71b6fcd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Mar 4, 2013 at 7:19 AM, Juergen = Schoenwaelder <j.schoenwaelder@jacobs-university.de= > wrote:
On Mon, Mar 04, 2013 at 07:03:54AM -0800, An= dy Bierman wrote:
>
> In sec. 4 you suggest that YANG is a bug not a feature, and:
>
> =C2=A0 =C2=A0The same approaches of YANG often causes variability of c= onfiguration
> =C2=A0 =C2=A0model and also causes too large and complex data schema. = =C2=A0Furthermore
> =C2=A0 =C2=A0YANG defines only the model schema, therefore the way to = construct
> =C2=A0 =C2=A0model data is owed to the developer. =C2=A0We think the f= undamental model
> =C2=A0 =C2=A0data, that is frequently used in configuration such as VL= ANs and
> =C2=A0 =C2=A0Interfaces, should be defined by NETCONF core specificati= on like SNMP
> =C2=A0 =C2=A0in order to avoid such problems.
>
> I =C2=A0assume this means we should be using SMIv2 instead of YANG? > I disagree that SMIv2 or SNMP simplifies CM for complex devices.
> IMO it makes it much worse, which is why we use NEETCONF/YANG instead.=

My interpretation of the paragraph was that they see a lack of
standard YANG modules. Yes, back in SNMP days, everything was done in
one go - you got SNMP, the SMI, and basic MIB modules. =C2=A0Now everything=
comes serialized, first NETCONF, then YANG, then data models. Serialization=
apparently takes a lot of time and leaves people with something incomplete.=


It actually took many years to get all those things = in SNMP.
If by "all at once", you mean "after the = first decade", then I agree ;-)

=C2=A0
/js

Andy
=C2=A0=

--
Juergen Schoenwaelder =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jacobs University = Bremen gGmbH
Phone: +49 421 200 3587 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Campus Ring 1, 28759 Br= emen, Germany
Fax: =C2=A0 +49 421 200 3103 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://www.jacobs-universi= ty.de/>

--14dae93409512389e904d71b6fcd-- From andy@yumaworks.com Mon Mar 4 08:23:57 2013 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 4168921F86C8 for ; Mon, 4 Mar 2013 08:23:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpAEodH2mzmg for ; Mon, 4 Mar 2013 08:23:56 -0800 (PST) Received: from mail-ia0-x22a.google.com (mail-ia0-x22a.google.com [IPv6:2607:f8b0:4001:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0EB21F86A5 for ; Mon, 4 Mar 2013 08:23:56 -0800 (PST) Received: by mail-ia0-f170.google.com with SMTP id k20so5034519iak.29 for ; Mon, 04 Mar 2013 08:23:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=2Xs8A4cjpx8Wuhn6sYx1539uHolFE2K/2+MeoowjYJ0=; b=CW5atboc5xmI2PDrBnHlfjxt9A661Ky5pusNhqy18EXGQu+pJfv5FDMuV3RUFB/1oE 4nmZOsrhRUyfQ197AJTh8HphhbxsrjAXARCZZ+4tCWi3/aGZMri7+5IzfmQYxmzZHe+R R16YrmI1C8PYqI7VR+p4TrS9SzKwpAqGdLxfd7s/sTkGcQm5o0QOMFSlsu6+iz6oHx6l iOv8zTKRvHS+cEZtmZecndzVaySPx63z5vP5QnOgnrcUnnYgejT7+l7So7p2DwGWs+vM 660bBWluklXA97WzcKsyMoIp9QnxO9EIpmOTkp7K1BZgFMfAbjW4atKBt8D0E0iDVIzu zk/Q== MIME-Version: 1.0 X-Received: by 10.50.17.131 with SMTP id o3mr2933570igd.112.1362414235993; Mon, 04 Mar 2013 08:23:55 -0800 (PST) Received: by 10.231.93.6 with HTTP; Mon, 4 Mar 2013 08:23:55 -0800 (PST) In-Reply-To: <20130304153847.GB8232@elstar.local> References: <20130225212537.8997.433.idtracker@ietfa.amsl.com> <20130304151901.GA8148@elstar.local> <4A4B42D1-2D8F-4329-9966-BF96BF540BEF@nic.cz> <20130304153847.GB8232@elstar.local> Date: Mon, 4 Mar 2013 08:23:55 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Ladislav Lhotka , Andy Bierman , "netconf@ietf.org" , Yasuo Okabe Content-Type: multipart/alternative; boundary=14dae934049f932ee504d71bc82c X-Gm-Message-State: ALoCoQmvBDMCVjSqesMYNfdGr96cNigR4Ar6ycLB3+kTwj4YpSA6mNXayhUahj39mSKGlcA23hpz Subject: Re: [Netconf] draft-teramoto-experience-network-management-01 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, 04 Mar 2013 16:23:57 -0000 --14dae934049f932ee504d71bc82c Content-Type: text/plain; charset=UTF-8 On Mon, Mar 4, 2013 at 7:38 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Mar 04, 2013 at 04:26:54PM +0100, Ladislav Lhotka wrote: > > > > On Mar 4, 2013, at 4:19 PM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > > > On Mon, Mar 04, 2013 at 07:03:54AM -0800, Andy Bierman wrote: > > >> > > >> In sec. 4 you suggest that YANG is a bug not a feature, and: > > >> > > >> The same approaches of YANG often causes variability of > configuration > > >> model and also causes too large and complex data schema. > Furthermore > > >> YANG defines only the model schema, therefore the way to construct > > >> model data is owed to the developer. We think the fundamental model > > >> data, that is frequently used in configuration such as VLANs and > > >> Interfaces, should be defined by NETCONF core specification like > SNMP > > >> in order to avoid such problems. > > >> > > >> I assume this means we should be using SMIv2 instead of YANG? > > >> I disagree that SMIv2 or SNMP simplifies CM for complex devices. > > >> IMO it makes it much worse, which is why we use NEETCONF/YANG instead. > > > > > > My interpretation of the paragraph was that they see a lack of > > > standard YANG modules. Yes, back in SNMP days, everything was done in > > > one go - you got SNMP, the SMI, and basic MIB modules. Now everything > > > comes serialized, first NETCONF, then YANG, then data models. > Serialization > > > apparently takes a lot of time and leaves people with something > incomplete. > > > > Well, even if we already had all the YANG data models available, they > would still essentially define model schema, so I don't get the "model > data" part. > > > > Trying to take words literally won't help. This was the only > meaningful interpretation I could come up with. Perhaps there are > others. ;-) > > Perhaps the issue being raised: - Why does RFC 6643 define a read-only mapping from SMIv2 to YANG? /js > Andy --14dae934049f932ee504d71bc82c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Mar 4, 2013 at 7:38 AM, Juergen = Schoenwaelder <j.schoenwaelder@jacobs-university.de= > wrote:
On Mon, Mar 04, 2013 at 04:26:54PM +0100, La= dislav Lhotka wrote:
>
> On Mar 4, 2013, at 4:19 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.d= e> wrote:
>
> > On Mon, Mar 04, 2013 at 07:03:54AM -0800, Andy Bierman wrote:
> >>
> >> In sec. 4 you suggest that YANG is a bug not a feature, and:<= br> > >>
> >> =C2=A0 The same approaches of YANG often causes variability o= f configuration
> >> =C2=A0 model and also causes too large and complex data schem= a. =C2=A0Furthermore
> >> =C2=A0 YANG defines only the model schema, therefore the way = to construct
> >> =C2=A0 model data is owed to the developer. =C2=A0We think th= e fundamental model
> >> =C2=A0 data, that is frequently used in configuration such as= VLANs and
> >> =C2=A0 Interfaces, should be defined by NETCONF core specific= ation like SNMP
> >> =C2=A0 in order to avoid such problems.
> >>
> >> I =C2=A0assume this means we should be using SMIv2 instead of= YANG?
> >> I disagree that SMIv2 or SNMP simplifies CM for complex devic= es.
> >> IMO it makes it much worse, which is why we use NEETCONF/YANG= instead.
> >
> > My interpretation of the paragraph was that they see a lack of > > standard YANG modules. Yes, back in SNMP days, everything was don= e in
> > one go - you got SNMP, the SMI, and basic MIB modules. =C2=A0Now = everything
> > comes serialized, first NETCONF, then YANG, then data models. Ser= ialization
> > apparently takes a lot of time and leaves people with something i= ncomplete.
>
> Well, even if we already had all the YANG data models available, they = would still essentially define model schema, so I don't get the "m= odel data" part.
>

Trying to take words literally won't help. This was the only
meaningful interpretation I could come up with. Perhaps there are
others. ;-)


Perhaps the issue being raised:
=C2=A0 =C2= =A0- Why does RFC 6643 define a read-only mapping from SMIv2 to YANG?
=



/js

Andy

--14dae934049f932ee504d71bc82c-- From j.schoenwaelder@jacobs-university.de Mon Mar 4 08:47:25 2013 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 A11D321F8D2A for ; Mon, 4 Mar 2013 08:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.924 X-Spam-Level: X-Spam-Status: No, score=-102.924 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ok6wCSOJG4Jg for ; Mon, 4 Mar 2013 08:47:21 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 057CE21F8D29 for ; Mon, 4 Mar 2013 08:47:21 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 411B120CFC; Mon, 4 Mar 2013 17:47:20 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id E56PwtRgGJxF; Mon, 4 Mar 2013 17:47:20 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A223A20CFB; Mon, 4 Mar 2013 17:47:19 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9ADF324D40D9; Mon, 4 Mar 2013 17:47:29 +0100 (CET) Date: Mon, 4 Mar 2013 17:47:29 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20130304164729.GA8549@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , "netconf@ietf.org" , Yasuo Okabe References: <20130225212537.8997.433.idtracker@ietfa.amsl.com> <20130304151901.GA8148@elstar.local> <4A4B42D1-2D8F-4329-9966-BF96BF540BEF@nic.cz> <20130304153847.GB8232@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Yasuo Okabe , "netconf@ietf.org" Subject: Re: [Netconf] draft-teramoto-experience-network-management-01 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: Mon, 04 Mar 2013 16:47:25 -0000 On Mon, Mar 04, 2013 at 08:23:55AM -0800, Andy Bierman wrote: > On Mon, Mar 4, 2013 at 7:38 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Mon, Mar 04, 2013 at 04:26:54PM +0100, Ladislav Lhotka wrote: > > > > > > On Mar 4, 2013, at 4:19 PM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > > On Mon, Mar 04, 2013 at 07:03:54AM -0800, Andy Bierman wrote: > > > >> > > > >> In sec. 4 you suggest that YANG is a bug not a feature, and: > > > >> > > > >> The same approaches of YANG often causes variability of > > configuration > > > >> model and also causes too large and complex data schema. > > Furthermore > > > >> YANG defines only the model schema, therefore the way to construct > > > >> model data is owed to the developer. We think the fundamental model > > > >> data, that is frequently used in configuration such as VLANs and > > > >> Interfaces, should be defined by NETCONF core specification like > > SNMP > > > >> in order to avoid such problems. > > > >> > > > >> I assume this means we should be using SMIv2 instead of YANG? > > > >> I disagree that SMIv2 or SNMP simplifies CM for complex devices. > > > >> IMO it makes it much worse, which is why we use NEETCONF/YANG instead. > > > > > > > > My interpretation of the paragraph was that they see a lack of > > > > standard YANG modules. Yes, back in SNMP days, everything was done in > > > > one go - you got SNMP, the SMI, and basic MIB modules. Now everything > > > > comes serialized, first NETCONF, then YANG, then data models. > > Serialization > > > > apparently takes a lot of time and leaves people with something > > incomplete. > > > > > > Well, even if we already had all the YANG data models available, they > > would still essentially define model schema, so I don't get the "model > > data" part. > > > > > > > Trying to take words literally won't help. This was the only > > meaningful interpretation I could come up with. Perhaps there are > > others. ;-) > > > > > Perhaps the issue being raised: > - Why does RFC 6643 define a read-only mapping from SMIv2 to YANG? Only the authors can tell us. Lets stop speculating. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From kwatsen@juniper.net Mon Mar 4 12:21:27 2013 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 49B7521F8D23 for ; Mon, 4 Mar 2013 12:21:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.867 X-Spam-Level: X-Spam-Status: No, score=-2.867 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hu9sMsmEU1G9 for ; Mon, 4 Mar 2013 12:21:26 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCBB21F8BEB for ; Mon, 4 Mar 2013 12:21:26 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUTUCRmbxEPytJbZ3iu+KdjBV0WmIyq/o@postini.com; Mon, 04 Mar 2013 12:21:26 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 4 Mar 2013 12:16:23 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Mon, 4 Mar 2013 12:16:22 -0800 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.30) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 4 Mar 2013 12:25:50 -0800 Received: from mail246-va3-R.bigfish.com (10.7.14.245) by VA3EHSOBE006.bigfish.com (10.7.40.26) with Microsoft SMTP Server id 14.1.225.23; Mon, 4 Mar 2013 20:16:20 +0000 Received: from mail246-va3 (localhost [127.0.0.1]) by mail246-va3-R.bigfish.com (Postfix) with ESMTP id D94AD680310 for ; Mon, 4 Mar 2013 20:16:20 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -5 X-BigFish: PS-5(zzbb2dI98dI9371I1432I4015Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz177df4h17326ah8275bhz2dh2a8h668h839h946he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1155h) Received: from mail246-va3 (localhost.localdomain [127.0.0.1]) by mail246-va3 (MessageSwitch) id 1362428166769477_13408; Mon, 4 Mar 2013 20:16:06 +0000 (UTC) Received: from VA3EHSMHS013.bigfish.com (unknown [10.7.14.235]) by mail246-va3.bigfish.com (Postfix) with ESMTP id 8F7035800E4; Mon, 4 Mar 2013 20:16:06 +0000 (UTC) Received: from CH1PRD0511HT004.namprd05.prod.outlook.com (157.56.245.197) by VA3EHSMHS013.bigfish.com (10.7.99.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 4 Mar 2013 20:16:04 +0000 Received: from CH1PRD0511MB407.namprd05.prod.outlook.com ([169.254.5.117]) by CH1PRD0511HT004.namprd05.prod.outlook.com ([10.255.159.39]) with mapi id 14.16.0275.006; Mon, 4 Mar 2013 20:16:04 +0000 From: Kent Watsen To: Ladislav Lhotka , Andy Bierman Thread-Topic: [Netconf] draft-kwatsen-conditional-enablement-00 Thread-Index: AQHOFGyhBDGXg9PhXkKLEOJGTSvqqZiMvHOAgAihugCAAE9VgA== Date: Mon, 4 Mar 2013 20:16:03 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.255.159.4] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%NIC.CZ$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%YUMAWORKS.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "netconf@ietf.org" Subject: Re: [Netconf] draft-kwatsen-conditional-enablement-00 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, 04 Mar 2013 20:21:27 -0000 [responding to all comments in this email] 0) Yes, this draft is about config (not schema). For instance, the I2RS folks talk about "temporal config" (their term) so instead of this: Every M-F @ 9am: Controller Router | | |----------------------------------->| | (turns on "foobar") | Every M-F @ 5pm: Controller Router | | |----------------------------------->| | (turns off "foobar") | Where the could be: // a "presence" node Or: // if we agreed on the "simple" expression They can have: When the policy is decided: Controller Router | | |----------------------------------->| | (set "foobar" with schedule) | Where the contains something like: =3D "Monday" && dayofweek <=3D "Friday= ") \ && (hour >=3D 9:00 && hour <=3D 17:00)"/> 1) I didn't define a YANG module because YANG is unable to model attributes. I view this as a shortcoming in YANG. Ideally we first address this issue in YANG and then update this draft with a YANG module. Any thoughts about this? 2) I'm not concerned about expression syntax, but I worry a lot about implementation complexity. The primary reason why the draft didn't specify XPath is because I thought it would be helpful if implementations could incrementally support parts they care about. For instance, if only wanting to support "simple" expressions, having to implement full-XPath could be more than a team wants to take on. YANG doesn't require XPath to be fully-implemented, since the vendor controls both the expression and its evaluation. In this case, clients could pass any expression, which then requires a full-xpath implementation on the device. Additionally, NMS's would need a XPath-parser so as to present pretty UI, which sounds complex... 3) Regarding an XPath expression function for comparing time values, this StackOverflow posting shows how it could be done in both XPath 1.0 and XPath 2.0: =20 http://stackoverflow.com/questions/475923/xpath-query-and-time. Just looking at the solutions, I'm struck by how unintuitive they are. In the same way that we choose YANG over XSD because we felt a domain-specific syntax could be better and simpler, maybe the same is true here? [ps: searching the path 2.0 spec, I didn't see a way to extract day-of-week=8A] Lastly, something that isn't a based on a comment from Andy or Lada, but you should know, I had planned to also submit a companion draft entitled "Conditional Assignment for Configuration Nodes". The idea is the similar except instead of an expression evaluating to a boolean, it instead evaluates to a value. That is, instead of: Every M-F @ 9am: Controller Router | | |----------------------------------->| | (sets "foobar" to 1024) | Every M-F @ 5pm: Controller Router | | |----------------------------------->| | (sets "foobar" to 2048) | Where the contains something like: 1024 Or 2048 It could be: When the policy is decided: Controller Router | | |----------------------------------->| | (set "foobar" with schedule) | Where the might look something like: -1 But this is where it gets tricky because: 1) there may be a need to handle multiple "if" cases 2) the "value" may be a subtree (not just a scalar) I stopped working on this solution because I ran out of time, but it should be considered along with "conditional-enablement" ... Thanks, Kent On 3/4/13 5:32 AM, "Ladislav Lhotka" wrote: >Andy Bierman writes: > >> >> IMO, inventing a new expression syntax when we already have 1 is not >>needed. > >Indeed, XPath should be suitable for this purpose - unlike YANG's when >statement, in fact. >This could also include the time-based enablement via current-time in >ietf-system, but this would require at least an XPath expression function >for comparing time values. > >Also, the draft uses features in a way that is not directly supported by >RFC 6020. We had this discussion before in another context and I don't >rememeber whether there was any conclusion. > >Lada > >--=20 >Ladislav Lhotka, CZ.NIC Labs >PGP Key ID: E74E8C0C > From andy@yumaworks.com Mon Mar 4 12:31:03 2013 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 D94D621F9092 for ; Mon, 4 Mar 2013 12:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1Rm+taUFi1W for ; Mon, 4 Mar 2013 12:31:03 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 4509F21F8E48 for ; Mon, 4 Mar 2013 12:31:02 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id 9so6757626iec.18 for ; Mon, 04 Mar 2013 12:31:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=wIVpTnHlHP8A7+5JKBSMiSRcLmAyYsYJxkAXYQhBBfE=; b=HQSAgOKNs40ChwbBvywC+e7egGrP4C++DTP8DhjfXZYsYR3ZkYqxS/jrCsJho0YyNl s7G21nlVoc167lu+FAsmP5CcfMQd6gg67agURW9VbaOiLv9EammnAKis7cuRLoXXbVxl w/0PUlhwCPsDcRyKOg9yz5kbcXJ24DikFSOW1kIhodkg7/r1eqIl+UZsaplGzIYkmmG/ CPlLiZ+4ITXz38/HFHXyHOasmQF63rJjXIJ/7osKXqc7qYrBrqAAgtxsBXVezAXd580p ZhETDWPzmyLc4OWWdNWy1i3lDW2TRfis7Ztr9BWvbfhE3bsnTVfaxAKMZlG8I5T+bXQP glXQ== MIME-Version: 1.0 X-Received: by 10.50.17.131 with SMTP id o3mr3753752igd.112.1362429061727; Mon, 04 Mar 2013 12:31:01 -0800 (PST) Received: by 10.231.93.6 with HTTP; Mon, 4 Mar 2013 12:31:01 -0800 (PST) In-Reply-To: References: Date: Mon, 4 Mar 2013 12:31:01 -0800 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQncd2UDWHrw3oa36nWhMfMF3dY6RX7kyYSp/odTqOv9Tx+BH3CDdn4BUiYUiexmhwyKu82r Cc: "netconf@ietf.org" Subject: Re: [Netconf] draft-kwatsen-conditional-enablement-00 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, 04 Mar 2013 20:31:04 -0000 Hi, This helps me understand what you are trying to do. Thanks. Maybe I'm biased (as co-author of NACM and original proponent of a standard ACM for NETCONF), but I would much rather see policy configur= ed with a YANG module that extends NACM, or at least coexists with NACM. IMO it is much easier and more efficient to use ordered rules like in NACM to describe the policy, rather than send s with the policy embedded in XML attributes in every data node that needs to have a policy applied to it. Andy On Mon, Mar 4, 2013 at 12:16 PM, Kent Watsen wrote: > > [responding to all comments in this email] > > > 0) Yes, this draft is about config (not schema). For instance, the I2RS > folks talk about "temporal config" (their term) so instead of this: > > Every M-F @ 9am: > > Controller Router > | | > |----------------------------------->| > | (turns on "foobar") | > > > Every M-F @ 5pm: > > Controller Router > | | > |----------------------------------->| > | (turns off "foobar") | > > > Where the could be: > // a "presence" node > Or: > // if we agreed on the "simple" > expression > > > > > They can have: > > When the policy is decided: > > Controller Router > | | > |----------------------------------->| > | (set "foobar" with schedule) | > > > Where the contains something like: > > =3D "Monday" && dayofweek <=3D "Frid= ay") \ > && (hour >=3D 9:00 && hour <=3D 17:00)"/> > > > > > > 1) I didn't define a YANG module because YANG is unable to model > attributes. I view this as a shortcoming in YANG. Ideally we first > address this issue in YANG and then update this draft with a YANG module. > Any thoughts about this? > > > 2) I'm not concerned about expression syntax, but I worry a lot about > implementation complexity. The primary reason why the draft didn't > specify XPath is because I thought it would be helpful if implementations > could incrementally support parts they care about. For instance, if only > wanting to support "simple" expressions, having to implement full-XPath > could be more than a team wants to take on. YANG doesn't require XPath t= o > be fully-implemented, since the vendor controls both the expression and > its evaluation. In this case, clients could pass any expression, which > then requires a full-xpath implementation on the device. Additionally, > NMS's would need a XPath-parser so as to present pretty UI, which sounds > complex... > > > 3) Regarding an XPath expression function for comparing time values, this > StackOverflow posting shows how it could be done in both XPath 1.0 and > XPath 2.0: > http://stackoverflow.com/questions/475923/xpath-query-and-time. Just > looking at the solutions, I'm struck by how unintuitive they are. In th= e > same way that we choose YANG over XSD because we felt a domain-specific > syntax could be better and simpler, maybe the same is true here? [ps: > searching the path 2.0 spec, I didn't see a way to extract day-of-week=C5= =A0] > > > Lastly, something that isn't a based on a comment from Andy or Lada, but > you should know, I had planned to also submit a companion draft entitled > "Conditional Assignment for Configuration Nodes". The idea is the simila= r > except instead of an expression evaluating to a boolean, it instead > evaluates to a value. That is, instead of: > > Every M-F @ 9am: > > Controller Router > | | > |----------------------------------->| > | (sets "foobar" to 1024) | > > > Every M-F @ 5pm: > > Controller Router > | | > |----------------------------------->| > | (sets "foobar" to 2048) | > > > Where the contains something like: > 1024 > Or > 2048 > > > > It could be: > > > When the policy is decided: > > Controller Router > | | > |----------------------------------->| > | (set "foobar" with schedule) | > > > Where the might look something like: > > -1 > > > > But this is where it gets tricky because: > > 1) there may be a need to handle multiple "if" cases > 2) the "value" may be a subtree (not just a scalar) > > I stopped working on this solution because I ran out of time, but it > should be considered along with "conditional-enablement" ... > > > Thanks, > Kent > > > > > > > > > On 3/4/13 5:32 AM, "Ladislav Lhotka" wrote: > >>Andy Bierman writes: >> >>> >>> IMO, inventing a new expression syntax when we already have 1 is not >>>needed. >> >>Indeed, XPath should be suitable for this purpose - unlike YANG's when >>statement, in fact. >>This could also include the time-based enablement via current-time in >>ietf-system, but this would require at least an XPath expression function >>for comparing time values. >> >>Also, the draft uses features in a way that is not directly supported by >>RFC 6020. We had this discussion before in another context and I don't >>rememeber whether there was any conclusion. >> >>Lada >> >>-- >>Ladislav Lhotka, CZ.NIC Labs >>PGP Key ID: E74E8C0C >> > > From kwatsen@juniper.net Mon Mar 4 18:12:00 2013 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 8A1B521F87E7 for ; Mon, 4 Mar 2013 18:12:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.167 X-Spam-Level: X-Spam-Status: No, score=-3.167 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKmO+FhJU9cG for ; Mon, 4 Mar 2013 18:12:00 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id E77D421F87D3 for ; Mon, 4 Mar 2013 18:11:59 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKUTVUboLvcPya4ENUjzQUpqTp0C3er+TP@postini.com; Mon, 04 Mar 2013 18:11:59 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 4 Mar 2013 18:09:19 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Mon, 4 Mar 2013 18:09:18 -0800 Received: from CO9EHSOBE011.bigfish.com (207.46.163.25) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 4 Mar 2013 18:18:46 -0800 Received: from mail183-co9-R.bigfish.com (10.236.132.232) by CO9EHSOBE011.bigfish.com (10.236.130.74) with Microsoft SMTP Server id 14.1.225.23; Tue, 5 Mar 2013 02:09:17 +0000 Received: from mail183-co9 (localhost [127.0.0.1]) by mail183-co9-R.bigfish.com (Postfix) with ESMTP id AE0C2DC00E1 for ; Tue, 5 Mar 2013 02:09:17 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -6 X-BigFish: PS-6(zzbb2dI98dI9371I1dbaI1432I4015Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275bhz2dh2a8h668h839h946he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1155h) Received: from mail183-co9 (localhost.localdomain [127.0.0.1]) by mail183-co9 (MessageSwitch) id 1362449356358364_16049; Tue, 5 Mar 2013 02:09:16 +0000 (UTC) Received: from CO9EHSMHS026.bigfish.com (unknown [10.236.132.253]) by mail183-co9.bigfish.com (Postfix) with ESMTP id 5444C8C005E; Tue, 5 Mar 2013 02:09:16 +0000 (UTC) Received: from CH1PRD0511HT001.namprd05.prod.outlook.com (157.56.245.197) by CO9EHSMHS026.bigfish.com (10.236.130.36) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 5 Mar 2013 02:09:13 +0000 Received: from CH1PRD0511MB407.namprd05.prod.outlook.com ([169.254.5.117]) by CH1PRD0511HT001.namprd05.prod.outlook.com ([10.255.159.36]) with mapi id 14.16.0275.006; Tue, 5 Mar 2013 02:09:12 +0000 From: Kent Watsen To: Andy Bierman Thread-Topic: [Netconf] draft-kwatsen-conditional-enablement-00 Thread-Index: AQHOFGyhBDGXg9PhXkKLEOJGTSvqqZiMvHOAgAihugCAAE9VgIAAWAOAgAAKp4A= Date: Tue, 5 Mar 2013 02:09:11 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.255.159.4] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%YUMAWORKS.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%NIC.CZ$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "netconf@ietf.org" Subject: Re: [Netconf] draft-kwatsen-conditional-enablement-00 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, 05 Mar 2013 02:12:00 -0000 I like rulebase processing - I've used it effectively on other modeling projects. The one thing I don't like about the approach here (or any other I've thought of in the last couple weeks), is that they change to structure of the config such that it is no longer just an annotation of its original self. At least somehow, in my mind, putting XML attributes on existing config nodes is less intrusive=8A Consider the data model: container foo { leaf bar { type integer; } } Which has config: 1024 Using XML attributes, conditional-enablement might looks like: 1024 Or: 1024 Whereas a rulebase approach might be: time M-F 9am-5pm 1024 Don't focus on the syntax, we can massage that into something better later, but what about the fact that the "config" hardly resembles the original YANG definition? Does it matter? I'm sure it would look better with namespaces clearly indicating which parts came from the "conditional-enablement" module, but still, it seems heavy - what do you think? Back to conditional *assignments*, there may be no other option - bottom line is that if/else expressions (or case statements) containing multiple conditions, there is no easy way to express them without taking up a lot of space. For instance: time M-F 9am-5pm 1024 2048 Thanks, Kent On 3/4/13 3:31 PM, "Andy Bierman" wrote: >Hi, > >This helps me understand what you are trying to do. Thanks. >Maybe I'm biased (as co-author of NACM and original proponent >of a standard ACM for NETCONF), but I would much rather see policy >configured >with a YANG module that extends NACM, or at least coexists with NACM. > >IMO it is much easier and more efficient to use ordered rules like in >NACM to describe the policy, >rather than send s with the policy embedded in XML >attributes in every >data node that needs to have a policy applied to it. > > >Andy From andy@yumaworks.com Mon Mar 4 18:39:13 2013 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 C1F6C21F85D9 for ; Mon, 4 Mar 2013 18:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.828 X-Spam-Level: X-Spam-Status: No, score=-1.828 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxdhauTG3Plk for ; Mon, 4 Mar 2013 18:39:13 -0800 (PST) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 451D921F85BD for ; Mon, 4 Mar 2013 18:39:13 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id 17so7045834iea.26 for ; Mon, 04 Mar 2013 18:39:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=1DJnIYhTeWWR2EiCfUQTJeB1H0Qr2PUifNW+Rk3130w=; b=KkKYS6+L3qNJVo1aT5rNT8oV1H7GNYCY4CFXzGxIzOpKD2sUO+XdLD7FHVs1luxWFE yzHfYA7YKsV0W+8PBce0HGScZzqgAiRGsgGuJWlefhnLnS9NcUZcAoXn6os72vpiGIpJ qAU5iLfinyckCHJtoCXiNfOwLRUX++t/WVAFPsVTr7Lb8NP+/Z1MYS/rPcuSgrzXFxRT 6piJ/3pzRxhPcAKVwVrAw5rY1wV7Jp2cBj2ixcCOyGw5cDorRiz6ZoVQGMeFXOFe4CVM vkEeJWREpVKPAuV7QZwOAU7sQqYGVA2CKkC4mShZk84V5Hw8BLgqopR0jjcrZK5c1xYU 68Lg== MIME-Version: 1.0 X-Received: by 10.50.153.198 with SMTP id vi6mr4702930igb.112.1362451152676; Mon, 04 Mar 2013 18:39:12 -0800 (PST) Received: by 10.231.93.6 with HTTP; Mon, 4 Mar 2013 18:39:12 -0800 (PST) In-Reply-To: References: Date: Mon, 4 Mar 2013 18:39:12 -0800 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkImGH5UhTipmMDaD+/8dxUb2MLS0iAJDCyZGYGBSf9hEaTKoB2Os87zy885tar7aXqAwQK Cc: "netconf@ietf.org" Subject: Re: [Netconf] draft-kwatsen-conditional-enablement-00 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, 05 Mar 2013 02:39:13 -0000 On Mon, Mar 4, 2013 at 6:09 PM, Kent Watsen wrote: > > I like rulebase processing - I've used it effectively on other modeling > projects. > > The one thing I don't like about the approach here (or any other I've > thought of in the last couple weeks), is that they change to structure of > the config such that it is no longer just an annotation of its original > self. At least somehow, in my mind, putting XML attributes on existing > config nodes is less intrusive=C5=A0 > > Consider the data model: > > container foo { > leaf bar { > type integer; > } > } > > Which has config: > > > 1024 > > > > Using XML attributes, conditional-enablement might looks like: > > > > 1024 > > > > Or: > > > 1024 > > > > Whereas a rulebase approach might be: > > > > > time > M-F 9am-5pm > > 1024 > > > > > > > > > > > > Don't focus on the syntax, we can massage that into something better > later, but what about the fact that the "config" hardly resembles the > original YANG definition? Does it matter? I'm sure it would look > better with namespaces clearly indicating which parts came from the > "conditional-enablement" module, but still, it seems heavy - what do you > think? > I think a rule-based approach scales much better and also works better if there are multiple manager apps setting config, but maybe not all apps have access to the policy config or know how to set the right policy. I would much rather be able to update the policy for 100,000 interfaces all at once, without requiring a massive to do that. Also there will be a lot of redundant verbose monitoring info with these attributes. > > > > Back to conditional *assignments*, there may be no other option - bottom > line is that if/else expressions (or case statements) containing multiple > conditions, there is no easy way to express them without taking up a lot > of space. For instance: > > > > > > time > M-F 9am-5pm > > 1024 > > > > > > 2048 > > > > > I think this is better than sending 100,000 'enabled' attributes to the ser= ver, especially since changing policy rules happens much less often than changing config. > > > > Thanks, > Kent > Andy From teramoto@net.ist.i.kyoto-u.ac.jp Tue Mar 5 05:02:05 2013 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 DBED921F88DB for ; Tue, 5 Mar 2013 05:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3SH2qfMSzdU for ; Tue, 5 Mar 2013 05:02:05 -0800 (PST) Received: from smtp-auth.kuins.kyoto-u.ac.jp (smtp-auth.kuins.kyoto-u.ac.jp [133.3.248.237]) by ietfa.amsl.com (Postfix) with ESMTP id 9F48021F8698 for ; Tue, 5 Mar 2013 05:02:03 -0800 (PST) Received: from smtp-auth.kuins.kyoto-u.ac.jp (smtp-auth.kuins.kyoto-u.ac.jp [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 9DA352EC002; Tue, 5 Mar 2013 22:02:01 +0900 (JST) Received: from h134.104.228.10.103219.vlan.kuins.net (h134.104.228.10.103219.vlan.kuins.net [10.228.104.134]) by smtp-auth.kuins.kyoto-u.ac.jp (Postfix) with ESMTP id 1723C2EC001; Tue, 5 Mar 2013 22:02:01 +0900 (JST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Teramoto Yasuhiro In-Reply-To: <20130304164729.GA8549@elstar.local> Date: Tue, 5 Mar 2013 22:01:59 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <12298AA2-00CF-4053-A53C-362A193E81F5@net.ist.i.kyoto-u.ac.jp> References: <20130225212537.8997.433.idtracker@ietfa.amsl.com> <20130304151901.GA8148@elstar.local> <4A4B42D1-2D8F-4329-9966-BF96BF540BEF@nic.cz> <20130304153847.GB8232@elstar.local> <20130304164729.GA8549@elstar.local> To: "netconf@ietf.org" X-Mailer: Apple Mail (2.1499) Cc: Yasuo Okabe Subject: Re: [Netconf] draft-teramoto-experience-network-management-01 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, 05 Mar 2013 13:02:06 -0000 Thanks for a lot of valuable comments on our I-D! I respond to all of comments in this email. > In 3.1 - 3.3, you do not say what implementation problems you had > connecting with SSH or completing the exchange. Normally = developers > creating a client implementation have access to the server logs during > development. Returning XML comments for implementations in progress > may be nice to have, but not generally needed. I am more interested > in knowing what text in RFCs 6241 and 6242 is too unclear to produce a = correct > implementation. Our opinion is that the NETCONF protocol only considers "soundness" but does not ensure "completeness"; that is, everything would go well when implementations of the client and servers are perfect and there are no error on transport layer, or the client encouters sudden disconnection from servers without any = error notifications. (For example, I had a bit trouble on connecting to Cisco IOS 12.2 with = NETCONF, because it used old base capability "urn:ietf:params:netconf:base:1.0" and does not support "urn:ietf:params:xml:ns:netconf:base:1.0". When I sent current capability, my client was disconnected suddenly on sending the "next" message by message, that is first = message. I first thought that was caused by invalid message or my = transport implementation) Even though the developer may be able to access the server log, we think it is better to notify exact error information on the protocol = level. And, of course, the error does not necessarily occur on developing, low probability errors sometimes occur much later. > I also do not agree that notifications are too complicated. > If you can support optional :interleave at all, then transitioning = from > replay to live notifications is trivial. Of course, If all servers supported :interleave, then these pointing out would be meaningless. However, the developers should not expect convenient assumption because the RFC 5277 says that the server which does not support = :interleave may exist on section 1.3. > In sec. 4 you suggest that YANG is a bug not a feature, and: >=20 > The same approaches of YANG often causes variability of = configuration > model and also causes too large and complex data schema. = Furthermore > YANG defines only the model schema, therefore the way to construct > model data is owed to the developer. We think the fundamental model > data, that is frequently used in configuration such as VLANs and > Interfaces, should be defined by NETCONF core specification like = SNMP > in order to avoid such problems. >=20 > I assume this means we should be using SMIv2 instead of YANG? > I disagree that SMIv2 or SNMP simplifies CM for complex devices. > IMO it makes it much worse, which is why we use NEETCONF/YANG instead. > The draft also has a section about YANG and data modelling but, = honestly, I don't understand the objections therein. Yasuhiro et al., = could you please explain them in more detail, preferably in the NETMOD = mailing list? At first, this is our opinion from our experience, so excuse me if the goal of NETCONF/YANG and our opinion significantly do not match. The first one is as Mr. Schoenwaelder gently interpretes my confusing = document. > My interpretation of the paragraph was that they see a lack of > standard YANG modules. Yes, back in SNMP days, everything was done in > one go - you got SNMP, the SMI, and basic MIB modules. Now everything > comes serialized, first NETCONF, then YANG, then data models. = Serialization > apparently takes a lot of time and leaves people with something = incomplete. It will also take a decade to all of them become available completely. We think some fundamental models now can be standardize using current = YANG language by referring to the good and bad points of current MIB modules. Many equipments now support the NETCONF protocol experimetally; however all of them are hard to use because of the lack of common = models. If models of fundamental part such as interface exist, developers can use on some degree even if the rest does not be modeled. This approach have benefits that the model designer can receive a lot of feedbacks from protocol users. The second one is that we feel the current approach of YANG adopts device centric approach that design models to express various kind of devices on few number of = complicated schema using flexible mechanism such as when statements. This approach will cause too complicated models and make it difficult to manage device briefly and construct model data. SNMP goes well because it is mainly used as read-only; the users only have to manage parts of their interest. We think the fundamental models that is frequently used should be simply = designed by top down approach on some degree, that is, the device side make some efforts to fit to the given model. Thanks. On 2013/03/05, at 1:47, Juergen Schoenwaelder = wrote: > On Mon, Mar 04, 2013 at 08:23:55AM -0800, Andy Bierman wrote: >> On Mon, Mar 4, 2013 at 7:38 AM, Juergen Schoenwaelder < >> j.schoenwaelder@jacobs-university.de> wrote: >>=20 >>> On Mon, Mar 04, 2013 at 04:26:54PM +0100, Ladislav Lhotka wrote: >>>>=20 >>>> On Mar 4, 2013, at 4:19 PM, Juergen Schoenwaelder < >>> j.schoenwaelder@jacobs-university.de> wrote: >>>>=20 >>>>> On Mon, Mar 04, 2013 at 07:03:54AM -0800, Andy Bierman wrote: >>>>>>=20 >>>>>> In sec. 4 you suggest that YANG is a bug not a feature, and: >>>>>>=20 >>>>>> The same approaches of YANG often causes variability of >>> configuration >>>>>> model and also causes too large and complex data schema. >>> Furthermore >>>>>> YANG defines only the model schema, therefore the way to = construct >>>>>> model data is owed to the developer. We think the fundamental = model >>>>>> data, that is frequently used in configuration such as VLANs and >>>>>> Interfaces, should be defined by NETCONF core specification like >>> SNMP >>>>>> in order to avoid such problems. >>>>>>=20 >>>>>> I assume this means we should be using SMIv2 instead of YANG? >>>>>> I disagree that SMIv2 or SNMP simplifies CM for complex devices. >>>>>> IMO it makes it much worse, which is why we use NEETCONF/YANG = instead. >>>>>=20 >>>>> My interpretation of the paragraph was that they see a lack of >>>>> standard YANG modules. Yes, back in SNMP days, everything was done = in >>>>> one go - you got SNMP, the SMI, and basic MIB modules. Now = everything >>>>> comes serialized, first NETCONF, then YANG, then data models. >>> Serialization >>>>> apparently takes a lot of time and leaves people with something >>> incomplete. >>>>=20 >>>> Well, even if we already had all the YANG data models available, = they >>> would still essentially define model schema, so I don't get the = "model >>> data" part. >>>>=20 >>>=20 >>> Trying to take words literally won't help. This was the only >>> meaningful interpretation I could come up with. Perhaps there are >>> others. ;-) >>>=20 >>>=20 >> Perhaps the issue being raised: >> - Why does RFC 6643 define a read-only mapping from SMIv2 to YANG? >=20 > Only the authors can tell us. Lets stop speculating. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From lhotka@nic.cz Tue Mar 5 05:05:58 2013 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 1397F21F88E1 for ; Tue, 5 Mar 2013 05:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.246 X-Spam-Level: X-Spam-Status: No, score=-1.246 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfCfHjDnLLAQ for ; Tue, 5 Mar 2013 05:05:56 -0800 (PST) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 4A15F21F88EF for ; Tue, 5 Mar 2013 05:05:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id A86FE540346; Tue, 5 Mar 2013 14:05:49 +0100 (CET) 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 N-qY8vxp0K8O; Tue, 5 Mar 2013 14:05:42 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 2826C54032E; Tue, 5 Mar 2013 14:05:37 +0100 (CET) From: Ladislav Lhotka To: Kent Watsen , Andy Bierman In-Reply-To: References: User-Agent: Notmuch/0.15.1+15~gd037040 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Date: Tue, 05 Mar 2013 14:05:36 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "netconf@ietf.org" Subject: Re: [Netconf] draft-kwatsen-conditional-enablement-00 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, 05 Mar 2013 13:05:58 -0000 Kent Watsen writes: ... > > 1) I didn't define a YANG module because YANG is unable to model > attributes. I view this as a shortcoming in YANG. Ideally we first > address this issue in YANG and then update this draft with a YANG module. > Any thoughts about this? I think it is actually a feature of YANG that it doesn't model XML attributes. A few global attributes, such as "enabled" can be easily defined using XSD or RELAX NG. > > > 2) I'm not concerned about expression syntax, but I worry a lot about > implementation complexity. The primary reason why the draft didn't > specify XPath is because I thought it would be helpful if implementations > could incrementally support parts they care about. For instance, if only > wanting to support "simple" expressions, having to implement full-XPath > could be more than a team wants to take on. YANG doesn't require XPath to There can still be two different capabilities: simple (true/false) and complex (XPath). > be fully-implemented, since the vendor controls both the expression and > its evaluation. In this case, clients could pass any expression, which > then requires a full-xpath implementation on the device. Additionally, > NMS's would need a XPath-parser so as to present pretty UI, which sounds > complex... The NMS can present a simple UI, e.g. a calendar widget, and just construct corresponding XPath expressions. > > > 3) Regarding an XPath expression function for comparing time values, this > StackOverflow posting shows how it could be done in both XPath 1.0 and > XPath 2.0: > http://stackoverflow.com/questions/475923/xpath-query-and-time. Just > looking at the solutions, I'm struck by how unintuitive they are. In the > same way that we choose YANG over XSD because we felt a domain-specific > syntax could be better and simpler, maybe the same is true here? [ps: > searching the path 2.0 spec, I didn't see a way to extract day-of-week] Nobody wants to repeatedly write such awkward expressions. What I had in mind was a function that extends XPath, something like "yang:time-before(/sys:system/sys:clock/sys:current-datetime, '2013-03-05T14:02:45+01:00')" Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Tue Mar 5 05:26:42 2013 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 63DCC21F8815 for ; Tue, 5 Mar 2013 05:26:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.208 X-Spam-Level: X-Spam-Status: No, score=-1.208 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEcjZH2-45s9 for ; Tue, 5 Mar 2013 05:26:42 -0800 (PST) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id C5BD421F8735 for ; Tue, 5 Mar 2013 05:26:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 095F3540346; Tue, 5 Mar 2013 14:26:41 +0100 (CET) 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 YW3jDr3v-mXt; Tue, 5 Mar 2013 14:26:30 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 3FDF55402CF; Tue, 5 Mar 2013 14:26:30 +0100 (CET) From: Ladislav Lhotka To: Kent Watsen , Andy Bierman In-Reply-To: References: User-Agent: Notmuch/0.15.1+15~gd037040 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Date: Tue, 05 Mar 2013 14:26:29 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "netconf@ietf.org" Subject: Re: [Netconf] draft-kwatsen-conditional-enablement-00 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, 05 Mar 2013 13:26:42 -0000 Kent Watsen writes: ... > > Back to conditional *assignments*, there may be no other option - bottom > line is that if/else expressions (or case statements) containing multiple > conditions, there is no easy way to express them without taking up a lot > of space. For instance: > > > > > > time > M-F 9am-5pm > > 1024 > > > > > > 2048 > > > > > > IMO, one option would be to have the candidate config represented not as a clone of running with modifications but rather as a sequence of patches. Then various rules/conditions could be specified as attributes of each patch - when it should be applied etc. At commit, all unconditional patches would be immediately applied and the conditional/termporal ones put on hold. BTW, this would also solve the problem of access rights - it can be easily checked whether the user submitting each patch is entitled to perform the changes. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Tue Mar 5 07:06:57 2013 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 F11E421F89DC for ; Tue, 5 Mar 2013 07:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.637 X-Spam-Level: X-Spam-Status: No, score=-1.637 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wO245oYOJ3Gt for ; Tue, 5 Mar 2013 07:06:57 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 0786C21F89D3 for ; Tue, 5 Mar 2013 07:06:57 -0800 (PST) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 22C8114059F; Tue, 5 Mar 2013 16:06:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1362496016; bh=a0yLdY8ehxmppCsD6a9OACOjl+MpCJAwlZn7pAafP34=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=KYpgB93QKLH04v9fAfC1PvnIWAXBiZQ4OA86Fx/kV0DAEX8qiFGVrDIZAq6PHG5nd VpQYeIM9WBSDkny0ClAKPObFvxvIeJ1fWVEo+6COLSjGLNcoCN0C+A8B1UtX5thVht 149OluJZEmo3QGVgvsWlXXFqtAncAhpUhUuOvexc= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: <12298AA2-00CF-4053-A53C-362A193E81F5@net.ist.i.kyoto-u.ac.jp> Date: Tue, 5 Mar 2013 16:06:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130225212537.8997.433.idtracker@ietfa.amsl.com> <20130304151901.GA8148@elstar.local> <4A4B42D1-2D8F-4329-9966-BF96BF540BEF@nic.cz> <20130304153847.GB8232@elstar.local> <20130304164729.GA8549@elstar.local> <12298AA2-00CF-4053-A53C-362A193E81F5@net.ist.i.kyoto-u.ac.jp> To: Teramoto Yasuhiro X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: "netconf@ietf.org" , Yasuo Okabe Subject: Re: [Netconf] draft-teramoto-experience-network-management-01 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, 05 Mar 2013 15:06:58 -0000 On Mar 5, 2013, at 2:01 PM, Teramoto Yasuhiro = wrote: > It will also take a decade to all of them become available completely. > We think some fundamental models now can be standardize using current = YANG language > by referring to the good and bad points of current MIB modules. > Many equipments now support the NETCONF protocol experimetally; > however all of them are hard to use because of the lack of common = models. > If models of fundamental part such as interface exist, > developers can use on some degree even if the rest does not be = modeled. > This approach have benefits that the model designer can receive > a lot of feedbacks from protocol users. If the data model is only partial or restricted so that some knobs = remain accessible only through CLI, then many users would see no point = in using NETCONF because they have to cope with CLI anyway. I understand = this is one of the reasons why SNMP was abandoned as a config tool.=20 >=20 > The second one is that we feel > the current approach of YANG adopts device centric approach > that design models to express various kind of devices on few number of = complicated schema > using flexible mechanism such as when statements. > This approach will cause too complicated models > and make it difficult to manage device briefly and construct model = data. > SNMP goes well because it is mainly used as read-only; > the users only have to manage parts of their interest. > We think the fundamental models that is frequently used should be = simply designed by top down approach on some degree, > that is, the device side make some efforts to fit to the given model. This is related to the previous issue. We didn't start with a clean = slate - the major router operating systems already have their = sophisticated configuration interfaces and the vendors are not likely to = change the logic of their configuration just for the sake of NETCONF. = That's why the NETMOD WG decided to create the core data models in a = "one-size-fits-all" style, as much as possible. Sure, this makes the = data models more complex and their development took some time, but I = think the result is a resonable compromise, though I am certainly = biased. One common pattern that you are probably referring to, and that might = indeed confuse readers of the data models, is the use of "augment", = often together with "when". I think this was unavoidable because we = cannot standardize everything in one shot and this way gradual = development of data models (both IETF and proprietary) can proceed from = general stuff to specific details. =20 Lada =20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Tue Mar 5 07:39:24 2013 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 D2E5D21F88EF for ; Tue, 5 Mar 2013 07:39:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.558 X-Spam-Level: X-Spam-Status: No, score=-1.558 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bo60aiel-a-7 for ; Tue, 5 Mar 2013 07:39:23 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id A14F821F88BF for ; Tue, 5 Mar 2013 07:39:23 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id c13so8074995ieb.9 for ; Tue, 05 Mar 2013 07:39:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=UxpXPem1bOcvCTAzT+h4m2DrUWM0wkrfHKBGFRAux5I=; b=NXDcJx3/JgEzI5OGu0jTeMGFLD9MeYjM0RdXA8nCc5nf9bFjEVpjSiAKIewIHLkSyX 3O9YR4TI/TqED/3PMp3L5W2xYxFrUn3uXVJOSNK0EqOiRZjhW5JTmv/JizZ5Ipum9qM8 MT3gUMfQQVguPTkRShUy8H5jFBP0hs51PijThsMCeAHUQ2/LkdBK1Esvp8RteDjLG2UU KUG0/kYZzgbKVe+nbnwjYFSAOZMu/WPW9f1L0L8UP1+Isg79E5QTcESsfyCb1H3NcVFW FTtSNGervgGlj1O9LXID2ha8XlbxmPhx5NIdo6JyX7Izv/ngBjmKbR+P2o5aUld2OlZI 9dWw== MIME-Version: 1.0 X-Received: by 10.50.37.239 with SMTP id b15mr6708283igk.69.1362497963030; Tue, 05 Mar 2013 07:39:23 -0800 (PST) Received: by 10.231.93.6 with HTTP; Tue, 5 Mar 2013 07:39:22 -0800 (PST) In-Reply-To: References: <20130225212537.8997.433.idtracker@ietfa.amsl.com> <20130304151901.GA8148@elstar.local> <4A4B42D1-2D8F-4329-9966-BF96BF540BEF@nic.cz> <20130304153847.GB8232@elstar.local> <20130304164729.GA8549@elstar.local> <12298AA2-00CF-4053-A53C-362A193E81F5@net.ist.i.kyoto-u.ac.jp> Date: Tue, 5 Mar 2013 07:39:22 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQno9SbJo5RdkNTb2N5FBGh5QZvC2d0tMnRjqr65puG1W9t5Tn9tyDX2WNNGUp1gm9P9owNG Cc: "netconf@ietf.org" , Yasuo Okabe Subject: Re: [Netconf] draft-teramoto-experience-network-management-01 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, 05 Mar 2013 15:39:25 -0000 On Tue, Mar 5, 2013 at 7:06 AM, Ladislav Lhotka wrote: > > On Mar 5, 2013, at 2:01 PM, Teramoto Yasuhiro wrote: > >> It will also take a decade to all of them become available completely. >> We think some fundamental models now can be standardize using current YA= NG language >> by referring to the good and bad points of current MIB modules. >> Many equipments now support the NETCONF protocol experimetally; >> however all of them are hard to use because of the lack of common models= . >> If models of fundamental part such as interface exist, >> developers can use on some degree even if the rest does not be modeled. >> This approach have benefits that the model designer can receive >> a lot of feedbacks from protocol users. > > If the data model is only partial or restricted so that some knobs remain= accessible only through CLI, then many users would see no point in using N= ETCONF because they have to cope with CLI anyway. I understand this is one = of the reasons why SNMP was abandoned as a config tool. > >> >> The second one is that we feel >> the current approach of YANG adopts device centric approach >> that design models to express various kind of devices on few number of c= omplicated schema >> using flexible mechanism such as when statements. >> This approach will cause too complicated models >> and make it difficult to manage device briefly and construct model data. >> SNMP goes well because it is mainly used as read-only; >> the users only have to manage parts of their interest. >> We think the fundamental models that is frequently used should be simply= designed by top down approach on some degree, >> that is, the device side make some efforts to fit to the given model. > > This is related to the previous issue. We didn't start with a clean slate= - the major router operating systems already have their sophisticated conf= iguration interfaces and the vendors are not likely to change the logic of = their configuration just for the sake of NETCONF. That's why the NETMOD WG = decided to create the core data models in a "one-size-fits-all" style, as m= uch as possible. Sure, this makes the data models more complex and their de= velopment took some time, but I think the result is a resonable compromise,= though I am certainly biased. > +1 If we start the clock on SNMP with RFC 1067 (and forget SGMP) that would be August 1988. One could argue that Entity MIB V2 finished the core SMIv2 module set in December 1999. NETCONF was first published in December 2006, so perhaps we are half finish= ed. It is always harder to plan ahead, agree on common functionality, and write a standard specification that will pass IESG review. Compared to that, throwing together a new data model every time a new device comes along is a "no-brainer". (Until "N" gets sufficiently large so the whole thing blows up in your face and it takes 150 people to develop an NMS application.) > One common pattern that you are probably referring to, and that might ind= eed confuse readers of the data models, is the use of "augment", often toge= ther with "when". I think this was unavoidable because we cannot standardiz= e everything in one shot and this way gradual development of data models (b= oth IETF and proprietary) can proceed from general stuff to specific detail= s. > > Lada Andy > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From kwatsen@juniper.net Tue Mar 5 13:31:11 2013 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 5DBD011E80D3 for ; Tue, 5 Mar 2013 13:31:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.317 X-Spam-Level: X-Spam-Status: No, score=-3.317 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyMmwno6NMuf for ; Tue, 5 Mar 2013 13:31:10 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 113E111E8110 for ; Tue, 5 Mar 2013 13:30:58 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUTZkEVHsfaPXbc68azISNTGcuP1z1/dY@postini.com; Tue, 05 Mar 2013 13:30:58 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 5 Mar 2013 13:26:45 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Tue, 5 Mar 2013 13:26:44 -0800 Received: from CO9EHSOBE022.bigfish.com (207.46.163.28) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 5 Mar 2013 13:36:11 -0800 Received: from mail190-co9-R.bigfish.com (10.236.132.231) by CO9EHSOBE022.bigfish.com (10.236.130.85) with Microsoft SMTP Server id 14.1.225.23; Tue, 5 Mar 2013 21:26:44 +0000 Received: from mail190-co9 (localhost [127.0.0.1]) by mail190-co9-R.bigfish.com (Postfix) with ESMTP id 13206C402F6 for ; Tue, 5 Mar 2013 21:26:44 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -3 X-BigFish: PS-3(zz1432I1418I4015Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzzz2dh2a8h668h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1155h) Received: from mail190-co9 (localhost.localdomain [127.0.0.1]) by mail190-co9 (MessageSwitch) id 1362518801773623_1273; Tue, 5 Mar 2013 21:26:41 +0000 (UTC) Received: from CO9EHSMHS020.bigfish.com (unknown [10.236.132.239]) by mail190-co9.bigfish.com (Postfix) with ESMTP id B09AE74004B; Tue, 5 Mar 2013 21:26:41 +0000 (UTC) Received: from CH1PRD0511HT004.namprd05.prod.outlook.com (157.56.245.197) by CO9EHSMHS020.bigfish.com (10.236.130.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 5 Mar 2013 21:26:41 +0000 Received: from CH1PRD0511MB407.namprd05.prod.outlook.com ([169.254.5.117]) by CH1PRD0511HT004.namprd05.prod.outlook.com ([10.255.159.39]) with mapi id 14.16.0275.006; Tue, 5 Mar 2013 21:26:40 +0000 From: Kent Watsen To: Andy Bierman Thread-Topic: [Netconf] draft-kwatsen-conditional-enablement-00 Thread-Index: AQHOFGyhBDGXg9PhXkKLEOJGTSvqqZiMvHOAgAihugCAAE9VgIAAWAOAgAAKp4CAAFw4AIAA5y4A Date: Tue, 5 Mar 2013 21:26:39 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.255.159.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%YUMAWORKS.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%NIC.CZ$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "netconf@ietf.org" Subject: Re: [Netconf] draft-kwatsen-conditional-enablement-00 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, 05 Mar 2013 21:31:11 -0000 HI Andy, I don't fully understand some of your comments... >I think a rule-based approach scales much better Scale better on which axis? All the solutions I can think of seem nearly equal from a scaling perspective... > and also works better >if there are multiple manager apps setting config, but maybe not all apps >have access to the policy config or know how to set the right policy. I don't understand - whatever syntax we choose would have to be understood by all clients, if the device-advertizes support for this ability. How would using rulebases make this any easier? >I would much rather be able to update the policy for 100,000 interfaces >all at once, without requiring a massive to do that. >Also there will be a lot of redundant verbose monitoring info with >these attributes. Do you mean that you rather a client set a temporal-policy on each of a 100,000 interfaces once, than having the client set/unset the settings remotely? In other words, you like the idea of temporal config? >my rulebase example >I think this is better than sending 100,000 'enabled' attributes to the >server, >especially since changing policy rules happens much less often than >changing config. Agreed, sending temporal-config is less chatty (and more reflective of what the client really wants) than having the client flipping settings themselves. =20 I think that your 'enabled' comment above regards only using what the draft referred to as "simple" expressions (i.e. enabled=3D"true" or enabled=3D"false"). The draft also described temporal-expressions, in whic= h case they'd be comparable to the rulebase example I gave. Thanks, Kent From kwatsen@juniper.net Tue Mar 5 14:00:22 2013 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 25EB411E811A for ; Tue, 5 Mar 2013 14:00:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.367 X-Spam-Level: X-Spam-Status: No, score=-3.367 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HY+kAdM8+hWl for ; Tue, 5 Mar 2013 14:00:21 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 81D7C11E8118 for ; Tue, 5 Mar 2013 14:00:21 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUTZq9SpPQk6YbHKfSKK3cD6LJfpSzd3o@postini.com; Tue, 05 Mar 2013 14:00:21 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 5 Mar 2013 13:58:37 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Tue, 5 Mar 2013 13:58:36 -0800 Received: from am1outboundpool.messaging.microsoft.com (213.199.154.207) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 5 Mar 2013 14:08:04 -0800 Received: from mail1-am1-R.bigfish.com (10.3.201.235) by AM1EHSOBE025.bigfish.com (10.3.207.147) with Microsoft SMTP Server id 14.1.225.23; Tue, 5 Mar 2013 21:58:34 +0000 Received: from mail1-am1 (localhost [127.0.0.1]) by mail1-am1-R.bigfish.com (Postfix) with ESMTP id CD7322001B7 for ; Tue, 5 Mar 2013 21:58:34 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -1 X-BigFish: PS-1(zz1432Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzzz2dh2a8h668h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1155h) Received: from mail1-am1 (localhost.localdomain [127.0.0.1]) by mail1-am1 (MessageSwitch) id 1362520713154731_25485; Tue, 5 Mar 2013 21:58:33 +0000 (UTC) Received: from AM1EHSMHS001.bigfish.com (unknown [10.3.201.253]) by mail1-am1.bigfish.com (Postfix) with ESMTP id 192153E0094; Tue, 5 Mar 2013 21:58:33 +0000 (UTC) Received: from CH1PRD0511HT003.namprd05.prod.outlook.com (157.56.245.197) by AM1EHSMHS001.bigfish.com (10.3.207.101) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 5 Mar 2013 21:58:32 +0000 Received: from CH1PRD0511MB407.namprd05.prod.outlook.com ([169.254.5.117]) by CH1PRD0511HT003.namprd05.prod.outlook.com ([10.255.159.38]) with mapi id 14.16.0275.006; Tue, 5 Mar 2013 21:58:26 +0000 From: Kent Watsen To: Ladislav Lhotka , Andy Bierman Thread-Topic: [Netconf] draft-kwatsen-conditional-enablement-00 Thread-Index: AQHOFGyhBDGXg9PhXkKLEOJGTSvqqZiMvHOAgAihugCAAE9VgIABbeUAgABBCwA= Date: Tue, 5 Mar 2013 21:58:26 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.255.159.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <17FF255BE2FECB46ADD8D40A9F1B3B06@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%NIC.CZ$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%YUMAWORKS.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "netconf@ietf.org" Subject: Re: [Netconf] draft-kwatsen-conditional-enablement-00 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, 05 Mar 2013 22:00:22 -0000 >I think it is actually a feature of YANG that it doesn't model XML >attributes. A few global attributes, such as "enabled" can be easily >defined using XSD or RELAX NG. >=20 Fair enough. >There can still be two different capabilities: simple (true/false) and >complex (XPath). True again, though I'd rather one capability with features... >The NMS can present a simple UI, e.g. a calendar widget, and just >construct corresponding XPath expressions. Yes, if the NMS is only exporting config to the device, but I was actually thinking about the NMS trying to import some config *another* client set, and then trying to parse the XPath so that it could present it in the UI - that seems hard... >Nobody wants to repeatedly write such awkward expressions. What I had in >mind was a function that extends XPath, something like > > "yang:time-before(/sys:system/sys:clock/sys:current-datetime, > '2013-03-05T14:02:45+01:00')" I see, but can you try to make an XPath mimic the "M-F 9-5" example with custom-functions to help make it usable? I'm not sure, but would we first capture a couple variables: dow=3Dyang:day-of-week(/sys:system/sys:clock/sys:current-datetime) tod=3Dyang:time-of-day(/sys:system/sys:clock/sys:current-datetime) And then construct a boolean expressions? ("Monday"<=3D$doy and $dow<=3D"Friday") and (9:00<=3D$tod and $tod<=3D17:= 00) From andy@yumaworks.com Tue Mar 5 14:12:48 2013 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 4267811E8106 for ; Tue, 5 Mar 2013 14:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.828 X-Spam-Level: X-Spam-Status: No, score=-1.828 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ijdao9wAN-dj for ; Tue, 5 Mar 2013 14:12:47 -0800 (PST) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id AADC111E809C for ; Tue, 5 Mar 2013 14:12:47 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id k10so8543284iea.33 for ; Tue, 05 Mar 2013 14:12:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=TBaJFMTrlV0IEA42GX2P+7nnldvGh4vwuRsyb/8QWm4=; b=Mbst3bx+7WZ4mWH2/jCiZx0j9vnP/eHzwlKlJVr+FtUpNXJss/YV2JNIBXRDL2IWJy MzPWK8dhotchhs5o9phN03awDAe62mN3P+CHFEFjfMun8WHZBYwpwKg8tmZj9bv7699L Cg7SKgKhpjleDx4GubU22d00xSJ8ZQLso+Dx+d9AkJ2txNWtQCIOgRTXWMXuARdJw/sS shZFrLmqtJxKvMVelwAkObtQBGBL3fPLUveExpIoeV1436LF8ruueW5UI0uNACSUqSwJ TF+z9WGSjOaTMqp+9ZfL7VqhMzzsXspWF+EdUu8DdUm/dm0Lx5lQzXr/cdg8NklfeL97 iu4A== MIME-Version: 1.0 X-Received: by 10.50.17.131 with SMTP id o3mr8089548igd.112.1362521566941; Tue, 05 Mar 2013 14:12:46 -0800 (PST) Received: by 10.231.93.6 with HTTP; Tue, 5 Mar 2013 14:12:46 -0800 (PST) In-Reply-To: References: Date: Tue, 5 Mar 2013 14:12:46 -0800 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQn+VVo5zh8r3bJTZ3+sPhs4ZAjoXQuUB7o+X5VYv0qaiJ9FIE5iksP0VRTUwH3rUjvarLXM Cc: "netconf@ietf.org" Subject: Re: [Netconf] draft-kwatsen-conditional-enablement-00 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, 05 Mar 2013 22:12:48 -0000 On Tue, Mar 5, 2013 at 1:26 PM, Kent Watsen wrote: > > HI Andy, > > I don't fully understand some of your comments... > > >>I think a rule-based approach scales much better > > Scale better on which axis? All the solutions I can think of seem nearly > equal from a scaling perspective... > I don't agree. The amount of network and server processing needed to handle policy embedded in each data node is relative to the number of nodes. A pattern or XPath expression can match a potentially unlimited number of nodes with the same 1 line expression. A rule-based approach moves the application of policy to the database to be a server implementation issue, allowing more flexibility which might produce better performance. > > >> and also works better >>if there are multiple manager apps setting config, but maybe not all apps >>have access to the policy config or know how to set the right policy. > > I don't understand - whatever syntax we choose would have to be understood > by all clients, if the device-advertizes support for this ability. How > would using rulebases make this any easier? > Access to the rule-base that controls the enable property for object X is different than access to object X directly. IMO separating them allows for more deployment scenarios. > > >>I would much rather be able to update the policy for 100,000 interfaces >>all at once, without requiring a massive to do that. >>Also there will be a lot of redundant verbose monitoring info with >>these attributes. > > > Do you mean that you rather a client set a temporal-policy on each of a > 100,000 interfaces once, than having the client set/unset the settings > remotely? In other words, you like the idea of temporal config? > > Wildcards can match N instances with 1 XPath expression. I would rather provide 1 rule that allowed the server to apply the policy internally however it wants to implement it. I don't know if I like moving temporal config to the server at the object level. Perhaps named sub-tree patches (e.g. business-hours-cfg and after-hours-cfg) might be more user-friendly. > >>my rulebase example >>I think this is better than sending 100,000 'enabled' attributes to the >>server, >>especially since changing policy rules happens much less often than >>changing config. > > > Agreed, sending temporal-config is less chatty (and more reflective of > what the client really wants) than having the client flipping settings > themselves. > > I think that your 'enabled' comment above regards only using what the > draft referred to as "simple" expressions (i.e. enabled="true" or > enabled="false"). The draft also described temporal-expressions, in which > case they'd be comparable to the rulebase example I gave. > I saw that -- I don't want a copy of a rule in every leaf. I want XPath expressions that can describe an arbitrarily large node-set. > > Thanks, > Kent > > Andy From kwatsen@juniper.net Tue Mar 5 15:39:47 2013 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 C29E121F859A for ; Tue, 5 Mar 2013 15:39:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.392 X-Spam-Level: X-Spam-Status: No, score=-3.392 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EoGSf0WYHv9e for ; Tue, 5 Mar 2013 15:39:47 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 2365221F8574 for ; Tue, 5 Mar 2013 15:39:47 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUTaCQ6icnX2a1U5gjiUOmk/M8gPV81Pf@postini.com; Tue, 05 Mar 2013 15:39:47 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 5 Mar 2013 15:38:42 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Tue, 5 Mar 2013 15:38:41 -0800 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.186) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 5 Mar 2013 15:41:36 -0800 Received: from mail189-ch1-R.bigfish.com (10.43.68.232) by CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id 14.1.225.23; Tue, 5 Mar 2013 23:38:41 +0000 Received: from mail189-ch1 (localhost [127.0.0.1]) by mail189-ch1-R.bigfish.com (Postfix) with ESMTP id DC1A44402D5 for ; Tue, 5 Mar 2013 23:38:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT002.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -2 X-BigFish: PS-2(zz111aI1521Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzzz2dh2a8h668h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1155h) Received: from mail189-ch1 (localhost.localdomain [127.0.0.1]) by mail189-ch1 (MessageSwitch) id 1362526703567989_514; Tue, 5 Mar 2013 23:38:23 +0000 (UTC) Received: from CH1EHSMHS037.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.251]) by mail189-ch1.bigfish.com (Postfix) with ESMTP id 817C160045; Tue, 5 Mar 2013 23:38:23 +0000 (UTC) Received: from CH1PRD0511HT002.namprd05.prod.outlook.com (157.56.245.197) by CH1EHSMHS037.bigfish.com (10.43.69.246) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 5 Mar 2013 23:38:23 +0000 Received: from CH1PRD0511MB407.namprd05.prod.outlook.com ([169.254.5.117]) by CH1PRD0511HT002.namprd05.prod.outlook.com ([10.255.159.37]) with mapi id 14.16.0275.006; Tue, 5 Mar 2013 23:38:22 +0000 From: Kent Watsen To: Ladislav Lhotka , Andy Bierman Thread-Topic: [Netconf] draft-kwatsen-conditional-enablement-00 Thread-Index: AQHOFGyhBDGXg9PhXkKLEOJGTSvqqZiMvHOAgAihugCAAE9VgIAAWAOAgAAKp4CAARERgIAAVyEA Date: Tue, 5 Mar 2013 23:38:22 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.255.159.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <4B7ACA414C27964881EF2DFB32D8C594@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%NIC.CZ$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%YUMAWORKS.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "netconf@ietf.org" Subject: Re: [Netconf] draft-kwatsen-conditional-enablement-00 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, 05 Mar 2013 23:39:47 -0000 >IMO, one option would be to have the candidate config represented not as >a clone of running with modifications but rather as a sequence of >patches. Then various rules/conditions could be specified as attributes >of each patch - when it should be applied etc. At commit, all >unconditional patches would be immediately applied and the >conditional/termporal ones put on hold. If I understand you correctly, you mean that the "running datastore" would always contain the evaluated temporal-config? So, for instance, if something is set "M-F 9-5", it would show up in running config only during those times and not otherwise? This is an interesting approach, as it enables the "running" datastore to be validated by its YANG module without the YANG-validator needing to process any expressions, but I wonder if it's a good idea, since the running config wouldn't represent the full/persisted config anymore - thoughts? Thanks again, Kent From lhotka@nic.cz Tue Mar 5 23:49:11 2013 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 BE94C21F852C for ; Tue, 5 Mar 2013 23:49:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.246 X-Spam-Level: X-Spam-Status: No, score=-1.246 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhYKeK4QyhRD for ; Tue, 5 Mar 2013 23:49:11 -0800 (PST) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8E221F852A for ; Tue, 5 Mar 2013 23:49:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id DF0BB5404CC; Wed, 6 Mar 2013 08:49:04 +0100 (CET) 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 MHiNozJUcC6W; Wed, 6 Mar 2013 08:48:57 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 1DCF154024C; Wed, 6 Mar 2013 08:48:52 +0100 (CET) From: Ladislav Lhotka To: Kent Watsen , Andy Bierman In-Reply-To: References: User-Agent: Notmuch/0.15.1+15~gd037040 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Date: Wed, 06 Mar 2013 08:48:52 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "netconf@ietf.org" Subject: Re: [Netconf] draft-kwatsen-conditional-enablement-00 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, 06 Mar 2013 07:49:11 -0000 Kent Watsen writes: >>IMO, one option would be to have the candidate config represented not as >>a clone of running with modifications but rather as a sequence of >>patches. Then various rules/conditions could be specified as attributes >>of each patch - when it should be applied etc. At commit, all >>unconditional patches would be immediately applied and the >>conditional/termporal ones put on hold. > > If I understand you correctly, you mean that the "running datastore" would > always contain the evaluated temporal-config? So, for instance, if > something is set "M-F 9-5", it would show up in running config only during > those times and not otherwise? Simply put, the conditions would be a property of an edit-config, not of a data node in the datastore. Such an edit-config would be similar to a cron job. Your "M-F 9-5" example could be implemented as two edits: one that enables the item on workdays at 9am and another that disables it at 5pm. In fact, this by itself doesn't require any changes to candidate, it could be an independent facility. > > This is an interesting approach, as it enables the "running" datastore to > be validated by its YANG module without the YANG-validator needing to > process any expressions, but I wonder if it's a good idea, since the > running config wouldn't represent the full/persisted config anymore - > thoughts? I think the running config would still show exactly the current configuration, and the client could also view the "cron table". Lada > > Thanks again, > Kent > > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Wed Mar 6 00:06:50 2013 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 B27D111E80D1 for ; Wed, 6 Mar 2013 00:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.224 X-Spam-Level: X-Spam-Status: No, score=-1.224 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XInep8g4f13C for ; Wed, 6 Mar 2013 00:06:50 -0800 (PST) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 1D04C21F867D for ; Wed, 6 Mar 2013 00:06:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 4D29C5404CC; Wed, 6 Mar 2013 09:06:49 +0100 (CET) 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 AbPkLVyTlb2R; Wed, 6 Mar 2013 09:06:42 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 7784D54024C; Wed, 6 Mar 2013 09:06:42 +0100 (CET) From: Ladislav Lhotka To: Kent Watsen , Andy Bierman In-Reply-To: References: User-Agent: Notmuch/0.15.1+15~gd037040 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Date: Wed, 06 Mar 2013 09:06:39 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "netconf@ietf.org" Subject: Re: [Netconf] draft-kwatsen-conditional-enablement-00 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, 06 Mar 2013 08:06:50 -0000 Kent Watsen writes: ... > >>The NMS can present a simple UI, e.g. a calendar widget, and just >>construct corresponding XPath expressions. > > Yes, if the NMS is only exporting config to the device, but I was actually > thinking about the NMS trying to import some config *another* client set, > and then trying to parse the XPath so that it could present it in the UI - > that seems hard... > Yes, I see. > > >>Nobody wants to repeatedly write such awkward expressions. What I had in >>mind was a function that extends XPath, something like >> >> "yang:time-before(/sys:system/sys:clock/sys:current-datetime, >> '2013-03-05T14:02:45+01:00')" > > I see, but can you try to make an XPath mimic the "M-F 9-5" example with > custom-functions to help make it usable? > > I'm not sure, but would we first capture a couple variables: > > dow=yang:day-of-week(/sys:system/sys:clock/sys:current-datetime) > tod=yang:time-of-day(/sys:system/sys:clock/sys:current-datetime) > > And then construct a boolean expressions? > > ("Monday"<=$doy and $dow<="Friday") and (9:00<=$tod and $tod<=17:00) This is pretty much impossible with XPath 1. Lada > > > > > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mehmet.ersue@nsn.com Thu Mar 7 08:11:39 2013 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 D812E21F898A for ; Thu, 7 Mar 2013 08:11:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id woujjtpJFxBZ for ; Thu, 7 Mar 2013 08:11:35 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 9D42D21F88F0 for ; Thu, 7 Mar 2013 08:11:16 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r27GBFMK030331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 7 Mar 2013 17:11:15 +0100 Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r27GBFI3017094 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 7 Mar 2013 17:11:15 +0100 Received: from DEMUHTC008.nsn-intra.net (10.159.42.39) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 7 Mar 2013 17:11:14 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.216]) by DEMUHTC008.nsn-intra.net ([10.159.42.39]) with mapi id 14.02.0328.009; Thu, 7 Mar 2013 17:11:14 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: Functional Analysis of I2RS Thread-Index: AQHOGnn+k429oeElm0eCnjtVNnFO1JiaZ2oA Date: Thu, 7 Mar 2013 16:11:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.118] Content-Type: multipart/mixed; boundary="_004_E4DE949E6CE3E34993A2FF8AE79131F8061DDADEMUMBX005nsnintr_" MIME-Version: 1.0 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: 34733 X-purgate-ID: 151667::1362672675-00001023-E631E46F/0-0/0-0 Subject: [Netconf] FW: Functional Analysis of I2RS 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, 07 Mar 2013 16:11:40 -0000 --_004_E4DE949E6CE3E34993A2FF8AE79131F8061DDADEMUMBX005nsnintr_ Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F8061DDADEMUMBX005nsnintr_" --_000_E4DE949E6CE3E34993A2FF8AE79131F8061DDADEMUMBX005nsnintr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Any comments? Mehmet From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of ext= Alia Atlas Sent: Wednesday, March 06, 2013 3:51 PM To: i2rs@ietf.org Subject: [i2rs] Functional Analysis of I2RS As you may have seen from the planned I2RS agenda, Ed and I are planning on= having two significant discussions during the WG. These are to help deve= lop ideas and consensus around what types of use-cases we have (or need) an= d around what types of functionality (new or new combinations) that is need= ed to support those use-cases. We have a deadline of THIS JULY to publish a high-level architecture. I ex= pect that the discussion of the functional analysis of i2rs will drive what= belongs in that architecture. Please come to the meeting with your though= ts, ideas, and concerns well thought through so we can have a very producti= ve meeting. Towards that end, I am including in this email a list of the features whose= combination I believe are driving the various new use-cases. These featur= es come from the following drafts and I would strongly encourage everyone w= ho is participating in the discussion to READ them beforehand, since the fe= ature description given is, of necessity, merely a short-hand that lacks th= e details in the drafts. Note that the drafts may, of course, have differ= ences between them. The drafts are: http://tools.ietf.org/id/draft-ward-i2rs-framework-00.txt http://tools.ietf.org/id/draft-atlas-i2rs-policy-framework-00.txt http://tools.ietf.org/html/draft-rfernando-irs-framework-requirement The list of features I am sending is a first pass. I might have missed som= e that are in the drafts. I may not have included one that you think is ne= eded (whether in the drafts or not). Please bring those up. At the end of= discussions, we hope to have a list of agreed upon new functionality - AND= pointers to the use-cases that explain why and how they are needed. The = use-cases should be specific cases of those in the charter (though for futu= re-thinking arguments sake, key new features could also be discussed). So - here's what I see as new features or combinations. 1. Support multi-headed control. This drives (at least) three sub-fe= atures. a. I2RS agent-based arbitration: I2RS uses policy associated with cl= ients/roles to determine which state to install. Policy need not just be l= ast-to-arrive (as with CLI/NetConf). This gives a way to handle/resolve co= nflicts when multiple clients touch the same configuration. b. Client Ownership: Written state is tracked by client who installed= it (or owns it). This determines which client can delete it and, for some= cases, indicates which client can modify it (for example, a sub-tree with = multiple attributes) versus simply delete/replace it. c. Notifications when written state changes: An application can lear= n when its written state is overwritten by another client. d. Optionally garbage collect ephemeral state when that client goes aw= ay. e. RELATED USE-CASES: i. CLI = writes something and an i2rs client wants to write the same data or vice ve= rsa. ii. 2 cli= ents want to use ACLs to direct the same traffic-flow (one client policy-ro= utes large flows and the second client identifies suspicious flows and dire= cts them to a DoS mitigation box) - described in draft-atlas-i2rs-policy-fr= amework-00.txt 2. Filtered thresholded subscriptions for notifications: Network App= lications use notifications to learn about the network in a push model that= can be more responsive and scale better than a pull model. Such events m= ight be everything from a link over a particular threshold to a next-hop ch= anging on a route of interest to a route being successfully installed into = the forwarding plane. 3. Different Operation Models: a. Persistence: permanent survives reboots & ephemeral doesn't b. Start-time modes - immediate/temporal/triggered c. State Expiration - unbounded or temporal 4. Standard data-models for read/write: some may already be in progre= ss in netmod (if YANG ends up being the selected data-modeling language) a. RIB interactions: static routes, redistribution to other protocol= s, varying admin-distance, etc. b. BGP policy c. IGP local policy: local link metrics, attached prefixes, etc. d. PIM local policy: local listeners, etc e. topology f. Etc - based on use-cases: framework suggests a number of differen= t areas 5. Client limited authorization: Network applications have limited a= uthorization to both read and write based upon role. In particular, for to= pology, a client should be able to learn a subset of topology and not need = very high trust/testing to learn. (e.g. IGPs may provide active topology, = but peers must be trusted & tested not to add in or modify data owned by ot= her network elements). 6. Expose topology at different abstraction layers a. Service topologies (i.e. points of presence and connections) b. VPN topologies c. Potential/previously active links? 7. Multiple transport sessions: Allows multiple senders and receivers= on the network element and on the client side. Allows different levels of= encryption, replay, etc. as appropriate for the data exchange. a. USE-CASE: Sending lots of notifications (statistics, analytics) f= rom line-cards directly. 8. Client has ability to prioritize its own operations: This supports= ASAP vs. in-flight on a single transport channel as well as providing an a= id for sending operations on multiple channels. 9. Role-based Client Identity not tied to a transport : A single net= work application can be distributed across multiple devices and for recover= y, it's important for an application to identify as a particular client, ev= en with a different IP address, different TCP session, etc. 10. Speed of programmatic interface - ability to react to operations in s= ub-second times. Fast is hard to tie down to a particular feature, but it= clearly plays a role in what kinds of use-cases are possible. Any suggest= ions on how to better describe this would be useful. Other functionality that isn't "new" but we do need to decide upon are gene= rally things like: i. Atomic operations: All the data sent to be read or w= ritten in a single operation is done only if all parts can be done (i.e. wr= itten). This may have size limitations to be discussed. It's not quite a = full transaction model, where a client can send multiple operations and an = explicit done. Exact details of what this means need to be specified. ii. Read Locks/Claiming Ownership: For data that can be = written, a client may need to take ownership to prevent that data from bein= g changed (by a lower precedence client). An example would be where a clie= nt makes a decision to write X based on a piece of data being Y (classic re= ad and increment by multiple writers). iii. Rollback or expiring an operation: Is rollback done = by the client (my assumption)? When an operation expires, does the state g= o back to either the default or the next highest client's stored operation = (which might be CLI)? Please think and then jump in and start talking! Regards, Alia --_000_E4DE949E6CE3E34993A2FF8AE79131F8061DDADEMUMBX005nsnintr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Any comments?

 

Mehmet

 

From: i2rs-bou= nces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of ext Alia Atlas
Sent: Wednesday, March 06, 2013 3:51 PM
To: i2rs@ietf.org
Subject: [i2rs] Functional Analysis of I2RS

 

As you may have seen from the planned I2RS agenda, E= d and I are planning on having two significant discussions during the WG.&n= bsp;  These are to help develop ideas and consensus around what types = of use-cases we have (or need) and around what types of functionality (new or new combinations) that is needed to support= those use-cases.

 

We have a deadline of THIS JULY to publish a high-le= vel architecture.  I expect that the discussion of the functional anal= ysis of i2rs will drive what belongs in that architecture.  Please com= e to the meeting with your thoughts, ideas, and concerns well thought through so we can have a very productive meeting= .

 

Towards that end, I am including in this email a lis= t of the features whose combination I believe are driving the various new u= se-cases.  These features come from the following drafts and I would s= trongly encourage everyone who is participating in the discussion to READ them beforehand, since the feature description g= iven is, of necessity, merely a short-hand that lacks the details in the dr= afts.   Note that the drafts may, of course, have differences bet= ween them.  The drafts are:

 

http://tools.ietf.org/id/dra= ft-ward-i2rs-framework-00.txt

http://tools.ietf.or= g/id/draft-atlas-i2rs-policy-framework-00.txt

http://tools.ietf= .org/html/draft-rfernando-irs-framework-requirement

 

The list of features I am sending is a first pass.&n= bsp; I might have missed some that are in the drafts.  I may not have = included one that you think is needed (whether in the drafts or not). = Please bring those up.  At the end of discussions, we hope to have a list of agreed upon new functionality – AND pointe= rs to the use-cases that explain why and how they are needed.   T= he use-cases should be specific cases of those in the charter (though for f= uture-thinking arguments sake, key new features could also be discussed).

 

So – here’s what I see as new features o= r combinations.

 

1.     &= nbsp; Support multi-headed control.  This drives (at= least) three sub-features.

a.       I2RS agent-based arbitration:  I2RS uses polic= y associated with clients/roles to determine which state to install.  = Policy need not just be last-to-arrive (as with CLI/NetConf).  This gi= ves a way to handle/resolve conflicts when multiple clients touch the same configuration.

b.      Client Ownership:  Written state is tracked by= client who installed it (or owns it).  This determines which client c= an delete it and, for some cases, indicates which client can modify it (for= example, a sub-tree with multiple attributes) versus simply delete/replace it.

c.       Notifications when written state changes:  An = application can learn when its written state is overwritten by another clie= nt.

d.      Optionally garbage collect ephemeral state when tha= t client goes away.

e.        RELATED USE-CASES:  

       =             &nb= sp;            =             &nb= sp;            =       i.  = ;    CLI writes something and an i2r= s client wants to write the same data or vice versa.

       =             &nb= sp;            =             &nb= sp;            =     ii. &nbs= p;    2 clients want to use ACLs to = direct the same traffic-flow (one client policy-routes large flows and the = second client identifies suspicious flows and directs them to a DoS mitigat= ion box) – described in draft-atlas-i2rs-policy-framework-00.txt

2.     &= nbsp; Filtered thresholded subscriptions for notification= s:  Network Applications use notifications to learn about the network = in a push model that can be more responsive and scale better than a pull mo= del.   Such events might be everything from a link over a particular threshold to a next-hop changing on a route = of interest to a route being successfully installed into the forwarding pla= ne.

3.     &= nbsp; Different Operation Models:

a.       Persistence:  permanent survives reboots = & ephemeral doesn’t

b.      Start-time modes – immediate/temporal/trigger= ed

c.       State Expiration – unbounded or temporal=

4.     &= nbsp; Standard data-models for read/write: some may alrea= dy be in progress in netmod (if YANG ends up being the selected data-modeli= ng language)

a.       RIB interactions:  static routes, redistributi= on to other protocols, varying admin-distance, etc.

b.      BGP policy

c.       IGP local policy:  local link metrics, attache= d prefixes, etc.

d.      PIM local policy: local listeners, etc

e.      topology 

f.      &nbs= p; Etc – based on use-cases: framework suggests = a number of different areas

5.     &= nbsp; Client limited authorization:  Network applica= tions have limited authorization to both read and write based upon role.&nb= sp; In particular, for topology, a client should be able to learn a subset = of topology and not need very high trust/testing to learn.  (e.g. IGPs may provide active topology, but peers must be = trusted & tested not to add in or modify data owned by other network el= ements).

6.     &= nbsp; Expose topology at different abstraction layers

a.       Service topologies (i.e. points of presence and con= nections)

b.      VPN topologies

c.       Potential/previously active links?

7.     &= nbsp; Multiple transport sessions: Allows multiple sender= s and receivers on the network element and on the client side.  Allows= different levels of encryption, replay, etc. as appropriate for the data e= xchange.

a.       USE-CASE:  Sending lots of notifications (stat= istics, analytics) from line-cards directly.

8.     &= nbsp; Client has ability to prioritize its own operations= : This supports ASAP vs. in-flight on a single transport channel as well as= providing an aid for sending operations on multiple channels.

9.     &= nbsp; Role-based Client Identity not tied to a transport = :  A single network application can be distributed across multiple dev= ices and for recovery, it’s important for an application to identify = as a particular client, even with a different IP address, different TCP session, etc.

10.   Speed of programmatic interface – ability to = react to operations in sub-second times. = ;  Fast is hard to tie down to a particular feature, but it clear= ly plays a role in what kinds of use-cases are possible.  Any suggesti= ons on how to better describe this would be useful.

 

Other functionality that isn’t “new̶= 1; but we do need to decide upon are generally things like:

       =   i.  = ;          Atomic operations: All the data sent to be read or written in a single= operation is done only if all parts can be done (i.e. written).  This= may have size limitations to be discussed.  It’s not quite a full transaction model, where a= client can send multiple operations and an explicit done.   Exac= t details of what this means need to be specified.

       ii. &nbs= p;          Read Locks/Claiming Ownership:  For data that can be written, a = client may need to take ownership to prevent that data from being changed (= by a lower precedence client).  An example would be where a client makes a decision to write X based on a = piece of data being Y (classic read and increment by multiple writers).

      iii. &nb= sp;          Rollback or expiring an operation:  Is rollback done by the cli= ent (my assumption)?  When an operation expires, does the state go bac= k to either the default or the next highest client’s stored operation (which might be CLI)?

 

Please think and then jump in and start talking!

 

Regards,

Alia

--_000_E4DE949E6CE3E34993A2FF8AE79131F8061DDADEMUMBX005nsnintr_-- --_004_E4DE949E6CE3E34993A2FF8AE79131F8061DDADEMUMBX005nsnintr_ Content-Type: text/plain; name="ATT00002.txt" Content-Description: ATT00002.txt Content-Disposition: attachment; filename="ATT00002.txt"; size=127; creation-date="Wed, 06 Mar 2013 14:58:05 GMT"; modification-date="Wed, 06 Mar 2013 14:58:05 GMT" Content-ID: Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmkycnMgbWFp bGluZyBsaXN0DQppMnJzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2kycnMNCg== --_004_E4DE949E6CE3E34993A2FF8AE79131F8061DDADEMUMBX005nsnintr_-- From mehmet.ersue@nsn.com Thu Mar 7 22:45:11 2013 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 3CD2E21F866E for ; Thu, 7 Mar 2013 22:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXsnnaxz9uel for ; Thu, 7 Mar 2013 22:45:09 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id C32FD21F863C for ; Thu, 7 Mar 2013 22:44:53 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r286iqP2007961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 8 Mar 2013 07:44:52 +0100 Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r286ino5029037 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 8 Mar 2013 07:44:51 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.216]) by DEMUHTC003.nsn-intra.net ([10.159.42.34]) with mapi id 14.02.0328.009; Fri, 8 Mar 2013 07:44:49 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: WGLC Reminder WAS:RE: [Netconf] WGLC for draft-ietf-netconf-rfc5539bis-02 Thread-Index: Ac2Saa4rBrh95h0ERw6mxs3XcPWMZSDT23Dg///y5QD/89X1sA== Date: Fri, 8 Mar 2013 06:44:48 +0000 Message-ID: References: <20130228135308.GA85320@elstar.local> In-Reply-To: <20130228135308.GA85320@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.125] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: 1498 X-purgate-ID: 151667::1362725092-00001023-EB33C9B3/0-0/0-0 Subject: [Netconf] WGLC Reminder WAS:RE: WGLC for draft-ietf-netconf-rfc5539bis-02 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, 08 Mar 2013 06:45:11 -0000 Dear Netconf WG, please review the RFC5539bis document and provide comments by March 14, 201= 2. It would be useful if we can discuss some of your comments already in the N= etconf session on March 11, 2012.=20 Please consider also to give input on the open issues in appendix A.1. Thank you. Mehmet=20 > -----Original Message----- > From: ext Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university= .de] > Sent: Thursday, February 28, 2013 2:53 PM > To: Ersue, Mehmet (NSN - DE/Munich) > Cc: netconf@ietf.org > Subject: Re: [Netconf] WGLC for draft-ietf-netconf-rfc5539bis-02 >=20 > On Thu, Feb 28, 2013 at 01:44:12PM +0000, Ersue, Mehmet (NSN - DE/Munich)= wrote: > > Dear NETCONF WG, > > > > rfc5539bis authors submitted the document draft-ietf-netconf-rfc5539bis= -02 > > addressing the issues we discussed in the last meeting > > (http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-02). > > > > This is a new WGLC for the RFC5539bis document, which is going to be > > published on the standards track and will obsolete RFC 5539. > > > > Please review the document and comment by March 14, 2013 (any > > timezone). Thank you. >=20 > Input on the open issues (appendix A.1) would also be very welcome. >=20 > /js >=20 > -- > 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 Mon Mar 11 07:13:14 2013 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 83B3721F88A1 for ; Mon, 11 Mar 2013 07:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=-0.369, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4i6xCUkjN8NY for ; Mon, 11 Mar 2013 07:13:14 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 1DEF621F87FB for ; Mon, 11 Mar 2013 07:13:14 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id 9so4812987iec.4 for ; Mon, 11 Mar 2013 07:13:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:content-transfer-encoding:x-gm-message-state; bh=cd2BqjNLzGw85z2Wxz0P46D9yHppqRXpe2VyEEr1S9s=; b=lCpVAi9drZpmAcLZZcxSqPssdfPecjySlj07/meXTdxWcJE9gVkNOxK1i5leecAmqS O6rSFV/ytijgVTotMB7btLNBStE3d3Yw6L7zLKnjCVob17EOMwmZc6E+293rPKGH1ex+ viniblhF34qIeGeACsPZ1aILxlMCM03nhBfS6out3i0vsmwWDMScwMaGVtVyLra5XDL9 tb+c37pGHz84NalLsNn+2FmZSKaFcEJ4wuzOsxfIObgrOlmeXyKN249Z1e/D43oAAFkq oWOb8HsdE50Y25jqUm0ssbx5XWBnzE2fIv38WgEMTgRuHBvHtmN0NwnTok1/NwSWei57 ipaQ== MIME-Version: 1.0 X-Received: by 10.50.219.168 with SMTP id pp8mr7415935igc.57.1363011193727; Mon, 11 Mar 2013 07:13:13 -0700 (PDT) Received: by 10.231.93.6 with HTTP; Mon, 11 Mar 2013 07:13:13 -0700 (PDT) Date: Mon, 11 Mar 2013 07:13:13 -0700 Message-ID: From: Andy Bierman To: Netconf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkTveFf3d+9q8zUnzI5ziCYowu/sYtyHOjitIb1Rx5viJySRtNszzCTNnziNdPJiD9l0FOb Subject: [Netconf] =?utf-8?b?USBvbiBjZXJ04oiSdG/iiJJzZWN1cml0eeKIkm5hbWUg?= =?utf-8?q?key_=28TLS_draft=29?= 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, 11 Mar 2013 14:13:14 -0000 Hi, Sorry if this issues was already discussed.... Curious why this list uses leaf 'id' to order the list entries instead of using "ordered-by user;" leaf id { type uint32; description "The id specifies the order in which the entries in the cert=E2=88=92to=E2=88=92security=E2=88=92name container are searched. = Entries with lower numbers are searched first."; reference "SNMP=E2=88=92TLS=E2=88=92TM=E2=88=92MIB.snmpTlstmCertToTSNID"= ; } Andy From luchuk@snmp.com Mon Mar 11 08:11:10 2013 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 ACFF621F8947 for ; Mon, 11 Mar 2013 08:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.326 X-Spam-Level: X-Spam-Status: No, score=-2.326 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8x2=0.246] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYeufk2y7IyZ for ; Mon, 11 Mar 2013 08:11:10 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 065C921F86E6 for ; Mon, 11 Mar 2013 08:10:59 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id LAA19437; Mon, 11 Mar 2013 11:10:57 -0400 (EDT) Received: (from luchuk@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) id LAA08786; Mon, 11 Mar 2013 11:10:55 -0400 (EDT) Date: Mon, 11 Mar 2013 11:10:55 -0400 (EDT) From: Alan Luchuk Message-Id: <201303111510.LAA08786@adminfs.snmp.com> To: andy@yumaworks.com Cc: netconf@ietf.org Subject: Re: [Netconf] =?utf-8?b?USBvbiBjZXJ04oiSdG/iiJJzZWN1cml0eeKIkm5hbWUg?= =?utf-8?q?key_=28TLS_draft=29?= 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, 11 Mar 2013 15:11:10 -0000 Hello, >Sorry if this issues was already discussed.... >Curious why this list uses leaf 'id' to order the list entries >instead of using "ordered-by user;" > >leaf id { > type uint32; > description > "The id specifies the order in which the entries in the > cert−to−security−name container are searched. Entries > with lower numbers are searched first."; > reference "SNMP−TLS−TM−MIB.snmpTlstmCertToTSNID"; >} To harmonize the data model in draft-ietf-netconf-rfc5539bis-02.txt with the data model in draft-ietf-netmod-snmp-cfg-01.txt. More specifically, to harmonize: - the cert-maps container in the ietf-netconf-tls module in draft-ietf-netconf-rfc5539bis-02.txt; with - the tlstm container in the ietf-snmp-tls submodule in draft-ietf-netmod-snmp-cfg-01.txt. The data model in draft-ietf-netconf-rfc5539bis-01.txt not being harmonized with the data model in the previous verion of draft-ietf-netmod-snmp-cfg was a perceived issue (and unfinished work item) by the NETCONF WG at IETF 85. The two are now harmonized, so this issue could be considered finished by the NETCONF WG. Regards, --Alan ------------------------------------------------------------------------------ Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Senior Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk at snmp.com Knoxville, TN 37920-9716 http://www.snmp.com/ ------------------------------------------------------------------------------ From j.schoenwaelder@jacobs-university.de Mon Mar 11 09:06:27 2013 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 7445D21F8B64 for ; Mon, 11 Mar 2013 09:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.915 X-Spam-Level: X-Spam-Status: No, score=-102.915 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+iCu78dqeiH for ; Mon, 11 Mar 2013 09:06:26 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 26BCC21F8B60 for ; Mon, 11 Mar 2013 09:06:25 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 68E9A20BF5; Mon, 11 Mar 2013 17:06:24 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ZSjjGBQd8Npw; Mon, 11 Mar 2013 17:06:24 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E8D9820BF3; Mon, 11 Mar 2013 17:06:23 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7E7DD24E67B6; Mon, 11 Mar 2013 17:06:36 +0100 (CET) Date: Mon, 11 Mar 2013 17:06:36 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20130311160636.GA62192@elstar.local> Mail-Followup-To: Andy Bierman , Netconf References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Netconf Subject: Re: [Netconf] =?utf-8?b?USBvbiBjZXJ04oiSdG/iiJJzZWN1cml0eeKIkm5hbWUg?= =?utf-8?q?key_=28TLS_draft=29?= 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: Mon, 11 Mar 2013 16:06:27 -0000 On Mon, Mar 11, 2013 at 07:13:13AM -0700, Andy Bierman wrote: > Hi, > > Sorry if this issues was already discussed.... > Curious why this list uses leaf 'id' to order the list entries > instead of using "ordered-by user;" > > leaf id { > type uint32; > description > "The id specifies the order in which the entries in the > cert−to−security−name container are searched. Entries > with lower numbers are searched first."; > reference "SNMP−TLS−TM−MIB.snmpTlstmCertToTSNID"; > } > Alan gave a procedural answer. However we resolve this issue, we need to keep in mind that we have two instantiations of this config snippet, one in a NETCONF document and one in a NETMOD document. And the NETMOD one is inheriting some SNMP history. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mehmet.ersue@nsn.com Mon Mar 11 10:12:24 2013 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 A09BE21F8C00 for ; Mon, 11 Mar 2013 10:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQGZH1PsvGnd for ; Mon, 11 Mar 2013 10:12:24 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 117DF21F8BF6 for ; Mon, 11 Mar 2013 10:12:16 -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 r2BHCFGo021233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 11 Mar 2013 18:12:15 +0100 Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r2BHCFx5013729 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 11 Mar 2013 18:12:15 +0100 Received: from DEMUHTC013.nsn-intra.net (10.159.42.44) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.2.328.9; Mon, 11 Mar 2013 18:12:15 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.216]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.02.0328.009; Mon, 11 Mar 2013 18:12:15 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: Early volunteers as note taker and jabber scribe? Thread-Index: Ac4ee5MnCr6hgsa3RUy8DnlafZP00g== Date: Mon, 11 Mar 2013 17:12:13 +0000 Message-ID: Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: 186 X-purgate-ID: 151667::1363021935-000050C9-83A6FE72/0-0/0-0 Subject: [Netconf] Early volunteers as note taker and jabber scribe? 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, 11 Mar 2013 17:12:24 -0000 Hi All, Before we loose time in the session. Are there any volunteers as note taker and jabber scribe? Please send a note to the co-chairs. Sent from my iPad. Mehmet Ersue From mehmet.ersue@nsn.com Wed Mar 13 07:58:29 2013 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 00F3621F8D8F for ; Wed, 13 Mar 2013 07:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTE4XCB6-Jfs for ; Wed, 13 Mar 2013 07:58:28 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 29B2321F8D62 for ; Wed, 13 Mar 2013 07:58:27 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r2DEwOFp027039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Mar 2013 15:58:24 +0100 Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r2DEwO9Y026556 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Mar 2013 15:58:24 +0100 Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 13 Mar 2013 15:58:23 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.216]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.02.0328.009; Wed, 13 Mar 2013 15:58:23 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: Benoit Claise Thread-Topic: Short Summary of the NETCONF Session at IETF 86 Thread-Index: AQHOH/am6G31PT5X7kKRYotihxIw/Jijsmew Date: Wed, 13 Mar 2013 14:58:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: 1724 X-purgate-ID: 151667::1363186704-00003B04-A7D1246B/0-0/0-0 Cc: "netconf@ietf.org" Subject: [Netconf] Short Summary of the NETCONF Session at IETF 86 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, 13 Mar 2013 14:58:29 -0000 Hi Benoit, below is a summary and action items from the NETCONF WG session on March 11= , 2013 in Orlando, FL, USA. - We had approx. 65 participants in the 1.5 hour NETCONF session, - We reviewed the status of the WG, - We went through the chartered WG item and had a good discussion also on n= on-chartered documents. Status of the documents (http://www.ietf.org/proceedings/86/slides/slides-8= 6-netconf-5.ppt): RFC5539bis (Netconf over TLS) has been updated addressing the issues raised= so far and is currently in WGLC. Main chartered topic was rfc5539bis (Netconf over TLS). Basically the WG ha= s consensus, but the room wanted to add the Call Home mechanism. This must = be confirmed on the WG list. Authors will add text for this and submit a ne= w version. There was also support from the room to resurrect the Call Home mechanism f= or the mandatory transport binding SSH. Kent Watsen volunteered to resurrec= t his draft on Reverse SSH and there were volunteers to review and implemen= t. Question: Would it be OK to have Call Home for the optional TLS transport w= hile not having it for the mandatory SSH transport. Our AD (Benoit) to chec= k this with IESG. Also several other presentations on "NETCONF API", Operational State retrie= val, Conditional Enablement, and Implementation Experience have been held and discussed. We need revisions for at least the= Operational State draft so we can ask the WG to review and comment. We also asked for volunteers to work on the supporting documentation for RF= C advancement. Volunteers to send email to chairs. NetConf and NetMod chairs have planned to meet with I2RS chairs later in th= e week. Bert and Mehmet From kwatsen@juniper.net Wed Mar 13 13:51:44 2013 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 C9BEB11E8103 for ; Wed, 13 Mar 2013 13:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.439 X-Spam-Level: X-Spam-Status: No, score=-3.439 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-C1eggbd0CQ for ; Wed, 13 Mar 2013 13:51:44 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id A851F11E80FE for ; Wed, 13 Mar 2013 13:51:43 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUUDm32R3bNGNZBsr1CZDjBBRP9fG0Zfc@postini.com; Wed, 13 Mar 2013 13:51:43 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 13 Mar 2013 13:40:14 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Wed, 13 Mar 2013 13:40:14 -0700 Received: from DB8EHSOBE027.bigfish.com (213.199.154.188) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 13 Mar 2013 13:49:34 -0700 Received: from mail85-db8-R.bigfish.com (10.174.8.242) by DB8EHSOBE027.bigfish.com (10.174.4.90) with Microsoft SMTP Server id 14.1.225.23; Wed, 13 Mar 2013 20:40:12 +0000 Received: from mail85-db8 (localhost [127.0.0.1]) by mail85-db8-R.bigfish.com (Postfix) with ESMTP id 3EB8CCC0084 for ; Wed, 13 Mar 2013 20:40:12 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.241.149; KIP:(null); UIP:(null); (null); H:BL2PRD0511HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -1 X-BigFish: PS-1(zzc85eh4015Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz18c673h8275bhz2dh2a8h668h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1155h) Received: from mail85-db8 (localhost.localdomain [127.0.0.1]) by mail85-db8 (MessageSwitch) id 1363207210171853_13250; Wed, 13 Mar 2013 20:40:10 +0000 (UTC) Received: from DB8EHSMHS004.bigfish.com (unknown [10.174.8.251]) by mail85-db8.bigfish.com (Postfix) with ESMTP id 1E03FD400B5 for ; Wed, 13 Mar 2013 20:40:10 +0000 (UTC) Received: from BL2PRD0511HT003.namprd05.prod.outlook.com (157.56.241.149) by DB8EHSMHS004.bigfish.com (10.174.4.14) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 13 Mar 2013 20:40:09 +0000 Received: from BL2PRD0511MB397.namprd05.prod.outlook.com ([169.254.9.132]) by BL2PRD0511HT003.namprd05.prod.outlook.com ([10.255.131.38]) with mapi id 14.16.0275.006; Wed, 13 Mar 2013 20:40:00 +0000 From: Kent Watsen To: NetConf Thread-Topic: yang-api comment: decouple protocol and encoding Thread-Index: AQHOICruspPBloJFjUm5lHnQ+QRDrQ== Date: Wed, 13 Mar 2013 20:40:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.255.159.4] Content-Type: multipart/alternative; boundary="_000_CD665C6225F2Dkwatsenjunipernet_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: [Netconf] yang-api comment: decouple protocol and encoding 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, 13 Mar 2013 20:51:44 -0000 --_000_CD665C6225F2Dkwatsenjunipernet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Andy, A follow-up to my comment during the NETCONF meeting, I think we should dec= ouple protocol and encoding. This is easily done for REST APIs, since HTTP's "Accept" and "Content-Type"= header fields are defined for just this purpose. If the client fails to = provide an Accept header, the server needs to default to something. FWIW, = our REST API use to default to JSON but we changed it to XML after receivin= g significant feedback=85 I'd also like to open the floor to alternate encodings for the NETCONF prot= ocol - e.g. Google Protocol Buffers (protobufs) or maybe even binary (raise= d by an I2RS member). For protobufs, we experimented passing a flag in the= RPC indicating that the RPC-reply should be encoded as a Google Protocol B= uffer - it's asymmetric (RPCs are always XML), but effective as we find tha= t most data flows in that direction. That said, we might consider negotiat= ed it at the session-level. Does anyone have interest in alternate data en= codings for NETCONF? Thanks, Kent --_000_CD665C6225F2Dkwatsenjunipernet_ Content-Type: text/html; charset="Windows-1252" Content-ID: <35F3B8287CA701428D5851F38E881BAE@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

Hi Andy,

A follow-up to my comment during the NETCONF meeting, I think we shoul= d decouple protocol and encoding.  

This is easily done for REST APIs, since HTTP's "Accept" and= "Content-Type" header fields are defined for just this purpose. =   If the client fails to provide an Accept header, the server needs to= default to something.  FWIW, our REST API use to default to JSON but we changed it to XML after receiving significant feedback=85

I'd also like to open the floor to alternate encodings for the NETCONF= protocol - e.g. Google Protocol Buffers (protobufs) or maybe even binary (= raised by an I2RS member).  For protobufs, we experimented passing a f= lag in the RPC indicating that the RPC-reply should be encoded as a Google Protocol Buffer - it's asymmetric (RPCs are = always XML), but effective as we find that most data flows in that directio= n.  That said, we might consider negotiated it at the session-level. &= nbsp;Does anyone have interest in alternate data encodings for NETCONF?

Thanks,
Kent

--_000_CD665C6225F2Dkwatsenjunipernet_-- From alex@cisco.com Wed Mar 13 15:00:08 2013 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 3450511E809C for ; Wed, 13 Mar 2013 15:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yz0Tftu7zQuC for ; Wed, 13 Mar 2013 15:00:06 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 51B1911E80A3 for ; Wed, 13 Mar 2013 15:00:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9174; q=dns/txt; s=iport; t=1363212006; x=1364421606; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=GccM+vS0hmd1z66fJgO1EGNn9PRrqX+TWnNhFMDvOEY=; b=MjTTxaojZuvPVbKD7rvfw1BXqBOEarQl0xbVuG3j48nvj4H10x3dOlgc tPUuXUF+Qb1OVHJyGaSUxUGVXihnZYtd6cp3bpEIKC+L45U3/xLnWsGsL n660bzJMpEscjd5iQedVh40HYpttc7qcAjVMn91uQiuQ7QkjGUHdfGAbb U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHn1QFGtJXG8/2dsb2JhbABDhBPAQ4FZFnSCKgEBAQQdEFwCAQgOAwQBAQsdBzIUCQgCBAESCIgMwwMXjl8mEQGCX2EDp1qDCoIo X-IronPort-AV: E=Sophos;i="4.84,840,1355097600"; d="scan'208,217";a="187185781" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 13 Mar 2013 22:00:05 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2DM05VD026317 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Mar 2013 22:00:05 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.147]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Wed, 13 Mar 2013 17:00:05 -0500 From: "Alexander Clemm (alex)" To: Kent Watsen , NetConf Thread-Topic: yang-api comment: decouple protocol and encoding Thread-Index: AQHOICruspPBloJFjUm5lHnQ+QRDrZikKHwg Date: Wed, 13 Mar 2013 22:00:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.167.178] Content-Type: multipart/alternative; boundary="_000_DBC595ED2346914F9F81D17DD5C32B57183E8997xmbrcdx05ciscoc_" MIME-Version: 1.0 Subject: Re: [Netconf] yang-api comment: decouple protocol and encoding 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, 13 Mar 2013 22:00:08 -0000 --_000_DBC595ED2346914F9F81D17DD5C32B57183E8997xmbrcdx05ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FWIW, I think decoupling protocol and encoding makes sense. I am not sure = if the encodings apply to the protocol as a whole, or if should allow them = to apply also just the payload. I.e., do you mean data encodings for YANG,= or for Netconf (or maybe for both)? For example, presumably, a motivation= for a binary protocol includes the desire for efficiency, which may call f= or protocol operations that are lighter-weight than what is supplied by Net= conf (not a criticism on Netconf, just placing the tradeoffs a bit differen= tly - just like REST API is a YANG/REST versus Netconf/REST). I think ther= e are definitely use cases for alternate encoding schemes for the payload, = whether or not Netconf protocol operations are used. --- Alex From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Kent Watsen Sent: Wednesday, March 13, 2013 1:40 PM To: NetConf Subject: [Netconf] yang-api comment: decouple protocol and encoding Hi Andy, A follow-up to my comment during the NETCONF meeting, I think we should dec= ouple protocol and encoding. This is easily done for REST APIs, since HTTP's "Accept" and "Content-Type"= header fields are defined for just this purpose. If the client fails to = provide an Accept header, the server needs to default to something. FWIW, = our REST API use to default to JSON but we changed it to XML after receivin= g significant feedback... I'd also like to open the floor to alternate encodings for the NETCONF prot= ocol - e.g. Google Protocol Buffers (protobufs) or maybe even binary (raise= d by an I2RS member). For protobufs, we experimented passing a flag in the= RPC indicating that the RPC-reply should be encoded as a Google Protocol B= uffer - it's asymmetric (RPCs are always XML), but effective as we find tha= t most data flows in that direction. That said, we might consider negotiat= ed it at the session-level. Does anyone have interest in alternate data en= codings for NETCONF? Thanks, Kent --_000_DBC595ED2346914F9F81D17DD5C32B57183E8997xmbrcdx05ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FWIW, I think decoupling = protocol and encoding makes sense.  I am not sure if the encodings app= ly to the protocol as a whole, or if should allow them to apply also just the payload.  I.e., do you mean data encodings for YANG, or= for Netconf (or maybe for both)?  For example, presumably, a motivati= on for a binary protocol includes the desire for efficiency, which may call= for protocol operations that are lighter-weight than what is supplied by Netconf (not a criticism on Netconf, just placing= the tradeoffs a bit differently – just like REST API is a YANG/REST = versus Netconf/REST).  I think there are definitely use cases for alte= rnate encoding schemes for the payload, whether or not Netconf protocol operations are used. 

--- Alex

 <= /p>

From: netconf-= bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Kent Watsen
Sent: Wednesday, March 13, 2013 1:40 PM
To: NetConf
Subject: [Netconf] yang-api comment: decouple protocol and encoding<= o:p>

 

 

Hi Andy,<= /p>

 

A follow-up to my comment d= uring the NETCONF meeting, I think we should decouple protocol and encoding= .  

 

This is easily done for RES= T APIs, since HTTP's "Accept" and "Content-Type" header= fields are defined for just this purpose.   If the client fails to pr= ovide an Accept header, the server needs to default to something.  FWIW, ou= r REST API use to default to JSON but we changed it to XML after receiving = significant feedback…

 

I'd also like to open the f= loor to alternate encodings for the NETCONF protocol - e.g. Google Protocol= Buffers (protobufs) or maybe even binary (raised by an I2RS member).  For protobufs, we experimented passing a flag in the R= PC indicating that the RPC-reply should be encoded as a Google Protocol Buf= fer - it's asymmetric (RPCs are always XML), but effective as we find that = most data flows in that direction.  That said, we might consider negotiated it at the session-level.  Does any= one have interest in alternate data encodings for NETCONF?

 

Thanks,

Kent

 

--_000_DBC595ED2346914F9F81D17DD5C32B57183E8997xmbrcdx05ciscoc_-- From andy@yumaworks.com Wed Mar 13 15:11:41 2013 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 9B90A21F8632 for ; Wed, 13 Mar 2013 15:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.064 X-Spam-Level: X-Spam-Status: No, score=-2.064 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDV4Ar-6qCJQ for ; Wed, 13 Mar 2013 15:11:41 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 0D61521F85EB for ; Wed, 13 Mar 2013 15:11:40 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id 9so2192586iec.4 for ; Wed, 13 Mar 2013 15:11:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=nYJ0jwKsqkhwDLFqPV+Ls1cG0gneQJSo8RURzCrB/Ic=; b=iKW23j5KlPyFIbFbDXsYULIP4JuP84wWPKJPd+laGGbWyt/egVL+HrDiEK3T9RSOCo I6I8FfZnoetqtMYdr0TmiYPI+Xf/SzP8X3HfPaa/DtiCuuA/Y6TvHBRezSC9Bs81mXh/ OKwu523LNwmbLMM5j7bhwZMR9gZr2ewWxOgoS6FCtsC3eRG+qZIrytAaTARzea/8+ef1 EWxv2W1ftQz0nZDtom/WP+rtZdS36bnxlseHApoK8zjG/z8qV2TWEWKzKCQpjOGaoQW2 oQX2Kqvy7j4QwB/snE/vOF6nO3Wj55FG09nAb5clJyTzEn9wQdZHVZKPgyDD4TyFBTWq eRjw== MIME-Version: 1.0 X-Received: by 10.50.7.69 with SMTP id h5mr716989iga.69.1363212700604; Wed, 13 Mar 2013 15:11:40 -0700 (PDT) Received: by 10.231.93.6 with HTTP; Wed, 13 Mar 2013 15:11:40 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Mar 2013 15:11:40 -0700 Message-ID: From: Andy Bierman To: "Alexander Clemm (alex)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQn2vWywpZGNwB092JlIeZCFKPfOXR95Lrw3j+almpPjRrGA+hqkFkcIGx93z+I4Dq1SHmYh Cc: NetConf Subject: Re: [Netconf] yang-api comment: decouple protocol and encoding 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, 13 Mar 2013 22:11:41 -0000 On Wed, Mar 13, 2013 at 3:00 PM, Alexander Clemm (alex) wr= ote: > FWIW, I think decoupling protocol and encoding makes sense. I am not sur= e > if the encodings apply to the protocol as a whole, or if should allow the= m > to apply also just the payload. I.e., do you mean data encodings for YAN= G, > or for Netconf (or maybe for both)? For example, presumably, a motivatio= n > for a binary protocol includes the desire for efficiency, which may call = for > protocol operations that are lighter-weight than what is supplied by Netc= onf > (not a criticism on Netconf, just placing the tradeoffs a bit differently= =E2=80=93 > just like REST API is a YANG/REST versus Netconf/REST). I think there ar= e > definitely use cases for alternate encoding schemes for the payload, whet= her > or not Netconf protocol operations are used. IMO using multiple encodings in the same message is too complicated. In my implementation, the encoding is negotiated at the same control point as the framing -- after the message in base:1.0 framing in XML enco= ding is processed. As the session startup gets more complicated, I realized that Teramoto is r= ight and a debug comment (XML comment) should be sent with the "session-dropped-reason". That way a client can find out if it was unsupported encoding vs. unsupported base version that caused the session to be rejected. > --- Alex Andy > > > > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behal= f > Of Kent Watsen > Sent: Wednesday, March 13, 2013 1:40 PM > To: NetConf > Subject: [Netconf] yang-api comment: decouple protocol and encoding > > > > > > Hi Andy, > > > > A follow-up to my comment during the NETCONF meeting, I think we should > decouple protocol and encoding. > > > > This is easily done for REST APIs, since HTTP's "Accept" and "Content-Typ= e" > header fields are defined for just this purpose. If the client fails to > provide an Accept header, the server needs to default to something. FWIW= , > our REST API use to default to JSON but we changed it to XML after receiv= ing > significant feedback=E2=80=A6 > > > > I'd also like to open the floor to alternate encodings for the NETCONF > protocol - e.g. Google Protocol Buffers (protobufs) or maybe even binary > (raised by an I2RS member). For protobufs, we experimented passing a fla= g > in the RPC indicating that the RPC-reply should be encoded as a Google > Protocol Buffer - it's asymmetric (RPCs are always XML), but effective as= we > find that most data flows in that direction. That said, we might conside= r > negotiated it at the session-level. Does anyone have interest in alterna= te > data encodings for NETCONF? > > > > Thanks, > > Kent > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From phil@juniper.net Thu Mar 14 06:14:46 2013 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 0403921F8FE8 for ; Thu, 14 Mar 2013 06:14:46 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bH2BE9CdUOmb for ; Thu, 14 Mar 2013 06:14:45 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 497C521F8FEC for ; Thu, 14 Mar 2013 06:14:40 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUUHNQA3eJjMdFw36/zUvLMsdhDoJiVUR@postini.com; Thu, 14 Mar 2013 06:14:45 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, 14 Mar 2013 06:13:00 -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 r2EDCx346529; Thu, 14 Mar 2013 06:13:00 -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 r2EDC33d013382; Thu, 14 Mar 2013 09:12:23 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201303141312.r2EDC33d013382@idle.juniper.net> To: Andy Bierman In-Reply-To: Date: Thu, 14 Mar 2013 09:12:03 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: NetConf Subject: Re: [Netconf] yang-api comment: decouple protocol and encoding 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, 14 Mar 2013 13:14:46 -0000 Andy Bierman writes: >That way a client can find out if it was unsupported encoding vs. >unsupported base version that caused the session to be rejected. It might be better for you to syslog this, so you aren't counting on comment processing/logging in the client and you're support folks can see the error without futzing with the client. Thanks, Phil From j.schoenwaelder@jacobs-university.de Thu Mar 14 06:23:09 2013 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 BCCF621F9096 for ; Thu, 14 Mar 2013 06:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cI3wxwKwkYa for ; Thu, 14 Mar 2013 06:23:05 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0F321F9092 for ; Thu, 14 Mar 2013 06:23:05 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 10B6E20C02; Thu, 14 Mar 2013 14:23:04 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id LauZrg490XWh; Thu, 14 Mar 2013 14:23:03 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9191F20BE5; Thu, 14 Mar 2013 14:23:03 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id EB57C24FC2FF; Thu, 14 Mar 2013 14:23:16 +0100 (CET) Date: Thu, 14 Mar 2013 14:23:16 +0100 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20130314132316.GB17446@elstar.local> Mail-Followup-To: Phil Shafer , Andy Bierman , NetConf References: <201303141312.r2EDC33d013382@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201303141312.r2EDC33d013382@idle.juniper.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: NetConf Subject: Re: [Netconf] yang-api comment: decouple protocol and encoding 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, 14 Mar 2013 13:23:10 -0000 On Thu, Mar 14, 2013 at 09:12:03AM -0400, Phil Shafer wrote: > Andy Bierman writes: > >That way a client can find out if it was unsupported encoding vs. > >unsupported base version that caused the session to be rejected. > > It might be better for you to syslog this, so you aren't counting > on comment processing/logging in the client and you're support folks > can see the error without futzing with the client. > Simply do both. ;-) /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 Mar 14 06:23:30 2013 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 8799A21F909A for ; Thu, 14 Mar 2013 06:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgaiHofS4zs2 for ; Thu, 14 Mar 2013 06:23:30 -0700 (PDT) Received: from mail-ia0-x229.google.com (mail-ia0-x229.google.com [IPv6:2607:f8b0:4001:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 0675A21F9098 for ; Thu, 14 Mar 2013 06:23:29 -0700 (PDT) Received: by mail-ia0-f169.google.com with SMTP id j5so2089274iaf.28 for ; Thu, 14 Mar 2013 06:23:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=lr8rY3s3KSmVQ/xuoXvJg3VLPwWwGLkugsptp/8XuZc=; b=J9Wpc8mNCebhwuTOxi6e8mWx6TkXxBXJlLvHd3K1uHwOEtg0PQCZa6NNmLQ1Tj3mM9 36NE+6V1Fl1rHOHY8k1rwS/9qsJlpVf4JJF7XXDSNcZBiX2/r/B/aWBb2Tj+THFkdCyU 0PPbjC30IG+w7Xi1i/hZVP+vAWW7cm1RuUvdBW2ykSpWmeymJ80D/MJcMUij2Bu33U+v fHbV0oXaewu+/9lWS1Z/cvzjL87Xy9UCiIUeU/vI6wf6d6UgYhzKVXZrPiJqC03q/Yai 17mZPa2mBOJ+NLu+s3n6fmz6vzDxstt39BQlyH6xZjlsWZpBISZE7hvYAVkDmPTWo7jH jkww== MIME-Version: 1.0 X-Received: by 10.50.153.198 with SMTP id vi6mr20615072igb.112.1363267409609; Thu, 14 Mar 2013 06:23:29 -0700 (PDT) Received: by 10.231.93.6 with HTTP; Thu, 14 Mar 2013 06:23:29 -0700 (PDT) In-Reply-To: <201303141312.r2EDC33d013382@idle.juniper.net> References: <201303141312.r2EDC33d013382@idle.juniper.net> Date: Thu, 14 Mar 2013 06:23:29 -0700 Message-ID: From: Andy Bierman To: Phil Shafer Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmE9tmo3bRnVQ0xIM9HmVizLtV1iks+PvBWQD6CNKo8118CDKwZi9BpTCdDcSYunEjaF7vG Cc: NetConf Subject: Re: [Netconf] yang-api comment: decouple protocol and encoding 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, 14 Mar 2013 13:23:30 -0000 Hi Phil, Good point. yangcli code drops PIs and comments and you need to set a fairly high debug trace level to actually see XML comments in the log. My thinking was, if a client developer or operator is having sessions rejected, they would turn on debugging. I think 1 issue that was brought up is that the client developer may not have access to the server logs or server syslog feed. I guess a robust solution would be an actual XML response from the server before dropping the connection. But in the case of improper framing, the server cannot trust what it got and has no choice but to ignore the client and drop the connection. Andy On Thu, Mar 14, 2013 at 6:12 AM, Phil Shafer wrote: > Andy Bierman writes: >>That way a client can find out if it was unsupported encoding vs. >>unsupported base version that caused the session to be rejected. > > It might be better for you to syslog this, so you aren't counting > on comment processing/logging in the client and you're support folks > can see the error without futzing with the client. > > Thanks, > Phil From lhotka@nic.cz Thu Mar 14 07:05:54 2013 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 D69C311E8131 for ; Thu, 14 Mar 2013 07:05:53 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ha1TEIVsWz1 for ; Thu, 14 Mar 2013 07:05:49 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A665E11E813B for ; Thu, 14 Mar 2013 07:05:48 -0700 (PDT) Received: from [IPv6:2001:df8::16:85c6:1503:5f38:692b] (unknown [IPv6:2001:df8:0:16:85c6:1503:5f38:692b]) by mail.nic.cz (Postfix) with ESMTPSA id 800D313F7D2; Thu, 14 Mar 2013 15:05:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1363269947; bh=I2zglZBVAdtEkljtJwYlTTbe8SEwEFLGc1BJf/p3SdM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=v7Cya0zct6T88olDvINNr+OFGID5uM54ZJyGG0Im9ZZKM0ktsAXgRUADEtu/xO610 0GT6cefp699ySNPULQvQfooxsLgZdVRLSXzUyglFl/7R66a4Yr5DrrVmPTkkbMaNgp sM11FOCGJc+dl0d0S1I9XgxNqMvIALx2bBJw4h0Y= 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, 14 Mar 2013 10:05:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <752BD624-50D3-400C-9506-9619D68FA264@nic.cz> References: <201303141312.r2EDC33d013382@idle.juniper.net> 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] yang-api comment: decouple protocol and encoding 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, 14 Mar 2013 14:05:57 -0000 On Mar 14, 2013, at 9:23 AM, Andy Bierman wrote: > Hi Phil, >=20 > Good point. > yangcli code drops PIs and comments and you need to set a fairly high > debug trace level > to actually see XML comments in the log. My thinking was, if a client > developer or operator > is having sessions rejected, they would turn on debugging. >=20 > I think 1 issue that was brought up is that the client developer may > not have access > to the server logs or server syslog feed. >=20 > I guess a robust solution would be an actual XML response from the = server > before dropping the connection. But in the case of improper framing, = the server > cannot trust what it got and has no choice but to ignore the client = and > drop the connection. I guess the server can still send an error message before shutting down. Lada >=20 >=20 > Andy >=20 >=20 >=20 >=20 > On Thu, Mar 14, 2013 at 6:12 AM, Phil Shafer wrote: >> Andy Bierman writes: >>> That way a client can find out if it was unsupported encoding vs. >>> unsupported base version that caused the session to be rejected. >>=20 >> It might be better for you to syslog this, so you aren't counting >> on comment processing/logging in the client and you're support folks >> can see the error without futzing with the client. >>=20 >> Thanks, >> Phil > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From rkrejci@cesnet.cz Fri Mar 15 09:42:36 2013 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 E90FD21F86DE for ; Fri, 15 Mar 2013 09:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqZYWIWvaWSv for ; Fri, 15 Mar 2013 09:42:35 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id C7B2121F85EE for ; Fri, 15 Mar 2013 09:42:33 -0700 (PDT) Received: from penny.liberouter.org (unknown [IPv6:2001:df8:0:8:8e70:5aff:fe81:4974]) by office2.cesnet.cz (Postfix) with ESMTPSA id 953552CDE073 for ; Fri, 15 Mar 2013 17:42:31 +0100 (CET) Message-ID: <51434F73.6030300@cesnet.cz> Date: Fri, 15 Mar 2013 12:42:27 -0400 From: =?ISO-8859-2?Q?Radek_Krej=E8=ED?= Organization: CESNET, z.s.p.o. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Netconf Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit Subject: [Netconf] delete-config with NACM 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, 15 Mar 2013 16:42:36 -0000 Hi all, I'd appreciate a clarification of NACM applied to delete-config operation. Section 3.2.5 of RFC 6536 talks about necessity of explicit permission to delete-config operation. My question is - when this is done, is server still supposed to check "delete" access permissions for all nodes in the datastore? Or does the explicit permission of delete-config say "group members are allowed to do it despite the specific access permissions to the nodes in the datastore" Radek Krejci From andy@yumaworks.com Tue Mar 19 08:02:42 2013 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 4C43521F8D03 for ; Tue, 19 Mar 2013 08:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.528 X-Spam-Level: X-Spam-Status: No, score=-1.528 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqV+0O35RzRv for ; Tue, 19 Mar 2013 08:02:41 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id D58F421F8CDD for ; Tue, 19 Mar 2013 08:02:41 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id 17so687218iea.26 for ; Tue, 19 Mar 2013 08:02:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=ktv9pP+VaAAWk989c2FrqM23VPvfA70eHrmUNUzKljA=; b=abgsvP6FSCm9HUo4WEphVaQ+Xy4Rov3nhMDb53WiF/9CuljSoMsB5gDZVAPjdUzPgs 7iSjSbkrU8VrDyuyC+PNsmb5S72fL1pKTRqQKB86TM1yU/m0HxbKP1dO3p3CNzq8kydM Dyu7uGD7TKf6rzNPHBugWttRhK0GmS2jDj0yL2jRRau5THy73bngrLyULjgE/chmTJlc ROoON2migFOktk15MC3Z60E1IBVc6+1T6KhnvH0Eq9PFWK9oOwycTs/AZkLKXzaB0LYg 7a5kptWEAdVb3eq0+t2dd7VZVB8gcAo+YY1rBKQYUFCrDLNDEItZy0u1LRc+JIzKTNpE zBRg== MIME-Version: 1.0 X-Received: by 10.42.29.198 with SMTP id s6mr11246034icc.54.1363705361178; Tue, 19 Mar 2013 08:02:41 -0700 (PDT) Received: by 10.231.93.6 with HTTP; Tue, 19 Mar 2013 08:02:41 -0700 (PDT) In-Reply-To: <51434F73.6030300@cesnet.cz> References: <51434F73.6030300@cesnet.cz> Date: Tue, 19 Mar 2013 08:02:41 -0700 Message-ID: From: Andy Bierman To: =?ISO-8859-2?B?UmFkZWsgS3Jlaujt?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQn2XSn45QrOU8vGp5yG9fAwBOTcmSF8/ZItndPrzYFH0Ed/tMg1jeN9wESt3s4VBZ/97Nxn Cc: Netconf Subject: Re: [Netconf] delete-config with NACM 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, 19 Mar 2013 15:02:42 -0000 On Fri, Mar 15, 2013 at 9:42 AM, Radek Krej=C4=8D=C3=AD = wrote: > Hi all, > I'd appreciate a clarification of NACM applied to delete-config > operation. Section 3.2.5 of RFC 6536 talks about necessity of explicit > permission to delete-config operation. My question is - when this is > done, is server still supposed to check "delete" access permissions for > all nodes in the datastore? Or does the explicit permission of > delete-config say "group members are allowed to do it despite the > specific access permissions to the nodes in the datastore" > No. If they can delete the datastore you don't need to check if they can delete specific contents. We allow datastores and the config to be deleted. > Radek Krejci Andy From rkrejci@cesnet.cz Tue Mar 19 09:51:11 2013 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 4427E21F8DA4 for ; Tue, 19 Mar 2013 09:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.625 X-Spam-Level: X-Spam-Status: No, score=-3.625 tagged_above=-999 required=5 tests=[AWL=1.325, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUSpuQFEkM3C for ; Tue, 19 Mar 2013 09:51:09 -0700 (PDT) Received: from minas.ics.muni.cz (minas.ics.muni.cz [147.251.4.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8D721F8DE5 for ; Tue, 19 Mar 2013 09:51:05 -0700 (PDT) Received: from anxur.fi.muni.cz (anxur.fi.muni.cz [147.251.48.3]) by minas.ics.muni.cz (8.13.8/8.13.8/SuSE Linux 0.8) with ESMTP id r2JGp1qH008521; Tue, 19 Mar 2013 17:51:03 +0100 Received: from sheldon.liberouter.org (unknown [147.251.21.249]) by anxur.fi.muni.cz (Postfix) with ESMTPSA id EEC2A617F7; Tue, 19 Mar 2013 17:51:01 +0100 (CET) Message-ID: <51489766.4050709@cesnet.cz> Date: Tue, 19 Mar 2013 17:50:46 +0100 From: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= Organization: CESNET, z.s.p.o. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Andy Bierman References: <51434F73.6030300@cesnet.cz> In-Reply-To: X-Enigmail-Version: 1.6a1pre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Muni-Spam-TestIP: 147.251.48.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (minas.ics.muni.cz [147.251.4.35]); Tue, 19 Mar 2013 17:51:03 +0100 (CET) Cc: Netconf Subject: Re: [Netconf] delete-config with NACM 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, 19 Mar 2013 16:51:11 -0000 Dne 19.3.2013 16:02, Andy Bierman napsal(a): > On Fri, Mar 15, 2013 at 9:42 AM, Radek Krejčí wrote: >> Hi all, >> I'd appreciate a clarification of NACM applied to delete-config >> operation. Section 3.2.5 of RFC 6536 talks about necessity of explicit >> permission to delete-config operation. My question is - when this is >> done, is server still supposed to check "delete" access permissions for >> all nodes in the datastore? Or does the explicit permission of >> delete-config say "group members are allowed to do it despite the >> specific access permissions to the nodes in the datastore" >> > > No. If they can delete the datastore you don't need to check > if they can delete specific contents. > thanks Andy, that's how libnetconf do it now. Radek > We allow datastores and the config to be deleted. > >> Radek Krejci > > Andy > From bertietf@bwijnen.net Wed Mar 20 08:51:17 2013 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 ECE1F21F8FDB for ; Wed, 20 Mar 2013 08:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OO-9PyeFP7f for ; Wed, 20 Mar 2013 08:51:17 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id B16C921F8E3C for ; Wed, 20 Mar 2013 08:51:08 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UILIA-0001SD-Rx for netconf@ietf.org; Wed, 20 Mar 2013 16:51:08 +0100 Received: from kitten.ripe.net ([193.0.1.240] helo=bwmacbook.fritz.box) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1UILIA-0004EV-Md for netconf@ietf.org; Wed, 20 Mar 2013 16:51:06 +0100 Message-ID: <5149DAEA.7010802@bwijnen.net> Date: Wed, 20 Mar 2013 16:51:06 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: netconf Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20130320 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd48b4ca0b2374990c5a8a0f09e42d02007 Subject: [Netconf] Advancement of NetConf RFCs 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, 20 Mar 2013 15:51:18 -0000 So are requested at the NetConf session at IETF86 in Orlando, PLEASE send me any deployment reports you may have. Some of you may be deploying netconf yourself. Some of you may have nnn customers who bought netconf related products from you or your companies. Some of you may know about the number of downloads of open source netconf code. Some of you may know about planned deployments All that sort of info will be helpfull trying to justify that we advance the documents. The documents we are considering are: - RFC6241, Network Configuration Protocol - RFC6242, Using the NETCONF Protocol over Secure Shell - RFC5717, Partial Lock Remote Procedure Call for NETCONF - RFC5277, NETCONF Event Notifications - RFC6243, With-defaults Capability for NETCONF - RFC6536, Network Configuration Protocol Access Control Model If you want tio keep it confidential, you can send it privately to us (or one of us) chairs. Pls mark clearly of you indeed want us to keep it confidential. We will then only count, but not make any details public. Bert and Mehmet -- Bert Wijnen From wwwrun@rfc-editor.org Wed Mar 27 07:01:53 2013 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 DE44321F910C for ; Wed, 27 Mar 2013 07:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.967 X-Spam-Level: X-Spam-Status: No, score=-101.967 tagged_above=-999 required=5 tests=[AWL=0.633, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxcQCsc-g5VB for ; Wed, 27 Mar 2013 07:01:53 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 1189921F910D for ; Wed, 27 Mar 2013 07:01:52 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id F33A7B1E002; Wed, 27 Mar 2013 07:01:21 -0700 (PDT) To: rob.enns@gmail.com, mbj@tail-f.com, j.schoenwaelder@jacobs-university.de, andy.bierman@brocade.com, bclaise@cisco.com, joelja@bogus.com, bertietf@bwijnen.net, mehmet.ersue@nsn.com From: RFC Errata System Message-Id: <20130327140122.F33A7B1E002@rfc-editor.org> Date: Wed, 27 Mar 2013 07:01:21 -0700 (PDT) X-Mailman-Approved-At: Wed, 27 Mar 2013 07:13:56 -0700 Cc: rfc-editor@rfc-editor.org, netconf@ietf.org Subject: [Netconf] [Editorial Errata Reported] RFC6241 (3569) 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, 27 Mar 2013 14:01:54 -0000 The following errata report has been submitted for RFC6241, "Network Configuration Protocol (NETCONF)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6241&eid=3569 -------------------------------------- Type: Editorial Reported by: Xiang Li Section: 1.2 Original Text ------------- (2) The Messages layer provides a simple, transport-independent framing mechanism for encoding RPCs and notifications. Section 4 documents the RPC messages, and [RFC5717] documents notifications Corrected Text -------------- (2) The Messages layer provides a simple, transport-independent framing mechanism for encoding RPCs and notifications. Section 4 documents the RPC messages, and [RFC5277] documents notifications Notes ----- RFC5717 Partial Lock Remote Procedure Call (RPC) for NETCONF RFC5277 NETCONF Event Notifications Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6241 (draft-ietf-netconf-4741bis-10) -------------------------------------- Title : Network Configuration Protocol (NETCONF) Publication Date : June 2011 Author(s) : R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., A. Bierman, Ed. Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG