From jeffrey.K.lange@ge.com Tue Oct 1 11:07:55 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1DEE21E8204 for ; Tue, 1 Oct 2013 11:07:55 -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 83Ek9dyT4Lzl for ; Tue, 1 Oct 2013 11:07:49 -0700 (PDT) Received: from exprod5og116.obsmtp.com (exprod5og116.obsmtp.com [64.18.0.147]) by ietfa.amsl.com (Postfix) with ESMTP id 59A8C21E805F for ; Tue, 1 Oct 2013 11:07:45 -0700 (PDT) Received: from cinmlip14.e2k.ad.ge.com ([165.156.4.1]) (using TLSv1) by exprod5ob116.postini.com ([64.18.4.12]) with SMTP ID DSNKUksPbwjCNG4kCMnBvwr2ly620BIrM05Z@postini.com; Tue, 01 Oct 2013 11:07:45 PDT Received: from unknown (HELO ALPMBHT02.e2k.ad.ge.com) ([3.159.19.195]) by cinmlip14.e2k.ad.ge.com with ESMTP/TLS/AES128-SHA; 01 Oct 2013 14:07:40 -0400 Received: from CINURAPD13.e2k.ad.ge.com (3.159.212.141) by ALPMBHT02.e2k.ad.ge.com (3.159.19.195) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 1 Oct 2013 14:07:39 -0400 Received: from CINURCNA15.e2k.ad.ge.com ([169.254.3.234]) by CINURAPD13.e2k.ad.ge.com ([169.254.7.178]) with mapi id 14.03.0146.000; Tue, 1 Oct 2013 14:07:39 -0400 From: "Lange, Jeffrey K (GE Energy Management)" To: "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt Thread-Index: AQHOodMlLyqCZb9RQkC9WKRHJHDjA5ngXCKw Date: Tue, 1 Oct 2013 18:07:39 +0000 Message-ID: References: <20130825203831.20582.30133.idtracker@ietfa.amsl.com> In-Reply-To: <20130825203831.20582.30133.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 18:07:56 -0000 I just wanted to pass along that I have created an implementation against t= his model (and the corresponding interfaces model). I did not find any issu= es with it in the process other than to reiterate what Jeurgen mentioned ab= out the fact that /interfaces-state/interface/ipv[46] are presence containe= rs. This doesn't seem to make a lot of sense for config-false data. Was th= ere ever a definitive answer on if this is truly desired? And as I've mentioned before, the iana-if-type enum doesn't work for us. I'= ve implemented this using my own identity type for interfaces due to the fa= ct that we have way too many proprietary interface types to make it work wi= th the if-type enum. I know this was brought up before and rejected due to = MIB interoperability issues, but that's the only real limitation we are hit= ting with these models. If this was an identity we would be able to use the= m as is. -Jeff > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On > Behalf Of internet-drafts@ietf.org > Sent: Sunday, August 25, 2013 4:39 PM > To: i-d-announce@ietf.org > Cc: netmod@ietf.org > Subject: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the NETCONF Data Modeling Language Working > Group of the IETF. >=20 > Title : A YANG Data Model for IP Management > Author(s) : Martin Bjorklund > Filename : draft-ietf-netmod-ip-cfg-10.txt > Pages : 33 > Date : 2013-08-25 >=20 > Abstract: > This document defines a YANG data model for management of IP > implementations. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netmod-ip-cfg >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-10 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-ip-cfg-10 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From mbj@tail-f.com Tue Oct 1 11:41:06 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 321D811E8233 for ; Tue, 1 Oct 2013 11:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 zGlTUH0AI4Nz for ; Tue, 1 Oct 2013 11:40:57 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC7521E81B9 for ; Tue, 1 Oct 2013 11:40:37 -0700 (PDT) Received: from localhost (unknown [193.13.114.80]) by mail.tail-f.com (Postfix) with ESMTPSA id 416EE12000B4; Tue, 1 Oct 2013 20:40:35 +0200 (CEST) Date: Tue, 01 Oct 2013 20:40:34 +0200 (CEST) Message-Id: <20131001.204034.194996395.mbj@tail-f.com> To: jeffrey.K.lange@ge.com From: Martin Bjorklund In-Reply-To: References: <20130825203831.20582.30133.idtracker@ietfa.amsl.com> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 18:41:06 -0000 Hi, Thank you for this implementation report! "Lange, Jeffrey K (GE Energy Management)" wrote: > I just wanted to pass along that I have created an implementation against this > model (and the corresponding interfaces model). I did not find any issues with > it in the process other than to reiterate what Jeurgen mentioned about the fact > that /interfaces-state/interface/ipv[46] are presence containers. This doesn't > seem to make a lot of sense for config-false data. Was there ever a definitive > answer on if this is truly desired? The only discussion I find re. presence containers was about the config tree (http://www.ietf.org/mail-archive/web/netmod/current/msg08479.html). If there was some other discussion that I don't remember, please point me in the right direction. In any case, I'd like to understand why you think using presence containers in the -state tree is problematic? The statement says: container ipv4 { presence "Present if IPv4 is enabled on this interface"; config false; ... so if ipv4 is disabled, this container will not show up in a reply. > And as I've mentioned before, the iana-if-type enum doesn't work for us. I've > implemented this using my own identity type for interfaces due to the fact that > we have way too many proprietary interface types to make it work with the > if-type enum. I know this was brought up before and rejected due to MIB > interoperability issues, but that's the only real limitation we are hitting > with these models. If this was an identity we would be able to use them as is. I believe Juergen also asked why you could not use the IANA procedure and register your proprietary interface types? /martin From jeffrey.K.lange@ge.com Tue Oct 1 12:06:28 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D34421F9E76 for ; Tue, 1 Oct 2013 12:06:28 -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 rqWkJB7scaVl for ; Tue, 1 Oct 2013 12:06:22 -0700 (PDT) Received: from exprod5og110.obsmtp.com (exprod5og110.obsmtp.com [64.18.0.20]) by ietfa.amsl.com (Postfix) with ESMTP id 648E621F9EA8 for ; Tue, 1 Oct 2013 12:05:42 -0700 (PDT) Received: from alpmlip10.e2k.ad.ge.com ([12.43.191.1]) (using TLSv1) by exprod5ob110.postini.com ([64.18.4.12]) with SMTP ID DSNKUksdBa12xDXgUtHCar23AQ2KmcWFNqU6@postini.com; Tue, 01 Oct 2013 12:05:42 PDT Received: from unknown (HELO ALPMBHT04.e2k.ad.ge.com) ([3.159.19.197]) by alpmlip10.e2k.ad.ge.com with ESMTP/TLS/AES128-SHA; 01 Oct 2013 15:05:41 -0400 Received: from ALPMLCH02.e2k.ad.ge.com (3.159.17.21) by ALPMBHT04.e2k.ad.ge.com (3.159.19.197) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 1 Oct 2013 15:05:39 -0400 Received: from CINURCNA21.e2k.ad.ge.com (3.159.212.169) by alpmlch02.e2k.ad.ge.com (3.159.17.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 1 Oct 2013 15:05:39 -0400 Received: from CINURCNA15.e2k.ad.ge.com ([169.254.3.234]) by CINURCNA21.e2k.ad.ge.com ([169.254.3.107]) with mapi id 14.03.0146.000; Tue, 1 Oct 2013 15:05:39 -0400 From: "Lange, Jeffrey K (GE Energy Management)" To: Martin Bjorklund Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt Thread-Index: AQHOodMlLyqCZb9RQkC9WKRHJHDjA5ngXCKwgABOsgD//8GvEA== Date: Tue, 1 Oct 2013 19:05:39 +0000 Message-ID: References: <20130825203831.20582.30133.idtracker@ietfa.amsl.com> <20131001.204034.194996395.mbj@tail-f.com> In-Reply-To: <20131001.204034.194996395.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 19:06:28 -0000 > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Tuesday, October 01, 2013 2:41 PM > To: Lange, Jeffrey K (GE Energy Management) > Cc: netmod@ietf.org > Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt >=20 > Hi, >=20 > Thank you for this implementation report! >=20 > "Lange, Jeffrey K (GE Energy Management)" > wrote: > > I just wanted to pass along that I have created an implementation again= st > this > > model (and the corresponding interfaces model). I did not find any issu= es > with > > it in the process other than to reiterate what Jeurgen mentioned about = the > fact > > that /interfaces-state/interface/ipv[46] are presence containers. This > doesn't > > seem to make a lot of sense for config-false data. Was there ever a > definitive > > answer on if this is truly desired? >=20 > The only discussion I find re. presence containers was about the > config tree > (http://www.ietf.org/mail-archive/web/netmod/current/msg08479.html). >=20 > If there was some other discussion that I don't remember, please point > me in the right direction. >=20 >From a previous email: > > /if:interfaces-state/if:interface/ipv4 > > /if:interfaces-state/if:interface/ipv6 > > /ip-state/ipv4 > > /ip-state/ipv6 > > =20 > > These leafs indicate that IPvX is enabled and hence they do > > actually carry semantics - if they do not show up, then > > /if:interfaces/if:interface/ipvX/enabled is most likely false. > In any case, I'd like to understand why you think using presence > containers in the -state tree is problematic? The statement says: >=20 It's not problematic per-se, but seems unneeded. If it's not configured, n= othing is returned. If there was mandatory leafs under there it would make= sense I guess, but there is not. > container ipv4 { > presence "Present if IPv4 is enabled on this interface"; > config false; >=20 > ... so if ipv4 is disabled, this container will not show up in a > reply. >=20 > > And as I've mentioned before, the iana-if-type enum doesn't work for us= . > I've > > implemented this using my own identity type for interfaces due to the f= act > that > > we have way too many proprietary interface types to make it work with > the > > if-type enum. I know this was brought up before and rejected due to MIB > > interoperability issues, but that's the only real limitation we are hit= ting > > with these models. If this was an identity we would be able to use them= as > is. >=20 > I believe Juergen also asked why you could not use the IANA procedure > and register your proprietary interface types? >=20 We have lots of custom interface types, and one-off designs that would mean= absolutely nothing to the Internet community at large. If we need to subm= it to an international standard body every time we want to create a new cus= tom interface type, it just doesn't make any sense. If this was an identit= y, with all the currently defined iana-iftypes defined as identities sharin= g the same common base identity type, we (and others in the same position a= s us) would be simply define a new interface type by creating a new identit= y in our yang models. -Jeff >=20 > /martin From andy@yumaworks.com Tue Oct 1 12:53:11 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5A021E81FA for ; Tue, 1 Oct 2013 12:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.223 X-Spam-Level: X-Spam-Status: No, score=0.223 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1] 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 oADZ5Yz40uAa for ; Tue, 1 Oct 2013 12:53:00 -0700 (PDT) Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD8721E818A for ; Tue, 1 Oct 2013 12:52:36 -0700 (PDT) Received: by mail-qe0-f45.google.com with SMTP id 6so5364377qea.4 for ; Tue, 01 Oct 2013 12:52:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4P1oEYfJ7EmGNm+kn+WpW5gRG3c6oL3RUyVbHXWCkSo=; b=KzFZjGoLwTFyKTGCVPvbv3+N6YMwyP1FftkmjPa+1mrMkw6g3iuIuKJNgxzY0c38BA G7eUaGqjqpWTf1TQBxtm2wAH5nD8gnpdUBK84txsSpBbUjV7JZ5Cd5Krw1XurHk/MhH9 txWD2wLGppWkrvTKjuKDhMN4bHEYl3BYe2kVdnoSTqSbNlLR4vgFRyJ1+r4N1wSHzoih COBh3aKDaC8vAm2bYvq3PJZDh+aA4QG8vjwYpZe1ntyxQzTl7tUB7zEwOdh1PVjMOxWR puxRiIwyAByM0NPdVUCY2taIv/rXDxKs2h5fqOGgyEfI+QWY9NktRZvmQJE7SrK26ozp zNsQ== X-Gm-Message-State: ALoCoQmCfTM2xIdViLlSFcndPnV6Dmdl10i3QuGwkn074aCiW4kXcxVqQhfTx67KSfWSdzRfZCsn MIME-Version: 1.0 X-Received: by 10.224.69.132 with SMTP id z4mr23164196qai.78.1380657151518; Tue, 01 Oct 2013 12:52:31 -0700 (PDT) Received: by 10.140.26.209 with HTTP; Tue, 1 Oct 2013 12:52:31 -0700 (PDT) In-Reply-To: References: <20130825203831.20582.30133.idtracker@ietfa.amsl.com> <20131001.204034.194996395.mbj@tail-f.com> Date: Tue, 1 Oct 2013 12:52:31 -0700 Message-ID: From: Andy Bierman To: "Lange, Jeffrey K (GE Energy Management)" Content-Type: multipart/alternative; boundary=001a11c2310e12bbcb04e7b34b52 Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 19:53:12 -0000 --001a11c2310e12bbcb04e7b34b52 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 1, 2013 at 12:05 PM, Lange, Jeffrey K (GE Energy Management) < jeffrey.K.lange@ge.com> wrote: > > > > -----Original Message----- > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > Sent: Tuesday, October 01, 2013 2:41 PM > > To: Lange, Jeffrey K (GE Energy Management) > > Cc: netmod@ietf.org > > Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt > > > > Hi, > > > > Thank you for this implementation report! > > > > "Lange, Jeffrey K (GE Energy Management)" > > wrote: > > > I just wanted to pass along that I have created an implementation > against > > this > > > model (and the corresponding interfaces model). I did not find any > issues > > with > > > it in the process other than to reiterate what Jeurgen mentioned about > the > > fact > > > that /interfaces-state/interface/ipv[46] are presence containers. This > > doesn't > > > seem to make a lot of sense for config-false data. Was there ever a > > definitive > > > answer on if this is truly desired? > > > > The only discussion I find re. presence containers was about the > > config tree > > (http://www.ietf.org/mail-archive/web/netmod/current/msg08479.html). > > > > If there was some other discussion that I don't remember, please point > > me in the right direction. > > > > From a previous email: > > > /if:interfaces-state/if:interface/ipv4 > > > /if:interfaces-state/if:interface/ipv6 > > > /ip-state/ipv4 > > > /ip-state/ipv6 > > > > > > These leafs indicate that IPvX is enabled and hence they do > > > actually carry semantics - if they do not show up, then > > > /if:interfaces/if:interface/ipvX/enabled is most likely false. > > > > > In any case, I'd like to understand why you think using presence > > containers in the -state tree is problematic? The statement says: > > > > It's not problematic per-se, but seems unneeded. If it's not configured, > nothing is returned. If there was mandatory leafs under there it would > make sense I guess, but there is not. > > IMO a presence container in config=false is a bit confusing. I also think the mandatory=true in a config=false node is confusing. If seems to mean "server MUST implement". But that would imply that mandatory=false means "server MAY implement". However the module base + YANG features are supposed to be the only conformance mechanisms. It is not very clear what mandatory-stmt means for config=false nodes. > container ipv4 { > > presence "Present if IPv4 is enabled on this interface"; > > config false; > > > > ... so if ipv4 is disabled, this container will not show up in a > > reply. > > > > > And as I've mentioned before, the iana-if-type enum doesn't work for > us. > > I've > > > implemented this using my own identity type for interfaces due to the > fact > > that > > > we have way too many proprietary interface types to make it work with > > the > > > if-type enum. I know this was brought up before and rejected due to MIB > > > interoperability issues, but that's the only real limitation we are > hitting > > > with these models. If this was an identity we would be able to use > them as > > is. > > > > I believe Juergen also asked why you could not use the IANA procedure > > and register your proprietary interface types? > > > > We have lots of custom interface types, and one-off designs that would > mean absolutely nothing to the Internet community at large. If we need to > submit to an international standard body every time we want to create a new > custom interface type, it just doesn't make any sense. If this was an > identity, with all the currently defined iana-iftypes defined as identities > sharing the same common base identity type, we (and others in the same > position as us) would be simply define a new interface type by creating a > new identity in our yang models This is a standard module so we need to make sure that there is some hope of interoperability. I think you can augment the module with additional classifiers that only your apps understand (since they are the only ones that understand your if-type enums). Pick the closest enum or use 'other' as a last resort. > -Jeff > > > Andy > > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11c2310e12bbcb04e7b34b52 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Oct 1, 2013 at 12:05 PM, Lange, Jeffrey K (GE Energy Manage= ment) <jeffrey.K.lange@ge.com> wrote:


> -----Original Message-----
> From: Martin Bjorklund [mailto:mbj@t= ail-f.com]
> Sent: Tuesday, October 01, 2013 2:41 PM
> To: Lange, Jeffrey K (GE Energy Management)
> Cc: netmod@ietf.org
> Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt
>
> Hi,
>
> Thank you for this implementation report!
>
> "Lange, Jeffrey K (GE Energy Management)" <jeffrey.K.lange@ge.com>
> wrote:
> > I just wanted to pass along that I have created an implementation= against
> this
> > model (and the corresponding interfaces model). I did not find an= y issues
> with
> > it in the process other than to reiterate what Jeurgen mentioned = about the
> fact
> > that /interfaces-state/interface/ipv[46] are presence containers.= This
> doesn't
> > seem to make a lot of sense for config-false data. =A0Was there e= ver a
> definitive
> > answer on if this is truly desired?
>
> The only discussion I find re. presence containers was about the
> config tree
> (http://www.ietf.org/mail-archive/web/netmod/curr= ent/msg08479.html).
>
> If there was some other discussion that I don't remember, please p= oint
> me in the right direction.
>

>From a previous email:
> > =A0 =A0/if:interfaces-state/if:interface/ipv4
> > =A0 =A0/if:interfaces-state/if:interface/ipv6
> > =A0 =A0/ip-state/ipv4
> > =A0 =A0/ip-state/ipv6
> >
> > =A0 =A0These leafs indicate that IPvX is enabled and hence they d= o
> > =A0 =A0actually carry semantics - if they do not show up, then > > =A0 =A0/if:interfaces/if:interface/ipvX/enabled is most likely fa= lse.



> In any case, I'd like to understand why you think using presence > containers in the -state tree is problematic? =A0The statement says: >

It's not problematic per-se, but seems unneeded. =A0If it's not con= figured, nothing is returned. =A0If there was mandatory leafs under there i= t would make sense I guess, but there is not.



IMO a presence containe= r in config=3Dfalse is a bit confusing.
I also think the mandator= y=3Dtrue in a config=3Dfalse node is confusing.
If seems to mean = "server MUST implement". =A0But that would imply
that mandatory=3Dfalse means "server MAY implement".
However the module base + YANG features are supposed
to be the= only conformance mechanisms. =A0It is not very clear what
mandat= ory-stmt means for config=3Dfalse nodes.




> =A0 =A0container ipv4 {
> =A0 =A0 =A0 presence "Present if IPv4 is enabled on this interfac= e";
> =A0 =A0 =A0 config false;
>
> ... so if ipv4 is disabled, this container will not show up in a <g= et>
> reply.
>
> > And as I've mentioned before, the iana-if-type enum doesn'= ;t work for us.
> I've
> > implemented this using my own identity type for interfaces due to= the fact
> that
> > we have way too many proprietary interface types to make it work = with
> the
> > if-type enum. I know this was brought up before and rejected due = to MIB
> > interoperability issues, but that's the only real limitation = we are hitting
> > with these models. If this was an identity we would be able to us= e them as
> is.
>
> I believe Juergen also asked why you could not use the IANA procedure<= br> > and register your proprietary interface types?
>

We have lots of custom interface types, and one-off designs that would mean= absolutely nothing to the Internet community at large. =A0If we need to su= bmit to an international standard body every time we want to create a new c= ustom interface type, it just doesn't make any sense. =A0If this was an= identity, with all the currently defined iana-iftypes defined as identitie= s sharing the same common base identity type, we (and others in the same po= sition as us) would be simply define a new interface type by creating a new= identity in our yang models


This is a standard module so we need to = make sure that there is
some hope of interoperability. =A0I think= you can augment the module
with additional classifiers that only= your apps understand (since they
are the only ones that understand your if-type enums). =A0Pick the
closest enum or use 'other' as a last resort.

=



=A0
-Jeff



Andy

=A0
>
> /martin
_______________________________________________
netmod mailing list
netmod@ietf.org
= https://www.ietf.org/mailman/listinfo/netmod

--001a11c2310e12bbcb04e7b34b52-- From jeffrey.K.lange@ge.com Wed Oct 2 06:19:03 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AAF921F84F8 for ; Wed, 2 Oct 2013 06:19:03 -0700 (PDT) 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] 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 i9kr-1y3tzNt for ; Wed, 2 Oct 2013 06:18:50 -0700 (PDT) Received: from exprod5og118.obsmtp.com (exprod5og118.obsmtp.com [64.18.0.160]) by ietfa.amsl.com (Postfix) with ESMTP id C8BA921F8CB4 for ; Wed, 2 Oct 2013 06:18:37 -0700 (PDT) Received: from cinmlip14.e2k.ad.ge.com ([165.156.4.1]) (using TLSv1) by exprod5ob118.postini.com ([64.18.4.12]) with SMTP ID DSNKUkwdK1rmFXYy+qgPN7+tJMHcKHBXBsUP@postini.com; Wed, 02 Oct 2013 06:18:37 PDT Received: from unknown (HELO ALPMBHT04.e2k.ad.ge.com) ([3.159.19.197]) by cinmlip14.e2k.ad.ge.com with ESMTP/TLS/AES128-SHA; 02 Oct 2013 09:18:34 -0400 Received: from CINMLCH01.e2k.ad.ge.com (3.159.212.50) by ALPMBHT04.e2k.ad.ge.com (3.159.19.197) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 2 Oct 2013 09:18:34 -0400 Received: from CINURAPD10.e2k.ad.ge.com (3.159.212.133) by cinmlch01.e2k.ad.ge.com (3.159.212.50) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 2 Oct 2013 09:18:33 -0400 Received: from CINURCNA15.e2k.ad.ge.com ([169.254.3.234]) by CINURAPD10.e2k.ad.ge.com ([169.254.8.227]) with mapi id 14.03.0146.000; Wed, 2 Oct 2013 09:18:33 -0400 From: "Lange, Jeffrey K (GE Energy Management)" To: Andy Bierman Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt Thread-Index: AQHOodMlLyqCZb9RQkC9WKRHJHDjA5ngXCKwgABOsgD//8GvEIAAUmyAgADgLUA= Date: Wed, 2 Oct 2013 13:18:34 +0000 Message-ID: References: <20130825203831.20582.30133.idtracker@ietfa.amsl.com> <20131001.204034.194996395.mbj@tail-f.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 13:19:03 -0000 >> We have lots of custom interface types, and one-off designs that would m= ean absolutely >> nothing to the Internet community at large. =A0If we need to submit to a= n international standard >> body every time we want to create a new custom interface type, it just d= oesn't make any sense. >>=A0If this was an identity, with all the currently defined iana-iftypes d= efined as identities sharing the >> same common base identity type, we (and others in the same position as u= s) would be simply >> define a new interface type by creating a new identity in our yang model= s > This is a standard module so we need to make sure that there is > some hope of interoperability. =A0I think you can augment the module > with additional classifiers that only your apps understand (since they > are the only ones that understand your if-type enums). =A0Pick the > closest enum or use 'other' as a last resort. >Andy Perhaps I'm missing part of an old conversation, but what would the drawbac= ks be to making the if type an identity vs an enum? Is it simply and argume= nt of "we don't' want to change it" or is there a more fundamental technica= l reason that it must remain an enum? I think the arguments for making it = an identity are pretty compelling from an extensibility standpoint. -Jeff From lhotka@nic.cz Wed Oct 2 08:12:09 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDF321F9AE3 for ; Wed, 2 Oct 2013 08:12:09 -0700 (PDT) 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 UGN67TieLcJC for ; Wed, 2 Oct 2013 08:11:59 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 447A421F9AF0 for ; Wed, 2 Oct 2013 08:09:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 0DC1354039A for ; Wed, 2 Oct 2013 17:09:27 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpkPGOhmrw-z for ; Wed, 2 Oct 2013 17:09:17 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 0E5B9540158 for ; Wed, 2 Oct 2013 17:09:12 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: References: <20130825203831.20582.30133.idtracker@ietfa.amsl.com> <20131001.204034.194996395.mbj@tail-f.com> User-Agent: Notmuch/0.15.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Mail-Followup-To: netmod@ietf.org Date: Wed, 02 Oct 2013 17:09:11 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 15:12:09 -0000 "Lange, Jeffrey K (GE Energy Management)" writes: >>> We have lots of custom interface types, and one-off designs that would = mean absolutely >>> nothing to the Internet community at large. =C2=A0If we need to submit = to an international standard >>> body every time we want to create a new custom interface type, it just = doesn't make any sense. >>>=C2=A0If this was an identity, with all the currently defined iana-iftyp= es defined as identities sharing the >>> same common base identity type, we (and others in the same position as = us) would be simply >>> define a new interface type by creating a new identity in our yang mode= ls > > >> This is a standard module so we need to make sure that there is >> some hope of interoperability. =C2=A0I think you can augment the module >> with additional classifiers that only your apps understand (since they >> are the only ones that understand your if-type enums). =C2=A0Pick the >> closest enum or use 'other' as a last resort. > >>Andy > > Perhaps I'm missing part of an old conversation, but what would the drawb= acks be to making the if type an identity vs an enum? Is it simply and argu= ment of "we don't' want to change it" or is there a more fundamental techni= cal reason that it must remain an enum? I think the arguments for making i= t an identity are pretty compelling from an extensibility standpoint. There is one technical issue, namely that there is no support for identitie= s in XPath expressions: 1. 'must' and 'when' conditions based on equality of identities are necessa= rily fragile. Consider an equivalent for when "if:type =3D 'ethernetCsmacd'"; With identities, the XPath expression would have to match *qualified names*= of identities, and this cannot be done properly, i.e., without relying on = the equality of namespace prefixes. 2. It is impossible to make use of the hierarchy of identities. For example= , suppose you modify a standard interface X into a new interface type Y, an= d you want to reuse configuration parameters of type X and perhaps add seve= ral new ones. Then, if the parameters of X are defined with =20 when "if:type =3D X"; you are out of luck because the interface type is Y !=3D X. What's really n= eeded in this case is to have Y as an identity derived from X, and then specify the 'when' condition= for X like this: when "yang:derived-from(if:type, X)"; Interface types based on the IANA registry do not have problem #1 but, on t= he other hand, they do not offer any solution to #2 (and probably never wil= l). Lada > > -Jeff > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jeffrey.K.lange@ge.com Wed Oct 2 08:47:05 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850FC21F9CB5 for ; Wed, 2 Oct 2013 08:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, 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 9vLtLHnkea-I for ; Wed, 2 Oct 2013 08:46:52 -0700 (PDT) Received: from exprod5og111.obsmtp.com (exprod5og111.obsmtp.com [64.18.0.22]) by ietfa.amsl.com (Postfix) with ESMTP id 26A9F21F8FE5 for ; Wed, 2 Oct 2013 08:46:13 -0700 (PDT) Received: from alpmlip14.e2k.ad.ge.com ([12.43.191.1]) (using TLSv1) by exprod5ob111.postini.com ([64.18.4.12]) with SMTP ID DSNKUkw/wqe2hE1Jz6pC6yMLDWGuRcdmUVlk@postini.com; Wed, 02 Oct 2013 08:46:15 PDT Received: from unknown (HELO ALPMBHT01.e2k.ad.ge.com) ([3.159.19.194]) by alpmlip14.e2k.ad.ge.com with ESMTP/TLS/AES128-SHA; 02 Oct 2013 11:46:09 -0400 Received: from CINURCNA07.e2k.ad.ge.com (3.159.212.124) by ALPMBHT01.e2k.ad.ge.com (3.159.19.194) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 2 Oct 2013 11:46:09 -0400 Received: from CINURCNA15.e2k.ad.ge.com ([169.254.3.234]) by CINURCNA07.e2k.ad.ge.com ([169.254.1.27]) with mapi id 14.03.0146.000; Wed, 2 Oct 2013 11:46:09 -0400 From: "Lange, Jeffrey K (GE Energy Management)" To: Ladislav Lhotka , "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt Thread-Index: AQHOodMlLyqCZb9RQkC9WKRHJHDjA5ngXCKwgABOsgD//8GvEIAAUmyAgADgLUCAAGL+gP//xLTQ Date: Wed, 2 Oct 2013 15:46:10 +0000 Message-ID: References: <20130825203831.20582.30133.idtracker@ietfa.amsl.com> <20131001.204034.194996395.mbj@tail-f.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 15:47:05 -0000 PiANCj4gVGhlcmUgaXMgb25lIHRlY2huaWNhbCBpc3N1ZSwgbmFtZWx5IHRoYXQgdGhlcmUgaXMg bm8gc3VwcG9ydCBmb3IgaWRlbnRpdGllcyBpbg0KPiBYUGF0aCBleHByZXNzaW9uczoNCj4gDQo+ IDEuICdtdXN0JyBhbmQgJ3doZW4nIGNvbmRpdGlvbnMgYmFzZWQgb24gZXF1YWxpdHkgb2YgaWRl bnRpdGllcyBhcmUgbmVjZXNzYXJpbHkNCj4gZnJhZ2lsZS4gQ29uc2lkZXIgYW4gZXF1aXZhbGVu dCBmb3INCj4gDQo+ICAgICB3aGVuICJpZjp0eXBlID0gJ2V0aGVybmV0Q3NtYWNkJyI7DQo+IA0K PiBXaXRoIGlkZW50aXRpZXMsIHRoZSBYUGF0aCBleHByZXNzaW9uIHdvdWxkIGhhdmUgdG8gbWF0 Y2ggKnF1YWxpZmllZA0KPiBuYW1lcyogb2YgaWRlbnRpdGllcywgYW5kIHRoaXMgY2Fubm90IGJl IGRvbmUgcHJvcGVybHksIGkuZS4sIHdpdGhvdXQgcmVseWluZw0KPiBvbiB0aGUgZXF1YWxpdHkg b2YgbmFtZXNwYWNlIHByZWZpeGVzLg0KPiANCg0KSSdtIG5vdCBzZWVpbmcgaG93IHRoaXMgaXMg ZGlmZmVyZW50IHRoYW4gaGF2aW5nOg0KbW9kdWxlIGlhbmEtaWYtdHlwZSB7DQogICAgIG5hbWVz cGFjZSAidXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOmlhbmEtaWYtdHlwZSI7DQogICAgIHBy ZWZpeCBpYW5haWZ0Ow0KDQogIGlkZW50aXR5IGlmdHlwZSB7DQogICAgZGVzY3JpcHRpb24NCiAg ICAgICJCYXNlIEludGVyZmFjZSB0eXBlIjsNCiAgfQ0KICBpZGVudGl0eSBldGhlcm5ldENzbWFj ZCB7DQogICAgYmFzZSBpZnR5cGU7DQogICAgZGVzY3JpcHRpb24NCiAgICAgICJFdGhlcm5ldCBp bnRlcmZhY2UgdHlwZSI7DQogIH0NCn0NCg0KQW5kIHRoZW4gdXNpbmc6DQogIHdoZW4gImlmOnR5 cGUgPSAnaWFuYWlmdDpldGhlcm5ldENzbWFjZCI7DQoNClRoaXMgaXMgaW4gZXNzZW5jZSB3aGF0 IEkgYW0gZG9pbmcgdG9kYXksIGFuZCBpdCB3b3JrcyBwZXJmZWN0bHkgZmluZS4NCg0KPiAyLiBJ dCBpcyBpbXBvc3NpYmxlIHRvIG1ha2UgdXNlIG9mIHRoZSBoaWVyYXJjaHkgb2YgaWRlbnRpdGll cy4gRm9yIGV4YW1wbGUsDQo+IHN1cHBvc2UgeW91IG1vZGlmeSBhIHN0YW5kYXJkIGludGVyZmFj ZSBYIGludG8gYSBuZXcgaW50ZXJmYWNlIHR5cGUgWSwgYW5kDQo+IHlvdSB3YW50IHRvIHJldXNl IGNvbmZpZ3VyYXRpb24gcGFyYW1ldGVycyBvZiB0eXBlIFggYW5kIHBlcmhhcHMgYWRkDQo+IHNl dmVyYWwgbmV3IG9uZXMuIFRoZW4sIGlmIHRoZSBwYXJhbWV0ZXJzIG9mIFggYXJlIGRlZmluZWQg d2l0aA0KPiANCj4gICAgIHdoZW4gImlmOnR5cGUgPSBYIjsNCj4gDQo+IHlvdSBhcmUgb3V0IG9m IGx1Y2sgYmVjYXVzZSB0aGUgaW50ZXJmYWNlIHR5cGUgaXMgWSAhPSBYLiBXaGF0J3MgcmVhbGx5 IG5lZWRlZA0KPiBpbiB0aGlzIGNhc2UgaXMgdG8NCj4gaGF2ZSBZIGFzIGFuIGlkZW50aXR5IGRl cml2ZWQgZnJvbSBYLCBhbmQgdGhlbiBzcGVjaWZ5IHRoZSAnd2hlbicgY29uZGl0aW9uDQo+IGZv ciBYIGxpa2UgdGhpczoNCj4gDQo+ICAgICB3aGVuICJ5YW5nOmRlcml2ZWQtZnJvbShpZjp0eXBl LCBYKSI7DQo+IA0KDQpJIGRvbid0IHNlZSBob3cgZWl0aGVyIGVudW1zIG9yIGlkZW50aXRpZXMg aGF2ZSBhbnkgYmVhcmluZyBvbiB0aGUgYWJvdmUuDQoNCi1KZWZmDQoNCg0KPiBJbnRlcmZhY2Ug dHlwZXMgYmFzZWQgb24gdGhlIElBTkEgcmVnaXN0cnkgZG8gbm90IGhhdmUgcHJvYmxlbSAjMSBi dXQsIG9uDQo+IHRoZSBvdGhlciBoYW5kLCB0aGV5IGRvIG5vdCBvZmZlciBhbnkgc29sdXRpb24g dG8gIzIgKGFuZCBwcm9iYWJseSBuZXZlcg0KPiB3aWxsKS4NCj4gDQo+IExhZGENCg== From andy@yumaworks.com Wed Oct 2 09:08:57 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C98E21F8613 for ; Wed, 2 Oct 2013 09:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 jwD3mCFWFojr for ; Wed, 2 Oct 2013 09:08:44 -0700 (PDT) Received: from mail-qe0-f46.google.com (mail-qe0-f46.google.com [209.85.128.46]) by ietfa.amsl.com (Postfix) with ESMTP id EFE1021F85D1 for ; Wed, 2 Oct 2013 09:06:39 -0700 (PDT) Received: by mail-qe0-f46.google.com with SMTP id x7so713615qeu.19 for ; Wed, 02 Oct 2013 09:06:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nHv1H7T6cP669vHM4xll3V81sXhuIzvTLMDAwC1zdg0=; b=TDaXiYLlKpWtQgIwpz2+JDC/6KXF6+ThEUlcxhj34lwuYmEm6+C71eIIGCTYzwL77o 1i2OiNG/zypezSEZ3S3z79y1pz/ExcLKxFS8GbDF/rbPBoIsKidoWN/nQo6N23i1MfZS 08ZFCHP4HVftxP2YmJYSIU6R5bhm6ID8gyk3JoRuKmpIw4tQ4oESyt+ycfJF63kzbVCu pqT2Fwk36hOp84f65h+M5ucAQYEj3Ofb9MOxwLGPJE8ETmAQmgNDuey+da79p6ZNsqGd /xCFwfwk20d79sVA7lo3Ai3icwL+GsVzEyY3EuhDshGBpbLYUPe3TOX08Wit/CC5uF5o b5jQ== X-Gm-Message-State: ALoCoQk+hkuZEXvaIZDt6R5uSnQiE3agX+Rj85tla/rl7u2N4OiIVi2KDrZIjlkGUVMeRLyhqCsB MIME-Version: 1.0 X-Received: by 10.49.120.72 with SMTP id la8mr3891536qeb.62.1380729995624; Wed, 02 Oct 2013 09:06:35 -0700 (PDT) Received: by 10.140.26.209 with HTTP; Wed, 2 Oct 2013 09:06:35 -0700 (PDT) In-Reply-To: References: <20130825203831.20582.30133.idtracker@ietfa.amsl.com> <20131001.204034.194996395.mbj@tail-f.com> Date: Wed, 2 Oct 2013 09:06:35 -0700 Message-ID: From: Andy Bierman To: "Lange, Jeffrey K (GE Energy Management)" Content-Type: multipart/alternative; boundary=047d7b6d8996eb958304e7c4406c Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 16:08:57 -0000 --047d7b6d8996eb958304e7c4406c Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 2, 2013 at 6:18 AM, Lange, Jeffrey K (GE Energy Management) < jeffrey.K.lange@ge.com> wrote: > > > >> We have lots of custom interface types, and one-off designs that would > mean absolutely > >> nothing to the Internet community at large. If we need to submit to an > international standard > >> body every time we want to create a new custom interface type, it just > doesn't make any sense. > >> If this was an identity, with all the currently defined iana-iftypes > defined as identities sharing the > >> same common base identity type, we (and others in the same position as > us) would be simply > >> define a new interface type by creating a new identity in our yang > models > > > > This is a standard module so we need to make sure that there is > > some hope of interoperability. I think you can augment the module > > with additional classifiers that only your apps understand (since they > > are the only ones that understand your if-type enums). Pick the > > closest enum or use 'other' as a last resort. > > >Andy > > Perhaps I'm missing part of an old conversation, but what would the > drawbacks be to making the if type an identity vs an enum? Is it simply and > argument of "we don't' want to change it" or is there a more fundamental > technical reason that it must remain an enum? I think the arguments for > making it an identity are pretty compelling from an extensibility > standpoint. > YANG identities are too extensible for this particular leaf. YANG enumerations are defined by a single centralized naming authority (IANA). The entire set of values is contained within 1 YANG statement. Identities are defined by any naming authority (hence the need for QNames). The entire set of values is unknowable since any YANG module can add new identity-stmts and extend it. A lot of investment has been made in the IANA interface type registry and I want vendors to use it. If every vendor can replace these enums with their own definitions, then 3rd party clients will have to hard-code the identities used by each server vendor. That is not very interoperable. > -Jeff > Andy --047d7b6d8996eb958304e7c4406c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Oct 2, 2013 at 6:18 AM, Lange, Jeffrey K (GE Energy Managem= ent) <jeffrey.K.lange@ge.com> wrote:


>> We have lots of custom interface types, and one-off designs that w= ould mean absolutely
>> nothing to the Internet community at large. =A0If we need to submi= t to an international standard
>> body every time we want to create a new custom interface type, it = just doesn't make any sense.
>>=A0If this was an identity, with all the currently defined iana-ift= ypes defined as identities sharing the
>> same common base identity type, we (and others in the same positio= n as us) would be simply
>> define a new interface type by creating a new identity in our yang= models


> This is a standard module so we need to make sure that there is
> some hope of interoperability. =A0I think you can augment the module > with additional classifiers that only your apps understand (since they=
> are the only ones that understand your if-type enums). =A0Pick the
> closest enum or use 'other' as a last resort.

>Andy

Perhaps I'm missing part of an old conversation, but what would the dra= wbacks be to making the if type an identity vs an enum? Is it simply and ar= gument of "we don't' want to change it" or is there a mor= e fundamental technical reason that it must remain an enum? =A0I think the = arguments for making it an identity are pretty compelling from an extensibi= lity standpoint.


YANG identities are too ext= ensible for this particular leaf.
YANG enumerations are defined b= y a single centralized
naming authority (IANA). =A0The entire set= of values is
contained within 1 YANG statement. =A0Identities are defined
by any naming authority (hence the need for QNames).
The entire = set of values is unknowable since any YANG module
can add new ide= ntity-stmts and extend it.

A lot of investment has been made in the IANA interface=
type registry and I want vendors to use it. =A0If every
vendor can replace these enums with their own definitions,
then 3rd party clients will have to hard-code the identities
used= by each server vendor. =A0That is not very interoperable.



-Jeff

Andy

--047d7b6d8996eb958304e7c4406c-- From jeffrey.K.lange@ge.com Wed Oct 2 09:31:06 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F4D21F9D89 for ; Wed, 2 Oct 2013 09:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, 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 3j2P5jdI5y8M for ; Wed, 2 Oct 2013 09:30:53 -0700 (PDT) Received: from exprod5og111.obsmtp.com (exprod5og111.obsmtp.com [64.18.0.22]) by ietfa.amsl.com (Postfix) with ESMTP id 3693621F99BD for ; Wed, 2 Oct 2013 09:29:15 -0700 (PDT) Received: from alpmlip10.e2k.ad.ge.com ([165.156.5.1]) (using TLSv1) by exprod5ob111.postini.com ([64.18.4.12]) with SMTP ID DSNKUkxJ2YXaQDLfwGVhaITh+8XTW7SGh5uL@postini.com; Wed, 02 Oct 2013 09:29:15 PDT Received: from unknown (HELO ALPMBHT04.e2k.ad.ge.com) ([3.159.19.197]) by alpmlip10.e2k.ad.ge.com with ESMTP/TLS/AES128-SHA; 02 Oct 2013 12:29:13 -0400 Received: from ALPMLCH02.e2k.ad.ge.com (3.159.17.21) by ALPMBHT04.e2k.ad.ge.com (3.159.19.197) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 2 Oct 2013 12:29:12 -0400 Received: from CINURCNA21.e2k.ad.ge.com (3.159.212.169) by alpmlch02.e2k.ad.ge.com (3.159.17.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 2 Oct 2013 12:29:12 -0400 Received: from CINURCNA15.e2k.ad.ge.com ([169.254.3.234]) by CINURCNA21.e2k.ad.ge.com ([169.254.3.107]) with mapi id 14.03.0146.000; Wed, 2 Oct 2013 12:29:12 -0400 From: "Lange, Jeffrey K (GE Energy Management)" To: Andy Bierman Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt Thread-Index: AQHOodMlLyqCZb9RQkC9WKRHJHDjA5ngXCKwgABOsgD//8GvEIAAUmyAgADgLUCAAHMHgP//v6AA Date: Wed, 2 Oct 2013 16:29:13 +0000 Message-ID: References: <20130825203831.20582.30133.idtracker@ietfa.amsl.com> <20131001.204034.194996395.mbj@tail-f.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 16:31:06 -0000 > YANG identities are too extensible for this particular leaf. > YANG enumerations are defined by a single centralized > naming authority (IANA). =A0The entire set of values is > contained within 1 YANG statement. =A0Identities are defined > by any naming authority (hence the need for QNames). > The entire set of values is unknowable since any YANG module > can add new identity-stmts and extend it. > My counter-argument is that by making the if type an identity you are actua= lly increasing the interoperability of things. Take the example where ther= e is a product that has a custom XYZ interface. In order to use the XYZ in= terface seamlessly with the standard interfaces list (assuming the current = iftype enum) you would have to set the type to "other" then augment in some= other selector as to what the type of the interface is so that you can aug= ment in any XYZ specific configuration variables. If an external management= application wants to configure that interface, they already need to specia= l case the code to deal with that custom interface type. =20 This extra selector code is not interoperable because every vendor would do= it differently. If on the other hand, the current IANA iftype list was con= verted to identities, then there is still a standard and common list of val= ues that the majority of all "standard" devices would be able to use for th= eir interfaces. BUT, it allows the extensibility of proprietary interfaces = in a STANDARD way. > A lot of investment has been made in the IANA interface > type registry and I want vendors to use it. If every > vendor can replace these enums with their own definitions, > then 3rd party clients will have to hard-code the identities > used by each server vendor. That is not very interoperable. I am in no way advocating abandoning this registry, but forewarning that if= it is overly restrictive in allowing someone to do what they need, it won'= t get used at all. >Andy From andy@yumaworks.com Wed Oct 2 12:13:47 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B510C21F9FA2 for ; Wed, 2 Oct 2013 12:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 ifbapcYnPY2M for ; Wed, 2 Oct 2013 12:13:23 -0700 (PDT) Received: from mail-qe0-f54.google.com (mail-qe0-f54.google.com [209.85.128.54]) by ietfa.amsl.com (Postfix) with ESMTP id B721721F9F97 for ; Wed, 2 Oct 2013 11:59:45 -0700 (PDT) Received: by mail-qe0-f54.google.com with SMTP id cy11so918558qeb.27 for ; Wed, 02 Oct 2013 11:59:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3zUnWSJP3HGlMObMwvo6YXqIv2hpNe4c91yHAjjgCoU=; b=mQpoZEEfI8hG+r8AGXAdN0/6UwfAME2VL6OoDhZd8W43mclRP5WHErRVgelcrKX9y0 KtDxudJlfonVMVh4WiatJF1F1GvI7xRDuUBk852ACiKaCQ/2IwMNWBVOm4Pj/uobb6Dj q3YPuroQHmkuWxGuwsZcwz2RPSz0HsXMa4Hfm1WmdP/cDHlopMvwlDGmMkiQp9Zu6mbk MON0ALex0K1SqNso0YOIlTGqvjtA5crVt0rUAShVi+6JeHSlhVivep5TZG8GGMgXCj4O 7HiFVRJrZNdh2zGy8DbSsc2dUYvdBvLagl4uIyx9egSiBGLp8t5Ayiyx69iQw6eQh8Nl KHvQ== X-Gm-Message-State: ALoCoQnxNk77Xv8cXncXDff7/IwB/+Xy/jKjxj5kh7dPJyLDTcCGSKO/YkbH2SawnTzMcNajfIue MIME-Version: 1.0 X-Received: by 10.49.37.193 with SMTP id a1mr4849343qek.56.1380740370271; Wed, 02 Oct 2013 11:59:30 -0700 (PDT) Received: by 10.140.26.209 with HTTP; Wed, 2 Oct 2013 11:59:30 -0700 (PDT) In-Reply-To: References: <20130825203831.20582.30133.idtracker@ietfa.amsl.com> <20131001.204034.194996395.mbj@tail-f.com> Date: Wed, 2 Oct 2013 11:59:30 -0700 Message-ID: From: Andy Bierman To: "Lange, Jeffrey K (GE Energy Management)" Content-Type: multipart/alternative; boundary=047d7bb042524c155304e7c6ab0d Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 19:14:04 -0000 --047d7bb042524c155304e7c6ab0d Content-Type: text/plain; charset=ISO-8859-1 Hi, On Wed, Oct 2, 2013 at 9:29 AM, Lange, Jeffrey K (GE Energy Management) < jeffrey.K.lange@ge.com> wrote: > > YANG identities are too extensible for this particular leaf. > > YANG enumerations are defined by a single centralized > > naming authority (IANA). The entire set of values is > > contained within 1 YANG statement. Identities are defined > > by any naming authority (hence the need for QNames). > > The entire set of values is unknowable since any YANG module > > can add new identity-stmts and extend it. > > > > My counter-argument is that by making the if type an identity you are > actually increasing the interoperability of things. Take the example where > there is a product that has a custom XYZ interface. In order to use the > XYZ interface seamlessly with the standard interfaces list (assuming the > current iftype enum) you would have to set the type to "other" then augment > in some other selector as to what the type of the interface is so that you > can augment in any XYZ specific configuration variables. If an external > management application wants to configure that interface, they already need > to special case the code to deal with that custom interface type. > > If you are saying the standard identifier does not support proprietary non-standard extensions, you are correct. IMO that is a feature, not a bug. You can augment the interface list with all the proprietary classifiers that you want. Or you can get IANA to assign new standard interface types. > This extra selector code is not interoperable because every vendor would > do it differently. If on the other hand, the current IANA iftype list was > converted to identities, then there is still a standard and common list of > values that the majority of all "standard" devices would be able to use for > their interfaces. BUT, it allows the extensibility of proprietary > interfaces in a STANDARD way. > > No -- just because my code can validate an identityref as being valid for the specified base, it does not imply that my code knows what your identity means. It is no more valuable than 'other' unless the client knows the non-standard extension. > > A lot of investment has been made in the IANA interface > > type registry and I want vendors to use it. If every > > vendor can replace these enums with their own definitions, > > then 3rd party clients will have to hard-code the identities > > used by each server vendor. That is not very interoperable. > > I am in no way advocating abandoning this registry, but forewarning that > if it is overly restrictive in allowing someone to do what they need, it > won't get used at all. > > I do not agree the current IANA-based registry is unusable. > >Andy > > Andy --047d7bb042524c155304e7c6ab0d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,


On Wed, Oct 2, 2013 at 9:29 AM, Lange, Jeffrey K (GE Energy Man= agement) <jeffrey.K.lange@ge.com> wrote:
> YANG identities are too extensible for this particula= r leaf.
> YANG enumerations are defined by a single centralized
> naming authority (IANA). =A0The entire set of values is
> contained within 1 YANG statement. =A0Identities are defined
> by any naming authority (hence the need for QNames).
> The entire set of values is unknowable since any YANG module
> can add new identity-stmts and extend it.
>

My counter-argument is that by making the if type an identity you are actua= lly increasing the interoperability of things. =A0Take the example where th= ere is a product that has a custom XYZ interface. =A0In order to use the XY= Z interface seamlessly with the standard interfaces list (assuming the curr= ent iftype enum) you would have to set the type to "other" then a= ugment in some other selector as to what the type of the interface is so th= at you can augment in any XYZ specific configuration variables. If an exter= nal management application wants to configure that interface, they already = need to special case the code to deal with that custom interface type.



If you are saying the s= tandard identifier does not support proprietary
non-standard exte= nsions, you are correct. =A0IMO that is a feature, not a bug.
You can augment the interface list with all the proprietary classifiers tha= t
you want. =A0Or you can get IANA to assign new standard interfa= ce types.


=A0
This extra selector code is not interoperable because every vendor would do= it differently. If on the other hand, the current IANA iftype list was con= verted to identities, then there is still a standard and common list of val= ues that the majority of all "standard" devices would be able to = use for their interfaces. BUT, it allows the extensibility of proprietary i= nterfaces in a STANDARD way.



No -- just because my c= ode can validate an identityref as
being valid for the specified = base, it does not imply that my code
knows what your identity mea= ns. =A0It is no more valuable
than 'other' unless the client knows the non-standard extensio= n.

=A0
> A lot of investment has been made in the IANA interface
> type registry and I want vendors to use it. =A0If every
> vendor can replace these enums with their own definitions,
> then 3rd party clients will have to hard-code the identities
> used by each server vendor. =A0That is not very interoperable.

I am in no way advocating abandoning this registry, but forewarning that if= it is overly restrictive in allowing someone to do what they need, it won&= #39;t get used at all.


I do not agree the current IANA-based = registry is unusable.
=A0
>Andy



Andy

--047d7bb042524c155304e7c6ab0d-- From lhotka@nic.cz Wed Oct 2 12:30:14 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A61A21F991E for ; Wed, 2 Oct 2013 12:30:14 -0700 (PDT) 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 5xx9c1SD4Fwq for ; Wed, 2 Oct 2013 12:30:05 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 88EB221F9E6D for ; Wed, 2 Oct 2013 12:16:06 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 9039813FCD8; Wed, 2 Oct 2013 21:16:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1380741364; bh=GopH5tBrx/kC+MpD8ZRHSnvnfQkJ5X9ql1D+6RCF+yE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=iqtBx87AOaLLaPqd/0AQaH+BWsWs0Q6JFfhgh0WKEcX9oZjTFHv9ZElevWTClrx/I VJw0nu1yEyK5OUFUfDZcTznbwI5uRJY/qoxP8iJFXN1FY6G0fSUYvZpHbznM1c6CNY pVN+Qc0OccAXCvlcHsYDBwEKdqMLVJOfgrPJZyWg= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 2 Oct 2013 21:16:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130825203831.20582.30133.idtracker@ietfa.amsl.com> <20131001.204034.194996395.mbj@tail-f.com> To: "Lange, Jeffrey K (GE Energy Management)" X-Mailer: Apple Mail (2.1510) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 19:30:14 -0000 On Oct 2, 2013, at 5:46 PM, "Lange, Jeffrey K (GE Energy Management)" = wrote: >>=20 >> There is one technical issue, namely that there is no support for = identities in >> XPath expressions: >>=20 >> 1. 'must' and 'when' conditions based on equality of identities are = necessarily >> fragile. Consider an equivalent for >>=20 >> when "if:type =3D 'ethernetCsmacd'"; >>=20 >> With identities, the XPath expression would have to match *qualified >> names* of identities, and this cannot be done properly, i.e., without = relying >> on the equality of namespace prefixes. >>=20 >=20 > I'm not seeing how this is different than having: > module iana-if-type { > namespace "urn:ietf:params:xml:ns:yang:iana-if-type"; > prefix ianaift; >=20 > identity iftype { > description > "Base Interface type"; > } > identity ethernetCsmacd { > base iftype; > description > "Ethernet interface type"; > } > } >=20 > And then using: > when "if:type =3D 'ianaift:ethernetCsmacd"; >=20 > This is in essence what I am doing today, and it works perfectly fine. The "identityref" type doesn't have a canonical form, so the value of = "if:type" may use another prefix than "ianaift" or sometimes even no = prefix, and then the XPath string comparison will break. =20 >=20 >> 2. It is impossible to make use of the hierarchy of identities. For = example, >> suppose you modify a standard interface X into a new interface type = Y, and >> you want to reuse configuration parameters of type X and perhaps add >> several new ones. Then, if the parameters of X are defined with >>=20 >> when "if:type =3D X"; >>=20 >> you are out of luck because the interface type is Y !=3D X. What's = really needed >> in this case is to >> have Y as an identity derived from X, and then specify the 'when' = condition >> for X like this: >>=20 >> when "yang:derived-from(if:type, X)"; >>=20 >=20 > I don't see how either enums or identities have any bearing on the = above. Take the example in appendix A of interfaces-cfg. The parameters defined = in that module cannot be reused by an interface type other than = 'ethernetCsmacd', even if it is only a slightly modified Ethernet.=20 Lada >=20 > -Jeff >=20 >=20 >> Interface types based on the IANA registry do not have problem #1 = but, on >> the other hand, they do not offer any solution to #2 (and probably = never >> will). >>=20 >> Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Wed Oct 2 12:37:53 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 904CC21F995B for ; Wed, 2 Oct 2013 12:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.773 X-Spam-Level: X-Spam-Status: No, score=-1.773 tagged_above=-999 required=5 tests=[AWL=0.226, 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 K3bjcfjWx3d8 for ; Wed, 2 Oct 2013 12:37:46 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1D921F9A50 for ; Wed, 2 Oct 2013 12:27:11 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 5E5681400F5; Wed, 2 Oct 2013 21:27:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1380742030; bh=dyJPRTYMkyafeeJzPDOJWRF0v6m4VKzOeuKb/TdDJWI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=VYGw5hCMyR4xB0Wgt7jdlDkMsQKy4mXCJh/Qc7e3vF40dEdk6MXpTvN5rXcD+qG2i k/9ZMyFR7nL+QojWOt5NGvtAMktcwf9v4uSpgFYLkDOHEEW+xxyhOLZpYaOc5/uAms g39yzaODZHCAnOP2M5PJQi8D1GecnzdmcMoZ9Sxs= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 2 Oct 2013 21:27:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8BB44E11-62C4-45FC-AABB-A1867EF8CDD1@nic.cz> References: <20130825203831.20582.30133.idtracker@ietfa.amsl.com> <20131001.204034.194996395.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1510) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 19:37:53 -0000 On Oct 2, 2013, at 6:06 PM, Andy Bierman wrote: >=20 >=20 >=20 > On Wed, Oct 2, 2013 at 6:18 AM, Lange, Jeffrey K (GE Energy = Management) wrote: >=20 >=20 > >> We have lots of custom interface types, and one-off designs that = would mean absolutely > >> nothing to the Internet community at large. If we need to submit = to an international standard > >> body every time we want to create a new custom interface type, it = just doesn't make any sense. > >> If this was an identity, with all the currently defined = iana-iftypes defined as identities sharing the > >> same common base identity type, we (and others in the same position = as us) would be simply > >> define a new interface type by creating a new identity in our yang = models >=20 >=20 > > This is a standard module so we need to make sure that there is > > some hope of interoperability. I think you can augment the module > > with additional classifiers that only your apps understand (since = they > > are the only ones that understand your if-type enums). Pick the > > closest enum or use 'other' as a last resort. >=20 > >Andy >=20 > Perhaps I'm missing part of an old conversation, but what would the = drawbacks be to making the if type an identity vs an enum? Is it simply = and argument of "we don't' want to change it" or is there a more = fundamental technical reason that it must remain an enum? I think the = arguments for making it an identity are pretty compelling from an = extensibility standpoint. >=20 >=20 > YANG identities are too extensible for this particular leaf. > YANG enumerations are defined by a single centralized > naming authority (IANA). The entire set of values is > contained within 1 YANG statement. Identities are defined > by any naming authority (hence the need for QNames). > The entire set of values is unknowable since any YANG module > can add new identity-stmts and extend it. >=20 > A lot of investment has been made in the IANA interface > type registry and I want vendors to use it. If every Hmm=85 The registry contains many values that are obsolete, obscure or = even funny ("coffee"), but the most common interface types are = represented only by very general entries - all Ethernet interfaces fall = under ethernetCsmacd, and different types of tunnels also have only one = entry "tunnel". That's probably why vendors don't use the registry in = their CLIs. Lada =20 > vendor can replace these enums with their own definitions, > then 3rd party clients will have to hard-code the identities > used by each server vendor. That is not very interoperable. >=20 >=20 >=20 > -Jeff >=20 > Andy >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Wed Oct 2 13:00:57 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9F621F9DCE for ; Wed, 2 Oct 2013 13:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.656 X-Spam-Level: X-Spam-Status: No, score=-2.656 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 YEnLvovZetd0 for ; Wed, 2 Oct 2013 13:00:45 -0700 (PDT) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABBB21F9EE9 for ; Wed, 2 Oct 2013 12:51:35 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id j7so4674754qaq.5 for ; Wed, 02 Oct 2013 12:51:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NUuYhPSdtdBcCUZGgFgX/mu/nA/zy9Rl0d1c8HLr1X8=; b=MJmbdXdRzZT1sNQ6refT8QmKkCvrnAF9wxQ4yis8Rdg6k/a2TmA3QJ8d7xfl7Op4yk eAK6LtOOhbkff/qlMUWQM7Qrw9Sv+Y9DvgDZOtvc5P41wHGv2ejLdvkhtBX38jWFWvI6 8dag5oxTQ9AdHSujPWTdMdD7nehh2cy5JhuoF761SyvOAXHTZ9FNv+qwonRA1gDW9dhH ThnUOsCwfNt5MTyWEbLEqEOLBFtO7v5zZ33FnmkwZH2ozrE+yIgvfVdN76zC9PEIJUcW wozpmnzN53aGs2yDIyJ6gUKEwZP+LqgnQr0dQU1KJfT9hJpQJ+ocPvj4fOl0uUViBM/+ MoKg== X-Gm-Message-State: ALoCoQk45nSAIUIUtYBpZJZ1tFCO1qV8oF4lz7HtwU4Puw60eybyGt3vXK9jOlgyJAwp61SNOz/f MIME-Version: 1.0 X-Received: by 10.224.130.72 with SMTP id r8mr5946339qas.32.1380743494951; Wed, 02 Oct 2013 12:51:34 -0700 (PDT) Received: by 10.140.26.209 with HTTP; Wed, 2 Oct 2013 12:51:34 -0700 (PDT) In-Reply-To: <8BB44E11-62C4-45FC-AABB-A1867EF8CDD1@nic.cz> References: <20130825203831.20582.30133.idtracker@ietfa.amsl.com> <20131001.204034.194996395.mbj@tail-f.com> <8BB44E11-62C4-45FC-AABB-A1867EF8CDD1@nic.cz> Date: Wed, 2 Oct 2013 12:51:34 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a1132ec708af39904e7c765d1 Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 20:00:57 -0000 --001a1132ec708af39904e7c765d1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Oct 2, 2013 at 12:27 PM, Ladislav Lhotka wrote: > > On Oct 2, 2013, at 6:06 PM, Andy Bierman wrote: > > ... > > A lot of investment has been made in the IANA interface > > type registry and I want vendors to use it. If every > > Hmm=85 The registry contains many values that are obsolete, obscure or ev= en > funny ("coffee"), but the most common interface types are represented onl= y > by very general entries - all Ethernet interfaces fall under > ethernetCsmacd, and different types of tunnels also have only one entry > "tunnel". That's probably why vendors don't use the registry in their CLI= s. > > If many vendors are not able to pick appropriate standard enumerations for their standard interface types, then that is a general problem that affects SNMP ifType and NETCONF if-type. I am not aware of such a problem. I expect the registry to contain all entries ever assigned, so the values never get reused inadvertently. > Lada > > Andy --001a1132ec708af39904e7c765d1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On Wed, Oct 2, 2013 at 12:27 PM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:

On Oct 2, 2013, at 6:06 PM, Andy Bierman <andy@yumaworks.com> wrote:

...
> A lot of investment has been made in the IANA interface
> type registry and I want vendors to use it. =A0If every

Hmm=85 The registry contains many values that are obsolete, obscure or even= funny ("coffee"), but the most common interface types are repres= ented only by very general entries - all Ethernet interfaces fall under eth= ernetCsmacd, and different types of tunnels also have only one entry "= tunnel". That's probably why vendors don't use the registry in= their CLIs.



If many vendors are not= able to pick appropriate standard enumerations
for their standar= d interface types, then that is a general problem
that affects SN= MP ifType and NETCONF if-type. =A0I am not aware of
such a problem.

I expect the registry to cont= ain all entries ever assigned, so
the values never get reused ina= dvertently.

=A0
Lada



Andy

--001a1132ec708af39904e7c765d1-- From jeffrey.K.lange@ge.com Wed Oct 2 13:01:29 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C3021F89FF for ; Wed, 2 Oct 2013 13:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.667, 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 MwL+JKX5-Tt4 for ; Wed, 2 Oct 2013 13:01:17 -0700 (PDT) Received: from exprod5og108.obsmtp.com (exprod5og108.obsmtp.com [64.18.0.186]) by ietfa.amsl.com (Postfix) with ESMTP id 123AA21F9FB5 for ; Wed, 2 Oct 2013 12:52:15 -0700 (PDT) Received: from alpmlip14.e2k.ad.ge.com ([12.43.191.1]) (using TLSv1) by exprod5ob108.postini.com ([64.18.4.12]) with SMTP ID DSNKUkx5bgCDINmSK7iJfktG8s2ehn24JV0f@postini.com; Wed, 02 Oct 2013 12:52:16 PDT Received: from unknown (HELO CINMBHT03.e2k.ad.ge.com) ([3.159.212.196]) by alpmlip14.e2k.ad.ge.com with ESMTP/TLS/AES128-SHA; 02 Oct 2013 15:52:13 -0400 Received: from CINMLCH01.e2k.ad.ge.com (3.159.212.50) by CINMBHT03.e2k.ad.ge.com (3.159.212.196) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 2 Oct 2013 15:52:13 -0400 Received: from CINURAPD15.e2k.ad.ge.com (3.159.212.143) by cinmlch01.e2k.ad.ge.com (3.159.212.50) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 2 Oct 2013 15:52:12 -0400 Received: from CINURCNA15.e2k.ad.ge.com ([169.254.3.234]) by CINURAPD15.e2k.ad.ge.com ([169.254.9.49]) with mapi id 14.03.0146.000; Wed, 2 Oct 2013 15:52:12 -0400 From: "Lange, Jeffrey K (GE Energy Management)" To: Ladislav Lhotka , Andy Bierman Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt Thread-Index: AQHOodMlLyqCZb9RQkC9WKRHJHDjA5ngXCKwgABOsgD//8GvEIAAUmyAgADgLUCAAHMHgIAAOAqA///Dy2A= Date: Wed, 2 Oct 2013 19:52:11 +0000 Message-ID: References: <20130825203831.20582.30133.idtracker@ietfa.amsl.com> <20131001.204034.194996395.mbj@tail-f.com> <8BB44E11-62C4-45FC-AABB-A1867EF8CDD1@nic.cz> In-Reply-To: <8BB44E11-62C4-45FC-AABB-A1867EF8CDD1@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 20:01:30 -0000 > > > > A lot of investment has been made in the IANA interface > > type registry and I want vendors to use it. If every >=20 > Hmm... The registry contains many values that are obsolete, obscure or ev= en > funny ("coffee"), but the most common interface types are represented > only by very general entries - all Ethernet interfaces fall under > ethernetCsmacd, and different types of tunnels also have only one entry > "tunnel". That's probably why vendors don't use the registry in their CLI= s. +1 >=20 > Lada From andy@yumaworks.com Wed Oct 2 13:12:34 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C11AA21F9E99 for ; Wed, 2 Oct 2013 13:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 R2mHN+aIfDyY for ; Wed, 2 Oct 2013 13:12:22 -0700 (PDT) Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB1121F9ECA for ; Wed, 2 Oct 2013 13:05:42 -0700 (PDT) Received: by mail-qe0-f45.google.com with SMTP id 6so988322qea.18 for ; Wed, 02 Oct 2013 13:05:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=J1QnAaNGaTuOazKBM/0Zk/pE3m+HOQKdgHADB6zuv3M=; b=glTpiCjfD5E510DPSvOJRMAE2QqdXCxBvwsoJDnWvgq2OSCqfhZ1qhYtn3Ois4ltYQ 4dJvskqc6MDu+/lYAUSzFz11NHQ5oPVsLEeQLSUJGkzYbPBnv3yp2jpHoAOuMBhShiOD uNR2+3EJ3BN/xGdD5r+umnX7OU0RZwLU2tLLtGl+Q9wkQvlDBicPie89hwm/VgJmycfH ZkhVIgsEFQNYDriWDg69RAtoh5gOtro/y114xlK7qWFQg0Ul3bDdAJaInIUs1qsHykdK gOycifhiq7LgFHZwbaUwwFqRmrIhkB9aVKqCsLKI/tWXJFYCqNjrj1DRp4OSDLSR9djH Y1sg== X-Gm-Message-State: ALoCoQlYPX6wypiP+aql4wgzsZ/bnKMwUih6Zo1hjOmpeKi+HNwya31KGtMxzyH8Q0T3WGhFA63f MIME-Version: 1.0 X-Received: by 10.224.69.132 with SMTP id z4mr5861032qai.78.1380744341461; Wed, 02 Oct 2013 13:05:41 -0700 (PDT) Received: by 10.140.26.209 with HTTP; Wed, 2 Oct 2013 13:05:41 -0700 (PDT) In-Reply-To: References: <20130825203831.20582.30133.idtracker@ietfa.amsl.com> <20131001.204034.194996395.mbj@tail-f.com> <8BB44E11-62C4-45FC-AABB-A1867EF8CDD1@nic.cz> Date: Wed, 2 Oct 2013 13:05:41 -0700 Message-ID: From: Andy Bierman To: "Lange, Jeffrey K (GE Energy Management)" Content-Type: multipart/alternative; boundary=001a11c2310effab1704e7c7978e Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 20:12:34 -0000 --001a11c2310effab1704e7c7978e Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 2, 2013 at 12:52 PM, Lange, Jeffrey K (GE Energy Management) < jeffrey.K.lange@ge.com> wrote: > > > > > > A lot of investment has been made in the IANA interface > > > type registry and I want vendors to use it. If every > > > > Hmm... The registry contains many values that are obsolete, obscure or > even > > funny ("coffee"), but the most common interface types are represented > > only by very general entries - all Ethernet interfaces fall under > > ethernetCsmacd, and different types of tunnels also have only one entry > > "tunnel". That's probably why vendors don't use the registry in their > CLIs. > > +1 > > I do not object to an additional optional leaf that is type identityref. Inventing a new standard interface classification system takes time. I do not like using embedded semantics in the interface name to add classifiers to the interface. Something like: identity interface-clasifier; Add to /interfaces/interface: leaf classifier { type identityref { base interface-classifier; } description } > > > Lada > --001a11c2310effab1704e7c7978e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Oct 2, 2013 at 12:52 PM, Lange, Jeffrey K (GE Energy Manage= ment) <jeffrey.K.lange@ge.com> wrote:
> >
> > A lot of investment has been made in the IANA interface
> > type registry and I want vendors to use it. =A0If every
>
> Hmm... The registry contains many values that are obsolete, obscure or= even
> funny ("coffee"), but the most common interface types are re= presented
> only by very general entries - all Ethernet interfaces fall under
> ethernetCsmacd, and different types of tunnels also have only one entr= y
> "tunnel". That's probably why vendors don't use the = registry in their CLIs.

+1


I do not object to an additional optio= nal leaf that is type identityref.
Inventing a new standard inter= face classification system takes time.
I do not like using embedd= ed semantics in the interface name
to add classifiers to the interface. Something like:


identity interface-clasifier;

Add to /interfaces/interface:

=A0 =A0 leaf clas= sifier {
=A0 =A0 =A0 =A0type identityref { base interface-classifier; }
=A0 =A0 =A0 =A0description

=A0 =A0 }
=

>
> Lada

--001a11c2310effab1704e7c7978e-- From andy@yumaworks.com Wed Oct 2 13:17:10 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD60A21F9E02 for ; Wed, 2 Oct 2013 13:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.748 X-Spam-Level: X-Spam-Status: No, score=-2.748 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 SMhgGIY-v9fP for ; Wed, 2 Oct 2013 13:16:46 -0700 (PDT) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by ietfa.amsl.com (Postfix) with ESMTP id CFA2621F89FF for ; Wed, 2 Oct 2013 13:10:43 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id j7so973349qaq.2 for ; Wed, 02 Oct 2013 13:10:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NIuQBUkD6WxI4Bxez1J9z+xMjHmnmKl8pnChd7miA74=; b=Ab8U/fvrAGEClVb05pBsjTSqAL+LxO3BRjR0obiPYMjCX6ikaRKWuwdbX/LmI555c8 PjLhPuGcGoyFVbH394ObRDvNygbHpMS104Nq0iyOXG6b8VpF4MzurNGauWk+4x654qVh HwiOpAfS7OebaQ1XzYhW1a0vzTiih8XA8oLAdjzR995phZvgGpq17E9tJ5HDuJFLPYUG Hk91ZUi5k+Nkg9SZ2F8xddIjAPyvJrMNiJXJgeWrQDslr7HASHjrDyVyYxG9n9n243MR rbJrGGmpJ9hPjIhu2HEpstKHGUaIMg8Xvc0eOWaWlhB/Mytw7enjzIrqwjXwGyWCKn7I GOZQ== X-Gm-Message-State: ALoCoQm25eoqBg7ltP0US5JPkNnfefKPt2d4uI+LDXoDcoMI9Q62iXNXNTVzHs/Yh9ryWROiUTE1 MIME-Version: 1.0 X-Received: by 10.49.0.234 with SMTP id 10mr5144020qeh.67.1380744643197; Wed, 02 Oct 2013 13:10:43 -0700 (PDT) Received: by 10.140.26.209 with HTTP; Wed, 2 Oct 2013 13:10:43 -0700 (PDT) In-Reply-To: References: <20130825203831.20582.30133.idtracker@ietfa.amsl.com> <20131001.204034.194996395.mbj@tail-f.com> <8BB44E11-62C4-45FC-AABB-A1867EF8CDD1@nic.cz> Date: Wed, 2 Oct 2013 13:10:43 -0700 Message-ID: From: Andy Bierman To: "Lange, Jeffrey K (GE Energy Management)" Content-Type: multipart/alternative; boundary=047d7b33d2e4fbd04b04e7c7a96b Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 20:17:10 -0000 --047d7b33d2e4fbd04b04e7c7a96b Content-Type: text/plain; charset=ISO-8859-1 oops - gmail sent this before I was done (I hate the new gmail!) On Wed, Oct 2, 2013 at 1:05 PM, Andy Bierman wrote: > > > > On Wed, Oct 2, 2013 at 12:52 PM, Lange, Jeffrey K (GE Energy Management) < > jeffrey.K.lange@ge.com> wrote: > >> > > >> > > A lot of investment has been made in the IANA interface >> > > type registry and I want vendors to use it. If every >> > >> > Hmm... The registry contains many values that are obsolete, obscure or >> even >> > funny ("coffee"), but the most common interface types are represented >> > only by very general entries - all Ethernet interfaces fall under >> > ethernetCsmacd, and different types of tunnels also have only one entry >> > "tunnel". That's probably why vendors don't use the registry in their >> CLIs. >> >> +1 >> >> > I do not object to an additional optional leaf that is type identityref. > Inventing a new standard interface classification system takes time. > I do not like using embedded semantics in the interface name > to add classifiers to the interface. Something like: > > > identity interface-classifier; > > Add to /interfaces/interface: > > leaf classifier { > type identityref { base interface-classifier; } > description > "Standard or vendor specific interface classification"; > > } > > Also add to /interfaces/interface-state, If the client knows what to provide it can set it in the interface entry when the interface is created. If not, it can read the interface-state to see if there is an additional classifier. > > > >> > Lada >> > > Andy --047d7b33d2e4fbd04b04e7c7a96b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

oops - gmail sent this befo= re I was done (I hate the new gmail!)

On = Wed, Oct 2, 2013 at 1:05 PM, Andy Bierman <andy@yumaworks.com> wrote:



On Wed, Oct 2, 2013 at 12:52 PM, Lan= ge, Jeffrey K (GE Energy Management) <jeffrey.K.lange@ge.com><= /span> wrote:
> >
> > A lot of investment has been made in the IANA interface
> > type registry and I want vendors to use it. =A0If every
>
> Hmm... The registry contains many values that are obsolete, obscure or= even
> funny ("coffee"), but the most common interface types are re= presented
> only by very general entries - all Ethernet interfaces fall under
> ethernetCsmacd, and different types of tunnels also have only one entr= y
> "tunnel". That's probably why vendors don't use the = registry in their CLIs.

+1


I do not object to an additional optio= nal leaf that is type identityref.
Inventing a new standard inter= face classification system takes time.
I do not like using embedd= ed semantics in the interface name
to add classifiers to the interface. Something like:


identity interface-classifier;

<= div>Add to /interfaces/interface:

=A0 =A0 leaf cla= ssifier {
=A0 =A0 =A0 =A0type identityref { base interface-classifier; }
=A0 =A0 =A0 =A0description
=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 "Standard or vendor specific interface cla= ssification"; =A0=A0
=

=A0 =A0 }



Also add to /interfac= es/interface-state,
If the client knows what to provide it can se= t it in the interface entry
when the interface is created. =A0If = not, it can read the interface-state
to see if there is an additional classifier.

= =A0

>
> Lada



Andy

--047d7b33d2e4fbd04b04e7c7a96b-- From andy@yumaworks.com Wed Oct 2 13:43:07 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D78BD21F8F2A for ; Wed, 2 Oct 2013 13:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.776 X-Spam-Level: X-Spam-Status: No, score=-2.776 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 hhkGBHJxymD2 for ; Wed, 2 Oct 2013 13:42:54 -0700 (PDT) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) by ietfa.amsl.com (Postfix) with ESMTP id D585121F9EAF for ; Wed, 2 Oct 2013 13:41:52 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id x19so953824qcw.2 for ; Wed, 02 Oct 2013 13:41:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4SKuOhnLotOQU/GaD4Ma0Q7cN5M4f5Js45cHkXGXhhk=; b=R140K/ZQnUjIJkvyvpSeSGLtYtEfZORo2YEZNll/sQG4e414IIi2geWNWA0rSyuRiy l6zIISl3qtrojzN8twNdJ7btyaFlxB4keueEDmSgCCfnAu5jOLv3lcPuI5ikMMuzAOza h/5fmrePvTlfmcrIjOX5+lvO/Wq/RqAFH8WZ2HDfQIsPUiQTpNu/DMlBBqImikHCDXx5 H450byDE70huC6kwxuVNDt9ql0WoR/ozvSUwswOPXVuHRpYociY03hx+++PwfyUV56P6 r6TjEFsxC1sWijZt7I0Whed0tueIGKfSVcb13jZqZP7jc/5OWyWZ8sbAkod/Q66blC08 F3og== X-Gm-Message-State: ALoCoQlPw15UJQtArFli44KIYisJICqnzg3U7ESVrl8Yssl9UKOFOjmghDI4NHPnKrQH32TPOukQ MIME-Version: 1.0 X-Received: by 10.224.69.132 with SMTP id z4mr6036868qai.78.1380746510932; Wed, 02 Oct 2013 13:41:50 -0700 (PDT) Received: by 10.140.26.209 with HTTP; Wed, 2 Oct 2013 13:41:50 -0700 (PDT) In-Reply-To: References: Date: Wed, 2 Oct 2013 13:41:50 -0700 Message-ID: From: Andy Bierman To: "Alexander Clemm (alex)" Content-Type: multipart/alternative; boundary=001a11c2310e4f2bcb04e7c81907 Cc: "netmod@ietf.org" Subject: Re: [netmod] New version of netmod mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 20:43:07 -0000 --001a11c2310e4f2bcb04e7c81907 Content-Type: text/plain; charset=ISO-8859-1 Hi, I have read this draft and it does raise some issues that impact the protocol and data models, namely -- how to manage more than 1 server at once. IMO the NFS-like mount points do not address the important issue, which is that NETCONF/YANG has no architecture or standard solution for network-wide management of multiple NETCONF servers.. Using an aggregation point that has the individual config-lets from N servers patched into 1 container may not be the most appropriate abstraction for network-wide data models or a network controller entity. I think confirmed-commit is supposed to be the answer to network-wide configuration support in NETCONF, but it is not good enough. IMO it would be better to have well-defined relationships between servers, based on use-cases. (e.g, link-pair, cluster, network). Andy On Sun, Sep 22, 2013 at 2:09 AM, Alexander Clemm (alex) wrote: > Hello, > > Just as an FYI, we have just posted a new revision of > draft-clemm-netmod-mount. The revisions are minor in nature and contain > for the most part additional clarifications around the concept of attaching > data from remote data stores into a local data stores and regarding how the > mount points will be managed. We hope to have a time slot in Vancouver for > a brief presentation and discussion. > > Kind regards > --- Alex, Jan, Eric > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Sunday, September 22, 2013 2:01 AM > To: Alexander Clemm (alex); Eric Voit (evoit); Jan Medved (jmedved); > Alexander Clemm (alex) > Subject: New Version Notification for draft-clemm-netmod-mount-01.txt > > > A new version of I-D, draft-clemm-netmod-mount-01.txt has been > successfully submitted by Alexander Clemm and posted to the IETF repository. > > Filename: draft-clemm-netmod-mount > Revision: 01 > Title: Mounting YANG-Defined Information from Remote Datastores > Creation date: 2013-09-22 > Group: Individual Submission > Number of pages: 29 > URL: > http://www.ietf.org/internet-drafts/draft-clemm-netmod-mount-01.txt > Status: http://datatracker.ietf.org/doc/draft-clemm-netmod-mount > Htmlized: http://tools.ietf.org/html/draft-clemm-netmod-mount-01 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-clemm-netmod-mount-01 > > Abstract: > This document introduces a new capability that allows YANG datastores > to reference and incorporate information from remote datastores. > This is accomplished using a new YANG data model that allows to > define and manage datastore mount points that reference data nodes in > remote datastores. The data model includes a set of YANG extensions > for the purposes of declaring such mount points. > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11c2310e4f2bcb04e7c81907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I have read this draft and it does = raise some issues that impact
the protocol and data models, namel= y -- how to manage more than
1 server at once.

IMO the NFS-like mount points do not address the important issue,
which is that NETCONF/YANG has no architecture or standard
= solution for network-wide management of multiple NETCONF servers..

Using an aggregation point that has the individual conf= ig-lets from N servers
patched into 1 container may not be the mo= st appropriate abstraction for network-wide
data models or a network controller entity.

I think confirmed-commit is supposed = to be the answer to network-wide
configurat= ion support in NETCONF, but it is not good enough. IMO it
would be better to have well-defined relationshi= ps between servers,
based on use-cases. (e.= g, link-pair, cluster, network).

=


A= ndy

On Sun, Sep 22, 2013 at 2:09 AM, Alexander Cle= mm (alex) <alex@cisco.com> wrote:
Hello,

Just as an FYI, we have just posted a new revision of draft-clemm-netmod-mo= unt. =A0The revisions are minor in nature and contain for the most part add= itional clarifications around the concept of attaching data from remote dat= a stores into a local data stores and regarding how the mount points will b= e managed. =A0We hope to have a time slot in Vancouver for a brief presenta= tion and discussion.

Kind regards
--- Alex, Jan, Eric

-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Sunday, September 22, 2013 2:01 AM
To: Alexander Clemm (alex); Eric Voit (evoit); Jan Medved (jmedved); Alexan= der Clemm (alex)
Subject: New Version Notification for draft-clemm-netmod-mount-01.txt


A new version of I-D, draft-clemm-netmod-mount-01.txt has been successfully= submitted by Alexander Clemm and posted to the IETF repository.

Filename: =A0 =A0 =A0 =A0draft-clemm-netmod-mount
Revision: =A0 =A0 =A0 =A001
Title: =A0 =A0 =A0 =A0 =A0 Mounting YANG-Defined Information from Remote Da= tastores
Creation date: =A0 2013-09-22
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 29
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/int= ernet-drafts/draft-clemm-netmod-mount-01.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draf= t-clemm-netmod-mount
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-clemm-n= etmod-mount-01
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/rfcdiff?= url2=3Ddraft-clemm-netmod-mount-01

Abstract:
=A0 =A0This document introduces a new capability that allows YANG datastore= s
=A0 =A0to reference and incorporate information from remote datastores.
=A0 =A0This is accomplished using a new YANG data model that allows to
=A0 =A0define and manage datastore mount points that reference data nodes i= n
=A0 =A0remote datastores. =A0The data model includes a set of YANG extensio= ns
=A0 =A0for the purposes of declaring such mount points.




Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

_______________________________________________
netmod mailing list
netmod@ietf.org
= https://www.ietf.org/mailman/listinfo/netmod

--001a11c2310e4f2bcb04e7c81907-- From jeffrey.K.lange@ge.com Fri Oct 4 08:15:16 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C5C21F9D9A for ; Fri, 4 Oct 2013 08:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.500, 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 dw3PWVv59+rW for ; Fri, 4 Oct 2013 08:15:02 -0700 (PDT) Received: from exprod5og112.obsmtp.com (exprod5og112.obsmtp.com [64.18.0.24]) by ietfa.amsl.com (Postfix) with ESMTP id CF3B421F9D68 for ; Fri, 4 Oct 2013 08:12:15 -0700 (PDT) Received: from alpmlip11.e2k.ad.ge.com ([165.156.5.1]) (using TLSv1) by exprod5ob112.postini.com ([64.18.4.12]) with SMTP ID DSNKUk7azgdeC6CfRDaxiKnUC/q2P4PoRWXM@postini.com; Fri, 04 Oct 2013 08:12:15 PDT Received: from unknown (HELO CINMBHT02.e2k.ad.ge.com) ([3.159.212.195]) by alpmlip11.e2k.ad.ge.com with ESMTP/TLS/AES128-SHA; 04 Oct 2013 11:12:13 -0400 Received: from CINURCNA02.e2k.ad.ge.com (3.159.212.103) by CINMBHT02.e2k.ad.ge.com (3.159.212.195) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 4 Oct 2013 11:12:12 -0400 Received: from CINURCNA15.e2k.ad.ge.com ([169.254.3.234]) by CINURCNA02.e2k.ad.ge.com ([169.254.3.118]) with mapi id 14.03.0146.000; Fri, 4 Oct 2013 11:12:12 -0400 From: "Lange, Jeffrey K (GE Energy Management)" To: "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt Thread-Index: AQHOodMlLyqCZb9RQkC9WKRHJHDjA5ngXCKwgABOsgD//8GvEIAAUmyAgADgLUCAAHMHgIAAOAqA///Dy2CAAEb5gIAAAWiAgAKMDnA= Date: Fri, 4 Oct 2013 15:12:12 +0000 Message-ID: References: <20130825203831.20582.30133.idtracker@ietfa.amsl.com> <20131001.204034.194996395.mbj@tail-f.com> <8BB44E11-62C4-45FC-AABB-A1867EF8CDD1@nic.cz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 15:15:17 -0000 Unrelated to previous messages about this draft, Why is it that /ip-state/i= pv6/neighbor has a 'state' leaf (incomplete/reachable/etc..), but /ip-state= /ipv4/neighbor does not? This is valid for ipv4 neighbors as well. e.g on Linux: # ip neigh show 192.168.1.2 dev eth0 lladdr 00:12:17:5c:4f:2d STALE I also question why the neighbor entries are at the top-level ip-state as o= pposed to per-interface? If you are configuring static ARP entries, you do= it at the interface level, not at some top-level IP configuration containe= r. It seems to follow that the state should match the same hierarchy. Thi= s would allow the removal of the interface lead from the neighbor list, as = it would already be relative to a specific interface. -Jeff From jeffrey.K.lange@ge.com Fri Oct 4 13:41:32 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A56C21F9CB1 for ; Fri, 4 Oct 2013 13:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.400, 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 jyJNIMzoXVtS for ; Fri, 4 Oct 2013 13:41:26 -0700 (PDT) Received: from exprod5og107.obsmtp.com (exprod5og107.obsmtp.com [64.18.0.184]) by ietfa.amsl.com (Postfix) with ESMTP id E47E321F9C7B for ; Fri, 4 Oct 2013 13:41:24 -0700 (PDT) Received: from cinmlip10.e2k.ad.ge.com ([165.156.4.1]) (using TLSv1) by exprod5ob107.postini.com ([64.18.4.12]) with SMTP ID DSNKUk8n84DiwqbqvsHFVdIHp7W1bp0wU63i@postini.com; Fri, 04 Oct 2013 13:41:25 PDT Received: from unknown (HELO CINMBHT02.e2k.ad.ge.com) ([3.159.212.195]) by cinmlip10.e2k.ad.ge.com with ESMTP/TLS/AES128-SHA; 04 Oct 2013 16:41:21 -0400 Received: from CINURCNA17.e2k.ad.ge.com (3.159.212.154) by CINMBHT02.e2k.ad.ge.com (3.159.212.195) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 4 Oct 2013 16:41:15 -0400 Received: from CINURCNA15.e2k.ad.ge.com ([169.254.3.234]) by CINURCNA17.e2k.ad.ge.com ([169.254.5.63]) with mapi id 14.03.0146.000; Fri, 4 Oct 2013 16:41:15 -0400 From: "Lange, Jeffrey K (GE Energy Management)" To: "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt Thread-Index: AQHOodMlLyqCZb9RQkC9WKRHJHDjA5ngXCKwgABOsgD//8GvEIAAUmyAgADgLUCAAHMHgIAAOAqA///Dy2CAAEb5gIAAAWiAgAKMDnCAAF1hgA== Date: Fri, 4 Oct 2013 20:41:14 +0000 Message-ID: References: <20130825203831.20582.30133.idtracker@ietfa.amsl.com> <20131001.204034.194996395.mbj@tail-f.com> <8BB44E11-62C4-45FC-AABB-A1867EF8CDD1@nic.cz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 20:41:32 -0000 Also, in regards to the neighbor state enum values. Is there a reason it d= oes not also include the standard values of: - failed - noarp - permanent -Jeff > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On > Behalf Of Lange, Jeffrey K (GE Energy Management) > Sent: Friday, October 04, 2013 11:12 AM > To: netmod@ietf.org > Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt >=20 > Unrelated to previous messages about this draft, Why is it that /ip- > state/ipv6/neighbor has a 'state' leaf (incomplete/reachable/etc..), but = /ip- > state/ipv4/neighbor does not? >=20 > This is valid for ipv4 neighbors as well. e.g on Linux: > # ip neigh show > 192.168.1.2 dev eth0 lladdr 00:12:17:5c:4f:2d STALE >=20 > I also question why the neighbor entries are at the top-level ip-state as > opposed to per-interface? If you are configuring static ARP entries, you= do it > at the interface level, not at some top-level IP configuration container.= It > seems to follow that the state should match the same hierarchy. This wou= ld > allow the removal of the interface lead from the neighbor list, as it wou= ld > already be relative to a specific interface. >=20 > -Jeff >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From j.schoenwaelder@jacobs-university.de Mon Oct 7 04:40:35 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F6921E8088 for ; Mon, 7 Oct 2013 04:40:35 -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=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, 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 m7j9ZLOusVCI for ; Mon, 7 Oct 2013 04:40:31 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 09E4521E8087 for ; Mon, 7 Oct 2013 04:40:26 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 65121209DC; Mon, 7 Oct 2013 13:40:25 +0200 (CEST) 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 Rw3b150zKzNs; Mon, 7 Oct 2013 13:40:25 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EA97C209D7; Mon, 7 Oct 2013 13:40:24 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CBF1728B9FC5; Mon, 7 Oct 2013 13:40:19 +0200 (CEST) Date: Mon, 7 Oct 2013 13:40:19 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20131007114019.GA55745@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [netmod] Fwd: NOMCOM 2013 - Second Call for Nominations - two weeks left X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 11:40:36 -0000 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, please take notice. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --gBBFr7Ir9EOA20Yy Content-Type: message/rfc822 Content-Disposition: inline Received: from hermes.jacobs-university.de (212.201.44.23) by SHUBCAS01.jacobs.jacobs-university.de (10.70.0.128) with Microsoft SMTP Server id 14.3.158.1; Mon, 7 Oct 2013 13:19:25 +0200 Received: from atlas2.jacobs-university.de (atlas2a.jacobs-university.de [212.201.44.15]) by hermes.jacobs-university.de (Postfix) with ESMTP id CC0D82062F for ; Mon, 7 Oct 2013 13:19:25 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by atlas2.jacobs-university.de (Postfix) with ESMTP id C6D6B6BB for ; Mon, 7 Oct 2013 13:19:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de X-Spam-Flag: NO X-Spam-Score: -9.5 X-Spam-Level: X-Spam-Status: No, score=-9.5 tagged_above=-100 required=6.2 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Authentication-Results: demetrius4.jacobs-university.de (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from atlas2b.jacobs-university.de ([212.201.44.15]) by localhost (demetrius4.jacobs-university.de [212.201.44.49]) (amavisd-new, port 10030) with ESMTP id fkWjy7_M4uNS for ; Mon, 7 Oct 2013 13:19:23 +0200 (CEST) X-JacobsISPWhiteListed: No X-policyd-weight: NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_SPAMCOP=-1.5 CL_IP_EQ_FROM_MX=-3.1; rate: -6.1 Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by atlas2b.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 7 Oct 2013 13:19:22 +0200 (CEST) Received: from ams-iport-1.cisco.com ([144.254.224.140]:55377) by grenache.tools.ietf.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from ) id 1VT8pW-0007Np-9C for ops-chairs@tools.ietf.org; Mon, 07 Oct 2013 13:18:27 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12500; q=dns/txt; s=iport; t=1381144706; x=1382354306; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=7nBGZ//2Mj2hyvaTLv2muAfgigJRlNwYBE+MSwWwFGs=; b=TO4iF1djPehED83FF8WaFrJZY/QK96D0uedXrIwkX/5WY9Tegvu84YHf 9Y0ZQJDIsqW2g445wt1+Dhig1VWkG13fMXTLrTuIj6xDqtQ1/ZbWtShcz zPewiQJEsEPZTHeDevLpJTU0YIHwEGtHOwWA6yMbRfUp1l39w2gTatXkd g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMFAMmXUlKQ/khM/2dsb2JhbABZgwc4g3qFXbgWgRwWbQeCJQEBAQQdBkgNDQQcAwECCgwKCwICCQMCAQIBNAcCCAYNBgIBARCHcgyoWJIRjgiBOBgGBIJggTkDlCSDXYEvhQeLSoMmOoE1 X-IronPort-AV: E=Sophos;i="4.90,1049,1371081600"; d="scan'208,217";a="160408979" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 07 Oct 2013 11:18:19 +0000 Received: from [10.61.65.181] (ams3-vpn-dhcp437.cisco.com [10.61.65.181]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r97BIEWq005751 for ; Mon, 7 Oct 2013 11:18:16 GMT Message-ID: <52527773.9020400@cisco.com> Date: Mon, 7 Oct 2013 10:57:23 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 To: "ops-chairs@tools.ietf.org" References: <20131004173149.22991.14931.idtracker@ietfa.amsl.com> In-Reply-To: <20131004173149.22991.14931.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20131004173149.22991.14931.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------070809030201080105080506" X-SA-Exim-Connect-IP: 144.254.224.140 X-SA-Exim-Rcpt-To: ops-chairs@tools.ietf.org X-SA-Exim-Mail-From: bclaise@cisco.com X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on grenache.tools.ietf.org X-Spam-Level: X-Spam-Status: No, score=-7.5 required=3.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,T_DKIM_INVALID autolearn=ham version=3.3.2 Subject: Fwd: NOMCOM 2013 - Second Call for Nominations - two weeks left X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on grenache.tools.ietf.org) Resent-To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , List-ID: Return-Path: wg-alias-bounces@tools.ietf.org X-MS-Exchange-Organization-AuthSource: SHUBCAS01.jacobs.jacobs-university.de X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0 MIME-Version: 1.0 --------------070809030201080105080506 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Please forward to your WGs. Regards, Benoit -------- Original Message -------- Subject: NOMCOM 2013 - Second Call for Nominations - two weeks left Date: Fri, 4 Oct 2013 10:31:49 -0700 From: NomCom Chair 2013 Reply-To: , , , <"2013 To: IETF Announcement List CC: IETF Discuss List Nominations for the IESG, IAB, and IAOC are due to the Nomcom by Friday, 18 October, 2013. Is there someone you work with at IETF who has leadership potential and a growing track record? Please read the Nomcom call for nominations and consider nominating her or him. Or several folks! Deadline for nominations is October 18. Nominate soon to give your nominee(s) plenty time to fill in the questionnaire. Information about the desired expertise for positions is here: https://datatracker.ietf.org/nomcom/2013/expertise Lots more, including which positions are open, how to make a nomination, and how to send us your feedback on the desired expertise, follows. IETFers, let's hear from you! Make nominations, accept nominations! If you have any questions about the process, feel free to get in touch with me. Best regards, Allison for the Nomcom Allison Mankin Nomcom Chair 2013-14 ----- The Info You Need for Nominating ----- The 2013-14 Nominating Committee (Nomcom) is seeking nominations from now until October 18, 2013. The open positions being considered by this year's Nomcom can be found later in this section, and also on this year's Nomcom website: https://datatracker.ietf.org/nomcom/2013/ Nominations may be made by selecting the Nominate link at the top of the Nomcom 2013 home page, or by visiting the following URL: https://datatracker.ietf.org/nomcom/2013/nominate/ Note that nominations made using the web tool require an ietf.org datatracker account. You can create a datatracker ietf.org account if you don't have one already by visiting the following URL: https://datatracker.ietf.org/accounts/create/ Nominations may also be made by email to nomcom13 at ietf.org. If you nominate by email, please include the word "Nominate" in the Subject and indicate in the email who is being nominated, their email address (to confirm acceptance of the nomination), and the position for which you are making the nomination. If you use email, please use a separate email for each person you nominate, and for each position (if you are nominating one person for multiple positions). Self-nomination is welcome! No need to be shy. Nomcom 2013-14 will follow the policy for "Open Disclosure of Willing Nominees" described in RFC 5680. As stated in RFC 5680: "The list of nominees willing to be considered for positions under review in the current Nomcom cycle is not confidential". Willing nominees for each position will be listed in a publicly accessible way - anyone with a datatracker account may access the lists. In all other ways, the confidentiality requirements of RFC 3777/BCP10 remain in effect. All feedback and all Nomcom deliberations will remain confidential and will not be disclosed. In order to ensure time to collect sufficient community feedback about each of the willing nominees, nominations must be received by the Nomcom on or before October 18, 2013. Please submit your nominations as early as possible for the sake of your nominees, as we've set the questionnaire submission deadline for October 25, 2013. The list of people and posts whose terms end with the March 2014 IETF meeting, and thus the positions for which we are accepting nominations: IAOC Chris Griffiths IAB Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) Please be resourceful in identifying possible candidates for these positions, as developing our talent is a very crucial requirement for the IETF. Also, please give serious consideration to accepting nominations you receive. The summaries of the desired expertise for the positions, developed by the respective bodies, are found at: https://datatracker.ietf.org/nomcom/2013/expertise/ In addition to nominations, the Nomcom seeks community input on the positions themselves. We need and welcome the community's views and input on the jobs within each organization. If you have ideas on the positions' responsibilities (more, less, different), please let us know. You can send us email about this to nomcom13 at ietf.org, and we will use this feedback actively. Thank you for your help in nominating a great pool of strong and interesting nominees! . --------------070809030201080105080506 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 7bit Please forward to your WGs.

Regards, Benoit


-------- Original Message --------
Subject: NOMCOM 2013 - Second Call for Nominations - two weeks left
Date: Fri, 4 Oct 2013 10:31:49 -0700
From: NomCom Chair 2013 <nomcom-chair-2013@ietf.org>
Reply-To: <ietf@ietf.org>, <Nomcom@ietfa.amsl.com>, <Chair@ietfa.amsl.com>, <"2013 <nomcom-chair-2013"@ietf.org>
To: IETF Announcement List <ietf-announce@ietf.org>
CC: IETF Discuss List <ietf@ietf.org> 


Nominations for the IESG, IAB, and IAOC are due to the Nomcom by Friday, 18 October, 2013.

Is there someone you work with at IETF who has leadership potential and a growing track record? Please read the Nomcom call for nominations and consider nominating her or him. Or several folks! Deadline for nominations is October 18.  Nominate soon to give your nominee(s) plenty time to fill in the questionnaire. Information about the desired expertise for positions is here: 
           https://datatracker.ietf.org/nomcom/2013/expertise

Lots more, including which positions are open, how to make a nomination, and how to 
send us your feedback on the desired expertise, follows.

IETFers, let's hear from you!  Make nominations, accept nominations!

If you have any questions about the process, feel free to get in touch with me.

Best regards,

Allison for the Nomcom

Allison Mankin 
Nomcom Chair 2013-14

----- The Info You Need for Nominating -----

The 2013-14 Nominating Committee (Nomcom) is seeking nominations
from now until October 18, 2013. The open positions being considered
by this year's Nomcom can be found later in this section, and also on
this year's Nomcom website: 

https://datatracker.ietf.org/nomcom/2013/

Nominations may be made by selecting the Nominate link at the top of
the Nomcom 2013 home page, or by visiting the following URL: 

https://datatracker.ietf.org/nomcom/2013/nominate/

Note that nominations made using the web tool require an ietf.org 
datatracker account. You can create a datatracker ietf.org account 
if you don't have one already by visiting the following URL:

https://datatracker.ietf.org/accounts/create/

Nominations may also be made by email to nomcom13 at ietf.org.
If you nominate by email, please include the word "Nominate" in the Subject
and indicate in the email who is being nominated, their email address (to
confirm acceptance of the nomination), and the position for which you
are making the nomination. If you use email, please use a separate email for
each person you nominate, and for each position (if you are nominating one
person for multiple positions).

Self-nomination is welcome!  No need to be shy.

Nomcom 2013-14 will follow the policy for "Open Disclosure of Willing
Nominees" described in RFC 5680.  As stated in RFC 5680: "The list of
nominees willing to be considered for positions under review in the
current Nomcom cycle is not confidential". Willing nominees for each
position will be listed in a publicly accessible way - anyone with a
datatracker account may access the lists.  In all other ways, the 
confidentiality requirements of RFC 3777/BCP10 remain in effect.  All
feedback and all Nomcom deliberations will remain confidential and will
not be disclosed.  

In order to ensure time to collect sufficient community feedback about
each of the willing nominees, nominations must be received by the 
Nomcom on or before October 18, 2013.  Please submit your nominations  
as early as possible for the sake of your nominees, as we've set the 
questionnaire submission deadline for October 25, 2013.

The list of people and posts whose terms end with the March 2014 IETF meeting, 
and thus the positions for which we are accepting nominations:  

IAOC
Chris Griffiths

IAB
Bernard Aboba
Marc Blanchet
Ross Callon
Eliot Lear
Hannes Tschofenig

IESG
Barry Leiba (Applications)
Brian Haberman (Internet)
Benoit Claise (Operations and Management)
Gonzalo Camarillo (RAI)
Stewart Bryant (Routing)
Sean Turner (Security)
Martin Stiemerling (Transport)

Please be resourceful in identifying possible candidates for these
positions, as developing our talent is a very crucial requirement for
the IETF.  Also, please give serious consideration to accepting nominations
you receive.  
 
The summaries of the desired expertise for the positions, developed by the 
respective bodies, are found at:

https://datatracker.ietf.org/nomcom/2013/expertise/

In addition to nominations, the Nomcom seeks community input on 
the positions themselves.  We need and welcome the community's 
views and input on the jobs within each organization. If you 
have ideas on the positions' responsibilities (more, less, 
different), please let us know.  You can send us email about this to
nomcom13 at ietf.org, and we will use this feedback actively.

Thank you for your help in nominating a great pool of strong and interesting
nominees!



.


--------------070809030201080105080506-- --gBBFr7Ir9EOA20Yy-- From jeffrey.K.lange@ge.com Mon Oct 7 06:58:45 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF5421E81A6 for ; Mon, 7 Oct 2013 06:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.166 X-Spam-Level: X-Spam-Status: No, score=-4.166 tagged_above=-999 required=5 tests=[AWL=-1.767, BAYES_00=-2.599, J_CHICKENPOX_210=0.6, J_CHICKENPOX_22=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_28=0.6, 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 qbDQuvWj8YUv for ; Mon, 7 Oct 2013 06:58:39 -0700 (PDT) Received: from exprod5og108.obsmtp.com (exprod5og108.obsmtp.com [64.18.0.186]) by ietfa.amsl.com (Postfix) with ESMTP id AD6B921E818D for ; Mon, 7 Oct 2013 06:58:38 -0700 (PDT) Received: from alpmlip13.e2k.ad.ge.com ([12.43.191.1]) (using TLSv1) by exprod5ob108.postini.com ([64.18.4.12]) with SMTP ID DSNKUlK+DWRB0eBW5ZysEd/M6ctdjls7uor2@postini.com; Mon, 07 Oct 2013 06:58:38 PDT Received: from unknown (HELO ALPMBHT01.e2k.ad.ge.com) ([3.159.19.194]) by alpmlip13.e2k.ad.ge.com with ESMTP/TLS/AES128-SHA; 07 Oct 2013 09:58:36 -0400 Received: from CINMLCH01.e2k.ad.ge.com (3.159.212.50) by ALPMBHT01.e2k.ad.ge.com (3.159.19.194) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 7 Oct 2013 09:58:36 -0400 Received: from CINURCNA11.e2k.ad.ge.com (3.159.212.128) by cinmlch01.e2k.ad.ge.com (3.159.212.50) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 7 Oct 2013 09:58:35 -0400 Received: from CINURCNA15.e2k.ad.ge.com ([169.254.3.234]) by CINURCNA11.e2k.ad.ge.com ([169.254.5.127]) with mapi id 14.03.0146.000; Mon, 7 Oct 2013 09:58:35 -0400 From: "Lange, Jeffrey K (GE Energy Management)" To: "netmod@ietf.org" Thread-Topic: IP data model neighbor changes Thread-Index: Ac7DY6ti9Y7wYBbKSH2A4uvg0EDM0w== Date: Mon, 7 Oct 2013 13:58:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [netmod] IP data model neighbor changes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 13:58:46 -0000 In regards to my previous message about the lack of IPv4 neighbor state, I = would like to propose a change to the ietf-ip model that makes the followin= g changes: * Moves IPv4/IPv6 neighbors into /interface-state/interface/ipv[46]/neighbo= r - in doing this, remove the interface leaf from the list * Removes the top-level ip-state as the only thing in it was the neighbor e= ntries - /ip-state/ipv[46] presence containers are redundant as they already exi= st per interface * Moves the neighbor-state leafs into a typedef so it can be used in both I= Pv4 and IPv6 * Add failed, noarp, and permanent as neighbor-state enum values Feedback is welcome. Thanks -Jeff module: ietf-interfaces +--rw interfaces | +--rw interface [name] | +--rw name string | +--rw description? string | +--rw type identityref | +--rw enabled? boolean | +--rw link-up-down-trap-enable? enumeration | +--rw ip:ipv4? | | +--rw ip:enabled? boolean | | +--rw ip:forwarding? boolean | | +--rw ip:mtu? uint16 | | +--rw ip:address [ip] | | | +--rw ip:ip inet:ipv4-address-no-zone | | | +--rw (subnet) | | | +--:(prefix-length) | | | | +--rw ip:prefix-length? uint8 | | | +--:(netmask) | | | +--rw ip:netmask? yang:dotted-quad | | +--rw ip:neighbor [ip] | | +--rw ip:ip inet:ipv4-address-no-zone | | +--rw ip:link-layer-address? yang:phys-address | +--rw ip:ipv6? | +--rw ip:enabled? boolean | +--rw ip:forwarding? boolean | +--rw ip:mtu? uint32 | +--rw ip:address [ip] | | +--rw ip:ip inet:ipv6-address-no-zone | | +--rw ip:prefix-length uint8 | +--rw ip:neighbor [ip] | | +--rw ip:ip inet:ipv6-address-no-zone | | +--rw ip:link-layer-address? yang:phys-address | +--rw ip:dup-addr-detect-transmits? uint32 | +--rw ip:autoconf | +--rw ip:create-global-addresses? boolean | +--rw ip:create-temporary-addresses? boolean | +--rw ip:temporary-valid-lifetime? uint32 | +--rw ip:temporary-preferred-lifetime? uint32 +--ro interfaces-state +--ro interface [name] +--ro name string +--ro type identityref +--ro admin-status enumeration +--ro oper-status enumeration +--ro last-change? yang:date-and-time +--ro if-index int32 +--ro phys-address? yang:phys-address +--ro higher-layer-if* interface-state-ref +--ro lower-layer-if* interface-state-ref +--ro speed? yang:gauge64 +--ro statistics | +--ro discontinuity-time yang:date-and-time | +--ro in-octets? yang:counter64 | +--ro in-unicast-pkts? yang:counter64 | +--ro in-broadcast-pkts? yang:counter64 | +--ro in-multicast-pkts? yang:counter64 | +--ro in-discards? yang:counter32 | +--ro in-errors? yang:counter32 | +--ro in-unknown-protos? yang:counter32 | +--ro out-octets? yang:counter64 | +--ro out-unicast-pkts? yang:counter64 | +--ro out-broadcast-pkts? yang:counter64 | +--ro out-multicast-pkts? yang:counter64 | +--ro out-discards? yang:counter32 | +--ro out-errors? yang:counter32 +--ro ip:ipv4? | +--ro ip:forwarding? boolean | +--ro ip:mtu? uint16 | +--ro ip:address [ip] | | +--ro ip:ip inet:ipv4-address-no-zone | | +--ro (subnet)? | | | +--:(prefix-length) | | | | +--ro ip:prefix-length? uint8 | | | +--:(netmask) | | | +--ro ip:netmask? yang:dotted-quad | | +--ro ip:origin? ip-address-origin | +--ro ip:neighbor [ip] | +--ro ip:ip inet:ipv4-address-no-zone | +--ro ip:link-layer-address? yang:phys-address | +--ro ip:origin? neighbor-origin | +--ro ip:state? neighbor-state +--ro ip:ipv6? +--ro ip:forwarding? boolean +--ro ip:mtu? uint32 +--ro ip:address [ip] | +--ro ip:ip inet:ipv6-address-no-zone | +--ro ip:prefix-length uint8 | +--ro ip:origin? ip-address-origin | +--ro ip:status? enumeration +--ro ip:neighbor [ip] +--ro ip:ip inet:ipv6-address-no-zone +--ro ip:link-layer-address? yang:phys-address +--ro ip:origin? neighbor-origin +--ro ip:is-router? empty +--ro ip:state? neighbor-state --- ietf-ip@2013-08-25.yang.orig 2013-10-07 09:18:11.952631152 -0400= = =20 +++ ietf-ip@2013-08-25.yang 2013-10-07 09:45:21.348509916 -0400 = = =20 @@ -136,6 +136,62 @@ = = =20 "The origin of a neighbor entry."; = = =20 } = = =20 = = =20 + typedef neighbor-state { = = =20 + type enumeration { + enum incomplete { + description + "Address resolution is in progress and the link-layer + address of the neighbor has not yet been + determined."; + } + enum reachable { + description + "Roughly speaking, the neighbor is known to have been + reachable recently (within tens of seconds ago)."; + } + enum stale { + description + "The neighbor is no longer known to be reachable but + until traffic is sent to the neighbor, no attempt + should be made to verify its reachability."; + } + enum delay { + description + "The neighbor is no longer known to be reachable, and + traffic has recently been sent to the neighbor. + Rather than probe the neighbor immediately, however, + delay sending probes for a short while in order to + give upper-layer protocols a chance to provide + reachability confirmation."; + } + enum probe { + description + "The neighbor is no longer known to be reachable, and + unicast Neighbor Solicitation probes are being sent + to verify reachability."; + } + enum failed { + description + "The neighbor was unable to be successfully probed."; + } + enum noarp { + description + "The neighbor entry will not use any protocol to + resolve the L3 to L2 mapping."; + } + enum permanent{ + description + "The neighbor entry has been statically configured."; + } + } + description + "The Neighbor Unreachability Detection state of this + entry."; + reference + "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) + Section 7.3.2"; + } + =20 /* * Configuration data nodes */ @@ -455,6 +511,37 @@ "The origin of this address."; } } + list neighbor { + key "ip"; + description + "A list of mappings from IPv4 addresses to + link-layer addresses. + + This list represents the ARP Cache."; + reference + "RFC 826: An Ethernet Address Resolution Protocol"; + + leaf ip { + type inet:ipv4-address-no-zone; + description + "The IPv4 address of the neighbor node."; + } + leaf link-layer-address { + type yang:phys-address; + description + "The link-layer address of the neighbor node."; + } + leaf origin { + type neighbor-origin; + description + "The origin of this neighbor entry."; + } + leaf state { + type neighbor-state; + description + "The state of this neighbor entry."; + } + } } =20 container ipv6 { @@ -567,59 +654,8 @@ RFC 4862: IPv6 Stateless Address Autoconfiguration"; } } - } - } - - container ip-state { - config false; - description - "Data nodes for the operational state of IP."; - - container ipv4 { - presence "Present if IPv4 is enabled"; - description - "Parameters for the IPv4 address family."; - - list neighbor { - key "interface ip"; - description - "A list of mappings from IPv4 addresses to - link-layer addresses. - - This list represents the ARP Cache."; - reference - "RFC 826: An Ethernet Address Resolution Protocol"; - - leaf interface { - type if:interface-state-ref; - description - "The name of the interface for this neighbor."; - } - leaf ip { - type inet:ipv4-address-no-zone; - description - "The IPv4 address of the neighbor node."; - } - leaf link-layer-address { - type yang:phys-address; - description - "The link-layer address of the neighbor node."; - } - leaf origin { - type neighbor-origin; - description - "The origin of this neighbor entry."; - } - } - } - - container ipv6 { - presence "Present if IPv6 is enabled"; - description - "Parameters for the IPv6 address family."; - list neighbor { - key "interface ip"; + key "ip"; description "A list of mappings from IPv6 addresses to link-layer addresses. @@ -628,11 +664,6 @@ reference "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)"; =20 - leaf interface { - type if:interface-state-ref; - description - "The name of the interface for this neighbor."; - } leaf ip { type inet:ipv6-address-no-zone; description @@ -654,46 +685,9 @@ "Indicates that the neighbor node acts as a router."; } leaf state { - type enumeration { - enum incomplete { - description - "Address resolution is in progress and the link-layer - address of the neighbor has not yet been - determined."; - } - enum reachable { - description - "Roughly speaking, the neighbor is known to have been - reachable recently (within tens of seconds ago)."; - } - enum stale { - description - "The neighbor is no longer known to be reachable but - until traffic is sent to the neighbor, no attempt - should be made to verify its reachability."; - } - enum delay { - description - "The neighbor is no longer known to be reachable, and - traffic has recently been sent to the neighbor. - Rather than probe the neighbor immediately, however, - delay sending probes for a short while in order to - give upper-layer protocols a chance to provide - reachability confirmation."; - } - enum probe { - description - "The neighbor is no longer known to be reachable, and - unicast Neighbor Solicitation probes are being sent - to verify reachability."; - } - } + type neighbor-state; description - "The Neighbor Unreachability Detection state of this - entry."; - reference - "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - Section 7.3.2"; + "The state of this neighbor entry."; } } } From mbj@tail-f.com Mon Oct 7 07:21:09 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF7721E80AD for ; Mon, 7 Oct 2013 07:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 4pGlUnQB4Gi2 for ; Mon, 7 Oct 2013 07:21:03 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id AA77121E80B8 for ; Mon, 7 Oct 2013 07:20:50 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 1A8D212002EE; Mon, 7 Oct 2013 16:20:49 +0200 (CEST) Date: Mon, 07 Oct 2013 16:20:48 +0200 (CEST) Message-Id: <20131007.162048.1755792130247781311.mbj@tail-f.com> To: jeffrey.K.lange@ge.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 14:21:09 -0000 Hi, "Lange, Jeffrey K (GE Energy Management)" wrote: > Unrelated to previous messages about this draft, Why is it that > /ip-state/ipv6/neighbor has a 'state' leaf > (incomplete/reachable/etc..), but /ip-state/ipv4/neighbor does not? ARP does not define such states. The IP-MIB says this re. this object: If Neighbor Unreachability Detection is not in use (e.g. for IPv4), this object is always unknown(6) > This is valid for ipv4 neighbors as well. e.g on Linux: > # ip neigh show > 192.168.1.2 dev eth0 lladdr 00:12:17:5c:4f:2d STALE Yes. It is a bit unclear to me what the different states would mean for ARP. > I also question why the neighbor entries are at the top-level ip-state > as opposed to per-interface? The only reason is that this how the neighbor info commonly is queried; e.g., you used "ip neigh show" above. OTOH, it is straight-forward to get all neigbor info from all interfaces with a filter. And RFC 4861 defines the neighbor cache to be a per interface structure. I think both ways work - what does other people think? /martin From mbj@tail-f.com Mon Oct 7 07:30:52 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F04BD21E818D for ; Mon, 7 Oct 2013 07:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 69FAJVz8hORO for ; Mon, 7 Oct 2013 07:30:47 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 01B3821E81A6 for ; Mon, 7 Oct 2013 07:30:46 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 1893212002EE; Mon, 7 Oct 2013 16:30:46 +0200 (CEST) Date: Mon, 07 Oct 2013 16:30:45 +0200 (CEST) Message-Id: <20131007.163045.753509374105912116.mbj@tail-f.com> To: jeffrey.K.lange@ge.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 14:30:53 -0000 Hi, "Lange, Jeffrey K (GE Energy Management)" wrote: > Also, in regards to the neighbor state enum values. Is there a reason > it does not also include the standard values of: The enumerations included are the five values defined in RFC 4861. > - failed > - noarp > - permanent As for permanent, this is typically (only?) set if the entry was configured; this information is present in the 'origin' leaf. /martin From jeffrey.K.lange@ge.com Mon Oct 7 08:14:43 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 400E511E80F8 for ; Mon, 7 Oct 2013 08:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.013 X-Spam-Level: X-Spam-Status: No, score=-6.013 tagged_above=-999 required=5 tests=[AWL=0.586, 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 ie2sq3W6JnI0 for ; Mon, 7 Oct 2013 08:14:36 -0700 (PDT) Received: from exprod5og111.obsmtp.com (exprod5og111.obsmtp.com [64.18.0.22]) by ietfa.amsl.com (Postfix) with ESMTP id 269BE11E80FA for ; Mon, 7 Oct 2013 08:14:36 -0700 (PDT) Received: from alpmlip14.e2k.ad.ge.com ([12.43.191.1]) (using TLSv1) by exprod5ob111.postini.com ([64.18.4.12]) with SMTP ID DSNKUlLP1sv7NFtdsR9GH2M15f3NBmKFoNFO@postini.com; Mon, 07 Oct 2013 08:14:36 PDT Received: from unknown (HELO CINMBHT03.e2k.ad.ge.com) ([3.159.212.196]) by alpmlip14.e2k.ad.ge.com with ESMTP/TLS/AES128-SHA; 07 Oct 2013 11:14:30 -0400 Received: from CINMLCH01.e2k.ad.ge.com (3.159.212.50) by CINMBHT03.e2k.ad.ge.com (3.159.212.196) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 7 Oct 2013 11:14:29 -0400 Received: from CINURCNA20.e2k.ad.ge.com (3.159.212.168) by cinmlch01.e2k.ad.ge.com (3.159.212.50) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 7 Oct 2013 11:14:28 -0400 Received: from CINURCNA15.e2k.ad.ge.com ([169.254.3.234]) by CINURCNA20.e2k.ad.ge.com ([169.254.2.227]) with mapi id 14.03.0146.000; Mon, 7 Oct 2013 11:14:29 -0400 From: "Lange, Jeffrey K (GE Energy Management)" To: Martin Bjorklund Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt Thread-Index: AQHOodMlLyqCZb9RQkC9WKRHJHDjA5ngXCKwgABOsgD//8GvEIAAUmyAgADgLUCAAHMHgIAAOAqA///Dy2CAAEb5gIAAAWiAgAKMDnCAAF1hgIAEkz2A///Ha2A= Date: Mon, 7 Oct 2013 15:14:27 +0000 Message-ID: References: <20131007.163045.753509374105912116.mbj@tail-f.com> In-Reply-To: <20131007.163045.753509374105912116.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 15:14:43 -0000 > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Monday, October 07, 2013 10:31 AM > To: Lange, Jeffrey K (GE Energy Management) > Cc: netmod@ietf.org > Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt >=20 > Hi, >=20 > "Lange, Jeffrey K (GE Energy Management)" wrote: > > Also, in regards to the neighbor state enum values. Is there a reason > > it does not also include the standard values of: >=20 > The enumerations included are the five values defined in RFC 4861. >=20 > > - failed > > - noarp > > - permanent >=20 > As for permanent, this is typically (only?) set if the entry was > configured; this information is present in the 'origin' leaf. >=20 >=20 While this may be true, adding it as an option makes it consistent with how= windows and linux both show their neighbor entry statuses. Linux: $ip neigh show dev eth1 1.2.3.4 lladdr 00:11:22:33:44:55 PERMANENT Window: >netsh interface ipv4 show neighbors Internet Address Physical Address Type -------------------------------------------- ----------------- ----------= - 224.0.0.2 01-00-5e-00-00-02 Permanent >=20 > /martin From lhotka@nic.cz Mon Oct 7 08:46:18 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2478C21E80AD for ; Mon, 7 Oct 2013 08:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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 m5FwsUugk4kP for ; Mon, 7 Oct 2013 08:46:17 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 64A2421E80AE for ; Mon, 7 Oct 2013 08:46:16 -0700 (PDT) Received: from [172.20.26.113] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id A394913F7B7; Mon, 7 Oct 2013 17:46:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1381160773; bh=xvOPIymOJbyY1S+a3rcLcvCKOBk4HjbqrfScyYOhbDE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=dDEkajIcGrxDpssfPVOcpsH64LIittuGDzzos3FSdTCsb1XGzrsXsjmJisEG3YcaK kv21ls33X3S5NE7+Z9/JF1IwDaKlsMXVnLEm8I3vwwUqXVMkVf65SAPG0+KtnnqUIK J3h6l9IpVK/pzgwNaZftlo5M2bnRcfQElfCJTWfE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ladislav Lhotka In-Reply-To: <20131007.162048.1755792130247781311.mbj@tail-f.com> Date: Mon, 7 Oct 2013 17:46:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131007.162048.1755792130247781311.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1510) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 15:46:18 -0000 On Oct 7, 2013, at 4:20 PM, Martin Bjorklund wrote: > Hi, >=20 > "Lange, Jeffrey K (GE Energy Management)" = wrote: >> Unrelated to previous messages about this draft, Why is it that >> /ip-state/ipv6/neighbor has a 'state' leaf >> (incomplete/reachable/etc..), but /ip-state/ipv4/neighbor does not? >=20 > ARP does not define such states. The IP-MIB says this re. this > object: >=20 > If Neighbor Unreachability Detection is not in use (e.g. for > IPv4), this object is always unknown(6) >=20 >> This is valid for ipv4 neighbors as well. e.g on Linux: >> # ip neigh show >> 192.168.1.2 dev eth0 lladdr 00:12:17:5c:4f:2d STALE >=20 > Yes. It is a bit unclear to me what the different states would mean > for ARP. >=20 >> I also question why the neighbor entries are at the top-level = ip-state >> as opposed to per-interface? >=20 > The only reason is that this how the neighbor info commonly is > queried; e.g., you used "ip neigh show" above. Same in Cisco IOS: "show ip arp". And static ARP entries are configured = as global: arp 10.0.0.0 aabb.cc03.8200 arpa Lada >=20 > OTOH, it is straight-forward to get all neigbor info from all > interfaces with a filter. >=20 > And RFC 4861 defines the neighbor cache to be a per interface > structure. >=20 > I think both ways work - what does other people think? >=20 >=20 > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jeffrey.K.lange@ge.com Mon Oct 7 09:01:31 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE86B21E8205 for ; Mon, 7 Oct 2013 09:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.787 X-Spam-Level: X-Spam-Status: No, score=-3.787 tagged_above=-999 required=5 tests=[AWL=-1.787, 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 w9v4c3q7oE8F for ; Mon, 7 Oct 2013 09:01:25 -0700 (PDT) Received: from exprod5og118.obsmtp.com (exprod5og118.obsmtp.com [64.18.0.160]) by ietfa.amsl.com (Postfix) with ESMTP id 89EE421E80F5 for ; Mon, 7 Oct 2013 09:00:46 -0700 (PDT) Received: from alpmlip13.e2k.ad.ge.com ([165.156.5.1]) (using TLSv1) by exprod5ob118.postini.com ([64.18.4.12]) with SMTP ID DSNKUlLarVFoHQLOS2uTxpldVRkWqV8lAzE5@postini.com; Mon, 07 Oct 2013 09:00:46 PDT Received: from unknown (HELO ALPMBHT04.e2k.ad.ge.com) ([3.159.19.197]) by alpmlip13.e2k.ad.ge.com with ESMTP/TLS/AES128-SHA; 07 Oct 2013 12:00:45 -0400 Received: from CINURAPD13.e2k.ad.ge.com (3.159.212.141) by ALPMBHT04.e2k.ad.ge.com (3.159.19.197) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 7 Oct 2013 12:00:45 -0400 Received: from CINURCNA15.e2k.ad.ge.com ([169.254.3.234]) by CINURAPD13.e2k.ad.ge.com ([169.254.7.178]) with mapi id 14.03.0146.000; Mon, 7 Oct 2013 12:00:44 -0400 From: "Lange, Jeffrey K (GE Energy Management)" To: Ladislav Lhotka , Martin Bjorklund Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt Thread-Index: AQHOodMlLyqCZb9RQkC9WKRHJHDjA5ngXCKwgABOsgD//8GvEIAAUmyAgADgLUCAAHMHgIAAOAqA///Dy2CAAEb5gIAAAWiAgAKMDnCABO3WAIAAF96A///AKuA= Date: Mon, 7 Oct 2013 16:00:43 +0000 Message-ID: References: <20131007.162048.1755792130247781311.mbj@tail-f.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 16:01:31 -0000 > -----Original Message----- > From: Ladislav Lhotka [mailto:lhotka@nic.cz] > Sent: Monday, October 07, 2013 11:46 AM > To: Martin Bjorklund > Cc: Lange, Jeffrey K (GE Energy Management); netmod@ietf.org > Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt >=20 >=20 > On Oct 7, 2013, at 4:20 PM, Martin Bjorklund wrote: >=20 > > Hi, > > > > "Lange, Jeffrey K (GE Energy Management)" > wrote: > >> Unrelated to previous messages about this draft, Why is it that > >> /ip-state/ipv6/neighbor has a 'state' leaf > >> (incomplete/reachable/etc..), but /ip-state/ipv4/neighbor does not? > > > > ARP does not define such states. The IP-MIB says this re. this > > object: > > > > If Neighbor Unreachability Detection is not in use (e.g. for > > IPv4), this object is always unknown(6) > > > >> This is valid for ipv4 neighbors as well. e.g on Linux: > >> # ip neigh show > >> 192.168.1.2 dev eth0 lladdr 00:12:17:5c:4f:2d STALE > > > > Yes. It is a bit unclear to me what the different states would mean > > for ARP. > > > >> I also question why the neighbor entries are at the top-level ip-state > >> as opposed to per-interface? > > > > The only reason is that this how the neighbor info commonly is > > queried; e.g., you used "ip neigh show" above. >=20 > Same in Cisco IOS: "show ip arp". And static ARP entries are configured a= s > global: >=20 > arp 10.0.0.0 aabb.cc03.8200 arpa >=20 > Lada >=20 My feeling on this is that it can go either way, but that the configuration= should match the status. If static neighbor entries are configured per int= erface (/interfaces/interface/ipv4/neighbor) then it should follow that the= state be laid out in the same manor. Either: /interfaces/interface/ipv4/neighbor & /interfaces-state/interface/ipv4/neig= hbor Or /ip/ipv4/neighbor & /ip-state/ipv4/neighbor -Jeff > > > > OTOH, it is straight-forward to get all neigbor info from all > > interfaces with a filter. > > > > And RFC 4861 defines the neighbor cache to be a per interface > > structure. > > > > I think both ways work - what does other people think? > > > > > > /martin > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 From lhotka@nic.cz Mon Oct 7 09:09:27 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C27421E8190 for ; Mon, 7 Oct 2013 09:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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 ODTwFhmQzmT8 for ; Mon, 7 Oct 2013 09:09:26 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 3876F21E81B2 for ; Mon, 7 Oct 2013 09:09:12 -0700 (PDT) Received: from [172.20.26.113] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 4371413F7B7; Mon, 7 Oct 2013 18:09:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1381162151; bh=hjrN2WPo+VaV7lm0dN9j5AfEmB4yxRLagwNriHtoLWk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=S32slYw1dkOUMH4grpnufQo838S3usogXRUP6d5zsx5xe0bV79bZv6gIexNENLs1V TJ5uzN4xV9RshLTLThI+REl05SqvCPcPrudwdxzsgWl7gSYDQEbqJRPTc8l4i1iNye fV7g1zKAg8nmqdgPN++n5i4hJiSKiXZnZvftWxdU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 7 Oct 2013 18:09:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4AF146A6-D3E4-409B-BFEA-BE75D538E2F2@nic.cz> References: <20131007.162048.1755792130247781311.mbj@tail-f.com> To: "Lange, Jeffrey K (GE Energy Management)" X-Mailer: Apple Mail (2.1510) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 16:09:27 -0000 On Oct 7, 2013, at 6:00 PM, "Lange, Jeffrey K (GE Energy Management)" = wrote: >=20 >=20 >> -----Original Message----- >> From: Ladislav Lhotka [mailto:lhotka@nic.cz] >> Sent: Monday, October 07, 2013 11:46 AM >> To: Martin Bjorklund >> Cc: Lange, Jeffrey K (GE Energy Management); netmod@ietf.org >> Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt >>=20 >>=20 >> On Oct 7, 2013, at 4:20 PM, Martin Bjorklund wrote: >>=20 >>> Hi, >>>=20 >>> "Lange, Jeffrey K (GE Energy Management)" >> wrote: >>>> Unrelated to previous messages about this draft, Why is it that >>>> /ip-state/ipv6/neighbor has a 'state' leaf >>>> (incomplete/reachable/etc..), but /ip-state/ipv4/neighbor does not? >>>=20 >>> ARP does not define such states. The IP-MIB says this re. this >>> object: >>>=20 >>> If Neighbor Unreachability Detection is not in use (e.g. for >>> IPv4), this object is always unknown(6) >>>=20 >>>> This is valid for ipv4 neighbors as well. e.g on Linux: >>>> # ip neigh show >>>> 192.168.1.2 dev eth0 lladdr 00:12:17:5c:4f:2d STALE >>>=20 >>> Yes. It is a bit unclear to me what the different states would mean >>> for ARP. >>>=20 >>>> I also question why the neighbor entries are at the top-level = ip-state >>>> as opposed to per-interface? >>>=20 >>> The only reason is that this how the neighbor info commonly is >>> queried; e.g., you used "ip neigh show" above. >>=20 >> Same in Cisco IOS: "show ip arp". And static ARP entries are = configured as >> global: >>=20 >> arp 10.0.0.0 aabb.cc03.8200 arpa >>=20 >> Lada >>=20 >=20 > My feeling on this is that it can go either way, but that the = configuration should match the status. If static neighbor entries are = configured per interface (/interfaces/interface/ipv4/neighbor) then it = should follow that the state be laid out in the same manor. >=20 > Either: > /interfaces/interface/ipv4/neighbor & = /interfaces-state/interface/ipv4/neighbor > Or > /ip/ipv4/neighbor & /ip-state/ipv4/neighbor Yes, I agree both config and state should use the same organization. Lada >=20 > -Jeff >=20 >=20 >>>=20 >>> OTOH, it is straight-forward to get all neigbor info from all >>> interfaces with a filter. >>>=20 >>> And RFC 4861 defines the neighbor cache to be a per interface >>> structure. >>>=20 >>> I think both ways work - what does other people think? >>>=20 >>>=20 >>> /martin >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Mon Oct 7 11:04:12 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6613111E8102 for ; Mon, 7 Oct 2013 11:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIMlsbpgtDbw for ; Mon, 7 Oct 2013 11:04:08 -0700 (PDT) Received: from mail-qe0-f50.google.com (mail-qe0-f50.google.com [209.85.128.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD5321F9EFB for ; Mon, 7 Oct 2013 11:04:08 -0700 (PDT) Received: by mail-qe0-f50.google.com with SMTP id a11so5627220qen.9 for ; Mon, 07 Oct 2013 11:04:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=onTW796+AR7qGH4N+IRY6xuE8gdBemwkojHA87fsgLE=; b=VZjha0Ng82Lq2aDJA92uomy8Op0kfRt1Z0LFODwx5EOmgitsxajQA9/fWi6OGbdu2e Np6aBLmXep09OvDentX8AzcUNdxE0mPTAHjS51mVur/Aamfduow5IjDvcfmUSAsn3Xoi mpxx6SGk83G7FryUBgFqupNxVq1G35qpSOnWOxriyWgzAXu4rw7dYZodgC/OEF/e0VJF hcVMhqrNtDUbNiXxjd4njmzLJ8jK1bz/gnFCx8Wh640Q2SsJccdi23Ru+0MWhN48J9eD wklDD8yxSAAOqQtGdw/epHXglVINO4MXV8E/Hc0jGFt5HoI0IsxR54ZpAvG75ew2LJkc pOmg== X-Gm-Message-State: ALoCoQlt4vl+iq3mxfMSTVtv1RWioq2Ku0itST+iyfUTVqWnECdyqFhaqSqZuScd4C7+o8vPmib6 MIME-Version: 1.0 X-Received: by 10.224.24.131 with SMTP id v3mr39508795qab.48.1381169047294; Mon, 07 Oct 2013 11:04:07 -0700 (PDT) Received: by 10.140.26.209 with HTTP; Mon, 7 Oct 2013 11:04:07 -0700 (PDT) In-Reply-To: References: <20130923152837.32168.80619.idtracker@ietfa.amsl.com> Date: Mon, 7 Oct 2013 11:04:07 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c251ea70771804e82a7ad0 Cc: "netmod@ietf.org" Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 18:04:12 -0000 --001a11c251ea70771804e82a7ad0 Content-Type: text/plain; charset=ISO-8859-1 Hi, I have implemented all of this draft for YANG-API (draft -01 version). I think the NETMOD WG should standardize this document. Comments: Sec 3.4: IANA Considerations I think a new media type is needed (yjson?). In the RESTCONF draft the generic "json" string is used in media types, but really this draft is required, not plain JSON. Accept: application/vnd.yang.data+yjson ^^^^^ instead of json Sec 3.5: Security Considerations You should replace [TBD] with a short paragraph stating that no new security threats are added by this spec, since it is not a protocol or a data model for a protocol. Andy On Mon, Sep 23, 2013 at 8:33 AM, Ladislav Lhotka wrote: > Hi, > > this revision of JSON mapping document clarifies several issues, mainly > based on Andy's feedback. Several new examples appear in the text, and > appendix A contains a complete translation of the reply from appendix > D of draft-ietf-netmod-interfaces-cfg-12. > > Lada > > Begin forwarded message: > > > From: internet-drafts@ietf.org > > Subject: New Version Notification for > draft-lhotka-netmod-yang-json-02.txt > > Date: September 23, 2013 5:28:37 PM GMT+02:00 > > To: Ladislav Lhotka > > > > > > A new version of I-D, draft-lhotka-netmod-yang-json-02.txt > > has been successfully submitted by Ladislav Lhotka and posted to the > > IETF repository. > > > > Filename: draft-lhotka-netmod-yang-json > > Revision: 02 > > Title: Modeling JSON Text with YANG > > Creation date: 2013-09-23 > > Group: Individual Submission > > Number of pages: 19 > > URL: > http://www.ietf.org/internet-drafts/draft-lhotka-netmod-yang-json-02.txt > > Status: > http://datatracker.ietf.org/doc/draft-lhotka-netmod-yang-json > > Htmlized: > http://tools.ietf.org/html/draft-lhotka-netmod-yang-json-02 > > Diff: > http://www.ietf.org/rfcdiff?url2=draft-lhotka-netmod-yang-json-02 > > > > Abstract: > > This document defines rules for presenting configuration and > > operational state data defined using YANG as JSON text. It does so > > by specifying a procedure for translating the subset of YANG- > > compatible XML documents to JSON text, and vice versa. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11c251ea70771804e82a7ad0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I have implemented all of this draf= t for YANG-API (draft -01 version).
I think the NETMOD WG should = standardize this document.

Comments:
Sec 3.4: IANA Considerations

I think a = new media type is needed (yjson?).
In the RESTCONF draft the gene= ric "json" string is used in
media types, but really th= is draft is required, not plain JSON.

Accept: application/vnd.yang.data+yjson
=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 ^^^^^ instead of json


Sec 3.5: Security Considerations

You should replace [TBD] with a short paragraph stating
that no new security threats are added by this spec, since
= it is not a protocol or a data model for a protocol.


A= ndy

On Mon, Sep 23, 2013 at 8:33 AM, Ladislav Lhot= ka <lhotka@nic.cz> wrote:
Hi,

this revision of JSON mapping document clarifies several issues, mainly bas= ed on Andy's feedback. Several new examples appear in the text, and app= endix A contains a complete translation of the <get> reply from appen= dix D of draft-ietf-netmod-interfaces-cfg-12.

Lada

Begin forwarded message:

> From: internet-drafts@ietf= .org
> Subject: New Version Notification for draft-lhotka-netmod-yang-json-02= .txt
> Date: September 23, 2013 5:28:37 PM GMT+02:00
> To: Ladislav Lhotka <lhotka@nic.cz= >
>
>
> A new version of I-D, draft-lhotka-netmod-yang-json-02.txt
> has been successfully submitted by Ladislav Lhotka and posted to the > IETF repository.
>
> Filename: =A0 =A0 =A0draft-lhotka-netmod-yang-json
> Revision: =A0 =A0 =A002
> Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Modeling JSON Text with YANG > Creation date: =A0 =A0 =A0 =A0 2013-09-23
> Group: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Individual Submission
> Number of pages: 19
> URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ie= tf.org/internet-drafts/draft-lhotka-netmod-yang-json-02.txt
> Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.or= g/doc/draft-lhotka-netmod-yang-json
> Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/dra= ft-lhotka-netmod-yang-json-02
> Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.or= g/rfcdiff?url2=3Ddraft-lhotka-netmod-yang-json-02
>
> Abstract:
> =A0 This document defines rules for presenting configuration and
> =A0 operational state data defined using YANG as JSON text. =A0It does= so
> =A0 by specifying a procedure for translating the subset of YANG-
> =A0 compatible XML documents to JSON text, and vice versa.
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>

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




_______________________________________________
netmod mailing list
netmod@ietf.org
= https://www.ietf.org/mailman/listinfo/netmod

--001a11c251ea70771804e82a7ad0-- From jeffrey.K.lange@ge.com Mon Oct 7 14:05:13 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0BEB11E816D for ; Mon, 7 Oct 2013 14:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.888 X-Spam-Level: X-Spam-Status: No, score=-5.888 tagged_above=-999 required=5 tests=[AWL=0.711, 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 UtlG-qp8yKH2 for ; Mon, 7 Oct 2013 14:05:01 -0700 (PDT) Received: from exprod5og116.obsmtp.com (exprod5og116.obsmtp.com [64.18.0.147]) by ietfa.amsl.com (Postfix) with ESMTP id 89EB711E816B for ; Mon, 7 Oct 2013 14:05:00 -0700 (PDT) Received: from cinmlip13.e2k.ad.ge.com ([12.71.149.1]) (using TLSv1) by exprod5ob116.postini.com ([64.18.4.12]) with SMTP ID DSNKUlMh+0aPoTLkEbbPr64P7V+WDHMRJt28@postini.com; Mon, 07 Oct 2013 14:05:00 PDT Received: from unknown (HELO ALPMBHT03.e2k.ad.ge.com) ([3.159.19.196]) by cinmlip13.e2k.ad.ge.com with ESMTP/TLS/AES128-SHA; 07 Oct 2013 17:04:59 -0400 Received: from CINURAPD16.e2k.ad.ge.com (3.159.212.144) by ALPMBHT03.e2k.ad.ge.com (3.159.19.196) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 7 Oct 2013 17:04:58 -0400 Received: from CINURCNA15.e2k.ad.ge.com ([169.254.3.234]) by CINURAPD16.e2k.ad.ge.com ([169.254.10.245]) with mapi id 14.03.0146.000; Mon, 7 Oct 2013 17:04:58 -0400 From: "Lange, Jeffrey K (GE Energy Management)" To: Ladislav Lhotka Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt Thread-Index: AQHOodMlLyqCZb9RQkC9WKRHJHDjA5ngXCKwgABOsgD//8GvEIAAUmyAgADgLUCAAHMHgIAAOAqA///Dy2CAAEb5gIAAAWiAgAKMDnCABO3WAIAAF96A///AKuAACMfWgAABzvyA Date: Mon, 7 Oct 2013 21:04:57 +0000 Message-ID: References: <20131007.162048.1755792130247781311.mbj@tail-f.com> <4AF146A6-D3E4-409B-BFEA-BE75D538E2F2@nic.cz> In-Reply-To: <4AF146A6-D3E4-409B-BFEA-BE75D538E2F2@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 21:05:13 -0000 > > > > My feeling on this is that it can go either way, but that the > configuration should match the status. If static neighbor entries are > configured per interface (/interfaces/interface/ipv4/neighbor) then it > should follow that the state be laid out in the same manor. > > > > Either: > > /interfaces/interface/ipv4/neighbor & /interfaces- > state/interface/ipv4/neighbor > > Or > > /ip/ipv4/neighbor & /ip-state/ipv4/neighbor >=20 > Yes, I agree both config and state should use the same organization. >=20 > Lada >=20 >=20 How about the following? Move /interfaces/interface/ipv[46]/neighbor to /ip/ipv[46]/neighbor and add= an optional interface-ref to the list? I also made link-layer-address mandatory, as without that it's not a very u= seful configuration entry. This now gives a place where system-wide IP set= tings can be augmented into. Should /ip/ipv[46] be presence containers for global ipv[46] disabling? container ip { container ipv4 { list neighbor { key "ip"; description "A list of mappings from IPv4 addresses to link-layer addresses. Entries in this list are used as static entries in the ARP cache."; reference "RFC 826: An Ethernet Address Resolution Protocol"; leaf ip { type inet:ipv4-address-no-zone; description "The IPv4 address of the neighbor node."; } leaf link-layer-address { type yang:phys-address; mandatory true; description "The link-layer address of the neighbor node."; } leaf interface { type if:interface-ref; description "The interface to which the neighbor is attached."; } } } container ipv6 { list neighbor { key "ip"; description "A list of mappings from IPv6 addresses to link-layer addresses. Entries in this list are used as static entries in the Neighbor Cache."; reference "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)"; leaf ip { type inet:ipv6-address-no-zone; description "The IPv6 address of the neighbor node."; } leaf link-layer-address { type yang:phys-address; mandatory true; description "The link-layer address of the neighbor node."; } leaf interface { type if:interface-ref; description "The interface to which the neighbor is attached."; } } } } From bclaise@cisco.com Mon Oct 7 15:03:57 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AACD11E8171; Mon, 7 Oct 2013 15:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.564 X-Spam-Level: X-Spam-Status: No, score=-10.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, 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 TGclJvdVX2Yt; Mon, 7 Oct 2013 15:03:53 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id CA56411E8142; Mon, 7 Oct 2013 15:03:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=458; q=dns/txt; s=iport; t=1381183433; x=1382393033; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=isLyEex9WsGEMA1sT1eMJ4ygXn9LKqFilxzkd4UZPUI=; b=e+papz95NswVP/JOl49jYREE6at2Fv9gB6jDCq9Ba+7MfnLH+tKIKNcp vcZbn5RTTqB34OiX1qGfVacQa+w41hWP4QvYyXzf+W0lEq7aD8jctO7h8 yy6R3QpEBON83msicPy3Qy3gxuPu918Yg9l81NLITWkbxpJ7fOWkce6hu w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFAGkvU1KQ/khN/2dsb2JhbABZgwc4wGKBBwGBKhZ0glMRQD0WGAMCAQIBSwEMCAEBGIdqDLsyk3sDmAGBL4UHi0qDJjo X-IronPort-AV: E=Sophos;i="4.90,1051,1371081600"; d="scan'208";a="160428086" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 07 Oct 2013 22:03:51 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r97M3kB7021203; Mon, 7 Oct 2013 22:03:48 GMT Message-ID: <52532FC2.9000804@cisco.com> Date: Tue, 08 Oct 2013 00:03:46 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: NETCONF , NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netmod] NETCONF/YANG tutorial under the training tab in the WG wiki X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 22:03:57 -0000 Dear all, From http://datatracker.ietf.org/wg/netmod/charter/ Or from http://datatracker.ietf.org/wg/netconf/charter/ -> Tools WG page -> Training tab Alternatively, directly go to http://trac.tools.ietf.org/wg/netmod/trac/wiki/TrainingMaterials (or http://trac.tools.ietf.org/wg/netconf/trac/wiki/TrainingMaterials. You will find a home for training material related to the WG charter, developed at the IETF. Regards, Benoit From lhotka@nic.cz Tue Oct 8 09:26:57 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C5921E824B for ; Tue, 8 Oct 2013 09:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.396 X-Spam-Level: X-Spam-Status: No, score=-1.396 tagged_above=-999 required=5 tests=[AWL=-0.301, 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 2s1pox8CpVej for ; Tue, 8 Oct 2013 09:26:52 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 9F33F21E809A for ; Tue, 8 Oct 2013 09:26:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 5B51A5405A8 for ; Tue, 8 Oct 2013 18:26:43 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovVJ+xrIkgM4 for ; Tue, 8 Oct 2013 18:26:38 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 24E9E5402F3 for ; Tue, 8 Oct 2013 18:26:34 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: References: <20131007.162048.1755792130247781311.mbj@tail-f.com> <4AF146A6-D3E4-409B-BFEA-BE75D538E2F2@nic.cz> User-Agent: Notmuch/0.15.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Mail-Followup-To: netmod@ietf.org Date: Tue, 08 Oct 2013 18:26:33 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 16:26:57 -0000 "Lange, Jeffrey K (GE Energy Management)" writes: >> > >> > My feeling on this is that it can go either way, but that the >> configuration should match the status. If static neighbor entries are >> configured per interface (/interfaces/interface/ipv4/neighbor) then it >> should follow that the state be laid out in the same manor. >> > >> > Either: >> > /interfaces/interface/ipv4/neighbor & /interfaces- >> state/interface/ipv4/neighbor >> > Or >> > /ip/ipv4/neighbor & /ip-state/ipv4/neighbor >> >> Yes, I agree both config and state should use the same organization. >> >> Lada >> >> > > How about the following? > > Move /interfaces/interface/ipv[46]/neighbor to /ip/ipv[46]/neighbor and add an optional interface-ref to the list? +1 > I also made link-layer-address mandatory, as without that it's not a very useful configuration entry. This now gives a place where system-wide IP settings can be augmented into. +1 > > Should /ip/ipv[46] be presence containers for global ipv[46] disabling? Would this be useful? Without any static neigbour entries (which is IMO a common case) the containers needn't be present in the configuration. Lada > > container ip { > container ipv4 { > list neighbor { > key "ip"; > description > "A list of mappings from IPv4 addresses to > link-layer addresses. > > Entries in this list are used as static entries in the > ARP cache."; > reference > "RFC 826: An Ethernet Address Resolution Protocol"; > > leaf ip { > type inet:ipv4-address-no-zone; > description > "The IPv4 address of the neighbor node."; > } > leaf link-layer-address { > type yang:phys-address; > mandatory true; > description > "The link-layer address of the neighbor node."; > } > leaf interface { > type if:interface-ref; > description > "The interface to which the neighbor is attached."; > } > } > } > container ipv6 { > list neighbor { > key "ip"; > description > "A list of mappings from IPv6 addresses to > link-layer addresses. > > Entries in this list are used as static entries in the > Neighbor Cache."; > reference > "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)"; > > leaf ip { > type inet:ipv6-address-no-zone; > description > "The IPv6 address of the neighbor node."; > } > leaf link-layer-address { > type yang:phys-address; > mandatory true; > description > "The link-layer address of the neighbor node."; > } > leaf interface { > type if:interface-ref; > description > "The interface to which the neighbor is attached."; > } > } > } > } -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jeffrey.K.lange@ge.com Tue Oct 8 11:22:46 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB2711E8104 for ; Tue, 8 Oct 2013 11:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.959 X-Spam-Level: X-Spam-Status: No, score=-5.959 tagged_above=-999 required=5 tests=[AWL=0.640, 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 iJK7vPmqTKTn for ; Tue, 8 Oct 2013 11:22:39 -0700 (PDT) Received: from exprod5og107.obsmtp.com (exprod5og107.obsmtp.com [64.18.0.184]) by ietfa.amsl.com (Postfix) with ESMTP id 278A911E80FA for ; Tue, 8 Oct 2013 11:22:35 -0700 (PDT) Received: from alpmlip13.e2k.ad.ge.com ([165.156.5.1]) (using TLSv1) by exprod5ob107.postini.com ([64.18.4.12]) with SMTP ID DSNKUlRNa1Z1vFf9linzb2rlYCpr8NFtdPr2@postini.com; Tue, 08 Oct 2013 11:22:36 PDT Received: from unknown (HELO ALPMBHT03.e2k.ad.ge.com) ([3.159.19.196]) by alpmlip13.e2k.ad.ge.com with ESMTP/TLS/AES128-SHA; 08 Oct 2013 14:22:34 -0400 Received: from CINURCNA08.e2k.ad.ge.com (3.159.212.125) by ALPMBHT03.e2k.ad.ge.com (3.159.19.196) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 8 Oct 2013 14:22:34 -0400 Received: from CINURCNA15.e2k.ad.ge.com ([169.254.3.234]) by CINURCNA08.e2k.ad.ge.com ([169.254.2.84]) with mapi id 14.03.0146.000; Tue, 8 Oct 2013 14:22:34 -0400 From: "Lange, Jeffrey K (GE Energy Management)" To: Ladislav Lhotka , "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt Thread-Index: AQHOodMlLyqCZb9RQkC9WKRHJHDjA5ngXCKwgABOsgD//8GvEIAAUmyAgADgLUCAAHMHgIAAOAqA///Dy2CAAEb5gIAAAWiAgAKMDnCABO3WAIAAF96A///AKuAACMfWgAABzvyAADEXMIAABHIaEA== Date: Tue, 8 Oct 2013 18:22:33 +0000 Message-ID: References: <20131007.162048.1755792130247781311.mbj@tail-f.com> <4AF146A6-D3E4-409B-BFEA-BE75D538E2F2@nic.cz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 18:22:46 -0000 > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf > Of Ladislav Lhotka > Sent: Tuesday, October 08, 2013 12:27 PM > To: netmod@ietf.org > Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt >=20 > "Lange, Jeffrey K (GE Energy Management)" writes= : >=20 > >> > > >> > My feeling on this is that it can go either way, but that the > >> configuration should match the status. If static neighbor entries are > >> configured per interface (/interfaces/interface/ipv4/neighbor) then it > >> should follow that the state be laid out in the same manor. > >> > > >> > Either: > >> > /interfaces/interface/ipv4/neighbor & /interfaces- > >> state/interface/ipv4/neighbor > >> > Or > >> > /ip/ipv4/neighbor & /ip-state/ipv4/neighbor > >> > >> Yes, I agree both config and state should use the same organization. > >> > >> Lada > >> > >> > > > > How about the following? > > > > Move /interfaces/interface/ipv[46]/neighbor to /ip/ipv[46]/neighbor and > add an optional interface-ref to the list? >=20 > +1 >=20 > > I also made link-layer-address mandatory, as without that it's not a > very useful configuration entry. This now gives a place where system-wid= e > IP settings can be augmented into. >=20 > +1 >=20 After playing with this a bit, on Linux at least, you cannot create a stati= c neighbor entry without specifying an interface. So placing this at a top = level /ip may not make as much sense as leaving it in /interfaces/interface= . And if that is the case, then the status version should also live in /in= terfaces-state/interface. What is the behavior in other environments (Cisco/Juniper)?=20 -Jeff > > > > Should /ip/ipv[46] be presence containers for global ipv[46] disabling? >=20 > Would this be useful? Without any static neigbour entries (which is IMO a > common case) the containers needn't be present in the configuration. >=20 > Lada >=20 From lhotka@nic.cz Tue Oct 8 12:06:43 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31BE921F9635 for ; Tue, 8 Oct 2013 12:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.773 X-Spam-Level: X-Spam-Status: No, score=-1.773 tagged_above=-999 required=5 tests=[AWL=0.226, 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 B8GnV5F14zLH for ; Tue, 8 Oct 2013 12:06:42 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 0797521F9C37 for ; Tue, 8 Oct 2013 12:05:45 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 7C10113FA80; Tue, 8 Oct 2013 21:05:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1381259142; bh=7TwvOHC9aLWyA1ADJeMwUcDvdi7bkGVqxQk5jQmdXos=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=dACEhRhxP+tR3E5PoAvRBPePCG4TLaaoA1as4TnKS1/NM3gToomFgQduCmWBZt/1l jznywHD34zUGv9F5qI1hOiJnKDuWFlFCuuUCvCWlPHKpL+RGYyzzzRi3HYkc7zucIl wWmFJiElOtcGElq6C9tOihiliA8eUwTFoW2Pnc90= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 8 Oct 2013 21:05:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3008616E-276B-4748-AB0E-07824A1ED7DF@nic.cz> References: <20131007.162048.1755792130247781311.mbj@tail-f.com> <4AF146A6-D3E4-409B-BFEA-BE75D538E2F2@nic.cz> To: "Lange, Jeffrey K (GE Energy Management)" X-Mailer: Apple Mail (2.1510) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 19:06:43 -0000 On Oct 8, 2013, at 8:22 PM, "Lange, Jeffrey K (GE Energy Management)" = wrote: >=20 >=20 >> -----Original Message----- >> From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On = Behalf >> Of Ladislav Lhotka >> Sent: Tuesday, October 08, 2013 12:27 PM >> To: netmod@ietf.org >> Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt >>=20 >> "Lange, Jeffrey K (GE Energy Management)" = writes: >>=20 >>>>>=20 >>>>> My feeling on this is that it can go either way, but that the >>>> configuration should match the status. If static neighbor entries = are >>>> configured per interface (/interfaces/interface/ipv4/neighbor) then = it >>>> should follow that the state be laid out in the same manor. >>>>>=20 >>>>> Either: >>>>> /interfaces/interface/ipv4/neighbor & /interfaces- >>>> state/interface/ipv4/neighbor >>>>> Or >>>>> /ip/ipv4/neighbor & /ip-state/ipv4/neighbor >>>>=20 >>>> Yes, I agree both config and state should use the same = organization. >>>>=20 >>>> Lada >>>>=20 >>>>=20 >>>=20 >>> How about the following? >>>=20 >>> Move /interfaces/interface/ipv[46]/neighbor to /ip/ipv[46]/neighbor = and >> add an optional interface-ref to the list? >>=20 >> +1 >>=20 >>> I also made link-layer-address mandatory, as without that it's not a >> very useful configuration entry. This now gives a place where = system-wide >> IP settings can be augmented into. >>=20 >> +1 >>=20 >=20 > After playing with this a bit, on Linux at least, you cannot create a = static neighbor entry without specifying an interface. So placing this = at a top level /ip may not make as much sense as leaving it in Why not? This works on my Linux box: $ sudo arp -s 172.29.2.224 44:87:fc:9e:7e:bb In Linux, the neighbour cache is global but every neighbour structure = has the "dev" member containing the pointer to the device/interface, and = actually the device is also part of the input to the hash function for = neighbour lookup. But still, I believe it is useful to be able to *configure* = ARP/neighbour entries without specifying the interface, because such a = configuration remains valid even after the interface to which the = neighbour is connected changes. It can be left to the server to figure = out the interface when processing the configuration. > /interfaces/interface. And if that is the case, then the status = version should also live in /interfaces-state/interface. >=20 > What is the behavior in other environments (Cisco/Juniper)? As I wrote earlier, the IOS command doesn't need the interface: arp 10.0.0.0 aabb.cc03.8200 arpa Lada >=20 >=20 > -Jeff >=20 >=20 >>>=20 >>> Should /ip/ipv[46] be presence containers for global ipv[46] = disabling? >>=20 >> Would this be useful? Without any static neigbour entries (which is = IMO a >> common case) the containers needn't be present in the configuration. >>=20 >> Lada >>=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Oct 8 14:16:10 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B5D11E80EA for ; Tue, 8 Oct 2013 14:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 MesS7Y+38Rcq for ; Tue, 8 Oct 2013 14:16:04 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECC821E80AD for ; Tue, 8 Oct 2013 14:15:57 -0700 (PDT) Received: from localhost (unknown [193.12.34.23]) by mail.tail-f.com (Postfix) with ESMTPSA id C76081200054; Tue, 8 Oct 2013 23:15:55 +0200 (CEST) Date: Tue, 08 Oct 2013 23:15:55 +0200 (CEST) Message-Id: <20131008.231555.416710381.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <3008616E-276B-4748-AB0E-07824A1ED7DF@nic.cz> References: <3008616E-276B-4748-AB0E-07824A1ED7DF@nic.cz> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 21:16:10 -0000 Hi, Ladislav Lhotka wrote: > > On Oct 8, 2013, at 8:22 PM, "Lange, Jeffrey K (GE Energy Management)" > wrote: > > > > > > >> -----Original Message----- > >> From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf > >> Of Ladislav Lhotka > >> Sent: Tuesday, October 08, 2013 12:27 PM > >> To: netmod@ietf.org > >> Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt > >> > >> "Lange, Jeffrey K (GE Energy Management)" writes: > >> > >>>>> > >>>>> My feeling on this is that it can go either way, but that the > >>>> configuration should match the status. If static neighbor entries are > >>>> configured per interface (/interfaces/interface/ipv4/neighbor) then it > >>>> should follow that the state be laid out in the same manor. > >>>>> > >>>>> Either: > >>>>> /interfaces/interface/ipv4/neighbor & /interfaces- > >>>> state/interface/ipv4/neighbor > >>>>> Or > >>>>> /ip/ipv4/neighbor & /ip-state/ipv4/neighbor > >>>> > >>>> Yes, I agree both config and state should use the same organization. > >>>> > >>>> Lada > >>>> > >>>> > >>> > >>> How about the following? > >>> > >>> Move /interfaces/interface/ipv[46]/neighbor to /ip/ipv[46]/neighbor and > >> add an optional interface-ref to the list? > >> > >> +1 > >> > >>> I also made link-layer-address mandatory, as without that it's not a > >> very useful configuration entry. This now gives a place where system-wide > >> IP settings can be augmented into. > >> > >> +1 > >> > > > > After playing with this a bit, on Linux at least, you cannot create a static > > neighbor entry without specifying an interface. So placing this at a top > > level /ip may not make as much sense as leaving it in > > Why not? This works on my Linux box: > > $ sudo arp -s 172.29.2.224 44:87:fc:9e:7e:bb It works, but the man page says: if this option [interface] is not used, the kernel will guess based on the routing table. > In Linux, the neighbour cache is global but every neighbour structure has the > "dev" member containing the pointer to the device/interface, and actually the > device is also part of the input to the hash function for neighbour lookup. > > But still, I believe it is useful to be able to *configure* ARP/neighbour > entries without specifying the interface, because such a configuration remains > valid even after the interface to which the neighbour is connected changes. It > can be left to the server to figure out the interface when processing the > configuration. I don't think this is a good idea. This complicates things quite a lot. We'd need to specify exactly during which circumstances (interfaces come and go, routing changes...) the mapping is (re)done. I prefer to keep the config as it is, and move the state structure to match the config, as Jeff suggested. /martin From lhotka@nic.cz Wed Oct 9 00:39:05 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 168C721E80D3 for ; Wed, 9 Oct 2013 00:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.818 X-Spam-Level: X-Spam-Status: No, score=-1.818 tagged_above=-999 required=5 tests=[AWL=0.181, 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 qNWwHnW3NKSf for ; Wed, 9 Oct 2013 00:39:04 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB3321F9D23 for ; Wed, 9 Oct 2013 00:39:03 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 39C7113FA80; Wed, 9 Oct 2013 09:39:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1381304342; bh=EIaFDxZGw9HoQGQj1wBHI5GzREJZ+snj3ckrRmJIQIw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=X7WrOSa1XQCgvB+1Vt55zbNwuR0EeFbGPOly2AJjU9/plr9AclT9lov50E+7GVyY1 rIhF9gcG5IcJx0iluDSlOoBxbt0/1N2DM4XRXOJRw/f8e2YxmUzLyF6eUmhWDb002i SrDrvBuRcDzR2Fyo+HFKQWioCAa38uUEm/UUNDEI= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ladislav Lhotka In-Reply-To: <20131008.231555.416710381.mbj@tail-f.com> Date: Wed, 9 Oct 2013 09:39:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2A815DBB-FD7D-4BB8-A6F1-6A49C9620547@nic.cz> References: <3008616E-276B-4748-AB0E-07824A1ED7DF@nic.cz> <20131008.231555.416710381.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1510) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 07:39:05 -0000 On Oct 8, 2013, at 11:15 PM, Martin Bjorklund wrote: > Hi, >=20 > Ladislav Lhotka wrote: >>=20 >> On Oct 8, 2013, at 8:22 PM, "Lange, Jeffrey K (GE Energy Management)" >> wrote: >>=20 >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On = Behalf >>>> Of Ladislav Lhotka >>>> Sent: Tuesday, October 08, 2013 12:27 PM >>>> To: netmod@ietf.org >>>> Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt >>>>=20 >>>> "Lange, Jeffrey K (GE Energy Management)" = writes: >>>>=20 >>>>>>>=20 >>>>>>> My feeling on this is that it can go either way, but that the >>>>>> configuration should match the status. If static neighbor entries = are >>>>>> configured per interface (/interfaces/interface/ipv4/neighbor) = then it >>>>>> should follow that the state be laid out in the same manor. >>>>>>>=20 >>>>>>> Either: >>>>>>> /interfaces/interface/ipv4/neighbor & /interfaces- >>>>>> state/interface/ipv4/neighbor >>>>>>> Or >>>>>>> /ip/ipv4/neighbor & /ip-state/ipv4/neighbor >>>>>>=20 >>>>>> Yes, I agree both config and state should use the same = organization. >>>>>>=20 >>>>>> Lada >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> How about the following? >>>>>=20 >>>>> Move /interfaces/interface/ipv[46]/neighbor to = /ip/ipv[46]/neighbor and >>>> add an optional interface-ref to the list? >>>>=20 >>>> +1 >>>>=20 >>>>> I also made link-layer-address mandatory, as without that it's not = a >>>> very useful configuration entry. This now gives a place where = system-wide >>>> IP settings can be augmented into. >>>>=20 >>>> +1 >>>>=20 >>>=20 >>> After playing with this a bit, on Linux at least, you cannot create = a static >>> neighbor entry without specifying an interface. So placing this at a = top >>> level /ip may not make as much sense as leaving it in >>=20 >> Why not? This works on my Linux box: >>=20 >> $ sudo arp -s 172.29.2.224 44:87:fc:9e:7e:bb >=20 > It works, but the man page says: >=20 > if this option [interface] is not used, the kernel will > guess based on the routing table. And that's exactly my point - given the L3 address, the interface info = is redundant. I can put such static ARP entries to an init script, and = they will continue to work after the corresponding interface changes = from eth0 to eth1. It is less of a problem with the "arbitrary-names" = feature though. =20 >=20 >> In Linux, the neighbour cache is global but every neighbour structure = has the >> "dev" member containing the pointer to the device/interface, and = actually the >> device is also part of the input to the hash function for neighbour = lookup. >>=20 >> But still, I believe it is useful to be able to *configure* = ARP/neighbour >> entries without specifying the interface, because such a = configuration remains >> valid even after the interface to which the neighbour is connected = changes. It >> can be left to the server to figure out the interface when processing = the >> configuration. >=20 > I don't think this is a good idea. This complicates things quite a > lot. We'd need to specify exactly during which circumstances > (interfaces come and go, routing changes...) the mapping is (re)done. >=20 > I prefer to keep the config as it is, and move the state structure to > match the config, as Jeff suggested. Note that Cisco IOS, JUNOS and Linux display the ARP cache as a global = table - presumably because it *is* a global table. So I think it is = better to keep at least the state data as they are in -10. Lada =20 >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jeffrey.K.lange@ge.com Wed Oct 9 05:26:59 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E97121F9CE3 for ; Wed, 9 Oct 2013 05:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.017 X-Spam-Level: X-Spam-Status: No, score=-4.017 tagged_above=-999 required=5 tests=[AWL=-1.418, BAYES_00=-2.599] 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 uGZhXZtVQp5a for ; Wed, 9 Oct 2013 05:26:52 -0700 (PDT) Received: from exprod5og119.obsmtp.com (exprod5og119.obsmtp.com [64.18.0.189]) by ietfa.amsl.com (Postfix) with ESMTP id BDC9211E8186 for ; Wed, 9 Oct 2013 05:26:46 -0700 (PDT) Received: from alpmlip13.e2k.ad.ge.com ([165.156.5.1]) (using TLSv1) by exprod5ob119.postini.com ([64.18.4.12]) with SMTP ID DSNKUlVLhnxyzPn7QuzP2fpvzhVU81Yr+wXV@postini.com; Wed, 09 Oct 2013 05:26:47 PDT Received: from unknown (HELO ALPMBHT02.e2k.ad.ge.com) ([3.159.19.195]) by alpmlip13.e2k.ad.ge.com with ESMTP/TLS/AES128-SHA; 09 Oct 2013 08:26:45 -0400 Received: from CINURCNA19.e2k.ad.ge.com (3.159.212.167) by ALPMBHT02.e2k.ad.ge.com (3.159.19.195) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 9 Oct 2013 08:26:45 -0400 Received: from CINURCNA15.e2k.ad.ge.com ([169.254.3.234]) by CINURCNA19.e2k.ad.ge.com ([169.254.1.67]) with mapi id 14.03.0146.000; Wed, 9 Oct 2013 08:26:44 -0400 From: "Lange, Jeffrey K (GE Energy Management)" To: Ladislav Lhotka Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt Thread-Index: AQHOodMlLyqCZb9RQkC9WKRHJHDjA5ngXCKwgABOsgD//8GvEIAAUmyAgADgLUCAAHMHgIAAOAqA///Dy2CAAEb5gIAAAWiAgAKMDnCABO3WAIAAF96A///AKuAACMfWgAABzvyAADEXMIAABHIaEAABHM8AABvVeuA= Date: Wed, 9 Oct 2013 12:26:44 +0000 Message-ID: References: <20131007.162048.1755792130247781311.mbj@tail-f.com> <4AF146A6-D3E4-409B-BFEA-BE75D538E2F2@nic.cz> <3008616E-276B-4748-AB0E-07824A1ED7DF@nic.cz> In-Reply-To: <3008616E-276B-4748-AB0E-07824A1ED7DF@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 12:26:59 -0000 > > After playing with this a bit, on Linux at least, you cannot create a > static neighbor entry without specifying an interface. So placing this at > a top level /ip may not make as much sense as leaving it in >=20 > Why not? This works on my Linux box: >=20 > $ sudo arp -s 172.29.2.224 44:87:fc:9e:7e:bb >=20 If you are attempting to add an IPv6 entry, you need to use the "ip" comman= d $ sudo ip -6 neigh add dead:beef::23 lladdr 00:11:22:33:44:55 Device and destination are required arguments. $ sudo ip -6 neigh add dead:beef::23 lladdr 00:11:22:33:44:55 dev eth0 $ -Jeff From lhotka@nic.cz Wed Oct 9 06:11:25 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330E311E8186 for ; Wed, 9 Oct 2013 06:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.396 X-Spam-Level: X-Spam-Status: No, score=-1.396 tagged_above=-999 required=5 tests=[AWL=-0.301, 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 wJmYXBvR6wU7 for ; Wed, 9 Oct 2013 06:11:20 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id B921A11E818A for ; Wed, 9 Oct 2013 06:11:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id CAF2B540483 for ; Wed, 9 Oct 2013 15:11:14 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNQn6oN3+tgm for ; Wed, 9 Oct 2013 15:11:07 +0200 (CEST) Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 7146654000E for ; Wed, 9 Oct 2013 15:11:03 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: References: <20130923152837.32168.80619.idtracker@ietfa.amsl.com> User-Agent: Notmuch/0.15.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Mail-Followup-To: netmod@ietf.org Date: Wed, 09 Oct 2013 15:11:02 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 13:11:25 -0000 Andy Bierman writes: > Hi, > > I have implemented all of this draft for YANG-API (draft -01 version). > I think the NETMOD WG should standardize this document. Thanks, Andy. > > Comments: > > Sec 3.4: IANA Considerations > > I think a new media type is needed (yjson?). > In the RESTCONF draft the generic "json" string is used in > media types, but really this draft is required, not plain JSON. > > Accept: application/vnd.yang.data+yjson > ^^^^^ instead of json Far from being an expert on the use of media types, I think the format is nothing but standard JSON. Using a new media type means that generic processors and intermediaries are out of luck. > > > Sec 3.5: Security Considerations > > You should replace [TBD] with a short paragraph stating > that no new security threats are added by this spec, since > it is not a protocol or a data model for a protocol. Yes, I'll do that. Lada > > > Andy > > > On Mon, Sep 23, 2013 at 8:33 AM, Ladislav Lhotka wrote: > >> Hi, >> >> this revision of JSON mapping document clarifies several issues, mainly >> based on Andy's feedback. Several new examples appear in the text, and >> appendix A contains a complete translation of the reply from appendix >> D of draft-ietf-netmod-interfaces-cfg-12. >> >> Lada >> >> Begin forwarded message: >> >> > From: internet-drafts@ietf.org >> > Subject: New Version Notification for >> draft-lhotka-netmod-yang-json-02.txt >> > Date: September 23, 2013 5:28:37 PM GMT+02:00 >> > To: Ladislav Lhotka >> > >> > >> > A new version of I-D, draft-lhotka-netmod-yang-json-02.txt >> > has been successfully submitted by Ladislav Lhotka and posted to the >> > IETF repository. >> > >> > Filename: draft-lhotka-netmod-yang-json >> > Revision: 02 >> > Title: Modeling JSON Text with YANG >> > Creation date: 2013-09-23 >> > Group: Individual Submission >> > Number of pages: 19 >> > URL: >> http://www.ietf.org/internet-drafts/draft-lhotka-netmod-yang-json-02.txt >> > Status: >> http://datatracker.ietf.org/doc/draft-lhotka-netmod-yang-json >> > Htmlized: >> http://tools.ietf.org/html/draft-lhotka-netmod-yang-json-02 >> > Diff: >> http://www.ietf.org/rfcdiff?url2=draft-lhotka-netmod-yang-json-02 >> > >> > Abstract: >> > This document defines rules for presenting configuration and >> > operational state data defined using YANG as JSON text. It does so >> > by specifying a procedure for translating the subset of YANG- >> > compatible XML documents to JSON text, and vice versa. >> > >> > >> > >> > >> > Please note that it may take a couple of minutes from the time of >> submission >> > until the htmlized version and diff are available at tools.ietf.org. >> > >> > The IETF Secretariat >> > >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Wed Oct 9 06:52:30 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 673E711E8192 for ; Wed, 9 Oct 2013 06:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.805 X-Spam-Level: X-Spam-Status: No, score=-1.805 tagged_above=-999 required=5 tests=[AWL=0.194, 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 Z6NKr9YR+RfT for ; Wed, 9 Oct 2013 06:52:27 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id C2B3411E818D for ; Wed, 9 Oct 2013 06:52:25 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id BA77413FA7E; Wed, 9 Oct 2013 15:52:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1381326744; bh=gB2nUZtI2AeHBelhvtPapYFkwN3ONoaPfPEyjK/Pl54=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=XhXSQaaQqaTkrrCXs9lPTAenFQMhYZ/B/N1LD/qyuvJUZqpoRxUaTMq1DCbRVB+Ya a6AhlFaTiBs5SVokNxw/z/wzMyGj14HZN90RMg064wezDE8JWXuo+aJsS1YwrJ/4ze CI+MH7AJyhEQMjryJSOplL70Q4KIH3lG2FyBCe1I= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 9 Oct 2013 15:52:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131007.162048.1755792130247781311.mbj@tail-f.com> <4AF146A6-D3E4-409B-BFEA-BE75D538E2F2@nic.cz> <3008616E-276B-4748-AB0E-07824A1ED7DF@nic.cz> To: "Lange, Jeffrey K (GE Energy Management)" X-Mailer: Apple Mail (2.1510) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 13:52:30 -0000 On Oct 9, 2013, at 2:26 PM, "Lange, Jeffrey K (GE Energy Management)" = wrote: >>> After playing with this a bit, on Linux at least, you cannot create = a >> static neighbor entry without specifying an interface. So placing = this at >> a top level /ip may not make as much sense as leaving it in >>=20 >> Why not? This works on my Linux box: >>=20 >> $ sudo arp -s 172.29.2.224 44:87:fc:9e:7e:bb >>=20 >=20 > If you are attempting to add an IPv6 entry, you need to use the "ip" = command >=20 > $ sudo ip -6 neigh add dead:beef::23 lladdr 00:11:22:33:44:55 > Device and destination are required arguments. > $ sudo ip -6 neigh add dead:beef::23 lladdr 00:11:22:33:44:55 dev eth0 > $ I checked four platforms (JUNOS, Cisco IOS, Mikrotik RouterOS, Linux) = and it seems that - for setting static ARP (IPv4) entries, some platforms/commands require = an interface (JUNOS, RouterOS, Linux "ip") and some don't (IOS, Linux = "arp"), - for setting IPv6 neighbour entries, an interface is always required, - show-like commands always present neighbour caches as a global table, = with various filtering options (show entries for a given interface, show = the entry for a given IP address). So I am now leaning towards keeping the neighbour stuff as it is in -10. Lada=20 >=20 > -Jeff >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jeffrey.K.lange@ge.com Wed Oct 9 07:06:29 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F8C21F8427 for ; Wed, 9 Oct 2013 07:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, 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 kUj9XY8-TAbx for ; Wed, 9 Oct 2013 07:06:21 -0700 (PDT) Received: from exprod5og115.obsmtp.com (exprod5og115.obsmtp.com [64.18.0.246]) by ietfa.amsl.com (Postfix) with ESMTP id CA36A21F8AD5 for ; Wed, 9 Oct 2013 07:06:04 -0700 (PDT) Received: from alpmlip11.e2k.ad.ge.com ([165.156.5.1]) (using TLSv1) by exprod5ob115.postini.com ([64.18.4.12]) with SMTP ID DSNKUlVizKP5gAKEh41CH3qqv3NwI8hgF81G@postini.com; Wed, 09 Oct 2013 07:06:08 PDT Received: from unknown (HELO CINMBHT02.e2k.ad.ge.com) ([3.159.212.195]) by alpmlip11.e2k.ad.ge.com with ESMTP/TLS/AES128-SHA; 09 Oct 2013 10:06:03 -0400 Received: from CINURAPD13.e2k.ad.ge.com (3.159.212.141) by CINMBHT02.e2k.ad.ge.com (3.159.212.195) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 9 Oct 2013 10:06:02 -0400 Received: from CINURCNA15.e2k.ad.ge.com ([169.254.3.234]) by CINURAPD13.e2k.ad.ge.com ([169.254.7.178]) with mapi id 14.03.0146.000; Wed, 9 Oct 2013 10:06:02 -0400 From: "Lange, Jeffrey K (GE Energy Management)" To: Ladislav Lhotka Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt Thread-Index: AQHOodMlLyqCZb9RQkC9WKRHJHDjA5ngXCKwgABOsgD//8GvEIAAUmyAgADgLUCAAHMHgIAAOAqA///Dy2CAAEb5gIAAAWiAgAKMDnCABO3WAIAAF96A///AKuAACMfWgAABzvyAADEXMIAABHIaEAABHM8AABvVeuAAC4QCAAAIFGog Date: Wed, 9 Oct 2013 14:06:01 +0000 Message-ID: References: <20131007.162048.1755792130247781311.mbj@tail-f.com> <4AF146A6-D3E4-409B-BFEA-BE75D538E2F2@nic.cz> <3008616E-276B-4748-AB0E-07824A1ED7DF@nic.cz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 14:06:29 -0000 > -----Original Message----- > From: Ladislav Lhotka [mailto:lhotka@nic.cz] > Sent: Wednesday, October 09, 2013 9:52 AM > To: Lange, Jeffrey K (GE Energy Management) > Cc: netmod@ietf.org > Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt >=20 >=20 > On Oct 9, 2013, at 2:26 PM, "Lange, Jeffrey K (GE Energy Management)" > wrote: >=20 > >>> After playing with this a bit, on Linux at least, you cannot create a > >> static neighbor entry without specifying an interface. So placing this > at > >> a top level /ip may not make as much sense as leaving it in > >> > >> Why not? This works on my Linux box: > >> > >> $ sudo arp -s 172.29.2.224 44:87:fc:9e:7e:bb > >> > > > > If you are attempting to add an IPv6 entry, you need to use the "ip" > command > > > > $ sudo ip -6 neigh add dead:beef::23 lladdr 00:11:22:33:44:55 > > Device and destination are required arguments. > > $ sudo ip -6 neigh add dead:beef::23 lladdr 00:11:22:33:44:55 dev eth0 > > $ >=20 > I checked four platforms (JUNOS, Cisco IOS, Mikrotik RouterOS, Linux) and > it seems that >=20 > - for setting static ARP (IPv4) entries, some platforms/commands require > an interface (JUNOS, RouterOS, Linux "ip") and some don't (IOS, Linux > "arp"), >=20 > - for setting IPv6 neighbour entries, an interface is always required, >=20 > - show-like commands always present neighbour caches as a global table, > with various filtering options (show entries for a given interface, show > the entry for a given IP address). >=20 > So I am now leaning towards keeping the neighbour stuff as it is in -10. >=20 If things are kept how they are, I would still change the link-layer-addres= s in the neighbor list to be mandatory. I also still suggest adding the neighbor state to /ip-state/ipv4/neighbor, = although I understand Martin's concern that this is not "defined" as a stan= dard for ARP. This is very useful information when you are trying to debug= connectivity issues. -Jeff > Lada >=20 > > > > -Jeff > > >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 From mbj@tail-f.com Wed Oct 9 07:18:36 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8730C21E8090 for ; Wed, 9 Oct 2013 07:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 L-n1m16P+Nm8 for ; Wed, 9 Oct 2013 07:18:31 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id C4BE621E805F for ; Wed, 9 Oct 2013 07:18:31 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 9997B1200438; Wed, 9 Oct 2013 16:18:30 +0200 (CEST) Date: Wed, 09 Oct 2013 16:18:30 +0200 (CEST) Message-Id: <20131009.161830.1731740457994143646.mbj@tail-f.com> To: jeffrey.K.lange@ge.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 14:18:36 -0000 "Lange, Jeffrey K (GE Energy Management)" wrote: > If things are kept how they are I can go either way - keep it as it is, or move the neighbor state to per-interface. I think it is pretty trivial to implement this even if there is a global table, and it is also pretty trivial to filter in all lists; for example, to get all neighbors w/ ip address 10.0.0.1: /interfaces-state/interface/ipv4/neighbor[ip='10.0.0.1'] The same query with the current design (one global list): /ip-state/ipv4/neighbor[ip='10.0.0.1'] > I would still change the > link-layer-address in the neighbor list to be mandatory. Agreed. /martin > I also still suggest adding the neighbor state to > /ip-state/ipv4/neighbor, although I understand Martin's concern that > this is not "defined" as a standard for ARP. This is very useful > information when you are trying to debug connectivity issues. > > -Jeff > > > Lada > > > > > > > > -Jeff > > > > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From jeffrey.K.lange@ge.com Wed Oct 9 07:29:00 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B6021F9FBA for ; Wed, 9 Oct 2013 07:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.63 X-Spam-Level: X-Spam-Status: No, score=-5.63 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, 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 9LtlwVZXIrq7 for ; Wed, 9 Oct 2013 07:28:32 -0700 (PDT) Received: from exprod5og113.obsmtp.com (exprod5og113.obsmtp.com [64.18.0.26]) by ietfa.amsl.com (Postfix) with ESMTP id 46BBE21F8421 for ; Wed, 9 Oct 2013 07:28:25 -0700 (PDT) Received: from cinmlip13.e2k.ad.ge.com ([165.156.4.1]) (using TLSv1) by exprod5ob113.postini.com ([64.18.4.12]) with SMTP ID DSNKUlVoApQ5FDZ/TxqMqxNi1R00XOO/uyM5@postini.com; Wed, 09 Oct 2013 07:28:26 PDT Received: from unknown (HELO ALPMBHT01.e2k.ad.ge.com) ([3.159.19.194]) by cinmlip13.e2k.ad.ge.com with ESMTP/TLS/AES128-SHA; 09 Oct 2013 10:28:01 -0400 Received: from CINMLCH01.e2k.ad.ge.com (3.159.212.50) by ALPMBHT01.e2k.ad.ge.com (3.159.19.194) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 9 Oct 2013 10:28:01 -0400 Received: from CINURCNA24.e2k.ad.ge.com (3.159.212.172) by cinmlch01.e2k.ad.ge.com (3.159.212.50) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 9 Oct 2013 10:28:00 -0400 Received: from CINURCNA15.e2k.ad.ge.com ([169.254.3.234]) by CINURCNA24.e2k.ad.ge.com ([169.254.5.186]) with mapi id 14.03.0146.000; Wed, 9 Oct 2013 10:28:00 -0400 From: "Lange, Jeffrey K (GE Energy Management)" To: Martin Bjorklund Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt Thread-Index: AQHOodMlLyqCZb9RQkC9WKRHJHDjA5ngXCKwgABOsgD//8GvEIAAUmyAgADgLUCAAHMHgIAAOAqA///Dy2CAAEb5gIAAAWiAgAKMDnCABO3WAIAAF96A///AKuAACMfWgAABzvyAADEXMIAABHIaEAABHM8AABvVeuAAC4QCAAAIFGog///GpwCAAEE+0A== Date: Wed, 9 Oct 2013 14:28:00 +0000 Message-ID: References: <20131009.161830.1731740457994143646.mbj@tail-f.com> In-Reply-To: <20131009.161830.1731740457994143646.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 14:29:00 -0000 > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Wednesday, October 09, 2013 10:19 AM > To: Lange, Jeffrey K (GE Energy Management) > Cc: lhotka@nic.cz; netmod@ietf.org > Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt >=20 > "Lange, Jeffrey K (GE Energy Management)" wrote: > > If things are kept how they are >=20 > I can go either way - keep it as it is, or move the neighbor state to > per-interface. I think it is pretty trivial to implement this even if > there is a global table, and it is also pretty trivial to filter in > all lists; for example, to get all neighbors w/ ip address 10.0.0.1: >=20 > /interfaces-state/interface/ipv4/neighbor[ip=3D'10.0.0.1'] >=20 > The same query with the current design (one global list): >=20 > /ip-state/ipv4/neighbor[ip=3D'10.0.0.1'] >=20 My feelings are that "/ip-state" just seems out of place in this model. All= IP configuration that is defined is per-interface. So it just seems a bit = awkward to have this extra state container sitting at the top of the tree. -Jeff >=20 > > I would still change the > > link-layer-address in the neighbor list to be mandatory. >=20 > Agreed. >=20 >=20 >=20 > /martin >=20 >=20 >=20 > > I also still suggest adding the neighbor state to > > /ip-state/ipv4/neighbor, although I understand Martin's concern that > > this is not "defined" as a standard for ARP. This is very useful > > information when you are trying to debug connectivity issues. > > > > -Jeff > > > > > Lada > > > > > > > > > > > -Jeff > > > > > > > > > > -- > > > Ladislav Lhotka, CZ.NIC Labs > > > PGP Key ID: E74E8C0C > > > > > > > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > From mbj@tail-f.com Wed Oct 9 07:32:27 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E30421F9C52 for ; Wed, 9 Oct 2013 07:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.946 X-Spam-Level: X-Spam-Status: No, score=-1.946 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 SdOQxKcoRebn for ; Wed, 9 Oct 2013 07:32:21 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 9C84321F9C4C for ; Wed, 9 Oct 2013 07:32:21 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id BB5B512003B0; Wed, 9 Oct 2013 16:32:19 +0200 (CEST) Date: Wed, 09 Oct 2013 16:32:19 +0200 (CEST) Message-Id: <20131009.163219.1457271997412930956.mbj@tail-f.com> To: jeffrey.K.lange@ge.com From: Martin Bjorklund In-Reply-To: References: <20131009.161830.1731740457994143646.mbj@tail-f.com> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 14:32:27 -0000 "Lange, Jeffrey K (GE Energy Management)" wrote: > > -----Original Message----- > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > Sent: Wednesday, October 09, 2013 10:19 AM > > To: Lange, Jeffrey K (GE Energy Management) > > Cc: lhotka@nic.cz; netmod@ietf.org > > Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt > > > > "Lange, Jeffrey K (GE Energy Management)" > > wrote: > > > If things are kept how they are > > > > I can go either way - keep it as it is, or move the neighbor state to > > per-interface. I think it is pretty trivial to implement this even if > > there is a global table, and it is also pretty trivial to filter in > > all lists; for example, to get all neighbors w/ ip address 10.0.0.1: > > > > /interfaces-state/interface/ipv4/neighbor[ip='10.0.0.1'] > > > > The same query with the current design (one global list): > > > > /ip-state/ipv4/neighbor[ip='10.0.0.1'] > > > > My feelings are that "/ip-state" just seems out of place in this > model. All IP configuration that is defined is per-interface. So it > just seems a bit awkward to have this extra state container sitting at > the top of the tree. Yes, I think you are right. It would be very useful to hear other people's opinions as well. /martin From andy@yumaworks.com Wed Oct 9 07:33:32 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A03F21F9CA6 for ; Wed, 9 Oct 2013 07:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DaEe-X6sfR9p for ; Wed, 9 Oct 2013 07:33:27 -0700 (PDT) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) by ietfa.amsl.com (Postfix) with ESMTP id 8867E11E8183 for ; Wed, 9 Oct 2013 07:33:21 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id i13so1574001qae.9 for ; Wed, 09 Oct 2013 07:33:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=cVDYOreIkwAn5xdH+tuU4dZo7jEN0g59eEOvLWCdPV8=; b=gW6A6TZgomkZpIZZ9jLP5UyLjMcala6CBdM2pGcPbKGR4/Y8mkJF+F/TmZ0hsxHDvv b7LI2jwDWpA9MuU8oCWh5y2pObg/Gzt5n9LJz7Hi/qIhSAnOUSgSAu3CuM7GT22hhfVC UGXFO952CXIffaJuBD1vIZNyRQb/mp+TYwggfKZ0mniPJa6IeyJPFai89CpDJ0Qth7AR SPz1yo9qTkG5G5ErsMZHAP9GnzLTAvOL7vAVQMV6Ccn17TeQ7AlVGABEHch+JQwVG8cF 5Q2nqlCs40xd4RykdS2JSqwAsgN4nu+l646b+Ot2Du9Uhwwh7koCPxKwRfcxzNicLGZV 8/WQ== X-Gm-Message-State: ALoCoQkC3GcEDFOh5yZuyrWPhuosDipT9FgY6YdNfchukb8VPdaPidWKRGEma8DRDj87cXb/ZPf2 MIME-Version: 1.0 X-Received: by 10.49.94.72 with SMTP id da8mr9678382qeb.67.1381329196497; Wed, 09 Oct 2013 07:33:16 -0700 (PDT) Received: by 10.140.26.209 with HTTP; Wed, 9 Oct 2013 07:33:16 -0700 (PDT) In-Reply-To: References: <20130923152837.32168.80619.idtracker@ietfa.amsl.com> Date: Wed, 9 Oct 2013 07:33:16 -0700 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=047d7b5d4e3c134dde04e84fc4dc Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 14:33:32 -0000 --047d7b5d4e3c134dde04e84fc4dc Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 9, 2013 at 6:11 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > > > Hi, > > > > I have implemented all of this draft for YANG-API (draft -01 version). > > I think the NETMOD WG should standardize this document. > > Thanks, Andy. > > > > > Comments: > > > > Sec 3.4: IANA Considerations > > > > I think a new media type is needed (yjson?). > > In the RESTCONF draft the generic "json" string is used in > > media types, but really this draft is required, not plain JSON. > > > > Accept: application/vnd.yang.data+yjson > > ^^^^^ instead of json > > Far from being an expert on the use of media types, I think the format is > nothing but standard JSON. Using a new media type means that generic > processors and intermediaries are out of luck. > > OK - I guess clients that don't know about the module-name prefixes will not attempt to do anything other than display the JSON received from the server. Clients that know the JSON represents YANG data will also know what to do with specially encoded strings. Andy > > > > > Sec 3.5: Security Considerations > > > > You should replace [TBD] with a short paragraph stating > > that no new security threats are added by this spec, since > > it is not a protocol or a data model for a protocol. > > Yes, I'll do that. > > Lada > > > > > > > Andy > > > > > > On Mon, Sep 23, 2013 at 8:33 AM, Ladislav Lhotka wrote: > > > >> Hi, > >> > >> this revision of JSON mapping document clarifies several issues, mainly > >> based on Andy's feedback. Several new examples appear in the text, and > >> appendix A contains a complete translation of the reply from > appendix > >> D of draft-ietf-netmod-interfaces-cfg-12. > >> > >> Lada > >> > >> Begin forwarded message: > >> > >> > From: internet-drafts@ietf.org > >> > Subject: New Version Notification for > >> draft-lhotka-netmod-yang-json-02.txt > >> > Date: September 23, 2013 5:28:37 PM GMT+02:00 > >> > To: Ladislav Lhotka > >> > > >> > > >> > A new version of I-D, draft-lhotka-netmod-yang-json-02.txt > >> > has been successfully submitted by Ladislav Lhotka and posted to the > >> > IETF repository. > >> > > >> > Filename: draft-lhotka-netmod-yang-json > >> > Revision: 02 > >> > Title: Modeling JSON Text with YANG > >> > Creation date: 2013-09-23 > >> > Group: Individual Submission > >> > Number of pages: 19 > >> > URL: > >> > http://www.ietf.org/internet-drafts/draft-lhotka-netmod-yang-json-02.txt > >> > Status: > >> http://datatracker.ietf.org/doc/draft-lhotka-netmod-yang-json > >> > Htmlized: > >> http://tools.ietf.org/html/draft-lhotka-netmod-yang-json-02 > >> > Diff: > >> http://www.ietf.org/rfcdiff?url2=draft-lhotka-netmod-yang-json-02 > >> > > >> > Abstract: > >> > This document defines rules for presenting configuration and > >> > operational state data defined using YANG as JSON text. It does so > >> > by specifying a procedure for translating the subset of YANG- > >> > compatible XML documents to JSON text, and vice versa. > >> > > >> > > >> > > >> > > >> > Please note that it may take a couple of minutes from the time of > >> submission > >> > until the htmlized version and diff are available at tools.ietf.org. > >> > > >> > The IETF Secretariat > >> > > >> > >> -- > >> Ladislav Lhotka, CZ.NIC Labs > >> PGP Key ID: E74E8C0C > >> > >> > >> > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > >> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --047d7b5d4e3c134dde04e84fc4dc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Oct 9, 2013 at 6:11 AM, Ladislav Lhotka &= lt;lhotka@nic.cz>= wrote:
Andy Bierman <andy@yumaworks.com> writes:

> Hi,
>
> I have implemented all of this draft for YANG-API (draft -01 version).=
> I think the NETMOD WG should standardize this document.

Thanks, Andy.

>
> Comments:
>
> Sec 3.4: IANA Considerations
>
> I think a new media type is needed (yjson?).
> In the RESTCONF draft the generic "json" string is used in > media types, but really this draft is required, not plain JSON.
>
> Accept: application/vnd.yang.data+yjson
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^^^^^ instead of json

Far from being an expert on the use of media types, I think the format is n= othing but standard JSON. Using a new media type means that generic process= ors and intermediaries are out of luck.



OK - I guess clients th= at don't know about the module-name prefixes
will not attempt= to do anything other than display the JSON received
from the ser= ver. =A0Clients that know the JSON represents YANG data
will also know what to do with specially encoded strings.

Andy


>
>
> Sec 3.5: Security Considerations
>
> You should replace [TBD] with a short paragraph stating
> that no new security threats are added by this spec, since
> it is not a protocol or a data model for a protocol.

Yes, I'll do that.

Lada

>
>
> Andy
>
>
> On Mon, Sep 23, 2013 at 8:33 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
>> Hi,
>>
>> this revision of JSON mapping document clarifies several issues, m= ainly
>> based on Andy's feedback. Several new examples appear in the t= ext, and
>> appendix A contains a complete translation of the <get> repl= y from appendix
>> D of draft-ietf-netmod-interfaces-cfg-12.
>>
>> Lada
>>
>> Begin forwarded message:
>>
>> > From: internet-dr= afts@ietf.org
>> > Subject: New Version Notification for
>> draft-lhotka-netmod-yang-json-02.txt
>> > Date: September 23, 2013 5:28:37 PM GMT+02:00
>> > To: Ladislav Lhotka <lhot= ka@nic.cz>
>> >
>> >
>> > A new version of I-D, draft-lhotka-netmod-yang-json-02.txt >> > has been successfully submitted by Ladislav Lhotka and posted= to the
>> > IETF repository.
>> >
>> > Filename: =A0 =A0 =A0draft-lhotka-netmod-yang-json
>> > Revision: =A0 =A0 =A002
>> > Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Modeling JSON Text wit= h YANG
>> > Creation date: =A0 =A0 =A0 =A0 2013-09-23
>> > Group: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Individual Submission<= br> >> > Number of pages: 19
>> > URL:
>> http://www.ietf.org/internet-drafts/dr= aft-lhotka-netmod-yang-json-02.txt
>> > Status:
>> http://datatracker.ietf.org/doc/draft-lhotka-netm= od-yang-json
>> > Htmlized:
>> http://tools.ietf.org/html/draft-lhotka-netmod-yang= -json-02
>> > Diff:
>> http://www.ietf.org/rfcdiff?url2=3Ddraft-lh= otka-netmod-yang-json-02
>> >
>> > Abstract:
>> > =A0 This document defines rules for presenting configuration = and
>> > =A0 operational state data defined using YANG as JSON text. = =A0It does so
>> > =A0 by specifying a procedure for translating the subset of Y= ANG-
>> > =A0 compatible XML documents to JSON text, and vice versa. >> >
>> >
>> >
>> >
>> > Please note that it may take a couple of minutes from the tim= e of
>> submission
>> > until the htmlized version and diff are available at tools.ietf.org.
>> >
>> > The IETF Secretariat
>> >
>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>
>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
netmod@ietf.org
= https://www.ietf.org/mailman/listinfo/netmod

--047d7b5d4e3c134dde04e84fc4dc-- From jeffrey.K.lange@ge.com Fri Oct 11 05:58:40 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D298421E8102 for ; Fri, 11 Oct 2013 05:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.956 X-Spam-Level: X-Spam-Status: No, score=-5.956 tagged_above=-999 required=5 tests=[AWL=0.642, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 hv+HVJF1a7W3 for ; Fri, 11 Oct 2013 05:58:31 -0700 (PDT) Received: from exprod5og105.obsmtp.com (exprod5og105.obsmtp.com [64.18.0.180]) by ietfa.amsl.com (Postfix) with ESMTP id 5F50821F93BF for ; Fri, 11 Oct 2013 05:58:29 -0700 (PDT) Received: from cinmlip13.e2k.ad.ge.com ([12.71.149.1]) (using TLSv1) by exprod5ob105.postini.com ([64.18.4.12]) with SMTP ID DSNKUlf19NXRvItPd92bPdzgj7sPaYQP+r0K@postini.com; Fri, 11 Oct 2013 05:58:29 PDT Received: from unknown (HELO CINMBHT02.e2k.ad.ge.com) ([3.159.212.195]) by cinmlip13.e2k.ad.ge.com with ESMTP/TLS/AES128-SHA; 11 Oct 2013 08:58:27 -0400 Received: from CINURAPD05.e2k.ad.ge.com (3.159.212.117) by CINMBHT02.e2k.ad.ge.com (3.159.212.195) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 11 Oct 2013 08:58:25 -0400 Received: from CINURCNA15.e2k.ad.ge.com ([169.254.3.234]) by CINURAPD05.e2k.ad.ge.com ([169.254.7.134]) with mapi id 14.03.0146.000; Fri, 11 Oct 2013 08:58:25 -0400 From: "Lange, Jeffrey K (GE Energy Management)" To: "netmod@ietf.org" Thread-Topic: link-layer-address vs phys-address Thread-Index: Ac7GgSIJu1YpkXvERr2PANTxFdCGZw== Date: Fri, 11 Oct 2013 12:58:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: multipart/alternative; boundary="_000_B0FB1FAC2C7B234D87DCEBF309F703C56755BB35CINURCNA15e2kad_" MIME-Version: 1.0 Subject: [netmod] link-layer-address vs phys-address X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 12:58:40 -0000 --_000_B0FB1FAC2C7B234D87DCEBF309F703C56755BB35CINURCNA15e2kad_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The ietf-ip module uses the name link-layer-address for all nodes of type p= hys-address. Yet the ietf-interfaces module uses: /interfaces-state/interface/phys-address Should this also be changed to link-layer-address so that the naming is con= sistent across modules? -Jeff --_000_B0FB1FAC2C7B234D87DCEBF309F703C56755BB35CINURCNA15e2kad_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The ietf-ip module use= s the name link-layer-address for all nodes of type phys-address.  Yet the ietf-interfaces module uses:

 

/interfaces-state/interface/p= hys-address

 

Should this also be changed to link-layer-address so= that the naming is consistent across modules?

 

-Jeff

 

--_000_B0FB1FAC2C7B234D87DCEBF309F703C56755BB35CINURCNA15e2kad_-- From alex@cisco.com Mon Oct 14 21:04:54 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E786A21F9AA8 for ; Mon, 14 Oct 2013 21:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_43=0.6, 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 AERigEWc99Kb for ; Mon, 14 Oct 2013 21:04:50 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 321C721F996A for ; Mon, 14 Oct 2013 21:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3324; q=dns/txt; s=iport; t=1381809888; x=1383019488; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Sciw2XQPkfrXSHhHMLj08R9AIgLHz5rKMz+ndP6UiSw=; b=Fc29NMZM38OCOSBIXuOEgn84z/6k0yUMyFP1IrQtWaEsi+wMXGIJOOcI IQDsSikEkNimJrmDwN6iyW9fum0IXxpFUXvWtGBn1NEGaC867BoDStp2S YFt3ThFKfmLrkeO11dAckniMWQ4tOAhUPQjfi1pzSDXTTHtPO4M7xEfwF k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAJW9XFKtJXHB/2dsb2JhbABQBgODBzhSwVdLgR4WdIIlAQEBAwEBAQE3NAsFBwICAgEIEAEEAQEBChQJBxsMCxQJCAIEAQ0FCId4Bgy9XQSOBIERIRAHBguDDoEGA6oGgySCKQ X-IronPort-AV: E=Sophos;i="4.93,496,1378857600"; d="scan'208";a="272106929" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 15 Oct 2013 04:04:47 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9F44lIb006143 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Oct 2013 04:04:47 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.21]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Mon, 14 Oct 2013 23:04:46 -0500 From: "Alexander Clemm (alex)" To: Ladislav Lhotka , Andy Bierman , "Juergen Schoenwaelder (j.schoenwaelder@jacobs-university.de)" Thread-Topic: [netmod] comments on draft-clemm-netmod-yang-network-topo-00.txt Thread-Index: AQHOjpP7xOTPIW73P0+wV5vZCV5BBJmAYvYAgAAgWACAdRMuIA== Date: Tue, 15 Oct 2013 04:04:45 +0000 Message-ID: References: <20130801084843.GA25224@elstar.local> <869CC112-E4DC-4A20-A1B1-814D65A31708@nic.cz> In-Reply-To: <869CC112-E4DC-4A20-A1B1-814D65A31708@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] comments on draft-clemm-netmod-yang-network-topo-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 04:04:55 -0000 Hi Juergen, Lada, Andy, =20 Thank you for your feedback, and apologies for being "offline" for so long.= =20 Quick responses to Juergen's points: - It would certainly be possible to use YANG identities to represent topolo= gy types. The reason why we chose the route of instead simply introducing = a container per topology type, with the corresponding topology type-specifi= c data inside it, was that this still brings across what type of topology i= t is - this is simply expressed by the container element - while avoiding t= he need for another integrity constraint, such as that use of a certain con= tainer requires that the topology type MUST be of a certain identity. Obvi= ously, this can all be subject to further discussions, but this appeared a = simpler choice. =20 - The choice of URI as identifier, rather than arbitrary identifier, has to= do with the potential to have nodes, links, and termination points refer t= o entities e.g. in a network inventory, or organize them according to some = other criteria. Again, subject to further discussions. =20 - Will be happy to not make it experimental but standards track Kind regards --- Alex -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of= Ladislav Lhotka Sent: Thursday, August 01, 2013 4:00 AM To: Andy Bierman Cc: netmod@ietf.org Subject: Re: [netmod] comments on draft-clemm-netmod-yang-network-topo-00.t= xt On Aug 1, 2013, at 11:04 AM, Andy Bierman wrote: > Hi, >=20 > I just want to add that I was very impressed with this draft. > A lot of work was done on the design and the actual data node=20 > specifications, and it shows. >=20 > I support adoption of this draft as a NETMOD work item, to produce a=20 > standards track RFC. > (agree w/Juergen Experimental is not desirable). +1 Lada >=20 >=20 > Andy >=20 >=20 > On Thu, Aug 1, 2013 at 1:48 AM, Juergen Schoenwaelder=20 > wrote: >> Hi, >>=20 >> I have read the document with quite some interest since it kind of=20 >> paves the way to do _network_ management instead of just device=20 >> management. I am wondering about two little technical details: >>=20 >> a) Why do you not use YANG identities to represent topology types? >>=20 >> b) Why do you use inet:uri as the base type for node-id, link-id, and >> tp-id? >>=20 >> The I-D status says 'Intended Status: Experimental' - was your idea=20 >> to submit this for eventual publication as an experimental RFC? >>=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 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From j.schoenwaelder@jacobs-university.de Tue Oct 15 00:27:12 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9224B11E810E for ; Tue, 15 Oct 2013 00:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.196 X-Spam-Level: X-Spam-Status: No, score=-103.196 tagged_above=-999 required=5 tests=[AWL=0.053, 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 QWxYyQ0yCoO9 for ; Tue, 15 Oct 2013 00:27:07 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA5721E80B2 for ; Tue, 15 Oct 2013 00:27:07 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 80B6720041; Tue, 15 Oct 2013 09:27:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id DE_uXqEDstLA; Tue, 15 Oct 2013 09:27:06 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F25B020048; Tue, 15 Oct 2013 09:27:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 48A7528D8CF1; Tue, 15 Oct 2013 09:27:01 +0200 (CEST) Date: Tue, 15 Oct 2013 09:27:01 +0200 From: Juergen Schoenwaelder To: "Lange, Jeffrey K (GE Energy Management)" Message-ID: <20131015072701.GB24295@elstar.local> Mail-Followup-To: "Lange, Jeffrey K (GE Energy Management)" , Ladislav Lhotka , "netmod@ietf.org" References: <20131007.162048.1755792130247781311.mbj@tail-f.com> <4AF146A6-D3E4-409B-BFEA-BE75D538E2F2@nic.cz> 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: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 07:27:12 -0000 On Mon, Oct 07, 2013 at 09:04:57PM +0000, Lange, Jeffrey K (GE Energy Management) wrote: > > How about the following? > > Move /interfaces/interface/ipv[46]/neighbor to /ip/ipv[46]/neighbor and add an optional interface-ref to the list? > I also made link-layer-address mandatory, as without that it's not a very useful configuration entry. This now gives a place where system-wide IP settings can be augmented into. > I think this approach fails if you need to configure the same IP address neighbor on different interfaces. We need to consider link-local addresses etc. in our design. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Tue Oct 15 00:35:10 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13A6A11E811B for ; Tue, 15 Oct 2013 00:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.199 X-Spam-Level: X-Spam-Status: No, score=-103.199 tagged_above=-999 required=5 tests=[AWL=0.050, 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 mUg1S9XXLVUe for ; Tue, 15 Oct 2013 00:35: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 DA99611E8104 for ; Tue, 15 Oct 2013 00:35:01 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 391332004A; Tue, 15 Oct 2013 09:35:01 +0200 (CEST) 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 rCDUwtKcwiQg; Tue, 15 Oct 2013 09:35:01 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 63D6020048; Tue, 15 Oct 2013 09:35:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AD8EF28D8D46; Tue, 15 Oct 2013 09:34:55 +0200 (CEST) Date: Tue, 15 Oct 2013 09:34:55 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20131015073455.GC24295@elstar.local> Mail-Followup-To: Andy Bierman , "Lange, Jeffrey K (GE Energy Management)" , "netmod@ietf.org" References: <20130825203831.20582.30133.idtracker@ietfa.amsl.com> <20131001.204034.194996395.mbj@tail-f.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: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 07:35:10 -0000 On Wed, Oct 02, 2013 at 11:59:30AM -0700, Andy Bierman wrote: > > > > A lot of investment has been made in the IANA interface > > > type registry and I want vendors to use it. If every > > > vendor can replace these enums with their own definitions, > > > then 3rd party clients will have to hard-code the identities > > > used by each server vendor. That is not very interoperable. > > > > I am in no way advocating abandoning this registry, but forewarning that > > if it is overly restrictive in allowing someone to do what they need, it > > won't get used at all. > > > I do not agree the current IANA-based registry is unusable. > My conclusion (as technical contributor) here is that the IANA registry (a) contains junk (ugly but not really a problem) and (b) has been optimized for monitoring (since entries are related to interface type specific monitoring MIB modules), not for configuration. The later is a problem - whatever we do, we will likely need additional registrations for configuration - so whether we have a flat registry (the current one) or a new one, we will face this sooner than later. As Lada said, a type hierarchy requires XPATH functions to be able to use it effectively in YANG data models. We discussed before that YANG needs a collection of XPATH functions - but we don't have them. So we essentially have two options: a) Use the flat IANA registry and be done, even though it is not very flexible. b) Stall the document until a suitable collection of XPATH functions has been defined. c) Move to an identity based type hierarchy with an understanding that this requires to define XPATH functions to be really useful. Personally, I believe for configuration, you likely want an interface type hierarchy if you were to design a product yourself. Getting this hierarchy defined/standardized properly, however, will not be trivial. If this is done carelessly, we will end up with a mess over the years. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Tue Oct 15 03:51:45 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B3711E81D3 for ; Tue, 15 Oct 2013 03:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.971 X-Spam-Level: X-Spam-Status: No, score=-1.971 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 0YoaoH0wUVTN for ; Tue, 15 Oct 2013 03:51:39 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id DD5A611E81CE for ; Tue, 15 Oct 2013 03:51:37 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 772F112000B4 for ; Tue, 15 Oct 2013 12:51:34 +0200 (CEST) Date: Tue, 15 Oct 2013 12:51:34 +0200 (CEST) Message-Id: <20131015.125134.1167345424645234375.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [netmod] open issue draft-ietf-netmod-ip-cfg-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 10:51:45 -0000 Hi, There is one open issue left in the ip-cfg document. Currently, neighbors are configured per interface, but the neighbor operational state is global: Config: /interfaces/interface[name]/ipvX/neighbor[ip] Oper: /ip-state/ipvX/neigbor[interface ip] It was suggested that we harmonize this, so that the neighbor operational state is also per interface: New oper: /interfaces-state/interface[name]/ipvX/neighbor[ip] The other ip-related state is already per interface. Note that the data available is exactly the same. So we have two alternatives: A) Keep current design B) Move neighbor operational state to the interface state In the previous thread, Lada preferres A, and Jeff and myself B. What do other people think? /martin From andy@yumaworks.com Tue Oct 15 05:04:38 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E309A21F9A97 for ; Tue, 15 Oct 2013 05:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.774 X-Spam-Level: X-Spam-Status: No, score=-2.774 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 wmJbkGrFUnj5 for ; Tue, 15 Oct 2013 05:04:34 -0700 (PDT) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0D64111E818F for ; Tue, 15 Oct 2013 05:04:32 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id f11so3262599qae.7 for ; Tue, 15 Oct 2013 05:04:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=eWW9qCZuyWw9n/d3zxSWYLkc2aRiT/pQDe0U20Apaa4=; b=CfwWzIFYMcj7Vt//gwvBtHpA0fOrajNikUsCXbCDhR3CyMchd2emo1pMZpGTd37JwP Yf6OrdGn6XimOrKTjcuZvO+KqGr+wgOxDMwmwzbg02XFvjv4iUCkdXo2PoA1yKsjELQ8 /FGyTpIkVxajgxB/Cufi+FWEsymVTO4zkU8/i7ZUgu1qbktetMJ6/GlhIwOJad64phYe 0eQihqPQefqa7qYO2mOAO78xjPzA/AHsR9p/oM5Ub4P2cgb0+KLqMQfI6peE1l5FKU9i MSsYd9Ibq0eqI+1c9MkgfgxtZXVP4U3eguzHv4u8aqNCqNlvSAQsyVSXFYlx8QNs0rJ7 2xVg== X-Gm-Message-State: ALoCoQlod8auMCsocpMRnUMtOczZmuXp/0e4oPdOz2D73TUgGNigUjLMq+BaTprJogFuVcBQbiyi MIME-Version: 1.0 X-Received: by 10.49.50.7 with SMTP id y7mr32885252qen.45.1381838672181; Tue, 15 Oct 2013 05:04:32 -0700 (PDT) Received: by 10.140.21.175 with HTTP; Tue, 15 Oct 2013 05:04:31 -0700 (PDT) In-Reply-To: <20131015073455.GC24295@elstar.local> References: <20130825203831.20582.30133.idtracker@ietfa.amsl.com> <20131001.204034.194996395.mbj@tail-f.com> <20131015073455.GC24295@elstar.local> Date: Tue, 15 Oct 2013 05:04:31 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , "Lange, Jeffrey K (GE Energy Management)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=047d7bdc1a80314ae404e8c6635c Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 12:04:39 -0000 --047d7bdc1a80314ae404e8c6635c Content-Type: text/plain; charset=ISO-8859-1 Hi, I strongly object to replacing the enumeration controlled by IANA with an identityref controlled by vendors. An additional leaf with values not controlled by IANA is acceptable. Andy On Tue, Oct 15, 2013 at 12:34 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Oct 02, 2013 at 11:59:30AM -0700, Andy Bierman wrote: > > > > > > A lot of investment has been made in the IANA interface > > > > type registry and I want vendors to use it. If every > > > > vendor can replace these enums with their own definitions, > > > > then 3rd party clients will have to hard-code the identities > > > > used by each server vendor. That is not very interoperable. > > > > > > I am in no way advocating abandoning this registry, but forewarning > that > > > if it is overly restrictive in allowing someone to do what they need, > it > > > won't get used at all. > > > > > I do not agree the current IANA-based registry is unusable. > > > > My conclusion (as technical contributor) here is that the IANA > registry (a) contains junk (ugly but not really a problem) and (b) has > been optimized for monitoring (since entries are related to interface > type specific monitoring MIB modules), not for configuration. > > The later is a problem - whatever we do, we will likely need > additional registrations for configuration - so whether we have a flat > registry (the current one) or a new one, we will face this sooner than > later. > > As Lada said, a type hierarchy requires XPATH functions to be able to > use it effectively in YANG data models. We discussed before that YANG > needs a collection of XPATH functions - but we don't have them. So > we essentially have two options: > > a) Use the flat IANA registry and be done, even though it is not very > flexible. > > b) Stall the document until a suitable collection of XPATH functions > has been defined. > > c) Move to an identity based type hierarchy with an understanding that > this requires to define XPATH functions to be really useful. > > Personally, I believe for configuration, you likely want an interface > type hierarchy if you were to design a product yourself. Getting this > hierarchy defined/standardized properly, however, will not be trivial. > If this is done carelessly, we will end up with a mess over the years. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --047d7bdc1a80314ae404e8c6635c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I strongly object to replacing the = enumeration controlled by IANA
with an identityref controlled by = vendors.=A0

An additional leaf with values not controlled by IANA is acceptable.

Andy
<= div class=3D"gmail_extra">

On Tue, Oct 15= , 2013 at 12:34 AM, Juergen Schoenwaelder <j.schoenwael= der@jacobs-university.de> wrote:
On Wed, Oct 02, 2013 at 11:59:30AM -0700, An= dy Bierman wrote:
>
> > > A lot of investment has been made in the IANA interface
> > > type registry and I want vendors to use it. =A0If every
> > > vendor can replace these enums with their own definitions, > > > then 3rd party clients will have to hard-code the identities=
> > > used by each server vendor. =A0That is not very interoperabl= e.
> >
> > I am in no way advocating abandoning this registry, but forewarni= ng that
> > if it is overly restrictive in allowing someone to do what they n= eed, it
> > won't get used at all.
> >
> I do not agree the current IANA-based registry is unusable.
>

My conclusion (as technical contributor) here is that the IANA
registry (a) contains junk (ugly but not really a problem) and (b) has
been optimized for monitoring (since entries are related to interface
type specific monitoring MIB modules), not for configuration.

The later is a problem - whatever we do, we will likely need
additional registrations for configuration - so whether we have a flat
registry (the current one) or a new one, we will face this sooner than
later.

As Lada said, a type hierarchy requires XPATH functions to be able to
use it effectively in YANG data models. We discussed before that YANG
needs a collection of XPATH functions - but we don't have them. So
we essentially have two options:

a) Use the flat IANA registry and be done, even though it is not very
=A0 =A0flexible.

b) Stall the document until a suitable collection of XPATH functions
=A0 =A0has been defined.

c) Move to an identity based type hierarchy with an understanding that
=A0 =A0this requires to define XPATH functions to be really useful.

Personally, I believe for configuration, you likely want an interface
type hierarchy if you were to design a product yourself. Getting this
hierarchy defined/standardized properly, however, will not be trivial.
If this is done carelessly, we will end up with a mess over the years.

/js

--
Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, German= y
Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/><= br>

--047d7bdc1a80314ae404e8c6635c-- From j.schoenwaelder@jacobs-university.de Tue Oct 15 05:13:58 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF4E21E80BF for ; Tue, 15 Oct 2013 05:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.202 X-Spam-Level: X-Spam-Status: No, score=-103.202 tagged_above=-999 required=5 tests=[AWL=0.047, 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 0aLYurgelV9e for ; Tue, 15 Oct 2013 05:13:53 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 384D211E81DA for ; Tue, 15 Oct 2013 05:13:53 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 912EA20062; Tue, 15 Oct 2013 14:13:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 9I1WnqMcdMyN; Tue, 15 Oct 2013 14:13:52 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 24B5820053; Tue, 15 Oct 2013 14:13:52 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6D8DD28D9BFF; Tue, 15 Oct 2013 14:13:47 +0200 (CEST) Date: Tue, 15 Oct 2013 14:13:47 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20131015121347.GB25419@elstar.local> Mail-Followup-To: Andy Bierman , "Lange, Jeffrey K (GE Energy Management)" , "netmod@ietf.org" References: <20131001.204034.194996395.mbj@tail-f.com> <20131015073455.GC24295@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: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 12:13:58 -0000 On Tue, Oct 15, 2013 at 05:04:31AM -0700, Andy Bierman wrote: > Hi, > > I strongly object to replacing the enumeration controlled by IANA > with an identityref controlled by vendors. > > An additional leaf with values not controlled by IANA is acceptable. It might be more constructive to respond to the technical issues and trade-offs I have described. IANA can very well maintain standard identities. A standard to configure, lets say 802.11 networks, will have to allocate a standard interface type. The same goes to a standard to configure PPP tunnels. You have worked for several vendors in the past and you may want to check how many of them used the currently registered interface types for _configuration_. /js PS: As co-chair, I note your position. -- 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 Tue Oct 15 05:20:13 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C597411E81DC for ; Tue, 15 Oct 2013 05:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.786 X-Spam-Level: X-Spam-Status: No, score=-2.786 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 U97zgyj2I3Bv for ; Tue, 15 Oct 2013 05:20:04 -0700 (PDT) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) by ietfa.amsl.com (Postfix) with ESMTP id 31E6D21F9DBD for ; Tue, 15 Oct 2013 05:20:01 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id f11so3325712qae.14 for ; Tue, 15 Oct 2013 05:20:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=ETxOr7oX4TGysVtNMXTHUKqazyTZ5gTQ1v2dCXOzxpk=; b=Y1MCZ6aW9uxHAUsXjpTRR/ZFdq83ANSMQE9LR5+AzjDe1Ws5kjnX6NYdXHJWc7/8Zm TkhxGNWm7Y764TzMui0o9+lcwLwX1U5rc8XS6r0DUwf7KU/9ujSo2mVuYDA6jTSD6m6D A9t6EQB8zaSPwC1TTGJXBIrNo6gFIIUu/5kPSNYxqaljmICWJ25cgbwRQuLS9PH59THa iQjsbHxbN48LzR0CnO7UJgPx61KDN94OeBCgJKqr8D8L1ngl/TwNN7DJOEzXl1Xxz9hG ZGEyz3X2dPwKvT3Zy+ZzemGx7C55PQIjItJKhsI8qN504C5B9uTG/6v9pxGTUmD1JKgE Mq8A== X-Gm-Message-State: ALoCoQlv0dEozzAhWwQsbY7KTIsvHug8UYGth3D1KeIAxTnelrNNuIF+4UhwypvtrC47RFRYNYTi MIME-Version: 1.0 X-Received: by 10.49.96.225 with SMTP id dv1mr2207970qeb.89.1381839600420; Tue, 15 Oct 2013 05:20:00 -0700 (PDT) Received: by 10.140.21.175 with HTTP; Tue, 15 Oct 2013 05:20:00 -0700 (PDT) In-Reply-To: <20131015121347.GB25419@elstar.local> References: <20131001.204034.194996395.mbj@tail-f.com> <20131015073455.GC24295@elstar.local> <20131015121347.GB25419@elstar.local> Date: Tue, 15 Oct 2013 05:20:00 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , "Lange, Jeffrey K (GE Energy Management)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=047d7bb049468526ac04e8c69a3f Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 12:20:13 -0000 --047d7bb049468526ac04e8c69a3f Content-Type: text/plain; charset=ISO-8859-1 Hi, I have brought up this concern before a few times, so I wonder why it was ignored in your issue summary. IMO, picking the most appropriate value from a closed standard list is better than picking what amounts to an arbitrary value from an unbounded list. If every vendor is allowed to replace the IANA identities with their own, then it isn't IANA if-type anymore. A 3rd party client developer has no idea what values will be used on a server implementation. Andy On Tue, Oct 15, 2013 at 5:13 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Oct 15, 2013 at 05:04:31AM -0700, Andy Bierman wrote: > > Hi, > > > > I strongly object to replacing the enumeration controlled by IANA > > with an identityref controlled by vendors. > > > > An additional leaf with values not controlled by IANA is acceptable. > > It might be more constructive to respond to the technical issues and > trade-offs I have described. IANA can very well maintain standard > identities. A standard to configure, lets say 802.11 networks, will > have to allocate a standard interface type. The same goes to a > standard to configure PPP tunnels. > > You have worked for several vendors in the past and you may want to > check how many of them used the currently registered interface types > for _configuration_. > > /js > > PS: As co-chair, I note your position. > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --047d7bb049468526ac04e8c69a3f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I have brought up this concern befo= re a few times, so I wonder why
it was ignored in your issue summ= ary. =A0IMO, picking the most appropriate
value from a closed sta= ndard list is better than picking what amounts
to an arbitrary value from an unbounded list.

If every vendor is allowed to replace the IANA identities with their
=
own, then it isn't IANA if-type anymore. A 3rd party client develo= per has
no idea what values will be used on a server implementation.


Andy



On Tue, Oct 15, 2013 at 5:= 13 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-un= iversity.de> wrote:
On Tue, Oct 15, 2013 at 05:04:31AM -0700, An= dy Bierman wrote:
> Hi,
>
> I strongly object to replacing the enumeration controlled by IANA
> with an identityref controlled by vendors.
>
> An additional leaf with values not controlled by IANA is acceptable.
It might be more constructive to respond to the technical issues and
trade-offs I have described. IANA can very well maintain standard
identities. A standard to configure, lets say 802.11 networks, will
have to allocate a standard interface type. The same goes to a
standard to configure PPP tunnels.

You have worked for several vendors in the past and you may want to
check how many of them used the currently registered interface types
for _configuration_.

/js

PS: As co-chair, I note your position.

--
Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, German= y
Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/><= br>

--047d7bb049468526ac04e8c69a3f-- From mbj@tail-f.com Tue Oct 15 05:35:07 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A97221F9FA5 for ; Tue, 15 Oct 2013 05:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.986 X-Spam-Level: X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 xMHJ1baOkH-9 for ; Tue, 15 Oct 2013 05:34:58 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id F3D7321F9E53 for ; Tue, 15 Oct 2013 05:34:56 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 0118712000B4; Tue, 15 Oct 2013 14:34:54 +0200 (CEST) Date: Tue, 15 Oct 2013 14:34:54 +0200 (CEST) Message-Id: <20131015.143454.1651796705288016701.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20131015121347.GB25419@elstar.local> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 12:35:07 -0000 Andy Bierman wrote: > Hi, > > I have brought up this concern before a few times, so I wonder why > it was ignored in your issue summary. IMO, picking the most appropriate > value from a closed standard list is better than picking what amounts > to an arbitrary value from an unbounded list. We are talking about the situation where a vendor must pick an appropriate interface type for the hardware he's got. If there is a matching if-type available, we're good in both cases (enum or identity). The question is what happens when there is no matching if-type available, as in Jeff's case. You are worried that a client won't know what to use in this case. But the current recommendation is to use if-type 'other' and use a vendor-specific leaf to identify the real type. Why is this solution better than an identity? I would argue that identities solves this problem; a third-party client can load all YANG modules available on the server, and present a list of all identities derived from 'if:interface-type'. This is much better than the vendor-specific extra leaf and if-type 'other'. /martin From j.schoenwaelder@jacobs-university.de Tue Oct 15 05:40:32 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 463A121F9D55 for ; Tue, 15 Oct 2013 05:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.205 X-Spam-Level: X-Spam-Status: No, score=-103.205 tagged_above=-999 required=5 tests=[AWL=0.044, 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 cbCI+Wu2v0PG for ; Tue, 15 Oct 2013 05:40:25 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6272511E81DF for ; Tue, 15 Oct 2013 05:40:21 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id BD0692003F; Tue, 15 Oct 2013 14:40:20 +0200 (CEST) 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 2yDpWSUZP5HB; Tue, 15 Oct 2013 14:40:20 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3F8ED20035; Tue, 15 Oct 2013 14:40:20 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C05F828D9CB2; Tue, 15 Oct 2013 14:40:13 +0200 (CEST) Date: Tue, 15 Oct 2013 14:40:13 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20131015124012.GC25419@elstar.local> Mail-Followup-To: Andy Bierman , "Lange, Jeffrey K (GE Energy Management)" , "netmod@ietf.org" References: <20131015073455.GC24295@elstar.local> <20131015121347.GB25419@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: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 12:40:33 -0000 On Tue, Oct 15, 2013 at 05:20:00AM -0700, Andy Bierman wrote: > Hi, > > I have brought up this concern before a few times, so I wonder why > it was ignored in your issue summary. IMO, picking the most appropriate > value from a closed standard list is better than picking what amounts > to an arbitrary value from an unbounded list. Because, as I keep writing, you can standardize identities as well. > If every vendor is allowed to replace the IANA identities with their > own, then it isn't IANA if-type anymore. A 3rd party client developer has > no idea what values will be used on a server implementation. If the configuration data model is standardized, the data model will also standardize the interface type. If the data model is not standardized, the value of having a known interface type is very small. /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 Tue Oct 15 05:45:33 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2EB21F9E96 for ; Tue, 15 Oct 2013 05:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[AWL=-0.282, 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 EZyeAxrLaCkm for ; Tue, 15 Oct 2013 05:45:24 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6BE11E81DA for ; Tue, 15 Oct 2013 05:45:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 122505403C7; Tue, 15 Oct 2013 14:45:13 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u87qIdCxu9yx; Tue, 15 Oct 2013 14:45:08 +0200 (CEST) Received: from [172.29.2.201] (unknown [172.29.2.201]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id C48E35401A9; Tue, 15 Oct 2013 14:45:03 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ladislav Lhotka In-Reply-To: <20131015.143454.1651796705288016701.mbj@tail-f.com> Date: Tue, 15 Oct 2013 14:45:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3CEA70F7-3457-4EFB-97AE-5810640EE35A@nic.cz> References: <20131015121347.GB25419@elstar.local> <20131015.143454.1651796705288016701.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1510) Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 12:45:33 -0000 On Oct 15, 2013, at 2:34 PM, Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >>=20 >> I have brought up this concern before a few times, so I wonder why >> it was ignored in your issue summary. IMO, picking the most = appropriate >> value from a closed standard list is better than picking what amounts >> to an arbitrary value from an unbounded list. >=20 > We are talking about the situation where a vendor must pick an > appropriate interface type for the hardware he's got. If there is a > matching if-type available, we're good in both cases (enum or > identity). The question is what happens when there is no matching > if-type available, as in Jeff's case. You are worried that a client > won't know what to use in this case. But the current > recommendation is to use if-type 'other' and use a vendor-specific > leaf to identify the real type. Why is this solution better than an > identity? >=20 > I would argue that identities solves this problem; a third-party > client can load all YANG modules available on the server, and present > a list of all identities derived from 'if:interface-type'. This is > much better than the vendor-specific extra leaf and if-type 'other'. >=20 +1 And we just have to do the long-postponed homework and write a spec for = the new XPath functions. They are badly needed anyway. Lada >=20 >=20 > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Tue Oct 15 06:22:05 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B26D11E818B for ; Tue, 15 Oct 2013 06:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 PK85+qkiBMQV for ; Tue, 15 Oct 2013 06:22:00 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0447811E81DA for ; Tue, 15 Oct 2013 06:21:46 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id n9so2835342qcw.15 for ; Tue, 15 Oct 2013 06:21:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=WcWsVzHJRQjlGrmIhKrqVq9Gb89w5xoMeYqKsKZJVv8=; b=PJTLefdccqhnLgmTPPmuhLlH63394sXgxcaXvj0zl5ut9sk6xBCu1WnvuHx6fMNaqK JTGBw8QLjO2vnDtepI6jXXFvzjZr+24g1LbzHIr6Tay9ZVaaNUERUsWcTKnbrO95BI6N x4TyumaiYzhQMqnjwEoSYQRBB1ClJpnuG8HxWtYSBJGMpW9zLGMSIyu6m5IHQ3kaIi4G 4nXncULcMyoMpolTYLR99217bAplvV5RtRV9aDXvS2OXd11BO0Vpzd2Y367TrxPyIY1g 6aKXJfIVJFfq0eUjRiNIOLkGeRiNxIy50Lulu58WHglVeMIsPfy9FwHYetnBhUOWKrIJ SsJw== X-Gm-Message-State: ALoCoQmKLZ6PEP6da0aiHh1ez3pmEe8dJPbCRW3l/uoe6V2lgqnCop9uzaBOtlZ9AvPnooXcnDXz MIME-Version: 1.0 X-Received: by 10.49.50.7 with SMTP id y7mr33461003qen.45.1381843305630; Tue, 15 Oct 2013 06:21:45 -0700 (PDT) Received: by 10.140.21.175 with HTTP; Tue, 15 Oct 2013 06:21:45 -0700 (PDT) In-Reply-To: <20131015124012.GC25419@elstar.local> References: <20131015073455.GC24295@elstar.local> <20131015121347.GB25419@elstar.local> <20131015124012.GC25419@elstar.local> Date: Tue, 15 Oct 2013 06:21:45 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , "Lange, Jeffrey K (GE Energy Management)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=047d7bdc1a805e1e8004e8c77758 Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 13:22:05 -0000 --047d7bdc1a805e1e8004e8c77758 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 15, 2013 at 5:40 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Oct 15, 2013 at 05:20:00AM -0700, Andy Bierman wrote: > > Hi, > > > > I have brought up this concern before a few times, so I wonder why > > it was ignored in your issue summary. IMO, picking the most appropriate > > value from a closed standard list is better than picking what amounts > > to an arbitrary value from an unbounded list. > > Because, as I keep writing, you can standardize identities as well. > There is nothing to prevent every vendor from replacing the IANA values with their own identities. This is not possible with an enumeration. > > > If every vendor is allowed to replace the IANA identities with their > > own, then it isn't IANA if-type anymore. A 3rd party client developer has > > no idea what values will be used on a server implementation. > > If the configuration data model is standardized, the data model will > also standardize the interface type. If the data model is not > standardized, the value of having a known interface type is very > small. > If IANA if-type is not useful then why bother using it at all? Come up with a new enumeration, or give up and call it a proprietary field. Make if-type a plain string so vendors have maximum flexibility. Why bother encoding arbitrary strings as arbitrary identities? > /js > > Andy --047d7bdc1a805e1e8004e8c77758 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Oct 15, 2013 at 5:40 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Oct 15, 2013 at 05:20:00AM -0700, An= dy Bierman wrote:
> Hi,
>
> I have brought up this concern before a few times, so I wonder why
> it was ignored in your issue summary. =A0IMO, picking the most appropr= iate
> value from a closed standard list is better than picking what amounts<= br> > to an arbitrary value from an unbounded list.

Because, as I keep writing, you can standardize identities as well.


There is nothing to prevent eve= ry vendor from replacing the IANA values
with their own identitie= s. =A0This is not possible with an enumeration.
=A0

> If every vendor is allowed to replace the IANA identities with their > own, then it isn't IANA if-type anymore. A 3rd party client develo= per has
> no idea what values will be used on a server implementation.

If the configuration data model is standardized, the data model will
also standardize the interface type. If the data model is not
standardized, the value of having a known interface type is very
small.


If IANA if-type i= s not useful then why bother using it at all?
Come up with a new = enumeration, or give up and call it
a proprietary field. =A0Make = if-type a plain string so vendors
have maximum flexibility. =A0Why bother encoding arbitrary strings
as arbitrary identities?



/js

=A0
Andy

=
--047d7bdc1a805e1e8004e8c77758-- From j.schoenwaelder@jacobs-university.de Tue Oct 15 07:01:11 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3CD721F81FF for ; Tue, 15 Oct 2013 07:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.208 X-Spam-Level: X-Spam-Status: No, score=-103.208 tagged_above=-999 required=5 tests=[AWL=0.041, 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 MVdrvA77cUmG for ; Tue, 15 Oct 2013 07:01:06 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B05E021E8109 for ; Tue, 15 Oct 2013 07:01:01 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id AF8192006D; Tue, 15 Oct 2013 16:00:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id MFcYVLjAwUC5; Tue, 15 Oct 2013 16:00:59 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 784D620064; Tue, 15 Oct 2013 16:00:58 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0B32428D9EFF; Tue, 15 Oct 2013 16:00:51 +0200 (CEST) Date: Tue, 15 Oct 2013 16:00:51 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20131015140051.GB25577@elstar.local> Mail-Followup-To: Andy Bierman , "Lange, Jeffrey K (GE Energy Management)" , "netmod@ietf.org" References: <20131015073455.GC24295@elstar.local> <20131015121347.GB25419@elstar.local> <20131015124012.GC25419@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: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 14:01:11 -0000 On Tue, Oct 15, 2013 at 06:21:45AM -0700, Andy Bierman wrote: > > If IANA if-type is not useful then why bother using it at all? > Come up with a new enumeration, or give up and call it > a proprietary field. Make if-type a plain string so vendors > have maximum flexibility. Why bother encoding arbitrary strings > as arbitrary identities? > As I keep saying, you can have standardized identities. I guess I will stop repeating this now. /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 Tue Oct 15 07:22:14 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B5221E80FE for ; Tue, 15 Oct 2013 07:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.808 X-Spam-Level: X-Spam-Status: No, score=-2.808 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 Svva0s6ftI0x for ; Tue, 15 Oct 2013 07:22:09 -0700 (PDT) Received: from mail-qe0-f41.google.com (mail-qe0-f41.google.com [209.85.128.41]) by ietfa.amsl.com (Postfix) with ESMTP id A25EA21E80BC for ; Tue, 15 Oct 2013 07:22:08 -0700 (PDT) Received: by mail-qe0-f41.google.com with SMTP id x7so5045199qeu.0 for ; Tue, 15 Oct 2013 07:22:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=BVYcB3VnUR9qzcSkWEaFZya7TZV43/AuV9IJo5jUiP4=; b=YhrHVmGPu+RbHJhyd7bQpligmZd9ni3MlFKQvRjRfrlPsZZV33mT9T0UYOels5m/af u/5x1spzBta5bB8Us9yHi5bYJ0SJz8H7yW0C/TjLM9qUdvtQOPPwPdUhEJbU+oov5FPX guA9ADbkUtZFwdAzHSfw3jMbqk+YJ+U+Xzdg3k0GiCd52TuzxIuPtJp71lYnUXrBdUNj pVpNpSbSegujwXughstDs8r8aY0HMj9VHxJ0mJ5TR407pepaZo5P18IRf0pZrjn44a1p rpWrVBmmxMj/1GtBljwFneS2/6Rq7U9o7apjnTvGk+GpE/I3sGvf1FXXCwTpjwEqn4Ed IyDA== X-Gm-Message-State: ALoCoQnPbfprrkiKqzPAs15Rj95uvIChzaSP1FdliOsX6BkLOAFgT3cFdHXUtGuQuifyfpn7vNE8 MIME-Version: 1.0 X-Received: by 10.224.111.195 with SMTP id t3mr30312651qap.49.1381846926633; Tue, 15 Oct 2013 07:22:06 -0700 (PDT) Received: by 10.140.21.175 with HTTP; Tue, 15 Oct 2013 07:22:06 -0700 (PDT) In-Reply-To: <20131015140051.GB25577@elstar.local> References: <20131015073455.GC24295@elstar.local> <20131015121347.GB25419@elstar.local> <20131015124012.GC25419@elstar.local> <20131015140051.GB25577@elstar.local> Date: Tue, 15 Oct 2013 07:22:06 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , "Lange, Jeffrey K (GE Energy Management)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=047d7b60457e323e3e04e8c84f9e Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 14:22:14 -0000 --047d7b60457e323e3e04e8c84f9e Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 15, 2013 at 7:00 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Oct 15, 2013 at 06:21:45AM -0700, Andy Bierman wrote: > > > > If IANA if-type is not useful then why bother using it at all? > > Come up with a new enumeration, or give up and call it > > a proprietary field. Make if-type a plain string so vendors > > have maximum flexibility. Why bother encoding arbitrary strings > > as arbitrary identities? > > > > As I keep saying, you can have standardized identities. I guess I will > stop repeating this now. > > And I keep saying that there is a difference between the value MUST be a standard value or not. This makes a big difference to client developers. The "name" field is a proprietary string that can have embedded semantics that the client needs to know in advance in order to create an interface. A device MAY restrict the allowed values for this leaf, possibly depending on the type of the interface. Whether the "type" field is a proprietary identityref or proprietary string doesn't make much difference. If the client does not know the exact values to use apriori then it cannot create interfaces. I do not understand why an additional leaf is not being considered: leaf extended-type { when "../type = 'other'"; type identityref { base if-extended-types; } } If the IANA type is sufficient then use it. If it says 'other' then the server uses the extended if-type instead. BTW, why is the XPath problem such a big deal? Our code fully supports identityrefs in XPath. We also have a YANG extension that tags string types as QNames, so the XPath parser knows what to do. http://www.netconfcentral.org/modules/yuma-ncx/2013-05-25#qname.631 So how many vendors out there support the :xpath capability but do not support identityrefs as QNames? If this is not a real problem then identityrefs should not be avoided. (If you don't support XPath evaluation then you can hardwire identityref handling along with everything else when supporting must/when expressions. /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --047d7b60457e323e3e04e8c84f9e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Oct 15, 2013 at 7:00 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Oct 15, 2013 at 06:21:45AM -0700, Andy Bierman wro= te:
>
> If IANA if-type is not useful then why bother using it at all?
> Come up with a new enumeration, or give up and call it
> a proprietary field. =A0Make if-type a plain string so vendors
> have maximum flexibility. =A0Why bother encoding arbitrary strings
> as arbitrary identities?
>

As I keep saying, you can have standardized identities. I guess I will
stop repeating this now.


And I keep saying that there is a difference between the v= alue
MUST be a standard value or not. =A0This makes a big differe= nce
to client developers.

The "name" fi= eld is a proprietary string that can have embedded
semantics that= the client needs to know in advance in order to
create an interf= ace.

       A device MAY restrict the allowed values for this=
 leaf,
       possibly depending on the type of the interface.


Whether the "type" field is a proprietary=A0identityref or proprietary string
doesn't make muc=
h difference.  If the client does not know the


exact values to use apri=
ori then it cannot create interfaces.




I do not under=
stand why an additional leaf is not being considered:
leaf extended-type {
when "../type =3D 'other'"= ;;
type identityref {
base if-extended-types;
}
}

If the IANA t= ype is sufficient then use it.
If it says 'other' then the server uses the exte= nded if-type
instead.

BTW, why is t= he XPath problem such a big deal?
Our code fully supports = identityrefs in XPath.
We also have a YANG e= xtension that tags string types
as QNames, so the XPath parser knows what to do.=


So how many vendors out there support the :xpath capability
but do not su= pport identityrefs as QNames? =A0If this is not a real
problem then identityrefs should not be avoided.

(If you don't= support XPath evaluation then you can hardwire
ide= ntityref handling along with everything else when supporting
must/when ex= pressions.
/js


Andy
=A0
=
--
Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, German= y
Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/><= br>

--047d7b60457e323e3e04e8c84f9e-- From lhotka@nic.cz Tue Oct 15 07:27:09 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB44F21E8123 for ; Tue, 15 Oct 2013 07:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.346 X-Spam-Level: X-Spam-Status: No, score=-1.346 tagged_above=-999 required=5 tests=[AWL=-0.251, 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 05LunTqRsmWI for ; Tue, 15 Oct 2013 07:27:05 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 19F5E21E8128 for ; Tue, 15 Oct 2013 07:26:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 7C13A5403C7; Tue, 15 Oct 2013 16:26:46 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZk0V0H669iK; Tue, 15 Oct 2013 16:26:38 +0200 (CEST) Received: from [172.29.2.201] (unknown [172.29.2.201]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 51265540218; Tue, 15 Oct 2013 16:26:34 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 15 Oct 2013 16:26:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131015073455.GC24295@elstar.local> <20131015121347.GB25419@elstar.local> <20131015124012.GC25419@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.1510) Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 14:27:10 -0000 On Oct 15, 2013, at 3:21 PM, Andy Bierman wrote: >=20 >=20 >=20 > On Tue, Oct 15, 2013 at 5:40 AM, Juergen Schoenwaelder = wrote: > On Tue, Oct 15, 2013 at 05:20:00AM -0700, Andy Bierman wrote: > > Hi, > > > > I have brought up this concern before a few times, so I wonder why > > it was ignored in your issue summary. IMO, picking the most = appropriate > > value from a closed standard list is better than picking what = amounts > > to an arbitrary value from an unbounded list. >=20 > Because, as I keep writing, you can standardize identities as well. >=20 >=20 > There is nothing to prevent every vendor from replacing the IANA = values > with their own identities. This is not possible with an enumeration. Most likely, the registry entries like "ethernetCsmacd", "tunnel" or = "other" will be heavily overloaded, hence not very interesting. If there = is another vendor-controlled leaf, it will be the distinguishing = parameter for augments etc. IMO it is much better if a vendor *derives* = their own identity from a standardised identity such as = "iana-if:ethernet". Lada > =20 >=20 > > If every vendor is allowed to replace the IANA identities with their > > own, then it isn't IANA if-type anymore. A 3rd party client = developer has > > no idea what values will be used on a server implementation. >=20 > If the configuration data model is standardized, the data model will > also standardize the interface type. If the data model is not > standardized, the value of having a known interface type is very > small. >=20 >=20 > If IANA if-type is not useful then why bother using it at all? > Come up with a new enumeration, or give up and call it > a proprietary field. Make if-type a plain string so vendors > have maximum flexibility. Why bother encoding arbitrary strings > as arbitrary identities? >=20 >=20 >=20 > /js >=20 > =20 > Andy >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Tue Oct 15 07:37:20 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3697D21E80C8 for ; Tue, 15 Oct 2013 07:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XPRRwjP96p3 for ; Tue, 15 Oct 2013 07:37:16 -0700 (PDT) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) by ietfa.amsl.com (Postfix) with ESMTP id 8C92F21E81C7 for ; Tue, 15 Oct 2013 07:37:11 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id q4so5983626qcx.26 for ; Tue, 15 Oct 2013 07:37:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=d7KB0ZzIkpnzx8LOgUxh2RATIgVDuNNUit/UTYLM0zM=; b=Qm+T299dNG4ejpRd/x47VYWfWkB95IGEDBM494I04atAsNSUjGcfg99JmpcQIKz87+ C5CZHCs9tsWv1+lSTMSKkA517pgtn6CCsvLGdU4ApwhJx5MGWGM+Oo5TAhkBO6qcV94Y jz63rzR+VIdp9E7u4r4X266x+GVZ9p/CU6Ulf4SHWuj2OguAnmARD3hgCelvwGjjzTzR DhaP5o5BcP18CsAqaFRLiJuRphAdyXKyL55LnVuDaIheOY7Iq1MU41SfWMuEH+CwFtxv Bts7dLOXR71gapGFAfQfiTyKnagQEqj0EN8xlu7CrcrIHvarov723S+aU750UJwiQ93N 3yzA== X-Gm-Message-State: ALoCoQkjIBIPCQamb+U1mlXX3hsP3fG/MOLscK+GgURaBS0urSu+ygHddrviJjitX48EOmTxc3wU MIME-Version: 1.0 X-Received: by 10.49.35.15 with SMTP id d15mr45802159qej.16.1381847823532; Tue, 15 Oct 2013 07:37:03 -0700 (PDT) Received: by 10.140.21.175 with HTTP; Tue, 15 Oct 2013 07:37:03 -0700 (PDT) In-Reply-To: References: <20131015073455.GC24295@elstar.local> <20131015121347.GB25419@elstar.local> <20131015124012.GC25419@elstar.local> Date: Tue, 15 Oct 2013 07:37:03 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=047d7b6dcbe0a7d6e304e8c8843e Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 14:37:20 -0000 --047d7b6dcbe0a7d6e304e8c8843e Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 15, 2013 at 7:26 AM, Ladislav Lhotka wrote: > > On Oct 15, 2013, at 3:21 PM, Andy Bierman wrote: > > > > > > > > > On Tue, Oct 15, 2013 at 5:40 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > On Tue, Oct 15, 2013 at 05:20:00AM -0700, Andy Bierman wrote: > > > Hi, > > > > > > I have brought up this concern before a few times, so I wonder why > > > it was ignored in your issue summary. IMO, picking the most > appropriate > > > value from a closed standard list is better than picking what amounts > > > to an arbitrary value from an unbounded list. > > > > Because, as I keep writing, you can standardize identities as well. > > > > > > There is nothing to prevent every vendor from replacing the IANA values > > with their own identities. This is not possible with an enumeration. > > Most likely, the registry entries like "ethernetCsmacd", "tunnel" or > "other" will be heavily overloaded, hence not very interesting. If there is > another vendor-controlled leaf, it will be the distinguishing parameter for > augments etc. IMO it is much better if a vendor *derives* their own > identity from a standardised identity such as "iana-if:ethernet". > > I do not think this is a valuable feature. Vendors manage their own registration roots already. The undocumented embedded semantics in the "name" field take care of ambiguities in the "type" field. There is another problem with identities instead of enumerations. If identities are used exclusively then the "value-stmt" data is lost in standard YANG. This is important for SNMP alignment because ifType is encoded on the wire as an integer. There is no way whatsoever to map a YANG identity to an integer without using the description-stmt or a new extension. Lada > > Andy > > > > > > > If every vendor is allowed to replace the IANA identities with their > > > own, then it isn't IANA if-type anymore. A 3rd party client developer > has > > > no idea what values will be used on a server implementation. > > > > If the configuration data model is standardized, the data model will > > also standardize the interface type. If the data model is not > > standardized, the value of having a known interface type is very > > small. > > > > > > If IANA if-type is not useful then why bother using it at all? > > Come up with a new enumeration, or give up and call it > > a proprietary field. Make if-type a plain string so vendors > > have maximum flexibility. Why bother encoding arbitrary strings > > as arbitrary identities? > > > > > > > > /js > > > > > > Andy > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --047d7b6dcbe0a7d6e304e8c8843e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Oct 15, 2013 at 7:26 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:

On Oct 15, 2013, at 3:21 PM, Andy Bierman <andy@yumaworks.com> wrote:

>
>
>
> On Tue, Oct 15, 2013 at 5:40 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-univers= ity.de> wrote:
> On Tue, Oct 15, 2013 at 05:20:00AM -0700, Andy Bierman wrote:
> > Hi,
> >
> > I have brought up this concern before a few times, so I wonder wh= y
> > it was ignored in your issue summary. =A0IMO, picking the most ap= propriate
> > value from a closed standard list is better than picking what amo= unts
> > to an arbitrary value from an unbounded list.
>
> Because, as I keep writing, you can standardize identities as well. >
>
> There is nothing to prevent every vendor from replacing the IANA value= s
> with their own identities. =A0This is not possible with an enumeration= .

Most likely, the registry entries like "ethernetCsmacd", "tu= nnel" or "other" will be heavily overloaded, hence not very = interesting. If there is another vendor-controlled leaf, it will be the dis= tinguishing parameter for augments etc. IMO it is much better if a vendor *= derives* their own identity from a standardised identity such as "iana= -if:ethernet".



I do not think this is = a valuable feature.
Vendors manage their own registration roots a= lready.
The undocumented embedded semantics in the "name&quo= t; field
take care of ambiguities in the "type" field.

=
There is another problem with identities instead of enumerations= .
If identities are used exclusively then the "value-stmt&qu= ot; data is lost in standard YANG.
This is important for SNMP alignment because ifType is encoded
on the wire as an integer. =A0 There is no way whatsoever to map
a YANG identity to an integer without using the description-stmt
or a new extension.


Lada


Andy
=A0
>
>
> > If every vendor is allowed to replace the IANA identities with th= eir
> > own, then it isn't IANA if-type anymore. A 3rd party client d= eveloper has
> > no idea what values will be used on a server implementation.
>
> If the configuration data model is standardized, the data model will > also standardize the interface type. If the data model is not
> standardized, the value of having a known interface type is very
> small.
>
>
> If IANA if-type is not useful then why bother using it at all?
> Come up with a new enumeration, or give up and call it
> a proprietary field. =A0Make if-type a plain string so vendors
> have maximum flexibility. =A0Why bother encoding arbitrary strings
> as arbitrary identities?
>
>
>
> /js
>
>
> Andy
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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





--047d7b6dcbe0a7d6e304e8c8843e-- From jeffrey.K.lange@ge.com Tue Oct 15 07:43:47 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F26421E81D7 for ; Tue, 15 Oct 2013 07:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.600, 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 Or0xXQerkMGh for ; Tue, 15 Oct 2013 07:43:36 -0700 (PDT) Received: from exprod5og102.obsmtp.com (exprod5og102.obsmtp.com [64.18.0.143]) by ietfa.amsl.com (Postfix) with ESMTP id EB26921E8164 for ; Tue, 15 Oct 2013 07:43:34 -0700 (PDT) Received: from alpmlip12.e2k.ad.ge.com ([165.156.5.1]) (using TLSv1) by exprod5ob102.postini.com ([64.18.4.12]) with SMTP ID DSNKUl1Ulvws1NVzuIk0skK6yo54Qum7ee+F@postini.com; Tue, 15 Oct 2013 07:43:35 PDT Received: from unknown (HELO CINMBHT03.e2k.ad.ge.com) ([3.159.212.196]) by alpmlip12.e2k.ad.ge.com with ESMTP/TLS/AES128-SHA; 15 Oct 2013 10:43:33 -0400 Received: from CINURCNA23.e2k.ad.ge.com (3.159.212.171) by CINMBHT03.e2k.ad.ge.com (3.159.212.196) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 15 Oct 2013 10:43:33 -0400 Received: from CINURCNA15.e2k.ad.ge.com ([169.254.3.234]) by CINURCNA23.e2k.ad.ge.com ([169.254.4.225]) with mapi id 14.03.0146.000; Tue, 15 Oct 2013 10:43:32 -0400 From: "Lange, Jeffrey K (GE Energy Management)" To: Andy Bierman , Juergen Schoenwaelder , "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt Thread-Index: AQHOodMlLyqCZb9RQkC9WKRHJHDjA5ngXCKwgABOsgD//8GvEIAAUmyAgADgLUCAAHMHgP//v6AAgABwsACAE68KgIAAS1OAgAACl4CAAAG9AIAABaaAgAALmoCAAArtgIAABfAA//++rqA= Date: Tue, 15 Oct 2013 14:43:32 +0000 Message-ID: References: <20131015073455.GC24295@elstar.local> <20131015121347.GB25419@elstar.local> <20131015124012.GC25419@elstar.local> <20131015140051.GB25577@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 14:43:47 -0000 > >I do not understand why an additional leaf is not being considered: > > > leaf extended-type { > when "../type =3D 'other'"; > > type identityref { > base if-extended-types; > > } > } > > >If the IANA type is sufficient then use it. > >If it says 'other' then the server uses the extended if-type >instead. The end-user usability of this is very poor. If a user is creating a confi= guration entry for an interface type, they will want a singular configurati= on point ('type'). Making someone have to remember that when they are confi= guring an interface that is not somewhere in the nearly 300 entries in the = iana-if-type enum that they have to use the value 'other' is an unreasonabl= e expectation for a user of a product. If someone is configuring a LTE cell= ular interface, in their minds they are not configuring an interface of typ= e 'other', they are configuring a LTE interface. We MUST remember that not all users of systems that will implement this dat= a model will be certified network professionals. Any place where things ca= n be simplified without losing functionality should be simplified. And add= ing a second leaf just so we can keep the iana-iftype as is just doesn't ma= ke sense from a simplified usability standpoint. Even something as standard as the "ethernetCsmacd" is horrible from = a usability standpoint. Who refers to Ethernet devices as "Ethernet Csmacd"= ??? -Jeff From lhotka@nic.cz Tue Oct 15 07:45:55 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B69121E80C6 for ; Tue, 15 Oct 2013 07:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.321 X-Spam-Level: X-Spam-Status: No, score=-1.321 tagged_above=-999 required=5 tests=[AWL=-0.226, 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 zvGcnUe4ix+8 for ; Tue, 15 Oct 2013 07:45:51 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id B8CEB21F9FD6 for ; Tue, 15 Oct 2013 07:45:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id D392A5403C7; Tue, 15 Oct 2013 16:45:44 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHRFTS4U4-ac; Tue, 15 Oct 2013 16:45:41 +0200 (CEST) Received: from [172.29.2.201] (unknown [172.29.2.201]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id EDA785401A9; Tue, 15 Oct 2013 16:45:40 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 15 Oct 2013 16:45:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <04E91B91-7DAA-444B-8B1F-7EDD6618E012@nic.cz> References: <20131015073455.GC24295@elstar.local> <20131015121347.GB25419@elstar.local> <20131015124012.GC25419@elstar.local> <20131015140051.GB25577@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.1510) Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 14:45:55 -0000 On Oct 15, 2013, at 4:22 PM, Andy Bierman wrote: >=20 >=20 >=20 > On Tue, Oct 15, 2013 at 7:00 AM, Juergen Schoenwaelder = wrote: > On Tue, Oct 15, 2013 at 06:21:45AM -0700, Andy Bierman wrote: > > > > If IANA if-type is not useful then why bother using it at all? > > Come up with a new enumeration, or give up and call it > > a proprietary field. Make if-type a plain string so vendors > > have maximum flexibility. Why bother encoding arbitrary strings > > as arbitrary identities? > > >=20 > As I keep saying, you can have standardized identities. I guess I will > stop repeating this now. >=20 >=20 > And I keep saying that there is a difference between the value > MUST be a standard value or not. This makes a big difference > to client developers. A client may just check that an interface type is derived from a = supported standard type and be happy with it.=20 >=20 > The "name" field is a proprietary string that can have embedded > semantics that the client needs to know in advance in order to > create an interface. >=20 > A device MAY restrict the allowed values for this leaf, > possibly depending on the type of the interface. >=20 >=20 > Whether the "type" field is a proprietary identityref or proprietary = string > doesn't make much difference. If the client does not know the >=20 > exact values to use apriori then it cannot create interfaces. >=20 >=20 >=20 > I do not understand why an additional leaf is not being considered: >=20 >=20 > leaf extended-type { > when "../type =3D 'other'"; What if a new interface is a special version of Ethernet?=20 >=20 > type identityref { > base if-extended-types; >=20 > } > } >=20 >=20 > If the IANA type is sufficient then use it. >=20 > If it says 'other' then the server uses the extended if-type > instead. >=20 >=20 > BTW, why is the XPath problem such a big deal? >=20 > Our code fully supports identityrefs in XPath. > We also have a YANG extension that tags string types > as QNames, so the XPath parser knows what to do. This is all non-standard because RFC 6020 states: YANG relies on XML Path Language (XPath) 1.0 [XPATH] =85 and=20 o The function library is the core function library defined in [XPATH], and a function "current()" that returns a node set with the initial context node. >=20 > http://www.netconfcentral.org/modules/yuma-ncx/2013-05-25#qname.631 >=20 >=20 >=20 > So how many vendors out there support the :xpath capability > but do not support identityrefs as QNames? If this is not a real > problem then identityrefs should not be avoided. It is not only equality of identities that matters but also their = partial ordering, otherwise identities don't make much sense. Lada >=20 > (If you don't support XPath evaluation then you can hardwire >=20 > identityref handling along with everything else when supporting > must/when expressions. >=20 >=20 > /js >=20 >=20 > Andy > =20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From ietfdbh@comcast.net Tue Oct 15 07:54:29 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F29021E81CC for ; Tue, 15 Oct 2013 07:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 pNV-yEd1LoNp for ; Tue, 15 Oct 2013 07:54:24 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id E6D2D21E81D7 for ; Tue, 15 Oct 2013 07:54:14 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta01.westchester.pa.mail.comcast.net with comcast id dPWp1m0021c6gX851SuEaZ; Tue, 15 Oct 2013 14:54:14 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta23.westchester.pa.mail.comcast.net with comcast id dSuD1m00T2yZEBF3jSuDzy; Tue, 15 Oct 2013 14:54:14 +0000 From: "ietfdbh" To: "'Juergen Schoenwaelder'" , "'Andy Bierman'" References: <20131015073455.GC24295@elstar.local> <20131015121347.GB25419@elstar.local> <20131015124012.GC25419@elstar.local> <20131015140051.GB25577@elstar.local> In-Reply-To: <20131015140051.GB25577@elstar.local> Date: Tue, 15 Oct 2013 10:54:12 -0400 Message-ID: <024901cec9b6$69b6edb0$3d24c910$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGE0VUKV23xPZoei94NSSBCooBkXwK3T5y7AUuWaqwAxbNrRAGfwYOoAohFewAAstVgsQFdyxjGAWOb8h4CBvvnqQH9RTlpmgaA+IA= Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1381848854; bh=80rWJXLaVhVTfB1ISYOCyMhK/5vNViYwcPz7tv8cIyg=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=sgBcpch3vvwp84Ds2b36SThbNRV1vAVI2MWcIu/vSmjeJGB6YfZAGzNpr3vaxd9El RPnMqj73mA95axR7JpSGrat/byWYzvv8ri/ZFquLoiJHI0Mq9+ES5lLiJYE3ZtAPK0 z3c9b4ALe2IHqTIr9Du9yp5pPSnTj3qRaXscxF1CZv0nCHo91lhj/v7eTIMBTC2u6F c57xge0Ugd9UZtmK5+SSVCdDBlkNmVc6bkuXYAMRm839LpretcWuTh2b1A6/Bao5zz leVo+tzdRjKP2yxhRX5th4vZROo1LEEXB3ZJQ0n0+2kxzEUnNDK/NIFHvHKR8WcgT0 Roa9tg9OB58CQ== Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 14:54:29 -0000 Channeling Jeff Case ... Repetition is the key to learning. Let me repeat that. Repetition is the key to learning. David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Tuesday, October 15, 2013 10:01 AM > To: Andy Bierman > Cc: netmod@ietf.org > Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt > > On Tue, Oct 15, 2013 at 06:21:45AM -0700, Andy Bierman wrote: > > > > If IANA if-type is not useful then why bother using it at all? > > Come up with a new enumeration, or give up and call it > > a proprietary field. Make if-type a plain string so vendors > > have maximum flexibility. Why bother encoding arbitrary strings > > as arbitrary identities? > > > > As I keep saying, you can have standardized identities. I guess I will > stop repeating this now. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From andy@yumaworks.com Tue Oct 15 07:57:47 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1B221E80D3 for ; Tue, 15 Oct 2013 07:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.809 X-Spam-Level: X-Spam-Status: No, score=-2.809 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 YdMf0+WnNBAF for ; Tue, 15 Oct 2013 07:57:42 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 3B83821E81DB for ; Tue, 15 Oct 2013 07:57:29 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id w8so3494207qac.1 for ; Tue, 15 Oct 2013 07:57:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kIAMT4/M4soccaHISy9IErNQjHcoB9TEeaf7q9fMdzw=; b=ULj5lQr6OnXpUtErrUSoEuSO5BJCR2Zt6FDyj0BmewXYZCC6fLeoOCYhqvX1DMGatg lNjaS5F9K5k3KnT53xvZSKuoUOi03PK/8pNao1gghEmTR8RdPnvhSUDqE93Y5RsYOJFp /JtsxF5Cz/WpxyFGed2mOJNYLGZzSGPgy6XeThf00hVHkpnzm9Ws26LeeXGp3bn4GeJn yFJ7D5wvkB33HUcFbVX/64M2BLzlTycVgXaM6OEFQiMdT/FsRRhblStFT2YXfNjdo2Qv dOlo8TMmnFZJQVyR9ViaPiw+8smJUW+cgE/ieHMGeDAsFAg4+nSccdmEpmQBfGRfN4gO TSBg== X-Gm-Message-State: ALoCoQkgtPuYGUgclM5TA8pig2AYQTK0VWc3mBDIWtJ6CU8yOivZoYu6evbq8PbsZ37Dh8YyVvTe MIME-Version: 1.0 X-Received: by 10.49.58.225 with SMTP id u1mr34751165qeq.55.1381849048550; Tue, 15 Oct 2013 07:57:28 -0700 (PDT) Received: by 10.140.21.175 with HTTP; Tue, 15 Oct 2013 07:57:28 -0700 (PDT) In-Reply-To: References: <20131015073455.GC24295@elstar.local> <20131015121347.GB25419@elstar.local> <20131015124012.GC25419@elstar.local> <20131015140051.GB25577@elstar.local> Date: Tue, 15 Oct 2013 07:57:28 -0700 Message-ID: From: Andy Bierman To: "Lange, Jeffrey K (GE Energy Management)" Content-Type: multipart/alternative; boundary=047d7b5db978ac1d6804e8c8cd8b Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 14:57:47 -0000 --047d7b5db978ac1d6804e8c8cd8b Content-Type: text/plain; charset=ISO-8859-1 Hi, ... > Even something as standard as the "ethernetCsmacd" is horrible from > a usability standpoint. Who refers to Ethernet devices as "Ethernet > Csmacd"??? > > You are making my points for me: #1) if vendors all pick their own favorite names for this enum then client apps will have to deal with several identities that mean the same thing. #2) You are confusing the GUI display string with the on-the-wire PDU value. They do not have to be the same. You can achieve #1 in your GUIs using the standard enum. (BTW, SNMP uses an integer on-the-wire. I wonder if SNMP developers will try to convert their code to work with identities.) -Jeff > > Andy --047d7b5db978ac1d6804e8c8cd8b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

...
<rant> Even something as standard as the "ethernetCsmacd" i= s horrible from a usability standpoint. Who refers to Ethernet devices as &= quot;Ethernet Csmacd"??? </rant>


You are making my points for me:
=

#1) if vendors all pick their own favorite names for th= is enum then client
=A0 =A0 =A0 apps will have to deal with sever= al identities that mean the same thing.

#2) You are confusing the GUI display string with the o= n-the-wire PDU value.
=A0 =A0 =A0 They do not have to be the same= . You can achieve #1 in your GUIs
=A0 =A0 =A0 using the standard = enum.
=A0 =A0 =A0 (BTW, SNMP uses an integer on-the-wire. I wonder if S= NMP developers
=A0 =A0 =A0 =A0will try to convert their code to w= ork with identities.)

-Jeff



Andy

--047d7b5db978ac1d6804e8c8cd8b-- From andy@yumaworks.com Tue Oct 15 08:32:10 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E27721E8174 for ; Tue, 15 Oct 2013 08:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.817 X-Spam-Level: X-Spam-Status: No, score=-2.817 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 0ni9rQdxIGId for ; Tue, 15 Oct 2013 08:32:05 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id CD88F21E817E for ; Tue, 15 Oct 2013 08:32:04 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id ii20so3427341qab.17 for ; Tue, 15 Oct 2013 08:32:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=21X02K7h+Ver8sIfP5ey+jmS3y8SOKUB4TWUu5loWv4=; b=ONKcTvK07iJKZFupaT0gB7BhxF5oRNe5kMlNjt0gZ4ifhI7bf53c1lghVbKP1+vrtS Kn2SEzdCrGbNXoZ5DQ9PUYjqVF83g8A533QKPXqpP+ZlhbqGliOsHTWG61dnJ4QmGmmq jUSIF5Qyvbi9GoZGgwiaL6szwnFg4WRWFwNL0D8jpjUVa9PJZwCM9cVm0hbd41kyL1oM 2Y5LbSGEHrKk4okvMUB2/ihO83I3//7jFstj0rCQZOuFF8sp2CD45jlqwqRJWhC6zH9g oAvFjunaWRWVU7OyeKVM2lg8Lm7kZk8zmP7xTu9gsLfAlPdNPp8xiFMw/uAUmwmNPJJd JJeg== X-Gm-Message-State: ALoCoQkbgASfvoRL8rKgt6hPADhv9UDCMRJg+9AqTdYw7f5Ev2I9jySbVTnKi6JrslLmANeQDAaK MIME-Version: 1.0 X-Received: by 10.224.131.72 with SMTP id w8mr18419423qas.82.1381851123829; Tue, 15 Oct 2013 08:32:03 -0700 (PDT) Received: by 10.140.21.175 with HTTP; Tue, 15 Oct 2013 08:32:03 -0700 (PDT) In-Reply-To: <20131015073455.GC24295@elstar.local> References: <20130825203831.20582.30133.idtracker@ietfa.amsl.com> <20131001.204034.194996395.mbj@tail-f.com> <20131015073455.GC24295@elstar.local> Date: Tue, 15 Oct 2013 08:32:03 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , "Lange, Jeffrey K (GE Energy Management)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2dc465e60e204e8c949f0 Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 15:32:10 -0000 --001a11c2dc465e60e204e8c949f0 Content-Type: text/plain; charset=ISO-8859-1 Hi, > a) Use the flat IANA registry and be done, even though it is not very > flexible. > > b) Stall the document until a suitable collection of XPATH functions > has been defined. > > c) Move to an identity based type hierarchy with an understanding that > this requires to define XPATH functions to be really useful. > > Personally, I believe for configuration, you likely want an interface > type hierarchy if you were to design a product yourself. Getting this > hierarchy defined/standardized properly, however, will not be trivial. > If this is done carelessly, we will end up with a mess over the years. > > IMO (b) is a strawman since adding new XPath functions for YANG and/or :xpath filtering would require a new YANG language version. I will remove my objection and support (c). Interface creation is already proprietary because of the "name" leaf, so keeping this leaf an an enum does not preserve interoperability anyway. /js > Andy --001a11c2dc465e60e204e8c949f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,


a) Use the flat IANA registry and be done, even though it is not very
=A0 =A0flexible.

b) Stall the document until a suitable collection of XPATH functions
=A0 =A0has been defined.

c) Move to an identity based type hierarchy with an understanding that
=A0 =A0this requires to define XPATH functions to be really useful.

Personally, I believe for configuration, you likely want an interface
type hierarchy if you were to design a product yourself. Getting this
hierarchy defined/standardized properly, however, will not be trivial.
If this is done carelessly, we will end up with a mess over the years.


IMO (b) is a strawman since adding new XPath functio= ns for YANG
and/or :xpath filtering would require a new YANG lang= uage version.

I will remove my objection and support (c).
I= nterface creation is already proprietary
because of the "nam= e" leaf, so keeping this leaf
an an enum does not preserve i= nteroperability anyway.


/js

Andy

--001a11c2dc465e60e204e8c949f0-- From andy@yumaworks.com Tue Oct 15 08:51:31 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0307121E80C0 for ; Tue, 15 Oct 2013 08:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.825 X-Spam-Level: X-Spam-Status: No, score=-2.825 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 uUxhwZfV83W9 for ; Tue, 15 Oct 2013 08:51:25 -0700 (PDT) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8B621E80D1 for ; Tue, 15 Oct 2013 08:51:23 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id k4so2417987qaq.7 for ; Tue, 15 Oct 2013 08:51:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=h08c1LIE0RMDIFWOqmDOi6Z2nZ9mSxKyrHJfU5649Ks=; b=SMEn0VoCkAkj/+eLWdZjTtLdD2r+sUE2FKh9XhYFk8Z5qtRnTzB64oPNbZPk4Y18oT HXrUtYxR9XKankH5l5Mnjx83wC6hiS89BnwR0LZM5NZN+4yp7Bi1z24nKAnF48DCsAtS 2qS8QSlv4JuL9JWZQFvsb1KIsMm9QFslvLbsC75v1HAIxYo0Tis3+BjEEjUkVEeA/5ro aOpuzNkyFM/dgnN16bbyFd5zWhjRZgxZTrjRY20kIxEyUaBrgNz5ksHVTU1ReKcSg6mL Ef7MxeQkji1xks7jE92SpbIRhawal2yK8NSe/y4Jwu9q1owSv2EXy0jldLWUA3b8ZIOW LnLw== X-Gm-Message-State: ALoCoQlibSerN8LWbxb7JyIS61CdTUtJdszkZ5wzeuDivZS/kORRZ1xHWobfaclmrGTtA0Z6Tfbp MIME-Version: 1.0 X-Received: by 10.229.75.9 with SMTP id w9mr58052795qcj.0.1381852282656; Tue, 15 Oct 2013 08:51:22 -0700 (PDT) Received: by 10.140.21.175 with HTTP; Tue, 15 Oct 2013 08:51:22 -0700 (PDT) In-Reply-To: <20131015140051.GB25577@elstar.local> References: <20131015073455.GC24295@elstar.local> <20131015121347.GB25419@elstar.local> <20131015124012.GC25419@elstar.local> <20131015140051.GB25577@elstar.local> Date: Tue, 15 Oct 2013 08:51:22 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , "Lange, Jeffrey K (GE Energy Management)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a1133b96070acca04e8c98e51 Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 15:51:31 -0000 --001a1133b96070acca04e8c98e51 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 15, 2013 at 7:00 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Oct 15, 2013 at 06:21:45AM -0700, Andy Bierman wrote: > > > > If IANA if-type is not useful then why bother using it at all? > > Come up with a new enumeration, or give up and call it > > a proprietary field. Make if-type a plain string so vendors > > have maximum flexibility. Why bother encoding arbitrary strings > > as arbitrary identities? > > > > As I keep saying, you can have standardized identities. I guess I will > stop repeating this now. > > You can have standardized enumerations too. The difference is that you cannot have non-standard enumeration leaf values, but you can for identityref leafs. That distinction does not seem to be important to the WG. /js > Andy --001a1133b96070acca04e8c98e51 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Oct 15, 2013 at 7:00 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Oct 15, 2013 at 06:21:45AM -0700, An= dy Bierman wrote:
>
> If IANA if-type is not useful then why bother using it at all?
> Come up with a new enumeration, or give up and call it
> a proprietary field. =A0Make if-type a plain string so vendors
> have maximum flexibility. =A0Why bother encoding arbitrary strings
> as arbitrary identities?
>

As I keep saying, you can have standardized identities. I guess I will
stop repeating this now.


You can have standardized enumerations too.
The difference is that you cannot have non-standard
enumeration= leaf values, but you can for identityref leafs.
That distinction does not seem to be important to the WG.
/js


Andy
=A0
--001a1133b96070acca04e8c98e51-- From mbj@tail-f.com Tue Oct 15 12:23:11 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC0B811E81A4 for ; Tue, 15 Oct 2013 12:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 RBQYc8jh2t5o for ; Tue, 15 Oct 2013 12:23:06 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id CCA0A11E8186 for ; Tue, 15 Oct 2013 12:23:05 -0700 (PDT) Received: from localhost (unknown [193.12.34.23]) by mail.tail-f.com (Postfix) with ESMTPSA id CF7A212002EC; Tue, 15 Oct 2013 21:23:02 +0200 (CEST) Date: Tue, 15 Oct 2013 21:23:02 +0200 (CEST) Message-Id: <20131015.212302.521116693.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20131015140051.GB25577@elstar.local> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 19:23:11 -0000 Andy Bierman wrote: > On Tue, Oct 15, 2013 at 7:00 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Tue, Oct 15, 2013 at 06:21:45AM -0700, Andy Bierman wrote: > > > > > > If IANA if-type is not useful then why bother using it at all? > > > Come up with a new enumeration, or give up and call it > > > a proprietary field. Make if-type a plain string so vendors > > > have maximum flexibility. Why bother encoding arbitrary strings > > > as arbitrary identities? > > > > > > > As I keep saying, you can have standardized identities. I guess I will > > stop repeating this now. > > > > > And I keep saying that there is a difference between the value > MUST be a standard value or not. This makes a big difference > to client developers. > > The "name" field is a proprietary string that can have embedded > semantics that the client needs to know in advance in order to > create an interface. > > A device MAY restrict the allowed values for this leaf, > possibly depending on the type of the interface. > > > Whether the "type" field is a proprietary identityref or proprietary string > doesn't make much difference. The idea is to have standardized identities as well (did someone say this? ;) We need to consider vendors that see a value in following the standard. If there is a standard type available that matches what they need, they will use it. Vendors that don't want to follow the standard can invent whatever proprietary model they want. > If the client does not know the > exact values to use apriori then it cannot create interfaces. Agreed. Same goes for 'other' + vendor-specific leaf. Hmm, actually, the situation is slightly better for identities, at least for system-controlled interfaces, since the type of the interface is available in the /interfaces-state/interface list. A client that sees a proprietary identity that is derived from a standard identity it knows about knows more about the type than if it was a plain string. > BTW, why is the XPath problem such a big deal? > Our code fully supports identityrefs in XPath. > We also have a YANG extension that tags string types > as QNames, so the XPath parser knows what to do. > http://www.netconfcentral.org/modules/yuma-ncx/2013-05-25#qname.631 Again I agree. You have this extension, and we do something similar. The idea is to have a standard way of handling this instead of each vendor inventing something own. (Also, as Lada pointed out, both of us formally violate the spec with these extensions). /martin From andy@yumaworks.com Tue Oct 15 12:38:15 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5C411E81E9 for ; Tue, 15 Oct 2013 12:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.831 X-Spam-Level: X-Spam-Status: No, score=-2.831 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 EXngBr0q5s43 for ; Tue, 15 Oct 2013 12:38:08 -0700 (PDT) Received: from mail-qe0-f49.google.com (mail-qe0-f49.google.com [209.85.128.49]) by ietfa.amsl.com (Postfix) with ESMTP id 5570D11E81A4 for ; Tue, 15 Oct 2013 12:38:07 -0700 (PDT) Received: by mail-qe0-f49.google.com with SMTP id a11so1715760qen.36 for ; Tue, 15 Oct 2013 12:38:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BG9iIe07UbO1aC4MDqBWGhQKCGpgGxWRNwUtyVY3sms=; b=ZS1jJpvYTS93UrrZAdeBS4UnIJsfKjrpXNtJjGAxbO1sIV/dWMEhXkf2hgINOT+/uI OuOCGF31QIXsMu3xKeh2RUfQ+sr7rrrVGaa08o6g7D/d35L/P9jXbE5WVWgT+QL1+o1E roJx18jjRQUhdDd8Yme9drIx+LE/MBXT1iDHmgZpJnP6FlTcSCPEnXDQwWMVodMYawFt 4QcwXVn+y6quGGDNTZCZZPmo76qftkVV1E761E4Gb5vOL4u524lTImAKKmA8pZcify0B S0mCK2b3fiWZMvP/Ufa6cjY01okhK+m+w6Bop0lVIXqr96h38AF8KKzg0IJQ6DhmAmMT 1fww== X-Gm-Message-State: ALoCoQmDm6N95az7CGw8dVHrmctl+Hi9s5HnjNSTVNH63HYXIvK/WXPMhvJZo6lsttbwC0krdGCp MIME-Version: 1.0 X-Received: by 10.49.50.7 with SMTP id y7mr36257746qen.45.1381865886631; Tue, 15 Oct 2013 12:38:06 -0700 (PDT) Received: by 10.140.21.175 with HTTP; Tue, 15 Oct 2013 12:38:06 -0700 (PDT) In-Reply-To: <20131015.212302.521116693.mbj@tail-f.com> References: <20131015140051.GB25577@elstar.local> <20131015.212302.521116693.mbj@tail-f.com> Date: Tue, 15 Oct 2013 12:38:06 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=047d7bdc1a804cf29d04e8ccb92b Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 19:38:15 -0000 --047d7bdc1a804cf29d04e8ccb92b Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 15, 2013 at 12:23 PM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Tue, Oct 15, 2013 at 7:00 AM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > On Tue, Oct 15, 2013 at 06:21:45AM -0700, Andy Bierman wrote: > > > > > > > > If IANA if-type is not useful then why bother using it at all? > > > > Come up with a new enumeration, or give up and call it > > > > a proprietary field. Make if-type a plain string so vendors > > > > have maximum flexibility. Why bother encoding arbitrary strings > > > > as arbitrary identities? > > > > > > > > > > As I keep saying, you can have standardized identities. I guess I will > > > stop repeating this now. > > > > > > > > And I keep saying that there is a difference between the value > > MUST be a standard value or not. This makes a big difference > > to client developers. > > > > The "name" field is a proprietary string that can have embedded > > semantics that the client needs to know in advance in order to > > create an interface. > > > > A device MAY restrict the allowed values for this leaf, > > possibly depending on the type of the interface. > > > > > > Whether the "type" field is a proprietary identityref or proprietary > string > > doesn't make much difference. > > The idea is to have standardized identities as well (did someone say > this? ;) We need to consider vendors that see a value in following the > standard. If there is a standard type available that matches what > they need, they will use it. Vendors that don't want to follow the > standard can invent whatever proprietary model they want. > > I agreed to bail on the enumeration. The value field goes away so the coupling to SNMP is removed. Might aw well get rid of the values that are not relevant and start a standard if-type tree before vendors get too entrenched in proprietary solutions. > If the client does not know the > > exact values to use apriori then it cannot create interfaces. > > Agreed. Same goes for 'other' + vendor-specific leaf. Hmm, actually, > the situation is slightly better for identities, at least for > system-controlled interfaces, since the type of the interface is > available in the /interfaces-state/interface list. A client that sees > a proprietary identity that is derived from a standard identity it > knows about knows more about the type than if it was a plain string. > > Inspecting the identity tree helps for reading the value but not for knowing apriori what identities the server accepts for interface creation for a given request. > BTW, why is the XPath problem such a big deal? > > Our code fully supports identityrefs in XPath. > > We also have a YANG extension that tags string types > > as QNames, so the XPath parser knows what to do. > > http://www.netconfcentral.org/modules/yuma-ncx/2013-05-25#qname.631 > > Again I agree. You have this extension, and we do something similar. > The idea is to have a standard way of handling this instead of each > vendor inventing something own. (Also, as Lada pointed out, both of > us formally violate the spec with these extensions). > This is needed to encode XML correctly in a retrieval reply, not just for XPath. If the string node content has an XML prefix then there has to be an xmlns attribute to map it to a namespace or the client will not be able to determine the extended name. If we have to bump the YANG version number and create YANG2, then a whole lot of little details and wish-list items should be on the table. I don't know if starting on YANG 2.0 would discourage people from using YANG 1.0, or if YANG 2.0 should be a high priority right now. > /martin > Andy --047d7bdc1a804cf29d04e8ccb92b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Oct 15, 2013 at 12:23 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Tue, Oct 15, 2013 at 7:00 AM, Juergen Schoenwaelder <
> j.schoenwaelde= r@jacobs-university.de> wrote:
>
> > On Tue, Oct 15, 2013 at 06:21:45AM -0700, Andy Bierman wrote:
> > >
> > > If IANA if-type is not useful then why bother using it at al= l?
> > > Come up with a new enumeration, or give up and call it
> > > a proprietary field. =A0Make if-type a plain string so vendo= rs
> > > have maximum flexibility. =A0Why bother encoding arbitrary s= trings
> > > as arbitrary identities?
> > >
> >
> > As I keep saying, you can have standardized identities. I guess I= will
> > stop repeating this now.
> >
> >
> And I keep saying that there is a difference between the value
> MUST be a standard value or not. =A0This makes a big difference
> to client developers.
>
> The "name" field is a proprietary string that can have embed= ded
> semantics that the client needs to know in advance in order to
> create an interface.
>
> =A0 =A0 =A0 =A0A device MAY restrict the allowed values for this leaf,=
> =A0 =A0 =A0 =A0possibly depending on the type of the interface.
>
>
> Whether the "type" field is a proprietary identityref or pro= prietary string
> doesn't make much difference.

The idea is to have standardized identities as well (did someone say
this? ;) =A0We need to consider vendors that see a value in following the standard. =A0If there is a standard type available that matches what
they need, they will use it. =A0Vendors that don't want to follow the standard can invent whatever proprietary model they want.


I agreed to bail on the enumeration.
The value field goes away so the coupling to SNMP
is rem= oved. =A0 Might aw well get rid of the values
that are not releva= nt and start a standard if-type tree
before vendors get too entrenched in proprietary solutions.
=

> If the client does not know the
> exact values to use apriori then it cannot create interfaces.

Agreed. =A0Same goes for 'other' + vendor-specific leaf. =A0Hmm, ac= tually,
the situation is slightly better for identities, at least for
system-controlled interfaces, since the type of the interface is
available in the /interfaces-state/interface list. =A0A client that sees a proprietary identity that is derived from a standard identity it
knows about knows more about the type than if it was a plain string.



Inspecting the identity= tree helps for reading the value
but not for knowing apriori wha= t identities the server accepts for
interface creation for a give= n request.


> BTW, why is the XPath problem such a big deal?
> Our code fully supports identityrefs in XPath.
> We also have a YANG extension that tags string types
> as QNames, so the XPath parser knows what to do.
> http://www.netconfcentral.org/modules/yuma-ncx/= 2013-05-25#qname.631

Again I agree. =A0You have this extension, and we do something similar.
The idea is to have a standard way of handling this instead of each
vendor inventing something own. =A0(Also, as Lada pointed out, both of
us formally violate the spec with these extensions).
<= br>

This is needed to encode XML correctly in a re= trieval reply,
not just for XPath. =A0If the string node content = has an XML prefix then
there has to be an xmlns attribute to map it to a namespace
= or the client will not be able to determine the extended name.
If we have to bump the YANG version number and create YANG2,
then a whole lot of little details and wish-list items should
be on the table. =A0I don't know if starting on YANG 2.0
wo= uld discourage people from using YANG 1.0, or if YANG 2.0
should = be a high priority right now.


=A0

/martin

Andy<= /div>

--047d7bdc1a804cf29d04e8ccb92b-- From mbj@tail-f.com Tue Oct 15 12:39:37 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7A911E8186 for ; Tue, 15 Oct 2013 12:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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+4HCaer0zEt for ; Tue, 15 Oct 2013 12:39:30 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1588B11E8156 for ; Tue, 15 Oct 2013 12:39:30 -0700 (PDT) Received: from localhost (unknown [193.12.34.23]) by mail.tail-f.com (Postfix) with ESMTPSA id 6128012002EC; Tue, 15 Oct 2013 21:39:29 +0200 (CEST) Date: Tue, 15 Oct 2013 21:39:28 +0200 (CEST) Message-Id: <20131015.213928.502252543.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20131015073455.GC24295@elstar.local> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 19:39:38 -0000 Andy Bierman wrote: > Hi, > > > > a) Use the flat IANA registry and be done, even though it is not very > > flexible. > > > > b) Stall the document until a suitable collection of XPATH functions > > has been defined. > > > > c) Move to an identity based type hierarchy with an understanding that > > this requires to define XPATH functions to be really useful. > > > > Personally, I believe for configuration, you likely want an interface > > type hierarchy if you were to design a product yourself. Getting this > > hierarchy defined/standardized properly, however, will not be trivial. > > If this is done carelessly, we will end up with a mess over the years. > > > > > IMO (b) is a strawman since adding new XPath functions for YANG > and/or :xpath filtering would require a new YANG language version. > > I will remove my objection and support (c). I support (c) as well. Should we create identities for all types in the 'ifType defintions' registry; i.e., simply keep the iana-if-type YANG module, but with 272 identities instead of 272 enums? Or should we somehow try to use a "cleaned up" registry? /martin From lhotka@nic.cz Tue Oct 15 23:02:25 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3CB11E80FC for ; Tue, 15 Oct 2013 23:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.752 X-Spam-Level: X-Spam-Status: No, score=-1.752 tagged_above=-999 required=5 tests=[AWL=0.247, 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 JEkHNe38Tla7 for ; Tue, 15 Oct 2013 23:02:24 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 4427021F9E6B for ; Tue, 15 Oct 2013 23:02:24 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 2AE5913F6A6; Wed, 16 Oct 2013 08:02:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1381903336; bh=3No28YV7nVeP/McAe/0yxKEngHAyoBI+e2z8H+SIDNs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=cfQBAyfjOP0coO4UvQM0zBKrM9l+IjMDhxDIMAAMGNOOAwRvFIVlfpLeDqs14FBxj nhSTC6LYeLoUmk1hq9bQA0+EXIn1SrxAzmFJUR0FVGdDsdnD9o0V+ehxA2A3hh+kxm /A5K4RBsZyQeSwNdWxdLeQvCvO05am3JKdckTqR4= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ladislav Lhotka In-Reply-To: <20131015.213928.502252543.mbj@tail-f.com> Date: Wed, 16 Oct 2013 08:02:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9B753F22-FC5B-4DFD-B7E4-D1331E6733AF@nic.cz> References: <20131015073455.GC24295@elstar.local> <20131015.213928.502252543.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1510) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 06:02:25 -0000 On Oct 15, 2013, at 9:39 PM, Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >>=20 >>=20 >>> a) Use the flat IANA registry and be done, even though it is not = very >>> flexible. >>>=20 >>> b) Stall the document until a suitable collection of XPATH functions >>> has been defined. >>>=20 >>> c) Move to an identity based type hierarchy with an understanding = that >>> this requires to define XPATH functions to be really useful. >>>=20 >>> Personally, I believe for configuration, you likely want an = interface >>> type hierarchy if you were to design a product yourself. Getting = this >>> hierarchy defined/standardized properly, however, will not be = trivial. >>> If this is done carelessly, we will end up with a mess over the = years. >>>=20 >>>=20 >> IMO (b) is a strawman since adding new XPath functions for YANG >> and/or :xpath filtering would require a new YANG language version. >>=20 >> I will remove my objection and support (c). >=20 > I support (c) as well. Me too. >=20 > Should we create identities for all types in the 'ifType defintions' > registry; i.e., simply keep the iana-if-type YANG module, but with 272 > identities instead of 272 enums? Or should we somehow try to use a > "cleaned up" registry? I think the identity tree should be built incrementally. That is, each = module will define identities for the interfaces it deals with. We also = needn't harass IANA with it, it is sufficient that they register YANG = modules. I guess we should then do the same with address families, too. I2RS = folks will be delighted. Lada >=20 >=20 > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From rkrejci@cesnet.cz Wed Oct 16 01:55:16 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A039C11E825F for ; Wed, 16 Oct 2013 01:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3] 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 vdwQztNZ3lvU for ; Wed, 16 Oct 2013 01:55:00 -0700 (PDT) Received: from relay2.muni.cz (relay2.muni.cz [147.251.4.34]) by ietfa.amsl.com (Postfix) with ESMTP id C38DF11E8167 for ; Wed, 16 Oct 2013 01:54:58 -0700 (PDT) Received: from anxur.fi.muni.cz (anxur.fi.muni.cz [147.251.48.3]) by relay2.muni.cz (8.14.3/8.14.3/Debian-9.4) with ESMTP id r9G8sttZ023588; Wed, 16 Oct 2013 10:54:56 +0200 Received: from sheldon.liberouter.org (pc12.liberouter.org [147.251.21.221]) by anxur.fi.muni.cz (Postfix) with ESMTPSA id 8CDB3618C3; Wed, 16 Oct 2013 10:54:55 +0200 (CEST) Message-ID: <525E545E.5040307@cesnet.cz> Date: Wed, 16 Oct 2013 10:54:54 +0200 From: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= Organization: CESNET, z.s.p.o. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Martin Bjorklund , netmod@ietf.org References: <20131015.125134.1167345424645234375.mbj@tail-f.com> In-Reply-To: <20131015.125134.1167345424645234375.mbj@tail-f.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.7 (relay2.muni.cz [147.251.4.35]); Wed, 16 Oct 2013 10:54:57 +0200 (CEST) X-Virus-Scanned: clamav-milter 0.97.8 at relay2.muni.cz X-Virus-Status: Clean Subject: Re: [netmod] open issue draft-ietf-netmod-ip-cfg-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 08:55:16 -0000 Hi, I prefer B) to unify place where the neighbors config/state data can be found. Radek Dne 15.10.2013 12:51, Martin Bjorklund napsal(a): > Hi, > > There is one open issue left in the ip-cfg document. > > Currently, neighbors are configured per interface, but the neighbor > operational state is global: > > Config: /interfaces/interface[name]/ipvX/neighbor[ip] > > Oper: /ip-state/ipvX/neigbor[interface ip] > > It was suggested that we harmonize this, so that the neighbor > operational state is also per interface: > > New oper: /interfaces-state/interface[name]/ipvX/neighbor[ip] > > The other ip-related state is already per interface. > > Note that the data available is exactly the same. > > > So we have two alternatives: > > A) Keep current design > > B) Move neighbor operational state to the interface state > > > In the previous thread, Lada preferres A, and Jeff and myself B. > What do other people think? > > > /martin > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From mbj@tail-f.com Wed Oct 16 02:09:11 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1426411E8158 for ; Wed, 16 Oct 2013 02:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 2Uei6oIGfNQI for ; Wed, 16 Oct 2013 02:09:04 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 728C411E8104 for ; Wed, 16 Oct 2013 02:09:00 -0700 (PDT) Received: from localhost (unknown [193.12.34.23]) by mail.tail-f.com (Postfix) with ESMTPSA id 3C00F12002EC; Wed, 16 Oct 2013 11:08:59 +0200 (CEST) Date: Wed, 16 Oct 2013 11:08:58 +0200 (CEST) Message-Id: <20131016.110858.389674426.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <9B753F22-FC5B-4DFD-B7E4-D1331E6733AF@nic.cz> References: <20131015.213928.502252543.mbj@tail-f.com> <9B753F22-FC5B-4DFD-B7E4-D1331E6733AF@nic.cz> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 09:09:12 -0000 Ladislav Lhotka wrote: > > On Oct 15, 2013, at 9:39 PM, Martin Bjorklund wrote: > > > Should we create identities for all types in the 'ifType defintions' > > registry; i.e., simply keep the iana-if-type YANG module, but with 272 > > identities instead of 272 enums? Or should we somehow try to use a > > "cleaned up" registry? > > I think the identity tree should be built incrementally. That is, each module > will define identities for the interfaces it deals with. We also needn't harass > IANA with it, it is sufficient that they register YANG modules. The problem is that if we do this, there are no standard types from the start. This means that vendors will _have_ to use proprietary identities, even if they don't want to. Or we try to pick some "useful" types, but we'll probably get it wrong... /martin From lhotka@nic.cz Wed Oct 16 02:31:24 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5685C11E8174 for ; Wed, 16 Oct 2013 02:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.756 X-Spam-Level: X-Spam-Status: No, score=-1.756 tagged_above=-999 required=5 tests=[AWL=0.243, 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 Y78dCzb7eh9V for ; Wed, 16 Oct 2013 02:31:23 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 4048511E8169 for ; Wed, 16 Oct 2013 02:31:13 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 25A5D1400D3; Wed, 16 Oct 2013 11:31:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1381915873; bh=Xpuk+JSaZ4loyuY6EY9guEgJm7yaqSpkQJI0Hb3LTsU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=hxhHibn3cnz/PJlirdajwxuJjn1Y4iMeb/K03Sz4RWr17P3NuIEyT2imCLeAPOT5l p2untKFacMScnym82c6PCyNHyoxaP/mXRL7ola5JRfFuSR4GpBgxAddpsRhafRzVfI iFUwJ05iPguJp6ZGng9Oh6/NcBe53g5XrwyED3iA= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ladislav Lhotka In-Reply-To: <20131016.110858.389674426.mbj@tail-f.com> Date: Wed, 16 Oct 2013 11:31:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4B1557B1-1382-4A5A-ADEA-41EE541D75BE@nic.cz> References: <20131015.213928.502252543.mbj@tail-f.com> <9B753F22-FC5B-4DFD-B7E4-D1331E6733AF@nic.cz> <20131016.110858.389674426.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1510) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 09:31:24 -0000 On Oct 16, 2013, at 11:08 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>=20 >> On Oct 15, 2013, at 9:39 PM, Martin Bjorklund wrote: >>=20 >>> Should we create identities for all types in the 'ifType defintions' >>> registry; i.e., simply keep the iana-if-type YANG module, but with = 272 >>> identities instead of 272 enums? Or should we somehow try to use a >>> "cleaned up" registry? >>=20 >> I think the identity tree should be built incrementally. That is, = each module >> will define identities for the interfaces it deals with. We also = needn't harass >> IANA with it, it is sufficient that they register YANG modules. >=20 > The problem is that if we do this, there are no standard types from > the start. This means that vendors will _have_ to use proprietary > identities, even if they don't want to. IMO, this is in fact no problem: if an identity is not standardized, it = means that a standard data model for that interface type doesn't exist = yet, so the vendor will have to define a proprietary data model anyway. In my view, an identity is just a tag that enables certain objects to be = conditionally included in the data model. And identity derivation = potentially allows to do it not only for the exact interface type but = also for all types derived from it. Lada=20 >=20 > Or we try to pick some "useful" types, but we'll probably get it > wrong... >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From internet-drafts@ietf.org Fri Oct 18 04:12:19 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B77E211E81F4; Fri, 18 Oct 2013 04:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.031, 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 TKqusZbvrNfV; Fri, 18 Oct 2013 04:12:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B4C11E81B1; Fri, 18 Oct 2013 04:12:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131018111219.2277.31466.idtracker@ietfa.amsl.com> Date: Fri, 18 Oct 2013 04:12:19 -0700 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-11.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 11:12:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Working Gr= oup of the IETF. Title : A YANG Data Model for Routing Management Author(s) : Ladislav Lhotka Filename : draft-ietf-netmod-routing-cfg-11.txt Pages : 93 Date : 2013-10-18 Abstract: This document contains a specification of three YANG modules. Together they form the core routing data model which serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for individual routing protocols and other related functions. The core routing data model provides common building blocks for such extensions - routing instances, routes, routing information bases (RIB), routing protocols and route filters. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-routing-cfg-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From lhotka@nic.cz Fri Oct 18 04:37:55 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82A4921F9E6D for ; Fri, 18 Oct 2013 04:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=0.211, 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 w-RvXfcCJbl4 for ; Fri, 18 Oct 2013 04:37:54 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id B970121F9DF1 for ; Fri, 18 Oct 2013 04:37:54 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 770BD1411A8 for ; Fri, 18 Oct 2013 13:37:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1382096273; bh=/AEOdEVwCkI5coQm5wBn6ZEUHx0LgZt4Sc1bVVzpFuk=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: References:To:Message-Id:Mime-Version; b=Tt+s7jn1cQmbwUOhlLrVHWIGvf9ES+AqsAEy8uAihlr8I6wTC1peP/2nHEu1HlWuN S+0w3pstkCFZPbbvmuHFlxoBauZj2y7v9GKk7dc0OJdoBKfq8myX0P6OirWqOkXAHU zPg0dWTZwRJsa9nJoFoXM4cWNHdmIVYHX9rHtZhA= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Oct 2013 13:37:46 +0200 References: <20131018111219.2277.31466.idtracker@ietfa.amsl.com> To: netmod@ietf.org Message-Id: <270C5069-D3A5-4484-972D-F88ECF6C6F4C@nic.cz> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Subject: [netmod] Fwd: I-D Action: draft-ietf-netmod-routing-cfg-11.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 11:37:55 -0000 Hi, this is a new revision of the routing draft. Most changes resulted from = discussions with the authors of the I2RS RIB info model draft. I hope = the current modules are suitable for building their data model on top of = them. A useful side-effect is an improved relationship between configuration = and state data versions of some lists (see sec. 4.1). Based on the recent consensus, I also migrated address family = information to identities. Lada =20 Begin forwarded message: > From: internet-drafts@ietf.org > Subject: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-11.txt > Date: October 18, 2013 1:12:19 PM GMT+02:00 > To: i-d-announce@ietf.org > Cc: netmod@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the NETCONF Data Modeling Language = Working Group of the IETF. >=20 > Title : A YANG Data Model for Routing Management > Author(s) : Ladislav Lhotka > Filename : draft-ietf-netmod-routing-cfg-11.txt > Pages : 93 > Date : 2013-10-18 >=20 > Abstract: > This document contains a specification of three YANG modules. > Together they form the core routing data model which serves as a > framework for configuring and managing a routing subsystem. It is > expected that these modules will be augmented by additional YANG > modules defining data models for individual routing protocols and > other related functions. The core routing data model provides = common > building blocks for such extensions - routing instances, routes, > routing information bases (RIB), routing protocols and route = filters. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-11 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-routing-cfg-11 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From internet-drafts@ietf.org Fri Oct 18 11:50:35 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F8D11E82E9; Fri, 18 Oct 2013 11:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.016, 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 wghgNznXglHB; Fri, 18 Oct 2013 11:50:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B97B411E8323; Fri, 18 Oct 2013 11:50:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131018185017.4087.33358.idtracker@ietfa.amsl.com> Date: Fri, 18 Oct 2013 11:50:17 -0700 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-11.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 18:50:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Working Gr= oup of the IETF. Title : A YANG Data Model for IP Management Author(s) : Martin Bjorklund Filename : draft-ietf-netmod-ip-cfg-11.txt Pages : 32 Date : 2013-10-18 Abstract: This document defines a YANG data model for management of IP implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-ip-cfg There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-ip-cfg-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mbj@tail-f.com Fri Oct 18 11:54:57 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA00311E8146 for ; Fri, 18 Oct 2013 11:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 1IR1cl8gAZuh for ; Fri, 18 Oct 2013 11:54:52 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id E4C2311E8116 for ; Fri, 18 Oct 2013 11:54:51 -0700 (PDT) Received: from localhost (unknown [193.12.34.23]) by mail.tail-f.com (Postfix) with ESMTPSA id 090B412000A8 for ; Fri, 18 Oct 2013 20:54:49 +0200 (CEST) Date: Fri, 18 Oct 2013 20:54:49 +0200 (CEST) Message-Id: <20131018.205449.401322121.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Fri_Oct_18_20_54_49_2013_722)--" Content-Transfer-Encoding: 7bit Subject: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-yang-xpath-extensions-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 18:54:57 -0000 ----Next_Part(Fri_Oct_18_20_54_49_2013_722)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I have posted a draft that introduces a YANG extension statement to define new XPath functions. It also defines a couple of XPath functions, for some built-in YANG types. Specifically, it solves the problem of comparing identities in must/when expressions. /martin ----Next_Part(Fri_Oct_18_20_54_49_2013_722)-- Content-Type: Message/Rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on dragon X-Spam-Level: X-Spam-Status: No, score=-99.6 required=5.0 tests=BAYES_00,RCVD_IN_RP_RNBL, RDNS_DYNAMIC,SPF_FAIL,USER_IN_WHITELIST autolearn=no version=3.3.1 X-Original-To: mbj@tail-f.com Delivered-To: mbj@tail-f.com Received: from mx.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id AAF8E12000A8 for ; Fri, 18 Oct 2013 20:52:04 +0200 (CEST) Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by mx.tail-f.com (Postfix) with ESMTP id 74963410C92 for ; Fri, 18 Oct 2013 20:52:04 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC27E11E8311 for ; Fri, 18 Oct 2013 11:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 Pgw+kjQlOX4g for ; Fri, 18 Oct 2013 11:52:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4372411E8146 for ; Fri, 18 Oct 2013 11:52:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: Martin Bjorklund Subject: New Version Notification for draft-bjorklund-netmod-yang-xpath-extensions-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131018185203.4069.15909.idtracker@ietfa.amsl.com> Date: Fri, 18 Oct 2013 11:52:03 -0700 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.1 int cnt prob spamicity histogram 0.00 55 0.019025 0.017332 ################################################ 0.10 6 0.112783 0.028329 ###### 0.20 0 0.000000 0.028329 0.30 0 0.000000 0.028329 0.40 0 0.000000 0.028329 0.50 0 0.000000 0.028329 0.60 0 0.000000 0.028329 0.70 0 0.000000 0.028329 0.80 0 0.000000 0.028329 0.90 0 0.000000 0.028329 A new version of I-D, draft-bjorklund-netmod-yang-xpath-extensions-00.txt has been successfully submitted by Martin Bjorklund and posted to the IETF repository. Filename: draft-bjorklund-netmod-yang-xpath-extensions Revision: 00 Title: YANG XPath Extensions Creation date: 2013-10-18 Group: Individual Submission Number of pages: 20 URL: http://www.ietf.org/internet-drafts/draft-bjorklund-netmod= -yang-xpath-extensions-00.txt Status: http://datatracker.ietf.org/doc/draft-bjorklund-netmod-yan= g-xpath-extensions Htmlized: http://tools.ietf.org/html/draft-bjorklund-netmod-yang-xpa= th-extensions-00 Abstract: This document introduces new YANG extension statements for defining XPath functions. These functions can be used in XPath expressions in YANG modules and in NETCONF XPath filters. A set of YANG-specific XPath functions are also defined. = = Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ----Next_Part(Fri_Oct_18_20_54_49_2013_722)---- From andy@yumaworks.com Fri Oct 18 16:37:16 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6871511E80E4 for ; Fri, 18 Oct 2013 16:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.826 X-Spam-Level: X-Spam-Status: No, score=-2.826 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 GBRyPRlgd-+y for ; Fri, 18 Oct 2013 16:37:12 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4BD11E80D9 for ; Fri, 18 Oct 2013 16:37:06 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id l13so3151931qcy.32 for ; Fri, 18 Oct 2013 16:37:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=h+VTx7R7vcHoCMqdTIH/0+ciDT4MQWfp0VsCz5V1SCI=; b=H+foNsTIVAK3FKR8y1z+VQmaXYKTxq4mNKuh4OJlperV5u6lNur6o/9awopaFsdY2D ipeBqtqZeyKTnbYKOccjBuuehdDvr7isQxZ329WC8HjEMQGVYN6NgwNoKleV45iE5ZNa 9v2+mYqbBwfguF/eTML+jDJHs26Y8Y0JgI3KzJp4rEN+4Bx+geg7ip7mwepHp/B+xitV xlN60SEjqauQ/laoSYN9XvrnmDh1NI7pLzfuts8Dmtd3p+7HdACg0cEAtn67JJPWGkZJ Q/f5EP5gFo2yFJLlBaxXv5yB2x7f/aPKKKAHnHCmQSrED0W7rpwa6GuLoKpNoN6MnR5S KGyg== X-Gm-Message-State: ALoCoQmCOzSKX9w5xA4ZLxtHaOyJ9EOePOLDjRk7ug9heKHOUhlqa4zgOlqB0Bv1AqTlPcmhwRMd MIME-Version: 1.0 X-Received: by 10.49.96.225 with SMTP id dv1mr7402303qeb.89.1382139425089; Fri, 18 Oct 2013 16:37:05 -0700 (PDT) Received: by 10.140.21.175 with HTTP; Fri, 18 Oct 2013 16:37:04 -0700 (PDT) In-Reply-To: <20131018.205449.401322121.mbj@tail-f.com> References: <20131018.205449.401322121.mbj@tail-f.com> Date: Fri, 18 Oct 2013 16:37:04 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=047d7bb0494676804404e90c69c8 Cc: "netmod@ietf.org" Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-yang-xpath-extensions-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 23:37:16 -0000 --047d7bb0494676804404e90c69c8 Content-Type: text/plain; charset=ISO-8859-1 Hi, I really like this draft. I think more powerful XPath would make writing must/when/select expressions less error-prone, and easier to read. I thought there was going to be more XPath functions defined. We have a couple: boolean module-supported(string) // module-name boolean feature-supported(string, string) // module-name, feature-name Andy On Fri, Oct 18, 2013 at 11:54 AM, Martin Bjorklund wrote: > Hi, > > I have posted a draft that introduces a YANG extension statement to > define new XPath functions. It also defines a couple of XPath > functions, for some built-in YANG types. Specifically, it solves the > problem of comparing identities in must/when expressions. > > > /martin > > > > ---------- Forwarded message ---------- > From: internet-drafts@ietf.org > To: Martin Bjorklund > Cc: > Date: Fri, 18 Oct 2013 11:52:03 -0700 > Subject: New Version Notification for > draft-bjorklund-netmod-yang-xpath-extensions-00.txt > > A new version of I-D, draft-bjorklund-netmod-yang-xpath-extensions-00.txt > has been successfully submitted by Martin Bjorklund and posted to the > IETF repository. > > Filename: draft-bjorklund-netmod-yang-xpath-extensions > Revision: 00 > Title: YANG XPath Extensions > Creation date: 2013-10-18 > Group: Individual Submission > Number of pages: 20 > URL: > http://www.ietf.org/internet-drafts/draft-bjorklund-netmod-yang-xpath-extensions-00.txt > Status: > http://datatracker.ietf.org/doc/draft-bjorklund-netmod-yang-xpath-extensions > Htmlized: > http://tools.ietf.org/html/draft-bjorklund-netmod-yang-xpath-extensions-00 > > > Abstract: > This document introduces new YANG extension statements for defining > XPath functions. These functions can be used in XPath expressions in > YANG modules and in NETCONF XPath filters. A set of YANG-specific > XPath functions are also defined. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --047d7bb0494676804404e90c69c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I really like this draft.
I think more powerful XPath would make writing
must/when/select = expressions less error-prone, and easier to read.

I thought there was going to be more XPath functions defined.
We = have a couple:

=A0 =A0boolean module-supported(str= ing) =A0// module-name

=A0 =A0boolean feature-supp= orted(string, string) // module-name, feature-name


Andy



On Fri, Oct 18, 2013 at= 11:54 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
Hi,

I have posted a draft that introduces a YANG extension statement to
define new XPath functions. =A0It also defines a couple of XPath
functions, for some built-in YANG types. =A0Specifically, it solves the
problem of comparing identities in must/when expressions.


/martin



---------- Forwarded message ----------
From:=A0internet-drafts@ietf.org
T= o:=A0Martin Bjorklund <mbj@tail-f.com<= /a>>
Cc:=A0
Date:=A0Fri, 18 Oct 2013 11:52:03 -0700
Subject:=A0New Version= Notification for draft-bjorklund-netmod-yang-xpath-extensions-00.txt
A new version of I-D, draft-bjorklund-netmod-yang-xpath-extensions-00.txt has been successfully submitted by Martin Bjorklund and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-bjorklund-netmod-yang-xpath-extensions
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 YANG XPath Extensions
Creation date: =A0 2013-10-18
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 20
URL: =A0 =A0 =A0 =A0 =A0 =A0 htt= p://www.ietf.org/internet-drafts/draft-bjorklund-netmod-yang-xpath-extensio= ns-00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatrack= er.ietf.org/doc/draft-bjorklund-netmod-yang-xpath-extensions
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.or= g/html/draft-bjorklund-netmod-yang-xpath-extensions-00


Abstract:
=A0 =A0This document introduces new YANG extension statements for defining<= br> =A0 =A0XPath functions. =A0These functions can be used in XPath expressions= in
=A0 =A0YANG modules and in NETCONF XPath filters. =A0A set of YANG-specific=
=A0 =A0XPath functions are also defined.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


_______________________________________________
netmod mailing list
netmod@ietf.org
= https://www.ietf.org/mailman/listinfo/netmod


--047d7bb0494676804404e90c69c8-- From jernej.tuljak@mg-soft.si Mon Oct 21 07:26:34 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A48AA11E85BF for ; Mon, 21 Oct 2013 07:26:34 -0700 (PDT) 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] 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 mntEOZkCg149 for ; Mon, 21 Oct 2013 07:26:29 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9F37311E85E5 for ; Mon, 21 Oct 2013 07:25:54 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id r9LEPn0R030350 for ; Mon, 21 Oct 2013 16:25:50 +0200 Message-ID: <5265396B.7060306@mg-soft.com> Date: Mon, 21 Oct 2013 16:25:47 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netmod] Single/double quote as an unquoted string X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 14:26:34 -0000 Section 6.1.3 Quoting, RFC6020, states the following: If a string contains any space or tab characters, a semicolon (";"), braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), then it MUST be enclosed within double or single quotes. Shouldn't this also include single quote (') and double quote (")? As it is now, this is allowed: default "; // or ' The thing is..how's a lexer supposed to differentiate between quoted and unquoted strings (for YANG concatenation) if this is allowed? Consider: default "; units "; Is this (A) a single default statement with an argument of ";\n units " or (B) are there two YANG keywords with a double quote as an argument? There's nothing that prohibits using a semicolon/newline/whitespace inside quoted strings, so the first case is perfectly valid. There's also nothing that prohibits an unquoted string with a value of a single or a double quote. So which one is it? Jernej From j.schoenwaelder@jacobs-university.de Mon Oct 21 07:41:15 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375F611E8602 for ; Mon, 21 Oct 2013 07:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.219 X-Spam-Level: X-Spam-Status: No, score=-103.219 tagged_above=-999 required=5 tests=[AWL=0.030, 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 a3VVS7IAlqUT for ; Mon, 21 Oct 2013 07:41:08 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3A46A11E860E for ; Mon, 21 Oct 2013 07:40:40 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3256720065; Mon, 21 Oct 2013 16:40:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Er8dkg8yt7t4; Mon, 21 Oct 2013 16:40:39 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BD3DD20064; Mon, 21 Oct 2013 16:40:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2FA3728F0E5D; Mon, 21 Oct 2013 16:40:32 +0200 (CEST) Date: Mon, 21 Oct 2013 16:40:32 +0200 From: Juergen Schoenwaelder To: Jernej Tuljak Message-ID: <20131021144031.GC50360@elstar.local> Mail-Followup-To: Jernej Tuljak , NETMOD Working Group References: <5265396B.7060306@mg-soft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5265396B.7060306@mg-soft.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: NETMOD Working Group Subject: Re: [netmod] Single/double quote as an unquoted string X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 14:41:15 -0000 On Mon, Oct 21, 2013 at 04:25:47PM +0200, Jernej Tuljak wrote: > Section 6.1.3 Quoting, RFC6020, states the following: > > If a string contains any space or tab characters, a semicolon (";"), > braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), then > it MUST be enclosed within double or single quotes. > > Shouldn't this also include single quote (') and double quote (")? > As it is now, this is allowed: > > default "; // or ' > > The thing is..how's a lexer supposed to differentiate between quoted > and unquoted strings (for YANG concatenation) if this is allowed? > Consider: > > default "; > units "; > > Is this (A) a single default statement with an argument of ";\n > units " or (B) are there two YANG keywords with a double quote as an > argument? There's nothing that prohibits using a > semicolon/newline/whitespace inside quoted strings, so the first > case is perfectly valid. There's also nothing that prohibits an > unquoted string with a value of a single or a double quote. So which > one is it? A double quote always starts or ends a quoted strings unless it is prefixed with a backslash or it is enclosed in a single quoted string. /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 Mon Oct 21 07:47:41 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9802F11E85F8 for ; Mon, 21 Oct 2013 07:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.843 X-Spam-Level: X-Spam-Status: No, score=-2.843 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 5p+DE33Ye1MV for ; Mon, 21 Oct 2013 07:47:29 -0700 (PDT) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 271FF11E8612 for ; Mon, 21 Oct 2013 07:47:27 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id k18so2352341qcv.10 for ; Mon, 21 Oct 2013 07:47:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HHSUPyskB+6HGgYIKvW6AZZYE2P5P+TcRPw5ryaorzo=; b=WeBcmU0Flkz0at/B01Sf3aJhJ1LsylIWvkzjVmyu/h8+U86lufKLNNpaReYksWUaAB zJKQm3N9fzLiC5PqmXvqXk/F76qHT9J0POgvb7OYv6Z9o7h4r+1wSf49b13MEAUKs8Ug VqGjY98LUGrR5d650zkjv4YUfBpyZDPLLbMPf5rKznvnkdVPJoA2YMeGUXIZ9US5EhjM Kv0YgQRlr7R4GQAKeo8WaemZgq/umGzZ0DWIgEl2b461jsuK0LfW5+Il9pF75ai4TwxT MfbBCVAKmScfxA+cgunQqwTPjKbOXnMErAY02kLyqlO0w7PKHLDYZuYHssw3lrdVAZXk /mBA== X-Gm-Message-State: ALoCoQlsmJoVRIJlv8GShaF90rt7mgV+NGpPJO9edvEeOSClwxwgJPmUfX+qC68tTqNGtumWbJTV MIME-Version: 1.0 X-Received: by 10.224.111.195 with SMTP id t3mr23438513qap.49.1382366846536; Mon, 21 Oct 2013 07:47:26 -0700 (PDT) Received: by 10.140.21.175 with HTTP; Mon, 21 Oct 2013 07:47:26 -0700 (PDT) In-Reply-To: <5265396B.7060306@mg-soft.com> References: <5265396B.7060306@mg-soft.com> Date: Mon, 21 Oct 2013 07:47:26 -0700 Message-ID: From: Andy Bierman To: Jernej Tuljak Content-Type: multipart/alternative; boundary=047d7b60457ed65fc904e9415c1b Cc: NETMOD Working Group Subject: Re: [netmod] Single/double quote as an unquoted string X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 14:47:41 -0000 --047d7b60457ed65fc904e9415c1b Content-Type: text/plain; charset=ISO-8859-1 Hi, sec. 6.1.3 is not precise enough. Quoted strings must end end the char that started the string. Double quoted strings are also treated special wrt/ formatting and special chars within the string. The RFC is not clear about reformatting combined strings: "\n foo" + '\nbar' + "\n baz". Is it A, B, or C? A) foo bar baz B) foo bar baz C) foo\nbar baz Implementing string concatenation with mixed strings is also problematic. The result can contain chars that are not allowed in either quoting format so rendering the combined strings with quotes is not possible. On Mon, Oct 21, 2013 at 7:25 AM, Jernej Tuljak wrote: > Section 6.1.3 Quoting, RFC6020, states the following: > > If a string contains any space or tab characters, a semicolon (";"), > braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), then > it MUST be enclosed within double or single quotes. > > Shouldn't this also include single quote (') and double quote (")? As it > is now, this is allowed: > > default "; // or ' > > A double quote has to end the string. The RFC should make this clear. > The thing is..how's a lexer supposed to differentiate between quoted and > unquoted strings (for YANG concatenation) if this is allowed? Consider: > > default "; > units "; > Is this (A) a single default statement with an argument of ";\n units " or > (B) are there two YANG keywords with a double quote as an argument? There's > nothing that prohibits using a semicolon/newline/whitespace inside quoted > strings, so the first case is perfectly valid. There's also nothing that > prohibits an unquoted string with a value of a single or a double quote. So > which one is it? > This is just 1 default-stmt (if both quotes are double-quotes). > > Jernej > Andy --047d7b60457ed65fc904e9415c1b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

sec. 6.1.3 is not precise enough.
Quoted strings must end end the char that started the string.
Double quoted strings are also treated special wrt/ formatting
and special chars within the string. The RFC is not clear about
<= div>reformatting combined strings:=A0

=A0 "\n= =A0 =A0foo" + '\nbar' =A0+ "\n =A0 baz".
=
Is it A, B, or C?

A)

=A0 =A0foo
bar
=A0 =A0baz

B)<= /div>

=A0 =A0foo
=A0 =A0bar
=A0 =A0b= az

C)

=A0 =A0foo\nbar
=A0 =A0baz=


Implementing string concatenation = with mixed strings is also problematic.
The result can contain ch= ars that are not allowed in either quoting
format so rendering the combined strings with quotes is not possible.<= /div>


On Mon, Oct 21, 2013 at 7:25 AM, Jernej Tuljak <jernej.tuljak@mg= -soft.si> wrote:
Section 6.1.3 Quoting, RFC6020, states the f= ollowing:

=A0 =A0If a string contains any space or tab characters, a semicolon ("= ;;"),
=A0 =A0braces ("{" or "}"), or comment sequences ("= ;//", "/*", or "*/"), then
=A0 =A0it MUST be enclosed within double or single quotes.

Shouldn't this also include single quote (') and double quote (&quo= t;)? As it is now, this is allowed:

=A0 =A0default "; // or '


A double quote has to end the string.<= /div>
The RFC should make this clear.
=A0
The thing is..how's a lexer supposed to differentiate between quoted an= d unquoted strings (for YANG concatenation) if this is allowed? Consider:
=A0 =A0default ";
=A0 =A0units ";
Is this (A) a single default statement with an argument of ";\n units = " or (B) are there two YANG keywords with a double quote as an argumen= t? There's nothing that prohibits using a semicolon/newline/whitespace = inside quoted strings, so the first case is perfectly valid. There's al= so nothing that prohibits an unquoted string with a value of a single or a = double quote. So which one is it?

This is just 1 default-stmt (if both quote= s are double-quotes).
=A0

Jernej

Andy
=A0
--047d7b60457ed65fc904e9415c1b-- From jernej.tuljak@gmail.com Mon Oct 21 07:51:53 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C09FF11E8535 for ; Mon, 21 Oct 2013 07:51:53 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxbEgljGZuJ0 for ; Mon, 21 Oct 2013 07:51:52 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 7C83711E85BE for ; Mon, 21 Oct 2013 07:51:49 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id g10so6798467pdj.20 for ; Mon, 21 Oct 2013 07:51:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ux2ct8tpIapLd9JyU1/yhc5vZxOY1lMnogX2D4fMrrQ=; b=XsOi9Xqy25CeDo0TXHU9h1Mmj90Dfo/btUIziO0/QR7DJ0eM+5krnxVXRK6gH/8EAb 6gIf2dYhk6JPL3xoy37lV10Cz6nhmilPZbfa9iCToRnVREGRPLMRpnqaW2tFoYmzr7df QTer8P8WSy/DUK/9Tuh2DBHzxIjLgU1gpvsZ2G51MYzZ8ROpByxbYPoEHe8dQxSxgAJz HgH2imFo8qoT86hQeJ+MDrDBEkTAsnQb1KfmEq78tVeGUll8jF/13NzYhNOCfANtvtow uLJore7/bPFi1t2MNUjczXArPsw1xitp7KU/zvNGtaHQ/NpX2TdGEXd7XzLPv3fbJaxB FNqQ== MIME-Version: 1.0 X-Received: by 10.68.109.195 with SMTP id hu3mr7183023pbb.123.1382367109225; Mon, 21 Oct 2013 07:51:49 -0700 (PDT) Received: by 10.70.103.44 with HTTP; Mon, 21 Oct 2013 07:51:49 -0700 (PDT) Received: by 10.70.103.44 with HTTP; Mon, 21 Oct 2013 07:51:49 -0700 (PDT) In-Reply-To: References: <5265396B.7060306@mg-soft.com> Date: Mon, 21 Oct 2013 16:51:49 +0200 Message-ID: From: Jernej Tuljak To: Andy Bierman Content-Type: multipart/alternative; boundary=047d7b86f3567ea6bf04e9416c50 Cc: netmod@ietf.org Subject: Re: [netmod] Single/double quote as an unquoted string X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 14:51:53 -0000 --047d7b86f3567ea6bf04e9416c50 Content-Type: text/plain; charset=ISO-8859-1 It's C. Single quotes preserve all characters. Jernej Dne 21. okt. 2013 16:47 je oseba "Andy Bierman" napisala: > Hi, > > sec. 6.1.3 is not precise enough. > Quoted strings must end end the char that started the string. > Double quoted strings are also treated special wrt/ formatting > and special chars within the string. The RFC is not clear about > reformatting combined strings: > > "\n foo" + '\nbar' + "\n baz". > > Is it A, B, or C? > > A) > > foo > bar > baz > > B) > > foo > bar > baz > > C) > > foo\nbar > baz > > > Implementing string concatenation with mixed strings is also problematic. > The result can contain chars that are not allowed in either quoting > format so rendering the combined strings with quotes is not possible. > > > On Mon, Oct 21, 2013 at 7:25 AM, Jernej Tuljak wrote: > >> Section 6.1.3 Quoting, RFC6020, states the following: >> >> If a string contains any space or tab characters, a semicolon (";"), >> braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), then >> it MUST be enclosed within double or single quotes. >> >> Shouldn't this also include single quote (') and double quote (")? As it >> is now, this is allowed: >> >> default "; // or ' >> >> > A double quote has to end the string. > The RFC should make this clear. > > >> The thing is..how's a lexer supposed to differentiate between quoted and >> unquoted strings (for YANG concatenation) if this is allowed? Consider: >> >> default "; >> units "; >> > Is this (A) a single default statement with an argument of ";\n units " or >> (B) are there two YANG keywords with a double quote as an argument? There's >> nothing that prohibits using a semicolon/newline/whitespace inside quoted >> strings, so the first case is perfectly valid. There's also nothing that >> prohibits an unquoted string with a value of a single or a double quote. So >> which one is it? >> > > This is just 1 default-stmt (if both quotes are double-quotes). > > >> >> Jernej >> > > Andy > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --047d7b86f3567ea6bf04e9416c50 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

It's C. Single quotes preserve all characters.

Jernej

Dne 21. okt. 2013 16:47 je oseba "Andy Bier= man" <andy@yumaworks.com&= gt; napisala:
Hi,

sec. 6.1.3 is not precise enough.
Quoted strings must end end the char that started the string.
Double quoted strings are also treated special wrt/ formatting
and special chars within the string. The RFC is not clear about
<= div>reformatting combined strings:=A0

=A0 "\n= =A0 =A0foo" + '\nbar' =A0+ "\n =A0 baz".
=
Is it A, B, or C?

A)

=A0 =A0foo
bar
=A0 =A0baz

B)<= /div>

=A0 =A0foo
=A0 =A0bar
=A0 =A0b= az

C)

=A0 =A0foo\nbar
=A0 =A0baz=


Implementing string concatenation = with mixed strings is also problematic.
The result can contain ch= ars that are not allowed in either quoting
format so rendering the combined strings with quotes is not possible.<= /div>


On Mon, Oct 21, 2013 at 7:25 AM, Jernej Tuljak <jernej.tuljak@mg= -soft.si> wrote:
Section 6.1.3 Quoting, RFC6020, states the f= ollowing:

=A0 =A0If a string contains any space or tab characters, a semicolon ("= ;;"),
=A0 =A0braces ("{" or "}"), or comment sequences ("= ;//", "/*", or "*/"), then
=A0 =A0it MUST be enclosed within double or single quotes.

Shouldn't this also include single quote (') and double quote (&quo= t;)? As it is now, this is allowed:

=A0 =A0default "; // or '


A double quote has to end the string.<= /div>
The RFC should make this clear.
=A0
The thing is..how's a lexer supposed to differentiate between quoted an= d unquoted strings (for YANG concatenation) if this is allowed? Consider:
=A0 =A0default ";
=A0 =A0units ";
Is this (A) a single default statement with an argument of ";\n units = " or (B) are there two YANG keywords with a double quote as an argumen= t? There's nothing that prohibits using a semicolon/newline/whitespace = inside quoted strings, so the first case is perfectly valid. There's al= so nothing that prohibits an unquoted string with a value of a single or a = double quote. So which one is it?

This is just 1 default-stmt (if both quote= s are double-quotes).
=A0

Jernej

Andy
=A0

_______________________________________________
netmod mailing list
netmod@ietf.org
= https://www.ietf.org/mailman/listinfo/netmod

--047d7b86f3567ea6bf04e9416c50-- From andy@yumaworks.com Mon Oct 21 07:54:56 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 702A311E81D2 for ; Mon, 21 Oct 2013 07:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.846 X-Spam-Level: X-Spam-Status: No, score=-2.846 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 bnGdgihzc-Js for ; Mon, 21 Oct 2013 07:54:50 -0700 (PDT) Received: from mail-qe0-f54.google.com (mail-qe0-f54.google.com [209.85.128.54]) by ietfa.amsl.com (Postfix) with ESMTP id C9F6F11E8625 for ; Mon, 21 Oct 2013 07:54:46 -0700 (PDT) Received: by mail-qe0-f54.google.com with SMTP id 1so3899083qec.27 for ; Mon, 21 Oct 2013 07:54:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PjyXUFchO/z2dWyVjH4aAx0i9JIfqayJnwOu4mphBck=; b=KKOe8WMLT4VOguw+kZClnx2+B0Ive9kJ3uT/Ah6tQVSkkCk/aKdH19nR/4JluQ7+j4 joa4/OyFgV/TTxlw1YVq/V9YJoOobReRvMyFuETmv6OgjnTj8ZYN5Hcj1djF73YOqn13 cu5hQUjs+LUpQe9/o+JMW/m8OHAvPbECXVlBkdd2S0YpOCg4m6a1KbIwwbm/Mc9bA7hP fsePyPGYfdqhLAhTZ1uSextxmmzUD00hdgi8kyHge8uPbcrhiFWaj0AhsWhKdiV2k+XX +qkeyL8K2Dz2eXkgUpgtL5urw4hFb5d706GvGKJhGymjGkEMXYl6anBo5+ZxP7XIGzJL xAbw== X-Gm-Message-State: ALoCoQnedFFEUOin9pzvAD7lAQB6ILlVSX5iMOpZAhJtNmodM5anj6APqpXsQmoX2NgJP0eF+2q8 MIME-Version: 1.0 X-Received: by 10.224.169.8 with SMTP id w8mr2658230qay.96.1382367285620; Mon, 21 Oct 2013 07:54:45 -0700 (PDT) Received: by 10.140.21.175 with HTTP; Mon, 21 Oct 2013 07:54:45 -0700 (PDT) In-Reply-To: References: <5265396B.7060306@mg-soft.com> Date: Mon, 21 Oct 2013 07:54:45 -0700 Message-ID: From: Andy Bierman To: Jernej Tuljak Content-Type: multipart/alternative; boundary=089e01494f4802483c04e94177aa Cc: NETMOD Working Group Subject: Re: [netmod] Single/double quote as an unquoted string X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 14:54:56 -0000 --089e01494f4802483c04e94177aa Content-Type: text/plain; charset=ISO-8859-1 Hi, ... default "; // or ' >> > It should be clear from the RFC that a comment within a quoted string is not treated at a comment at all. The quoted string starts a token. Everything up to the closing quote is part of that 1 token. > Jernej >> > > Andy --089e01494f4802483c04e94177aa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

...

=A0 =A0default "; // or '


It should be clear from the RFC t= hat a comment within a quoted string
is not treated at a comment = at all. The quoted string starts a token.
Everything up to the closing quote is part of that 1 token.
=
=A0
Jernej


<= div class=3D"gmail_extra">
Andy
<= br>
--089e01494f4802483c04e94177aa-- From andy@yumaworks.com Mon Oct 21 07:56:56 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDC8611E85B4 for ; Mon, 21 Oct 2013 07:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 ISMF2lpbWg8g for ; Mon, 21 Oct 2013 07:56:39 -0700 (PDT) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) by ietfa.amsl.com (Postfix) with ESMTP id AC35011E81CF for ; Mon, 21 Oct 2013 07:56:31 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id w4so3860534qcr.26 for ; Mon, 21 Oct 2013 07:56:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ktRaT3c6mggM3rJmfkgc8J8OIiD1ALgYVVyTjIddKpI=; b=SKbZYwz5yQVhgXtPwZMOPXt8KvcIM6rcC3/nQbPWNtTcHOe7eo2T3M7ovI0y01Shx/ 7f9roWWwMHsXDOentclCvvdIbh8/Ytsg1eUmfyp9XUFmvd/c3UR8X7JL3ZiwwqKVg0+v TbUXRAP39vO0s6doaYgZvH3GbbUOePf/MiXBtE6Nhk3m4o4n0zy98SmtM4dNkkBQ4FlG VjHu6CgVrL4HQVK9JJ7QjjvlIBPUj/Mu5kUkolfS+Mmng0gdLMh30ZQLsS9494v8/fS2 aQgjmFTT1eWeE85PdmPdTHYAYcq31mxbwvqB3fhTL3WWwR1uEAX5g1U5xDE0O8g8agMr Y+4g== X-Gm-Message-State: ALoCoQk5LOBjCedHaEiuqc25MDAwbd9m80m1H61OIw/K3R0Hg5ilyva1SNX2i9NhWID7//zWI9jt MIME-Version: 1.0 X-Received: by 10.224.169.8 with SMTP id w8mr2669128qay.96.1382367390934; Mon, 21 Oct 2013 07:56:30 -0700 (PDT) Received: by 10.140.21.175 with HTTP; Mon, 21 Oct 2013 07:56:30 -0700 (PDT) In-Reply-To: References: <5265396B.7060306@mg-soft.com> Date: Mon, 21 Oct 2013 07:56:30 -0700 Message-ID: From: Andy Bierman To: Jernej Tuljak Content-Type: multipart/alternative; boundary=089e01494f4849305404e9417d86 Cc: "netmod@ietf.org" Subject: Re: [netmod] Single/double quote as an unquoted string X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 14:56:56 -0000 --089e01494f4849305404e9417d86 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 21, 2013 at 7:51 AM, Jernej Tuljak wrote: > It's C. Single quotes preserve all characters. > I agree. > Jernej > Andy > Dne 21. okt. 2013 16:47 je oseba "Andy Bierman" > napisala: > >> Hi, >> >> sec. 6.1.3 is not precise enough. >> Quoted strings must end end the char that started the string. >> Double quoted strings are also treated special wrt/ formatting >> and special chars within the string. The RFC is not clear about >> reformatting combined strings: >> >> "\n foo" + '\nbar' + "\n baz". >> >> Is it A, B, or C? >> >> A) >> >> foo >> bar >> baz >> >> B) >> >> foo >> bar >> baz >> >> C) >> >> foo\nbar >> baz >> >> >> Implementing string concatenation with mixed strings is also problematic. >> The result can contain chars that are not allowed in either quoting >> format so rendering the combined strings with quotes is not possible. >> >> >> On Mon, Oct 21, 2013 at 7:25 AM, Jernej Tuljak wrote: >> >>> Section 6.1.3 Quoting, RFC6020, states the following: >>> >>> If a string contains any space or tab characters, a semicolon (";"), >>> braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), then >>> it MUST be enclosed within double or single quotes. >>> >>> Shouldn't this also include single quote (') and double quote (")? As it >>> is now, this is allowed: >>> >>> default "; // or ' >>> >>> >> A double quote has to end the string. >> The RFC should make this clear. >> >> >>> The thing is..how's a lexer supposed to differentiate between quoted and >>> unquoted strings (for YANG concatenation) if this is allowed? Consider: >>> >>> default "; >>> units "; >>> >> Is this (A) a single default statement with an argument of ";\n units " >>> or (B) are there two YANG keywords with a double quote as an argument? >>> There's nothing that prohibits using a semicolon/newline/whitespace inside >>> quoted strings, so the first case is perfectly valid. There's also nothing >>> that prohibits an unquoted string with a value of a single or a double >>> quote. So which one is it? >>> >> >> This is just 1 default-stmt (if both quotes are double-quotes). >> >> >>> >>> Jernej >>> >> >> Andy >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> --089e01494f4849305404e9417d86 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Oct 21, 2013 at 7:51 AM, Jernej Tuljak &l= t;jernej.tulja= k@gmail.com> wrote:

It's C. Single quotes pre= serve all characters.



I = agree.
=A0

Jernej


Andy
=A0

Dne 21. okt. 2013 16:47 je oseba "Andy Bier= man" <andy@= yumaworks.com> napisala:
Hi,

sec. 6.1.3 is not precise enough.
Quoted strings must end end the char that started the string.
Double quoted strings are also treated special wrt/ formatting
and special chars within the string. The RFC is not clear about
<= div>reformatting combined strings:=A0

=A0 "\n= =A0 =A0foo" + '\nbar' =A0+ "\n =A0 baz".
=
Is it A, B, or C?

A)

=A0 =A0foo
bar
=A0 =A0baz

B)<= /div>

=A0 =A0foo
=A0 =A0bar
=A0 =A0b= az

C)

=A0 =A0foo\nbar
=A0 =A0baz=


Implementing string concatenation = with mixed strings is also problematic.
The result can contain ch= ars that are not allowed in either quoting
format so rendering the combined strings with quotes is not possible.<= /div>


On Mon, Oct 21, 2013 at 7:25 AM, Jernej Tuljak <jernej.tuljak@mg= -soft.si> wrote:
Section 6.1.3 Quoting, RFC6020, states the f= ollowing:

=A0 =A0If a string contains any space or tab characters, a semicolon ("= ;;"),
=A0 =A0braces ("{" or "}"), or comment sequences ("= ;//", "/*", or "*/"), then
=A0 =A0it MUST be enclosed within double or single quotes.

Shouldn't this also include single quote (') and double quote (&quo= t;)? As it is now, this is allowed:

=A0 =A0default "; // or '


A double quote has to end the string.<= /div>
The RFC should make this clear.
=A0
The thing is..how's a lexer supposed to differentiate between quoted an= d unquoted strings (for YANG concatenation) if this is allowed? Consider:
=A0 =A0default ";
=A0 =A0units ";
Is this (A) a single default statement with an argument of ";\n units = " or (B) are there two YANG keywords with a double quote as an argumen= t? There's nothing that prohibits using a semicolon/newline/whitespace = inside quoted strings, so the first case is perfectly valid. There's al= so nothing that prohibits an unquoted string with a value of a single or a = double quote. So which one is it?

This is just 1 default-stmt (if both quote= s are double-quotes).
=A0

Jernej

Andy
=A0

_______________________________________________
netmod mailing list
netmod@ietf.org = https://www.ietf.org/mailman/listinfo/netmod


--089e01494f4849305404e9417d86-- From jernej.tuljak@mg-soft.si Tue Oct 22 01:25:40 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212EA11E8184 for ; Tue, 22 Oct 2013 01:25:40 -0700 (PDT) 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] 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 QqL20FtVvUwG for ; Tue, 22 Oct 2013 01:25:33 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 65D1821E808C for ; Tue, 22 Oct 2013 01:25:17 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id r9M8PGut018461; Tue, 22 Oct 2013 10:25:16 +0200 Message-ID: <52663669.1070205@mg-soft.com> Date: Tue, 22 Oct 2013 10:25:13 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Jernej Tuljak , NETMOD Working Group References: <5265396B.7060306@mg-soft.com> <20131021144031.GC50360@elstar.local> In-Reply-To: <20131021144031.GC50360@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [netmod] Single/double quote as an unquoted string X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 08:25:40 -0000 Dne 21.10.2013 16:40, piše Juergen Schoenwaelder: > On Mon, Oct 21, 2013 at 04:25:47PM +0200, Jernej Tuljak wrote: >> Section 6.1.3 Quoting, RFC6020, states the following: >> >> If a string contains any space or tab characters, a semicolon (";"), >> braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), then >> it MUST be enclosed within double or single quotes. >> >> Shouldn't this also include single quote (') and double quote (")? >> As it is now, this is allowed: >> >> default "; // or ' >> >> The thing is..how's a lexer supposed to differentiate between quoted >> and unquoted strings (for YANG concatenation) if this is allowed? >> Consider: >> >> default "; >> units "; >> >> Is this (A) a single default statement with an argument of ";\n >> units " or (B) are there two YANG keywords with a double quote as an >> argument? There's nothing that prohibits using a >> semicolon/newline/whitespace inside quoted strings, so the first >> case is perfectly valid. There's also nothing that prohibits an >> unquoted string with a value of a single or a double quote. So which >> one is it? > A double quote always starts or ends a quoted strings unless it is > prefixed with a backslash or it is enclosed in a single quoted string. You meant "...unless it is prefixed with a backslash within a double quoted string...", right? Jernej > > /js > From j.schoenwaelder@jacobs-university.de Tue Oct 22 13:31:15 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C9C11E825E for ; Tue, 22 Oct 2013 13:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.22 X-Spam-Level: X-Spam-Status: No, score=-103.22 tagged_above=-999 required=5 tests=[AWL=0.029, 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 Jn517K9M71ok for ; Tue, 22 Oct 2013 13:31:08 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id E21E211E821F for ; Tue, 22 Oct 2013 13:31:07 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 505642021A; Tue, 22 Oct 2013 22:31:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id EW2t2JgViF-A; Tue, 22 Oct 2013 22:31:07 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D58FD2085B; Tue, 22 Oct 2013 22:31:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B831128F5BF8; Tue, 22 Oct 2013 22:31:01 +0200 (CEST) Date: Tue, 22 Oct 2013 22:31:01 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20131022203101.GA59449@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [netmod] vancouver agenda (IETF 88) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 20:31:15 -0000 Hi, I have posted an agenda for the upcoming meeting in Vancouver. http://www.ietf.org/proceedings/88/agenda/agenda-88-netmod Please let me/us know if something should be changed. But also keep in mind that we are relatively short with time. /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 Wed Oct 23 03:14:42 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E2C11E82E8 for ; Wed, 23 Oct 2013 03:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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 lyqvCsPLg6gj for ; Wed, 23 Oct 2013 03:14:41 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 272F311E817A for ; Wed, 23 Oct 2013 03:14:01 -0700 (PDT) Received: from 68a86d0081e0.netpoint.com (187.31.0.109.rev.sfr.net [109.0.31.187]) by mail.nic.cz (Postfix) with ESMTPSA id C9DD7142954; Wed, 23 Oct 2013 12:13:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1382523240; bh=Q7gEVp2v3ZSGk+D+DVNTsnBR48FgLwfaYsR3J990Ryc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=UGVbjDQXzLnN+RFYgNkOaWJcSamk0WlyONG9in+7nqoFfSkfFclkmAQEflz9r/ZIF Q8LAq02Df1hRI9fnBNqx1caj44M5kqoEJqQ22BjFVgwUaDGt2jTG0/FHFoOfEMw9FN MaHY4jAIA00egHXcsT725YqGUv/a74Yyg6y5zE7s= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ladislav Lhotka In-Reply-To: <20131022203101.GA59449@elstar.local> Date: Wed, 23 Oct 2013 12:13:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <00533863-F2B4-495A-A88B-CC2A34ADE557@nic.cz> References: <20131022203101.GA59449@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1510) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] vancouver agenda (IETF 88) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 10:14:42 -0000 On Oct 22, 2013, at 10:31 PM, Juergen Schoenwaelder = wrote: > Hi, >=20 > I have posted an agenda for the upcoming meeting in Vancouver. >=20 > http://www.ietf.org/proceedings/88/agenda/agenda-88-netmod >=20 > Please let me/us know if something should be changed. But also keep in > mind that we are relatively short with time. In my view, the alignment with the I2RS RIB model was successful, so the = routing draft should now be ready for WGLC. As a matter of fact, it = doesn't use the iana-afn-safi module anymore, so I propose to drop that = module together with draft-ietf-netmod-iana-afn-safi-00. 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 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Wed Oct 23 04:24:08 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F3211E839E for ; Wed, 23 Oct 2013 04:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.221 X-Spam-Level: X-Spam-Status: No, score=-103.221 tagged_above=-999 required=5 tests=[AWL=0.028, 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 3bBFntS0kI6E for ; Wed, 23 Oct 2013 04:24:04 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 24F8711E8386 for ; Wed, 23 Oct 2013 04:24:00 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3B12B20086; Wed, 23 Oct 2013 13:23:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id yWwQ0B0lI20x; Wed, 23 Oct 2013 13:23:59 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B02CC20084; Wed, 23 Oct 2013 13:23:58 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 716D02906F6C; Wed, 23 Oct 2013 13:23:52 +0200 (CEST) Date: Wed, 23 Oct 2013 13:23:51 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20131023112351.GA28446@elstar.local> Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org References: <20131022203101.GA59449@elstar.local> <00533863-F2B4-495A-A88B-CC2A34ADE557@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00533863-F2B4-495A-A88B-CC2A34ADE557@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] vancouver agenda (IETF 88) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 11:24:08 -0000 On Wed, Oct 23, 2013 at 12:13:58PM +0200, Ladislav Lhotka wrote: > > On Oct 22, 2013, at 10:31 PM, Juergen Schoenwaelder wrote: > > > Hi, > > > > I have posted an agenda for the upcoming meeting in Vancouver. > > > > http://www.ietf.org/proceedings/88/agenda/agenda-88-netmod > > > > Please let me/us know if something should be changed. But also keep in > > mind that we are relatively short with time. > > In my view, the alignment with the I2RS RIB model was successful, so the routing draft should now be ready for WGLC. As a matter of fact, it doesn't use the iana-afn-safi module anymore, so I propose to drop that module together with draft-ietf-netmod-iana-afn-safi-00. > Perhaps it helps to post a short elaboration of the changes you made, that is some text that is a bit more detailed than the summary in D.1, e.g. by providing the motivation for the change. /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 Thu Oct 24 05:38:34 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0932311E8153 for ; Thu, 24 Oct 2013 05:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.349 X-Spam-Level: X-Spam-Status: No, score=-1.349 tagged_above=-999 required=5 tests=[AWL=-0.254, 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 8c5mcFIqNCkr for ; Thu, 24 Oct 2013 05:38:29 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 43A6711E8256 for ; Thu, 24 Oct 2013 05:38:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 0B2F054047D for ; Thu, 24 Oct 2013 14:38:24 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3q+C0EyP114L for ; Thu, 24 Oct 2013 14:38:17 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 5DDDB540470 for ; Thu, 24 Oct 2013 14:38:13 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org User-Agent: Notmuch/0.15.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Mail-Followup-To: netmod@ietf.org Date: Thu, 24 Oct 2013 14:38:12 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [netmod] changes in the routing model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 12:38:34 -0000 Hi, I am sending more details about the recent changes in the routing draft. Most of them follow from the discussion with I2RS people (Jan Medved, Nitin Bahadur, Sriganesh Kini, and Hariharan Ananthakrishnan). Besides email exchange, we also had a teleconference. The basic plan lies in the following correspondence: | I2RS | NETCONF/YANG | |-----------------+------------------------| | ephemeral data | operational state data | | persistent data | configuration | It means that I2RS agents will be able to read and write (parts of) what is operational state data in the NETCONF sense, but any such changes will not survive reboot. To make persistent changes, I2RS agents will write NETCONF configuration datastore(s). It is an open question whether I2RS agent will be able to act as a compliant NETCONF client, with regard to locks etc. The motivation and reasoning behind the main changes is the following: o Migrated address families from IANA enumerations to identities. I2RS people strongly preferred identities to the IANA enumerations. Meanwhile, a discussion in this list also turned out in favour of identities, so I decided to bite the bullet, and there is now only one identityref leaf specifying an address family instead of two (AFN and SAFI), which is IMO a positive change. o Terminology and node names aligned with the I2RS RIB model: router -> routing instance, routing table -> RIB. I2RS WG are the domain experts, so it makes sense to follow suit. o Introduced uint64 keys for state lists: routing-instance, rib, route, nexthop. The idea is that an I2RS client creates an entry (e.g. a route) and gets back a unique numeric handle that can be used later for referring to that entry. Modelling these handles as keys of operational state lists then seems quite natural. o Feature "user-defined-routing-tables" changed into "advanced- router". I didn't want to introduce more features, I think the distinction between a basic and advanced router should be sufficient. o Made nexthop into a choice in order to allow for nexthop-list (I2RS requirement). o Added nexthop-list with entries having priorities (backup) and weights (load balancing). The last two changes implement multipath routes that are crucial for I2RS. Both are bound to the feature "advanced-router", so simple devices needn't bother with it. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Fri Oct 25 07:09:57 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9EDB11E81A8 for ; Fri, 25 Oct 2013 07:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.334 X-Spam-Level: X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[AWL=-0.239, 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 Tq3jIXxiDt3m for ; Fri, 25 Oct 2013 07:09:53 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id E31F411E8270 for ; Fri, 25 Oct 2013 07:09:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 5CE68540222 for ; Fri, 25 Oct 2013 16:09:48 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0oJv35FT3dgd for ; Fri, 25 Oct 2013 16:09:38 +0200 (CEST) Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 13DD95401FC for ; Fri, 25 Oct 2013 16:09:34 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: References: <20131018.205449.401322121.mbj@tail-f.com> User-Agent: Notmuch/0.15.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Mail-Followup-To: netmod@ietf.org Date: Fri, 25 Oct 2013 16:09:32 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-yang-xpath-extensions-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 14:09:57 -0000 Andy Bierman writes: > Hi, > > I really like this draft. > I think more powerful XPath would make writing > must/when/select expressions less error-prone, and easier to read. Indeed, this is a very useful work. > > I thought there was going to be more XPath functions defined. > We have a couple: > > boolean module-supported(string) // module-name > > boolean feature-supported(string, string) // module-name, feature-name Hmm, XPath generally works with a concrete XML document, so it would be better to expose this info as standard state data - ietf-netconf-monitoring can already give supported modules, right? I think the example in sec. 2.2 uses wrong namespace for the "reverse" function, it should be "ex1" and not "ex2". If the server doesn't advertise the "ietf-yang-xpath-extensions" module, can other advertized modules still use new XPath functions in "must" and "when", if they import that module? Lada > > > Andy > > > > On Fri, Oct 18, 2013 at 11:54 AM, Martin Bjorklund wrote: > >> Hi, >> >> I have posted a draft that introduces a YANG extension statement to >> define new XPath functions. It also defines a couple of XPath >> functions, for some built-in YANG types. Specifically, it solves the >> problem of comparing identities in must/when expressions. >> >> >> /martin >> >> >> >> ---------- Forwarded message ---------- >> From: internet-drafts@ietf.org >> To: Martin Bjorklund >> Cc: >> Date: Fri, 18 Oct 2013 11:52:03 -0700 >> Subject: New Version Notification for >> draft-bjorklund-netmod-yang-xpath-extensions-00.txt >> >> A new version of I-D, draft-bjorklund-netmod-yang-xpath-extensions-00.txt >> has been successfully submitted by Martin Bjorklund and posted to the >> IETF repository. >> >> Filename: draft-bjorklund-netmod-yang-xpath-extensions >> Revision: 00 >> Title: YANG XPath Extensions >> Creation date: 2013-10-18 >> Group: Individual Submission >> Number of pages: 20 >> URL: >> http://www.ietf.org/internet-drafts/draft-bjorklund-netmod-yang-xpath-extensions-00.txt >> Status: >> http://datatracker.ietf.org/doc/draft-bjorklund-netmod-yang-xpath-extensions >> Htmlized: >> http://tools.ietf.org/html/draft-bjorklund-netmod-yang-xpath-extensions-00 >> >> >> Abstract: >> This document introduces new YANG extension statements for defining >> XPath functions. These functions can be used in XPath expressions in >> YANG modules and in NETCONF XPath filters. A set of YANG-specific >> XPath functions are also defined. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Fri Oct 25 07:51:09 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 209B811E8270 for ; Fri, 25 Oct 2013 07:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0m90rWK4rYt4 for ; Fri, 25 Oct 2013 07:51:05 -0700 (PDT) Received: from mail-pb0-f42.google.com (mail-pb0-f42.google.com [209.85.160.42]) by ietfa.amsl.com (Postfix) with ESMTP id E675311E81BB for ; Fri, 25 Oct 2013 07:51:03 -0700 (PDT) Received: by mail-pb0-f42.google.com with SMTP id jt11so3580104pbb.29 for ; Fri, 25 Oct 2013 07:51:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=f+cn69zIPWNEy1l4yiroyZ0q2M/0BS+O1sSv6APECVU=; b=GfrDTZYTlWsz5o6gAx1yoM2DxTNefMqU9814cscg/2Q4kzMGyoGL6sLpCyJ4LXMS9U Rdv4rKW+ExLg20/q02gb3M2gBMlxd+A2p4pw8mJstjC/M4vG4QmbZDh3o1b1r8AwaGPa gh6WCX7HOMujlg102b9EKSCqvDSUTKPQ3LvusC5DjfrzaqbsILHu6JBabGpZ6Rwk8mby zi/XxmSgI9TPM6FVM3hTPjtGQ+dcxa1UR9h/HKnmvSKe3Zlsz9X1k7ag5t1LtFVqQmSM DqxlbMlmbxKtlNDPTXdRgVFMqr1sPGlWVjYRgWMSi3jDjWguBDhW9JKgd6/pVijCYwnf lBvQ== X-Gm-Message-State: ALoCoQkgDirauYrTBacVPOOeqK7plGvWtTVJ/q6NZUbdnH4ePLdvcAPT6FOQkRDkW/XGfbhf6ZJx MIME-Version: 1.0 X-Received: by 10.67.22.67 with SMTP id hq3mr11192196pad.132.1382712663444; Fri, 25 Oct 2013 07:51:03 -0700 (PDT) Received: by 10.70.9.33 with HTTP; Fri, 25 Oct 2013 07:51:03 -0700 (PDT) In-Reply-To: References: <20131018.205449.401322121.mbj@tail-f.com> Date: Fri, 25 Oct 2013 07:51:03 -0700 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=047d7b5dbbd421a72f04e991e1b6 Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-yang-xpath-extensions-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 14:51:09 -0000 --047d7b5dbbd421a72f04e991e1b6 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 25, 2013 at 7:09 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > > > Hi, > > > > I really like this draft. > > I think more powerful XPath would make writing > > must/when/select expressions less error-prone, and easier to read. > > Indeed, this is a very useful work. > > > > > I thought there was going to be more XPath functions defined. > > We have a couple: > > > > boolean module-supported(string) // module-name > > > > boolean feature-supported(string, string) // module-name, feature-name > > Hmm, XPath generally works with a concrete XML document, so it would be > better to expose this info as standard state data - ietf-netconf-monitoring > can already give supported modules, right? > > The ietf-netconf-monitoring module is optional to implement. There are no features listed in that data structure, and writing XPath to match against strings is difficult (also optional to implement). > I think the example in sec. 2.2 uses wrong namespace for the "reverse" > function, it should be "ex1" and not "ex2". > > If the server doesn't advertise the "ietf-yang-xpath-extensions" module, > can other advertized modules still use new XPath functions in "must" and > "when", if they import that module? > > Lada > > > > > > > Andy > > > > > Andy > > > > On Fri, Oct 18, 2013 at 11:54 AM, Martin Bjorklund > wrote: > > > >> Hi, > >> > >> I have posted a draft that introduces a YANG extension statement to > >> define new XPath functions. It also defines a couple of XPath > >> functions, for some built-in YANG types. Specifically, it solves the > >> problem of comparing identities in must/when expressions. > >> > >> > >> /martin > >> > >> > >> > >> ---------- Forwarded message ---------- > >> From: internet-drafts@ietf.org > >> To: Martin Bjorklund > >> Cc: > >> Date: Fri, 18 Oct 2013 11:52:03 -0700 > >> Subject: New Version Notification for > >> draft-bjorklund-netmod-yang-xpath-extensions-00.txt > >> > >> A new version of I-D, > draft-bjorklund-netmod-yang-xpath-extensions-00.txt > >> has been successfully submitted by Martin Bjorklund and posted to the > >> IETF repository. > >> > >> Filename: draft-bjorklund-netmod-yang-xpath-extensions > >> Revision: 00 > >> Title: YANG XPath Extensions > >> Creation date: 2013-10-18 > >> Group: Individual Submission > >> Number of pages: 20 > >> URL: > >> > http://www.ietf.org/internet-drafts/draft-bjorklund-netmod-yang-xpath-extensions-00.txt > >> Status: > >> > http://datatracker.ietf.org/doc/draft-bjorklund-netmod-yang-xpath-extensions > >> Htmlized: > >> > http://tools.ietf.org/html/draft-bjorklund-netmod-yang-xpath-extensions-00 > >> > >> > >> Abstract: > >> This document introduces new YANG extension statements for defining > >> XPath functions. These functions can be used in XPath expressions in > >> YANG modules and in NETCONF XPath filters. A set of YANG-specific > >> XPath functions are also defined. > >> > >> > >> > >> > >> Please note that it may take a couple of minutes from the time of > >> submission > >> until the htmlized version and diff are available at tools.ietf.org. > >> > >> The IETF Secretariat > >> > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > >> > >> > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --047d7b5dbbd421a72f04e991e1b6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Oct 25, 2013 at 7:09 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:
Andy Bierman <andy@yumaworks.com> writes:

> Hi,
>
> I really like this draft.
> I think more powerful XPath would make writing
> must/when/select expressions less error-prone, and easier to read.

Indeed, this is a very useful work.

>
> I thought there was going to be more XPath functions defined.
> We have a couple:
>
> =A0 =A0boolean module-supported(string) =A0// module-name
>
> =A0 =A0boolean feature-supported(string, string) // module-name, featu= re-name

Hmm, XPath generally works with a concrete XML document, so it would be bet= ter to expose this info as standard state data - ietf-netconf-monitoring ca= n already give supported modules, right?


The ietf-netconf-monitoring module is = optional to implement.
There are no features listed in that data = structure, and writing XPath
to match against <capability> = strings is difficult (also optional to implement).

=A0 =A0 =A0
I think the example in sec. 2.2 uses wrong namespace for the "reverse&= quot; function, it should be "ex1" and not "ex2".

If the server doesn't advertise the "ietf-yang-xpath-extensions&qu= ot; module, can other advertized modules still use new XPath functions in &= quot;must" and "when", if they import that module?

Lada

>
>
> Andy
>
>


Andy

=
=A0
>
> On Fri, Oct 18, 2013 at 11:54 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
>> Hi,
>>
>> I have posted a draft that introduces a YANG extension statement t= o
>> define new XPath functions. =A0It also defines a couple of XPath >> functions, for some built-in YANG types. =A0Specifically, it solve= s the
>> problem of comparing identities in must/when expressions.
>>
>>
>> /martin
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: internet-drafts@= ietf.org
>> To: Martin Bjorklund <mbj@tai= l-f.com>
>> Cc:
>> Date: Fri, 18 Oct 2013 11:52:03 -0700
>> Subject: New Version Notification for
>> draft-bjorklund-netmod-yang-xpath-extensions-00.txt
>>
>> A new version of I-D, draft-bjorklund-netmod-yang-xpath-extensions= -00.txt
>> has been successfully submitted by Martin Bjorklund and posted to = the
>> IETF repository.
>>
>> Filename: =A0 =A0 =A0 =A0draft-bjorklund-netmod-yang-xpath-extensi= ons
>> Revision: =A0 =A0 =A0 =A000
>> Title: =A0 =A0 =A0 =A0 =A0 YANG XPath Extensions
>> Creation date: =A0 2013-10-18
>> Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
>> Number of pages: 20
>> URL:
>> http://www.ietf.org/int= ernet-drafts/draft-bjorklund-netmod-yang-xpath-extensions-00.txt
>> Status:
>> http://datatracker.ietf.org/doc/dr= aft-bjorklund-netmod-yang-xpath-extensions
>> Htmlized:
>> http://tools.ietf.org/html/draft-bjo= rklund-netmod-yang-xpath-extensions-00
>>
>>
>> Abstract:
>> =A0 =A0This document introduces new YANG extension statements for = defining
>> =A0 =A0XPath functions. =A0These functions can be used in XPath ex= pressions in
>> =A0 =A0YANG modules and in NETCONF XPath filters. =A0A set of YANG= -specific
>> =A0 =A0XPath functions are also defined.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of<= br> >> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
netmod@ietf.org
= https://www.ietf.org/mailman/listinfo/netmod

--047d7b5dbbd421a72f04e991e1b6-- From mbj@tail-f.com Fri Oct 25 08:02:13 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 752D511E83CB for ; Fri, 25 Oct 2013 08:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 Q0j1CHVBSrBd for ; Fri, 25 Oct 2013 08:02:07 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 8F59421F9E8D for ; Fri, 25 Oct 2013 08:01:56 -0700 (PDT) Received: from localhost (unknown [193.12.34.23]) by mail.tail-f.com (Postfix) with ESMTPSA id 6946D1200443; Fri, 25 Oct 2013 17:01:54 +0200 (CEST) Date: Fri, 25 Oct 2013 17:01:54 +0200 (CEST) Message-Id: <20131025.170154.518459007.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20131018.205449.401322121.mbj@tail-f.com> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-yang-xpath-extensions-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 15:02:13 -0000 Ladislav Lhotka wrote: > Andy Bierman writes: > > > Hi, > > > > I really like this draft. > > I think more powerful XPath would make writing > > must/when/select expressions less error-prone, and easier to read. > > Indeed, this is a very useful work. > > > > > I thought there was going to be more XPath functions defined. > > We have a couple: > > > > boolean module-supported(string) // module-name > > > > boolean feature-supported(string, string) // module-name, feature-name > > Hmm, XPath generally works with a concrete XML document, so it would be better > to expose this info as standard state data - ietf-netconf-monitoring can > already give supported modules, right? > > I think the example in sec. 2.2 uses wrong namespace for the "reverse" > function, it should be "ex1" and not "ex2". Right, and the function is actually called string-reverse. I have fixed this. > If the server doesn't advertise the "ietf-yang-xpath-extensions" module, can > other advertized modules still use new XPath functions in "must" and "when", if > they import that module? Yes. Note that all XPath expressions are conceptual. If a server claims that it implements a module that uses such an xpath function, it must implement the contraint somehow. It doesn't have to use an XPath evaluator; it can be implemented in code - just like ane constraints defined in description statements. /martin From lhotka@nic.cz Fri Oct 25 09:15:58 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C197311E8339 for ; Fri, 25 Oct 2013 09:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.623 X-Spam-Level: X-Spam-Status: No, score=-1.623 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] 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 CZzWdor56-YP for ; Fri, 25 Oct 2013 09:15:58 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 4297111E833F for ; Fri, 25 Oct 2013 09:15:52 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 27FCF14220C; Fri, 25 Oct 2013 18:15:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1382717749; bh=i4UKGRskYoUwiIWwQmpPva29ihTku5h2WisqnLW3Nrc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=QAFNWIjDO3b/Sb9jai3kccHlM1+zjH3MfYpsG77cJmlJU9ixbn5IVK9UU2jwJkVyo hgoYDtpBkarvIqosB0mRG55am64SYLpWrW6vTYcfPpLdqainOkJlMQR17RivnNfXkW mtmhGOsn+tpq6Z6+KiOOfRfcCfDefMdp7Rjh104M= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ladislav Lhotka In-Reply-To: <20131025.170154.518459007.mbj@tail-f.com> Date: Fri, 25 Oct 2013 18:15:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0840D035-DF82-4436-85DC-8DA59D414BB7@nic.cz> References: <20131018.205449.401322121.mbj@tail-f.com> <20131025.170154.518459007.mbj@tail-f.com> To: =?iso-8859-1?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1816) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-yang-xpath-extensions-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 16:15:58 -0000 On 25 Oct 2013, at 17:01, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> Andy Bierman writes: >>=20 >>> Hi, >>>=20 >>> I really like this draft. >>> I think more powerful XPath would make writing >>> must/when/select expressions less error-prone, and easier to read. >>=20 >> Indeed, this is a very useful work. >>=20 >>>=20 >>> I thought there was going to be more XPath functions defined. >>> We have a couple: >>>=20 >>> boolean module-supported(string) // module-name >>>=20 >>> boolean feature-supported(string, string) // module-name, = feature-name >>=20 >> Hmm, XPath generally works with a concrete XML document, so it would = be better >> to expose this info as standard state data - ietf-netconf-monitoring = can >> already give supported modules, right? >>=20 >> I think the example in sec. 2.2 uses wrong namespace for the = "reverse" >> function, it should be "ex1" and not "ex2". >=20 > Right, and the function is actually called string-reverse. I have > fixed this. >=20 >> If the server doesn't advertise the "ietf-yang-xpath-extensions" = module, can >> other advertized modules still use new XPath functions in "must" and = "when", if >> they import that module? >=20 > Yes. Note that all XPath expressions are conceptual. If a server > claims that it implements a module that uses such an xpath function, > it must implement the contraint somehow. It doesn't have to use an > XPath evaluator; it can be implemented in code - just like ane > constraints defined in description statements. Yes, but one has to be careful with revisions - sec. 10 in RFC 6020 = allows new extensions in an updated module, but I think in this case it = could be dangerous because the server cannot easily ignore unknown = functions appearing in XPath expressions. Lada=20 >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jmh@joelhalpern.com Fri Oct 25 10:21:36 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47DA411E80E7 for ; Fri, 25 Oct 2013 10:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.611 X-Spam-Level: X-Spam-Status: No, score=-102.611 tagged_above=-999 required=5 tests=[AWL=-0.012, 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 Nn93-qIZ8BP1 for ; Fri, 25 Oct 2013 10:21:30 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id EA74411E81A6 for ; Fri, 25 Oct 2013 10:21:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id C46A1E240B for ; Fri, 25 Oct 2013 10:21:28 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (c213-89-137-101.bredband.comhem.se [213.89.137.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 37AD6E240E for ; Fri, 25 Oct 2013 10:21:28 -0700 (PDT) Message-ID: <526AA898.3050902@joelhalpern.com> Date: Fri, 25 Oct 2013 13:21:28 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: netmod@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] changes in the routing model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 17:21:36 -0000 I am a bit confused by teh discussion of configuration / persistent data in this email. I believe the working group agreement with regard to the I2RS architecture and persistence is that NO i2RS changes persist across reboot. Yours, Joel M. Halpern On 10/24/13 8:38 AM, Ladislav Lhotka wrote: > Hi, > > I am sending more details about the recent changes in the routing draft. Most of them follow from the discussion with I2RS people (Jan Medved, Nitin Bahadur, Sriganesh Kini, and Hariharan Ananthakrishnan). Besides email exchange, we also had a teleconference. > > The basic plan lies in the following correspondence: > > | I2RS | NETCONF/YANG | > |-----------------+------------------------| > | ephemeral data | operational state data | > | persistent data | configuration | > > It means that I2RS agents will be able to read and write (parts of) what is operational state data in the NETCONF sense, but any such changes will not survive reboot. To make persistent changes, I2RS agents will write NETCONF configuration datastore(s). It is an open question whether I2RS agent will be able to act as a compliant NETCONF client, with regard to locks etc. > > The motivation and reasoning behind the main changes is the following: > > o Migrated address families from IANA enumerations to identities. > > I2RS people strongly preferred identities to the IANA enumerations. Meanwhile, a discussion in this list also turned out in favour of identities, so I decided to bite the bullet, and there is now only one identityref leaf specifying an address family instead of two (AFN and SAFI), which is IMO a positive change. > > o Terminology and node names aligned with the I2RS RIB model: router > -> routing instance, routing table -> RIB. > > I2RS WG are the domain experts, so it makes sense to follow suit. > > o Introduced uint64 keys for state lists: routing-instance, rib, > route, nexthop. > > The idea is that an I2RS client creates an entry (e.g. a route) and gets back a unique numeric handle that can be used later for referring to that entry. Modelling these handles as keys of operational state lists then seems quite natural. > > o Feature "user-defined-routing-tables" changed into "advanced- > router". > > I didn't want to introduce more features, I think the distinction between a basic and advanced router should be sufficient. > > o Made nexthop into a choice in order to allow for nexthop-list > (I2RS requirement). > > o Added nexthop-list with entries having priorities (backup) and > weights (load balancing). > > The last two changes implement multipath routes that are crucial for I2RS. Both are bound to the feature "advanced-router", so simple devices needn't bother with it. > > Lada > From mbj@tail-f.com Fri Oct 25 10:24:55 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 310C311E8382 for ; Fri, 25 Oct 2013 10:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 xHR6miTZIFPN for ; Fri, 25 Oct 2013 10:24:49 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 8B03811E8369 for ; Fri, 25 Oct 2013 10:24:46 -0700 (PDT) Received: from localhost (unknown [193.12.34.23]) by mail.tail-f.com (Postfix) with ESMTPSA id 86F851200A2B; Fri, 25 Oct 2013 19:24:45 +0200 (CEST) Date: Fri, 25 Oct 2013 19:24:45 +0200 (CEST) Message-Id: <20131025.192445.290343408.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <0840D035-DF82-4436-85DC-8DA59D414BB7@nic.cz> References: <20131025.170154.518459007.mbj@tail-f.com> <0840D035-DF82-4436-85DC-8DA59D414BB7@nic.cz> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-yang-xpath-extensions-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 17:24:55 -0000 Ladislav Lhotka wrote: > > On 25 Oct 2013, at 17:01, Martin Bjorklund wrote: > > > Ladislav Lhotka wrote: > >> If the server doesn't advertise the "ietf-yang-xpath-extensions" module, can > >> other advertized modules still use new XPath functions in "must" and "when", > >> if > >> they import that module? > > > > Yes. Note that all XPath expressions are conceptual. If a server > > claims that it implements a module that uses such an xpath function, > > it must implement the contraint somehow. It doesn't have to use an > > XPath evaluator; it can be implemented in code - just like ane > > constraints defined in description statements. > > Yes, but one has to be careful with revisions - sec. 10 in RFC 6020 allows new > extensions in an updated module, but I think in this case it could be dangerous > because the server cannot easily ignore unknown functions appearing in XPath > expressions. You typcially do not just load a new module into a server; it needs some instrumentation to be useful. So a new revison that uses some new XPath functions or not needs an implemention effort in the server. But maybe I misunderstood your concern? /martin From andy@yumaworks.com Fri Oct 25 11:33:47 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1006211E81B3 for ; Fri, 25 Oct 2013 11:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.85 X-Spam-Level: X-Spam-Status: No, score=-2.85 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 qmv3vfNFcwWY for ; Fri, 25 Oct 2013 11:33:42 -0700 (PDT) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by ietfa.amsl.com (Postfix) with ESMTP id D5D5F11E81AB for ; Fri, 25 Oct 2013 11:33:42 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id hz1so4408841pad.2 for ; Fri, 25 Oct 2013 11:33:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SMwl0hLuUa3EZ0i84kPhVxkikrHT8ZZgR2qizGNV5Lo=; b=QWSdGmju2Fx9bbhutg2fQagWkrU0e/IgPPtyGljW+e+W9S3lDqQTptty92zjcp7fuK CoJY6XvAr9VAFRJtlV9rh2V92KJFOD1Le/Rvgu/CwbXFhaw3qCL/WjhSGC3p/BQZuRiX i18iIzh8Axc8MR5w5iy4LflB5Vw/hKP1/OFZAFIKqtPmSIheYZMzGQZ59NZus8/Qf8QU 8eZE/s/J07Y8DLFoGPe6kC65SKukw3NW4YICgH8yvtiqSPmCle52jDwG+xKOKv66M3pu GAigs2gO91LE9lY6hYYecPowjcFxsXruiuFTAuCZJQwb8lBCuJ2gPtnEESnfGPG+z6CU llGA== X-Gm-Message-State: ALoCoQmKxcHpyDLV1DSivocjuigUjbfIsOy8rD6oCac3Z342afHIZFFrF/cAB2rGH4uy4JFnMBAp MIME-Version: 1.0 X-Received: by 10.66.161.38 with SMTP id xp6mr11860454pab.145.1382726022494; Fri, 25 Oct 2013 11:33:42 -0700 (PDT) Received: by 10.70.9.33 with HTTP; Fri, 25 Oct 2013 11:33:42 -0700 (PDT) In-Reply-To: <20131025.192445.290343408.mbj@tail-f.com> References: <20131025.170154.518459007.mbj@tail-f.com> <0840D035-DF82-4436-85DC-8DA59D414BB7@nic.cz> <20131025.192445.290343408.mbj@tail-f.com> Date: Fri, 25 Oct 2013 11:33:42 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=047d7b6d87b264a84904e994fdc3 Cc: "netmod@ietf.org" Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-yang-xpath-extensions-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 18:33:47 -0000 --047d7b6d87b264a84904e994fdc3 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 25, 2013 at 10:24 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > > > On 25 Oct 2013, at 17:01, Martin Bjorklund wrote: > > > > > Ladislav Lhotka wrote: > > >> If the server doesn't advertise the "ietf-yang-xpath-extensions" > module, can > > >> other advertized modules still use new XPath functions in "must" and > "when", > > >> if > > >> they import that module? > > > > > > Yes. Note that all XPath expressions are conceptual. If a server > > > claims that it implements a module that uses such an xpath function, > > > it must implement the contraint somehow. It doesn't have to use an > > > XPath evaluator; it can be implemented in code - just like ane > > > constraints defined in description statements. > > > > Yes, but one has to be careful with revisions - sec. 10 in RFC 6020 > allows new > > extensions in an updated module, but I think in this case it could be > dangerous > > because the server cannot easily ignore unknown functions appearing in > XPath > > expressions. > > You typcially do not just load a new module into a server; it needs > some instrumentation to be useful. So a new revison that uses some > new XPath functions or not needs an implemention effort in the > server. > > A YANG compiler that checks XPath can understand the xpath-function statement and validate the XPath, even without instrumentation. Some more comments: sec 2 is a bit thin. It should say the entire normative deefinition is in the YANG module, not sec. 2. The document order of the xpath-argument statement is significant, since XPath functions are passed an ordered parameter list. IMO the extension statements should be in a separate module because they will be stable. The library of external xpath-function\ statements is not likely to be stable. This document has the mandatory set of XPath functions, so WG consensus will be needed. The current set is somewhat limited. I am not sure this example does what it says: leaf mgmt-interface { type leafref { path "/interface/name"; } must 'yangxp:deref(.)/../enabled = "true"' { error-message "The management interface cannot be disabled."; } } The must-expr says that at least 1 interface (derived from the nodeset of /interface/name leafs) must be enabled. It does not say the interface indicated by the value of mgmt-interface must be enabled. The path-expr is "/interface/name" not "/interface/name[.=current()]". Andy But maybe I misunderstood your concern? > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --047d7b6d87b264a84904e994fdc3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Oct 25, 2013 at 10:24 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> On 25 Oct 2013, at 17:01, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Ladislav Lhotka <lhotka@nic.cz> wrote:
> >> If the server doesn't advertise the "ietf-yang-xpath= -extensions" module, can
> >> other advertized modules still use new XPath functions in &qu= ot;must" and "when",
> >> if
> >> they import that module?
> >
> > Yes. =A0Note that all XPath expressions are conceptual. =A0If a s= erver
> > claims that it implements a module that uses such an xpath functi= on,
> > it must implement the contraint somehow. =A0It doesn't have t= o use an
> > XPath evaluator; it can be implemented in code - just like ane > > constraints defined in description statements.
>
> Yes, but one has to be careful with revisions - sec. 10 in RFC 6020 al= lows new
> extensions in an updated module, but I think in this case it could be = dangerous
> because the server cannot easily ignore unknown functions appearing in= XPath
> expressions.

You typcially do not just load a new module into a server; it needs
some instrumentation to be useful. =A0So a new revison that uses some
new XPath functions or not needs an implemention effort in the
server.


A YANG compiler that checks XPath can = understand the =A0xpath-function statement
and validate the XPath= , even without instrumentation.

Some more comments= :

sec 2 is a bit thin. It should say the entire normative= deefinition
is in the YANG module, not sec. 2.

The document order of the xpath-argument statement is significant,<= /div>
since XPath functions are passed an ordered parameter list.
=
IMO the extension statements should be in a separate module<= /div>
because they will be stable. =A0The library of external xpath-fun= ction\
statements is not likely to be stable.

This d= ocument has the mandatory set of XPath functions,
so WG consensus= will be needed. The current set is somewhat limited.

I am not sure this example does what it says:

=A0 =A0leaf mgmt-interface {
=A0 =A0 =A0 =A0 =A0type leafre= f {
=A0 =A0 =A0 =A0 =A0 =A0 =A0path "/interface/name";<= /div>
=A0 =A0 =A0 =A0 =A0}
=A0 =A0 =A0 =A0 =A0must 'yangxp:deref(.)/../enabled =3D "true= "' {
=A0 =A0 =A0 =A0 =A0 =A0 =A0error-message
= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"The management interface cannot be= disabled.";
=A0 =A0 =A0 =A0 =A0}
=A0 =A0 =A0}

The must-expr says that at= least 1 interface (derived from the nodeset
of /interface/name l= eafs) must be enabled. It does not say the interface
indicated by= the value of mgmt-interface must be enabled.
The path-expr is "/interface/name" not "/interface/name= [.=3Dcurrent()]".


Andy








=

But maybe I misunderstood your concern?


/martin
_______________________________________________
netmod mailing list
netmod@ietf.org = https://www.ietf.org/mailman/listinfo/netmod
--047d7b6d87b264a84904e994fdc3-- From lhotka@nic.cz Fri Oct 25 12:02:27 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89DC211E8377 for ; Fri, 25 Oct 2013 12:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.777 X-Spam-Level: X-Spam-Status: No, score=-1.777 tagged_above=-999 required=5 tests=[AWL=0.222, 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 GxNnkRl4D+5N for ; Fri, 25 Oct 2013 12:02:22 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 04C0311E82F9 for ; Fri, 25 Oct 2013 12:01:48 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id C44E314220C; Fri, 25 Oct 2013 21:01:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1382727703; bh=GY/eugPqnGa+bd0Dgi1g32b/U1GzZCeh1JBvltLqw/E=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=BOKkQPbPcudLAnNM+jQP90Q+ndVxkZDCx+R0WrEZWIl0kwDcDjfr/UN5dtlsJHpaV TEV5b3AOsXho8B4QPlk1JUQA8UrmOV32gJYTSgpZCUM6SMNno9DrJcyzVcPZhmUIqf jiAoyiWjw7udHEt9SIolJm/SaFedNU5+gRz771ns= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ladislav Lhotka In-Reply-To: <526AA898.3050902@joelhalpern.com> Date: Fri, 25 Oct 2013 21:01:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <526AA898.3050902@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1816) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] changes in the routing model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 19:02:27 -0000 On 25 Oct 2013, at 19:21, Joel M. Halpern wrote: > I am a bit confused by teh discussion of configuration / persistent = data in this email. > I believe the working group agreement with regard to the I2RS = architecture and persistence is that NO i2RS changes persist across = reboot. This was my original understanding, too, but the authors of the RIB info = model expressed the need for persistent data - routes in particular. = This is an excerpt from the =93minutes=94 of our teleconference, by Jan: The current model has clear distinction between config and operational data. If i2rs wants to use the data model it needs to define a yang extension identifying data as read-write as opposed to read-only. This will work well for ephemeral data. For persistent data, use the config tree to add static routes - but a static route entry has to have = almost all (or all?) the attributes that an ephemeral route entry has. Lada >=20 > Yours, > Joel M. Halpern >=20 > On 10/24/13 8:38 AM, Ladislav Lhotka wrote: >> Hi, >>=20 >> I am sending more details about the recent changes in the routing = draft. Most of them follow from the discussion with I2RS people (Jan = Medved, Nitin Bahadur, Sriganesh Kini, and Hariharan Ananthakrishnan). = Besides email exchange, we also had a teleconference. >>=20 >> The basic plan lies in the following correspondence: >>=20 >> | I2RS | NETCONF/YANG | >> |-----------------+------------------------| >> | ephemeral data | operational state data | >> | persistent data | configuration | >>=20 >> It means that I2RS agents will be able to read and write (parts of) = what is operational state data in the NETCONF sense, but any such = changes will not survive reboot. To make persistent changes, I2RS agents = will write NETCONF configuration datastore(s). It is an open question = whether I2RS agent will be able to act as a compliant NETCONF client, = with regard to locks etc. >>=20 >> The motivation and reasoning behind the main changes is the = following: >>=20 >> o Migrated address families from IANA enumerations to identities. >>=20 >> I2RS people strongly preferred identities to the IANA enumerations. = Meanwhile, a discussion in this list also turned out in favour of = identities, so I decided to bite the bullet, and there is now only one = identityref leaf specifying an address family instead of two (AFN and = SAFI), which is IMO a positive change. >>=20 >> o Terminology and node names aligned with the I2RS RIB model: = router >> -> routing instance, routing table -> RIB. >>=20 >> I2RS WG are the domain experts, so it makes sense to follow suit. >>=20 >> o Introduced uint64 keys for state lists: routing-instance, rib, >> route, nexthop. >>=20 >> The idea is that an I2RS client creates an entry (e.g. a route) and = gets back a unique numeric handle that can be used later for referring = to that entry. Modelling these handles as keys of operational state = lists then seems quite natural. >>=20 >> o Feature "user-defined-routing-tables" changed into "advanced- >> router". >>=20 >> I didn't want to introduce more features, I think the distinction = between a basic and advanced router should be sufficient. >>=20 >> o Made nexthop into a choice in order to allow for nexthop-list >> (I2RS requirement). >>=20 >> o Added nexthop-list with entries having priorities (backup) and >> weights (load balancing). >>=20 >> The last two changes implement multipath routes that are crucial for = I2RS. Both are bound to the feature "advanced-router", so simple devices = needn't bother with it. >>=20 >> Lada >>=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Fri Oct 25 12:07:18 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B9521F9FAC for ; Fri, 25 Oct 2013 12:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.638 X-Spam-Level: X-Spam-Status: No, score=-1.638 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] 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 JuGqOe04L0aV for ; Fri, 25 Oct 2013 12:07:18 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id B2BFE11E81DA for ; Fri, 25 Oct 2013 12:06:51 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 35C7814220C; Fri, 25 Oct 2013 21:06:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1382728009; bh=41TACpY7NZNmRJXlnz9fa5hmH85VClX97MiuK4ZiPEU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=l4FtT4mBlItX+vOYcdUvKtQb19Gpq/6Isv50BuEB8b8GSn73WNy8buh+Iirlk0cZt MvXeaOJLi+Uy+7UmTPQ1cYRq7S9GqcfaP7fo+uHMAksWZTeceuvnsOhh6+HgJquzJv TwDkrt6CjM+MZ0Hv5c3d+8doTz3NxLy21qH3NB6A= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ladislav Lhotka In-Reply-To: <20131025.192445.290343408.mbj@tail-f.com> Date: Fri, 25 Oct 2013 21:06:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131025.170154.518459007.mbj@tail-f.com> <0840D035-DF82-4436-85DC-8DA59D414BB7@nic.cz> <20131025.192445.290343408.mbj@tail-f.com> To: =?iso-8859-1?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1816) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-yang-xpath-extensions-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 19:07:18 -0000 On 25 Oct 2013, at 19:24, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>=20 >> On 25 Oct 2013, at 17:01, Martin Bjorklund wrote: >>=20 >>> Ladislav Lhotka wrote: >>>> If the server doesn't advertise the "ietf-yang-xpath-extensions" = module, can >>>> other advertized modules still use new XPath functions in "must" = and "when", >>>> if >>>> they import that module? >>>=20 >>> Yes. Note that all XPath expressions are conceptual. If a server >>> claims that it implements a module that uses such an xpath function, >>> it must implement the contraint somehow. It doesn't have to use an >>> XPath evaluator; it can be implemented in code - just like ane >>> constraints defined in description statements. >>=20 >> Yes, but one has to be careful with revisions - sec. 10 in RFC 6020 = allows new >> extensions in an updated module, but I think in this case it could be = dangerous >> because the server cannot easily ignore unknown functions appearing = in XPath >> expressions. >=20 > You typcially do not just load a new module into a server; it needs > some instrumentation to be useful. So a new revison that uses some > new XPath functions or not needs an implemention effort in the > server. >=20 > But maybe I misunderstood your concern? Sec. 6.3.1 says: If a YANG compiler does not support a particular extension, which = appears in a YANG module as an unknown-statement (see Section 12), the = entire unknown-statement MAY be ignored by the compiler. So my point here is that while ignoring extensions is easy because they = are self-contained, it is not the case for extensions in XPath = expressions. But maybe it is not an issue. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jmh@joelhalpern.com Fri Oct 25 12:13:48 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4761A11E8198 for ; Fri, 25 Oct 2013 12:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.31 X-Spam-Level: X-Spam-Status: No, score=-102.31 tagged_above=-999 required=5 tests=[AWL=-0.311, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, 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 5XCClosY0Ite for ; Fri, 25 Oct 2013 12:13:43 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 28D7A11E81B6 for ; Fri, 25 Oct 2013 12:13:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id F06221C0D7A; Fri, 25 Oct 2013 12:13:40 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (c213-89-137-101.bredband.comhem.se [213.89.137.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id E626B1C0C61; Fri, 25 Oct 2013 12:13:39 -0700 (PDT) Message-ID: <526AC2E3.3070607@joelhalpern.com> Date: Fri, 25 Oct 2013 15:13:39 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ladislav Lhotka References: <526AA898.3050902@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] changes in the routing model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 19:13:48 -0000 There appears to be a miscommunication of some kind. Quoting from section 5.2 of draft-ietf-i2rs-archtiecture: The I2RS Agent will not attempt to retain or reapply state across routing element reboot. I will not attempt to read Jan's mind or provide interpretation. Rather than taking my word, I suggest you raise this question on the I2RS mailing list. Yours, Joel On 10/25/13 3:01 PM, Ladislav Lhotka wrote: > > On 25 Oct 2013, at 19:21, Joel M. Halpern wrote: > >> I am a bit confused by teh discussion of configuration / persistent data in this email. >> I believe the working group agreement with regard to the I2RS architecture and persistence is that NO i2RS changes persist across reboot. > > This was my original understanding, too, but the authors of the RIB info model expressed the need for persistent data - routes in particular. This is an excerpt from the “minutes” of our teleconference, by Jan: > > The current model has clear distinction between config and operational > data. If i2rs wants to use the data model it needs to define a yang > extension identifying data as read-write as opposed to read-only. This > will work well for ephemeral data. For persistent data, use the config > tree to add static routes - but a static route entry has to have almost > all (or all?) the attributes that an ephemeral route entry has. > > Lada > >> >> Yours, >> Joel M. Halpern >> >> On 10/24/13 8:38 AM, Ladislav Lhotka wrote: >>> Hi, >>> >>> I am sending more details about the recent changes in the routing draft. Most of them follow from the discussion with I2RS people (Jan Medved, Nitin Bahadur, Sriganesh Kini, and Hariharan Ananthakrishnan). Besides email exchange, we also had a teleconference. >>> >>> The basic plan lies in the following correspondence: >>> >>> | I2RS | NETCONF/YANG | >>> |-----------------+------------------------| >>> | ephemeral data | operational state data | >>> | persistent data | configuration | >>> >>> It means that I2RS agents will be able to read and write (parts of) what is operational state data in the NETCONF sense, but any such changes will not survive reboot. To make persistent changes, I2RS agents will write NETCONF configuration datastore(s). It is an open question whether I2RS agent will be able to act as a compliant NETCONF client, with regard to locks etc. >>> >>> The motivation and reasoning behind the main changes is the following: >>> >>> o Migrated address families from IANA enumerations to identities. >>> >>> I2RS people strongly preferred identities to the IANA enumerations. Meanwhile, a discussion in this list also turned out in favour of identities, so I decided to bite the bullet, and there is now only one identityref leaf specifying an address family instead of two (AFN and SAFI), which is IMO a positive change. >>> >>> o Terminology and node names aligned with the I2RS RIB model: router >>> -> routing instance, routing table -> RIB. >>> >>> I2RS WG are the domain experts, so it makes sense to follow suit. >>> >>> o Introduced uint64 keys for state lists: routing-instance, rib, >>> route, nexthop. >>> >>> The idea is that an I2RS client creates an entry (e.g. a route) and gets back a unique numeric handle that can be used later for referring to that entry. Modelling these handles as keys of operational state lists then seems quite natural. >>> >>> o Feature "user-defined-routing-tables" changed into "advanced- >>> router". >>> >>> I didn't want to introduce more features, I think the distinction between a basic and advanced router should be sufficient. >>> >>> o Made nexthop into a choice in order to allow for nexthop-list >>> (I2RS requirement). >>> >>> o Added nexthop-list with entries having priorities (backup) and >>> weights (load balancing). >>> >>> The last two changes implement multipath routes that are crucial for I2RS. Both are bound to the feature "advanced-router", so simple devices needn't bother with it. >>> >>> Lada >>> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > From lhotka@nic.cz Fri Oct 25 12:29:00 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9FC11E81D1 for ; Fri, 25 Oct 2013 12:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[AWL=0.208, 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 CmOkzORxX56d for ; Fri, 25 Oct 2013 12:28:59 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB3311E813A for ; Fri, 25 Oct 2013 12:28:59 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 30C7E14220C; Fri, 25 Oct 2013 21:28:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1382729338; bh=XLCiIKDfKnXoTOECRdrsnKSQwqMl+5BKEFJcVDoxjs0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=nHQS3Q09qiqOuEiIlRhduUYnanQIbvcckZtwFis3P7Z8Zxx/cV367I2PSsLm1/mZG dnfSvw6WYa5kNIquTeXztfIfvUQ0H1b0WyjVppq79ifPof6ROcSZlu0uF/bfeuQd1O vpf8wOG4XE+FvtwmO2qOW9glI9RiQoKVYEfBS2H0= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ladislav Lhotka In-Reply-To: <526AC2E3.3070607@joelhalpern.com> Date: Fri, 25 Oct 2013 21:28:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <526AA898.3050902@joelhalpern.com> <526AC2E3.3070607@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1816) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] changes in the routing model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 19:29:00 -0000 On 25 Oct 2013, at 21:13, Joel M. Halpern wrote: > There appears to be a miscommunication of some kind. > Quoting from section 5.2 of draft-ietf-i2rs-archtiecture: > The I2RS Agent will not attempt to retain or reapply state across > routing element reboot. >=20 > I will not attempt to read Jan's mind or provide interpretation. > Rather than taking my word, I suggest you raise this question on the = I2RS mailing list. Either way, it is not an issue for the NETMOD routing model, so I = believe we can proceed to WGLC. Lada >=20 > Yours, > Joel >=20 > On 10/25/13 3:01 PM, Ladislav Lhotka wrote: >>=20 >> On 25 Oct 2013, at 19:21, Joel M. Halpern = wrote: >>=20 >>> I am a bit confused by teh discussion of configuration / persistent = data in this email. >>> I believe the working group agreement with regard to the I2RS = architecture and persistence is that NO i2RS changes persist across = reboot. >>=20 >> This was my original understanding, too, but the authors of the RIB = info model expressed the need for persistent data - routes in = particular. This is an excerpt from the =93minutes=94 of our = teleconference, by Jan: >>=20 >> The current model has clear distinction between config and = operational >> data. If i2rs wants to use the data model it needs to define a yang >> extension identifying data as read-write as opposed to read-only. = This >> will work well for ephemeral data. For persistent data, use the = config >> tree to add static routes - but a static route entry has to have = almost >> all (or all?) the attributes that an ephemeral route entry has. >>=20 >> Lada >>=20 >>>=20 >>> Yours, >>> Joel M. Halpern >>>=20 >>> On 10/24/13 8:38 AM, Ladislav Lhotka wrote: >>>> Hi, >>>>=20 >>>> I am sending more details about the recent changes in the routing = draft. Most of them follow from the discussion with I2RS people (Jan = Medved, Nitin Bahadur, Sriganesh Kini, and Hariharan Ananthakrishnan). = Besides email exchange, we also had a teleconference. >>>>=20 >>>> The basic plan lies in the following correspondence: >>>>=20 >>>> | I2RS | NETCONF/YANG | >>>> |-----------------+------------------------| >>>> | ephemeral data | operational state data | >>>> | persistent data | configuration | >>>>=20 >>>> It means that I2RS agents will be able to read and write (parts of) = what is operational state data in the NETCONF sense, but any such = changes will not survive reboot. To make persistent changes, I2RS agents = will write NETCONF configuration datastore(s). It is an open question = whether I2RS agent will be able to act as a compliant NETCONF client, = with regard to locks etc. >>>>=20 >>>> The motivation and reasoning behind the main changes is the = following: >>>>=20 >>>> o Migrated address families from IANA enumerations to = identities. >>>>=20 >>>> I2RS people strongly preferred identities to the IANA enumerations. = Meanwhile, a discussion in this list also turned out in favour of = identities, so I decided to bite the bullet, and there is now only one = identityref leaf specifying an address family instead of two (AFN and = SAFI), which is IMO a positive change. >>>>=20 >>>> o Terminology and node names aligned with the I2RS RIB model: = router >>>> -> routing instance, routing table -> RIB. >>>>=20 >>>> I2RS WG are the domain experts, so it makes sense to follow suit. >>>>=20 >>>> o Introduced uint64 keys for state lists: routing-instance, = rib, >>>> route, nexthop. >>>>=20 >>>> The idea is that an I2RS client creates an entry (e.g. a route) and = gets back a unique numeric handle that can be used later for referring = to that entry. Modelling these handles as keys of operational state = lists then seems quite natural. >>>>=20 >>>> o Feature "user-defined-routing-tables" changed into "advanced- >>>> router". >>>>=20 >>>> I didn't want to introduce more features, I think the distinction = between a basic and advanced router should be sufficient. >>>>=20 >>>> o Made nexthop into a choice in order to allow for nexthop-list >>>> (I2RS requirement). >>>>=20 >>>> o Added nexthop-list with entries having priorities (backup) = and >>>> weights (load balancing). >>>>=20 >>>> The last two changes implement multipath routes that are crucial = for I2RS. Both are bound to the feature "advanced-router", so simple = devices needn't bother with it. >>>>=20 >>>> Lada >>>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >>=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Thu Oct 31 12:01:23 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77EF511E837E for ; Thu, 31 Oct 2013 12:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 17UUKXMeoGzM for ; Thu, 31 Oct 2013 12:01:17 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id D0BD111E8331 for ; Thu, 31 Oct 2013 12:00:39 -0700 (PDT) Received: from localhost (unknown [193.12.34.23]) by mail.tail-f.com (Postfix) with ESMTPSA id 963A312000B3; Thu, 31 Oct 2013 20:00:38 +0100 (CET) Date: Thu, 31 Oct 2013 20:00:37 +0100 (CET) Message-Id: <20131031.200037.317939079.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <0840D035-DF82-4436-85DC-8DA59D414BB7@nic.cz> <20131025.192445.290343408.mbj@tail-f.com> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-yang-xpath-extensions-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 19:01:23 -0000 Hi, Andy Bierman wrote: > On Fri, Oct 25, 2013 at 10:24 AM, Martin Bjorklund wrote: > > > Ladislav Lhotka wrote: > > > > > > On 25 Oct 2013, at 17:01, Martin Bjorklund wrote: > > > > > > > Ladislav Lhotka wrote: > > > >> If the server doesn't advertise the "ietf-yang-xpath-extensions" > > module, can > > > >> other advertized modules still use new XPath functions in "must" and > > "when", > > > >> if > > > >> they import that module? > > > > > > > > Yes. Note that all XPath expressions are conceptual. If a server > > > > claims that it implements a module that uses such an xpath function, > > > > it must implement the contraint somehow. It doesn't have to use an > > > > XPath evaluator; it can be implemented in code - just like ane > > > > constraints defined in description statements. > > > > > > Yes, but one has to be careful with revisions - sec. 10 in RFC 6020 > > allows new > > > extensions in an updated module, but I think in this case it could be > > dangerous > > > because the server cannot easily ignore unknown functions appearing in > > XPath > > > expressions. > > > > You typcially do not just load a new module into a server; it needs > > some instrumentation to be useful. So a new revison that uses some > > new XPath functions or not needs an implemention effort in the > > server. > > > > > A YANG compiler that checks XPath can understand the xpath-function > statement > and validate the XPath, even without instrumentation. > > Some more comments: > > sec 2 is a bit thin. It should say the entire normative deefinition > is in the YANG module, not sec. 2. Ok. > The document order of the xpath-argument statement is significant, > since XPath functions are passed an ordered parameter list. Yes, this should be clarified. > IMO the extension statements should be in a separate module > because they will be stable. The library of external xpath-function\ > statements is not likely to be stable. Hopefully the function set defined here will be quite stable; it is intended to define functions for core YANG features. Functions related to other features should be defined in specific modules. > This document has the mandatory set of XPath functions, > so WG consensus will be needed. The current set is somewhat limited. This was intentional... > I am not sure this example does what it says: > > leaf mgmt-interface { > type leafref { > path "/interface/name"; > } > must 'yangxp:deref(.)/../enabled = "true"' { > error-message > "The management interface cannot be disabled."; > } > } > > The must-expr says that at least 1 interface (derived from the nodeset > of /interface/name leafs) must be enabled. It does not say the interface > indicated by the value of mgmt-interface must be enabled. > The path-expr is "/interface/name" not > "/interface/name[.=current()]". So I have to explain this better. The idea is that deref(X) follows whatever X points to. If 'mgmt-interface' is "eth0", deref(mgmt-interface) returns the node set with the node /interface[name="eth0"]. I also now realize that this example is a bit too simplistic; deref() makes more sense when these are multiple connected leafrefs. deref() is actually just syntactic sugar; the same thing can be done with normal path expressions, but it can become pretty complex. I will try to explain this better in the draft, and add another example. /martin