From dromasca@avaya.com Wed May 1 01:45: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 D7C0921F8E2C for ; Wed, 1 May 2013 01:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.513 X-Spam-Level: X-Spam-Status: No, score=-103.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, 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 qpP5g61rMsw6 for ; Wed, 1 May 2013 01:45:35 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 624CA21F8E4E for ; Wed, 1 May 2013 01:45:35 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAAH/ZlGHCzI1/2dsb2JhbABQgmUhwX6BBxZ0gh8BAQEBAxIoPwwEAgEIDQEHDRQFBAcyFBECBAENBQgTB4dyAaBHnSOOZSYLB4JgYQOdKYpogVWBNoIo X-IronPort-AV: E=Sophos;i="4.87,456,1363147200"; d="scan'208";a="9378366" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 01 May 2013 04:45:34 -0400 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 01 May 2013 04:42:12 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.02.0328.009; Wed, 1 May 2013 04:45:33 -0400 From: "Romascanu, Dan (Dan)" To: Martin Bjorklund , "bclaise@cisco.com" Thread-Topic: [netmod] Last Call: (A YANG Data Model for Interface Management) to Proposed Standard Thread-Index: AQHORYx1iQbr9cfI2ECu413TKNMZEpju3bOAgAAGR4CAASAU0A== Date: Wed, 1 May 2013 08:45:32 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA0D9840@AZ-FFEXMB04.global.avaya.com> References: <20130427.093659.369612374.mbj@tail-f.com> <20130430.122049.1111664509032933339.mbj@tail-f.com> <517FA5E3.2010604@cisco.com> <20130430.132943.828559691589933098.mbj@tail-f.com> In-Reply-To: <20130430.132943.828559691589933098.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ietfdbh@comcast.net" , "netmod@ietf.org" Subject: Re: [netmod] Last Call: (A YANG Data Model for Interface Management) to Proposed Standard 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, 01 May 2013 08:45:41 -0000 Hi, See in-line.=20 Regards, Dan > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf > Of Martin Bjorklund >=20 > > - what should an NM application or operator do if the YANG > > oper-status > > - and the IF-MIB operStatus differ? >=20 > I need help also with this one. I do not understand the problem, so I > cannot suggest a solution :( >=20 [[DR]] The problem is that if both NETCONF and SNMP implementations exist o= n the device and the operator reads both, he needs an indication about what= takes precedence in case of inconsistency. > > - persistence >=20 > I don't think this document is the right place to describe the > persistency model for SNMP vs. NETCONF - if we do it here we probably > have to do it in all other data-model specific documents as well... >=20 [[DR]]this is not an SNMP vs. NETCONF discussion, this is a specific data-m= odel specification to understand what objects in the specific data model mu= st be kept persistent. And yes, all data-model documents should specify thi= s, if they do not the assumption is that all is lost on reboot (if this is = not written some place it should be IMO) =20 From j.schoenwaelder@jacobs-university.de Wed May 1 02:06: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 8D05321F84B0 for ; Wed, 1 May 2013 02:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZCObdwZyx-v for ; Wed, 1 May 2013 02:06:27 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 563B221F8E98 for ; Wed, 1 May 2013 02:06:27 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 549D420C57; Wed, 1 May 2013 11:06:26 +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 1p0x8qzXslXp; Wed, 1 May 2013 11:06:26 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6EAE120BEB; Wed, 1 May 2013 11:06:25 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C11A625ED435; Wed, 1 May 2013 11:06:23 +0200 (CEST) Date: Wed, 1 May 2013 11:06:23 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20130501090622.GA2364@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , Martin Bjorklund , "bclaise@cisco.com" , "ietfdbh@comcast.net" , "netmod@ietf.org" References: <20130427.093659.369612374.mbj@tail-f.com> <20130430.122049.1111664509032933339.mbj@tail-f.com> <517FA5E3.2010604@cisco.com> <20130430.132943.828559691589933098.mbj@tail-f.com> <9904FB1B0159DA42B0B887B7FA8119CA0D9840@AZ-FFEXMB04.global.avaya.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA0D9840@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "ietfdbh@comcast.net" , "netmod@ietf.org" Subject: Re: [netmod] Last Call: (A YANG Data Model for Interface Management) to Proposed Standard 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, 01 May 2013 09:06:32 -0000 On Wed, May 01, 2013 at 08:45:32AM +0000, Romascanu, Dan (Dan) wrote: > Hi, > > See in-line. > > Regards, > > Dan > > > > > > -----Original Message----- > > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf > > Of Martin Bjorklund > > > > > - what should an NM application or operator do if the YANG > > > oper-status > > > - and the IF-MIB operStatus differ? > > > > I need help also with this one. I do not understand the problem, so I > > cannot suggest a solution :( > > > [[DR]] The problem is that if both NETCONF and SNMP implementations exist on the device and the operator reads both, he needs an indication about what takes precedence in case of inconsistency. We can only recommend to file a bug report to the vendor in this case. SNMP and NETCONF are both protocol to access the state of the interface (as does the CLI, the Web UI, or even IPFIX for some data objects). If things are not consistent, then there is a bug in the way these interfaces access the instrumentation. I think it is difficult to standardize which access methos is right if such a bug exists. /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 Wed May 1 07:55:22 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 6DD5021F96AC for ; Wed, 1 May 2013 07:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqSvpSiB8iwV for ; Wed, 1 May 2013 07:55:22 -0700 (PDT) Received: from mail-ia0-x230.google.com (mail-ia0-x230.google.com [IPv6:2607:f8b0:4001:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id CE9CB21F9666 for ; Wed, 1 May 2013 07:55:21 -0700 (PDT) Received: by mail-ia0-f176.google.com with SMTP id l27so1417883iae.35 for ; Wed, 01 May 2013 07:55:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=k7k4QdU4YTjS4+eEDHOkJYYk/H+sDIEJaGGpcKMjH+8=; b=LRh3Z+95w6EMGjk+cSDj+YiRvaiBhBZVqdq/9F014OYqvHpNyabwnHWU5FbP4s0Agy QW8KnGvicO7nS+83XZtLffWBES3mTc/YBUjdC4ELm14n7PI7AnEzqHyUxUx5ESvpT88K Am6Ltkdr2FwEIu2YHsfixCGVAgR/jPVf9Nn9IIy8PZYUzRWE0HVB41HZDSuJGyC3TaFm ljIaS1nZcangCIKBqH6FQom3hbchScPgPjLqAL8+V0sV8gih80yb1B0WgMiTjlsWWqDx SqpTApMDHZelp3E5ZXIR4lMzAEIDFjF/h91Yyq6V+hj4K71H294X0NCACzPeexghXWm6 iHFA== MIME-Version: 1.0 X-Received: by 10.50.170.36 with SMTP id aj4mr6625177igc.67.1367420120775; Wed, 01 May 2013 07:55:20 -0700 (PDT) Received: by 10.231.125.202 with HTTP; Wed, 1 May 2013 07:55:20 -0700 (PDT) In-Reply-To: <20130501090622.GA2364@elstar.local> References: <20130427.093659.369612374.mbj@tail-f.com> <20130430.122049.1111664509032933339.mbj@tail-f.com> <517FA5E3.2010604@cisco.com> <20130430.132943.828559691589933098.mbj@tail-f.com> <9904FB1B0159DA42B0B887B7FA8119CA0D9840@AZ-FFEXMB04.global.avaya.com> <20130501090622.GA2364@elstar.local> Date: Wed, 1 May 2013 07:55:20 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , "Romascanu, Dan (Dan)" , Martin Bjorklund , "bclaise@cisco.com" , "ietfdbh@comcast.net" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=e89a8f234a518ece1c04dba94ead X-Gm-Message-State: ALoCoQl/adouLD8FF9aXFLo+gDf/Kud5Svnbj7zJnIp0Cz7pCOrFkHw30ubnD9PXSEb6SbGRRDBf Subject: Re: [netmod] Last Call: (A YANG Data Model for Interface Management) to Proposed Standard 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, 01 May 2013 14:55:22 -0000 --e89a8f234a518ece1c04dba94ead Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 1, 2013 at 2:06 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, May 01, 2013 at 08:45:32AM +0000, Romascanu, Dan (Dan) wrote: > > Hi, > > > > See in-line. > > > > Regards, > > > > Dan > > > > > > > > > > > -----Original Message----- > > > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On > Behalf > > > Of Martin Bjorklund > > > > > > > - what should an NM application or operator do if the YANG > > > > oper-status > > > > - and the IF-MIB operStatus differ? > > > > > > I need help also with this one. I do not understand the problem, so I > > > cannot suggest a solution :( > > > > > [[DR]] The problem is that if both NETCONF and SNMP implementations > exist on the device and the operator reads both, he needs an indication > about what takes precedence in case of inconsistency. > > We can only recommend to file a bug report to the vendor in this case. > > SNMP and NETCONF are both protocol to access the state of the > interface (as does the CLI, the Web UI, or even IPFIX for some data > objects). If things are not consistent, then there is a bug in the way > these interfaces access the instrumentation. I think it is difficult > to standardize which access methos is right if such a bug exists. > > +1 Apply to comments about IF-MIB counter deltas not matching as well. /js > > Andy --e89a8f234a518ece1c04dba94ead Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, May 1, 2013 at 2:06 AM, Juergen = Schoenwaelder <j.schoenwaelder@jacobs-university.de= > wrote:
On Wed, May 01, 2013 at 08:45:32AM +0000, Ro= mascanu, Dan (Dan) wrote:
> Hi,
>
> See in-line.
>
> Regards,
>
> Dan
>
>
>
>
> > -----Original Message-----
> > From: netmod-bounces@i= etf.org [mailto:netmod-bounc= es@ietf.org] On Behalf
> > Of Martin Bjorklund
> >
> > > - =A0what should an NM application or operator do if the YAN= G
> > > oper-status
> > > - =A0and the IF-MIB operStatus differ?
> >
> > I need help also with this one. =A0I do not understand the proble= m, so I
> > cannot suggest a solution :(
> >
> [[DR]] The problem is that if both NETCONF and SNMP implementations ex= ist on the device and the operator reads both, he needs an indication about= what takes precedence in case of inconsistency.

We can only recommend to file a bug report to the vendor in this case.

SNMP and NETCONF are both protocol to access the state of the
interface (as does the CLI, the Web UI, or even IPFIX for some data
objects). If things are not consistent, then there is a bug in the way
these interfaces access the instrumentation. I think it is difficult
to standardize which access methos is right if such a bug exists.


+1
Apply to comments about IF-MIB counter = deltas not matching as well.=A0

/js



Andy
=A0
--e89a8f234a518ece1c04dba94ead-- From lhotka@nic.cz Wed May 1 08:48: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 BD0A721F9A47 for ; Wed, 1 May 2013 08:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[AWL=0.043, 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 rJLlWDPxO1r0 for ; Wed, 1 May 2013 08:48:13 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id EA7E321F9A00 for ; Wed, 1 May 2013 08:48:12 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 230E214085C; Wed, 1 May 2013 17:48:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1367423291; bh=lgMAFZqh4lW2XmqOHWtDNi4pf4O1g+0mAydguaS5iFY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=tMjwixG9BmbhS41espwFtJuM9VaDBDUCgoPwGSDAyJqHVuj7kkgKavYo7SNocitoe zPM0jPzpbi/vDK8+J2tfMjtI+ISmddwQxuVOxBTZ5wYevMhk6SgUCuI/Rwwy1/rfvP RqrCG2YSZUt7EsaDcxbrKolheyrgz+LwxpIObOmo= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ladislav Lhotka In-Reply-To: <20130501090622.GA2364@elstar.local> Date: Wed, 1 May 2013 17:48:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3755872E-471B-45B8-B330-795A7DB71966@nic.cz> References: <20130427.093659.369612374.mbj@tail-f.com> <20130430.122049.1111664509032933339.mbj@tail-f.com> <517FA5E3.2010604@cisco.com> <20130430.132943.828559691589933098.mbj@tail-f.com> <9904FB1B0159DA42B0B887B7FA8119CA0D9840@AZ-FFEXMB04.global.avaya.com> <20130501090622.GA2364@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1503) X-Virus-Scanned: clamav-milter 0.97.7 at mail X-Virus-Status: Clean Cc: "ietfdbh@comcast.net" , "netmod@ietf.org" Subject: Re: [netmod] Last Call: (A YANG Data Model for Interface Management) to Proposed Standard 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, 01 May 2013 15:48:13 -0000 On May 1, 2013, at 11:06 AM, Juergen Schoenwaelder = wrote: > On Wed, May 01, 2013 at 08:45:32AM +0000, Romascanu, Dan (Dan) wrote: >> Hi, >>=20 >> See in-line.=20 >>=20 >> Regards, >>=20 >> Dan >>=20 >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On = Behalf >>> Of Martin Bjorklund >>>=20 >>>> - what should an NM application or operator do if the YANG >>>> oper-status >>>> - and the IF-MIB operStatus differ? >>>=20 >>> I need help also with this one. I do not understand the problem, so = I >>> cannot suggest a solution :( >>>=20 >> [[DR]] The problem is that if both NETCONF and SNMP implementations = exist on the device and the operator reads both, he needs an indication = about what takes precedence in case of inconsistency. >=20 > We can only recommend to file a bug report to the vendor in this case. >=20 > SNMP and NETCONF are both protocol to access the state of the > interface (as does the CLI, the Web UI, or even IPFIX for some data > objects). If things are not consistent, then there is a bug in the way > these interfaces access the instrumentation. I think it is difficult > to standardize which access methos is right if such a bug exists. Perhaps what's really needed is to properly model the state of the = interface, hence operational state. And since nothing more clever has = been invented yet, I think it is necessary to face the duplication and = have separate subtrees for operational state and config. The former = would be managed by the device and the latter by the client (as a sort = of recipe for changing the operational state). In particular, a list of = interfaces would be present in either subtree. The mapping of any MIB objects would then aim exclusively at the = operational state subtree. Lada =20 >=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 May 1 09:39: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 AF4BE21F9A57 for ; Wed, 1 May 2013 09:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uLxZRQrcxgn for ; Wed, 1 May 2013 09:39:52 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 644CF21F9A6F for ; Wed, 1 May 2013 09:39:52 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 674E020C4D; Wed, 1 May 2013 18:39:51 +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 bYXWUTxnTzgv; Wed, 1 May 2013 18:39:51 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8DA3D20C4C; Wed, 1 May 2013 18:39:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 14A3E25EDE58; Wed, 1 May 2013 18:39:48 +0200 (CEST) Date: Wed, 1 May 2013 18:39:48 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20130501163948.GA3435@elstar.local> Mail-Followup-To: Ladislav Lhotka , "Romascanu, Dan (Dan)" , "ietfdbh@comcast.net" , "netmod@ietf.org" References: <20130427.093659.369612374.mbj@tail-f.com> <20130430.122049.1111664509032933339.mbj@tail-f.com> <517FA5E3.2010604@cisco.com> <20130430.132943.828559691589933098.mbj@tail-f.com> <9904FB1B0159DA42B0B887B7FA8119CA0D9840@AZ-FFEXMB04.global.avaya.com> <20130501090622.GA2364@elstar.local> <3755872E-471B-45B8-B330-795A7DB71966@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3755872E-471B-45B8-B330-795A7DB71966@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "ietfdbh@comcast.net" , "netmod@ietf.org" Subject: Re: [netmod] Last Call: (A YANG Data Model for Interface Management) to Proposed Standard 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, 01 May 2013 16:39:57 -0000 On Wed, May 01, 2013 at 05:48:10PM +0200, Ladislav Lhotka wrote: > > We can only recommend to file a bug report to the vendor in this case. > > > > SNMP and NETCONF are both protocol to access the state of the > > interface (as does the CLI, the Web UI, or even IPFIX for some data > > objects). If things are not consistent, then there is a bug in the way > > these interfaces access the instrumentation. I think it is difficult > > to standardize which access methos is right if such a bug exists. > > Perhaps what's really needed is to properly model the state of the interface, hence operational state. And since nothing more clever has been invented yet, I think it is necessary to face the duplication and have separate subtrees for operational state and config. The former would be managed by the device and the latter by the client (as a sort of recipe for changing the operational state). In particular, a list of interfaces would be present in either subtree. > > The mapping of any MIB objects would then aim exclusively at the operational state subtree. > We are talking about a config false object here. It has the same enumeration as the MIB object. I do not understand your comment. /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 May 1 23: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 5158521F9948 for ; Wed, 1 May 2013 23:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.601 X-Spam-Level: * X-Spam-Status: No, score=1.601 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_210=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_28=0.6, J_CHICKENPOX_29=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 6ydLvPLmVZSF for ; Wed, 1 May 2013 23:02:11 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 86F6121F993C for ; Wed, 1 May 2013 23:02:07 -0700 (PDT) Received: from [192.168.42.41] (89-24-17-96.i4g.tmcz.cz [89.24.17.96]) by mail.nic.cz (Postfix) with ESMTPSA id 23AF413F95A; Thu, 2 May 2013 08:01:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1367474526; bh=nre146EliUTLSfKOXrcNIGrKqBzlZGwJD0xc9f7c6Rg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=WJ2QV2W8QzZEOkp0dAKJzfAUhSPEg0mKB7r6SLlxcjEHajaC20foteXxlvge1r+S7 T5SwAGB2L81Hm0fftTecsq6gi4z7EbWfWYvOI0mprsmC9j8j5ZAc9LMOEs/FjRRlIa E2rELA3J4vbMI6etFDZMFIl2dS9HKSDxpoqkJBTE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ladislav Lhotka In-Reply-To: <20130501163948.GA3435@elstar.local> Date: Thu, 2 May 2013 08:01:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2DD17965-E5C6-40FE-AA49-A3E3E4876D93@nic.cz> References: <20130427.093659.369612374.mbj@tail-f.com> <20130430.122049.1111664509032933339.mbj@tail-f.com> <517FA5E3.2010604@cisco.com> <20130430.132943.828559691589933098.mbj@tail-f.com> <9904FB1B0159DA42B0B887B7FA8119CA0D9840@AZ-FFEXMB04.global.avaya.com> <20130501090622.GA2364@elstar.local> <3755872E-471B-45B8-B330-795A7DB71966@nic.cz> <20130501163948.GA3435@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1503) X-Virus-Scanned: clamav-milter 0.97.7 at mail X-Virus-Status: Clean Cc: "ietfdbh@comcast.net" , "netmod@ietf.org" Subject: Re: [netmod] Last Call: (A YANG Data Model for Interface Management) to Proposed Standard 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, 02 May 2013 06:02:13 -0000 On May 1, 2013, at 6:39 PM, Juergen Schoenwaelder = wrote: > On Wed, May 01, 2013 at 05:48:10PM +0200, Ladislav Lhotka wrote: >>> We can only recommend to file a bug report to the vendor in this = case. >>>=20 >>> SNMP and NETCONF are both protocol to access the state of the >>> interface (as does the CLI, the Web UI, or even IPFIX for some data >>> objects). If things are not consistent, then there is a bug in the = way >>> these interfaces access the instrumentation. I think it is difficult >>> to standardize which access methos is right if such a bug exists. >>=20 >> Perhaps what's really needed is to properly model the state of the = interface, hence operational state. And since nothing more clever has = been invented yet, I think it is necessary to face the duplication and = have separate subtrees for operational state and config. The former = would be managed by the device and the latter by the client (as a sort = of recipe for changing the operational state). In particular, a list of = interfaces would be present in either subtree. >>=20 >> The mapping of any MIB objects would then aim exclusively at the = operational state subtree. >>=20 >=20 > We are talking about a config false object here. It has the same > enumeration as the MIB object. I do not understand your comment. Some operational state data for an interface should be present even = without any configuration. In the current model, the operational state = data are not present unless the corresponding entry in the "interface" = list is *configured*. So, what I have in mind is a data tree like this: +--rw configuration | +--rw if:interfaces | +--rw if:interface [name] | +--rw if:name string | +--rw if:description? string | +--rw if:type? ianaift:iana-if-type | +--rw if:enabled? boolean | +--rw if:link-up-down-trap-enabled? boolean +--ro operational-state +--ro if:interfaces +--ro if:interface [name] +--ro if:name string +--ro if:description? string +--ro if:type ianaift:iana-if-type +--ro if:location? string +--ro if:oper-status enumeration +--ro if:last-change yang:date-and-time +--ro if:if-index int32 +--ro if:link-up-down-trap-enabled boolean +--ro if:phys-address yang:phys-address +--ro if:higher-layer-if* interface-ref +--ro if:lower-layer-if* interface-ref +--ro if:speed yang:gauge64 +--ro if:statistics +--ro if:discontinuity-time yang:date-and-time +--ro if:in-octets yang:counter64 +--ro if:in-unicast-pkts yang:counter64 +--ro if:in-broadcast-pkts yang:counter64 +--ro if:in-multicast-pkts yang:counter64 +--ro if:in-discards yang:counter32 +--ro if:in-errors yang:counter32 +--ro if:in-unknown-protos yang:counter32 +--ro if:out-octets yang:counter64 +--ro if:out-unicast-pkts yang:counter64 +--ro if:out-broadcast-pkts yang:counter64 +--ro if:out-multicast-pkts yang:counter64 +--ro if:out-discards yang:counter32 +--ro if:out-errors yang:counter32 Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Wed May 1 23:40: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 E290321F9944 for ; Wed, 1 May 2013 23:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[AWL=-0.091, 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 L05p2oiQnYaR for ; Wed, 1 May 2013 23:40:43 -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 06DF721F9942 for ; Wed, 1 May 2013 23:40:42 -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 C0DBB1200DA1; Thu, 2 May 2013 08:40:40 +0200 (CEST) Date: Thu, 02 May 2013 08:40:40 +0200 (CEST) Message-Id: <20130502.084040.999899373393431650.mbj@tail-f.com> To: ietfdbh@comcast.net From: Martin Bjorklund In-Reply-To: <036001ce46ad$aed16c90$0c7445b0$@comcast.net> References: <20130430.132943.828559691589933098.mbj@tail-f.com> <9904FB1B0159DA42B0B887B7FA8119CA0D9840@AZ-FFEXMB04.global.avaya.com> <036001ce46ad$aed16c90$0c7445b0$@comcast.net> 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] Last Call: (A YANG Data Model for Interface Management) to Proposed Standard 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, 02 May 2013 06:40:49 -0000 "ietfdbh" wrote: > > I don't think this document is the right place to describe the > > persistency model for SNMP vs. NETCONF - if we do it here we probably > > have to do it in all other data-model specific documents as well... > > > > [[DR]]this is not an SNMP vs. NETCONF discussion, this is a specific > data-model specification to understand what objects in the specific data > model must be kept persistent. And yes, all data-model documents should > specify this, if they do not the assumption is that all is lost on reboot > (if this is not written some place it should be IMO) > > > [dbh>] I think the data model should specify the persistence of the data > objects in this model, most notably the config objects. Does each config > object persist across system reboots? Do some objects persist but > not all? In NETCONF, the persistency of the configuration nodes are not a property of the node itself, but a property of the datastore in which the node exists. So it would be wrong to state that e.g., 'description' MUST be persistently stored across reboots - this is not true for 'running' on a device that supports 'startup'; but it is true for 'startup'. > Is each YANG counter reinitialized on reboot, or are they expected to > persist across reboots? This is already specified in the document. /martin From martin.thomson@gmail.com Tue Apr 30 12:29: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 39DD021F984B; Tue, 30 Apr 2013 12:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 0VkAPh2Ep2CC; Tue, 30 Apr 2013 12:29:32 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2B66E21F992E; Tue, 30 Apr 2013 12:29:02 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id m15so831870wgh.5 for ; Tue, 30 Apr 2013 12:29:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=SA1BqMG1R8xDriSJQbUH5xR7wT9S25vujE/zleBuWS8=; b=a8uFymPea6P+YprXtI1ruGjnh4CMkh/LijzfMySq3V0cjS1a4tSlc5QqfYsy4HEYO2 2Xu3Y7xwgtyzI7IxYbthCO6VmZl8J3C5LodyRXpE3uTOOH7r5E/7Oj5wR6w9uTDuRkBA +yKZkSQY34voTaEPXp99YgCiFDH+ScMCgRBaejdzpCIH7U6P6okoMxlS0mF45YNRJ4C0 TNWOup5+kJdCpdHANxLcedWwWd5CT7UQJ0PURZX3oJkbDCDvhjrNPwk/7W5eqW52r/II +h8oRtJ0qd7JrGKq4VSXoyn18ux8yvWNYgjvBbQaqURBwVqUF8l7k2r2ivoXLIF8zw0p g3tw== MIME-Version: 1.0 X-Received: by 10.194.109.227 with SMTP id hv3mr41538571wjb.32.1367350142347; Tue, 30 Apr 2013 12:29:02 -0700 (PDT) Received: by 10.194.33.102 with HTTP; Tue, 30 Apr 2013 12:29:02 -0700 (PDT) In-Reply-To: <20130430083206.GD46852@elstar.local> References: <6.2.5.6.2.20130428233426.0b62fed0@elandnews.com> <20130430083206.GD46852@elstar.local> Date: Tue, 30 Apr 2013 12:29:02 -0700 Message-ID: From: Martin Thomson To: Juergen Schoenwaelder , Martin Thomson , IETF Apps Discuss , draft-ietf-netmod-rfc6021-bis.all@tools.ietf.org, The IESG , netmod@ietf.org Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Thu, 02 May 2013 00:27:43 -0700 Subject: Re: [netmod] [appsdir] Fwd: APPSDIR review of draft-ietf-netmod-rfc6021-bis-01 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, 30 Apr 2013 19:29:34 -0000 One meta-comment. I don't consider the contents of RFC 6021 to have any bearing on the review of this document. I'm not familiar with 6021, so I consider all of this to be new. On 30 April 2013 01:32, Juergen Schoenwaelder wrote: >> There is an RFC that describes a canonical textual representation of >> IPv6 addresses. You should use that: RFC 5952. > > The typedef ipv6-address has a reference to RFC 5952. I believe the > text in the description statement is inline with RFC 5952. Note that > this text did not change since RFC 6021 (and other than clarifications > we likely do not want changes). That's unfortunate because I can't tell whether RFC 5952 and the following are the same very easily: "The canonical format of IPv6 addresses uses the compressed format described in RFC 4291, Section 2.2, item 2 with the following additional rules: the :: substitution must be applied to the longest sequence of all-zero 16-bit chunks in an IPv6 address. If there is a tie, the first sequence of all-zero 16-bit chunks is replaced by ::. Single all-zero 16-bit chunks are not compressed. The canonical format uses lowercase characters and leading zeros are not allowed. The canonical format for the zone index is the numerical format as described in RFC 4007, Section 11.2." Suggest: "The canonical format of IPv6 addresses is described in RFC5952; the canonical form of the zone index is described in RFC 4007, Section 11.2." Adding something to references is not the same as providing normative text that stipulates how the information is intended to be consumed. If the intent is to have the reference as normative, informative references are fine as disassociated links. >> domain-name doesn't mention RFC 5890 at all (5891 is cited, but not >> used in the text). I assume that these are LDH-labels: >> http://tools.ietf.org/html/rfc5890#section-2.3.1 and that this >> document should say as much. > > I am not sure what you think is unclear. Note that the definition of > the typedef domain-name is unchanged from the one in RFC 6021. Perhaps > you can make a concrete text change proposal so I better understand > what your concern is. The pattern for domain-name implies LDH label, however the textual description does not. OLD: Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice in domain name use, and some possible future expansion. It is designed to hold various types of domain names, including names used for A or AAAA records (host names) and other records, such as SRV records. Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-name type are recommended to adhere to this stricter standard to ensure interoperability. NEW: "A domain-name MUST consist of LDH-labels as defined in RFC 5890. Note: If fields of this type are used to store host names [RFC0952], host names use a stricter syntax. Systems that store host names SHOULD enforce stronger restrictions or use a derived type for host names." >> phys-address: why is this optionally empty? Maybe explain why in the >> document - value absent? > > The primary reason is to be consistent with the PhysAddress textual > convention of RFC 2579. Note that this definition did not change since > RFC 6021. What an empty address means needs to be defined where the > type is used. I do not think we can regulate that in the type > definition itself. All we could do is add a 'warning' that this type > allows zero-length strings as values and hence users of this type > either need to subtype this type or explain the semantics of a > zero-length string. Yes, either would be nice, but I'm not that concerned about these. I prefer to see such surprises explained in some way. e.g., "phys-address permits an empty string to so that the textual convention established in RFC 2579 can be used. An empty string has no defined semantics here, subtypes SHOULD either assign semantics to this value or eliminate it." >> hex-string: why is this required to include at least one octet? The >> text does not mention this at all, I tend to find lots of uses for >> empty octet strings, so this seems odd. > > I will take this to the WG. Note that in YANG you often use choices to > model situations where in other frameworks you give special meanings > to say zero-length strings. > ipv6 pattern > Note sure what the "official" ABNF definition is but we believe that > the two pattern are correct. So far nobody was able to find a case > that was not properly accepted by the pattern. You are welcome to try > to find something where our two pattern break. ;-) Sorry, "official" is my shorthand for saying: there is an RFC out there that defines this ABNF but I was too lazy to go and look for it because I know that chances are I will find the wrong one. The first pattern is overly restrictive, I think (only double colon at the start?). The second is definitely overly permissive. This:sentence:is::actually:valid. (I think). > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From ietfdbh@comcast.net Wed May 1 13:52: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 4F83221F96FA for ; Wed, 1 May 2013 13:52:03 -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=[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 r5ijZnQYgb1h for ; Wed, 1 May 2013 13:51:55 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 75C0121F8EBB for ; Wed, 1 May 2013 13:51:40 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta03.westchester.pa.mail.comcast.net with comcast id Wa0G1l0031YDfWL53krfs3; Wed, 01 May 2013 20:51:39 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta20.westchester.pa.mail.comcast.net with comcast id Wkrf1l00A2yZEBF3gkrffF; Wed, 01 May 2013 20:51:39 +0000 From: "ietfdbh" To: "'Romascanu, Dan \(Dan\)'" , "'Martin Bjorklund'" , References: <20130427.093659.369612374.mbj@tail-f.com> <20130430.122049.1111664509032933339.mbj@tail-f.com> <517FA5E3.2010604@cisco.com> <20130430.132943.828559691589933098.mbj@tail-f.com> <9904FB1B0159DA42B0B887B7FA8119CA0D9840@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA0D9840@AZ-FFEXMB04.global.avaya.com> Date: Wed, 1 May 2013 16:51:41 -0400 Message-ID: <036001ce46ad$aed16c90$0c7445b0$@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: AQDrDAR3fV+FKxeqH+Ujl8JAf9AEDQE5/9A/AYnJQ2QCTm94SwGrscV5moFLn4A= Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367441499; bh=DBUaHshhWCgMo+Jc50pxNpoKylpT2o7MrG/bX0Wd2+s=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=FGLHv7CVUXr6gdkgvXwPnjrr5u8tCesJRQ2fS9huryPaJ6PBTsQ5QZ7JkZy5XBKZI 9veeAhhA3TWMpqGTI/EH/a0KNNbRuqu53YKMkUhPArXUuu3C9rGfenLElF4eYQy47H vwGX6jVJaO9AC5mTsKprIlTYvu8nWQCd9CW09nyFK6tvgNwgWDPW6BiWc782Mvw8Gk Bii9ntoqV6kPPvaS1aL0xMw4AZzWky/p3yQsRO/YehGv1ww5Cxq1hGJ7fX0O34KeK0 G8/cjCEN7TyCtKfUOeLzi2KXJuu1i9yAehmFnqUP+UE3aw4gOJU0q0esrLFfKzhgzp ujq8rKFbm+TFQ== X-Mailman-Approved-At: Thu, 02 May 2013 00:27:43 -0700 Cc: netmod@ietf.org Subject: Re: [netmod] Last Call: (A YANG Data Model for Interface Management) to Proposed Standard 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, 01 May 2013 20:52:11 -0000 Hi, > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On > Behalf Of Martin Bjorklund > > > - what should an NM application or operator do if the YANG > > oper-status > > - and the IF-MIB operStatus differ? > > I need help also with this one. I do not understand the problem, so I > cannot suggest a solution :( > [[DR]] The problem is that if both NETCONF and SNMP implementations exist on the device and the operator reads both, he needs an indication about what takes precedence in case of inconsistency. [dbh>] I think that "what takes precedence?" is not something we can answer in the data model; that will be implementation dependent. I think what is needed is an "operational consideration" that says "the status and counters in SNMP and the status and counters in NETCONF might be different." It could be good to explain that SNMP and NETCONF and CLI counters are typically just front-ends for hardware or OS status/counters (as in Juergen's email explanation). But there is no MUST that says these counters MUST simply be front-ends for hardware/OS counters. For example, as Juergen points out, SNMP counters are sometimes cached. SNMP counters are sometimes cached; CLI counters typically are not; Is it an implementation decision whether NETCONF counters match other counter interfaces? Let's say that someplace. > > - persistence > > I don't think this document is the right place to describe the > persistency model for SNMP vs. NETCONF - if we do it here we probably > have to do it in all other data-model specific documents as well... > [[DR]]this is not an SNMP vs. NETCONF discussion, this is a specific data-model specification to understand what objects in the specific data model must be kept persistent. And yes, all data-model documents should specify this, if they do not the assumption is that all is lost on reboot (if this is not written some place it should be IMO) [dbh>] I think the data model should specify the persistence of the data objects in this model, most notably the config objects. Does each config object persist across system reboots? Do some objects persist but not all? Is each YANG counter reinitialized on reboot, or are they expected to persist across reboots? Some of the YANG counters include a reference to IF-MIB counters. Do the YANG counters match the persistence specified in the corresponding MIB objects? If not, why not? (If this is an SNMP vs NETCONF difference, then is this documented in a NETCONF document someplace?) Having worked for a hardware vendor that also produced NM software, I am aware that sometimes a hardware counter is added to match a MIB standard required by customers. Whether that hardware counter persists often depends on what the standard requires. So if you will develop any YANG counters that are not mirrors of SNMP counters, how does the hardware designer know whether to make it persistent or not? This affects cross-vendor/cross-product interoperability. David Harrington ietfdbh@comcast.net +1-603-828-1401 From lhotka@nic.cz Thu May 2 00: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 3551421F890F for ; Thu, 2 May 2013 00:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.101 X-Spam-Level: * X-Spam-Status: No, score=1.101 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_50=0.001, 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 b6jMJB2BE48r for ; Thu, 2 May 2013 00:33: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 6C22E21F86D3 for ; Thu, 2 May 2013 00:33:46 -0700 (PDT) Received: from [192.168.42.12] (89-24-17-96.i4g.tmcz.cz [89.24.17.96]) by mail.nic.cz (Postfix) with ESMTPSA id 5B29713F7DA for ; Thu, 2 May 2013 09:33:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1367480025; bh=Ur0N80j0eDoE5mw53BXlZnOVJZioYKXW3n5rZ45VpX0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=OPY/CrfoOsvu7sTWqzAMPcAwzx/F1+PJn74Ft0hBpzSQ71L359t754b95Gb6l7tQ4 kJ5hhsbYnGM5u/tJIxBjR+QRqojSNgouDDpHibcqa7QIQYtla3b70c8exfMirz3pPT NzkQtYTJkpAyvAc7qBuRCFnlQV1wgeeCNV03n94I= Content-Type: text/plain; charset=iso-2022-jp Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ladislav Lhotka In-Reply-To: <20130430.103839.1231060720297181226.mbj@tail-f.com> Date: Thu, 2 May 2013 09:33:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130430.103839.1231060720297181226.mbj@tail-f.com> To: netmod@ietf.org X-Mailer: Apple Mail (2.1503) X-Virus-Scanned: clamav-milter 0.97.7 at mail X-Virus-Status: Clean Subject: Re: [netmod] [apps-discuss] Apps Area review of draft-ietf-netmod-interfaces-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: Thu, 02 May 2013 07:33:47 -0000 [switched to NETMOD list] On Apr 30, 2013, at 10:38 AM, Martin Bjorklund wrote: >> 3.1 =1B$B!H=1B(BThe data model for interfaces presented in this = document uses a flat >> list of interfaces.=1B$B!I=1B(B - does this mean that the model in = section 3. should >> have =1B$B!H=1B(Binterface*=1B$B!I=1B(B rather than just = =1B$B!H=1B(Binterface=1B$B!I=1B(B as a child of = =1B$B!H=1B(Binterfaces=1B$B!I=1B(B? >=20 > In this tree diagram, the notion "interface [name]" means that it is a > YANG list, with "name" as key. But what about keyless list, i.e. operational state? They are = indistinguishable from containers, so I'd suggest to append '*' to their = names as well. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Thu May 2 00:42: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 4E27D21F8501; Thu, 2 May 2013 00:42:07 -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, 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 AaTLY0QCoFSg; Thu, 2 May 2013 00:42:02 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id E192121F84FD; Thu, 2 May 2013 00:42:01 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id DEC3720C54; Thu, 2 May 2013 09:42:00 +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 B37oqpB-mZLQ; Thu, 2 May 2013 09:42:00 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 468F020C4B; Thu, 2 May 2013 09:42:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E440025EE922; Thu, 2 May 2013 09:41:57 +0200 (CEST) Date: Thu, 2 May 2013 09:41:57 +0200 From: Juergen Schoenwaelder To: Martin Thomson Message-ID: <20130502074157.GA4935@elstar.local> Mail-Followup-To: Martin Thomson , IETF Apps Discuss , draft-ietf-netmod-rfc6021-bis.all@tools.ietf.org, The IESG , netmod@ietf.org References: <6.2.5.6.2.20130428233426.0b62fed0@elandnews.com> <20130430083206.GD46852@elstar.local> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="pWyiEgJYm5f9v55/" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: draft-ietf-netmod-rfc6021-bis.all@tools.ietf.org, netmod@ietf.org, The IESG , IETF Apps Discuss Subject: Re: [netmod] [appsdir] Fwd: APPSDIR review of draft-ietf-netmod-rfc6021-bis-01 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: Thu, 02 May 2013 07:42:07 -0000 --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Apr 30, 2013 at 12:29:02PM -0700, Martin Thomson wrote: > One meta-comment. I don't consider the contents of RFC 6021 to have > any bearing on the review of this document. I'm not familiar with > 6021, so I consider all of this to be new. But most of the definitions are not new and I am reluctant to make changes to published RFC text. [...] > > ipv6 pattern > > Note sure what the "official" ABNF definition is but we believe that > > the two pattern are correct. So far nobody was able to find a case > > that was not properly accepted by the pattern. You are welcome to try > > to find something where our two pattern break. ;-) > > Sorry, "official" is my shorthand for saying: there is an RFC out > there that defines this ABNF but I was too lazy to go and look for it > because I know that chances are I will find the wrong one. > > The first pattern is overly restrictive, I think (only double colon at > the start?). The second is definitely overly permissive. > This:sentence:is::actually:valid. (I think). Please give me an example of an IPv6 address that the ipv6-address pattern does not handle so we have something concrete to talk about. I am appending some test cases to make it easier for you to find one. If you mean by "second" the ipv6-address-no-zone typedef, please see my response to Joel. This is a type derived from ipv6-address. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ipv6-gen.py" import libxml2 ip6_pat1 = \ '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}' \ + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|' \ + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}' \ + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))' \ + '(%[\p{N}\p{L}]+)?' ip6_pat2 = \ '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|' \ + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)' \ + '(%.+)?' ip6_re1 = libxml2.regexpCompile(ip6_pat1) ip6_re2 = libxml2.regexpCompile(ip6_pat2) pfx_pat1 = \ '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}' \ + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|' \ + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}' \ + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))' \ + '(/(([0-9])|([0-9]{2})|(1[0-1][0-9])|(12[0-8])))' pfx_pat2 = \ '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|' \ + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)' \ + '(/.+)' pfx_re1 = libxml2.regexpCompile(pfx_pat1) pfx_re2 = libxml2.regexpCompile(pfx_pat2) ip6_good = ['ABCD:EF01:2345:6789:ABCD:EF01:2345:6789', '2001:DB8:0:0:8:800:200C:417A', 'FF01:0:0:0:0:0:0:101', '0:0:0:0:0:0:0:1', '0:0:0:0:0:0:0:0', '2001:DB8::8:800:200C:417A', 'FF01::101', '::1', '::', '0:0:0:0:0:0:13.1.68.3', '0:0:0:0:0:FFFF:129.144.52.38', '::13.1.68.3', '::FFFF:129.144.52.38', '1:2:3:4:5:6:7::', '::1:2:3:4:5:6:7', '::1%eth0', '::1%42', '::1%en1'] ip6_bad = ['::1::', '::FFFF:1.2.3.4.5', '1:2:3:4:5:6:7:8:9' '::1%', '::1%*', '::1%-1'] pfx_good = ['ABCD:EF01:2345:6789:ABCD:EF01:2345:6789/48', '2001:DB8:0:0:8:800:200C:417A/0', 'FF01:0:0:0:0:0:0:101/128', '0:0:0:0:0:0:0:1/1', '0:0:0:0:0:0:0:0/123', '2001:DB8::8:800:200C:417A/8', 'FF01::101/64', '::1/64', '::/64', '0:0:0:0:0:0:13.1.68.3/64', '0:0:0:0:0:FFFF:129.144.52.38/64', '::13.1.68.3/64', '::FFFF:129.144.52.38/64', '1:2:3:4:5:6:7::/64', '::1:2:3:4:5:6:7/64'] pfx_bad = ['::1::/48', '::FFFF:1.2.3.4.5/48', '1:2:3:4:5:6:7:8:9/48', '::1/-1', '::1/a', '::1/129', '::1/1234', '::1/+12' ] for ip in ip6_good: if ip6_re1.regexpExec(ip) != 1: print "** ipv6 pattern #1 fails on %s" % ip if ip6_re2.regexpExec(ip) != 1: print "** ipv6 pattern #2 fails on %s" % ip for ip in ip6_bad: if ip6_re1.regexpExec(ip) != 1: continue if ip6_re2.regexpExec(ip) != 1: continue print "** ipv6 pattern fail to reject %s" % ip for ip in pfx_good: if pfx_re1.regexpExec(ip) != 1: print "** pfx pattern #1 fails on %s" % ip if pfx_re2.regexpExec(ip) != 1: print "** pfx pattern #2 fails on %s" % ip for ip in pfx_bad: if pfx_re1.regexpExec(ip) != 1: continue if pfx_re2.regexpExec(ip) != 1: continue print "** pfx pattern fail to reject %s" % ip --pWyiEgJYm5f9v55/-- From mbj@tail-f.com Thu May 2 00:57: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 DB87921F9936 for ; Thu, 2 May 2013 00:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.922 X-Spam-Level: X-Spam-Status: No, score=-0.922 tagged_above=-999 required=5 tests=[AWL=-1.290, BAYES_40=-0.185, 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 WZDSwJlJWsSi for ; Thu, 2 May 2013 00:57:40 -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 038A821F992E for ; Thu, 2 May 2013 00:57:39 -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 7CD2D1200DA0; Thu, 2 May 2013 09:57:37 +0200 (CEST) Date: Thu, 02 May 2013 09:57:37 +0200 (CEST) Message-Id: <20130502.095737.1388088311920396196.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20130430.103839.1231060720297181226.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=iso-2022-jp Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] [apps-discuss] Apps Area review of draft-ietf-netmod-interfaces-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: Thu, 02 May 2013 07:57:46 -0000 Ladislav Lhotka wrote: > [switched to NETMOD list] > > On Apr 30, 2013, at 10:38 AM, Martin Bjorklund wrote: > > >> 3.1 $B!H(BThe data model for interfaces presented in this document uses a > >> flat > >> list of interfaces.$B!I(B - does this mean that the model in section > >> 3. should > >> have $B!H(Binterface*$B!I(B rather than just $B!H(Binterface$B!I(B as a child of > >> $B!H(Binterfaces$B!I(B? > > > > In this tree diagram, the notion "interface [name]" means that it is a > > YANG list, with "name" as key. > > But what about keyless list, i.e. operational state? They are > indistinguishable from containers, so I'd suggest to append '*' to > their names as well. Yes, makes sense. And it also makes sense for lists with keys in general. (I have updated the pyang plugin to use this notation). /martin From j.schoenwaelder@jacobs-university.de Thu May 2 01:09: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 1563D21F8E5D for ; Thu, 2 May 2013 01:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyVb8yDeIhlF for ; Thu, 2 May 2013 01:09:47 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id AD68121F856D for ; Thu, 2 May 2013 01:09:46 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id E769320C3E; Thu, 2 May 2013 10:09:45 +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 caqWw9Fnf-jj; Thu, 2 May 2013 10:09:45 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2547620C2D; Thu, 2 May 2013 10:09:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 64EB925EEB5F; Thu, 2 May 2013 10:09:43 +0200 (CEST) Date: Thu, 2 May 2013 10:09:42 +0200 From: Juergen Schoenwaelder To: ietfdbh Message-ID: <20130502080941.GB5077@elstar.local> Mail-Followup-To: ietfdbh , "'Romascanu, Dan (Dan)'" , 'Martin Bjorklund' , bclaise@cisco.com, netmod@ietf.org References: <20130427.093659.369612374.mbj@tail-f.com> <20130430.122049.1111664509032933339.mbj@tail-f.com> <517FA5E3.2010604@cisco.com> <20130430.132943.828559691589933098.mbj@tail-f.com> <9904FB1B0159DA42B0B887B7FA8119CA0D9840@AZ-FFEXMB04.global.avaya.com> <036001ce46ad$aed16c90$0c7445b0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <036001ce46ad$aed16c90$0c7445b0$@comcast.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] Last Call: (A YANG Data Model for Interface Management) to Proposed Standard 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: Thu, 02 May 2013 08:09:52 -0000 On Wed, May 01, 2013 at 04:51:41PM -0400, ietfdbh wrote: > Hi, > > > > -----Original Message----- > > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On > > Behalf Of Martin Bjorklund > > > > > - what should an NM application or operator do if the YANG > > > oper-status > > > - and the IF-MIB operStatus differ? > > > > I need help also with this one. I do not understand the problem, so I > > cannot suggest a solution :( > > > [[DR]] The problem is that if both NETCONF and SNMP implementations exist on > the device and the operator reads both, he needs an indication about what > takes precedence in case of inconsistency. > [dbh>] I think that "what takes precedence?" is not something we can answer > in the data model; that will be implementation dependent. > I think what is needed is an "operational consideration" that says "the > status and counters in SNMP and the status and counters in NETCONF might be > different." No, the counters as they are defined are the same. And note, some of them also exist in IPFIX. Multiple protocols to access the counters are a long time reality, even multiple standards track protocols. I do not recall having read IPFIX operational considerations discussing why some information elements might have a different accuracy as what you might get form an SNMP implementation. > It could be good to explain that SNMP and NETCONF and CLI counters are > typically just front-ends for hardware or OS status/counters (as in > Juergen's email explanation). OK > But there is no MUST that says these counters MUST simply be front-ends for > hardware/OS counters. For example, as Juergen points out, SNMP counters are > sometimes cached. The cache does not change the semantics of the counters or introduce new counters. The cache and the way the SNMP protocol works adds sometimes surprising timing delays. So it boils down to: Network management protocols such as SNMP, IPFIX, NETCONF, or command line interfaces may differ in the time granularity in which they provide access to the counters. Are we now going to add this to all future SNMP, IPFIX, NETCONF data model documents? > SNMP counters are sometimes cached; CLI counters typically are not; Is it an > implementation decision whether NETCONF counters match other counter > interfaces? Let's say that someplace. > > > - persistence > > > > I don't think this document is the right place to describe the > > persistency model for SNMP vs. NETCONF - if we do it here we probably > > have to do it in all other data-model specific documents as well... > > > > [[DR]]this is not an SNMP vs. NETCONF discussion, this is a specific > data-model specification to understand what objects in the specific data > model must be kept persistent. And yes, all data-model documents should > specify this, if they do not the assumption is that all is lost on reboot > (if this is not written some place it should be IMO) > > > [dbh>] I think the data model should specify the persistence of the data > objects in this model, most notably the config objects. Does each config > object persist across system reboots? Do some objects persist but not all? > Is each YANG counter reinitialized on reboot, or are they expected to > persist across reboots? > Some of the YANG counters include a reference to IF-MIB counters. Do the > YANG counters match the persistence specified in the corresponding MIB > objects? > If not, why not? (If this is an SNMP vs NETCONF difference, then is this > documented in a NETCONF document someplace?) Section 5.1 of RFC 6241 defines the configuration datastore and Section 8.7 of RFC 6241 defines the configuration datastore and how they are synced. > Having worked for a hardware vendor that also produced NM software, I am > aware that sometimes a hardware counter is added to match a MIB standard > required by customers. > Whether that hardware counter persists often depends on what the standard > requires. > So if you will develop any YANG counters that are not mirrors of SNMP > counters, how does the hardware designer know whether to make it persistent > or not? > This affects cross-vendor/cross-product interoperability. Counters are typically config false objects and thus not persistent. See also the definition of the counter datatypes in RFC 6021. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Thu May 2 02:08: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 A005721F8624 for ; Thu, 2 May 2013 02:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.532 X-Spam-Level: X-Spam-Status: No, score=-103.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, 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 Lm4K0TNTzmk1 for ; Thu, 2 May 2013 02:08:01 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 2559421F85C9 for ; Thu, 2 May 2013 02:08:01 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAAH/ZlGHCzI1/2dsb2JhbABQgmUhwX6BBxZ0gh8BAQEBAxIoPwwEAgEIDQEDBAEBAQoUBQQHMhQJCAIEAQ0FCBqHYAMPAaBHkzkIiUsXjmUmCwcGglphA50pimiBVYE2gig X-IronPort-AV: E=Sophos;i="4.87,456,1363147200"; d="scan'208";a="9536639" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 02 May 2013 05:07:59 -0400 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 02 May 2013 05:04:35 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.02.0328.009; Thu, 2 May 2013 05:07:58 -0400 From: "Romascanu, Dan (Dan)" To: Martin Bjorklund , "ietfdbh@comcast.net" Thread-Topic: [netmod] Last Call: (A YANG Data Model for Interface Management) to Proposed Standard Thread-Index: AQHORYx1iQbr9cfI2ECu413TKNMZEpju3bOAgAAGR4CAASAU0IABD0SAgACkjwD//+UrIA== Date: Thu, 2 May 2013 09:07:57 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA0DBAB3@AZ-FFEXMB04.global.avaya.com> References: <20130430.132943.828559691589933098.mbj@tail-f.com> <9904FB1B0159DA42B0B887B7FA8119CA0D9840@AZ-FFEXMB04.global.avaya.com> <036001ce46ad$aed16c90$0c7445b0$@comcast.net> <20130502.084040.999899373393431650.mbj@tail-f.com> In-Reply-To: <20130502.084040.999899373393431650.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] Last Call: (A YANG Data Model for Interface Management) to Proposed Standard 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, 02 May 2013 09:08:07 -0000 > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Thursday, May 02, 2013 9:41 AM > To: ietfdbh@comcast.net > Cc: Romascanu, Dan (Dan); bclaise@cisco.com; netmod@ietf.org > Subject: Re: [netmod] Last Call: 10.txt> (A YANG Data Model for Interface Management) to Proposed > Standard >=20 > "ietfdbh" wrote: > > > I don't think this document is the right place to describe the > > > persistency model for SNMP vs. NETCONF - if we do it here we > > > probably have to do it in all other data-model specific documents as > well... > > > > > > > [[DR]]this is not an SNMP vs. NETCONF discussion, this is a specific > > data-model specification to understand what objects in the specific > > data model must be kept persistent. And yes, all data-model documents > > should specify this, if they do not the assumption is that all is lost > > on reboot (if this is not written some place it should be IMO) > > > > > > [dbh>] I think the data model should specify the persistence of the > > data objects in this model, most notably the config objects. Does each > > config object persist across system reboots? Do some objects persist > > but not all? >=20 > In NETCONF, the persistency of the configuration nodes are not a > property of the node itself, but a property of the datastore in which > the node exists. >=20 [[DR]] Why would this be different than for SNMP/SMI? The persistency infor= mation in the MIB modules determines the persistency characteristics of the= data store. If operational considerations require some objects (configurat= ion nodes) states must be kept in persistent memory. If there is no such ob= jects there may be no need for a persistent datastore at all.=20 Regards, Dan =20 From dromasca@avaya.com Thu May 2 02:10: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 1DD4B21F9928 for ; Thu, 2 May 2013 02:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.539 X-Spam-Level: X-Spam-Status: No, score=-103.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, 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 1XTZoH0mI4xB for ; Thu, 2 May 2013 02:10:06 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC7121F997A for ; Thu, 2 May 2013 02:10:06 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAAH/ZlGHCzI1/2dsb2JhbABNA4JlIcF+gQcWdIIfAQEBAQMSKD8MBAIBCA0EBAEBCxQFBAcyFAkIAgQBDQUIEweHYAMPAaBHkzkIiWKNVIERIQULBwYLgk9hA50pimiBVYE2gXM1 X-IronPort-AV: E=Sophos;i="4.87,456,1363147200"; d="scan'208";a="9536874" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 02 May 2013 05:10:05 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 02 May 2013 05:06:40 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.02.0328.009; Thu, 2 May 2013 05:10:03 -0400 From: "Romascanu, Dan (Dan)" To: ietfdbh , 'Martin Bjorklund' , "bclaise@cisco.com" Thread-Topic: [netmod] Last Call: (A YANG Data Model for Interface Management) to Proposed Standard Thread-Index: AQHORYx1iQbr9cfI2ECu413TKNMZEpju3bOAgAAGR4CAASAU0IABD0SAgACKssA= Date: Thu, 2 May 2013 09:10:02 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA0DBAC3@AZ-FFEXMB04.global.avaya.com> References: <20130427.093659.369612374.mbj@tail-f.com> <20130430.122049.1111664509032933339.mbj@tail-f.com> <517FA5E3.2010604@cisco.com> <20130430.132943.828559691589933098.mbj@tail-f.com> <9904FB1B0159DA42B0B887B7FA8119CA0D9840@AZ-FFEXMB04.global.avaya.com> <036001ce46ad$aed16c90$0c7445b0$@comcast.net> In-Reply-To: <036001ce46ad$aed16c90$0c7445b0$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] Last Call: (A YANG Data Model for Interface Management) to Proposed Standard 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, 02 May 2013 09:10:13 -0000 I agree with all that David says here. My wording ' he needs an indication = about what takes precedence in case of inconsistency' was negligent (sorry!= ), but I think we reached the right conclusion about what operational consi= derations information needs to be inserted here.=20 Thanks and Regards, Dan > -----Original Message----- > From: ietfdbh [mailto:ietfdbh@comcast.net] > Sent: Wednesday, May 01, 2013 11:52 PM > To: Romascanu, Dan (Dan); 'Martin Bjorklund'; bclaise@cisco.com > Cc: netmod@ietf.org > Subject: RE: [netmod] Last Call: 10.txt> (A YANG Data Model for Interface Management) to Proposed > Standard >=20 > Hi, >=20 >=20 > > -----Original Message----- > > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On > > Behalf Of Martin Bjorklund > > > > > - what should an NM application or operator do if the YANG > > > oper-status > > > - and the IF-MIB operStatus differ? > > > > I need help also with this one. I do not understand the problem, so I > > cannot suggest a solution :( > > > [[DR]] The problem is that if both NETCONF and SNMP implementations > exist on the device and the operator reads both, he needs an indication > about what takes precedence in case of inconsistency. > [dbh>] I think that "what takes precedence?" is not something we can > answer in the data model; that will be implementation dependent. > I think what is needed is an "operational consideration" that says "the > status and counters in SNMP and the status and counters in NETCONF might > be different." > It could be good to explain that SNMP and NETCONF and CLI counters are > typically just front-ends for hardware or OS status/counters (as in > Juergen's email explanation). > But there is no MUST that says these counters MUST simply be front-ends > for hardware/OS counters. For example, as Juergen points out, SNMP > counters are sometimes cached. > SNMP counters are sometimes cached; CLI counters typically are not; Is > it an implementation decision whether NETCONF counters match other > counter interfaces? Let's say that someplace. >=20 > > > - persistence > > > > I don't think this document is the right place to describe the > > persistency model for SNMP vs. NETCONF - if we do it here we probably > > have to do it in all other data-model specific documents as well... > > >=20 > [[DR]]this is not an SNMP vs. NETCONF discussion, this is a specific > data-model specification to understand what objects in the specific data > model must be kept persistent. And yes, all data-model documents should > specify this, if they do not the assumption is that all is lost on > reboot (if this is not written some place it should be IMO) >=20 >=20 > [dbh>] I think the data model should specify the persistence of the data > objects in this model, most notably the config objects. Does each config > object persist across system reboots? Do some objects persist but not > all? > Is each YANG counter reinitialized on reboot, or are they expected to > persist across reboots? > Some of the YANG counters include a reference to IF-MIB counters. Do the > YANG counters match the persistence specified in the corresponding MIB > objects? > If not, why not? (If this is an SNMP vs NETCONF difference, then is this > documented in a NETCONF document someplace?) >=20 > Having worked for a hardware vendor that also produced NM software, I am > aware that sometimes a hardware counter is added to match a MIB standard > required by customers. > Whether that hardware counter persists often depends on what the > standard requires. > So if you will develop any YANG counters that are not mirrors of SNMP > counters, how does the hardware designer know whether to make it > persistent or not? > This affects cross-vendor/cross-product interoperability. >=20 > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 From j.schoenwaelder@jacobs-university.de Thu May 2 02:21: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 E58B821F9981 for ; Thu, 2 May 2013 02:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-UUieBLCRsZ for ; Thu, 2 May 2013 02:21: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 73DAB21F8960 for ; Thu, 2 May 2013 02:21:07 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C1E6720C33; Thu, 2 May 2013 11:21:06 +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 96CaD-Dhj_S3; Thu, 2 May 2013 11:21: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 C8CEC20C2D; Thu, 2 May 2013 11:21:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 50D6D25EEEF6; Thu, 2 May 2013 11:21:05 +0200 (CEST) Date: Thu, 2 May 2013 11:21:05 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20130502092105.GA217@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , Martin Bjorklund , "ietfdbh@comcast.net" , "netmod@ietf.org" References: <20130430.132943.828559691589933098.mbj@tail-f.com> <9904FB1B0159DA42B0B887B7FA8119CA0D9840@AZ-FFEXMB04.global.avaya.com> <036001ce46ad$aed16c90$0c7445b0$@comcast.net> <20130502.084040.999899373393431650.mbj@tail-f.com> <9904FB1B0159DA42B0B887B7FA8119CA0DBAB3@AZ-FFEXMB04.global.avaya.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA0DBAB3@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "ietfdbh@comcast.net" , "netmod@ietf.org" Subject: Re: [netmod] Last Call: (A YANG Data Model for Interface Management) to Proposed Standard 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: Thu, 02 May 2013 09:21:14 -0000 On Thu, May 02, 2013 at 09:07:57AM +0000, Romascanu, Dan (Dan) wrote: > > > > > In NETCONF, the persistency of the configuration nodes are not a > > property of the node itself, but a property of the datastore in which > > the node exists. > > > > [[DR]] Why would this be different than for SNMP/SMI? The persistency information in the MIB modules determines the persistency characteristics of the data store. If operational considerations require some objects (configuration nodes) states must be kept in persistent memory. If there is no such objects there may be no need for a persistent datastore at all. > NETCONF is not SNMP. NETCONF has configuration data stores and the data stores have persistency properties for configuration data. /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 May 2 03:10: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 242A221F98CA for ; Thu, 2 May 2013 03:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.6 X-Spam-Level: X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30NS8ctg-dSi for ; Thu, 2 May 2013 03:10: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 BC80B21F9885 for ; Thu, 2 May 2013 03:10:05 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:7d03:821c:86c:d78] (unknown [IPv6:2001:1488:ac14:1400:7d03:821c:86c:d78]) by mail.nic.cz (Postfix) with ESMTPSA id 13401140857; Thu, 2 May 2013 12:10:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1367489405; bh=2r2oyat94hAO40uoe7X619KzO4pJgXyFSFbIqGgLbcs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=amd9ux4zYTy6zKjGmfsG2CUJgoKH6TTGLBdtzRCRUIJzcDiMDWycSfPU0VX7VFVke xldJDw3lM8PCVy9GI9I5qwKqMupE64TSYIdjoeTGddM/kprrlm6WtzLwKb/qdOj6VO jJwMoMLy3VbqQFVjTaj+7zU7s4z8Yz8bbA0AMFyw= Content-Type: text/plain; charset=iso-2022-jp Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ladislav Lhotka In-Reply-To: <20130502.095737.1388088311920396196.mbj@tail-f.com> Date: Thu, 2 May 2013 12:10:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130430.103839.1231060720297181226.mbj@tail-f.com> <20130502.095737.1388088311920396196.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1503) X-Virus-Scanned: clamav-milter 0.97.7 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] [apps-discuss] Apps Area review of draft-ietf-netmod-interfaces-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: Thu, 02 May 2013 10:10:07 -0000 On May 2, 2013, at 9:57 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> [switched to NETMOD list] >>=20 >> On Apr 30, 2013, at 10:38 AM, Martin Bjorklund = wrote: >>=20 >>>> 3.1 =1B$B!H=1B(BThe data model for interfaces presented in this = document uses a >>>> flat >>>> list of interfaces.=1B$B!I=1B(B - does this mean that the model in = section >>>> 3. should >>>> have =1B$B!H=1B(Binterface*=1B$B!I=1B(B rather than just = =1B$B!H=1B(Binterface=1B$B!I=1B(B as a child of >>>> =1B$B!H=1B(Binterfaces=1B$B!I=1B(B? >>>=20 >>> In this tree diagram, the notion "interface [name]" means that it is = a >>> YANG list, with "name" as key. >>=20 >> But what about keyless list, i.e. operational state? They are >> indistinguishable from containers, so I'd suggest to append '*' to >> their names as well. >=20 > Yes, makes sense. And it also makes sense for lists with keys in > general. Right, that's what I meant. >=20 > (I have updated the pyang plugin to use this notation). Good, thanks, Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From ietfdbh@comcast.net Thu May 2 05:27: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 329DC21F93E3 for ; Thu, 2 May 2013 05:27:05 -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=[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 nff1Da0nARpu for ; Thu, 2 May 2013 05:26:59 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCCD21F970E for ; Thu, 2 May 2013 05:26:17 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta03.westchester.pa.mail.comcast.net with comcast id WyhF1l00D1ZXKqc530SGH9; Thu, 02 May 2013 12:26:16 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta21.westchester.pa.mail.comcast.net with comcast id X0SF1l00z2yZEBF3h0SFyX; Thu, 02 May 2013 12:26:16 +0000 From: "ietfdbh" To: "'Juergen Schoenwaelder'" , "'Romascanu, Dan \(Dan\)'" References: <20130430.132943.828559691589933098.mbj@tail-f.com> <9904FB1B0159DA42B0B887B7FA8119CA0D9840@AZ-FFEXMB04.global.avaya.com> <036001ce46ad$aed16c90$0c7445b0$@comcast.net> <20130502.084040.999899373393431650.mbj@tail-f.com> <9904FB1B0159DA42B0B887B7FA8119CA0DBAB3@AZ-FFEXMB04.global.avaya.com> <20130502092105.GA217@elstar.local> In-Reply-To: <20130502092105.GA217@elstar.local> Date: Thu, 2 May 2013 08:26:16 -0400 Message-ID: <038d01ce4730$3e9e5810$bbdb0830$@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: AQJOb3hL/HEfw9uHR50Xe+YK6gF6/wGrscV5ASRgkQMCiI6n7wGgSU+mAcZsiFGXq3s64A== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367497576; bh=QYopbgsYxjRVs0Ne1yn11qb/jAaFec9hH3QDOSOAvHo=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=Vk+Jo499SyYbpB/XYxAz/XXgrlAgC8YloQer8tI5BWEOSW9wZphDGP8fW3Q8/KvRC 2QIFIZWG0UjV4pBBYMnoOgB7SZOaUvY9rnw9LPWKBt140YJp1VMAc7N1pZbvvP7ral f5W3creOx8z4cu5vccwYr4FIwnoJUoNMWRVT8C1xTT2MNuwUx1ayOBuZlhNd+gCzdX ifsB/gQKvenEV2MZhJ8ZamAqKGPZ0+1zTzlMo3Smx3Ncd7Y20Hm2y8bvXPdCYg9Tc1 LROxTvbpTxDbKwBtoWoga1rZ1WSjfH4uvjPlb1ogmlsFqDEBGKqCj8r1OqdbklRE1N qJFjxSabsnXgQ== Cc: netmod@ietf.org Subject: Re: [netmod] Last Call: (A YANG Data Model for Interface Management) to Proposed Standard 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, 02 May 2013 12:27:05 -0000 Hi, js> NETCONF is not SNMP. NETCONF has configuration data stores and the data stores have persistency properties for configuration data. [dbh>] You're right that NETCONF is not SNMP. The MIB has different persistence rules than NETCONF datastores. There has long been a problem about whether SNMP SETs were automatically captured in the startup config (e.g., NVRAM) or not. Some implementations did not do this automatically; others did. Some values, such as ifAlias, need to persist across reboots to be useful. >From RFC2863: " the ifAlias name is non-volatile, and thus an interface must retain its assigned ifAlias value across reboots" So what happens if an operator uses NETCONF to configure 'description' (which MAY map to ifAlias)? I presume that, indirectly, NETCONF is being used to SET ifAlias in the IF-MIB, by configuring the underlying instrumentation. In a system that supports both running and startup, is the 'description' value configured in 'running' automatically mirrored to startup? Or does the operator need to send a command to set the value into the startup config as well? This is not explained, and since 'description' uses a reference to ifAlias, operators could interoperate this inconsistently. That would affect interoperability. What if the system only supports the 'running' config, but also supports the MIB? Then what? Does ifAlias become non-persistent across reboots if configured via NETCONF, but persistent if configured using SNMP? Should we warn the operators about that? The YANG Interfaces config uses ifIndex. ifAlias was provided in rfc2863 at least partly because ifIndex semantics changed to accommodate operational realities. ifAlias provides a way to recognize an interface, even if the ifIndex corresponding to an interface changes across a reboot. NM applications can use this to correlate the database of interface operational state they acquired before reboot with the interface operational state they acquire after a reboot. This is important for tracking trends, and being able to study pre-reboot states, to do casual analysis for fault/performance problems after a reboot. With this module, you are now making it possible to acquire the same operational state, but doing so using NETCONF instead of SNMP. If ifAlias is non-persistent if configured by NETCONF, how should operators/applications correlate ifIndexes across reboots for operational state they have already read from the device using NETCONF? Or, on a reboot, should they throw away all historic/trending information they have previously acquired through NETCONF, and start over from scratch on any trending analysis? -- David Harrington ietfdbh@comcast.net +1-603-828-1401 From mbj@tail-f.com Thu May 2 06:02:44 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 20E6B21F8BE4 for ; Thu, 2 May 2013 06:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[AWL=0.016, 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 A0zrrK0nCnYq for ; Thu, 2 May 2013 06:02:38 -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 BDC1821F87D1 for ; Thu, 2 May 2013 06:02:27 -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 533BE1200D79; Thu, 2 May 2013 15:02:26 +0200 (CEST) Date: Thu, 02 May 2013 15:02:26 +0200 (CEST) Message-Id: <20130502.150226.786661102583726170.mbj@tail-f.com> To: ietfdbh@comcast.net From: Martin Bjorklund In-Reply-To: <038d01ce4730$3e9e5810$bbdb0830$@comcast.net> References: <9904FB1B0159DA42B0B887B7FA8119CA0DBAB3@AZ-FFEXMB04.global.avaya.com> <20130502092105.GA217@elstar.local> <038d01ce4730$3e9e5810$bbdb0830$@comcast.net> 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] Last Call: (A YANG Data Model for Interface Management) to Proposed Standard 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, 02 May 2013 13:02:44 -0000 Hi, "ietfdbh" wrote: > Hi, > > > js> NETCONF is not SNMP. NETCONF has configuration data stores and the data > stores have persistency properties for configuration data. > > > [dbh>] You're right that NETCONF is not SNMP. The MIB has different > persistence rules than NETCONF datastores. > There has long been a problem about whether SNMP SETs were automatically > captured in the startup config (e.g., NVRAM) or not. > Some implementations did not do this automatically; others did. > Some values, such as ifAlias, need to persist across reboots to be useful. > From RFC2863: " the ifAlias name is non-volatile, and thus an interface must > retain its assigned ifAlias value across reboots" So pre-netconf devices with running and startup that implement ifAlias faithfully probably store it in running, and do an implicit save to nvram. > So what happens if an operator uses NETCONF to configure 'description' > (which MAY map to ifAlias)? > I presume that, indirectly, NETCONF is being used to SET ifAlias in the > IF-MIB, by configuring the underlying instrumentation. > In a system that supports both running and startup, is the 'description' > value configured in 'running' automatically mirrored to startup? No, and it has nothing to do with 'description' - the persistence is a property of the data store. > Or does the operator need to send a command to set the value into the > startup config as well? Yes. > This is not explained It is explained in RFC 6241. > and since 'description' uses a reference to ifAlias, > operators could interoperate this inconsistently. > That would affect interoperability. You are right, this is a problem that noone thought about. I see two options: 1) Drop the mapping between ifAlias and description. (implementations that do this mapping anyway are on their own - just like they are today in their cli) 2) Explain that if description is mapped to ifAlias, it MUST map to the persistently stored description; i.e., in startup if it is present, and running otherwise. > What if the system only supports the 'running' config, but also supports the > MIB? Then what? This case is easy, b/c running is persistent if there is no startup. > Does ifAlias become non-persistent across reboots if configured via NETCONF, > but persistent if configured using SNMP? I don't think we should change the semantics of ifAlias. > Should we warn the operators about that? > > The YANG Interfaces config uses ifIndex. > ifAlias was provided in rfc2863 at least partly because ifIndex semantics > changed to accommodate operational realities. > ifAlias provides a way to recognize an interface, even if the ifIndex > corresponding to an interface changes across a reboot. > NM applications can use this to correlate the database of interface > operational state they acquired before reboot with the interface operational > state they acquire after a reboot. > This is important for tracking trends, and being able to study pre-reboot > states, to do casual analysis for fault/performance problems after a reboot. > With this module, you are now making it possible to acquire the same > operational state, but doing so using NETCONF instead of SNMP. > If ifAlias is non-persistent if configured by NETCONF, how should > operators/applications correlate ifIndexes across reboots for operational > state they have already read from the device using NETCONF? > Or, on a reboot, should they throw away all historic/trending information > they have previously acquired through NETCONF, and start over from scratch > on any trending analysis? They would probably just use the name of the interface if they are using this module. /martin From lhotka@nic.cz Thu May 2 06:18: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 29F6521F84A6 for ; Thu, 2 May 2013 06:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.449 X-Spam-Level: X-Spam-Status: No, score=-0.449 tagged_above=-999 required=5 tests=[AWL=1.550, 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 vIzvft5CoF0r for ; Thu, 2 May 2013 06:18:57 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 649CC21F8314 for ; Thu, 2 May 2013 06:18:57 -0700 (PDT) Received: from [192.168.42.52] (89-24-23-96.i4g.tmcz.cz [89.24.23.96]) by mail.nic.cz (Postfix) with ESMTPSA id B8A3E1402DC; Thu, 2 May 2013 15:18:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1367500736; bh=yaGyRQDCNCuX2riSoPcAOqtmXMIBKmajOU+O2Tmf0cA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=PK2IfiVzzpO7+rac8H/SK5rZcXyWn7EkVmO7mczMpgT+l+/1oFMxfXY2iQ0UQnB0n DWdThVAFIgI0ii0kgYGqxjNaxsKywllRQOEThR0BnEDCOX9xocQsMNAc07RbX30c8/ nSQJmY6WZn9WCo4xmt4xBPML091oWxLJ7885BQ1k= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ladislav Lhotka In-Reply-To: <20130502.150226.786661102583726170.mbj@tail-f.com> Date: Thu, 2 May 2013 15:18:44 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <9904FB1B0159DA42B0B887B7FA8119CA0DBAB3@AZ-FFEXMB04.global.avaya.com> <20130502092105.GA217@elstar.local> <038d01ce4730$3e9e5810$bbdb0830$@comcast.net> <20130502.150226.786661102583726170.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1503) X-Virus-Scanned: clamav-milter 0.97.7 at mail X-Virus-Status: Clean Cc: ietfdbh@comcast.net, netmod@ietf.org Subject: Re: [netmod] Last Call: (A YANG Data Model for Interface Management) to Proposed Standard 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, 02 May 2013 13:18:58 -0000 On May 2, 2013, at 3:02 PM, Martin Bjorklund wrote: >> and since 'description' uses a reference to ifAlias, >> operators could interoperate this inconsistently. >> That would affect interoperability. > > You are right, this is a problem that noone thought about. > > I see two options: > > 1) Drop the mapping between ifAlias and description. > (implementations that do this mapping anyway are on their own - > just like they are today in their cli) > > 2) Explain that if description is mapped to ifAlias, it MUST map to > the persistently stored description; i.e., in startup if it is > present, and running otherwise. Or 3) map ifAlias to something else, perhaps a new node. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Thu May 2 06:23: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 6AFB221F8D00 for ; Thu, 2 May 2013 06:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[AWL=0.015, 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 QXOPYZhQ-wVb for ; Thu, 2 May 2013 06:23:00 -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 834C021F8CEC for ; Thu, 2 May 2013 06:23:00 -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 CD05E1200DA0; Thu, 2 May 2013 15:22:59 +0200 (CEST) Date: Thu, 02 May 2013 15:22:59 +0200 (CEST) Message-Id: <20130502.152259.1658227545250854956.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <038d01ce4730$3e9e5810$bbdb0830$@comcast.net> <20130502.150226.786661102583726170.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: ietfdbh@comcast.net, netmod@ietf.org Subject: Re: [netmod] Last Call: (A YANG Data Model for Interface Management) to Proposed Standard 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, 02 May 2013 13:23:06 -0000 Ladislav Lhotka wrote: > > On May 2, 2013, at 3:02 PM, Martin Bjorklund wrote: > > >> and since 'description' uses a reference to ifAlias, > >> operators could interoperate this inconsistently. > >> That would affect interoperability. > > > > You are right, this is a problem that noone thought about. > > > > I see two options: > > > > 1) Drop the mapping between ifAlias and description. > > (implementations that do this mapping anyway are on their own - > > just like they are today in their cli) > > > > 2) Explain that if description is mapped to ifAlias, it MUST map to > > the persistently stored description; i.e., in startup if it is > > present, and running otherwise. > > Or 3) map ifAlias to something else, perhaps a new node. But then you'll just push the same problem to this new node. /martin From lhotka@nic.cz Thu May 2 06:42:21 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 B8D1021F851E for ; Thu, 2 May 2013 06:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.966 X-Spam-Level: X-Spam-Status: No, score=-0.966 tagged_above=-999 required=5 tests=[AWL=1.033, 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 OwU+WMPDGt8j for ; Thu, 2 May 2013 06:42:21 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 31AA121F850F for ; Thu, 2 May 2013 06:42:17 -0700 (PDT) Received: from [192.168.42.52] (89-24-23-96.i4g.tmcz.cz [89.24.23.96]) by mail.nic.cz (Postfix) with ESMTPSA id 90D6913F7DA; Thu, 2 May 2013 15:42:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1367502136; bh=MJX9EmypcyqqV/hBlGg1luCx45QtMtLzq/3JWNlqStY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=gTf5yl0JbdzPX7CrPLRYFKxf3T4Ik/lio28s1TLtMCFfMAFVOH+peEJsXkiWvo7cR WmX6lXGFkshfpDQfSDTnoEEIZpnw1XwbGnL4+Er4eAiT+PDqpONH6GH03iG1JJ3XLO /1BI8EKM1eLfyd9tYFY0YzSfjemMqR8YDUkskALg= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ladislav Lhotka In-Reply-To: <20130502.152259.1658227545250854956.mbj@tail-f.com> Date: Thu, 2 May 2013 15:42:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <038d01ce4730$3e9e5810$bbdb0830$@comcast.net> <20130502.150226.786661102583726170.mbj@tail-f.com> <20130502.152259.1658227545250854956.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1503) X-Virus-Scanned: clamav-milter 0.97.7 at mail X-Virus-Status: Clean Cc: ietfdbh@comcast.net, netmod@ietf.org Subject: Re: [netmod] Last Call: (A YANG Data Model for Interface Management) to Proposed Standard 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, 02 May 2013 13:42:21 -0000 On May 2, 2013, at 3:22 PM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>=20 >> On May 2, 2013, at 3:02 PM, Martin Bjorklund wrote: >>=20 >>>> and since 'description' uses a reference to ifAlias, >>>> operators could interoperate this inconsistently. >>>> That would affect interoperability. >>>=20 >>> You are right, this is a problem that noone thought about. >>>=20 >>> I see two options: >>>=20 >>> 1) Drop the mapping between ifAlias and description. >>> (implementations that do this mapping anyway are on their own - >>> just like they are today in their cli) >>>=20 >>> 2) Explain that if description is mapped to ifAlias, it MUST map to >>> the persistently stored description; i.e., in startup if it is >>> present, and running otherwise. >>=20 >> Or 3) map ifAlias to something else, perhaps a new node. >=20 > But then you'll just push the same problem to this new node. I understand Dave's concern was that the relationship between ifAlias = and description is casual (MAY). So if the new leaf ("alias") is defined = as THE equivalent of if ifAlias, it has to work the same for all = implementations. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Thu May 2 06:51: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 DD21F21F89B2 for ; Thu, 2 May 2013 06:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.032 X-Spam-Level: X-Spam-Status: No, score=-2.032 tagged_above=-999 required=5 tests=[AWL=0.014, 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 IlaB10d+cGNG for ; Thu, 2 May 2013 06:50:51 -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 DF82E21F86F4 for ; Thu, 2 May 2013 06:50: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 B722D1200DA1; Thu, 2 May 2013 15:50:49 +0200 (CEST) Date: Thu, 02 May 2013 15:50:49 +0200 (CEST) Message-Id: <20130502.155049.544273456438875339.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20130502.152259.1658227545250854956.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: ietfdbh@comcast.net, netmod@ietf.org Subject: Re: [netmod] Last Call: (A YANG Data Model for Interface Management) to Proposed Standard 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, 02 May 2013 13:51:01 -0000 Ladislav Lhotka wrote: > > On May 2, 2013, at 3:22 PM, Martin Bjorklund wrote: > > > Ladislav Lhotka wrote: > >> > >> On May 2, 2013, at 3:02 PM, Martin Bjorklund wrote: > >> > >>>> and since 'description' uses a reference to ifAlias, > >>>> operators could interoperate this inconsistently. > >>>> That would affect interoperability. > >>> > >>> You are right, this is a problem that noone thought about. > >>> > >>> I see two options: > >>> > >>> 1) Drop the mapping between ifAlias and description. > >>> (implementations that do this mapping anyway are on their own - > >>> just like they are today in their cli) > >>> > >>> 2) Explain that if description is mapped to ifAlias, it MUST map to > >>> the persistently stored description; i.e., in startup if it is > >>> present, and running otherwise. > >> > >> Or 3) map ifAlias to something else, perhaps a new node. > > > > But then you'll just push the same problem to this new node. > > I understand Dave's concern was that the relationship between ifAlias > and description is casual (MAY). So if the new leaf ("alias") is > defined as THE equivalent of if ifAlias, it has to work the same for > all implementations. The problem as I see it is that ifAlias MUST be stored persistently. This means that if a device supports both startup and running, and a NETCONF client writes a new value for 'description' into running, this new value should not be reported for ifAlias over SNMP. When running has been copied to startup, the new value should be reported. /martin From lhotka@nic.cz Thu May 2 07:08: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 70C2921F8B18 for ; Thu, 2 May 2013 07:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.224 X-Spam-Level: X-Spam-Status: No, score=-1.224 tagged_above=-999 required=5 tests=[AWL=0.775, 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 Z06g9Z265+Nn for ; Thu, 2 May 2013 07:08:15 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id EDCFB21F8B38 for ; Thu, 2 May 2013 07:08:11 -0700 (PDT) Received: from [192.168.42.52] (89-24-23-96.i4g.tmcz.cz [89.24.23.96]) by mail.nic.cz (Postfix) with ESMTPSA id ABCD513F7DA; Thu, 2 May 2013 16:08:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1367503691; bh=y5WhkCKOB2zIXbVieRwbllKlUv3UaYBRjj2FTZJFn8o=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=vkT/38NC07cZBNX1Gnj8kRD3gP59tVsf/lDzKnr2qiQMkJu0i46jMC/pbWjTMG+e8 plaYFTKvHeJ3RHSSoZrmD28RbMWp0uAh8ebcVc0xjzF3d9smYUXjojB5AtFphDLfw+ y5uB/BjynDkUb7p5tvBni6nfyjbLi/JcmFPc3/mQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ladislav Lhotka In-Reply-To: <20130502.155049.544273456438875339.mbj@tail-f.com> Date: Thu, 2 May 2013 16:08:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8CDB748F-0D08-42C6-85B5-81B992DDADB5@nic.cz> References: <20130502.152259.1658227545250854956.mbj@tail-f.com> <20130502.155049.544273456438875339.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1503) X-Virus-Scanned: clamav-milter 0.97.7 at mail X-Virus-Status: Clean Cc: ietfdbh@comcast.net, netmod@ietf.org Subject: Re: [netmod] Last Call: (A YANG Data Model for Interface Management) to Proposed Standard 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, 02 May 2013 14:08:16 -0000 On May 2, 2013, at 3:50 PM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>=20 >> On May 2, 2013, at 3:22 PM, Martin Bjorklund wrote: >>=20 >>> Ladislav Lhotka wrote: >>>>=20 >>>> On May 2, 2013, at 3:02 PM, Martin Bjorklund = wrote: >>>>=20 >>>>>> and since 'description' uses a reference to ifAlias, >>>>>> operators could interoperate this inconsistently. >>>>>> That would affect interoperability. >>>>>=20 >>>>> You are right, this is a problem that noone thought about. >>>>>=20 >>>>> I see two options: >>>>>=20 >>>>> 1) Drop the mapping between ifAlias and description. >>>>> (implementations that do this mapping anyway are on their own - >>>>> just like they are today in their cli) >>>>>=20 >>>>> 2) Explain that if description is mapped to ifAlias, it MUST map = to >>>>> the persistently stored description; i.e., in startup if it is >>>>> present, and running otherwise. >>>>=20 >>>> Or 3) map ifAlias to something else, perhaps a new node. >>>=20 >>> But then you'll just push the same problem to this new node. >>=20 >> I understand Dave's concern was that the relationship between ifAlias >> and description is casual (MAY). So if the new leaf ("alias") is >> defined as THE equivalent of if ifAlias, it has to work the same for >> all implementations. >=20 > The problem as I see it is that ifAlias MUST be stored persistently. > This means that if a device supports both startup and running, and a > NETCONF client writes a new value for 'description' into running, this > new value should not be reported for ifAlias over SNMP. When running > has been copied to startup, the new value should be reported. This problem is not specific to ifAlias, it will be the same for many = other parameters. If both NETCONF and SNMP (or any other mechanism, for = that matter) attempt to set the same parameter, there have to be some = arbitration rules, and the result will become the operational state = value for that parameter (which all management interfaces should be able = to discover). I think it would be very problematic (locks etc.) if the = device was supposed to change something in a NETCONF datastore because = it was changed via SNMP. Lada >=20 >=20 > /martin >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From ietfdbh@comcast.net Thu May 2 09: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 195A521F8F0F for ; Thu, 2 May 2013 09:37:18 -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=[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 uPhI7WIG7D8R for ; Thu, 2 May 2013 09:37:09 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 14E9C21F8EDF for ; Thu, 2 May 2013 09:37:08 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta05.westchester.pa.mail.comcast.net with comcast id WzDR1l0070EZKEL554d8h5; Thu, 02 May 2013 16:37:08 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta01.westchester.pa.mail.comcast.net with comcast id X4d71l00r2yZEBF3M4d814; Thu, 02 May 2013 16:37:08 +0000 From: "ietfdbh" To: "'Ladislav Lhotka'" , "'Martin Bjorklund'" References: <038d01ce4730$3e9e5810$bbdb0830$@comcast.net> <20130502.150226.786661102583726170.mbj@tail-f.com> <20130502.152259.1658227545250854956.mbj@tail-f.com> In-Reply-To: Date: Thu, 2 May 2013 12:37:08 -0400 Message-ID: <039d01ce4753$4a540100$defc0300$@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: AQKj4EuW3JnDOSjd6eyjup9w3aS6bAKmQnJPAadVzCoB8MpcdQHonV4KlwWOD8A= Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367512628; bh=gfVYRH7I7cUjITBVfYTIkENcIFsVPWJ2GKXjj4Xi+ws=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=NweYkic3UftsqA4oBIUjYlDGSlE4GCcWxznLe/z5tOPNVcJmM7OKsy6p+KdmZPa81 uuXcx6ZwzF05kQD43pujgkG/NGT4mcTRI7f0yk0+iIzBNN9O6aPv4XWj77kkseCj55 Gv8k24LN66a9qwPZ8vVDWKDKIZi3ktSFtgKwaAQC1wrXgTR4jTl20FL60kkjShd3bi /a2/1IOGY71g+Nc/P0wn2oMATqLfUCT54BDRIB4MlqFGsNEjD/vVX6e4jdYtEQXUUL Fts7Sq7OF1Eq3K9Dw8FwsZ7gilfEOAKR7DUte/WhgVnyqPTLMOsvX0qw5wZyGN2M/v /gYErq1uNNegA== Cc: netmod@ietf.org Subject: Re: [netmod] Last Call: (A YANG Data Model for Interface Management) to Proposed Standard 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, 02 May 2013 16:37:20 -0000 Hi, Comments inline. -----Original Message----- From: Ladislav Lhotka [mailto:lhotka@nic.cz] I understand Dave's concern was that the relationship between ifAlias and description is casual (MAY). So if the new leaf ("alias") is defined as THE equivalent of if ifAlias, it has to work the same for all implementations. [dbh>] [dbh>] Actually, I think I have four concerns. 1) the relationship is casual. This means it is not standardized. On some implementations, 'description' == ifAlias; on others it is not. ifAlias was defined in RFC2863 for a reason, and some applications depend on it being there to help interpret ifIndex correctly after a reboot. IF-MIB's ifAlias does not have to have a value, so applications cannot always rely on it for this purpose, but 1) where the value is set, the value should be able to be relied upon consistently across reboots, and 2) that behavior should be able to be relied upon consistently across implementations. Neither of these assumptions appear to be supported by the YANG definition. 2) the semantic requirements of 'description' and ifAlias are different, even when they are mapped, especially the persistence issue. The coexistence of SNMP and NETCONF might be worthy of its own discussion, because it will impact any MIB object declared in the MIB to be persistent that is mirrored in a YANG data model, where persistence is different. It has become an IETF requirement that persistence be discussed in MIB objects. At a minimum, any YANG data object that tries to access the same underlying data object as a MIB object (especially an IETF standard MIB object) that specifies persistence constraints should probably discuss whether the MIB-described persistence applies or not, to warn operators that they cannot expect the same semantics across the two data models. It might be possible to note this in the definition of counters in YANG-types, but it gets trickier for other types, such as configured text strings like ifAlias. (and not all MIB counters are persistent, so I think it really is an object-by-object issue.) 3) even if the ifAlias mapping is supported, the type/value constraints are casual. 'description' MAY or MAY not restrict the type/character set so that the values are consistent regardless of whether accessed through NETCONF or SNMP. And there is no discussion of what should happen if the IF-MIB is supported but not its ifAlias restrictions, and 'description' is set with a value that doesn't meet the IF-MIB requirements; so if the underlying instrumentation for ifAlias is configured with a value that is illegal for ifAlias, what happens when SNMP tries to access this underlying instrumentation and finds it contains an invalid value? Should the SNMP agent somehow translate the value into a valid syntax? Report an error? I think we cannot say "that's an SNMP problem", when the problem is caused by this YANG module's definitions of a casual relationship between the two. If 'description' is mapped to ifAlias, then it has to have the same semantics for all implementations that support the mapping. 4) The YANG module allows casual mapping relationships between its objects and existing standard objects, and casual relationships between the syntactic and semantic constraints of the data models, but there are no indicators in the YANG model to query what is or is not supported in the YANG implementation. And there is no discussion within the YANG model of the operational considerations of these non-standardized YANG implementation decisions. So is an NMS expected to test each implementation by configuring a MIB-illegal test value into the YANG 'description' and then checking to see what effect it has on an SNMP GET of ifAlias? If the IETF published a standard YANG module, and subsequently published a standard MIB module that defined a read-write object mapped to a config-true YANG object, and chose to change the semantics of the underlying instrumentation mapped to the MIB object and the YANG object, and did so in a way that would be illegal for a subsequent YANG module to make, don't you think it would be appropriate to at least point this out in the MIB module that it is basically obsoleting/updating the semantics of the YANG object and/or its underlying instrumentation? (and I think it would be appropriate for IESG to say "wait a minute ..."). David Harrington ietfdbh@comcast.net +1-603-828-1401 From j.schoenwaelder@jacobs-university.de Thu May 2 10:06: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 20D0F21F8F4D for ; Thu, 2 May 2013 10:06:12 -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, 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 kdRx1wKDV-Uy for ; Thu, 2 May 2013 10:06: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 E2AFB21F8F0D for ; Thu, 2 May 2013 10:06:06 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 14F3020C33; Thu, 2 May 2013 19:06:06 +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 PqnVSXQXr281; Thu, 2 May 2013 19:06:05 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 92AA220C34; Thu, 2 May 2013 19:06:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 16D2325F0880; Thu, 2 May 2013 19:06:03 +0200 (CEST) Date: Thu, 2 May 2013 19:06:03 +0200 From: Juergen Schoenwaelder To: ietfdbh Message-ID: <20130502170603.GA1819@elstar.local> Mail-Followup-To: ietfdbh , netmod@ietf.org References: <038d01ce4730$3e9e5810$bbdb0830$@comcast.net> <20130502.150226.786661102583726170.mbj@tail-f.com> <20130502.152259.1658227545250854956.mbj@tail-f.com> <039d01ce4753$4a540100$defc0300$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <039d01ce4753$4a540100$defc0300$@comcast.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] Last Call: (A YANG Data Model for Interface Management) to Proposed Standard 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: Thu, 02 May 2013 17:06:12 -0000 On Thu, May 02, 2013 at 12:37:08PM -0400, ietfdbh wrote: > 2) the semantic requirements of 'description' and ifAlias are different, > even when they are mapped, especially the persistence issue. The coexistence > of SNMP and NETCONF might be worthy of its own discussion, because it will > impact any MIB object declared in the MIB to be persistent that is mirrored > in a YANG data model, where persistence is different. It has become an IETF > requirement that persistence be discussed in MIB objects. At a minimum, any > YANG data object that tries to access the same underlying data object as a > MIB object (especially an IETF standard MIB object) that specifies > persistence constraints should probably discuss whether the MIB-described > persistence applies or not, to warn operators that they cannot expect the > same semantics across the two data models. It might be possible to note this > in the definition of counters in YANG-types, but it gets trickier for other > types, such as configured text strings like ifAlias. (and not all MIB > counters are persistent, so I think it really is an object-by-object issue.) David, can you point me to an example of an IETF standards-track SNMP counter that is persistent? I understand you are talking about this in a broader scope but since this counter argument continues to pop up, I like to know an example where this would matter. Thanks, /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietfdbh@comcast.net Thu May 2 11:52: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 14C8E21F930A for ; Thu, 2 May 2013 11:52:05 -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=[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 jYB77WqK2ulV for ; Thu, 2 May 2013 11:52:00 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id BFCB521F92FB for ; Thu, 2 May 2013 11:51:59 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta08.westchester.pa.mail.comcast.net with comcast id X60y1l0081ap0As586rzGJ; Thu, 02 May 2013 18:51:59 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta22.westchester.pa.mail.comcast.net with comcast id X6ry1l00z2yZEBF3i6ry2J; Thu, 02 May 2013 18:51:59 +0000 From: "ietfdbh" To: "'Juergen Schoenwaelder'" References: <038d01ce4730$3e9e5810$bbdb0830$@comcast.net> <20130502.150226.786661102583726170.mbj@tail-f.com> <20130502.152259.1658227545250854956.mbj@tail-f.com> <039d01ce4753$4a540100$defc0300$@comcast.net> <20130502170603.GA1819@elstar.local> In-Reply-To: <20130502170603.GA1819@elstar.local> Date: Thu, 2 May 2013 14:51:59 -0400 Message-ID: <03a101ce4766$20deed40$629cc7c0$@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: AQKj4EuW3JnDOSjd6eyjup9w3aS6bAKmQnJPAadVzCoB8MpcdQHonV4KAwvCXV8BwMTV3ZbfZnUA Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367520719; bh=lHOj2yuFvR+MjlutHukmqbd7fx1u0kRTjOQuj/qCEPo=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=hMFFNJ9RlOzu0QTR7mCS7lEKTcWlcynBaluRD1THHLv8hvGKqAXFjVSt1O/8iYcs1 5ksbB5PHZ1kakT2k+9E11wQVzydbkTDQ25M8dVwW/1uqujcO0a4Xb1q4OFo+dESyEW 4tmeCgA36b4RLfgUCxbDclESxLNgfwIUbIoB9YXPsOCgLPDtlHCnJXwnL4twEVl2XC xNGqGZbKQ/vKvi4zJS8vih5ZkWn9JdjKYOnXWdxbFovkWd0gp5IU283JjCDryFpqDw jP0CxNfje6NrruKUSD8xTTfyuP8xJ5pB/voXb7DlKe1a7jOEkZqnqmbO1qyg4deC9h 2mdKIiSJBD27A== Cc: netmod@ietf.org Subject: Re: [netmod] Last Call: (A YANG Data Model for Interface Management) to Proposed Standard 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, 02 May 2013 18:52:05 -0000 Hi Juergen, Hmmm. Thanks for asking me this question. I think all counters, being read-only, reset on reboot since reboot is a fundamental discontinuity. So counters would be off the table in these discussions of reboot persistence. Thanks for narrowing the scope. It's the read-write MIB objects that can be SET by an operator/application that might require persistence across reboots. And it's only config-true YANG objects that map to persistent MIB objects that are a real concern here. So we can narrow the scope of discussion even further. I think there are not that many MIB objects that MUST persist, but they do pop up here and there. So I think we will need to deal with them whenever there is a config-true YANG object mapping to one of these persistent MIB objects. NM interfaces that don't modify managed objects, such as IPFIX and Syslog , would avoid this issue. CLI isn't IETF-standardized so we can't address this very well. So, for our purposes, I think we only need to talk about YANG and read-write MIB model (or NETCONF/XML and MIB) co-existence. (I'm a bit concerned about new efforts, such as SACM, that might try to write their own config data models in XML or something, but that's a discussion for a different forum.) David Harrington ietfdbh@comcast.net +1-603-828-1401 -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Thursday, May 02, 2013 1:06 PM To: ietfdbh Cc: netmod@ietf.org Subject: Re: [netmod] Last Call: (A YANG Data Model for Interface Management) to Proposed Standard On Thu, May 02, 2013 at 12:37:08PM -0400, ietfdbh wrote: > 2) the semantic requirements of 'description' and ifAlias are > different, even when they are mapped, especially the persistence > issue. The coexistence of SNMP and NETCONF might be worthy of its own > discussion, because it will impact any MIB object declared in the MIB > to be persistent that is mirrored in a YANG data model, where > persistence is different. It has become an IETF requirement that > persistence be discussed in MIB objects. At a minimum, any YANG data > object that tries to access the same underlying data object as a MIB > object (especially an IETF standard MIB object) that specifies > persistence constraints should probably discuss whether the > MIB-described persistence applies or not, to warn operators that they > cannot expect the same semantics across the two data models. It might > be possible to note this in the definition of counters in YANG-types, > but it gets trickier for other types, such as configured text strings > like ifAlias. (and not all MIB counters are persistent, so I think it > really is an object-by-object issue.) David, can you point me to an example of an IETF standards-track SNMP counter that is persistent? I understand you are talking about this in a broader scope but since this counter argument continues to pop up, I like to know an example where this would matter. Thanks, /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@yumaworks.com Thu May 2 12:31:01 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 C406821F8F5D for ; Thu, 2 May 2013 12:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAzxZKqSbAoR for ; Thu, 2 May 2013 12:30:59 -0700 (PDT) Received: from mail-ia0-x229.google.com (mail-ia0-x229.google.com [IPv6:2607:f8b0:4001:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 129A421F8EC1 for ; Thu, 2 May 2013 12:30:57 -0700 (PDT) Received: by mail-ia0-f169.google.com with SMTP id l29so764915iag.14 for ; Thu, 02 May 2013 12:30:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=ZMRWGRSSDRqPX7z0Fid1vtN3Y0/6SZMVsLmOdTiE+y8=; b=jjHe/saW7Zczkbg7mw4nDYeDVmouw1HL7cwHugPM57CkJtOKhPtD7Y/JUN8TpzhN3Q aizqtLFzSYLy4x7oyxOQ37TYr5eEPgzIKzUzLW6B+gW6Uf4x4W36y9mQ4g4fXGH1rU4a ritff01+XoXJRdGEePZ1tro5faBoTayrhmRpvpHMzfjkNvyCrhkK2ehZz6CO+dRCsfM9 GiW9uqI1BXY6HwkUaCtRBj8nUauNlIKG5kD60XEB745AqNBdfUluHSnSfVpUWi9BcYA0 cjCte23reHZ81aO57VMOMPtmHc6QsHTnZdGP5C2cby2ewfqSHnEeMrEK9LQZfnLdI0bG EM4Q== MIME-Version: 1.0 X-Received: by 10.42.102.211 with SMTP id j19mr978223ico.0.1367523056606; Thu, 02 May 2013 12:30:56 -0700 (PDT) Received: by 10.231.125.202 with HTTP; Thu, 2 May 2013 12:30:56 -0700 (PDT) In-Reply-To: <03a101ce4766$20deed40$629cc7c0$@comcast.net> References: <038d01ce4730$3e9e5810$bbdb0830$@comcast.net> <20130502.150226.786661102583726170.mbj@tail-f.com> <20130502.152259.1658227545250854956.mbj@tail-f.com> <039d01ce4753$4a540100$defc0300$@comcast.net> <20130502170603.GA1819@elstar.local> <03a101ce4766$20deed40$629cc7c0$@comcast.net> Date: Thu, 2 May 2013 12:30:56 -0700 Message-ID: From: Andy Bierman To: ietfdbh Content-Type: multipart/alternative; boundary=20cf3011e35d02f4c504dbc14685 X-Gm-Message-State: ALoCoQlfhtR8018COXkpItvFZmG2wUrKkmZ7hnLM+4QnIWyNUNpceEN6oRwoOrSOUYAqmbwO7aJI Cc: netmod@ietf.org Subject: Re: [netmod] Last Call: (A YANG Data Model for Interface Management) to Proposed Standard 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, 02 May 2013 19:31:01 -0000 --20cf3011e35d02f4c504dbc14685 Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 2, 2013 at 11:51 AM, ietfdbh wrote: > Hi Juergen, > > Hmmm. Thanks for asking me this question. > I think all counters, being read-only, reset on reboot since reboot is a > fundamental discontinuity. > So counters would be off the table in these discussions of reboot > persistence. > > Thanks for narrowing the scope. > > It's the read-write MIB objects that can be SET by an operator/application > that might require persistence across reboots. > And it's only config-true YANG objects that map to persistent MIB objects > that are a real concern here. > So we can narrow the scope of discussion even further. > > I think there are not that many MIB objects that MUST persist, but they do > pop up here and there. > So I think we will need to deal with them whenever there is a config-true > YANG object mapping to one of these persistent MIB objects. > NM interfaces that don't modify managed objects, such as IPFIX and Syslog , > would avoid this issue. > CLI isn't IETF-standardized so we can't address this very well. > So, for our purposes, I think we only need to talk about YANG and > read-write > MIB model (or NETCONF/XML and MIB) co-existence. > > Looking over the RowStatus and StorageType TCs, it seems to be implied that the "mirror" model for NV-storage is used. Unless explicitly stated otherwise, when a row is activated and intended to persist, it is assumed to be saved automatically. NETCONF servers using the :startup capability do not follow this persistence model. So we narrow the scope further to NETCONF servers running without an explicit startup config. IMO, if the semantics of a MIB object call for something different, then it is an implementation detail to make sure the NETCONF/YANG version is correct. I think the YANG Usage Guidelines (RFC 6087) is the proper document to put guidelines for implementing YANG datastore objects for optimal coexistence with SNMP agents. > (I'm a bit concerned about new efforts, such as SACM, that might try to > write their own config data models in XML or something, but that's a > discussion for a different forum.) > > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 > > Andy > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, May 02, 2013 1:06 PM > To: ietfdbh > Cc: netmod@ietf.org > Subject: Re: [netmod] Last Call: > (A YANG Data Model for Interface Management) to Proposed Standard > > On Thu, May 02, 2013 at 12:37:08PM -0400, ietfdbh wrote: > > > 2) the semantic requirements of 'description' and ifAlias are > > different, even when they are mapped, especially the persistence > > issue. The coexistence of SNMP and NETCONF might be worthy of its own > > discussion, because it will impact any MIB object declared in the MIB > > to be persistent that is mirrored in a YANG data model, where > > persistence is different. It has become an IETF requirement that > > persistence be discussed in MIB objects. At a minimum, any YANG data > > object that tries to access the same underlying data object as a MIB > > object (especially an IETF standard MIB object) that specifies > > persistence constraints should probably discuss whether the > > MIB-described persistence applies or not, to warn operators that they > > cannot expect the same semantics across the two data models. It might > > be possible to note this in the definition of counters in YANG-types, > > but it gets trickier for other types, such as configured text strings > > like ifAlias. (and not all MIB counters are persistent, so I think it > > really is an object-by-object issue.) > > David, > > can you point me to an example of an IETF standards-track SNMP counter that > is persistent? I understand you are talking about this in a broader scope > but since this counter argument continues to pop up, I like to know an > example where this would matter. > > Thanks, > > /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 > --20cf3011e35d02f4c504dbc14685 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, May 2, 2013 at 11:51 AM, ietfdbh= <ietfdbh@comcast.net> wrote:
Hi Juergen,

Hmmm. Thanks for asking me this question.
I think all counters, being read-only, reset on reboot since reboot is a fundamental discontinuity.
So counters would be off the table in these discussions of reboot
persistence.

Thanks for narrowing the scope.

It's the read-write MIB objects that can be SET by an operator/applicat= ion
that might require persistence across reboots.
And it's only config-true YANG objects that map to persistent MIB objec= ts
that are a real concern here.
So we can narrow the scope of discussion even further.

I think there are not that many MIB objects that MUST persist, but they do<= br> pop up here and there.
So I think we will need to deal with them whenever there is a config-true YANG object mapping to one of these persistent MIB objects.
NM interfaces that don't modify managed objects, such as IPFIX and Sysl= og ,
would avoid this issue.
CLI isn't IETF-standardized so we can't address this very well.
So, for our purposes, I think we only need to talk about YANG and read-writ= e
MIB model (or NETCONF/XML and MIB) co-existence.


Looking over the RowStatus and Storage= Type TCs, it seems to
be implied that the "mirror" mode= l for NV-storage is used.
Unless explicitly stated otherwise, whe= n a row is activated
and intended to persist, it is assumed to be saved automatically.

NETCONF servers using the :startup capability do not f= ollow this
persistence model. =A0So we narrow the scope further t= o NETCONF
servers running without an explicit startup config.

IMO, if the semantics of a MIB object call for something
d= ifferent, then it is an implementation detail to make sure
the NE= TCONF/YANG version is correct.

I think the YANG Usage Guidelines (RFC 6087) is the pro= per
document to put guidelines for implementing YANG datastore
objects for optimal coexistence with SNMP agents.


=A0
(I'm a bit concerned about new efforts, such as SACM, that might try to=
write their own config data models in XML or something, but that's a discussion for a different forum.)

David Harrington
ietfdbh@comcast.net
+1-603-828-1401



Andy

=A0
-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
Sent: Thursday, May 02, 2013 1:06 PM
To: ietfdbh
Cc: netmod@ietf.org
Subject: Re: [netmod] Last Call: <draft-ietf-netmod-interfaces-cfg-10.tx= t>
(A YANG Data Model for Interface Management) to Proposed Standard

On Thu, May 02, 2013 at 12:37:08PM -0400, ietfdbh wrote:

> 2) the semantic requirements of 'description' and ifAlias are<= br> > different, even when they are mapped, especially the persistence
> issue. The coexistence of SNMP and NETCONF might be worthy of its own<= br> > discussion, because it will impact any MIB object declared in the MIB<= br> > to be persistent that is mirrored in a YANG data model, where
> persistence is different. It has become an IETF requirement that
> persistence be discussed in MIB objects. At a minimum, any YANG data > object that tries to access the same underlying data object as a MIB > object (especially an IETF standard MIB object) that specifies
> persistence constraints should probably discuss whether the
> MIB-described persistence applies or not, to warn operators that they<= br> > cannot expect the same semantics across the two data models. It might<= br> > be possible to note this in the definition of counters in YANG-types,<= br> > but it gets trickier for other types, such as configured text strings<= br> > like ifAlias. (and not all MIB counters are persistent, so I think it<= br> > really is an object-by-object issue.)

David,

can you point me to an example of an IETF standards-track SNMP counter that=
is persistent? I understand you are talking about this in a broader scope but since this counter argument continues to pop up, I like to know an
example where this would matter.

Thanks,

/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>
_______________________________________________
netmod mailing list
netmod@ietf.org
= https://www.ietf.org/mailman/listinfo/netmod

--20cf3011e35d02f4c504dbc14685-- From martin.thomson@gmail.com Thu May 2 13:28: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 3200821F8D29; Thu, 2 May 2013 13:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Qha1eId8s4b2; Thu, 2 May 2013 13:28:47 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 35D3721F8D0D; Thu, 2 May 2013 13:28:47 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id hq12so100207wib.3 for ; Thu, 02 May 2013 13:28:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=bYg6sAu59InJ6FBOrFPc2w7FzSdkRnBWrAQtXFUvsY4=; b=V6+NNQy9SZ7upLOp5juKuA0YHSpIubsXeReVJXf0XpGGaHhRcAETjHBtoZtjOIZcNE onui89fqyx3M670OGqv3h15YoL6fhNshgdrEURvfFIyAKKHasZbiIPhpURrkh+BSAV/a i8Oanjm5XkrjvjM5/OUZ1cMiTSDHfKdapj6NzWXpC+DrgxwmX0YHzwfoRE1yo1ItGWPE TIlCsAI/bgGygbAcyj6IIJnnCV52pU0V+Clkaoou1hX955Jdxe/jzb5wFA7FaKWAuO27 Fn1LDqr6jhYD4+pGJL1uBgNf4dVSQEEnC3iJU8yFa4VWkJ+Xv60TEBcfH018+FHqFiWR TiPQ== MIME-Version: 1.0 X-Received: by 10.180.83.199 with SMTP id s7mr9931501wiy.19.1367526526427; Thu, 02 May 2013 13:28:46 -0700 (PDT) Received: by 10.194.33.102 with HTTP; Thu, 2 May 2013 13:28:46 -0700 (PDT) In-Reply-To: <20130502074157.GA4935@elstar.local> References: <6.2.5.6.2.20130428233426.0b62fed0@elandnews.com> <20130430083206.GD46852@elstar.local> <20130502074157.GA4935@elstar.local> Date: Thu, 2 May 2013 13:28:46 -0700 Message-ID: From: Martin Thomson To: Juergen Schoenwaelder , Martin Thomson , IETF Apps Discuss , draft-ietf-netmod-rfc6021-bis.all@tools.ietf.org, The IESG , netmod@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: Re: [netmod] [appsdir] Fwd: APPSDIR review of draft-ietf-netmod-rfc6021-bis-01 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, 02 May 2013 20:28:48 -0000 On 2 May 2013 00:41, Juergen Schoenwaelder wrote: > On Tue, Apr 30, 2013 at 12:29:02PM -0700, Martin Thomson wrote: >> One meta-comment. I don't consider the contents of RFC 6021 to have >> any bearing on the review of this document. I'm not familiar with >> 6021, so I consider all of this to be new. > > But most of the definitions are not new and I am reluctant to make > changes to published RFC text. I thought that was the purpose of revising an RFC. If you were just looking to add types, an update might be more appropriate. > If you mean by "second" the ipv6-address-no-zone typedef, please see > my response to Joel. This is a type derived from ipv6-address. Ahh, both patterns apply. My mistake; I had assumed OR (like XML schema), not AND. Interesting approach. From ietfdbh@comcast.net Thu May 2 15:20: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 0501921F8976 for ; Thu, 2 May 2013 15:20:20 -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.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, 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 Og73PYw+GRml for ; Thu, 2 May 2013 15:20:14 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id F092921F8B38 for ; Thu, 2 May 2013 15:20:13 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta05.westchester.pa.mail.comcast.net with comcast id Wz5Q1l0081GhbT855ALDNc; Thu, 02 May 2013 22:20:13 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta07.westchester.pa.mail.comcast.net with comcast id XALC1l00n2yZEBF3TALCQ4; Thu, 02 May 2013 22:20:13 +0000 From: "ietfdbh" To: "'Andy Bierman'" References: <038d01ce4730$3e9e5810$bbdb0830$@comcast.net> <20130502.150226.786661102583726170.mbj@tail-f.com> <20130502.152259.1658227545250854956.mbj@tail-f.com> <039d01ce4753$4a540100$defc0300$@comcast.net> <20130502170603.GA1819@elstar.local> <03a101ce4766$20deed40$629cc7c0$@comcast.net> In-Reply-To: Date: Thu, 2 May 2013 18:20:13 -0400 Message-ID: <03dd01ce4783$37f60140$a7e203c0$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03DE_01CE4761.B0E68420" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKj4EuW3JnDOSjd6eyjup9w3aS6bAKmQnJPAadVzCoB8MpcdQHonV4KAwvCXV8BwMTV3QFX4WngArlOhBGWvxsDcA== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367533213; bh=qcSYZLk4fQJqeJrkgRcWe1wchKLR/usw3XbaiDSBLkU=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=Ubf87/uWoXYAROeil3hidKBq6F9TOPJwHpgqeXhlImbEDqbrkPFmdIIG90zIELi3n PKAdMtRo/DjdDL1Ms+cFGprS5z/RSadlfbb3lm+jlz7GZFKbkX4lHTPobPdJzhMj6o pY+cmpIzi2R+Rr6td5lvhHHSA6ewJhZd4tPJr0Sswaa6cIdW/p9Zj4oEZaVsypAoSV I5qdHOdFGlpfdhttOGGluo2I2LQKz4HvvdlCq4/Xy4/MTn4u+Aknlg+6cxjt3oyPrX oXfGcXDWmVwofakjwBXrVDYd9Zhu61L2qxndKG6+06P+ku4WDfrtUX2ZXGQOADPa48 zx3n3lT4JDpEw== Cc: netmod@ietf.org Subject: Re: [netmod] Last Call: (A YANG Data Model for Interface Management) to Proposed Standard 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, 02 May 2013 22:20:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03DE_01CE4761.B0E68420 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, From: Andy Bierman [mailto:andy@yumaworks.com] Looking over the RowStatus and StorageType TCs, it seems to be implied that the "mirror" model for NV-storage is used. Unless explicitly stated otherwise, when a row is activated and intended to persist, it is assumed to be saved automatically. NETCONF servers using the :startup capability do not follow this persistence model. So we narrow the scope further to NETCONF servers running without an explicit startup config. [dbh>] I think both cases are in scope, but have different solutions. For implementations with :startup, we should advise operators that they are responsible to provide persistence by explicitly writing to :startup. For :startup-less implementations, we need to specify the persistence of the relevant :running config objects. IMO, if the semantics of a MIB object call for something different, then it is an implementation detail to make sure the NETCONF/YANG version is correct. [dbh>] If the YANG module documentation doesn't require specific semantics, then why would any implementation choice be incorrect? i.e., any implementation choice would be correct for YANG, even if it wouldn't be correct for the MIB object implementation. Without specification, it becomes a matter of implementer choice/interpretation, which could lead to non-interoperability. Not a good thing for a standard. I think the YANG Usage Guidelines (RFC 6087) is the proper document to put guidelines for implementing YANG datastore objects for optimal coexistence with SNMP agents. [dbh>] Well, that's one place to provide general guidelines. But when an operator is dealing with inconsistent values/behaviors across NM interfaces, they are likely to look up the definitions of the relevant objects, not the YANG Usage Guidelines. [dbh>] Maybe we could just add an additional reference to each relevant object (config-true,MIB persistent), pointing to the co-existence section in YANG Usage Guidelines. [dbh>] I'm not quite sure what you think should be put into such a section. David Harrington ietfdbh@comcast.net +1-603-828-1401 ------=_NextPart_000_03DE_01CE4761.B0E68420 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

From:= = Andy Bierman [mailto:andy@yumaworks.com] =

Looking = over the RowStatus and StorageType TCs, it seems = to

be implied that the = "mirror" model for NV-storage is = used.

Unless explicitly = stated otherwise, when a row is activated

and intended to persist, it is assumed to be saved = automatically.

 

NETCONF servers using the :startup capability do not = follow this

persistence = model.  So we narrow the scope further to = NETCONF

servers running = without an explicit startup config.

[dbh>]

I think both cases are in scope, but have different = solutions.

For implementations with :startup, we should advise operators that = they are responsible to provide persistence by explicitly writing to = :startup.

For :startup-less implementations, we need to specify the persistence = of the relevant  :running config = objects.

 

IMO, if the semantics of a MIB object call for = something

different, then = it is an implementation detail to make sure

the NETCONF/YANG version is correct.

[dbh>] If the YANG module documentation doesn’t require = specific semantics, then why would any implementation choice be = incorrect?

i.e., any implementation choice would be correct for YANG, even if it = wouldn’t be correct for the MIB object = implementation.

Without specification, it becomes a matter of implementer = choice/interpretation, which could lead to = non-interoperability.

Not a good thing for a standard.

 

I = think the YANG Usage Guidelines (RFC 6087) is the = proper

document to put = guidelines for implementing YANG datastore

objects for optimal coexistence with SNMP = agents.

[dbh>] Well, that’s one place to provide general = guidelines.

But when an operator is dealing with inconsistent values/behaviors = across NM interfaces, they are likely to look up the definitions of the = relevant objects, not the YANG Usage Guidelines.

[dbh>] Maybe we could just add an additional reference = to each relevant object (config-true,MIB persistent), pointing to the = co-existence section in YANG Usage Guidelines.

[dbh>] I’m not quite sure what you think should be put into = such a section.

 

David Harrington

ietfdbh@comcast.net

+1-603-828-1401

 

------=_NextPart_000_03DE_01CE4761.B0E68420-- From andy@yumaworks.com Thu May 2 15:44: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 CD4D621F86FA for ; Thu, 2 May 2013 15:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghhD5zuuOX3M for ; Thu, 2 May 2013 15:44:23 -0700 (PDT) Received: from mail-ia0-x232.google.com (mail-ia0-x232.google.com [IPv6:2607:f8b0:4001:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id E5D2E21F86B9 for ; Thu, 2 May 2013 15:44:22 -0700 (PDT) Received: by mail-ia0-f178.google.com with SMTP id t29so875555iag.23 for ; Thu, 02 May 2013 15:44:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=qRugI6IlO1xie3ucVMdVNzcZRdyF9K1CU03UYtNT0Jo=; b=cAUL1mS01rZDbU4OC0Pqp7G2iA69djBwYEZSe7EacdBXY1Hs10DP+GCskFITzzj5nA WrqR+yWMbQvy8JLIjmIf4TghGWVXJq9M3u9RJ0IxeIdJtpTE7qSbf8zI2MaSPdZaeUqH 3mUTSsq+YFtmSBPn7ycjzIwU43BFNuFQPj30Jdb6axCkDFGtdTS54WvjydRkaQV27nKu Jl4ccVl8/iUxKmuaMDmrok6jlfpaUH9lCKKKEwTy3gWfmNxsc/7/R7z3EbbgEcCUCxWR aFBGTwxoX7A33+AkhwzDk1Sugep4yxU+nH1jwYfLcfRyAgltBIPlr2HfdhVMVaXjfI8n Sxjg== MIME-Version: 1.0 X-Received: by 10.50.236.100 with SMTP id ut4mr15131048igc.86.1367534662490; Thu, 02 May 2013 15:44:22 -0700 (PDT) Received: by 10.231.125.202 with HTTP; Thu, 2 May 2013 15:44:22 -0700 (PDT) In-Reply-To: <03dd01ce4783$37f60140$a7e203c0$@comcast.net> References: <038d01ce4730$3e9e5810$bbdb0830$@comcast.net> <20130502.150226.786661102583726170.mbj@tail-f.com> <20130502.152259.1658227545250854956.mbj@tail-f.com> <039d01ce4753$4a540100$defc0300$@comcast.net> <20130502170603.GA1819@elstar.local> <03a101ce4766$20deed40$629cc7c0$@comcast.net> <03dd01ce4783$37f60140$a7e203c0$@comcast.net> Date: Thu, 2 May 2013 15:44:22 -0700 Message-ID: From: Andy Bierman To: ietfdbh Content-Type: multipart/alternative; boundary=14dae9399de3c6c8d904dbc3f90e X-Gm-Message-State: ALoCoQmv+eTfduwA0gm67D/BVTENSHljMqeznJ1tb+nhFGwm+tjqE5nFTahJ8CvBd06fbybI5D5s Cc: netmod@ietf.org Subject: Re: [netmod] Last Call: (A YANG Data Model for Interface Management) to Proposed Standard 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, 02 May 2013 22:44:23 -0000 --14dae9399de3c6c8d904dbc3f90e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, May 2, 2013 at 3:20 PM, ietfdbh wrote: > Hi,**** > > ** ** > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > > **** > > Looking over the RowStatus and StorageType TCs, it seems to**** > > be implied that the "mirror" model for NV-storage is used.**** > > Unless explicitly stated otherwise, when a row is activated**** > > and intended to persist, it is assumed to be saved automatically.**** > > ** ** > > NETCONF servers using the :startup capability do not follow this**** > > persistence model. So we narrow the scope further to NETCONF**** > > servers running without an explicit startup config.**** > > *[dbh>] * > > *I think both cases are in scope, but have different solutions.* > > *For implementations with :startup, we should advise operators that they > are responsible to provide persistence by explicitly writing to :startup.= * > > *For :startup-less implementations, we need to specify the persistence of > the relevant :running config objects.* > > ** > There is nothing extra to say in the YANG object definitions. NETCONF defines when the running configuration is saved to NV-storage. > ** > > IMO, if the semantics of a MIB object call for something**** > > different, then it is an implementation detail to make sure**** > > the NETCONF/YANG version is correct.**** > > *[dbh>] If the YANG module documentation doesn=92t require specific > semantics, then why would any implementation choice be incorrect?* > > *i.e., any implementation choice would be correct for YANG, even if it > wouldn=92t be correct for the MIB object implementation.* > > *Without specification, it becomes a matter of implementer > choice/interpretation, which could lead to non-interoperability.* > > *Not a good thing for a standard.***** > > ** > If SNMP and SMIv2 are silent about when/how active objects are saved to NV-storage, then SNMP implementations are free to do whatever they want. I think the YANG module applies to NETCONF only. RFC 6241 says how to save config=3Dtrue data nodes. I don't see why the YANG definition should couple together the NETCONF and SNMP persistence models. Since SNMP has no way to access what is in the startup config it is hard to see how it can get out of synch with NETCONF. Maybe if you could provide some OLD and NEW text for a YANG leaf that needs to be changed, your concerns would be more clear. Andy > ** > > I think the YANG Usage Guidelines (RFC 6087) is the proper**** > > document to put guidelines for implementing YANG datastore**** > > objects for optimal coexistence with SNMP agents.**** > > *[dbh>] Well, that=92s one place to provide general guidelines.* > > *But when an operator is dealing with inconsistent values/behaviors > across NM interfaces, they are likely to look up the definitions of the > relevant objects, not the YANG Usage Guidelines.***** > > *[dbh>] *Maybe we could just add an additional reference to each relevant > object (config-true,MIB persistent), pointing to the co-existence section > in YANG Usage Guidelines.**** > > *[dbh>] I=92m not quite sure what you think should be put into such a > section.***** > > ** ** > > David Harrington**** > > ietfdbh@comcast.net**** > > +1-603-828-1401**** > > ** ** > --14dae9399de3c6c8d904dbc3f90e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Thu, May 2, 2013 at 3:20 PM, ietfdbh = <ietfdbh@comcast.net> wrote:

Hi,

=A0<= /p>

From: Andy Bierman [mailto:andy@yumaworks.com]

Looking over= the RowStatus and StorageType TCs, it seems to

be implied that the "mirror" model for NV= -storage is used.

Unless explicitly stated otherwise, when = a row is activated

and i= ntended to persist, it is assumed to be saved automatically.<= /p>

=A0

NETCONF servers using the :startup capability do not follow = this

persistence model. = =A0So we narrow the scope further to NETCONF

servers running without an explicit start= up config.

[dbh>]

I think both cases = are in scope, but have different solutions.

For implementations= with :startup, we should advise operators that they are responsible to pro= vide persistence by explicitly writing to :startup.

For :startup-less i= mplementations, we need to specify the persistence of the relevant =A0:runn= ing config objects.

=A0


There is nothing extra to say in the YANG obj= ect definitions.
NETCONF defines when the running configuration i= s saved
to NV-storage.


=A0

IM= O, if the semantics of a MIB object call for something

different, then it is an implementation deta= il to make sure

the NETCONF/YANG version is correct.

[dbh&g= t;] If the YANG module documentation doesn=92t require specific semantics, = then why would any implementation choice be incorrect?=

i.e., any implement= ation choice would be correct for YANG, even if it wouldn=92t be correct fo= r the MIB object implementation.

Without specificati= on, it becomes a matter of implementer choice/interpretation, which could l= ead to non-interoperability.

Not a good thing fo= r a standard.

=A0


If SNMP and SMIv2 are silent about when/how a= ctive objects are
saved to NV-storage, then SNMP implementations = are free to do
whatever they want.

I think the YANG module a= pplies to NETCONF only.
RFC 6241 says how to save config=3Dtrue d= ata nodes.

I don't see why the YANG definition= should couple together
the NETCONF and SNMP persistence models. =A0Since SNMP
has n= o way to access what is in the startup config it is hard
to see h= ow it can get out of synch with NETCONF.

Maybe if = you could provide some OLD and NEW text for
a YANG leaf that needs to be changed, your concerns would
be= more clear.


Andy


=A0

I think the YAN= G Usage Guidelines (RFC 6087) is the proper

document to put guidelines for implementing YANG datastore

objects for optimal coexistence with SNM= P agents.

[dbh>] Well, that=92s one place to provide general guidelines.

But when an operato= r is dealing with inconsistent values/behaviors across NM interfaces, they = are likely to look up the definitions of the relevant objects, not the YANG= Usage Guidelines.<= /span>

[dbh&= gt;] Maybe we could just add a= n additional reference to each relevant object (config-true,MIB persistent)= , pointing to the co-existence section in YANG Usage Guidelines.<= /u>

[dbh>] I=92m not= quite sure what you think should be put into such a section.

=A0

David Harrington

ietfdbh@comcast.net

+1-603-828-1401

=A0


--14dae9399de3c6c8d904dbc3f90e-- From j.schoenwaelder@jacobs-university.de Fri May 3 01:16: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 A36DF21F9418; Fri, 3 May 2013 01:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRNLKVWDIC-v; Fri, 3 May 2013 01:16:12 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id EE38F21F949A; Fri, 3 May 2013 01:16:11 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0E0B520C27; Fri, 3 May 2013 10:16:11 +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 SvNMVkHH-y75; Fri, 3 May 2013 10:16:10 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 498FC20C26; Fri, 3 May 2013 10:16:10 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E4B1925F2630; Fri, 3 May 2013 10:16:08 +0200 (CEST) Date: Fri, 3 May 2013 10:16:08 +0200 From: Juergen Schoenwaelder To: Martin Thomson Message-ID: <20130503081608.GA4483@elstar.local> Mail-Followup-To: Martin Thomson , IETF Apps Discuss , draft-ietf-netmod-rfc6021-bis.all@tools.ietf.org, The IESG , netmod@ietf.org References: <6.2.5.6.2.20130428233426.0b62fed0@elandnews.com> <20130430083206.GD46852@elstar.local> <20130502074157.GA4935@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: draft-ietf-netmod-rfc6021-bis.all@tools.ietf.org, netmod@ietf.org, The IESG , IETF Apps Discuss Subject: Re: [netmod] [appsdir] Fwd: APPSDIR review of draft-ietf-netmod-rfc6021-bis-01 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: Fri, 03 May 2013 08:16:19 -0000 On Thu, May 02, 2013 at 01:28:46PM -0700, Martin Thomson wrote: > On 2 May 2013 00:41, Juergen Schoenwaelder > wrote: > > On Tue, Apr 30, 2013 at 12:29:02PM -0700, Martin Thomson wrote: > >> One meta-comment. I don't consider the contents of RFC 6021 to have > >> any bearing on the review of this document. I'm not familiar with > >> 6021, so I consider all of this to be new. > > > > But most of the definitions are not new and I am reluctant to make > > changes to published RFC text. > > I thought that was the purpose of revising an RFC. If you were just > looking to add types, an update might be more appropriate. The new types go into existing YANG module and this requires to republish the whole module. This is what we have been doing >20 years for MIB modules - so there is experience with this. > > If you mean by "second" the ipv6-address-no-zone typedef, please see > > my response to Joel. This is a type derived from ipv6-address. > > Ahh, both patterns apply. My mistake; I had assumed OR (like XML > schema), not AND. Interesting approach. In XML schema, you have both: If multiple element information items appear as [children] of a , the [value]s should be combined as if they appeared in a single ·regular expression· as separate ·branch·es. Note: It is a consequence of the schema representation constraint Multiple patterns (§4.3.4.3) and of the rules for ·restriction· that ·pattern· facets specified on the same step in a type derivation are ORed together, while ·pattern· facets specified on different steps of a type derivation are ANDed together. I believe YANG is actually following XML schema here. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bclaise@cisco.com Fri May 3 01:33: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 4CA4A21F9457 for ; Fri, 3 May 2013 01:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.48 X-Spam-Level: X-Spam-Status: No, score=-10.48 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8Btn1bINxyj for ; Fri, 3 May 2013 01:32:56 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id C04E821F94FD for ; Fri, 3 May 2013 01:32:55 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r438Wkn1019900; Fri, 3 May 2013 10:32:46 +0200 (CEST) Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r438W03i022483; Fri, 3 May 2013 10:32:15 +0200 (CEST) Message-ID: <51837600.3010303@cisco.com> Date: Fri, 03 May 2013 10:32:00 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: ietfdbh , "'Romascanu, Dan (Dan)'" , "'Martin Bjorklund'" , netmod@ietf.org References: <20130427.093659.369612374.mbj@tail-f.com> <20130430.122049.1111664509032933339.mbj@tail-f.com> <517FA5E3.2010604@cisco.com> <20130430.132943.828559691589933098.mbj@tail-f.com> <9904FB1B0159DA42B0B887B7FA8119CA0D9840@AZ-FFEXMB04.global.avaya.com> <036001ce46ad$aed16c90$0c7445b0$@comcast.net> <20130502080941.GB5077@elstar.local> In-Reply-To: <20130502080941.GB5077@elstar.local> Content-Type: multipart/alternative; boundary="------------040209050205070602080309" Subject: Re: [netmod] Last Call: (A YANG Data Model for Interface Management) to Proposed Standard 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, 03 May 2013 08:33:00 -0000 This is a multi-part message in MIME format. --------------040209050205070602080309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2/05/2013 10:09, Juergen Schoenwaelder wrote: > On Wed, May 01, 2013 at 04:51:41PM -0400, ietfdbh wrote: >> Hi, >> >> >>> -----Original Message----- >>> From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On >>> Behalf Of Martin Bjorklund >>> >>>> - what should an NM application or operator do if the YANG >>>> oper-status >>>> - and the IF-MIB operStatus differ? >>> I need help also with this one. I do not understand the problem, so I >>> cannot suggest a solution :( >>> >> [[DR]] The problem is that if both NETCONF and SNMP implementations exist on >> the device and the operator reads both, he needs an indication about what >> takes precedence in case of inconsistency. >> [dbh>] I think that "what takes precedence?" is not something we can answer >> in the data model; that will be implementation dependent. >> I think what is needed is an "operational consideration" that says "the >> status and counters in SNMP and the status and counters in NETCONF might be >> different." > No, the counters as they are defined are the same. And note, some of > them also exist in IPFIX. Multiple protocols to access the counters > are a long time reality, even multiple standards track protocols. I do > not recall having read IPFIX operational considerations discussing why > some information elements might have a different accuracy as what you > might get form an SNMP implementation. IPFIX is not supposed to be replacing SNMP, while NETCONF could be replacing SNMP. Or at least used in parallel. ingressInterface, http://www.iana.org/assignments/ipfix/ipfix.xml The index of the IP interface where packets of this Flow are being received. The value matches the value of managed object 'ifIndex' as defined in [RFC2863]. Note that ifIndex values are not assigned statically to an interface and that the interfaces may be renumbered every time the device's management system is re-initialized, as specified in [RFC2863]. Regards, Benoit > >> It could be good to explain that SNMP and NETCONF and CLI counters are >> typically just front-ends for hardware or OS status/counters (as in >> Juergen's email explanation). > OK > >> But there is no MUST that says these counters MUST simply be front-ends for >> hardware/OS counters. For example, as Juergen points out, SNMP counters are >> sometimes cached. > The cache does not change the semantics of the counters or introduce > new counters. The cache and the way the SNMP protocol works adds > sometimes surprising timing delays. So it boils down to: > > Network management protocols such as SNMP, IPFIX, NETCONF, or > command line interfaces may differ in the time granularity in which > they provide access to the counters. > > Are we now going to add this to all future SNMP, IPFIX, NETCONF data > model documents? > >> SNMP counters are sometimes cached; CLI counters typically are not; Is it an >> implementation decision whether NETCONF counters match other counter >> interfaces? Let's say that someplace. >>>> - persistence >>> I don't think this document is the right place to describe the >>> persistency model for SNMP vs. NETCONF - if we do it here we probably >>> have to do it in all other data-model specific documents as well... >>> >> [[DR]]this is not an SNMP vs. NETCONF discussion, this is a specific >> data-model specification to understand what objects in the specific data >> model must be kept persistent. And yes, all data-model documents should >> specify this, if they do not the assumption is that all is lost on reboot >> (if this is not written some place it should be IMO) >> >> >> [dbh>] I think the data model should specify the persistence of the data >> objects in this model, most notably the config objects. Does each config >> object persist across system reboots? Do some objects persist but not all? >> Is each YANG counter reinitialized on reboot, or are they expected to >> persist across reboots? >> Some of the YANG counters include a reference to IF-MIB counters. Do the >> YANG counters match the persistence specified in the corresponding MIB >> objects? >> If not, why not? (If this is an SNMP vs NETCONF difference, then is this >> documented in a NETCONF document someplace?) > Section 5.1 of RFC 6241 defines the configuration datastore > and Section 8.7 of RFC 6241 defines the configuration > datastore and how they are synced. > >> Having worked for a hardware vendor that also produced NM software, I am >> aware that sometimes a hardware counter is added to match a MIB standard >> required by customers. >> Whether that hardware counter persists often depends on what the standard >> requires. >> So if you will develop any YANG counters that are not mirrors of SNMP >> counters, how does the hardware designer know whether to make it persistent >> or not? >> This affects cross-vendor/cross-product interoperability. > Counters are typically config false objects and thus not > persistent. See also the definition of the counter datatypes in RFC > 6021. > > /js > --------------040209050205070602080309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 2/05/2013 10:09, Juergen Schoenwaelder wrote:
On Wed, May 01, 2013 at 04:51:41PM -0400, ietfdbh wrote:

Hi,



-----Original Message-----
From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On 
Behalf Of Martin Bjorklund


-  what should an NM application or operator do if the YANG 
oper-status
-  and the IF-MIB operStatus differ?

I need help also with this one.  I do not understand the problem, so I 
cannot suggest a solution :(


[[DR]] The problem is that if both NETCONF and SNMP implementations exist on
the device and the operator reads both, he needs an indication about what
takes precedence in case of inconsistency.
[dbh>] I think that "what takes precedence?" is not something we can answer
in the data model; that will be implementation dependent.
I think what is needed is an "operational consideration" that says "the
status and counters in SNMP and the status and counters in NETCONF might be
different."

No, the counters as they are defined are the same. And note, some of
them also exist in IPFIX. Multiple protocols to access the counters
are a long time reality, even multiple standards track protocols. I do
not recall having read IPFIX operational considerations discussing why
some information elements might have a different accuracy as what you
might get form an SNMP implementation.
IPFIX is not supposed to be replacing SNMP, while NETCONF could be replacing SNMP. Or at least used in parallel.

ingressInterface, http://www.iana.org/assignments/ipfix/ipfix.xml
The index of the IP interface where packets of this Flow
are being received.  The value matches the value of managed
object 'ifIndex' as defined in [RFC2863].
Note that ifIndex values are not assigned statically to an
interface and that the interfaces may be renumbered every
time the device's management system is re-initialized, as
specified in [RFC2863].
Regards, Benoit


It could be good to explain that SNMP and NETCONF and CLI counters are
typically just front-ends for hardware or OS status/counters (as in
Juergen's email explanation).

OK


But there is no MUST that says these counters MUST simply be front-ends for
hardware/OS counters. For example, as Juergen points out, SNMP counters are
sometimes cached.

The cache does not change the semantics of the counters or introduce
new counters. The cache and the way the SNMP protocol works adds
sometimes surprising timing delays. So it boils down to:

  Network management protocols such as SNMP, IPFIX, NETCONF, or
  command line interfaces may differ in the time granularity in which
  they provide access to the counters.

Are we now going to add this to all future SNMP, IPFIX, NETCONF data
model documents?


SNMP counters are sometimes cached; CLI counters typically are not; Is it an
implementation decision whether NETCONF counters match other counter
interfaces? Let's say that someplace.


      

        

          

            
- persistence


          

          
I don't think this document is the right place to describe the 
persistency model for SNMP vs. NETCONF - if we do it here we probably 
have to do it in all other data-model specific documents as well...



        

        
[[DR]]this is not an SNMP vs. NETCONF discussion, this is a specific
data-model specification to understand what objects in the specific data
model must be kept persistent. And yes, all data-model documents should
specify this, if they do not the assumption is that all is lost on reboot
(if this is not written some place it should be IMO)

  
[dbh>] I think the data model should specify the persistence of the data
objects in this model, most notably the config objects. Does each config
object persist across system reboots? Do some objects persist but not all?
Is each YANG counter reinitialized on reboot, or are they expected to
persist across reboots? 
Some of the YANG counters include a reference to IF-MIB counters. Do the
YANG counters match the persistence specified in the corresponding MIB
objects?
If not, why not? (If this is an SNMP vs NETCONF difference, then is this
documented in a NETCONF document someplace?)


      

      
Section 5.1 of RFC 6241 defines the <running> configuration datastore
and Section 8.7 of RFC 6241 defines the <startup> configuration
datastore and how they are synced.
 


      

        
Having worked for a hardware vendor that also produced NM software, I am
aware that sometimes a hardware counter is added to match a MIB standard
required by customers.
Whether that hardware counter persists often depends on what the standard
requires.
So if you will develop any YANG counters that are not mirrors of SNMP
counters, how does the hardware designer know whether to make it persistent
or not?
This affects cross-vendor/cross-product interoperability.


      

      
Counters are typically config false objects and thus not
persistent. See also the definition of the counter datatypes in RFC
6021.

/js



    

    

  


--------------040209050205070602080309--

From lhotka@nic.cz  Fri May  3 02:28: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 5B55121F905C for ; Fri,  3 May 2013 02:28:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.662
X-Spam-Level: 
X-Spam-Status: No, score=-1.662 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_64=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 GyPGJcid7bCE for ; Fri,  3 May 2013 02:28:08 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 4658B21F9026 for ; Fri,  3 May 2013 02:28:08 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 43A7713F9D9; Fri,  3 May 2013 11:28:06 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1367573286; bh=H3yBaTxl5LM6SUVBAXKlV4QRL4poiYi3r8zDlu/bFvY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=kVl9+74mzvEoey8xtBkjjIjartYcq5mNQhW04nWQolFAax/jyFTI4YDu3h7LA7x6d c4fOMCdmU1eE0OSbVuufsqrT3T0nIKGQKgxpal8Rv9o3SXPxHpKRJW9xsIIiE0NGA/ b6UkdOvyUPkInqv72kHg+kY7TycFscMe1jyls1b4=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Fri, 3 May 2013 11:28:04 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <038d01ce4730$3e9e5810$bbdb0830$@comcast.net> <20130502.150226.786661102583726170.mbj@tail-f.com>  <20130502.152259.1658227545250854956.mbj@tail-f.com>  <039d01ce4753$4a540100$defc0300$@comcast.net> <20130502170603.GA1819@elstar.local> <03a101ce4766$20deed40$629cc7c0$@comcast.net>  <03dd01ce4783$37f60140$a7e203c0$@comcast.net> 
To: Andy Bierman 
X-Mailer: Apple Mail (2.1503)
X-Virus-Scanned: clamav-milter 0.97.7 at mail
X-Virus-Status: Clean
Cc: ietfdbh , netmod@ietf.org
Subject: Re: [netmod] Last Call:  (A YANG Data Model for Interface Management) to Proposed Standard
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, 03 May 2013 09:28:09 -0000

On May 3, 2013, at 12:44 AM, Andy Bierman  wrote:

>=20
>=20
> On Thu, May 2, 2013 at 3:20 PM, ietfdbh  wrote:
> Hi,
>=20
> =20
>=20
> From: Andy Bierman [mailto:andy@yumaworks.com]=20
>=20
>=20
> Looking over the RowStatus and StorageType TCs, it seems to
>=20
> be implied that the "mirror" model for NV-storage is used.
>=20
> Unless explicitly stated otherwise, when a row is activated
>=20
> and intended to persist, it is assumed to be saved automatically.
>=20
> =20
>=20
> NETCONF servers using the :startup capability do not follow this
>=20
> persistence model.  So we narrow the scope further to NETCONF
>=20
> servers running without an explicit startup config.
>=20
> [dbh>]
>=20
> I think both cases are in scope, but have different solutions.
>=20
> For implementations with :startup, we should advise operators that =
they are responsible to provide persistence by explicitly writing to =
:startup.
>=20
> For :startup-less implementations, we need to specify the persistence =
of the relevant  :running config objects.
>=20
> =20
>=20
>=20
> There is nothing extra to say in the YANG object definitions.
> NETCONF defines when the running configuration is saved
> to NV-storage.
>=20
>=20
> =20
>=20
> IMO, if the semantics of a MIB object call for something
>=20
> different, then it is an implementation detail to make sure
>=20
> the NETCONF/YANG version is correct.
>=20
> [dbh>] If the YANG module documentation doesn=92t require specific =
semantics, then why would any implementation choice be incorrect?
>=20
> i.e., any implementation choice would be correct for YANG, even if it =
wouldn=92t be correct for the MIB object implementation.
>=20
> Without specification, it becomes a matter of implementer =
choice/interpretation, which could lead to non-interoperability.
>=20
> Not a good thing for a standard.
>=20
> =20
>=20
>=20
> If SNMP and SMIv2 are silent about when/how active objects are
> saved to NV-storage, then SNMP implementations are free to do
> whatever they want.
>=20
> I think the YANG module applies to NETCONF only.
> RFC 6241 says how to save config=3Dtrue data nodes.
>=20
> I don't see why the YANG definition should couple together
> the NETCONF and SNMP persistence models.  Since SNMP
> has no way to access what is in the startup config it is hard
> to see how it can get out of synch with NETCONF.

I agree. IMO we have to accept that, at boot time, the NV memory used by =
SNMP and NETCONF's startup datastore may contain different values for =
the same parameter. It is up to an admin to arrange things so that the =
system operates predictably.

Lada
=20
>=20
> Maybe if you could provide some OLD and NEW text for
> a YANG leaf that needs to be changed, your concerns would
> be more clear.
>=20
>=20
> Andy
>=20
>=20
> =20
>=20
> I think the YANG Usage Guidelines (RFC 6087) is the proper
>=20
> document to put guidelines for implementing YANG datastore
>=20
> objects for optimal coexistence with SNMP agents.
>=20
> [dbh>] Well, that=92s one place to provide general guidelines.
>=20
> But when an operator is dealing with inconsistent values/behaviors =
across NM interfaces, they are likely to look up the definitions of the =
relevant objects, not the YANG Usage Guidelines.
>=20
> [dbh>] Maybe we could just add an additional reference to each =
relevant object (config-true,MIB persistent), pointing to the =
co-existence section in YANG Usage Guidelines.
>=20
> [dbh>] I=92m not quite sure what you think should be put into such a =
section.
>=20
> =20
>=20
> David Harrington
>=20
> ietfdbh@comcast.net
>=20
> +1-603-828-1401
>=20
> =20
>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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





From ietfc@btconnect.com  Fri May  3 06:48: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 B336221F8E6B for ; Fri,  3 May 2013 06:48:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 gNGqhbqEprFn for ; Fri,  3 May 2013 06:48:52 -0700 (PDT)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA5F21F961F for ; Fri,  3 May 2013 06:48:52 -0700 (PDT)
Received: from mail161-va3-R.bigfish.com (10.7.14.252) by VA3EHSOBE014.bigfish.com (10.7.40.64) with Microsoft SMTP Server id 14.1.225.23; Fri, 3 May 2013 13:48:51 +0000
Received: from mail161-va3 (localhost [127.0.0.1])	by mail161-va3-R.bigfish.com (Postfix) with ESMTP id 577B42A0618; Fri,  3 May 2013 13:48:51 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.249.85; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0710HT005.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -24
X-BigFish: PS-24(zz98dI9371I148cI542I1432I1418I4015I179dNzz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz17326ah8275dh8275ch1033ILz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh304l1d11m1155h)
Received: from mail161-va3 (localhost.localdomain [127.0.0.1]) by mail161-va3 (MessageSwitch) id 1367588929723684_25212; Fri,  3 May 2013 13:48:49 +0000 (UTC)
Received: from VA3EHSMHS010.bigfish.com (unknown [10.7.14.247])	by mail161-va3.bigfish.com (Postfix) with ESMTP id A29F0C005B; Fri,  3 May 2013 13:48:49 +0000 (UTC)
Received: from AMSPRD0710HT005.eurprd07.prod.outlook.com (157.56.249.85) by VA3EHSMHS010.bigfish.com (10.7.99.20) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 3 May 2013 13:48:40 +0000
Received: from AMXPRD0310HT004.eurprd03.prod.outlook.com (157.56.248.133) by pod51017.outlook.com (10.255.160.168) with Microsoft SMTP Server (TLS) id 14.16.305.3; Fri, 3 May 2013 13:48:32 +0000
Message-ID: <016701ce4804$302c4600$4001a8c0@gateway.2wire.net>
From: t.petch 
To: ietfdbh , 'Juergen Schoenwaelder' 
References: <038d01ce4730$3e9e5810$bbdb0830$@comcast.net><20130502.150226.786661102583726170.mbj@tail-f.com><20130502.152259.1658227545250854956.mbj@tail-f.com><039d01ce4753$4a540100$defc0300$@comcast.net><20130502170603.GA1819@elstar.local> <03a101ce4766$20deed40$629cc7c0$@comcast.net>
Date: Fri, 3 May 2013 14:42:18 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.248.133]
X-FOPE-CRA-SourceIpAddress: 157.56.249.85
X-FOPE-CRA-DRYRUN: 1207119;1
X-FOPE-BFA-SENDER: ietfc@btconnect.com
X-FOPE-BFA-RECEIVER: netmod@ietf.org
X-FOPE-BFA-RECEIVER: j.schoenwaelder@jacobs-university.de
X-FOPE-BFA-RECEIVER: ietfdbh@comcast.net
X-OriginatorOrg: btconnect.com
Cc: netmod@ietf.org
Subject: Re: [netmod] Last Call: (A YANG Data Model for Interface Management) to Proposed Standard
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, 03 May 2013 13:48:57 -0000

----- Original Message -----
From: "ietfdbh" 
To: "'Juergen Schoenwaelder'" 
Cc: 
Sent: Thursday, May 02, 2013 7:51 PM
> Hi Juergen,
>
> Hmmm. Thanks for asking me this question.
> I think all counters, being read-only, reset on reboot since reboot is
a
> fundamental discontinuity.
> So counters would be off the table in these discussions of reboot
> persistence.

My head hurts (too many balls bouncing around).

I had thought that Netconf split configuration from state data.

And I thought that state data is the additional data on a system that is
not
   configuration data such as read-only status information and collected
   statistics.

And I thought that we were discussing interface configuration.

Therefore I thought that this discussion became ultra vires a few
hundred posts ago.

Where have I gone wrong?

Not that the persistence of statistics is not an important subject but I
think that there are far bigger gorillas in the room that are being
ignored.

Tom Petch

ps Sorry David, nothing to to with dbh, just the e-mail at which I gave
up.
>
> Thanks for narrowing the scope.
>
> It's the read-write MIB objects that can be SET by an
operator/application
> that might require persistence across reboots.
> And it's only config-true YANG objects that map to persistent MIB
objects
> that are a real concern here.
> So we can narrow the scope of discussion even further.
>
> I think there are not that many MIB objects that MUST persist, but
they do
> pop up here and there.
> So I think we will need to deal with them whenever there is a
config-true
> YANG object mapping to one of these persistent MIB objects.
> NM interfaces that don't modify managed objects, such as IPFIX and
Syslog ,
> would avoid this issue.
> CLI isn't IETF-standardized so we can't address this very well.
> So, for our purposes, I think we only need to talk about YANG and
read-write
> MIB model (or NETCONF/XML and MIB) co-existence.
>
> (I'm a bit concerned about new efforts, such as SACM, that might try
to
> write their own config data models in XML or something, but that's a
> discussion for a different forum.)
>
> David Harrington
> ietfdbh@comcast.net
> +1-603-828-1401
>
> -----Original Message-----
> From: Juergen Schoenwaelder
[mailto:j.schoenwaelder@jacobs-university.de]
> Sent: Thursday, May 02, 2013 1:06 PM
> To: ietfdbh
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Last Call:

> (A YANG Data Model for Interface Management) to Proposed Standard
>
> On Thu, May 02, 2013 at 12:37:08PM -0400, ietfdbh wrote:
>
> > 2) the semantic requirements of 'description' and ifAlias are
> > different, even when they are mapped, especially the persistence
> > issue. The coexistence of SNMP and NETCONF might be worthy of its
own
> > discussion, because it will impact any MIB object declared in the
MIB
> > to be persistent that is mirrored in a YANG data model, where
> > persistence is different. It has become an IETF requirement that
> > persistence be discussed in MIB objects. At a minimum, any YANG data
> > object that tries to access the same underlying data object as a MIB
> > object (especially an IETF standard MIB object) that specifies
> > persistence constraints should probably discuss whether the
> > MIB-described persistence applies or not, to warn operators that
they
> > cannot expect the same semantics across the two data models. It
might
> > be possible to note this in the definition of counters in
YANG-types,
> > but it gets trickier for other types, such as configured text
strings
> > like ifAlias. (and not all MIB counters are persistent, so I think
it
> > really is an object-by-object issue.)
>
> David,
>
> can you point me to an example of an IETF standards-track SNMP counter
that
> is persistent? I understand you are talking about this in a broader
scope
> but since this counter argument continues to pop up, I like to know an
> example where this would matter.
>
> Thanks,
>
> /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 j.schoenwaelder@jacobs-university.de  Fri May  3 07:06: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 2CD1121F93B4 for ; Fri,  3 May 2013 07:06:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.949
X-Spam-Level: 
X-Spam-Status: No, score=-102.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_15=0.6, 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 e7-ojWSymKFe for ; Fri,  3 May 2013 07:06:15 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id F082A21F8A0C for ; Fri,  3 May 2013 07:06:14 -0700 (PDT)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 10A7920C1E; Fri,  3 May 2013 16:06:14 +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 Qdcj0Mu4MUMR; Fri,  3 May 2013 16:06:13 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5436820BFC; Fri,  3 May 2013 16:06:13 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id B6D0925F5528; Fri,  3 May 2013 16:06:12 +0200 (CEST)
Date: Fri, 3 May 2013 16:06:12 +0200
From: Juergen Schoenwaelder 
To: "t.petch" 
Message-ID: <20130503140611.GC5424@elstar.local>
Mail-Followup-To: "t.petch" , ietfdbh , netmod@ietf.org
References: <038d01ce4730$3e9e5810$bbdb0830$@comcast.net> <20130502.150226.786661102583726170.mbj@tail-f.com>  <20130502.152259.1658227545250854956.mbj@tail-f.com>  <039d01ce4753$4a540100$defc0300$@comcast.net> <20130502170603.GA1819@elstar.local> <03a101ce4766$20deed40$629cc7c0$@comcast.net> <016701ce4804$302c4600$4001a8c0@gateway.2wire.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <016701ce4804$302c4600$4001a8c0@gateway.2wire.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: ietfdbh , netmod@ietf.org
Subject: Re: [netmod] Last Call: (A YANG Data Model for Interface Management) to Proposed Standard
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: Fri, 03 May 2013 14:06:20 -0000

On Fri, May 03, 2013 at 02:42:18PM +0100, t.petch wrote:
> ----- Original Message -----
> From: "ietfdbh" 
> To: "'Juergen Schoenwaelder'" 
> Cc: 
> Sent: Thursday, May 02, 2013 7:51 PM
> > Hi Juergen,
> >
> > Hmmm. Thanks for asking me this question.
> > I think all counters, being read-only, reset on reboot since reboot is
> a
> > fundamental discontinuity.
> > So counters would be off the table in these discussions of reboot
> > persistence.
> 
> My head hurts (too many balls bouncing around).
> 
> I had thought that Netconf split configuration from state data.
> 
> And I thought that state data is the additional data on a system that is
> not
>    configuration data such as read-only status information and collected
>    statistics.
> 
> And I thought that we were discussing interface configuration.
> 
> Therefore I thought that this discussion became ultra vires a few
> hundred posts ago.
> 
> Where have I gone wrong?

Check the document we are discussing. There are config false counters.
(And yes, likely any other SNMP counters, they are not persistent.)

/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  Fri May  3 07:29: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 7347321F93B4 for ; Fri,  3 May 2013 07:29:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D440Id4SOEtw for ; Fri,  3 May 2013 07:29:05 -0700 (PDT)
Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id DE49721F8681 for ; Fri,  3 May 2013 07:29:04 -0700 (PDT)
Received: by mail-ie0-f180.google.com with SMTP id ar20so1845525iec.25 for ; Fri, 03 May 2013 07:28:54 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=lX9DsvSB5kPZXC6npjKEItZe4VrzVM6BfqVgw5g0j/k=; b=leD23i7lsb/3PgiTAYsIhaFOqNE7Y4suGyL2WRMP+r/qYfVIvL4xXIHfthLZHSB343 li4r4Yi08CvPiw+ANCtFjyFpGOV3YB0e9TBk53GLq2lvnT4dXsbcgmhx2Fdt0y0jyAnQ 2w009AncutY9KaZ9xww7GGFW2l4rB6JWr3274sC79tNmQ8zRuPIwOffvd/ZpRBLDJKvq Q4xgeATz7YAlWKCOJKtjuPt28GqlpViKfXaCHX/PBx3yHvWB4mzFLx7+YDxER5/fR0ms +fMZ0fhB313NnXdY9c1QZB4qV++DRqTDKjxch6KIASnwk+f8Mp+SDr0gBmsVwdcSubIu sEwQ==
MIME-Version: 1.0
X-Received: by 10.50.170.36 with SMTP id aj4mr10070506igc.67.1367591334588; Fri, 03 May 2013 07:28:54 -0700 (PDT)
Received: by 10.231.125.202 with HTTP; Fri, 3 May 2013 07:28:54 -0700 (PDT)
In-Reply-To: 
References: <038d01ce4730$3e9e5810$bbdb0830$@comcast.net> <20130502.150226.786661102583726170.mbj@tail-f.com>  <20130502.152259.1658227545250854956.mbj@tail-f.com>  <039d01ce4753$4a540100$defc0300$@comcast.net> <20130502170603.GA1819@elstar.local> <03a101ce4766$20deed40$629cc7c0$@comcast.net>  <03dd01ce4783$37f60140$a7e203c0$@comcast.net>  
Date: Fri, 3 May 2013 07:28:54 -0700
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=e89a8f234a51b2477e04dbd12bd3
X-Gm-Message-State: ALoCoQnnRvIr1YVIk7Xa6HUQKgUB1+Z0x+bNzSKFmA1JHY8f9+0JO5oa/1csoyhV8BRos6tylyyZ
Cc: ietfdbh , netmod@ietf.org
Subject: Re: [netmod] Last Call:  (A YANG Data Model for Interface Management) to Proposed Standard
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, 03 May 2013 14:29:05 -0000

--e89a8f234a51b2477e04dbd12bd3
Content-Type: text/plain; charset=ISO-8859-1

....

> > I don't see why the YANG definition should couple together
> > the NETCONF and SNMP persistence models.  Since SNMP
> > has no way to access what is in the startup config it is hard
> > to see how it can get out of synch with NETCONF.
>
> I agree. IMO we have to accept that, at boot time, the NV memory used by
> SNMP and NETCONF's startup datastore may contain different values for the
> same parameter. It is up to an admin to arrange things so that the system
> operates predictably.
>
>
There is some assumption here that SNMP and NETCONF get their
config at boot-time from different sources.  That does not seem likely.
Without :startup, it seems a correct implementation should be in sync.
There are no issues for the standard.

With :startup, there seems to be a "contract violation" possible.
If SNMP does in fact specify "save to NV-storage right now"
and NETCONF :startup of course only writes to NV-storage
via the copy-config operation from the client, then who wins?
The server cannot honor both the MIB object and YANG object
semantics.

If SNMP/SMI is silent on NV-storage behavior, then
NETCONF/YANG wins (there is no SNMP contract
to break).


Lada
>
>
Andy

--e89a8f234a51b2477e04dbd12bd3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

....

> I don't see why the YANG definition should couple together

> the NETCONF and SNMP persistence models. =A0Since SNMP

> has no way to access what is in the startup config it is hard

> to see how it can get out of synch with NETCONF.



I agree. IMO we have to accept that, at boot time, the NV memory used by SN=
MP and NETCONF's startup datastore may contain different values for the=
 same parameter. It is up to an admin to arrange things so that the system =
operates predictably.




There is some assumption here that SNM=
P and NETCONF get their
config at boot-time from different source=
s. =A0That does not seem likely.
Without :startup, it seems a cor=
rect implementation should be in sync.


There are no issues for the standard.

With :s=
tartup, there seems to be a "contract violation" possible.
<=
div>If SNMP does in fact specify "save to NV-storage right now"

and NETCONF :startup of course only writes to NV-storage
via=
 the copy-config operation from the client, then who wins?
The se=
rver cannot honor both the MIB object and YANG object
semantics.<=
/div>


If SNMP/SMI is silent on NV-storage behavior, then
NETCONF/YANG wins (there is no SNMP contract
to break).




Lada



Andy



--e89a8f234a51b2477e04dbd12bd3--

From ietfc@btconnect.com  Fri May  3 10:35: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 1DB8821F8464 for ; Fri,  3 May 2013 10:35:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]
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 a836uX7aUWVy for ; Fri,  3 May 2013 10:35:41 -0700 (PDT)
Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0187.outbound.messaging.microsoft.com [213.199.154.187]) by ietfa.amsl.com (Postfix) with ESMTP id 0461521F9768 for ; Fri,  3 May 2013 10:11:40 -0700 (PDT)
Received: from mail47-db8-R.bigfish.com (10.174.8.248) by DB8EHSOBE017.bigfish.com (10.174.4.80) with Microsoft SMTP Server id 14.1.225.23; Fri, 3 May 2013 17:11:14 +0000
Received: from mail47-db8 (localhost [127.0.0.1])	by mail47-db8-R.bigfish.com (Postfix) with ESMTP id 8F2FBC206C0; Fri,  3 May 2013 17:11:14 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.254.197; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0711HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -15
X-BigFish: PS-15(zz9371I542I1432I1418Izz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz17326ah8275bh8275dh8275ch1033ILz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh304l1d11m1155h)
Received: from mail47-db8 (localhost.localdomain [127.0.0.1]) by mail47-db8 (MessageSwitch) id 1367601072976304_29213; Fri,  3 May 2013 17:11:12 +0000 (UTC)
Received: from DB8EHSMHS026.bigfish.com (unknown [10.174.8.243])	by mail47-db8.bigfish.com (Postfix) with ESMTP id E2C72580055; Fri,  3 May 2013 17:11:12 +0000 (UTC)
Received: from DB3PRD0711HT003.eurprd07.prod.outlook.com (157.56.254.197) by DB8EHSMHS026.bigfish.com (10.174.4.36) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 3 May 2013 17:11:11 +0000
Received: from AMXPRD0310HT002.eurprd03.prod.outlook.com (157.56.248.133) by pod51017.outlook.com (10.255.183.36) with Microsoft SMTP Server (TLS) id 14.16.305.3; Fri, 3 May 2013 17:11:11 +0000
Message-ID: <027e01ce4820$7f405940$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Juergen Schoenwaelder 
References: <038d01ce4730$3e9e5810$bbdb0830$@comcast.net> <20130502.150226.786661102583726170.mbj@tail-f.com>  <20130502.152259.1658227545250854956.mbj@tail-f.com>  <039d01ce4753$4a540100$defc0300$@comcast.net> <20130502170603.GA1819@elstar.local> <03a101ce4766$20deed40$629cc7c0$@comcast.net> <016701ce4804$302c4600$4001a8c0@gateway.2wire.net> <20130503140611.GC5424@elstar.local>
Date: Fri, 3 May 2013 18:05:10 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.248.133]
X-FOPE-CRA-SourceIpAddress: 157.56.254.197
X-FOPE-CRA-DRYRUN: 1207119;1
X-FOPE-BFA-SENDER: ietfc@btconnect.com
X-FOPE-BFA-RECEIVER: netmod@ietf.org
X-FOPE-BFA-RECEIVER: ietfdbh@comcast.net
X-FOPE-BFA-RECEIVER: j.schoenwaelder@jacobs-university.de
X-OriginatorOrg: btconnect.com
Cc: ietfdbh , netmod@ietf.org
Subject: Re: [netmod] Last Call: (A YANG Data Model for Interface Management) to Proposed Standard
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, 03 May 2013 17:35:47 -0000

----- Original Message -----
From: "Juergen Schoenwaelder" 
To: "t.petch" 
Cc: "ietfdbh" ; 
Sent: Friday, May 03, 2013 3:06 PM

> > My head hurts (too many balls bouncing around).
> >
> > I had thought that Netconf split configuration from state data.
> >
> > And I thought that state data is the additional data on a system
that is
> > not
> >    configuration data such as read-only status information and
collected
> >    statistics.
> >
> > And I thought that we were discussing interface configuration.
> >
> > Therefore I thought that this discussion became ultra vires a few
> > hundred posts ago.
> >
> > Where have I gone wrong?
>
> Check the document we are discussing. There are config false counters.
> (And yes, likely any other SNMP counters, they are not persistent.)

Juergen

Yes, I know that really (they got added in -06 and increased the size of
the document considerably:-).

But read sections one and two and three and four and I can see no
mention of this state data, you stumble across it only when you plough
into the detail later.  I think that this is an omission that needs
rectifying.  Netconf is very strong on the separation of configuration
and state and here we are, producing a basic module and bundling them up
together again  I think that that needs an explanation (which should
probably touch on persistent storage).

Tom Petch


>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         
>



From ietfc@btconnect.com  Fri May  3 10:35: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 694BD21F8FE3 for ; Fri,  3 May 2013 10:35:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]
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 t+vc9dIVTYx2 for ; Fri,  3 May 2013 10:35:47 -0700 (PDT)
Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0188.outbound.messaging.microsoft.com [213.199.154.188]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4F521F97B1 for ; Fri,  3 May 2013 10:11:37 -0700 (PDT)
Received: from mail213-db8-R.bigfish.com (10.174.8.250) by DB8EHSOBE021.bigfish.com (10.174.4.84) with Microsoft SMTP Server id 14.1.225.23; Fri, 3 May 2013 17:11:14 +0000
Received: from mail213-db8 (localhost [127.0.0.1])	by mail213-db8-R.bigfish.com (Postfix) with ESMTP id F18ABE0679; Fri,  3 May 2013 17:11:13 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.254.197; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0711HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -14
X-BigFish: PS-14(zz9371I542I1432Izz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz8275bh8275dh8275ch1033ILz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh304l1d11m1155h)
Received: from mail213-db8 (localhost.localdomain [127.0.0.1]) by mail213-db8 (MessageSwitch) id 1367601072504060_1688; Fri,  3 May 2013 17:11:12 +0000 (UTC)
Received: from DB8EHSMHS026.bigfish.com (unknown [10.174.8.243])	by mail213-db8.bigfish.com (Postfix) with ESMTP id 6E9623E0075; Fri,  3 May 2013 17:11:12 +0000 (UTC)
Received: from DB3PRD0711HT003.eurprd07.prod.outlook.com (157.56.254.197) by DB8EHSMHS026.bigfish.com (10.174.4.36) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 3 May 2013 17:11:11 +0000
Received: from AMXPRD0310HT002.eurprd03.prod.outlook.com (157.56.248.133) by pod51017.outlook.com (10.255.183.36) with Microsoft SMTP Server (TLS) id 14.16.305.3; Fri, 3 May 2013 17:11:10 +0000
Message-ID: <027d01ce4820$7efd35c0$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Andy Bierman , Ladislav Lhotka 
References: <038d01ce4730$3e9e5810$bbdb0830$@comcast.net><20130502.150226.786661102583726170.mbj@tail-f.com><20130502.152259.1658227545250854956.mbj@tail-f.com><039d01ce4753$4a540100$defc0300$@comcast.net><20130502170603.GA1819@elstar.local><03a101ce4766$20deed40$629cc7c0$@comcast.net><03dd01ce4783$37f60140$a7e203c0$@comcast.net> 
Date: Fri, 3 May 2013 17:58:01 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.248.133]
X-FOPE-CRA-SourceIpAddress: 157.56.254.197
X-FOPE-CRA-DRYRUN: 1207119;1
X-FOPE-BFA-SENDER: ietfc@btconnect.com
X-FOPE-BFA-RECEIVER: ietfdbh@comcast.net
X-FOPE-BFA-RECEIVER: netmod@ietf.org
X-FOPE-BFA-RECEIVER: andy@yumaworks.com
X-FOPE-BFA-RECEIVER: lhotka@nic.cz
X-OriginatorOrg: btconnect.com
Cc: ietfdbh , netmod@ietf.org
Subject: Re: [netmod] Last Call:  (A YANG Data Model for Interface Management) to Proposed Standard
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, 03 May 2013 17:35:53 -0000

----- Original Message -----
From: "Andy Bierman" 
To: "Ladislav Lhotka" 
Cc: "ietfdbh" ; 
Sent: Friday, May 03, 2013 3:28 PM
.
>
> > > I don't see why the YANG definition should couple together
> > > the NETCONF and SNMP persistence models.  Since SNMP
> > > has no way to access what is in the startup config it is hard
> > > to see how it can get out of synch with NETCONF.
> >
> > I agree. IMO we have to accept that, at boot time, the NV memory
used by
> > SNMP and NETCONF's startup datastore may contain different values
for the
> > same parameter. It is up to an admin to arrange things so that the
system
> > operates predictably.
> >
> >
> There is some assumption here that SNMP and NETCONF get their
> config at boot-time from different sources.  That does not seem
likely.
> Without :startup, it seems a correct implementation should be in sync.
> There are no issues for the standard.
>
> With :startup, there seems to be a "contract violation" possible.
> If SNMP does in fact specify "save to NV-storage right now"
> and NETCONF :startup of course only writes to NV-storage
> via the copy-config operation from the client, then who wins?
> The server cannot honor both the MIB object and YANG object
> semantics.
>
> If SNMP/SMI is silent on NV-storage behavior, then
> NETCONF/YANG wins (there is no SNMP contract
> to break).

Andy

One of my gorillas is this difference in the model underlying SMI and
Netconf.

SMI got round to being very specific as to whether or not an object is
in persistent storage (grep StorageType).

Netconf focusses on startup and writing to a configuration datastore but
does not go into persistence.  Look at RFC6241 with an innocent eye and
it really does not talk about persistence in the way that SMI came to
do.  I think this an omission which needs rectifying, this as one of the
differences in the underlying model (which I expect to catch people
out).

Tom Petch

>
> Lada
> >
> >
> Andy
>


------------------------------------------------------------------------
--------


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



From andy@yumaworks.com  Fri May  3 10:40: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 EAD0421F870F for ; Fri,  3 May 2013 10:40:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.822
X-Spam-Level: *
X-Spam-Status: No, score=1.822 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6,  J_CHICKENPOX_64=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBTQzzXYWvVy for ; Fri,  3 May 2013 10:40:00 -0700 (PDT)
Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1DC21F8F43 for ; Fri,  3 May 2013 10:29:17 -0700 (PDT)
Received: by mail-ie0-f182.google.com with SMTP id a14so2097488iee.13 for ; Fri, 03 May 2013 10:29:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=yDKyPdnYe4aWH/T8b36CMkmI6nevNBXKGAcgvFYnMAg=; b=S+8bj0PPr8E6m9I3Ok7eAwf2UcS80K70iahCSolik5s+G9mCj1Yhy7cMzhljshk4l9 KiDhtWgSlOODSao9INnu0lfRRfTzFHmyJtQOHFFlIrQ81pw6UY3cqVhRq0usiygqEWo2 9YCynz5O9NcEuSlqofHLhxBDso/UnUBNzqqzRahpiVG3lDG6HlV/6g8QxkEzXY5FMq13 WYbppbnWkkmCxK4NxxCamF5dOi0TqBDANMYzMA4ev+YEUh5g7rxZwxmU6IRcgsS2m9xB 1/9va6a/o5H6g318i5HLctO+s0JUu14WDYuBPplXb07gUkPdi9mlCtOO4aC+ByemYBUY RiqA==
MIME-Version: 1.0
X-Received: by 10.50.170.36 with SMTP id aj4mr10275217igc.67.1367602157389; Fri, 03 May 2013 10:29:17 -0700 (PDT)
Received: by 10.231.125.202 with HTTP; Fri, 3 May 2013 10:29:17 -0700 (PDT)
In-Reply-To: <027d01ce4820$7efd35c0$4001a8c0@gateway.2wire.net>
References: <038d01ce4730$3e9e5810$bbdb0830$@comcast.net> <20130502.150226.786661102583726170.mbj@tail-f.com>  <20130502.152259.1658227545250854956.mbj@tail-f.com>  <039d01ce4753$4a540100$defc0300$@comcast.net> <20130502170603.GA1819@elstar.local> <03a101ce4766$20deed40$629cc7c0$@comcast.net>  <03dd01ce4783$37f60140$a7e203c0$@comcast.net>    <027d01ce4820$7efd35c0$4001a8c0@gateway.2wire.net>
Date: Fri, 3 May 2013 10:29:17 -0700
Message-ID: 
From: Andy Bierman 
To: "t.petch" 
Content-Type: multipart/alternative; boundary=e89a8f234a51c91b5a04dbd3b0ad
X-Gm-Message-State: ALoCoQlBBLwXQjtSohJawcduqLWGl1TsHiO1P2HGW3KqR0uQv67AVwrQ5Rbd7PfTgJhkkd2pqDPc
Cc: ietfdbh , netmod@ietf.org
Subject: Re: [netmod] Last Call:  (A YANG Data Model for Interface Management) to Proposed Standard
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, 03 May 2013 17:40:01 -0000

--e89a8f234a51c91b5a04dbd3b0ad
Content-Type: text/plain; charset=ISO-8859-1

On Fri, May 3, 2013 at 9:58 AM, t.petch  wrote:

> ----- Original Message -----
> From: "Andy Bierman" 
> To: "Ladislav Lhotka" 
> Cc: "ietfdbh" ; 
> Sent: Friday, May 03, 2013 3:28 PM
> .
> >
> > > > I don't see why the YANG definition should couple together
> > > > the NETCONF and SNMP persistence models.  Since SNMP
> > > > has no way to access what is in the startup config it is hard
> > > > to see how it can get out of synch with NETCONF.
> > >
> > > I agree. IMO we have to accept that, at boot time, the NV memory
> used by
> > > SNMP and NETCONF's startup datastore may contain different values
> for the
> > > same parameter. It is up to an admin to arrange things so that the
> system
> > > operates predictably.
> > >
> > >
> > There is some assumption here that SNMP and NETCONF get their
> > config at boot-time from different sources.  That does not seem
> likely.
> > Without :startup, it seems a correct implementation should be in sync.
> > There are no issues for the standard.
> >
> > With :startup, there seems to be a "contract violation" possible.
> > If SNMP does in fact specify "save to NV-storage right now"
> > and NETCONF :startup of course only writes to NV-storage
> > via the copy-config operation from the client, then who wins?
> > The server cannot honor both the MIB object and YANG object
> > semantics.
> >
> > If SNMP/SMI is silent on NV-storage behavior, then
> > NETCONF/YANG wins (there is no SNMP contract
> > to break).
>
> Andy
>
> One of my gorillas is this difference in the model underlying SMI and
> Netconf.
>
> SMI got round to being very specific as to whether or not an object is
> in persistent storage (grep StorageType).
>
>
I am familiar with the StorageType TC.
It says that an entry can be expected to persist.
It does not say when the NV-copy is updated by the agent.

In NETCONF all config=true nodes are expected to persist.
If the :startup capability is present then this is a manual process.
If not, it is automatic (same as SNMP) and it is an implementation detail
how the server makes sure the value persists across a reboot.


Netconf focusses on startup and writing to a configuration datastore but
> does not go into persistence.  Look at RFC6241 with an innocent eye and
> it really does not talk about persistence in the way that SMI came to
> do.  I think this an omission which needs rectifying, this as one of the
> differences in the underlying model (which I expect to catch people
> out).
>

I've read RFC 6241 quite a few times, but you are right that there is no
explicit
section on the persistence model if :startup is not advertised.  It is
implied
in sec. 8.7.1 that the server automatically maintains the NV-storage
unless :startup is present.

It could be more clear in RFC 6241 that it is an implementation detail
how a server automatically retains configuration data across a reboot.


> Tom Petch
>
> >
> > Lada
> > >
> > >
> > Andy
> >
>
>
Andy

--e89a8f234a51c91b5a04dbd3b0ad
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Fri, May 3, 2013 at 9:58 AM, t.petch =
<ietfc@btconnect.com> wrote:

----- Original Message -----

From: "Andy Bierman" <an=
dy@yumaworks.com>

To: "Ladislav Lhotka" <lhotka=
@nic.cz>

Cc: "ietfdbh" <ietfdbh@=
comcast.net>; <netmod@ietf.org=
>

Sent: Friday, May 03, 2013 3:28 PM

.

>

> > > I don't see why the YANG definition should couple togeth=
er

> > > the NETCONF and SNMP persistence models. =A0Since SNMP

> > > has no way to access what is in the startup config it is har=
d

> > > to see how it can get out of synch with NETCONF.

> >

> > I agree. IMO we have to accept that, at boot time, the NV memory<=
br>
used by

> > SNMP and NETCONF's startup datastore may contain different va=
lues

for the

> > same parameter. It is up to an admin to arrange things so that th=
e

system

> > operates predictably.

> >

> >

> There is some assumption here that SNMP and NETCONF get their

> config at boot-time from different sources. =A0That does not seem

likely.

> Without :startup, it seems a correct implementation should be in sync.=


> There are no issues for the standard.

>

> With :startup, there seems to be a "contract violation" poss=
ible.

> If SNMP does in fact specify "save to NV-storage right now"<=
br>
> and NETCONF :startup of course only writes to NV-storage

> via the copy-config operation from the client, then who wins?

> The server cannot honor both the MIB object and YANG object

> semantics.

>

> If SNMP/SMI is silent on NV-storage behavior, then

> NETCONF/YANG wins (there is no SNMP contract

> to break).



Andy



One of my gorillas is this difference in the model underlying SMI and

Netconf.



SMI got round to being very specific as to whether or not an object is

in persistent storage (grep StorageType).



I am familiar with the StorageType TC.=

It says that an entry can be expected to persist.
It d=
oes not say when the NV-copy is updated by the agent.



In NETCONF all config=3Dtrue nodes are expected to persist.
=
If the :startup capability is present then this is a manual process.
<=
div>If not, it is automatic (same as SNMP) and it is an implementation deta=
il


how the server makes sure the value persists across a reboot.



Netconf focusses on startup and writing to a configuration datastore but
does not go into persistence. =A0Look at RFC6241 with an innocent eye and
it really does not talk about persistence in the way that SMI came to

do. =A0I think this an omission which needs rectifying, this as one of the<=
br>
differences in the underlying model (which I expect to catch people

out).

I've read RFC 6241 quite a fe=
w times, but you are right that there is no explicit
section on t=
he persistence model if :startup is not advertised. =A0It is implied


in sec. 8.7.1 that the server automatically maintains the NV-storage
unless :startup is present.

It could be m=
ore clear in RFC 6241 that it is an implementation detail
how a s=
erver automatically retains configuration data across a reboot.=A0






Tom Petch



>

> Lada

> >

> >

> Andy

>



Andy
=A0


--e89a8f234a51c91b5a04dbd3b0ad--

From j.schoenwaelder@jacobs-university.de  Fri May  3 11:46: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 E17FA21F8206 for ; Fri,  3 May 2013 11:46:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.649
X-Spam-Level: 
X-Spam-Status: No, score=-102.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_15=0.6, 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 Lp2rFdwnTLDW for ; Fri,  3 May 2013 11:46:35 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0666721F848A for ; Fri,  3 May 2013 11:46:25 -0700 (PDT)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 45D0220C27; Fri,  3 May 2013 20:46:22 +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 oSzuHprdqU9w; Fri,  3 May 2013 20:46:22 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 93BCF20BDD; Fri,  3 May 2013 20:46:21 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 143C025F5C84; Fri,  3 May 2013 20:46:21 +0200 (CEST)
Date: Fri, 3 May 2013 20:46:21 +0200
From: Juergen Schoenwaelder 
To: "t.petch" 
Message-ID: <20130503184621.GB6118@elstar.local>
Mail-Followup-To: "t.petch" , ietfdbh , netmod@ietf.org
References: <20130502.150226.786661102583726170.mbj@tail-f.com>  <20130502.152259.1658227545250854956.mbj@tail-f.com>  <039d01ce4753$4a540100$defc0300$@comcast.net> <20130502170603.GA1819@elstar.local> <03a101ce4766$20deed40$629cc7c0$@comcast.net> <016701ce4804$302c4600$4001a8c0@gateway.2wire.net> <20130503140611.GC5424@elstar.local> <027e01ce4820$7f405940$4001a8c0@gateway.2wire.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <027e01ce4820$7f405940$4001a8c0@gateway.2wire.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: ietfdbh , netmod@ietf.org
Subject: Re: [netmod] Last Call: (A YANG Data Model for Interface Management) to Proposed Standard
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: Fri, 03 May 2013 18:46:41 -0000

On Fri, May 03, 2013 at 06:05:10PM +0100, t.petch wrote:
> 
> But read sections one and two and three and four and I can see no
> mention of this state data, you stumble across it only when you plough
> into the detail later.  I think that this is an omission that needs
> rectifying.  Netconf is very strong on the separation of configuration
> and state and here we are, producing a basic module and bundling them up
> together again  I think that that needs an explanation (which should
> probably touch on persistent storage).
> 

Perhaps there is a need to better document NETCONF's persistency
model. I do not think this belongs into some arbitrary data model.

If you think something is missing in the introduction because there
are some counters, how about proposing some text?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From ietfc@btconnect.com  Fri May  3 13:03: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 D888921F86AE for ; Fri,  3 May 2013 13:03:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level: 
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[AWL=0.333,  BAYES_00=-2.599, J_CHICKENPOX_15=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 9UpCNjLf3vbO for ; Fri,  3 May 2013 13:03:02 -0700 (PDT)
Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0185.outbound.messaging.microsoft.com [213.199.154.185]) by ietfa.amsl.com (Postfix) with ESMTP id 024DB21F84CA for ; Fri,  3 May 2013 13:03:01 -0700 (PDT)
Received: from mail210-db8-R.bigfish.com (10.174.8.226) by DB8EHSOBE039.bigfish.com (10.174.4.102) with Microsoft SMTP Server id 14.1.225.23; Fri, 3 May 2013 20:03:00 +0000
Received: from mail210-db8 (localhost [127.0.0.1])	by mail210-db8-R.bigfish.com (Postfix) with ESMTP id A8D702E03D8; Fri,  3 May 2013 20:03:00 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.249.213; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0710HT002.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -16
X-BigFish: PS-16(zz98dI9371I542I1432I1418Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz17326ah8275bh8275dh8275ch1033ILz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh304l1d11m1155h)
Received: from mail210-db8 (localhost.localdomain [127.0.0.1]) by mail210-db8 (MessageSwitch) id 1367611378641807_7739; Fri,  3 May 2013 20:02:58 +0000 (UTC)
Received: from DB8EHSMHS011.bigfish.com (unknown [10.174.8.237])	by mail210-db8.bigfish.com (Postfix) with ESMTP id 90BF61C006B; Fri,  3 May 2013 20:02:58 +0000 (UTC)
Received: from AM2PRD0710HT002.eurprd07.prod.outlook.com (157.56.249.213) by DB8EHSMHS011.bigfish.com (10.174.4.21) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 3 May 2013 20:02:57 +0000
Received: from AMXPRD0310HT003.eurprd03.prod.outlook.com (157.56.248.133) by pod51017.outlook.com (10.255.165.37) with Microsoft SMTP Server (TLS) id 14.16.305.3; Fri, 3 May 2013 20:02:56 +0000
Message-ID: <036501ce4838$7dbe1220$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Juergen Schoenwaelder 
References: <20130502.150226.786661102583726170.mbj@tail-f.com>  <20130502.152259.1658227545250854956.mbj@tail-f.com>  <039d01ce4753$4a540100$defc0300$@comcast.net> <20130502170603.GA1819@elstar.local> <03a101ce4766$20deed40$629cc7c0$@comcast.net> <016701ce4804$302c4600$4001a8c0@gateway.2wire.net> <20130503140611.GC5424@elstar.local> <027e01ce4820$7f405940$4001a8c0@gateway.2wire.net> <20130503184621.GB6118@elstar.local>
Date: Fri, 3 May 2013 20:57:13 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.248.133]
X-FOPE-CRA-SourceIpAddress: 157.56.249.213
X-FOPE-CRA-DRYRUN: 1207119;1
X-FOPE-BFA-SENDER: ietfc@btconnect.com
X-FOPE-BFA-RECEIVER: netmod@ietf.org
X-FOPE-BFA-RECEIVER: j.schoenwaelder@jacobs-university.de
X-OriginatorOrg: btconnect.com
Cc: netmod@ietf.org
Subject: Re: [netmod] Last Call: (A YANG Data Model for Interface Management) to Proposed Standard
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, 03 May 2013 20:03:08 -0000

----- Original Message -----
From: "Juergen Schoenwaelder" 
To: "t.petch" 
Cc: "ietfdbh" ; 
Sent: Friday, May 03, 2013 7:46 PM
> On Fri, May 03, 2013 at 06:05:10PM +0100, t.petch wrote:
> >
> > But read sections one and two and three and four and I can see no
> > mention of this state data, you stumble across it only when you
plough
> > into the detail later.  I think that this is an omission that needs
> > rectifying.  Netconf is very strong on the separation of
configuration
> > and state and here we are, producing a basic module and bundling
them up
> > together again  I think that that needs an explanation (which should
> > probably touch on persistent storage).
> >
>
> Perhaps there is a need to better document NETCONF's persistency
> model. I do not think this belongs into some arbitrary data model.
>
> If you think something is missing in the introduction because there
> are some counters, how about proposing some text?

Abstract
NEW
**The model includes both configuration data and counters for the
collection of statistics.


Introduction at end
NEW
**The model includes both configuration data and counters for the
collection of statistics.


Objectives at end
NEW
   o  the data model should include (read-only) counters in order to
gather statistics for octets, packets and errors, sent and received

Tom Petch

>
> /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  Fri May  3 22:46: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 C164C21F9075 for ; Fri,  3 May 2013 22:46:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 1LihwRQngL-f for ; Fri,  3 May 2013 22:46:10 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id C7A7321F9057 for ; Fri,  3 May 2013 22:46:09 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id EE47713F94C; Sat,  4 May 2013 07:46:08 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1367646369; bh=VmRiUN2zFF6h1CuG/7XcehgUneof4tzy5vpbITen09A=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ERibaWhF0VOYS/d4I+75+kC9ZkpuR8bdqtxnhsccSleA24gzR2kR3UpYDjaChQi44 Q88OUBrLbJBvD10Wpd7jBYPptt8QqoNKHv3cnC/78u7jRqb4IMpKwUK6MyFSvU8tG0 sucMMcTh9n0Ph9wsqm0K2H8V9Q63h1lHKGuUqbPY=
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Content-Type: text/plain; charset=us-ascii
From: Ladislav Lhotka 
X-Priority: 3
In-Reply-To: <027e01ce4820$7f405940$4001a8c0@gateway.2wire.net>
Date: Sat, 4 May 2013 07:46:08 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <038d01ce4730$3e9e5810$bbdb0830$@comcast.net> <20130502.150226.786661102583726170.mbj@tail-f.com>  <20130502.152259.1658227545250854956.mbj@tail-f.com>  <039d01ce4753$4a540100$defc0300$@comcast.net> <20130502170603.GA1819@elstar.local> <03a101ce4766$20deed40$629cc7c0$@comcast.net> <016701ce4804$302c4600$4001a8c0@gateway.2wire.net> <20130503140611.GC5424@elstar.local> <027e01ce4820$7f405940$4001a8c0@gateway.2wire.net>
To: t.petch 
X-Mailer: Apple Mail (2.1503)
X-Virus-Scanned: clamav-milter 0.97.7 at mail
X-Virus-Status: Clean
Cc: ietfdbh , netmod@ietf.org
Subject: Re: [netmod] Last Call: (A YANG Data Model for Interface Management) to Proposed Standard
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: Sat, 04 May 2013 05:46:10 -0000

On May 3, 2013, at 7:05 PM, t.petch  wrote:

>=20
> ----- Original Message -----
> From: "Juergen Schoenwaelder" 
> To: "t.petch" 
> Cc: "ietfdbh" ; 
> Sent: Friday, May 03, 2013 3:06 PM
>=20
>>> My head hurts (too many balls bouncing around).
>>>=20
>>> I had thought that Netconf split configuration from state data.
>>>=20
>>> And I thought that state data is the additional data on a system
> that is
>>> not
>>>   configuration data such as read-only status information and
> collected
>>>   statistics.
>>>=20
>>> And I thought that we were discussing interface configuration.
>>>=20
>>> Therefore I thought that this discussion became ultra vires a few
>>> hundred posts ago.
>>>=20
>>> Where have I gone wrong?
>>=20
>> Check the document we are discussing. There are config false =
counters.
>> (And yes, likely any other SNMP counters, they are not persistent.)
>=20
> Juergen
>=20
> Yes, I know that really (they got added in -06 and increased the size =
of
> the document considerably:-).
>=20
> But read sections one and two and three and four and I can see no
> mention of this state data, you stumble across it only when you plough
> into the detail later.  I think that this is an omission that needs
> rectifying.  Netconf is very strong on the separation of configuration
> and state and here we are, producing a basic module and bundling them =
up
> together again  I think that that needs an explanation (which should
> probably touch on persistent storage).

I agree that configuration and state data should be separated. In fact, =
as it is now, the state data (statistics) are not present unless the =
corresponding (config=3Dtrue) entry in the interface list is created.
IMO some state data for physical interfaces should be present even =
before any configuration has been written.

Lada

>=20
> Tom Petch
>=20
>=20
>>=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         
>>=20
>=20
>=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 May  3 22:53: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 BFED521F8FD5 for ; Fri,  3 May 2013 22:53:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 u7RFp5gOe3gA for ; Fri,  3 May 2013 22:53:10 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id CC92021F8FC0 for ; Fri,  3 May 2013 22:53:09 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 181EC13F94C; Sat,  4 May 2013 07:53:09 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1367646789; bh=+/6JQLuiB54h3Cbj4BJLSlvzS9gMk2GnVuGdBlR8k7E=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=baUwJVW3kaMgsVb7Jjsjpvv02LTWp2zdeXsjxIklmSDoMLN9To4YQPhe+05SQjSVt zLpul5TtBA9cuD5fzXNyCCJABRkYi0Cr9BugQcK8KIWOe2oqEqDFWwWgZHKBCIKC7s aQhuZIK0H5eDm2FQv0N6z896CdqsEePuhkQUX8Hw=
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Content-Type: text/plain; charset=us-ascii
From: Ladislav Lhotka 
X-Priority: 3
In-Reply-To: <036501ce4838$7dbe1220$4001a8c0@gateway.2wire.net>
Date: Sat, 4 May 2013 07:53:08 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20130502.150226.786661102583726170.mbj@tail-f.com>  <20130502.152259.1658227545250854956.mbj@tail-f.com>  <039d01ce4753$4a540100$defc0300$@comcast.net> <20130502170603.GA1819@elstar.local> <03a101ce4766$20deed40$629cc7c0$@comcast.net> <016701ce4804$302c4600$4001a8c0@gateway.2wire.net> <20130503140611.GC5424@elstar.local> <027e01ce4820$7f405940$4001a8c0@gateway.2wire.net> <20130503184621.GB6118@elstar.local> <036501ce4838$7dbe1220$4001a8c0@gateway.2wire.net>
To: t.petch 
X-Mailer: Apple Mail (2.1503)
X-Virus-Scanned: clamav-milter 0.97.7 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] Last Call: (A YANG Data Model for Interface Management) to Proposed Standard
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: Sat, 04 May 2013 05:53:10 -0000

On May 3, 2013, at 9:57 PM, t.petch  wrote:

> ----- Original Message -----
> From: "Juergen Schoenwaelder" 
> To: "t.petch" 
> Cc: "ietfdbh" ; 
> Sent: Friday, May 03, 2013 7:46 PM
>> On Fri, May 03, 2013 at 06:05:10PM +0100, t.petch wrote:
>>>=20
>>> But read sections one and two and three and four and I can see no
>>> mention of this state data, you stumble across it only when you
> plough
>>> into the detail later.  I think that this is an omission that needs
>>> rectifying.  Netconf is very strong on the separation of
> configuration
>>> and state and here we are, producing a basic module and bundling
> them up
>>> together again  I think that that needs an explanation (which should
>>> probably touch on persistent storage).
>>>=20
>>=20
>> Perhaps there is a need to better document NETCONF's persistency
>> model. I do not think this belongs into some arbitrary data model.
>>=20
>> If you think something is missing in the introduction because there
>> are some counters, how about proposing some text?
>=20
> Abstract
> NEW
> **The model includes both configuration data and counters for the
> collection of statistics.

It is not only statistics. I believe there has to be a way for the =
server to publish the OS-level names of all physical interfaces, their =
physical addresses, duplex settings etc. as state data.

Analogically for the ietf-ip module: there should be a way for the =
client to learn IP addresses that are in operational use - and these =
needn't be the same as manually configured addresses.

Lada

>=20
>=20
> Introduction at end
> NEW
> **The model includes both configuration data and counters for the
> collection of statistics.
>=20
>=20
> Objectives at end
> NEW
>   o  the data model should include (read-only) counters in order to
> gather statistics for octets, packets and errors, sent and received
>=20
> Tom Petch
>=20
>>=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         
>>=20
>=20
>=20
> _______________________________________________
> 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  Sat May  4 01:30: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 61EEE21F949D for ; Sat,  4 May 2013 01:30:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.924
X-Spam-Level: 
X-Spam-Status: No, score=-102.924 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwzGiGraV+QX for ; Sat,  4 May 2013 01:30:49 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 21F2A21F9416 for ; Sat,  4 May 2013 01:30:49 -0700 (PDT)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5999F20C14 for ; Sat,  4 May 2013 10:30:48 +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 nioesYXQn_nc for ; Sat,  4 May 2013 10:30:48 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3285320C10 for ; Sat,  4 May 2013 10:30:48 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id B1C342602E3E; Sat,  4 May 2013 10:30:47 +0200 (CEST)
Resent-From: Juergen Schoenwaelder 
Resent-Date: Sat, 4 May 2013 10:30:47 +0200
Resent-Message-ID: <20130504083047.GB44790@elstar.local>
Resent-To: netmod@ietf.org
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.2.342.3; Sat, 4 May 2013 08:26:32 +0200
Received: from atlas2.jacobs-university.de (atlas2a.jacobs-university.de [212.201.44.15])	by hermes.jacobs-university.de (Postfix) with ESMTP id 91EBF20C10	for ; Sat,  4 May 2013 08:26:37 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48])	by atlas2.jacobs-university.de (Postfix) with ESMTP id 0DB5B3D9	for ; Sat,  4 May 2013 08:26:37 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas2a.jacobs-university.de ([212.201.44.15])	by localhost (demetrius3.jacobs-university.de [212.201.44.48]) (amavisd-new, port 10030) with ESMTP id DmAC5eAwD5qr for ; Sat, 4 May 2013 08:26:35 +0200 (CEST)
X-JacobsISPWhiteListed: No
X-policyd-weight: using cached result; rate: -6.1
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30])	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested)	by atlas2a.jacobs-university.de (Postfix) with ESMTPS	for ; Sat,  4 May 2013 08:26:34 +0200 (CEST)
Received: from p3plsmtpa08-10.prod.phx3.secureserver.net ([173.201.193.111]:52304)	by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from )	id 1UYVvS-00036J-Jo	for draft-ietf-netmod-ip-cfg.all@tools.ietf.org; Sat, 04 May 2013 08:26:31 +0200
Received: from spectre ([173.8.184.78])	by p3plsmtpa08-10.prod.phx3.secureserver.net with id XiS41l00D1huGat01iS5ml; Fri, 03 May 2013 23:26:09 -0700
From: Peter Yee 
To: 
Date: Fri, 3 May 2013 23:26:07 -0700
Message-ID: <05fd01ce4890$45f5cbf0$d1e163d0$@akayla.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac5Ijf7f2lgl5gtAS46HdVoU7WmpFw==
Content-Language: en-us
X-SA-Exim-Connect-IP: 173.201.193.111
X-SA-Exim-Rcpt-To: draft-ietf-netmod-ip-cfg.all@tools.ietf.org
X-SA-Exim-Mail-From: peter@akayla.com
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: , , , 
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
Cc: gen-art@ietf.org, ietf@ietf.org
Subject: [netmod] Gen-ART LC review of draft-ietf-netmod-ip-cfg-09
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: Sat, 04 May 2013 08:30:55 -0000

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at


Please resolve these comments along with any other Last Call comments you
may receive.

Document: draft-ietf-netmod-ip-cfg-09
Reviewer: Peter Yee
Review Date: May-03-2013
IETF LC End Date: May-03-2013
IESG Telechat date: May-16-2013

Summary: This draft is basically ready for publication as a Standards Track
RFC, but has nits that should be fixed before publication. [Ready with nits]

The abstract says it pretty well: This document defines a YANG data model
for management of IP implementations.

Major issues:

Minor issues:

Nits:

Page 7, bottom: The code copyright date says 2012.  Update it to 2013.

Page 10, in leaf phys-address, the description has an incorrect spelling of
"neighbor".

General: where a description of phys-address is given, in both cases it says
"The physical level address...".  It might be more correct to state "The
link layer address..." for most but not all cases.  

That's it.  Everything appears consistent within the limits of my
understanding of YANG.

		-Peter Yee




From xiangli@seguesoft.com  Sat May  4 06:39: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 E6E3921F95E9 for ; Sat,  4 May 2013 06:39:36 -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 jODknhAa1uhc for ; Sat,  4 May 2013 06:39:30 -0700 (PDT)
Received: from p3plsmtpa08-10.prod.phx3.secureserver.net (p3plsmtpa08-10.prod.phx3.secureserver.net [173.201.193.111]) by ietfa.amsl.com (Postfix) with ESMTP id B4B7721F95EA for ; Sat,  4 May 2013 06:39:15 -0700 (PDT)
Received: from [192.168.2.10] ([98.212.151.151]) by p3plsmtpa08-10.prod.phx3.secureserver.net with  id XpfC1l00F3GEayi01pfERP; Sat, 04 May 2013 06:39:15 -0700
Message-ID: <51850F80.8050606@seguesoft.com>
Date: Sat, 04 May 2013 08:39:12 -0500
From: Xiang Li 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: netmod@ietf.org, lhotka@nic.cz
References: <20130502.150226.786661102583726170.mbj@tail-f.com>  <20130502.152259.1658227545250854956.mbj@tail-f.com>  <039d01ce4753$4a540100$defc0300$@comcast.net> <20130502170603.GA1819@elstar.local> <03a101ce4766$20deed40$629cc7c0$@comcast.net> <016701ce4804$302c4600$4001a8c0@gateway.2wire.net> <20130503140611.GC5424@elstar.local> <027e01ce4820$7f405940$4001a8c0@gateway.2wire.net> <20130503184621.GB6118@elstar.local> <036501ce4838$7dbe1220$4001a8c0@gateway.2wire.net> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: [netmod] the main-routing-table in draft-ietf-netmod-routing-cfg-09
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: Sat, 04 May 2013 13:39:37 -0000

Hi Lada,

On page 29 the draft says:

...The main routing table is operationally connected to all
routing protocols for which a connected routing table
has not been explicitly configured.

Can the "main-routing-table" be thought as the default connected routing 
table "used" by
all routing protocols which do not have a connected-routing-table 
explicitly configured
for this router? In other words is the "main routing table" a kind of 
"default routing
table"? If yes I think it's better to use “default-routing-table” or 
another better term.
If that is not the case, but even if there are connected-routing-tables 
explicitly
configured the “main-routing-table” is still in play. Then how exactly 
this “main-routing-
table” is used? I have read this draft several times but still don't 
think I really get it.
I find it is rather difficult to understand its exact meaning and feel 
some additional texts are needed to explain it clearly. I am no routing 
expert but I think it's likely many folks will
stumble on this one ...

Thanks
--Xiang Li


From ietfc@btconnect.com  Sat May  4 10:15: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 7820421F9667 for ; Sat,  4 May 2013 10:15:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level: 
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.450,  BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 iuRnM-C6+Bm7 for ; Sat,  4 May 2013 10:15:20 -0700 (PDT)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 83B4821F8C33 for ; Sat,  4 May 2013 10:15:20 -0700 (PDT)
Received: from mail5-ch1-R.bigfish.com (10.43.68.239) by CH1EHSOBE013.bigfish.com (10.43.70.63) with Microsoft SMTP Server id 14.1.225.23; Sat, 4 May 2013 17:15:19 +0000
Received: from mail5-ch1 (localhost [127.0.0.1])	by mail5-ch1-R.bigfish.com (Postfix) with ESMTP id 5A15B200817; Sat,  4 May 2013 17:15:19 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.254.181; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0711HT002.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -16
X-BigFish: PS-16(zz98dI9371I542I1432I1418Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275bh8275dh8275chz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh304l1d11m1155h)
Received: from mail5-ch1 (localhost.localdomain [127.0.0.1]) by mail5-ch1 (MessageSwitch) id 1367687717522066_14732; Sat,  4 May 2013 17:15:17 +0000 (UTC)
Received: from CH1EHSMHS033.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.234])	by mail5-ch1.bigfish.com (Postfix) with ESMTP id 7CB5D300048; Sat,  4 May 2013 17:15:17 +0000 (UTC)
Received: from DBXPRD0711HT002.eurprd07.prod.outlook.com (157.56.254.181) by CH1EHSMHS033.bigfish.com (10.43.70.33) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 4 May 2013 17:15:17 +0000
Received: from AMXPRD0310HT002.eurprd03.prod.outlook.com (157.56.248.133) by pod51017.outlook.com (10.255.178.35) with Microsoft SMTP Server (TLS) id 14.16.305.3; Sat, 4 May 2013 17:15:15 +0000
Message-ID: <00b001ce48ea$3aa8a100$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Ladislav Lhotka 
References: <20130502.150226.786661102583726170.mbj@tail-f.com>  <20130502.152259.1658227545250854956.mbj@tail-f.com>  <039d01ce4753$4a540100$defc0300$@comcast.net> <20130502170603.GA1819@elstar.local> <03a101ce4766$20deed40$629cc7c0$@comcast.net> <016701ce4804$302c4600$4001a8c0@gateway.2wire.net> <20130503140611.GC5424@elstar.local> <027e01ce4820$7f405940$4001a8c0@gateway.2wire.net> <20130503184621.GB6118@elstar.local> <036501ce4838$7dbe1220$4001a8c0@gateway.2wire.net> 
Date: Sat, 4 May 2013 18:10:00 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.248.133]
X-FOPE-CRA-SourceIpAddress: 157.56.254.181
X-FOPE-CRA-DRYRUN: 1207119;1
X-FOPE-BFA-SENDER: ietfc@btconnect.com
X-FOPE-BFA-RECEIVER: netmod@ietf.org
X-FOPE-BFA-RECEIVER: j.schoenwaelder@jacobs-university.de
X-FOPE-BFA-RECEIVER: lhotka@nic.cz
X-OriginatorOrg: btconnect.com
Cc: netmod@ietf.org
Subject: Re: [netmod] Last Call: (A YANG Data Model for Interface Management) to Proposed Standard
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: Sat, 04 May 2013 17:15:25 -0000

---- Original Message -----
From: "Ladislav Lhotka" 
To: "t.petch" 
Cc: "Juergen Schoenwaelder" ;

Sent: Saturday, May 04, 2013 6:53 AM
On May 3, 2013, at 9:57 PM, t.petch  wrote:

> ----- Original Message -----
> From: "Juergen Schoenwaelder" 
> To: "t.petch" 
> Cc: "ietfdbh" ; 
> Sent: Friday, May 03, 2013 7:46 PM
>> On Fri, May 03, 2013 at 06:05:10PM +0100, t.petch wrote:
>>>
>>> But read sections one and two and three and four and I can see no
>>> mention of this state data, you stumble across it only when you
> plough
>>> into the detail later.  I think that this is an omission that needs
>>> rectifying.  Netconf is very strong on the separation of
> configuration
>>> and state and here we are, producing a basic module and bundling
> them up
>>> together again  I think that that needs an explanation (which should
>>> probably touch on persistent storage).
>>>
>>
>> Perhaps there is a need to better document NETCONF's persistency
>> model. I do not think this belongs into some arbitrary data model.
>>
>> If you think something is missing in the introduction because there
>> are some counters, how about proposing some text?
>
> Abstract
> NEW
> **The model includes both configuration data and counters for the
> collection of statistics.

It is not only statistics. I believe there has to be a way for the
server to publish the OS-level names of all physical interfaces, their
physical addresses, duplex settings etc. as state data.


yes, trying to strike a balance between keeping it simple and being
embracingly accurate.

Perhaps
NEW
The model includes both configuration data and state data (such as
counters for the collection of statistics and operational status).

in each of the three cases.

Tom Petch


Analogically for the ietf-ip module: there should be a way for the
client to learn IP addresses that are in operational use - and these
needn't be the same as manually configured addresses.

Lada

>
>
> Introduction at end
> NEW
> **The model includes both configuration data and counters for the
> collection of statistics.
>
>
> Objectives at end
> NEW
>   o  the data model should include (read-only) counters in order to
> gather statistics for octets, packets and errors, sent and received
>
> Tom Petch
>
>>
>> /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

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







From lhotka@nic.cz  Sat May  4 23:54: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 A57CF21F8F33 for ; Sat,  4 May 2013 23:54:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 lIrsgZjb2lC7 for ; Sat,  4 May 2013 23:54:12 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 8E14E21F8E8E for ; Sat,  4 May 2013 23:54:12 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id CE60513FBBF; Sun,  5 May 2013 08:54:10 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1367736851; bh=h1ncD2TWp6/UGPUNk2UL4wTMTLjQNMCooA8Q3W6W4BU=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=PSXzQkSNeJ+tdOPXsLWt7NTYdcwaBLAmB9ECGclqIEArD2Bt8Mvpz9ztayEP8MYEw ue7nabw4cDmChfy1XZFlljbfB76x1hswphGN55qm5kic0YtDQH07BnFVjz9zBKzqAq 68y+cH0D2L3gGKZLBdkYDHfc4JQ7p9HyXZrWObrI=
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Content-Type: text/plain; charset=iso-8859-1
From: Ladislav Lhotka 
X-Priority: 3
In-Reply-To: <00b001ce48ea$3aa8a100$4001a8c0@gateway.2wire.net>
Date: Sun, 5 May 2013 08:54:11 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <28E9614F-92E6-462D-AD5E-11DF84F5F03B@nic.cz>
References: <20130502.150226.786661102583726170.mbj@tail-f.com>  <20130502.152259.1658227545250854956.mbj@tail-f.com>  <039d01ce4753$4a540100$defc0300$@comcast.net> <20130502170603.GA1819@elstar.local> <03a101ce4766$20deed40$629cc7c0$@comcast.net> <016701ce4804$302c4600$4001a8c0@gateway.2wire.net> <20130503140611.GC5424@elstar.local> <027e01ce4820$7f405940$4001a8c0@gateway.2wire.net> <20130503184621.GB6118@elstar.local> <036501ce4838$7dbe1220$4001a8c0@gateway.2wire.net>  <00b001ce48ea$3aa8a100$4001a8c0@gateway.2wire.net>
To: t.petch 
X-Mailer: Apple Mail (2.1503)
X-Virus-Scanned: clamav-milter 0.97.7 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] Last Call: (A YANG Data Model for Interface Management) to Proposed Standard
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: Sun, 05 May 2013 06:54:13 -0000

On May 4, 2013, at 7:10 PM, t.petch  wrote:

> ---- Original Message -----
> From: "Ladislav Lhotka" 
> To: "t.petch" 
> Cc: "Juergen Schoenwaelder" ;
> 
> Sent: Saturday, May 04, 2013 6:53 AM
> On May 3, 2013, at 9:57 PM, t.petch  wrote:
> 
>> ----- Original Message -----
>> From: "Juergen Schoenwaelder" 
>> To: "t.petch" 
>> Cc: "ietfdbh" ; 
>> Sent: Friday, May 03, 2013 7:46 PM
>>> On Fri, May 03, 2013 at 06:05:10PM +0100, t.petch wrote:
>>>> 
>>>> But read sections one and two and three and four and I can see no
>>>> mention of this state data, you stumble across it only when you
>> plough
>>>> into the detail later.  I think that this is an omission that needs
>>>> rectifying.  Netconf is very strong on the separation of
>> configuration
>>>> and state and here we are, producing a basic module and bundling
>> them up
>>>> together again  I think that that needs an explanation (which should
>>>> probably touch on persistent storage).
>>>> 
>>> 
>>> Perhaps there is a need to better document NETCONF's persistency
>>> model. I do not think this belongs into some arbitrary data model.
>>> 
>>> If you think something is missing in the introduction because there
>>> are some counters, how about proposing some text?
>> 
>> Abstract
>> NEW
>> **The model includes both configuration data and counters for the
>> collection of statistics.
> 
> It is not only statistics. I believe there has to be a way for the
> server to publish the OS-level names of all physical interfaces, their
> physical addresses, duplex settings etc. as state data.
> 
> 
> yes, trying to strike a balance between keeping it simple and being
> embracingly accurate.
> 
> Perhaps
> NEW
> The model includes both configuration data and state data (such as
> counters for the collection of statistics and operational status).

Yes, this looks good.

Lada

> 
> in each of the three cases.
> 
> Tom Petch
> 
> 
> Analogically for the ietf-ip module: there should be a way for the
> client to learn IP addresses that are in operational use - and these
> needn't be the same as manually configured addresses.
> 
> Lada
> 
>> 
>> 
>> Introduction at end
>> NEW
>> **The model includes both configuration data and counters for the
>> collection of statistics.
>> 
>> 
>> Objectives at end
>> NEW
>>  o  the data model should include (read-only) counters in order to
>> gather statistics for octets, packets and errors, sent and received
>> 
>> Tom Petch
>> 
>>> 
>>> /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
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 
> 
> 

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





From lhotka@nic.cz  Sun May  5 00:29:04 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 80CBB21F9283 for ; Sun,  5 May 2013 00:29:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level: 
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.300,  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 ywtMBcSek3Hp for ; Sun,  5 May 2013 00:29: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 D542921F8CE2 for ; Sun,  5 May 2013 00:29:03 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id A72F213FBBF; Sun,  5 May 2013 09:29:02 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1367738942; bh=orhDclKz4KfPBGWhX7/yajc5/bAK8WoQxE1MOz7DUfI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=x7JeBIKCqBV9vqRGrRYLthQ9Lzb/Cv0S0fw0ECjZpKUXw0eM8Kn9IVIUkVafC6y8+ rdw8nibRU7DbsrNP/YMeB9FRNJ6eZeSTcCsTcqReDAv1trzkspW9ETU+L8oXAxbS6d 6kZG8Dg/3Glr78NhY+AzG2PIUAKktIkXzEGl7Nx8=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: <51850F80.8050606@seguesoft.com>
Date: Sun, 5 May 2013 09:29:02 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <79ED36E5-4E8D-4519-B1E7-9A0622DA0246@nic.cz>
References: <20130502.150226.786661102583726170.mbj@tail-f.com>  <20130502.152259.1658227545250854956.mbj@tail-f.com>  <039d01ce4753$4a540100$defc0300$@comcast.net> <20130502170603.GA1819@elstar.local> <03a101ce4766$20deed40$629cc7c0$@comcast.net> <016701ce4804$302c4600$4001a8c0@gateway.2wire.net> <20130503140611.GC5424@elstar.local> <027e01ce4820$7f405940$4001a8c0@gateway.2wire.net> <20130503184621.GB6118@elstar.local> <036501ce4838$7dbe1220$4001a8c0@gateway.2wire.net>  <51850F80.8050606@seguesoft.com>
To: Xiang Li 
X-Mailer: Apple Mail (2.1503)
X-Virus-Scanned: clamav-milter 0.97.7 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] the main-routing-table in draft-ietf-netmod-routing-cfg-09
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: Sun, 05 May 2013 07:29:04 -0000

Hi,

On May 4, 2013, at 3:39 PM, Xiang Li  wrote:

> Hi Lada,
>=20
> On page 29 the draft says:
>=20
> ...The main routing table is operationally connected to all
> routing protocols for which a connected routing table
> has not been explicitly configured.
>=20
> Can the "main-routing-table" be thought as the default connected =
routing table "used" by
> all routing protocols which do not have a connected-routing-table =
explicitly configured
> for this router? In other words is the "main routing table" a kind of =
"default routing

Yes, this is correct. It is explained in sec. 4.4:

   A routing table is connected to a routing protocol instance by
   creating a corresponding entry in the "connected-routing-table" list.
   If such an entry is not configured for an address family, then the
   main routing table MUST be used as the connected routing table for
   this address family.

> table"? If yes I think it's better to use =93default-routing-table=94 =
or another better term.

Well, this is certainly possible, although the term "default" has a =
specific meaning in YANG.

> If that is not the case, but even if there are =
connected-routing-tables explicitly
> configured the =93main-routing-table=94 is still in play. Then how =
exactly this =93main-routing-
> table=94 is used? I have read this draft several times but still don't =
think I really get it.
> I find it is rather difficult to understand its exact meaning and feel =
some additional texts are needed to explain it clearly. I am no routing =
expert but I think it's likely many folks will
> stumble on this one =85

Yes, it is important that the text be clear and understandable. One =
change that might clarify the role and omnipresence of the main routing =
table would be to make it part of the operational state so that this =
table needn't be configured. This has to do with the parallel discussion =
about config versus operational state.

Thanks, Lada

>=20
> Thanks
> --Xiang Li
>=20

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





From xiangli@seguesoft.com  Sun May  5 07:30: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 7721C21F93EE for ; Sun,  5 May 2013 07:30:45 -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 0rKwbomSmy-I for ; Sun,  5 May 2013 07:30:39 -0700 (PDT)
Received: from p3plsmtpa06-08.prod.phx3.secureserver.net (p3plsmtpa06-08.prod.phx3.secureserver.net [173.201.192.109]) by ietfa.amsl.com (Postfix) with ESMTP id 8A38921F93E5 for ; Sun,  5 May 2013 07:30:39 -0700 (PDT)
Received: from [192.168.2.10] ([98.212.151.151]) by p3plsmtpa06-08.prod.phx3.secureserver.net with  id YEWd1l00A3GEayi01EWdxb; Sun, 05 May 2013 07:30:38 -0700
Message-ID: <51866D0E.9080308@seguesoft.com>
Date: Sun, 05 May 2013 09:30:38 -0500
From: Xiang Li 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Ladislav Lhotka 
References: <20130502.150226.786661102583726170.mbj@tail-f.com>  <20130502.152259.1658227545250854956.mbj@tail-f.com>  <039d01ce4753$4a540100$defc0300$@comcast.net> <20130502170603.GA1819@elstar.local> <03a101ce4766$20deed40$629cc7c0$@comcast.net> <016701ce4804$302c4600$4001a8c0@gateway.2wire.net> <20130503140611.GC5424@elstar.local> <027e01ce4820$7f405940$4001a8c0@gateway.2wire.net> <20130503184621.GB6118@elstar.local> <036501ce4838$7dbe1220$4001a8c0@gateway.2wire.net>  <51850F80.8050606@seguesoft.com> <79ED36E5-4E8D-4519-B1E7-9A0622DA0246@nic.cz>
In-Reply-To: <79ED36E5-4E8D-4519-B1E7-9A0622DA0246@nic.cz>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Cc: netmod@ietf.org
Subject: Re: [netmod] the main-routing-table in draft-ietf-netmod-routing-cfg-09
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: Sun, 05 May 2013 14:30:45 -0000

On 5/5/2013 2:29 AM, Ladislav Lhotka wrote:
> Hi,
>
> On May 4, 2013, at 3:39 PM, Xiang Li  wrote:
>
>> Hi Lada,
>>
>> On page 29 the draft says:
>>
>> ...The main routing table is operationally connected to all
>> routing protocols for which a connected routing table
>> has not been explicitly configured.
>>
>> Can the "main-routing-table" be thought as the default connected routing table "used" by
>> all routing protocols which do not have a connected-routing-table explicitly configured
>> for this router? In other words is the "main routing table" a kind of "default routing
> Yes, this is correct. It is explained in sec. 4.4:
>
>     A routing table is connected to a routing protocol instance by
>     creating a corresponding entry in the "connected-routing-table" list.
>     If such an entry is not configured for an address family, then the
>     main routing table MUST be used as the connected routing table for
>     this address family.
>
>> table"? If yes I think it's better to use “default-routing-table” or another better term.
> Well, this is certainly possible,


Well, I think the term "default-routing-table" is way  better than 
"main-routing-table".
It precisely tells me what it is.

>   although the term "default" has a specific meaning in YANG.

I don't think how folks can confuse this the YANG's 'default'. Actually 
I don't think
YANG changes the meaning of the word 'default'.

>> If that is not the case, but even if there are connected-routing-tables explicitly
>> configured the “main-routing-table” is still in play. Then how exactly this “main-routing-
>> table” is used? I have read this draft several times but still don't think I really get it.
>> I find it is rather difficult to understand its exact meaning and feel some additional texts are needed to explain it clearly. I am no routing expert but I think it's likely many folks will
>> stumble on this one …
> Yes, it is important that the text be clear and understandable.


IMO It's a VERY important. Otherwise it may give readers the impression 
the module is
convoluted...but in fact this module may be very cleverly designed.

>   One change that might clarify the role and omnipresence of the main routing table would be to make it part of the operational state so that this table needn't be configured. This has to do with the parallel discussion about config versus operational state.

Yes That should help.

-Xiang

From lhotka@nic.cz  Sun May  5 08:11:44 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 B19AA21F8FAC for ; Sun,  5 May 2013 08:11:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.774
X-Spam-Level: 
X-Spam-Status: No, score=-1.774 tagged_above=-999 required=5 tests=[AWL=0.225,  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 6DcgdtlSMHMl for ; Sun,  5 May 2013 08:11:44 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 01D5821F91D9 for ; Sun,  5 May 2013 08:11:39 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 5CC5B13F6C1; Sun,  5 May 2013 17:11:38 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1367766698; bh=RHDpkDOuLG/VlGWbWlmEMtYcVKpq9zelEDa8Pw1PyQ0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=dLcuHByGTe5FylT9lSVGmVHkxq1vjWjGivQvlAQ2uSDkrKg1jtWMS1ah6TaFGECA8 bE/DvuXoIPB6sDnZljCDEnufuED1BlGshxAgV4Ll57Gdn1jzJssJpV+qmOUQa+bD5d dtzSnTYcjpGY0K/vLeXaT+Py76z6kXzP9QVHoRWU=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: <51866D0E.9080308@seguesoft.com>
Date: Sun, 5 May 2013 17:11:37 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <3A4F32FA-E64D-4841-8BCF-7E90FE3FE534@nic.cz>
References: <20130502.150226.786661102583726170.mbj@tail-f.com>  <20130502.152259.1658227545250854956.mbj@tail-f.com>  <039d01ce4753$4a540100$defc0300$@comcast.net> <20130502170603.GA1819@elstar.local> <03a101ce4766$20deed40$629cc7c0$@comcast.net> <016701ce4804$302c4600$4001a8c0@gateway.2wire.net> <20130503140611.GC5424@elstar.local> <027e01ce4820$7f405940$4001a8c0@gateway.2wire.net> <20130503184621.GB6118@elstar.local> <036501ce4838$7dbe1220$4001a8c0@gateway.2wire.net>  <51850F80.8050606@seguesoft.com> <79ED36E5-4E8D-4519-B1E7-9A0622DA0246@nic.cz> <51866D0E.9080308@seguesoft.com>
To: Xiang Li 
X-Mailer: Apple Mail (2.1503)
X-Virus-Scanned: clamav-milter 0.97.7 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] the main-routing-table in draft-ietf-netmod-routing-cfg-09
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: Sun, 05 May 2013 15:11:44 -0000

On May 5, 2013, at 4:30 PM, Xiang Li  wrote:

>=20
> On 5/5/2013 2:29 AM, Ladislav Lhotka wrote:
>> Hi,
>>=20
>> On May 4, 2013, at 3:39 PM, Xiang Li  wrote:
>>=20
>>> Hi Lada,
>>>=20
>>> On page 29 the draft says:
>>>=20
>>> ...The main routing table is operationally connected to all
>>> routing protocols for which a connected routing table
>>> has not been explicitly configured.
>>>=20
>>> Can the "main-routing-table" be thought as the default connected =
routing table "used" by
>>> all routing protocols which do not have a connected-routing-table =
explicitly configured
>>> for this router? In other words is the "main routing table" a kind =
of "default routing
>> Yes, this is correct. It is explained in sec. 4.4:
>>=20
>>    A routing table is connected to a routing protocol instance by
>>    creating a corresponding entry in the "connected-routing-table" =
list.
>>    If such an entry is not configured for an address family, then the
>>    main routing table MUST be used as the connected routing table for
>>    this address family.
>>=20
>>> table"? If yes I think it's better to use =93default-routing-table=94 =
or another better term.
>> Well, this is certainly possible,
>=20
>=20
> Well, I think the term "default-routing-table" is way  better than =
"main-routing-table".
> It precisely tells me what it is.

Fair enough. What do others think of this change?

>=20
>>  although the term "default" has a specific meaning in YANG.
>=20
> I don't think how folks can confuse this the YANG's 'default'. =
Actually I don't think
> YANG changes the meaning of the word 'default'.
>=20
>>> If that is not the case, but even if there are =
connected-routing-tables explicitly
>>> configured the =93main-routing-table=94 is still in play. Then how =
exactly this =93main-routing-
>>> table=94 is used? I have read this draft several times but still =
don't think I really get it.
>>> I find it is rather difficult to understand its exact meaning and =
feel some additional texts are needed to explain it clearly. I am no =
routing expert but I think it's likely many folks will
>>> stumble on this one =85
>> Yes, it is important that the text be clear and understandable.
>=20
>=20
> IMO It's a VERY important. Otherwise it may give readers the =
impression the module is
> convoluted...but in fact this module may be very cleverly designed.
>=20
>>  One change that might clarify the role and omnipresence of the main =
routing table would be to make it part of the operational state so that =
this table needn't be configured. This has to do with the parallel =
discussion about config versus operational state.
>=20
> Yes That should help.

OK, but I'd prefer if the WG agrees on a unified solution for all core =
modules.

Lada

>=20
> -Xiang

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





From randy_presuhn@mindspring.com  Sun May  5 22:18:02 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 8953F21F8C23 for ; Sun,  5 May 2013 22:18:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.999
X-Spam-Level: 
X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[BAYES_50=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 FqOoDl7prqKH for ; Sun,  5 May 2013 22:17:56 -0700 (PDT)
Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 35B0721F8BE4 for ; Sun,  5 May 2013 22:17:55 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=riQh/xRNDZDgv5vQEEOsUArKMyefVCl2hP3cZFDoep45wU2j0YgZ1KHIlZbVJy3c; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [76.254.50.245] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1UZDoA-0002sV-UT for netmod@ietf.org; Mon, 06 May 2013 01:17:55 -0400
Message-ID: <00f401ce4a19$772563e0$6b01a8c0@oemcomputer>
From: "Randy Presuhn" 
To: 
References: <038d01ce4730$3e9e5810$bbdb0830$@comcast.net><20130502.150226.786661102583726170.mbj@tail-f.com><20130502.152259.1658227545250854956.mbj@tail-f.com><039d01ce4753$4a540100$defc0300$@comcast.net><20130502170603.GA1819@elstar.local><03a101ce4766$20deed40$629cc7c0$@comcast.net><03dd01ce4783$37f60140$a7e203c0$@comcast.net><027d01ce4820$7efd35c0$4001a8c0@gateway.2wire.net> 
Date: Sun, 5 May 2013 22:20:45 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88880ff2f3e23ebe94651cccb707707044c5c0b6344c7cc2f46350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 76.254.50.245
Subject: Re: [netmod] Last Call:  (A YANG Data Model for Interface Management) to Proposed Standard
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, 06 May 2013 05:18:02 -0000

Hi -

> From: "Andy Bierman" 
> To: "t.petch" 
> Cc: "ietfdbh" ; 
> Sent: Friday, May 03, 2013 10:29 AM
> Subject: Re: [netmod] Last Call:  (A YANG Data Model for Interface Management) to
Proposed Standard
...
> I am familiar with the StorageType TC.
> It says that an entry can be expected to persist.
> It does not say when the NV-copy is updated by the agent.

But to conform to the TC specification, it must guarantee that the
non-volatile storage will have been properly updated before
the processor is rebooted.  If the device has a hard reset button
or the like, this effectively requires NV updates to be completed
before the SNMP response to the SetRequest is transmitted.  If the
device only has soft reset and power failure detection with "last
gasp" handling (i.e. some number of cycles of processing after
an interruption in the power has been detected before the
CPU has to be safely halted / put to sleep), caching is possible,
but it would seem to me to be worth the implementation pain only
if the NV hardware were severely limited in the number of
write cycles it could handle.

I think the real issue goes back to how netconf's locks, both explicit
and implied, interact with other software capable of modifying "the
same" underlying datastore.  Consider, for example, the use of
SNMP contexts to provide access to startup configuration data.

Randy



From mbj@tail-f.com  Sun May  5 22:57: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 D19DD21F8551 for ; Sun,  5 May 2013 22:57:13 -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 D48qXlNch-l9 for ; Sun,  5 May 2013 22:57:08 -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 B3DD121F84D1 for ; Sun,  5 May 2013 22:57:07 -0700 (PDT)
Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id C80C71200D65; Mon,  6 May 2013 07:57:05 +0200 (CEST)
Date: Mon, 06 May 2013 07:57:05 +0200 (CEST)
Message-Id: <20130506.075705.181961749.mbj@tail-f.com>
To: randy_presuhn@mindspring.com
From: Martin Bjorklund 
In-Reply-To: <00f401ce4a19$772563e0$6b01a8c0@oemcomputer>
References: <027d01ce4820$7efd35c0$4001a8c0@gateway.2wire.net>  <00f401ce4a19$772563e0$6b01a8c0@oemcomputer>
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] Last Call:  (A YANG Data Model for Interface Management) to Proposed Standard
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, 06 May 2013 05:57:14 -0000

Hi Randy,

"Randy Presuhn"  wrote:
> I think the real issue goes back to how netconf's locks, both explicit
> and implied, interact with other software capable of modifying "the
> same" underlying datastore.  Consider, for example, the use of
> SNMP contexts to provide access to startup configuration data.

This is an interesting idea, and it would be great if we somehow could
use it.  But how would StorageType interact with such a context;
e.g. what happens if the manager SETs it to 'volatile' in the startup
context or maybe more problematic to 'nonVolatile' in the running
(default maybe?) context?   Can we make some recommentations for how
to implement both SNMP and NETCONF on the same device, by using
contexts?


/martin

From internet-drafts@ietf.org  Tue May  7 23:16: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 39AD721F8FFC; Tue,  7 May 2013 23:16:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 mjzZJfdgc-dr; Tue,  7 May 2013 23:16:34 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF3DE21F8FA5; Tue,  7 May 2013 23:16:34 -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.44.p7
Message-ID: <20130508061634.2410.68675.idtracker@ietfa.amsl.com>
Date: Tue, 07 May 2013 23:16:34 -0700
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-rfc6021-bis-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, 08 May 2013 06:16:35 -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           : Common YANG Data Types
	Author(s)       : Juergen Schoenwaelder
	Filename        : draft-ietf-netmod-rfc6021-bis-02.txt
	Pages           : 37
	Date            : 2013-05-07

Abstract:
   This document introduces a collection of common data types to be used
   with the YANG data modeling language.  This document obsoletes RFC
   6021.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6021-bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-netmod-rfc6021-bis-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-rfc6021-bis-02


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


From j.schoenwaelder@jacobs-university.de  Tue May  7 23:34:02 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 39C4321F8EF2 for ; Tue,  7 May 2013 23:34:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.249
X-Spam-Level: 
X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjW56U2Lydga for ; Tue,  7 May 2013 23:33:57 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id AFEE021F8EE8 for ; Tue,  7 May 2013 23:33:57 -0700 (PDT)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B890520BEF; Wed,  8 May 2013 08:33:56 +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 4oKajpPFvBfI; Wed,  8 May 2013 08:33:56 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F257420BED; Wed,  8 May 2013 08:33:55 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 522DB260C126; Wed,  8 May 2013 08:33:55 +0200 (CEST)
Date: Wed, 8 May 2013 08:33:55 +0200
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20130508063355.GB61484@elstar.local>
Mail-Followup-To: netmod@ietf.org
References: <20130508061634.2410.68675.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20130508061634.2410.68675.idtracker@ietfa.amsl.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6021-bis-02.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: Wed, 08 May 2013 06:34:02 -0000

> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6021-bis-02

Hi,

this update incorporates last call comments and IANA / directorate
review comments. The technical changes are that I added \. to the
ipv6-address-no-zone pattern and that a hex-string can be zero-length.
Both changes were discussed previously here. Anyway, please double
check the diff and if you find something wrong, please report it
immediately. The document is currently on the agenda of the IESG
telechat on 2013-05-16.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From sm@elandsys.com  Wed May  8 10:07: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 A1A3021F90C3; Wed,  8 May 2013 10:07:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Sgd6ZJUJtWLx; Wed,  8 May 2013 10:07:04 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D071321F9121; Wed,  8 May 2013 10:07:04 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([197.224.145.230]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r48H6gFR011969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 May 2013 10:06:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1368032821; bh=VqGmhoCTZLT7tdGw9bsAEdoIzPCdQAiNjBel/0JE+kI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Fp5hRMoV9DOwuuo0iYb9JlgBYcd9yvmLdS17YW/QX2kklzyh4sdI6OvCEwjfgv9Ou yjrCon8iSHGbK8g/FA2W4A6xUWvV7ORJtfPflQ9TlbTtwJkbGlQgD2EmMlcD6qWr6c gKtzQq1HFWibkf2hGo+cgp4/2Z9Ym8AhcxOvZTtg=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1368032821; i=@elandsys.com; bh=VqGmhoCTZLT7tdGw9bsAEdoIzPCdQAiNjBel/0JE+kI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=QaFqeDnopAPyM3olNhdi8PYzI6VixU2ZUY7u0Tw5JS4AQsshtI16WHGUbIGCYgZyf Dmhgqd6Racrhv4UJlRk2AQyAtwvyYygIMFLf0fRM6jHfJr3QNh6ohqSUcsr/CEiPCc M2IqXlNjJ5b6YLa+vh/WeP7npUBDh0xi+VxHMNKs=
Message-Id: <6.2.5.6.2.20130508092054.0c02f378@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Wed, 08 May 2013 10:03:43 -0700
To: ietf@ietf.org
From: S Moonesamy 
In-Reply-To: <20130430083206.GD46852@elstar.local>
References: <6.2.5.6.2.20130428233426.0b62fed0@elandnews.com> <20130430083206.GD46852@elstar.local>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Mailman-Approved-At: Thu, 09 May 2013 20:07:08 -0700
Cc: Martin Thomson , netmod@ietf.org
Subject: Re: [netmod] APPSDIR review of draft-ietf-netmod-rfc6021-bis-01
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, 08 May 2013 17:07:05 -0000

At 01:32 30-04-2013, Juergen Schoenwaelder wrote:
>I am not sure what you think is unclear. Note that the definition of
>the typedef domain-name is unchanged from the one in RFC 6021. Perhaps
>you can make a concrete text change proposal so I better understand
>what your concern is.

I read draft-ietf-netmod-rfc6021-bis-02.  In Section 4:

   "The domain-name type represents a DNS domain name.  The
    name SHOULD be fully qualified whenever possible."

That sounds like a MAY.

The text in RFC 6021 and the draft is clear.  I don't think that the 
fact that DNS-related text is already in RFC 6021 means that it is correct.

   "Internationalized domain names MUST be encoded in punycode as described
    in RFC 3492";

RFC 5891 discusses about IDNA-aware implementations.  It also 
discusses about A-labels and U-labels.  The above text jumps directly 
to punycode.

Regards,
S. Moonesamy



From randy@psg.com  Wed May  8 12:53: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 F205B21F8ADF; Wed,  8 May 2013 12:53:07 -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=[AWL=0.000,  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 wmAkAVyRm-Sx; Wed,  8 May 2013 12:53:07 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 85AD521F89FF; Wed,  8 May 2013 12:53:07 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UaAQB-000GQy-3V; Wed, 08 May 2013 19:53:03 +0000
Date: Wed, 08 May 2013 21:53:01 +0200
Message-ID: 
From: Randy Bush 
To: S Moonesamy 
In-Reply-To: <6.2.5.6.2.20130508092054.0c02f378@resistor.net>
References: <6.2.5.6.2.20130428233426.0b62fed0@elandnews.com> <20130430083206.GD46852@elstar.local> <6.2.5.6.2.20130508092054.0c02f378@resistor.net>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-Mailman-Approved-At: Thu, 09 May 2013 20:07:08 -0700
Cc: ietf@ietf.org, netmod@ietf.org
Subject: Re: [netmod] APPSDIR review of draft-ietf-netmod-rfc6021-bis-01
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, 08 May 2013 19:53:08 -0000

>    "The domain-name type represents a DNS domain name.  The
>     name SHOULD be fully qualified whenever possible."
> 
> That sounds like a MAY.

MAY != SHOULD

From sm@elandsys.com  Wed May  8 14:30: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 F019D21F8ED8; Wed,  8 May 2013 14:30:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.195
X-Spam-Level: 
X-Spam-Status: No, score=-102.195 tagged_above=-999 required=5 tests=[AWL=0.404, 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 Y-NO0SqDSG3Y; Wed,  8 May 2013 14:30:29 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3402221F884F; Wed,  8 May 2013 14:30:28 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([197.224.145.230]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r48LUEZH005813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 May 2013 14:30:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1368048627; bh=OA9vcS4BW/kx8g9pAuYDkazTHpkIu9UlOHgrVccQ/1o=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=LIGwws4am02FKeDoFRUVk4AWvSfoVGOw0O8Do0NDOhlmdEd/Hz4VrC6wpMotFybLf PTBhQ01vMya6Paf1vmKhDeMPQQKWh626xwpIkgF5puooi3+iu39WuohZk4teur3GbO uHPJIX2+Z9ClmbyRXd67+F+klFSJSqkxLniNjsJ4=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1368048627; i=@elandsys.com; bh=OA9vcS4BW/kx8g9pAuYDkazTHpkIu9UlOHgrVccQ/1o=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=IQ9RbsVw+S5T8kz1AAimow5cQ5moKT2ybR0w5rl+dd4Hk8xJhKlg0njCzHOMvqyv+ zWOLHTA5f92U0lx+xbJJc1EkrhllXGSIIrsQcWDp2xhy+9v8Yxajw8W0h2ekloYOAL MHMwWvMZTPAD225c+IqdmEAPQKD5jVrZ0x/uRA+Q=
Message-Id: <6.2.5.6.2.20130508130025.0c082b18@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Wed, 08 May 2013 13:44:44 -0700
To: ietf@ietf.org
From: S Moonesamy 
In-Reply-To: 
References: <6.2.5.6.2.20130428233426.0b62fed0@elandnews.com> <20130430083206.GD46852@elstar.local> <6.2.5.6.2.20130508092054.0c02f378@resistor.net> 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Mailman-Approved-At: Thu, 09 May 2013 20:07:08 -0700
Cc: netmod@ietf.org
Subject: Re: [netmod] APPSDIR review of draft-ietf-netmod-rfc6021-bis-01
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, 08 May 2013 21:30:30 -0000

At 12:53 08-05-2013, Randy Bush wrote:
>MAY != SHOULD

The text is as follows: "The name SHOULD be fully qualified whenever 
possible".  If the working group would like a RFC 2119 SHOULD it 
would help if there is an explanation in the sentence for the reader 
weigh the implications of not following that.

For what it is worth Eric Burger posted an analysis of "SHOULD" usage 
in a different draft ( 
http://www.ietf.org/mail-archive/web/mile/current/msg01021.html ).

Regards,
S. Moonesamy 


From jabley@hopcount.ca  Wed May  8 14:55:50 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 73A2E21F86F0 for ; Wed,  8 May 2013 14:55:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 AN0++C-P94Ts for ; Wed,  8 May 2013 14:55:50 -0700 (PDT)
Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id A555921F85EF for ; Wed,  8 May 2013 14:55:49 -0700 (PDT)
Received: by mail-qc0-f181.google.com with SMTP id s10so1341018qcv.12 for ; Wed, 08 May 2013 14:55:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:references:from:mime-version:in-reply-to:date:message-id :subject:to:cc:content-type; bh=wBcZ/bmQOh0G1PYVdxCD2be+H62RdbgXN7M9Y0ch+oA=; b=mYjFy2M/rDPQJaTT+S71C6K4ibnslLETm5KC/Xri0e2qIigwl4JNFgjj+Ssp5Y4Vo+ JMznLzpbvH3ly38IztWwU7hPviK2mGnk/YH4ilAbl9Ul3zPgDJsFhZ1CW3/70dU/Phwj /Ntacix7FKu/jjyCjxNpMNDevdRFgRIJDEFL4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:from:mime-version:in-reply-to:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=wBcZ/bmQOh0G1PYVdxCD2be+H62RdbgXN7M9Y0ch+oA=; b=kRglNgwIZ6+FQhNUek8JItQxuhU3Pz9ZJf3MBdoLFUvl1V6wz07Br3Begl3uqh/k4t Ej9ze7OpR0FxSg5SMxnubqkcSiZKf8rWER+rRExebXvr9j34/mAf33u9JSAh44MZHfDF 0+pfs9uKcF41zqSi0OW0TsQVDJTCyiej19evi/EL5bKq9gL9tV6Txo4HHPMKCKLlAHxV 6zaeG3mdqC3pfLRcDIgPelR4DRmKI0qqbGdSyoOBzcMAgHwo7O1CL18LAz98LZmCTKkJ QImC6dvgjRhyVDESiu3E2zWKhrK0ezCsnWo923HxvCz04JC5oW/bj960PayioZ6Ma6rJ WrSg==
X-Received: by 10.49.104.37 with SMTP id gb5mr7314169qeb.41.1368050149092; Wed, 08 May 2013 14:55:49 -0700 (PDT)
References: <6.2.5.6.2.20130428233426.0b62fed0@elandnews.com> <20130430083206.GD46852@elstar.local> <6.2.5.6.2.20130508092054.0c02f378@resistor.net>  <6.2.5.6.2.20130508130025.0c082b18@elandnews.com>
From: Joe Abley 
Mime-Version: 1.0 (1.0)
In-Reply-To: <6.2.5.6.2.20130508130025.0c082b18@elandnews.com>
Date: Wed, 8 May 2013 17:55:49 -0400
Message-ID: <2604527301889679776@unknownmsgid>
To: S Moonesamy 
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQkUykdw4xNTaUHhdOB2nhhXGnsZY1WSl6XSkpHShRABiQ9DO4eQKPU1YnR+1KsjhOaDYhBU
X-Mailman-Approved-At: Thu, 09 May 2013 20:07:08 -0700
Cc: "ietf@ietf.org" , "netmod@ietf.org" 
Subject: Re: [netmod] APPSDIR review of draft-ietf-netmod-rfc6021-bis-01
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, 08 May 2013 21:55:50 -0000

On 2013-05-08, at 17:30, S Moonesamy  wrote:

> At 12:53 08-05-2013, Randy Bush wrote:
>> MAY != SHOULD
>
> The text is as follows: "The name SHOULD be fully qualified whenever possible".  If the working group would like a RFC 2119 SHOULD it would help if there is an explanation in the sentence for the reader weigh the implications of not following that.

My knee-jerk reaction is to use MUST. Partially-qualified domain names
are ambiguous at best.

Similarly, "wherever possible" is unhelpful; if it's not possible to
fully-qualify a domain name then ambiguity is guaranteed.


Joe

From mrex@sap.com  Wed May  8 23:31: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 8EC4821F859D; Wed,  8 May 2013 23:31:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level: 
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 l-QEQhpQyWMQ; Wed,  8 May 2013 23:31:20 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3D99521F85C3; Wed,  8 May 2013 23:31:19 -0700 (PDT)
Received: from mail06.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r496V12V004323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 May 2013 08:31:01 +0200 (MEST)
In-Reply-To: <6.2.5.6.2.20130508092054.0c02f378@resistor.net>
To: S Moonesamy 
Date: Thu, 9 May 2013 08:31:01 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20130509063101.3141D1A700@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
X-Mailman-Approved-At: Thu, 09 May 2013 20:07:08 -0700
Cc: ietf@ietf.org, netmod@ietf.org
Subject: Re: [netmod] APPSDIR review of draft-ietf-netmod-rfc6021-bis-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 May 2013 06:31:25 -0000

S Moonesamy wrote:
> At 01:32 30-04-2013, Juergen Schoenwaelder wrote:
> >I am not sure what you think is unclear. Note that the definition of
> >the typedef domain-name is unchanged from the one in RFC 6021. Perhaps
> >you can make a concrete text change proposal so I better understand
> >what your concern is.
> 
> I read draft-ietf-netmod-rfc6021-bis-02.  In Section 4:
> 
>    "The domain-name type represents a DNS domain name.  The
>     name SHOULD be fully qualified whenever possible."
> 
> That sounds like a MAY.

That is a MAY.  That probably needs to be a may.

How do you recognize a "fully qualified" name anyway?


Today a huge number of machines simply does not have a
"fully qualified domain name" (and uses private address space).

My DSL router (a brand that is pretty common in Germany)
does _not_ provide a domain name via DHCP and will resolve
plain hostnames for all addresses that it hands out via DHCP.
And a lot of stuff that you attach to home networks comes
with a Web-UI (my DVB-S Set-Top Box, my HomeNAS, my DSL-router
(although the latter recognizes "fritz.box" as a name for itself).

-Martin

From mbj@tail-f.com  Fri May 10 01:25: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 25B0821F849C for ; Fri, 10 May 2013 01:25:54 -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 uc8l5k00RaxJ for ; Fri, 10 May 2013 01:25:48 -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 414CF21F8496 for ; Fri, 10 May 2013 01:25:48 -0700 (PDT)
Received: from localhost (213-65-184-248-no181.tbcn.telia.com [213.65.184.248]) by mail.tail-f.com (Postfix) with ESMTPSA id 12F5D1200DA0 for ; Fri, 10 May 2013 10:25:46 +0200 (CEST)
Date: Fri, 10 May 2013 10:25:45 +0200 (CEST)
Message-Id: <20130510.102545.163409025.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] terminology in ip cfg
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, 10 May 2013 08:25:54 -0000

Hi,

The Gen-ART review from Peter Yee of draft-ietf-netmod-ip-cfg-09 had
this comment:

  General: where a description of phys-address is given, in both cases
  it says "The physical level address...".  It might be more correct
  to state "The link layer address..." for most but not all cases.

It seems rfc 4861 and others use the term 'link-layer address' whereas
the term in (most?) SNMP documents is 'physical level
address'.  Some recent MIBs (I found PMIPV6-MIB on a quick search) use
the term 'link-level address' with the type PhysAddress.

So, what is the preferred term?

If we change this to link-layer address, we should probably also
change the name of the leaf itself to "link-address" or
"link-layer-address".


/martin

From j.schoenwaelder@jacobs-university.de  Fri May 10 01:48: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 369DB21F85F7 for ; Fri, 10 May 2013 01:48:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.249
X-Spam-Level: 
X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45VMZhnwtBvv for ; Fri, 10 May 2013 01:48:29 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0A48A21F8D00 for ; Fri, 10 May 2013 01:48:28 -0700 (PDT)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 37E0420BFB; Fri, 10 May 2013 10:48:27 +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 mIPpeIqNt_QO; Fri, 10 May 2013 10:48:27 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7673920BF6; Fri, 10 May 2013 10:48:26 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 0BDA826192DE; Fri, 10 May 2013 10:48:22 +0200 (CEST)
Date: Fri, 10 May 2013 10:48:22 +0200
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20130510084821.GA70835@elstar.local>
Mail-Followup-To: Martin Bjorklund , netmod@ietf.org
References: <20130510.102545.163409025.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20130510.102545.163409025.mbj@tail-f.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] terminology in ip cfg
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: Fri, 10 May 2013 08:48:34 -0000

On Fri, May 10, 2013 at 10:25:45AM +0200, Martin Bjorklund wrote:
> Hi,
> 
> The Gen-ART review from Peter Yee of draft-ietf-netmod-ip-cfg-09 had
> this comment:
> 
>   General: where a description of phys-address is given, in both cases
>   it says "The physical level address...".  It might be more correct
>   to state "The link layer address..." for most but not all cases.
> 
> It seems rfc 4861 and others use the term 'link-layer address' whereas
> the term in (most?) SNMP documents is 'physical level
> address'.  Some recent MIBs (I found PMIPV6-MIB on a quick search) use
> the term 'link-level address' with the type PhysAddress.
> 
> So, what is the preferred term?
> 
> If we change this to link-layer address, we should probably also
> change the name of the leaf itself to "link-address" or
> "link-layer-address".

RFC 4861 clearly defines the term link-layer address for neighborhood
discovery. The good old ARP specification talks about 'hardware
addresses' - but yes it is somewhat dated. It seems that
link-layer-address is meanwhile the proper term when we talk about IP
neighborhood tables so we should probably change the leaf's name.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From jonathan@hansfords.net  Fri May 10 01:52: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 833FF21F84CE for ; Fri, 10 May 2013 01:52:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 FE-hsqbdYgrQ for ; Fri, 10 May 2013 01:52:49 -0700 (PDT)
Received: from avasout03.plus.net (avasout03.plus.net [84.93.230.244]) by ietfa.amsl.com (Postfix) with ESMTP id 0AEF221F8D00 for ; Fri, 10 May 2013 01:52:48 -0700 (PDT)
Received: from webmail.plus.net ([84.93.228.147]) by avasout03 with smtp id a8sn1l0013BT6uC018snd3; Fri, 10 May 2013 09:52:47 +0100
X-CM-Score: 0.00
X-CNFS-Analysis: v=2.1 cv=Wq0Sb7vv c=1 sm=1 tr=0 a=jSQgp9IWXRf89EXR5FPwJg==:117 a=zvOXFpZrtIe2DiqMBxawyA==:17 a=0Bzu9jTXAAAA:8 a=jkFKeVsF5M4A:10 a=dYCPD3cKDi0A:10 a=07KFqYEZQLYA:10 a=0B8HqoTn75oA:10 a=IkcTkHD0fZMA:10 a=6bkCdLdQAAAA:8 a=f0uUZFObAAAA:8 a=qROEEQzr_rYA:10 a=UnnwD1GPAAAA:8 a=48vgC7mUAAAA:8 a=b29Mz3jcfzY59-a4lRYA:9 a=Gge3B7LoxkpBX_AL:21 a=s16vpj3xCsXeHi2X:21 a=QEXdDO2ut3YA:10 a=lXTCXeLT_n8A:10 a=lZB815dzVvQA:10
X-AUTH: hansfords+us:2500
Received: from host-212-159-131-154.static.as13285.net ([212.159.131.154]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Fri, 10 May 2013 09:52:47 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Date: Fri, 10 May 2013 09:52:47 +0100
From: Jonathan Hansford 
To: 
In-Reply-To: <20130509063101.3141D1A700@ld9781.wdf.sap.corp>
References: <20130509063101.3141D1A700@ld9781.wdf.sap.corp>
Message-ID: 
X-Sender: Jonathan@hansfords.net
User-Agent: Roundcube Webmail/0.7.4
X-Originating-IP: [212.159.131.154]
Subject: Re: [netmod] APPSDIR review of draft-ietf-netmod-rfc6021-bis-01
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, 10 May 2013 08:52:54 -0000

On 2013-05-09 07:31, mrex@sap.com wrote:

> S Moonesamy wrote:
>
>> At 01:32 30-04-2013, Juergen Schoenwaelder wrote:
>>
>>> I am not sure what you think is unclear. Note that the definition 
>>> of
>>> the typedef domain-name is unchanged from the one in RFC 6021.
>>> Perhaps you can make a concrete text change proposal so I better
>>> understand what your concern is.
>> I read draft-ietf-netmod-rfc6021-bis-02. In Section 4: "The
>> domain-name type represents a DNS domain name. The name SHOULD be 
>> fully
>> qualified whenever possible." That sounds like a MAY.
>
> That is a MAY. That probably needs to be a may.
>
> How do you recognize a "fully qualified" name anyway?

RFC 1033 states:

    A domain name is a sequence of labels separated by dots.

    Domain names in the zone files can be one of two types, either
    absolute or relative.  An absolute name is the fully qualified 
domain
    name and is terminated with a period.

You recognise an FQDN by the terminating period.

>
> Today a huge number of machines simply does not have a
> "fully qualified domain name" (and uses private address space).
>
> My DSL router (a brand that is pretty common in Germany)
> does _not_ provide a domain name via DHCP and will resolve
> plain hostnames for all addresses that it hands out via DHCP.
> And a lot of stuff that you attach to home networks comes
> with a Web-UI (my DVB-S Set-Top Box, my HomeNAS, my DSL-router
> (although the latter recognizes "fritz.box" as a name for itself).
>
> -Martin
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

From jonathan@hansfords.net  Fri May 10 01:55: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 EAD2421F8511 for ; Fri, 10 May 2013 01:55:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, 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 YBdhBLE6diuv for ; Fri, 10 May 2013 01:55:52 -0700 (PDT)
Received: from avasout03.plus.net (avasout03.plus.net [84.93.230.244]) by ietfa.amsl.com (Postfix) with ESMTP id 351B121F8425 for ; Fri, 10 May 2013 01:55:47 -0700 (PDT)
Received: from webmail.plus.net ([84.93.228.147]) by avasout03 with smtp id a8vm1l0053BT6uC018vmpy; Fri, 10 May 2013 09:55:46 +0100
X-CM-Score: 0.00
X-CNFS-Analysis: v=2.1 cv=Wq0Sb7vv c=1 sm=1 tr=0 a=jSQgp9IWXRf89EXR5FPwJg==:117 a=zvOXFpZrtIe2DiqMBxawyA==:17 a=0Bzu9jTXAAAA:8 a=jkFKeVsF5M4A:10 a=dYCPD3cKDi0A:10 a=nYC1tl3xXIEA:10 a=0B8HqoTn75oA:10 a=6bkCdLdQAAAA:8 a=f0uUZFObAAAA:8 a=JtN-lBymtsIA:10 a=48vgC7mUAAAA:8 a=Rl-bPHkqFP2Ya-1gPWkA:9 a=lW5amROyA0t1Lgj-:21 a=8mDBPNeF7l14IL9f:21 a=QEXdDO2ut3YA:10 a=lZB815dzVvQA:10 a=Qq0bNopXvGIf0U_VFnYA:9 a=OpCHOUG42MlemR0x:21 a=F-K2s4hfF996NQce:21 a=_W_S_7VecoQA:10
X-AUTH: hansfords+us:2500
Received: from host-212-159-131-154.static.as13285.net ([212.159.131.154]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Fri, 10 May 2013 09:55:46 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_1ba3fe78bfccbd48c507dc6694b0a379"
Date: Fri, 10 May 2013 09:55:46 +0100
From: Jonathan Hansford 
To: 
In-Reply-To: <20130510.102545.163409025.mbj@tail-f.com>
References: <20130510.102545.163409025.mbj@tail-f.com>
Message-ID: 
X-Sender: Jonathan@hansfords.net
User-Agent: Roundcube Webmail/0.7.4
X-Originating-IP: [212.159.131.154]
Subject: Re: [netmod] terminology in ip cfg
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, 10 May 2013 08:55:58 -0000

--=_1ba3fe78bfccbd48c507dc6694b0a379
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=UTF-8

 

link-layer-address 

+1 

On 2013-05-10 09:25, Martin Bjorklund
wrote: 

> Hi,
> 
> The Gen-ART review from Peter Yee of
draft-ietf-netmod-ip-cfg-09 had
> this comment:
> 
> General: where a
description of phys-address is given, in both cases
> it says "The
physical level address...". It might be more correct
> to state "The
link layer address..." for most but not all cases.
> 
> It seems rfc
4861 and others use the term 'link-layer address' whereas
> the term in
(most?) SNMP documents is 'physical level
> address'. Some recent MIBs
(I found PMIPV6-MIB on a quick search) use
> the term 'link-level
address' with the type PhysAddress.
> 
> So, what is the preferred
term?
> 
> If we change this to link-layer address, we should probably
also
> change the name of the leaf itself to "link-address" or
>
"link-layer-address".
> 
> /martin
>
_______________________________________________
> netmod mailing list
>
netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
 
--=_1ba3fe78bfccbd48c507dc6694b0a379
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8




link-layer-address


+1


On 2013-05-10 09:25, Martin Bjorklund wrote:




Hi,

The Gen-ART review from Peter Yee of draft-ietf-netmod-ip-cfg-09 had
this comment:

  General: where a description of phys-address is given, in both cases
  it says "The physical level address...".  It might be more correct
  to state "The link layer address..." for most but not all cases.

It seems rfc 4861 and others use the term 'link-layer address' whereas
the term in (most?) SNMP documents is 'physical level
address'.  Some recent MIBs (I found PMIPV6-MIB on a quick search) use
the term 'link-level address' with the type PhysAddress.

So, what is the preferred term?

If we change this to link-layer address, we should probably also
change the name of the leaf itself to "link-address" or
"link-layer-address".


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






--=_1ba3fe78bfccbd48c507dc6694b0a379--


From ietfc@btconnect.com  Fri May 10 04:42: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 B645421F8AD5 for ; Fri, 10 May 2013 04:42:40 -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 t3fKymAQGyRP for ; Fri, 10 May 2013 04:42:35 -0700 (PDT)
Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id 8C47921F8A7B for ; Fri, 10 May 2013 04:42:35 -0700 (PDT)
Received: from mail158-co9-R.bigfish.com (10.236.132.229) by CO9EHSOBE027.bigfish.com (10.236.130.90) with Microsoft SMTP Server id 14.1.225.23; Fri, 10 May 2013 11:42:34 +0000
Received: from mail158-co9 (localhost [127.0.0.1])	by mail158-co9-R.bigfish.com (Postfix) with ESMTP id CC2A92C0878; Fri, 10 May 2013 11:42:34 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.250.181; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0711HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -15
X-BigFish: PS-15(zz98dI9371I542I1432Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275bh8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh304l1d11m1155h)
Received: from mail158-co9 (localhost.localdomain [127.0.0.1]) by mail158-co9 (MessageSwitch) id 1368186153581173_20845; Fri, 10 May 2013 11:42:33 +0000 (UTC)
Received: from CO9EHSMHS024.bigfish.com (unknown [10.236.132.238])	by mail158-co9.bigfish.com (Postfix) with ESMTP id 81FE4340280; Fri, 10 May 2013 11:42:33 +0000 (UTC)
Received: from AMSPRD0711HT001.eurprd07.prod.outlook.com (157.56.250.181) by CO9EHSMHS024.bigfish.com (10.236.130.34) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 10 May 2013 11:42:33 +0000
Received: from DB3PRD0411HT001.eurprd04.prod.outlook.com (157.56.253.53) by pod51017.outlook.com (10.242.14.162) with Microsoft SMTP Server (TLS) id 14.16.305.3; Fri, 10 May 2013 11:42:20 +0000
Message-ID: <002f01ce4d72$b2acc280$4001a8c0@gateway.2wire.net>
From: t.petch 
To: , Martin Bjorklund 
References: <027d01ce4820$7efd35c0$4001a8c0@gateway.2wire.net><00f401ce4a19$772563e0$6b01a8c0@oemcomputer> <20130506.075705.181961749.mbj@tail-f.com>
Date: Fri, 10 May 2013 12:35:15 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.253.53]
X-FOPE-CRA-SourceIpAddress: 157.56.250.181
X-FOPE-CRA-DRYRUN: 1207119;1
X-FOPE-BFA-SENDER: ietfc@btconnect.com
X-FOPE-BFA-RECEIVER: netmod@ietf.org
X-FOPE-BFA-RECEIVER: mbj@tail-f.com
X-FOPE-BFA-RECEIVER: randy_presuhn@mindspring.com
X-OriginatorOrg: btconnect.com
Cc: netmod@ietf.org
Subject: Re: [netmod] Last Call:  (A YANG Data Model for Interface Management) to Proposed Standard
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, 10 May 2013 11:42:40 -0000

The comments on this I-D triggered some more general thoughts in me
about netmod modules, which I tried to turn into an I-D; that has not
worked terribly well, but this section comes close to what I was
thinking

4.  Persistence

   SNMP developed the concept of persistent data and embodied it in a
   Textual Convention, StorageType [RFC2579] .  This means that the
   persistence or otherwise of the data is integral with definition of
   the data model.

   Netconf took a different approach, defining datastores, of which the
   one mandatory one is :running, although most devices will also have a
   :startup datastore.  Netconf says nothing about the persistency of
   the datastores.  :startup is used at boot time and so by implication
   is in a storage type that persists across shutdowns.  Again, by
   implication, :running is ephemeral since "Operations that affect the
   running configuration will not be automatically copied to the startup
   configuration " [RFC6241].  So making data persistent with Netconf
   requires a successful protocol operation, with SNMP, it is integral
   with the data definition.

   The impact of this could be far-reaching.

Not a criticism, rather a reflection of what is to be.

Tom Petch

p.s. the rest is at

http://www.ietf.org/internet-drafts/draft-petch-netconf-surprises-00.txt

----- Original Message -----
From: "Martin Bjorklund" 
To: 
Cc: 
Sent: Monday, May 06, 2013 6:57 AM

> Hi Randy,
>
> "Randy Presuhn"  wrote:
> > I think the real issue goes back to how netconf's locks, both
explicit
> > and implied, interact with other software capable of modifying "the
> > same" underlying datastore.  Consider, for example, the use of
> > SNMP contexts to provide access to startup configuration data.
>
> This is an interesting idea, and it would be great if we somehow could
> use it.  But how would StorageType interact with such a context;
> e.g. what happens if the manager SETs it to 'volatile' in the startup
> context or maybe more problematic to 'nonVolatile' in the running
> (default maybe?) context?   Can we make some recommentations for how
> to implement both SNMP and NETCONF on the same device, by using
> contexts?
>
>
> /martin
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>



From j.schoenwaelder@jacobs-university.de  Fri May 10 05:37: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 1F83921F8FA5 for ; Fri, 10 May 2013 05:37:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.949
X-Spam-Level: 
X-Spam-Status: No, score=-102.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_15=0.6, 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 5OuNyoXxgbiD for ; Fri, 10 May 2013 05:36:47 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0089621F8FDC for ; Fri, 10 May 2013 05:36:46 -0700 (PDT)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B7D8520BEE; Fri, 10 May 2013 14:36:45 +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 acWiRDWPdcoa; Fri, 10 May 2013 14:36:45 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C39E220A1F; Fri, 10 May 2013 14:36:44 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id A8710261A307; Fri, 10 May 2013 14:36:42 +0200 (CEST)
Date: Fri, 10 May 2013 14:36:41 +0200
From: Juergen Schoenwaelder 
To: "t.petch" 
Message-ID: <20130510123639.GA71399@elstar.local>
Mail-Followup-To: "t.petch" , randy_presuhn@mindspring.com, Martin Bjorklund , netmod@ietf.org
References: <027d01ce4820$7efd35c0$4001a8c0@gateway.2wire.net>  <00f401ce4a19$772563e0$6b01a8c0@oemcomputer> <20130506.075705.181961749.mbj@tail-f.com> <002f01ce4d72$b2acc280$4001a8c0@gateway.2wire.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <002f01ce4d72$b2acc280$4001a8c0@gateway.2wire.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] Last Call:  (A YANG Data Model for Interface Management) to Proposed Standard
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: Fri, 10 May 2013 12:37:09 -0000

On Fri, May 10, 2013 at 12:35:15PM +0100, t.petch wrote:
> The comments on this I-D triggered some more general thoughts in me
> about netmod modules, which I tried to turn into an I-D; that has not
> worked terribly well, but this section comes close to what I was
> thinking
> 
> 4.  Persistence
> 
>    SNMP developed the concept of persistent data and embodied it in a
>    Textual Convention, StorageType [RFC2579] .  This means that the
>    persistence or otherwise of the data is integral with definition of
>    the data model.
> 
>    Netconf took a different approach, defining datastores, of which the
>    one mandatory one is :running, although most devices will also have a
>    :startup datastore.  Netconf says nothing about the persistency of
>    the datastores.  :startup is used at boot time and so by implication
>    is in a storage type that persists across shutdowns.  Again, by
>    implication, :running is ephemeral since "Operations that affect the
>    running configuration will not be automatically copied to the startup
>    configuration " [RFC6241].  So making data persistent with Netconf
>    requires a successful protocol operation, with SNMP, it is integral
>    with the data definition.
> 
>    The impact of this could be far-reaching.
> 
> Not a criticism, rather a reflection of what is to be.

My understanding was that on systems that only have , the
 configuration data store is persistent.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From ietfc@btconnect.com  Fri May 10 10:01: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 32E9B21F881F for ; Fri, 10 May 2013 10:01:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level: 
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=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 4t+nyJubZ41O for ; Fri, 10 May 2013 10:01:02 -0700 (PDT)
Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id C05C521F84B5 for ; Fri, 10 May 2013 10:01:01 -0700 (PDT)
Received: from mail154-co1-R.bigfish.com (10.243.78.244) by CO1EHSOBE008.bigfish.com (10.243.66.71) with Microsoft SMTP Server id 14.1.225.23; Fri, 10 May 2013 17:01:01 +0000
Received: from mail154-co1 (localhost [127.0.0.1])	by mail154-co1-R.bigfish.com (Postfix) with ESMTP id D6846C6059C; Fri, 10 May 2013 17:01:00 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.250.181; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0711HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -15
X-BigFish: PS-15(zz98dI9371I542I1432Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL8275bh8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh304l1d11m1155h)
Received: from mail154-co1 (localhost.localdomain [127.0.0.1]) by mail154-co1 (MessageSwitch) id 1368205259262552_30760; Fri, 10 May 2013 17:00:59 +0000 (UTC)
Received: from CO1EHSMHS009.bigfish.com (unknown [10.243.78.229])	by mail154-co1.bigfish.com (Postfix) with ESMTP id 3398420049; Fri, 10 May 2013 17:00:59 +0000 (UTC)
Received: from AMSPRD0711HT001.eurprd07.prod.outlook.com (157.56.250.181) by CO1EHSMHS009.bigfish.com (10.243.66.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 10 May 2013 17:00:57 +0000
Received: from pc6 (86.166.98.191) by pod51017.outlook.com (10.242.14.162) with Microsoft SMTP Server (TLS) id 14.16.305.3; Fri, 10 May 2013 17:00:42 +0000
Message-ID: <010901ce4d9f$2c15fb60$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Juergen Schoenwaelder 
References: <027d01ce4820$7efd35c0$4001a8c0@gateway.2wire.net>  <00f401ce4a19$772563e0$6b01a8c0@oemcomputer> <20130506.075705.181961749.mbj@tail-f.com> <002f01ce4d72$b2acc280$4001a8c0@gateway.2wire.net> <20130510123639.GA71399@elstar.local>
Date: Fri, 10 May 2013 17:43:09 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [86.166.98.191]
X-FOPE-CRA-SourceIpAddress: 157.56.250.181
X-FOPE-CRA-DRYRUN: 1207119;1
X-FOPE-BFA-SENDER: ietfc@btconnect.com
X-FOPE-BFA-RECEIVER: netmod@ietf.org
X-FOPE-BFA-RECEIVER: mbj@tail-f.com
X-FOPE-BFA-RECEIVER: j.schoenwaelder@jacobs-university.de
X-OriginatorOrg: btconnect.com
Cc: netmod@ietf.org
Subject: Re: [netmod] Last Call:  (A YANG Data Model for Interface Management) to Proposed Standard
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, 10 May 2013 17:01:08 -0000

---- Original Message -----
From: "Juergen Schoenwaelder" 
To: "t.petch" 
Cc: ; "Martin Bjorklund" ;

Sent: Friday, May 10, 2013 1:36 PM
> On Fri, May 10, 2013 at 12:35:15PM +0100, t.petch wrote:
> > The comments on this I-D triggered some more general thoughts in me
> > about netmod modules, which I tried to turn into an I-D; that has
not
> > worked terribly well, but this section comes close to what I was
> > thinking
> >
> > 4.  Persistence
> >
> >    SNMP developed the concept of persistent data and embodied it in
a
> >    Textual Convention, StorageType [RFC2579] .  This means that the
> >    persistence or otherwise of the data is integral with definition
of
> >    the data model.
> >
> >    Netconf took a different approach, defining datastores, of which
the
> >    one mandatory one is :running, although most devices will also
have a
> >    :startup datastore.  Netconf says nothing about the persistency
of
> >    the datastores.  :startup is used at boot time and so by
implication
> >    is in a storage type that persists across shutdowns.  Again, by
> >    implication, :running is ephemeral since "Operations that affect
the
> >    running configuration will not be automatically copied to the
startup
> >    configuration " [RFC6241].  So making data persistent with
Netconf
> >    requires a successful protocol operation, with SNMP, it is
integral
> >    with the data definition.
> >
> >    The impact of this could be far-reaching.
> >
> > Not a criticism, rather a reflection of what is to be.
>
> My understanding was that on systems that only have , the
>  configuration data store is persistent.

That is an interesting idea.  I had not thought of or seen any reference
to that in the RFC/I-D but it would make sense.  The devices I know of I
would expect to have  so the idea of a device without one is
rather strange to me.

Tom Petch
>
> /js
>



From j.schoenwaelder@jacobs-university.de  Fri May 10 12:20: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 58ED021F955E for ; Fri, 10 May 2013 12:20:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.899
X-Spam-Level: 
X-Spam-Status: No, score=-102.899 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_15=0.6, 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 CLgjLXAjW4BQ for ; Fri, 10 May 2013 12:20:35 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 23EB621F9501 for ; Fri, 10 May 2013 12:20:34 -0700 (PDT)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D45AD20BEC; Fri, 10 May 2013 21:20:33 +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 2K6THRSVB09M; Fri, 10 May 2013 21:20:33 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 131F920BE3; Fri, 10 May 2013 21:20:33 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id AE43C261C595; Fri, 10 May 2013 21:20:29 +0200 (CEST)
Date: Fri, 10 May 2013 21:20:29 +0200
From: Juergen Schoenwaelder 
To: "t.petch" 
Message-ID: <20130510192028.GH72461@elstar.local>
Mail-Followup-To: "t.petch" , Martin Bjorklund , netmod@ietf.org
References: <027d01ce4820$7efd35c0$4001a8c0@gateway.2wire.net>  <00f401ce4a19$772563e0$6b01a8c0@oemcomputer> <20130506.075705.181961749.mbj@tail-f.com> <002f01ce4d72$b2acc280$4001a8c0@gateway.2wire.net> <20130510123639.GA71399@elstar.local> <010901ce4d9f$2c15fb60$4001a8c0@gateway.2wire.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <010901ce4d9f$2c15fb60$4001a8c0@gateway.2wire.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] Last Call:  (A YANG Data Model for Interface Management) to Proposed Standard
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: Fri, 10 May 2013 19:20:40 -0000

On Fri, May 10, 2013 at 05:43:09PM +0100, t.petch wrote:
> 
> That is an interesting idea.  I had not thought of or seen any reference
> to that in the RFC/I-D but it would make sense.  The devices I know of I
> would expect to have  so the idea of a device without one is
> rather strange to me.
> 

My home router is a device that does not claim to have a separate
startup on its web interface. Every config change immediately persists
- I assume this is rather common on these kind of devices.

/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  Fri May 10 12:47: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 243DA21F9080 for ; Fri, 10 May 2013 12:47:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.557
X-Spam-Level: 
X-Spam-Status: No, score=-0.557 tagged_above=-999 required=5 tests=[AWL=0.821,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrcbZa03nW2Y for ; Fri, 10 May 2013 12:47:24 -0700 (PDT)
Received: from mail-ia0-x22d.google.com (mail-ia0-x22d.google.com [IPv6:2607:f8b0:4001:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B7D9321F90B9 for ; Fri, 10 May 2013 12:47:23 -0700 (PDT)
Received: by mail-ia0-f173.google.com with SMTP id l25so5127219iad.32 for ; Fri, 10 May 2013 12:47:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=+mTchqiKuE5HZs6sfcklXWxKJrW3KLcCBBBC3sWBv74=; b=IXXzj6CoiZauGCmc/Z85XbdGtNitcG7XnepbhkubshBE8j1lZ10+lbzECPBth0aish 8hI1WMsdUw1zqjbhyL8DRNHsySrjcQGWoJIyn4IXAoX9BuK1wiiPNeP7i08n/O2bFlWR 1KES8bqpf8RMeJyvOdRq0Y5qbSh/o2A+Mtl30qAP8SSWREea7DmlbmQVN46Eu51E8j98 VI38A8BVhMRdUGwFWaX5fb1mWFE7NojoWeJhDC/gI/AAIr4Ta0gd33nVSyXMXJ9nTcXv 2vkB313gyYUUFaisV7H5sotMQRS1Moz0JtUjlbqBT4zi8/GvCSJRzoKQyDIYBbebF0mN e/Hg==
MIME-Version: 1.0
X-Received: by 10.50.7.69 with SMTP id h5mr3186687iga.69.1368215243094; Fri, 10 May 2013 12:47:23 -0700 (PDT)
Received: by 10.231.125.202 with HTTP; Fri, 10 May 2013 12:47:22 -0700 (PDT)
In-Reply-To: <20130510192028.GH72461@elstar.local>
References: <027d01ce4820$7efd35c0$4001a8c0@gateway.2wire.net>  <00f401ce4a19$772563e0$6b01a8c0@oemcomputer> <20130506.075705.181961749.mbj@tail-f.com> <002f01ce4d72$b2acc280$4001a8c0@gateway.2wire.net> <20130510123639.GA71399@elstar.local> <010901ce4d9f$2c15fb60$4001a8c0@gateway.2wire.net> <20130510192028.GH72461@elstar.local>
Date: Fri, 10 May 2013 12:47:22 -0700
Message-ID: 
From: Andy Bierman 
To: Juergen Schoenwaelder , "t.petch" ,  Martin Bjorklund , netmod@ietf.org
Content-Type: multipart/alternative; boundary=089e0111be2a8a927b04dc626f03
X-Gm-Message-State: ALoCoQlSJkdO1Z4FSpVcLHEdMSU45x5/5iTGYODvMyXIsmnBHfj2KA+rMagA+AbvyBNkdSDkGpRC
Subject: Re: [netmod] Last Call:  (A YANG Data Model for Interface Management) to Proposed Standard
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, 10 May 2013 19:47:25 -0000

--089e0111be2a8a927b04dc626f03
Content-Type: text/plain; charset=ISO-8859-1

On Fri, May 10, 2013 at 12:20 PM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Fri, May 10, 2013 at 05:43:09PM +0100, t.petch wrote:
> >
> > That is an interesting idea.  I had not thought of or seen any reference
> > to that in the RFC/I-D but it would make sense.  The devices I know of I
> > would expect to have  so the idea of a device without one is
> > rather strange to me.
> >
>
> My home router is a device that does not claim to have a separate
> startup on its web interface. Every config change immediately persists
> - I assume this is rather common on these kind of devices.
>
>
Perhaps there is some confusion over the Distinct Startup capability
as defined in RFC 6241, sec. 8.7?

All NETCONF devices have persistent storage of the running configuration.
Devices with a distinct startup require the client to ask for the NV-storage
to be updated (e,g, CLI: write mem). A client can send 
requests for the startup datastore and the value may be different
than the running datastore.  The startup datastore does not exist
on NETCONF devices that do not advertise :startup.

NETCONF persistence tends to mirror the CLI persistence model
for the device.  SNMP is generally for monitoring, but the writable
objects I've implemented in routers (RMON, RMON2, etc.) followed
whatever the CLI did, not what SNMP said to do.


/js
>
>
Andy

--089e0111be2a8a927b04dc626f03
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Fri, May 10, 2013 at 12:20 PM, Juerge=
n Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:


On Fri, May 10, 2013 at 05:43:09PM +0100, t.=
petch wrote:

>

> That is an interesting idea. =A0I had not thought of or seen any refer=
ence

> to that in the RFC/I-D but it would make sense. =A0The devices I know =
of I

> would expect to have <startup> so the idea of a device without o=
ne is

> rather strange to me.

>



My home router is a device that does not claim to have a separate

startup on its web interface. Every config change immediately persists

- I assume this is rather common on these kind of devices.



Perhaps there is some confusion over the Distinct St=
artup capability
as defined in RFC 6241, sec. 8.7?



All NETCONF devices have persistent storage of the running confi=
guration.
Devices with a distinct startup require the client to a=
sk for the NV-storage
to be updated (e,g, CLI: write mem). A clie=
nt can send <get-config>


requests for the startup datastore and the value may be different
than the running datastore. =A0The startup datastore does not exist
on NETCONF devices that do not advertise :startup.



NETCONF persistence tends to mirror the CLI persistence model
for the device. =A0SNMP is generally for monitoring, but the writab=
le
objects I've implemented in routers (RMON, RMON2, etc.) fo=
llowed


whatever the CLI did, not what SNMP said to do.



/js



Andy
=A0
=



--089e0111be2a8a927b04dc626f03--

From j.schoenwaelder@jacobs-university.de  Sat May 11 03:51: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 B7B6821F89A5 for ; Sat, 11 May 2013 03:51:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.182
X-Spam-Level: 
X-Spam-Status: No, score=-103.182 tagged_above=-999 required=5 tests=[AWL=0.067, 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 KLLsoOHEu3DN for ; Sat, 11 May 2013 03:51:41 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 804DA21F8956 for ; Sat, 11 May 2013 03:51:41 -0700 (PDT)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 62E7D20BEB; Sat, 11 May 2013 12:51:40 +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 Go0D4ud1btkA; Sat, 11 May 2013 12:51:40 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8D8FA20BE9; Sat, 11 May 2013 12:51:39 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 507922620E1D; Sat, 11 May 2013 12:51:36 +0200 (CEST)
Date: Sat, 11 May 2013 12:51:34 +0200
From: Juergen Schoenwaelder 
To: S Moonesamy 
Message-ID: <20130511105132.GD192@elstar.local>
Mail-Followup-To: S Moonesamy , Martin Thomson , netmod@ietf.org
References: <6.2.5.6.2.20130428233426.0b62fed0@elandnews.com> <20130430083206.GD46852@elstar.local> <6.2.5.6.2.20130508092054.0c02f378@resistor.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6.2.5.6.2.20130508092054.0c02f378@resistor.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Martin Thomson , netmod@ietf.org
Subject: Re: [netmod] APPSDIR review of draft-ietf-netmod-rfc6021-bis-01
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: Sat, 11 May 2013 10:51:46 -0000

On Wed, May 08, 2013 at 10:03:43AM -0700, S Moonesamy wrote:
> At 01:32 30-04-2013, Juergen Schoenwaelder wrote:
> >I am not sure what you think is unclear. Note that the definition of
> >the typedef domain-name is unchanged from the one in RFC 6021. Perhaps
> >you can make a concrete text change proposal so I better understand
> >what your concern is.
> 
> I read draft-ietf-netmod-rfc6021-bis-02.  In Section 4:
> 
>   "The domain-name type represents a DNS domain name.  The
>    name SHOULD be fully qualified whenever possible."
> 
> That sounds like a MAY.

When RFC 6021 was published, the WGs concensus was SHOULD as defined
in RFC 2119:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.
 
> The text in RFC 6021 and the draft is clear.  I don't think that the
> fact that DNS-related text is already in RFC 6021 means that it is
> correct.

Sure, RFCs can be buggy. But then it needs to be clear what the bug is
- so far that is not clear to me and hence I am reluctant to make any
changes.

>   "Internationalized domain names MUST be encoded in punycode as described
>    in RFC 3492";
> 
> RFC 5891 discusses about IDNA-aware implementations.  It also
> discusses about A-labels and U-labels.  The above text jumps
> directly to punycode.

Please help the WG understand what is wrong with the current text (in
the sense that it affects interoperable implementations). Perhaps you
can tell the WG also what you think the proper fix would look like.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From dromasca@avaya.com  Sun May 12 00: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 50DB721F85D6 for ; Sun, 12 May 2013 00:15:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.245
X-Spam-Level: 
X-Spam-Status: No, score=-103.245 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, 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 sC0Vp8eg3n+l for ; Sun, 12 May 2013 00:15:09 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 34B9E21F85EB for ; Sun, 12 May 2013 00:15:08 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag4FAG9Aj1GHCzI1/2dsb2JhbABagkMjITfAIoEAFnSCHwEBAQEDEhtcAgEIDQMBBAEBAQoZBAcyFAkIAgQBEggah2oBoF2aPheNfHs3AYJ0YQOdZYp8gVeBOIFqPQ
X-IronPort-AV: E=Sophos;i="4.87,655,1363147200"; d="scan'208,217";a="8933308"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 12 May 2013 03:15:06 -0400
Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 12 May 2013 03:11:21 -0400
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.02.0328.009; Sun, 12 May 2013 03:15:04 -0400
From: "Romascanu, Dan (Dan)" 
To: Andy Bierman , Juergen Schoenwaelder , t.petch ,  "Martin Bjorklund" , "netmod@ietf.org" 
Thread-Topic: [netmod] Last Call:  (A YANG Data Model for Interface Management) to Proposed Standard
Thread-Index: AQHOTbN3zPPinsiIE0Sb8ujAuUIC0Zj/FgcAgAIONUA=
Date: Sun, 12 May 2013 07:15:03 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1699A6@AZ-FFEXMB04.global.avaya.com>
References: <027d01ce4820$7efd35c0$4001a8c0@gateway.2wire.net>  <00f401ce4a19$772563e0$6b01a8c0@oemcomputer> <20130506.075705.181961749.mbj@tail-f.com> <002f01ce4d72$b2acc280$4001a8c0@gateway.2wire.net> <20130510123639.GA71399@elstar.local> <010901ce4d9f$2c15fb60$4001a8c0@gateway.2wire.net> <20130510192028.GH72461@elstar.local> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.64.58.45]
Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA1699A6AZFFEXMB04globala_"
MIME-Version: 1.0
Subject: Re: [netmod] Last Call:  (A YANG Data Model for Interface Management) to Proposed Standard
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: Sun, 12 May 2013 07:15:16 -0000

--_000_9904FB1B0159DA42B0B887B7FA8119CA1699A6AZFFEXMB04globala_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

So which one of these two statements is true?


(Juergen) My understanding was that on systems that only have , th=
e  configuration data store is persistent.


(Andy) My understanding was that on systems that only have , the <=
running> configuration data store is persistent.

Dan



From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of=
 Andy Bierman
Sent: Friday, May 10, 2013 10:47 PM
To: Juergen Schoenwaelder; t.petch; Martin Bjorklund; netmod@ietf.org
Subject: Re: [netmod] Last Call:  =
(A YANG Data Model for Interface Management) to Proposed Standard


On Fri, May 10, 2013 at 12:20 PM, Juergen Schoenwaelder > wrote:
On Fri, May 10, 2013 at 05:43:09PM +0100, t.petch wrote:
>
> That is an interesting idea.  I had not thought of or seen any reference
> to that in the RFC/I-D but it would make sense.  The devices I know of I
> would expect to have  so the idea of a device without one is
> rather strange to me.
>

My home router is a device that does not claim to have a separate
startup on its web interface. Every config change immediately persists
- I assume this is rather common on these kind of devices.

Perhaps there is some confusion over the Distinct Startup capability
as defined in RFC 6241, sec. 8.7?

All NETCONF devices have persistent storage of the running configuration.
Devices with a distinct startup require the client to ask for the NV-storag=
e
to be updated (e,g, CLI: write mem). A client can send 
requests for the startup datastore and the value may be different
than the running datastore.  The startup datastore does not exist
on NETCONF devices that do not advertise :startup.

NETCONF persistence tends to mirror the CLI persistence model
for the device.  SNMP is generally for monitoring, but the writable
objects I've implemented in routers (RMON, RMON2, etc.) followed
whatever the CLI did, not what SNMP said to do.


/js

Andy


--_000_9904FB1B0159DA42B0B887B7FA8119CA1699A6AZFFEXMB04globala_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











So which one of these two=
 statements is true?



 <=
/p>

(Juergen)
My understanding was that on systems that only have <running>,=
 the <running> configuration data store is persistent.


 <=
/p>

(Andy)
My understanding was that on systems that only have <running>,=
 the <running> configuration data store is persistent.


 <=
/p>

Dan


 <=
/p>

 <=
/p>

 <=
/p>







From: netmod-b=
ounces@ietf.org [mailto:netmod-bounces@ietf.org]
On Behalf Of Andy Bierman

Sent: Friday, May 10, 2013 10:47 PM

To: Juergen Schoenwaelder; t.petch; Martin Bjorklund; netmod@ietf.or=
g

Subject: Re: [netmod] Last Call: <draft-ietf-netmod-interfaces-cf=
g-10.txt> (A YANG Data Model for Interface Management) to Proposed Stand=
ard






 


 




On Fri, May 10, 2013 at 12:20 PM, Juergen Schoenwael=
der <j.schoenwaelder@jacobs-university.de> wrote:


On Fri, May 10, 2013 =
at 05:43:09PM +0100, t.petch wrote:

>

> That is an interesting idea.  I had not thought of or seen any re=
ference

> to that in the RFC/I-D but it would make sense.  The devices I kn=
ow of I

> would expect to have <startup> so the idea of a device without o=
ne is

> rather strange to me.

>



My home router is a device that does not claim to have a separate

startup on its web interface. Every config change immediately persists

- I assume this is rather common on these kind of devices.




 






Perhaps there is some confusion over the Distinct St=
artup capability






as defined in RFC 6241, sec. 8.7?






 






All NETCONF devices have persistent storage of the r=
unning configuration.






Devices with a distinct startup require the client t=
o ask for the NV-storage






to be updated (e,g, CLI: write mem). A client can se=
nd <get-config>






requests for the startup datastore and the value may=
 be different






than the running datastore.  The startup datast=
ore does not exist






on NETCONF devices that do not advertise :startup.






 






NETCONF persistence tends to mirror the CLI persiste=
nce model






for the device.  SNMP is generally for monitori=
ng, but the writable






objects I've implemented in routers (RMON, RMON2, et=
c.) followed






whatever the CLI did, not what SNMP said to do.=







 






 






/js






 






Andy






 












--_000_9904FB1B0159DA42B0B887B7FA8119CA1699A6AZFFEXMB04globala_--

From dromasca@avaya.com  Sun May 12 00:19: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 0BC9A21F871C for ; Sun, 12 May 2013 00:19:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.73
X-Spam-Level: 
X-Spam-Status: No, score=-102.73 tagged_above=-999 required=5 tests=[AWL=-0.732, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=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 vTVXsD4yhbtP for ; Sun, 12 May 2013 00:19:01 -0700 (PDT)
Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3C71721F8721 for ; Sun, 12 May 2013 00:19:01 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag4FAHlBj1GHCzI1/2dsb2JhbABagkMjITfAIoEAFnSCHwEBAQEDEhtcAgEIDQMBBAEBAQoZBAcyFAkIAgQBEggah2oBoF2aPheNfHs3AYJ0YQOdZYp8gVeBOIFqPQ
X-IronPort-AV: E=Sophos;i="4.87,655,1363147200"; d="scan'208,217";a="11182699"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 12 May 2013 03:19:00 -0400
Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 12 May 2013 03:15:15 -0400
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.02.0328.009; Sun, 12 May 2013 03:18:58 -0400
From: "Romascanu, Dan (Dan)" 
To: "Romascanu, Dan (Dan)" , Andy Bierman , Juergen Schoenwaelder , t.petch ,  "Martin Bjorklund" , "netmod@ietf.org" 
Thread-Topic: [netmod] Last Call:  (A YANG Data Model for Interface Management) to Proposed Standard
Thread-Index: AQHOTbN3zPPinsiIE0Sb8ujAuUIC0Zj/FgcAgAIONUCAAAIOIA==
Date: Sun, 12 May 2013 07:18:57 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1699BE@AZ-FFEXMB04.global.avaya.com>
References: <027d01ce4820$7efd35c0$4001a8c0@gateway.2wire.net>  <00f401ce4a19$772563e0$6b01a8c0@oemcomputer> <20130506.075705.181961749.mbj@tail-f.com> <002f01ce4d72$b2acc280$4001a8c0@gateway.2wire.net> <20130510123639.GA71399@elstar.local> <010901ce4d9f$2c15fb60$4001a8c0@gateway.2wire.net> <20130510192028.GH72461@elstar.local>  <9904FB1B0159DA42B0B887B7FA8119CA1699A6@AZ-FFEXMB04.global.avaya.com>
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA1699A6@AZ-FFEXMB04.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.64.58.45]
Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA1699BEAZFFEXMB04globala_"
MIME-Version: 1.0
Subject: Re: [netmod] Last Call:  (A YANG Data Model for Interface Management) to Proposed Standard
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: Sun, 12 May 2013 07:19:08 -0000

--_000_9904FB1B0159DA42B0B887B7FA8119CA1699BEAZFFEXMB04globala_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Sorry,  I meant:

which one of these two statements is true?


(Juergen) My understanding was that on systems that only have , th=
e  configuration data store is persistent.

(Andy) All NETCONF devices have persistent storage of the running configura=
tion.

Dan



From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of=
 Romascanu, Dan (Dan)
Sent: Sunday, May 12, 2013 10:15 AM
To: Andy Bierman; Juergen Schoenwaelder; t.petch; Martin Bjorklund; netmod@=
ietf.org
Subject: Re: [netmod] Last Call:  =
(A YANG Data Model for Interface Management) to Proposed Standard

So which one of these two statements is true?


(Juergen) My understanding was that on systems that only have , th=
e  configuration data store is persistent.


(Andy) My understanding was that on systems that only have , the <=
running> configuration data store is persistent.

Dan



From: netmod-bounces@ietf.org [mailto:netmo=
d-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: Friday, May 10, 2013 10:47 PM
To: Juergen Schoenwaelder; t.petch; Martin Bjorklund; netmod@ietf.org
Subject: Re: [netmod] Last Call:  =
(A YANG Data Model for Interface Management) to Proposed Standard


On Fri, May 10, 2013 at 12:20 PM, Juergen Schoenwaelder > wrote:
On Fri, May 10, 2013 at 05:43:09PM +0100, t.petch wrote:
>
> That is an interesting idea.  I had not thought of or seen any reference
> to that in the RFC/I-D but it would make sense.  The devices I know of I
> would expect to have  so the idea of a device without one is
> rather strange to me.
>

My home router is a device that does not claim to have a separate
startup on its web interface. Every config change immediately persists
- I assume this is rather common on these kind of devices.

Perhaps there is some confusion over the Distinct Startup capability
as defined in RFC 6241, sec. 8.7?

All NETCONF devices have persistent storage of the running configuration.
Devices with a distinct startup require the client to ask for the NV-storag=
e
to be updated (e,g, CLI: write mem). A client can send 
requests for the startup datastore and the value may be different
than the running datastore.  The startup datastore does not exist
on NETCONF devices that do not advertise :startup.

NETCONF persistence tends to mirror the CLI persistence model
for the device.  SNMP is generally for monitoring, but the writable
objects I've implemented in routers (RMON, RMON2, etc.) followed
whatever the CLI did, not what SNMP said to do.


/js

Andy


--_000_9904FB1B0159DA42B0B887B7FA8119CA1699BEAZFFEXMB04globala_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Sorry,  I meant:



 <=
/p>

which one of these two st=
atements is true?



 <=
/p>

(Juergen)
My understanding was that on systems that only have <running>,=
 the <running> configuration data store is persistent.


 <=
/p>

(Andy)
All NETCONF devices have persistent storage of the running configura=
tion.


 <=
/p>

Dan


 <=
/p>

 <=
/p>

 <=
/p>







From: netmod-b=
ounces@ietf.org [mailto:netmod-bounces@ietf.org]
On Behalf Of Romascanu, Dan (Dan)

Sent: Sunday, May 12, 2013 10:15 AM

To: Andy Bierman; Juergen Schoenwaelder; t.petch; Martin Bjorklund; =
netmod@ietf.org

Subject: Re: [netmod] Last Call: <draft-ietf-netmod-interfaces-cf=
g-10.txt> (A YANG Data Model for Interface Management) to Proposed Stand=
ard






 


So which one of these two=
 statements is true?



 <=
/p>

(Juergen)
My understanding was that on systems that only have <running>,=
 the <running> configuration data store is persistent.


 <=
/p>

(Andy)
My understanding was that on systems that only have <running>,=
 the <running> configuration data store is persistent.


 <=
/p>

Dan


 <=
/p>

 <=
/p>

 <=
/p>







From:
netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org]
On Behalf Of Andy Bierman

Sent: Friday, May 10, 2013 10:47 PM

To: Juergen Schoenwaelder; t.petch; Martin Bjorklund; 
netmod@ietf.org

Subject: Re: [netmod] Last Call: <draft-ietf-netmod-interfaces-cf=
g-10.txt> (A YANG Data Model for Interface Management) to Proposed Stand=
ard






 


 




On Fri, May 10, 2013 at 12:20 PM, Juergen Schoenwael=
der <j.schoenwaelder@jacobs-university.de> wrote:


On Fri, May 10, 2013 =
at 05:43:09PM +0100, t.petch wrote:

>

> That is an interesting idea.  I had not thought of or seen any re=
ference

> to that in the RFC/I-D but it would make sense.  The devices I kn=
ow of I

> would expect to have <startup> so the idea of a device without o=
ne is

> rather strange to me.

>



My home router is a device that does not claim to have a separate

startup on its web interface. Every config change immediately persists

- I assume this is rather common on these kind of devices.




 






Perhaps there is some confusion over the Distinct St=
artup capability






as defined in RFC 6241, sec. 8.7?






 






All NETCONF devices have persistent storage of the r=
unning configuration.






Devices with a distinct startup require the client t=
o ask for the NV-storage






to be updated (e,g, CLI: write mem). A client can se=
nd <get-config>






requests for the startup datastore and the value may=
 be different






than the running datastore.  The startup datast=
ore does not exist






on NETCONF devices that do not advertise :startup.






 






NETCONF persistence tends to mirror the CLI persiste=
nce model






for the device.  SNMP is generally for monitori=
ng, but the writable






objects I've implemented in routers (RMON, RMON2, et=
c.) followed






whatever the CLI did, not what SNMP said to do.=







 






 






/js






 






Andy






 














--_000_9904FB1B0159DA42B0B887B7FA8119CA1699BEAZFFEXMB04globala_--

From j.schoenwaelder@jacobs-university.de  Sun May 12 05:00: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 9674F21F8E59 for ; Sun, 12 May 2013 05:00:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.189
X-Spam-Level: 
X-Spam-Status: No, score=-103.189 tagged_above=-999 required=5 tests=[AWL=0.060, 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 AQNZ7ho5MXHa for ; Sun, 12 May 2013 05:00:27 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 313A321F8E49 for ; Sun, 12 May 2013 05:00:26 -0700 (PDT)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 36A9820C14; Sun, 12 May 2013 14:00:25 +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 9OiEuFRnYQ-B; Sun, 12 May 2013 14:00: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 AAC1E20C11; Sun, 12 May 2013 14:00:22 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 8C68B262F21A; Sun, 12 May 2013 14:00:20 +0200 (CEST)
Date: Sun, 12 May 2013 14:00:18 +0200
From: Juergen Schoenwaelder 
To: "Romascanu, Dan (Dan)" 
Message-ID: <20130512120016.GA4203@elstar.local>
Mail-Followup-To: "Romascanu, Dan (Dan)" , Andy Bierman , "t.petch" , Martin Bjorklund , "netmod@ietf.org" 
References:  <00f401ce4a19$772563e0$6b01a8c0@oemcomputer> <20130506.075705.181961749.mbj@tail-f.com> <002f01ce4d72$b2acc280$4001a8c0@gateway.2wire.net> <20130510123639.GA71399@elstar.local> <010901ce4d9f$2c15fb60$4001a8c0@gateway.2wire.net> <20130510192028.GH72461@elstar.local>  <9904FB1B0159DA42B0B887B7FA8119CA1699A6@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA1699BE@AZ-FFEXMB04.global.avaya.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA1699BE@AZ-FFEXMB04.global.avaya.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Last Call:  (A YANG Data Model for Interface Management) to Proposed Standard
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: Sun, 12 May 2013 12:00:32 -0000

On Sun, May 12, 2013 at 07:18:57AM +0000, Romascanu, Dan (Dan) wrote:
> Sorry,  I meant:
> 
> which one of these two statements is true?
> 
> 
> (Juergen) My understanding was that on systems that only have , the  configuration data store is persistent.
> 
> (Andy) All NETCONF devices have persistent storage of the running configuration.
> 

Both statement can both be true. ;-) The problem is to find the
relevant pieces of text in the RFCs that talk about persistence since
apparently this is where some people are confused.

RFC 6241 says for example:

   o  configuration datastore: The datastore holding the complete set of
      configuration data that is required to get a device from its
      initial default state into a desired operational state.

While this does not say 'persist', one might argue that persistence is
kind of implied in order to "get a device from its initial default
state into a desired operational state". And the startup datastore
really is a special feature:

   o  startup configuration datastore: The configuration datastore
      holding the configuration loaded by the device when it boots.
      Only present on devices that separate the startup configuration
      datastore from the running configuration datastore.

Even without a startup, your running datastore still persists since it
is a configuration datastore.

   o  running configuration datastore: A configuration datastore holding
      the complete configuration currently active on the device.  The
      running configuration datastore always exists.

NETCONF was designed to modify configuration data and configuration
data usually persists (otherwise we would simply talk about writable
operational state, the stuff i2rs people are working on).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From dromasca@avaya.com  Sun May 12 06:24: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 077DC21F8607 for ; Sun, 12 May 2013 06:24:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.487
X-Spam-Level: 
X-Spam-Status: No, score=-103.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, 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 qeFqH77-EeAB for ; Sun, 12 May 2013 06:24:13 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 27F7621F8E59 for ; Sun, 12 May 2013 06:24:13 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgUFAAH/ZlHGmAcF/2dsb2JhbABQgmUhNsFIgQcWdIIfAQEBAQIBEig/BQcEAgEIDQECAQQBAQEKFAUEBzIUCQgCBA4FCBqHbAYBoEedDBeNansmCwcGglphA5M2hG2FBopogVWBNoFrPQ
X-IronPort-AV: E=Sophos;i="4.87,456,1363147200"; d="scan'208";a="10840873"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 12 May 2013 09:24:12 -0400
Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 12 May 2013 09:19:33 -0400
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.02.0328.009; Sun, 12 May 2013 09:24:10 -0400
From: "Romascanu, Dan (Dan)" 
To: Juergen Schoenwaelder 
Thread-Topic: [netmod] Last Call:  (A YANG Data Model for Interface Management) to Proposed Standard
Thread-Index: AQHOTbN3zPPinsiIE0Sb8ujAuUIC0Zj/FgcAgAIONUCAAAIOIIAAkecA///RqYA=
Date: Sun, 12 May 2013 13:24:09 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA16A0BF@AZ-FFEXMB04.global.avaya.com>
References:  <00f401ce4a19$772563e0$6b01a8c0@oemcomputer> <20130506.075705.181961749.mbj@tail-f.com> <002f01ce4d72$b2acc280$4001a8c0@gateway.2wire.net> <20130510123639.GA71399@elstar.local> <010901ce4d9f$2c15fb60$4001a8c0@gateway.2wire.net> <20130510192028.GH72461@elstar.local>  <9904FB1B0159DA42B0B887B7FA8119CA1699A6@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA1699BE@AZ-FFEXMB04.global.avaya.com> <20130512120016.GA4203@elstar.local>
In-Reply-To: <20130512120016.GA4203@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.64.58.45]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Last Call:  (A YANG Data Model for Interface Management) to Proposed Standard
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: Sun, 12 May 2013 13:24:19 -0000

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Sunday, May 12, 2013 3:00 PM
> To: Romascanu, Dan (Dan)
> Cc: Andy Bierman; t.petch; Martin Bjorklund; netmod@ietf.org
> Subject: Re: [netmod] Last Call:  10.txt> (A YANG Data Model for Interface Management) to Proposed
> Standard
>=20
> On Sun, May 12, 2013 at 07:18:57AM +0000, Romascanu, Dan (Dan) wrote:
> > Sorry,  I meant:
> >
> > which one of these two statements is true?
> >
> >
> > (Juergen) My understanding was that on systems that only have
> , the  configuration data store is persistent.
> >
> > (Andy) All NETCONF devices have persistent storage of the running
> configuration.
> >
>=20
> Both statement can both be true. ;-) The problem is to find the relevant
> pieces of text in the RFCs that talk about persistence since apparently
> this is where some people are confused.
>=20
> RFC 6241 says for example:
>=20
>    o  configuration datastore: The datastore holding the complete set of
>       configuration data that is required to get a device from its
>       initial default state into a desired operational state.
>=20
> While this does not say 'persist', one might argue that persistence is
> kind of implied in order to "get a device from its initial default state
> into a desired operational state". And the startup datastore really is a
> special feature:
>=20
>    o  startup configuration datastore: The configuration datastore
>       holding the configuration loaded by the device when it boots.
>       Only present on devices that separate the startup configuration
>       datastore from the running configuration datastore.
>=20
> Even without a startup, your running datastore still persists since it
> is a configuration datastore.
>=20
>    o  running configuration datastore: A configuration datastore holding
>       the complete configuration currently active on the device.  The
>       running configuration datastore always exists.
>=20
> NETCONF was designed to modify configuration data and configuration data
> usually persists (otherwise we would simply talk about writable
> operational state, the stuff i2rs people are working on).
>=20
> /js
>=20

[[DR]] So the practical way to formulate the requirement would be:=20

Any device that supports NETCONF MUST implement the running configuration d=
atastore in persistent memory.=20

This is an important requirement from the point of view of developers imple=
menting NETCONF on devices. I believe it should be stated directly and clea=
rly, in a way that does not leave the way open to other implementations.=20

Regards,

Dan


From andy@yumaworks.com  Sun May 12 07:00:50 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 11F0521F8607 for ; Sun, 12 May 2013 07:00:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.021
X-Spam-Level: 
X-Spam-Status: No, score=-1.021 tagged_above=-999 required=5 tests=[AWL=0.956,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZpyWOYxIyMX for ; Sun, 12 May 2013 07:00:49 -0700 (PDT)
Received: from mail-ia0-x232.google.com (mail-ia0-x232.google.com [IPv6:2607:f8b0:4001:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2064521F849C for ; Sun, 12 May 2013 07:00:49 -0700 (PDT)
Received: by mail-ia0-f178.google.com with SMTP id i9so2675669iad.9 for ; Sun, 12 May 2013 07:00:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=IAYJkVVYO/pxMnAU39vJ+aMGGpLJQObOZr6elnlqEKY=; b=jlq2f3TKphZy34XyQALpLu2kXD5qPcZl8Y2FRw02scjtPvK3li9CQyqfSNhUEZlhJX B1P1/C3IT3AaUM4AicnLZahVo+Q5M/GpRf2zodNveOjdUXjI0Krb1h+eDKvElPjWdH38 VMav6/8YJRhX+mkcTfGTAcFuNu32kZQyZxM+iyhq9aNwKXsQP5BizEqti97lJ9qR4GLM Uw5RzlN8c3fnaFFXkzb2QCcTJrwK1oZLJNJS/BtUARyYp4E2DueWuCOZg4jgDeUsMz7h a+4AmXbXXyGlvwkpD89zjvC1q9ytkbZ+cA24UMTSN5lfQb0l1c1oln8oxBMrtQ8q4D/g V7AA==
MIME-Version: 1.0
X-Received: by 10.50.236.100 with SMTP id ut4mr7083447igc.86.1368367248611; Sun, 12 May 2013 07:00:48 -0700 (PDT)
Received: by 10.231.125.202 with HTTP; Sun, 12 May 2013 07:00:48 -0700 (PDT)
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA16A0BF@AZ-FFEXMB04.global.avaya.com>
References:  <00f401ce4a19$772563e0$6b01a8c0@oemcomputer> <20130506.075705.181961749.mbj@tail-f.com> <002f01ce4d72$b2acc280$4001a8c0@gateway.2wire.net> <20130510123639.GA71399@elstar.local> <010901ce4d9f$2c15fb60$4001a8c0@gateway.2wire.net> <20130510192028.GH72461@elstar.local>  <9904FB1B0159DA42B0B887B7FA8119CA1699A6@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA1699BE@AZ-FFEXMB04.global.avaya.com> <20130512120016.GA4203@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA16A0BF@AZ-FFEXMB04.global.avaya.com>
Date: Sun, 12 May 2013 07:00:48 -0700
Message-ID: 
From: Andy Bierman 
To: "Romascanu, Dan (Dan)" 
Content-Type: multipart/alternative; boundary=14dae9399de3c6c8df04dc85d3de
X-Gm-Message-State: ALoCoQm6JgMqfYMtJ389eIkjf7kKtoNawMwC5Q39mDcd+DZqGepSbPZmNDE9s4tK/AmO1qQX/MaH
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Last Call:  (A YANG Data Model for Interface Management) to Proposed Standard
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: Sun, 12 May 2013 14:00:50 -0000

--14dae9399de3c6c8df04dc85d3de
Content-Type: text/plain; charset=ISO-8859-1

On Sun, May 12, 2013 at 6:24 AM, Romascanu, Dan (Dan) wrote:

>
>
>
>
> > -----Original Message-----
> > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> > university.de]
> > Sent: Sunday, May 12, 2013 3:00 PM
> > To: Romascanu, Dan (Dan)
> > Cc: Andy Bierman; t.petch; Martin Bjorklund; netmod@ietf.org
> > Subject: Re: [netmod] Last Call:  > 10.txt> (A YANG Data Model for Interface Management) to Proposed
> > Standard
> >
> > On Sun, May 12, 2013 at 07:18:57AM +0000, Romascanu, Dan (Dan) wrote:
> > > Sorry,  I meant:
> > >
> > > which one of these two statements is true?
> > >
> > >
> > > (Juergen) My understanding was that on systems that only have
> > , the  configuration data store is persistent.
> > >
> > > (Andy) All NETCONF devices have persistent storage of the running
> > configuration.
> > >
> >
> > Both statement can both be true. ;-) The problem is to find the relevant
> > pieces of text in the RFCs that talk about persistence since apparently
> > this is where some people are confused.
> >
> > RFC 6241 says for example:
> >
> >    o  configuration datastore: The datastore holding the complete set of
> >       configuration data that is required to get a device from its
> >       initial default state into a desired operational state.
> >
> > While this does not say 'persist', one might argue that persistence is
> > kind of implied in order to "get a device from its initial default state
> > into a desired operational state". And the startup datastore really is a
> > special feature:
> >
> >    o  startup configuration datastore: The configuration datastore
> >       holding the configuration loaded by the device when it boots.
> >       Only present on devices that separate the startup configuration
> >       datastore from the running configuration datastore.
> >
> > Even without a startup, your running datastore still persists since it
> > is a configuration datastore.
> >
> >    o  running configuration datastore: A configuration datastore holding
> >       the complete configuration currently active on the device.  The
> >       running configuration datastore always exists.
> >
> > NETCONF was designed to modify configuration data and configuration data
> > usually persists (otherwise we would simply talk about writable
> > operational state, the stuff i2rs people are working on).
> >
> > /js
> >
>
> [[DR]] So the practical way to formulate the requirement would be:
>
> Any device that supports NETCONF MUST implement the running configuration
> datastore in persistent memory.
>
> This is an important requirement from the point of view of developers
> implementing NETCONF on devices. I believe it should be stated directly and
> clearly, in a way that does not leave the way open to other implementations.
>
>
Not sure why this is an issue.
Is anybody selling a NETCONF server that tosses all edits on the next
reboot?
Has anyone seen any evidence at all that the persistence of the running
config
is not implemented in NETCONF servers?

Clarifications are fine, but I don't think developers are confused on this
point.



> Regards,
>
> Dan
>
>
Andy

--14dae9399de3c6c8df04dc85d3de
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Sun, May 12, 2013 at 6:24 AM, Romasca=
nu, Dan (Dan) <dromasca@avaya.com> wrote:









> -----Original Message-----

> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-

> university.de]<=
br>
> Sent: Sunday, May 12, 2013 3:00 PM

> To: Romascanu, Dan (Dan)

> Cc: Andy Bierman; t.petch; Martin Bjorklund; netmod@ietf.org

> Subject: Re: [netmod] Last Call: <draft-ietf-netmod-interfaces-cfg-=


> 10.txt> (A YANG Data Model for Interface Management) to Proposed
> Standard

>

> On Sun, May 12, 2013 at 07:18:57AM +0000, Romascanu, Dan (Dan) wrote:<=
br>
> > Sorry, =A0I meant:

> >

> > which one of these two statements is true?

> >

> >

> > (Juergen) My understanding was that on systems that only have

> <running>, the <running> configuration data store is persi=
stent.

> >

> > (Andy) All NETCONF devices have persistent storage of the running=


> configuration.

> >

>

> Both statement can both be true. ;-) The problem is to find the releva=
nt

> pieces of text in the RFCs that talk about persistence since apparentl=
y

> this is where some people are confused.

>

> RFC 6241 says for example:

>

> =A0 =A0o =A0configuration datastore: The datastore holding the complet=
e set of

> =A0 =A0 =A0 configuration data that is required to get a device from i=
ts

> =A0 =A0 =A0 initial default state into a desired operational state.
>

> While this does not say 'persist', one might argue that persis=
tence is

> kind of implied in order to "get a device from its initial defaul=
t state

> into a desired operational state". And the startup datastore real=
ly is a

> special feature:

>

> =A0 =A0o =A0startup configuration datastore: The configuration datasto=
re

> =A0 =A0 =A0 holding the configuration loaded by the device when it boo=
ts.

> =A0 =A0 =A0 Only present on devices that separate the startup configur=
ation

> =A0 =A0 =A0 datastore from the running configuration datastore.

>

> Even without a startup, your running datastore still persists since it=


> is a configuration datastore.

>

> =A0 =A0o =A0running configuration datastore: A configuration datastore=
 holding

> =A0 =A0 =A0 the complete configuration currently active on the device.=
 =A0The

> =A0 =A0 =A0 running configuration datastore always exists.

>

> NETCONF was designed to modify configuration data and configuration da=
ta

> usually persists (otherwise we would simply talk about writable

> operational state, the stuff i2rs people are working on).

>

> /js

>



[[DR]] So the practical way to formulate the requirement would be:



Any device that supports NETCONF MUST implement the running configuration d=
atastore in persistent memory.



This is an important requirement from the point of view of developers imple=
menting NETCONF on devices. I believe it should be stated directly and clea=
rly, in a way that does not leave the way open to other implementations.



Not sure why this is an issue.
Is anybody selling a NETCONF server that tosses all edits on the next re=
boot?
Has anyone seen any evidence at all that the persistence of=
 the running config


is not implemented in NETCONF servers?

Clarif=
ications are fine, but I don't think developers are confused on this po=
int.

=A0


Regards,



Dan





Andy



--14dae9399de3c6c8df04dc85d3de--

From dromasca@avaya.com  Sun May 12 07:09: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 CCC6E21F8E3C for ; Sun, 12 May 2013 07:09:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.493
X-Spam-Level: 
X-Spam-Status: No, score=-103.493 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, 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 6btt9TOh8hjH for ; Sun, 12 May 2013 07:09:00 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 880DA21F8518 for ; Sun, 12 May 2013 07:08:54 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Al8FAAH/ZlHGmAcF/2dsb2JhbABQgkIjITavZokxiDGBBxZ0gh8BAQEBAgESFQZMBQcEAgEIDQMBBAEBAQoZBAcyFAkIAgQOBQgah2wGAaBHnQwXjWp7JgsGAQYDgldhA5M2hG2FBopogVWBNoFrPQ
X-IronPort-AV: E=Sophos;i="4.87,456,1363147200"; d="scan'208,217";a="10842935"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 12 May 2013 10:08:53 -0400
Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 12 May 2013 10:04:11 -0400
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.02.0328.009; Sun, 12 May 2013 10:08:48 -0400
From: "Romascanu, Dan (Dan)" 
To: Andy Bierman 
Thread-Topic: [netmod] Last Call:  (A YANG Data Model for Interface Management) to Proposed Standard
Thread-Index: AQHOTbN3zPPinsiIE0Sb8ujAuUIC0Zj/FgcAgAIONUCAAAIOIIAAkecA///RqYCAAFACAP//vqSA
Date: Sun, 12 May 2013 14:08:48 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA16A0F8@AZ-FFEXMB04.global.avaya.com>
References:  <00f401ce4a19$772563e0$6b01a8c0@oemcomputer> <20130506.075705.181961749.mbj@tail-f.com> <002f01ce4d72$b2acc280$4001a8c0@gateway.2wire.net> <20130510123639.GA71399@elstar.local> <010901ce4d9f$2c15fb60$4001a8c0@gateway.2wire.net> <20130510192028.GH72461@elstar.local>  <9904FB1B0159DA42B0B887B7FA8119CA1699A6@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA1699BE@AZ-FFEXMB04.global.avaya.com> <20130512120016.GA4203@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA16A0BF@AZ-FFEXMB04.global.avaya.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.64.58.45]
Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA16A0F8AZFFEXMB04globala_"
MIME-Version: 1.0
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Last Call:  (A YANG Data Model for Interface Management) to Proposed Standard
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: Sun, 12 May 2013 14:09:05 -0000

--_000_9904FB1B0159DA42B0B887B7FA8119CA16A0F8AZFFEXMB04globala_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable




From: Andy Bierman [mailto:andy@yumaworks.com]
Sent: Sunday, May 12, 2013 5:01 PM
To: Romascanu, Dan (Dan)
Cc: Juergen Schoenwaelder; t.petch; Martin Bjorklund; netmod@ietf.org
Subject: Re: [netmod] Last Call:  =
(A YANG Data Model for Interface Management) to Proposed Standard


On Sun, May 12, 2013 at 6:24 AM, Romascanu, Dan (Dan) > wrote:




> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Sunday, May 12, 2013 3:00 PM
> To: Romascanu, Dan (Dan)
> Cc: Andy Bierman; t.petch; Martin Bjorklund; netmod@ietf.org
> Subject: Re: [netmod] Last Call:  10.txt> (A YANG Data Model for Interface Management) to Proposed
> Standard
>
> On Sun, May 12, 2013 at 07:18:57AM +0000, Romascanu, Dan (Dan) wrote:
> > Sorry,  I meant:
> >
> > which one of these two statements is true?
> >
> >
> > (Juergen) My understanding was that on systems that only have
> , the  configuration data store is persistent.
> >
> > (Andy) All NETCONF devices have persistent storage of the running
> configuration.
> >
>
> Both statement can both be true. ;-) The problem is to find the relevant
> pieces of text in the RFCs that talk about persistence since apparently
> this is where some people are confused.
>
> RFC 6241 says for example:
>
>    o  configuration datastore: The datastore holding the complete set of
>       configuration data that is required to get a device from its
>       initial default state into a desired operational state.
>
> While this does not say 'persist', one might argue that persistence is
> kind of implied in order to "get a device from its initial default state
> into a desired operational state". And the startup datastore really is a
> special feature:
>
>    o  startup configuration datastore: The configuration datastore
>       holding the configuration loaded by the device when it boots.
>       Only present on devices that separate the startup configuration
>       datastore from the running configuration datastore.
>
> Even without a startup, your running datastore still persists since it
> is a configuration datastore.
>
>    o  running configuration datastore: A configuration datastore holding
>       the complete configuration currently active on the device.  The
>       running configuration datastore always exists.
>
> NETCONF was designed to modify configuration data and configuration data
> usually persists (otherwise we would simply talk about writable
> operational state, the stuff i2rs people are working on).
>
> /js
>

[[DR]] So the practical way to formulate the requirement would be:

Any device that supports NETCONF MUST implement the running configuration d=
atastore in persistent memory.

This is an important requirement from the point of view of developers imple=
menting NETCONF on devices. I believe it should be stated directly and clea=
rly, in a way that does not leave the way open to other implementations.

Not sure why this is an issue.
Is anybody selling a NETCONF server that tosses all edits on the next reboo=
t?
Has anyone seen any evidence at all that the persistence of the running con=
fig
is not implemented in NETCONF servers?

Clarifications are fine, but I don't think developers are confused on this =
point.

 [[DR]] I believe that this discussion proves that the text is not clear. I=
f everybody agrees and clarifications are fine, let us put them in text.

Regards,

Dan



--_000_9904FB1B0159DA42B0B887B7FA8119CA16A0F8AZFFEXMB04globala_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











 <=
/p>

 <=
/p>

 <=
/p>







From: Andy Bie=
rman [mailto:andy@yumaworks.com]


Sent: Sunday, May 12, 2013 5:01 PM

To: Romascanu, Dan (Dan)

Cc: Juergen Schoenwaelder; t.petch; Martin Bjorklund; netmod@ietf.or=
g

Subject: Re: [netmod] Last Call: <draft-ietf-netmod-interfaces-cf=
g-10.txt> (A YANG Data Model for Interface Management) to Proposed Stand=
ard






 


 




On Sun, May 12, 2013 at 6:24 AM, Romascanu, Dan (Dan=
) <dromasca@avay=
a.com> wrote:










> -----Original Message-----

> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-

> university.de]<=
br>
> Sent: Sunday, May 12, 2013 3:00 PM

> To: Romascanu, Dan (Dan)

> Cc: Andy Bierman; t.petch; Martin Bjorklund; netmod@ietf.org

> Subject: Re: [netmod] Last Call: <draft-ietf-netmod-interfaces-cfg-=


> 10.txt> (A YANG Data Model for Interface Management) to Proposed
> Standard

>

> On Sun, May 12, 2013 at 07:18:57AM +0000, Romascanu, Dan (Dan) wro=
te:

> > Sorry,  I meant:

> >

> > which one of these two statements is true?

> >

> >

> > (Juergen) My understanding was that on systems that only have

> <running>, the <running> configuration data store is persi=
stent.

> >

> > (Andy) All NETCONF devices have persistent storage of the running=


> configuration.

> >

>

> Both statement can both be true. ;-) The problem is to find the releva=
nt

> pieces of text in the RFCs that talk about persistence since apparentl=
y

> this is where some people are confused.

>

> RFC 6241 says for example:

>

>    o  configuration datastore: The datastore holding th=
e complete set of

>       configuration data that is required to get a devi=
ce from its

>       initial default state into a desired operational =
state.

>

> While this does not say 'persist', one might argue that persistence is=


> kind of implied in order to "get a device from its initial defaul=
t state

> into a desired operational state". And the startup datastore real=
ly is a

> special feature:

>

>    o  startup configuration datastore: The configuratio=
n datastore

>       holding the configuration loaded by the device wh=
en it boots.

>       Only present on devices that separate the startup=
 configuration

>       datastore from the running configuration datastor=
e.

>

> Even without a startup, your running datastore still persists since it=


> is a configuration datastore.

>

>    o  running configuration datastore: A configuration =
datastore holding

>       the complete configuration currently active on th=
e device.  The

>       running configuration datastore always exists.
>

> NETCONF was designed to modify configuration data and configuration da=
ta

> usually persists (otherwise we would simply talk about writable

> operational state, the stuff i2rs people are working on).

>

> /js

>



[[DR]] So the practical way to formulate the requirement would be:



Any device that supports NETCONF MUST implement the running configuration d=
atastore in persistent memory.



This is an important requirement from the point of view of developers imple=
menting NETCONF on devices. I believe it should be stated directly and clea=
rly, in a way that does not leave the way open to other implementations.




 






Not sure why this is an issue.






Is anybody selling a NETCONF server that tosses all =
edits on the next reboot?






Has anyone seen any evidence at all that the persist=
ence of the running config






is not implemented in NETCONF servers?





 






Clarifications are fine, but I don't think developer=
s are confused on this point.






 






 [[DR]] I believe tha=
t this discussion proves that the text is not clear. If everybody agrees an=
d clarifications are fine, let us put them in text.



 


Regards,


 


Dan


 <=
/p>







 










--_000_9904FB1B0159DA42B0B887B7FA8119CA16A0F8AZFFEXMB04globala_--

From andy@yumaworks.com  Sun May 12 07:26:50 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 1155B21F86CE for ; Sun, 12 May 2013 07:26:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.18
X-Spam-Level: 
X-Spam-Status: No, score=-1.18 tagged_above=-999 required=5 tests=[AWL=0.797,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHClq0FyZFpj for ; Sun, 12 May 2013 07:26:49 -0700 (PDT)
Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id EE54721F84B5 for ; Sun, 12 May 2013 07:26:48 -0700 (PDT)
Received: by mail-ie0-f169.google.com with SMTP id u16so11093753iet.0 for ; Sun, 12 May 2013 07:26:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=30mrWnbuRSb0shJXyHQLKmNi7T93X+c9iRUanVVeAMc=; b=OtAwcO5YhwX4gyra0CH9h2lFwXvj9caSXDTMdCeiqj1Rz4HXhGRNxPoeKoK7GXBY5k ecweRzOlUxeflGSfEz9XtLeHzaQhM6il4XlnfJfCPR1qfQUTCfvOivHlu6DZ8xVYRdCo XYL4pngBAQ4kQrOFfshwG2CqW/rkNs3O6Qz6e7enx+xAkEzAjboRbJ2vVU/WpuvZdFM5 jlq8oS2sOKJ+yUkg9qLAdXBbYJSS2zyxGU2aMPbJ3CHOQz+D54DkJzCb3/2ht/Y4xsD7 T0RhkBS7GO/CthqR2mLKFYKudBx5B0Bw2WD2ZDFofvNGPPp+WdmaAkK3VMyMHo2/3csL 5U5Q==
MIME-Version: 1.0
X-Received: by 10.50.120.4 with SMTP id ky4mr7130381igb.86.1368368808567; Sun, 12 May 2013 07:26:48 -0700 (PDT)
Received: by 10.231.125.202 with HTTP; Sun, 12 May 2013 07:26:48 -0700 (PDT)
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA16A0F8@AZ-FFEXMB04.global.avaya.com>
References:  <00f401ce4a19$772563e0$6b01a8c0@oemcomputer> <20130506.075705.181961749.mbj@tail-f.com> <002f01ce4d72$b2acc280$4001a8c0@gateway.2wire.net> <20130510123639.GA71399@elstar.local> <010901ce4d9f$2c15fb60$4001a8c0@gateway.2wire.net> <20130510192028.GH72461@elstar.local>  <9904FB1B0159DA42B0B887B7FA8119CA1699A6@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA1699BE@AZ-FFEXMB04.global.avaya.com> <20130512120016.GA4203@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA16A0BF@AZ-FFEXMB04.global.avaya.com>  <9904FB1B0159DA42B0B887B7FA8119CA16A0F8@AZ-FFEXMB04.global.avaya.com>
Date: Sun, 12 May 2013 07:26:48 -0700
Message-ID: 
From: Andy Bierman 
To: "Romascanu, Dan (Dan)" 
Content-Type: multipart/alternative; boundary=047d7b8746d4c1b8f204dc8630b9
X-Gm-Message-State: ALoCoQmC7csZ8naXQPpF2KvczOQXmMGT0nZ+CICHiSo+ZZxgEzCRgKQBewTfbR2lBpep/KsSeW49
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Last Call:  (A YANG Data Model for Interface Management) to Proposed Standard
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: Sun, 12 May 2013 14:26:50 -0000

--047d7b8746d4c1b8f204dc8630b9
Content-Type: text/plain; charset=ISO-8859-1

On Sun, May 12, 2013 at 7:08 AM, Romascanu, Dan (Dan) wrote:

>  ** **
>
> ** **
>
> ** **
>
> *From:* Andy Bierman [mailto:andy@yumaworks.com]
> *Sent:* Sunday, May 12, 2013 5:01 PM
> *To:* Romascanu, Dan (Dan)
> *Cc:* Juergen Schoenwaelder; t.petch; Martin Bjorklund; netmod@ietf.org
> *Subject:* Re: [netmod] Last Call:
>  (A YANG Data Model for Interface
> Management) to Proposed Standard****
>
> ** **
>
> ** **
>
> On Sun, May 12, 2013 at 6:24 AM, Romascanu, Dan (Dan) 
> wrote:****
>
>
>
>
>
> > -----Original Message-----
> > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> > university.de]
> > Sent: Sunday, May 12, 2013 3:00 PM
> > To: Romascanu, Dan (Dan)
> > Cc: Andy Bierman; t.petch; Martin Bjorklund; netmod@ietf.org
> > Subject: Re: [netmod] Last Call:  > 10.txt> (A YANG Data Model for Interface Management) to Proposed
> > Standard
> >
> > On Sun, May 12, 2013 at 07:18:57AM +0000, Romascanu, Dan (Dan) wrote:
> > > Sorry,  I meant:
> > >
> > > which one of these two statements is true?
> > >
> > >
> > > (Juergen) My understanding was that on systems that only have
> > , the  configuration data store is persistent.
> > >
> > > (Andy) All NETCONF devices have persistent storage of the running
> > configuration.
> > >
> >
> > Both statement can both be true. ;-) The problem is to find the relevant
> > pieces of text in the RFCs that talk about persistence since apparently
> > this is where some people are confused.
> >
> > RFC 6241 says for example:
> >
> >    o  configuration datastore: The datastore holding the complete set of
> >       configuration data that is required to get a device from its
> >       initial default state into a desired operational state.
> >
> > While this does not say 'persist', one might argue that persistence is
> > kind of implied in order to "get a device from its initial default state
> > into a desired operational state". And the startup datastore really is a
> > special feature:
> >
> >    o  startup configuration datastore: The configuration datastore
> >       holding the configuration loaded by the device when it boots.
> >       Only present on devices that separate the startup configuration
> >       datastore from the running configuration datastore.
> >
> > Even without a startup, your running datastore still persists since it
> > is a configuration datastore.
> >
> >    o  running configuration datastore: A configuration datastore holding
> >       the complete configuration currently active on the device.  The
> >       running configuration datastore always exists.
> >
> > NETCONF was designed to modify configuration data and configuration data
> > usually persists (otherwise we would simply talk about writable
> > operational state, the stuff i2rs people are working on).
> >
> > /js
> >
>
> [[DR]] So the practical way to formulate the requirement would be:
>
> Any device that supports NETCONF MUST implement the running configuration
> datastore in persistent memory.
>
> This is an important requirement from the point of view of developers
> implementing NETCONF on devices. I believe it should be stated directly and
> clearly, in a way that does not leave the way open to other implementations.
> ****
>
> ** **
>
> Not sure why this is an issue.****
>
> Is anybody selling a NETCONF server that tosses all edits on the next
> reboot?****
>
> Has anyone seen any evidence at all that the persistence of the running
> config****
>
> is not implemented in NETCONF servers?****
>
> ** **
>
> Clarifications are fine, but I don't think developers are confused on this
> point.****
>
> ** **
>
>  [[DR]] I believe that this discussion proves that the text is not clear.
> If everybody agrees and clarifications are fine, let us put them in text.
> ****
>
> **
>


OK -- the clarifications would be to the candidate and writable-running
capabilities.
Remember that a "default" NETCONF server is not required to implement any
writable objects.  It is not required to advertise :candidate or
:writable-running.
It is not required to implement  or  unless 1 of
these
capabilities is advertised.


**
>
> Regards,****
>
> ** **
>
> Dan****
>
> ** **
>
> ** **
>

Andy

--047d7b8746d4c1b8f204dc8630b9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Sun, May 12, 2013 at 7:08 AM, Romasca=
nu, Dan (Dan) <dromasca@avaya.com> wrote:












=A0<=
/p>

=A0<=
/p>

=A0<=
/p>







From: Andy Bie=
rman [mailto:andy@y=
umaworks.com]


Sent: Sunday, May 12, 2013 5:01 PM

To: Romascanu, Dan (Dan)

Cc: Juergen Schoenwaelder; t.petch; Martin Bjorklund; netmod@ietf.org

Subject: Re: [netmod] Last Call: <draft-ietf-netmod-interfaces-cf=
g-10.txt> (A YANG Data Model for Interface Management) to Proposed Stand=
ard






=A0


=A0




On Sun, May 12, 2013 at 6:24 AM, Romascanu, Dan (Dan=
) <dromasca@avay=
a.com> wrote:










> -----Original Message-----

> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-

> university.de]<=
br>
> Sent: Sunday, May 12, 2013 3:00 PM

> To: Romascanu, Dan (Dan)

> Cc: Andy Bierman; t.petch; Martin Bjorklund; netmod@ietf.org

> Subject: Re: [netmod] Last Call: <draft-ietf-netmod-interfaces-cfg-=


> 10.txt> (A YANG Data Model for Interface Management) to Proposed
> Standard

>

> On Sun, May 12, 2013 at 07:18:57AM +0000, Romascanu, Dan (Dan) wrote:<=
br>
> > Sorry, =A0I meant:

> >

> > which one of these two statements is true?

> >

> >

> > (Juergen) My understanding was that on systems that only have

> <running>, the <running> configuration data store is persi=
stent.

> >

> > (Andy) All NETCONF devices have persistent storage of the running=


> configuration.

> >

>

> Both statement can both be true. ;-) The problem is to find the releva=
nt

> pieces of text in the RFCs that talk about persistence since apparentl=
y

> this is where some people are confused.

>

> RFC 6241 says for example:

>

> =A0 =A0o =A0configuration datastore: The datastore holding the complet=
e set of

> =A0 =A0 =A0 configuration data that is required to get a device from i=
ts

> =A0 =A0 =A0 initial default state into a desired operational state.
>

> While this does not say 'persist', one might argue that persis=
tence is

> kind of implied in order to "get a device from its initial defaul=
t state

> into a desired operational state". And the startup datastore real=
ly is a

> special feature:

>

> =A0 =A0o =A0startup configuration datastore: The configuration datasto=
re

> =A0 =A0 =A0 holding the configuration loaded by the device when it boo=
ts.

> =A0 =A0 =A0 Only present on devices that separate the startup configur=
ation

> =A0 =A0 =A0 datastore from the running configuration datastore.

>

> Even without a startup, your running datastore still persists since it=


> is a configuration datastore.

>

> =A0 =A0o =A0running configuration datastore: A configuration datastore=
 holding

> =A0 =A0 =A0 the complete configuration currently active on the device.=
 =A0The

> =A0 =A0 =A0 running configuration datastore always exists.

>

> NETCONF was designed to modify configuration data and configuration da=
ta

> usually persists (otherwise we would simply talk about writable

> operational state, the stuff i2rs people are working on).

>

> /js

>



[[DR]] So the practical way to formulate the requirement would be:



Any device that supports NETCONF MUST implement the running configuration d=
atastore in persistent memory.



This is an important requirement from the point of view of developers imple=
menting NETCONF on devices. I believe it should be stated directly and clea=
rly, in a way that does not leave the way open to other implementations.=






=A0






Not sure why this is an issue.






Is anybody selling a NETCONF server that tosses all =
edits on the next reboot?






Has anyone seen any evidence at all that the persist=
ence of the running config






is not implemented in NETCONF servers?=







=A0






Clarifications are fine, but I don't think devel=
opers are confused on this point.






=A0






=A0[[DR]] I believe that t=
his discussion proves that the text is not clear. If everybody agrees and c=
larifications are fine, let us put them in text.



=A0


OK -- the clarific=
ations would be to the candidate and writable-running capabilities.


Remember that a "default" NETCONF server is not required to =
implement any
writable objects. =A0It is not required to advertis=
e :candidate or :writable-running.
It is not required to implemen=
t <edit-config> or <copy-config> unless 1 of these


capabilities is advertised.


=





Regards,
=


=A0


Dan


=A0<=
/p>







=A0












Andy



--047d7b8746d4c1b8f204dc8630b9--

From mbj@tail-f.com  Sun May 12 13:55: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 69A1B21F848A for ; Sun, 12 May 2013 13:55:07 -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 dEiOonepC+wF for ; Sun, 12 May 2013 13:55:02 -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 EE45F21F8B9C for ; Sun, 12 May 2013 13:55:01 -0700 (PDT)
Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id C1CE112008B7; Sun, 12 May 2013 22:54:59 +0200 (CEST)
Date: Sun, 12 May 2013 22:54:59 +0200 (CEST)
Message-Id: <20130512.225459.503916152.mbj@tail-f.com>
To: dromasca@avaya.com
From: Martin Bjorklund 
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA16A0F8@AZ-FFEXMB04.global.avaya.com>
References: <9904FB1B0159DA42B0B887B7FA8119CA16A0BF@AZ-FFEXMB04.global.avaya.com>  <9904FB1B0159DA42B0B887B7FA8119CA16A0F8@AZ-FFEXMB04.global.avaya.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] Last Call:  (A YANG Data Model for Interface Management) to Proposed Standard
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: Sun, 12 May 2013 20:55:07 -0000

"Romascanu, Dan (Dan)"  wrote:
> 
> 
> 
> From: Andy Bierman [mailto:andy@yumaworks.com]
> Sent: Sunday, May 12, 2013 5:01 PM
> To: Romascanu, Dan (Dan)
> Cc: Juergen Schoenwaelder; t.petch; Martin Bjorklund; netmod@ietf.org
> Subject: Re: [netmod] Last Call:  (A
> YANG Data Model for Interface Management) to Proposed Standard
> 
> 
> On Sun, May 12, 2013 at 6:24 AM, Romascanu, Dan (Dan)
> > wrote:
> 
> 
> 
> 
> > -----Original Message-----
> > From: Juergen Schoenwaelder
> > [mailto:j.schoenwaelder@jacobs-
> > university.de]
> > Sent: Sunday, May 12, 2013 3:00 PM
> > To: Romascanu, Dan (Dan)
> > Cc: Andy Bierman; t.petch; Martin Bjorklund;
> > netmod@ietf.org
> > Subject: Re: [netmod] Last Call:  > 10.txt> (A YANG Data Model for Interface Management) to Proposed
> > Standard
> >
> > On Sun, May 12, 2013 at 07:18:57AM +0000, Romascanu, Dan (Dan) wrote:
> > > Sorry,  I meant:
> > >
> > > which one of these two statements is true?
> > >
> > >
> > > (Juergen) My understanding was that on systems that only have
> > , the  configuration data store is persistent.
> > >
> > > (Andy) All NETCONF devices have persistent storage of the running
> > configuration.
> > >
> >
> > Both statement can both be true. ;-) The problem is to find the relevant
> > pieces of text in the RFCs that talk about persistence since apparently
> > this is where some people are confused.
> >
> > RFC 6241 says for example:
> >
> >    o  configuration datastore: The datastore holding the complete set of
> >       configuration data that is required to get a device from its
> >       initial default state into a desired operational state.
> >
> > While this does not say 'persist', one might argue that persistence is
> > kind of implied in order to "get a device from its initial default state
> > into a desired operational state". And the startup datastore really is a
> > special feature:
> >
> >    o  startup configuration datastore: The configuration datastore
> >       holding the configuration loaded by the device when it boots.
> >       Only present on devices that separate the startup configuration
> >       datastore from the running configuration datastore.
> >
> > Even without a startup, your running datastore still persists since it
> > is a configuration datastore.
> >
> >    o  running configuration datastore: A configuration datastore holding
> >       the complete configuration currently active on the device.  The
> >       running configuration datastore always exists.
> >
> > NETCONF was designed to modify configuration data and configuration data
> > usually persists (otherwise we would simply talk about writable
> > operational state, the stuff i2rs people are working on).
> >
> > /js
> >
> 
> [[DR]] So the practical way to formulate the requirement would be:
> 
> Any device that supports NETCONF MUST implement the running configuration
> datastore in persistent memory.

I would say:

  The startup datastore MUST be persistent.

  If startup is implemented, running MUST NOT be persistent.
  If startup is not implemented, running MUST be persitent.

  The candidate datastore MUST be persitent.


/martin

From andy@yumaworks.com  Sun May 12 14:48: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 3261721F8B38 for ; Sun, 12 May 2013 14:48:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.294
X-Spam-Level: 
X-Spam-Status: No, score=-1.294 tagged_above=-999 required=5 tests=[AWL=0.683,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3X6um3DyVTj for ; Sun, 12 May 2013 14:48:02 -0700 (PDT)
Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 3316E21F8B18 for ; Sun, 12 May 2013 14:48:02 -0700 (PDT)
Received: by mail-ie0-f172.google.com with SMTP id 16so11248313iea.31 for ; Sun, 12 May 2013 14:48:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=VYpa+g1Ga/pQh1xwfXD6MKUWWyXBdlsVzgiH7ePIjJY=; b=lxSggsTxviNmKe/l2f676luG9e1UEzWyNgVwEwCIa/zoNhwazcY3tJMip8ayWV75vN Q5NqZeSwJp+4t9G/CM7bE0SJI82AquozakdCN6P7nUGuv24aRgilWpcZ+E4PkdmBCTd6 GuWi+77qyCbvPLNnhwzaCJaZUFXgnyRK0BtkLTQKbls4wQdtg8IagS4BCZ/2o2VLeetY Axve9+jtACDajCKxGtNQI4bqh0UAJCX+AfVM3umKEAfD7g6SJqVetVW3vrXBdR33Z5Bc fubFnGiQgFU1UwVYFK9L1NgypC3GxAGCNYFko1LAsi5QFTyufxrD0+l6uZO+tbFQpKRx qZ0Q==
MIME-Version: 1.0
X-Received: by 10.42.102.211 with SMTP id j19mr12664603ico.0.1368395281720; Sun, 12 May 2013 14:48:01 -0700 (PDT)
Received: by 10.231.125.202 with HTTP; Sun, 12 May 2013 14:48:01 -0700 (PDT)
In-Reply-To: <20130512.225459.503916152.mbj@tail-f.com>
References: <9904FB1B0159DA42B0B887B7FA8119CA16A0BF@AZ-FFEXMB04.global.avaya.com>  <9904FB1B0159DA42B0B887B7FA8119CA16A0F8@AZ-FFEXMB04.global.avaya.com> <20130512.225459.503916152.mbj@tail-f.com>
Date: Sun, 12 May 2013 14:48:01 -0700
Message-ID: 
From: Andy Bierman 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=20cf3011e35dae3d1c04dc8c5a1f
X-Gm-Message-State: ALoCoQnLK05hpUBslNoam2f5ZZn4GXAcqYM3A9sL1fefJU0fBcLMbXVoptM0HY+IZ30ZnpJ2jpI3
Cc: netmod@ietf.org
Subject: Re: [netmod] Last Call:  (A YANG Data Model for Interface Management) to Proposed Standard
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: Sun, 12 May 2013 21:48:03 -0000

--20cf3011e35dae3d1c04dc8c5a1f
Content-Type: text/plain; charset=ISO-8859-1

On Sun, May 12, 2013 at 1:54 PM, Martin Bjorklund  wrote:

> "Romascanu, Dan (Dan)"  wrote:
> >
> >
> >
> > From: Andy Bierman [mailto:andy@yumaworks.com]
> > Sent: Sunday, May 12, 2013 5:01 PM
> > To: Romascanu, Dan (Dan)
> > Cc: Juergen Schoenwaelder; t.petch; Martin Bjorklund; netmod@ietf.org
> > Subject: Re: [netmod] Last Call:
>  (A
> > YANG Data Model for Interface Management) to Proposed Standard
> >
> >
> > On Sun, May 12, 2013 at 6:24 AM, Romascanu, Dan (Dan)
> > > wrote:
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Juergen Schoenwaelder
> > > [mailto:j.schoenwaelder@jacobs-
> > > university.de]
> > > Sent: Sunday, May 12, 2013 3:00 PM
> > > To: Romascanu, Dan (Dan)
> > > Cc: Andy Bierman; t.petch; Martin Bjorklund;
> > > netmod@ietf.org
> > > Subject: Re: [netmod] Last Call:  > > 10.txt> (A YANG Data Model for Interface Management) to Proposed
> > > Standard
> > >
> > > On Sun, May 12, 2013 at 07:18:57AM +0000, Romascanu, Dan (Dan) wrote:
> > > > Sorry,  I meant:
> > > >
> > > > which one of these two statements is true?
> > > >
> > > >
> > > > (Juergen) My understanding was that on systems that only have
> > > , the  configuration data store is persistent.
> > > >
> > > > (Andy) All NETCONF devices have persistent storage of the running
> > > configuration.
> > > >
> > >
> > > Both statement can both be true. ;-) The problem is to find the
> relevant
> > > pieces of text in the RFCs that talk about persistence since apparently
> > > this is where some people are confused.
> > >
> > > RFC 6241 says for example:
> > >
> > >    o  configuration datastore: The datastore holding the complete set
> of
> > >       configuration data that is required to get a device from its
> > >       initial default state into a desired operational state.
> > >
> > > While this does not say 'persist', one might argue that persistence is
> > > kind of implied in order to "get a device from its initial default
> state
> > > into a desired operational state". And the startup datastore really is
> a
> > > special feature:
> > >
> > >    o  startup configuration datastore: The configuration datastore
> > >       holding the configuration loaded by the device when it boots.
> > >       Only present on devices that separate the startup configuration
> > >       datastore from the running configuration datastore.
> > >
> > > Even without a startup, your running datastore still persists since it
> > > is a configuration datastore.
> > >
> > >    o  running configuration datastore: A configuration datastore
> holding
> > >       the complete configuration currently active on the device.  The
> > >       running configuration datastore always exists.
> > >
> > > NETCONF was designed to modify configuration data and configuration
> data
> > > usually persists (otherwise we would simply talk about writable
> > > operational state, the stuff i2rs people are working on).
> > >
> > > /js
> > >
> >
> > [[DR]] So the practical way to formulate the requirement would be:
> >
> > Any device that supports NETCONF MUST implement the running configuration
> > datastore in persistent memory.
>
> I would say:
>
>   The startup datastore MUST be persistent.
>
>   If startup is implemented, running MUST NOT be persistent.
>   If startup is not implemented, running MUST be persitent.
>
>   The candidate datastore MUST be persitent.
>

This does not quite describe the NETCONF persistence model.
When the server starts, the contents of running config get loaded
from some persistent storage.  The contents of candidate,
if it exists, are loaded from running at the same time.


>
> /martin
>

Andy

--20cf3011e35dae3d1c04dc8c5a1f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Sun, May 12, 2013 at 1:54 PM, Martin =
Bjorklund <mbj@tail-f.com> wrote:

"Romascanu, Dan (Dan)" <=
dromasca@avaya.com> wrote:

>

>

>

> From: Andy Bierman [mailto:andy@=
yumaworks.com]

> Sent: Sunday, May 12, 2013 5:01 PM

> To: Romascanu, Dan (Dan)

> Cc: Juergen Schoenwaelder; t.petch; Martin Bjorklund; netmod@ietf.org

> Subject: Re: [netmod] Last Call: <draft-ietf-netmod-interfaces-cfg-=
10.txt> (A

> YANG Data Model for Interface Management) to Proposed Standard

>

>

> On Sun, May 12, 2013 at 6:24 AM, Romascanu, Dan (Dan)

> <dromasca@avaya.com<ma=
ilto:dromasca@avaya.com>> w=
rote:

>

>

>

>

> > -----Original Message-----

> > From: Juergen Schoenwaelder

> > [mailto:j.schoenwaelde=
r@jacobs-<mailto:j.schoen=
waelder@jacobs->

> > university.de<=
/a><http://university=
.de>]

> > Sent: Sunday, May 12, 2013 3:00 PM

> > To: Romascanu, Dan (Dan)

> > Cc: Andy Bierman; t.petch; Martin Bjorklund;

> > netmod@ietf.org<mailto:=
netmod@ietf.org>

> > Subject: Re: [netmod] Last Call: <draft-ietf-netmod-interfaces=
-cfg-

> > 10.txt> (A YANG Data Model for Interface Management) to Propos=
ed

> > Standard

> >

> > On Sun, May 12, 2013 at 07:18:57AM +0000, Romascanu, Dan (Dan) wr=
ote:

> > > Sorry, =A0I meant:

> > >

> > > which one of these two statements is true?

> > >

> > >

> > > (Juergen) My understanding was that on systems that only hav=
e

> > <running>, the <running> configuration data store is =
persistent.

> > >

> > > (Andy) All NETCONF devices have persistent storage of the ru=
nning

> > configuration.

> > >

> >

> > Both statement can both be true. ;-) The problem is to find the r=
elevant

> > pieces of text in the RFCs that talk about persistence since appa=
rently

> > this is where some people are confused.

> >

> > RFC 6241 says for example:

> >

> > =A0 =A0o =A0configuration datastore: The datastore holding the co=
mplete set of

> > =A0 =A0 =A0 configuration data that is required to get a device f=
rom its

> > =A0 =A0 =A0 initial default state into a desired operational stat=
e.

> >

> > While this does not say 'persist', one might argue that p=
ersistence is

> > kind of implied in order to "get a device from its initial d=
efault state

> > into a desired operational state". And the startup datastore=
 really is a

> > special feature:

> >

> > =A0 =A0o =A0startup configuration datastore: The configuration da=
tastore

> > =A0 =A0 =A0 holding the configuration loaded by the device when i=
t boots.

> > =A0 =A0 =A0 Only present on devices that separate the startup con=
figuration

> > =A0 =A0 =A0 datastore from the running configuration datastore.
> >

> > Even without a startup, your running datastore still persists sin=
ce it

> > is a configuration datastore.

> >

> > =A0 =A0o =A0running configuration datastore: A configuration data=
store holding

> > =A0 =A0 =A0 the complete configuration currently active on the de=
vice. =A0The

> > =A0 =A0 =A0 running configuration datastore always exists.

> >

> > NETCONF was designed to modify configuration data and configurati=
on data

> > usually persists (otherwise we would simply talk about writable
> > operational state, the stuff i2rs people are working on).

> >

> > /js

> >

>

> [[DR]] So the practical way to formulate the requirement would be:

>

> Any device that supports NETCONF MUST implement the running configurat=
ion

> datastore in persistent memory.



I would say:



=A0 The startup datastore MUST be persistent.



=A0 If startup is implemented, running MUST NOT be persistent.

=A0 If startup is not implemented, running MUST be persitent.



=A0 The candidate datastore MUST be persitent.

This does not quite describe the NETCONF persistence model.
When the server starts, the contents of running config get loaded


from some persistent storage. =A0The contents of candidate,
=
if it exists, are loaded from running at the same time.







/martin



Andy



--20cf3011e35dae3d1c04dc8c5a1f--

From bclaise@cisco.com  Mon May 13 03:34: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 447F321F9446; Mon, 13 May 2013 03:34:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.987
X-Spam-Level: 
X-Spam-Status: No, score=-8.987 tagged_above=-999 required=5 tests=[AWL=1.612,  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 ymdUidkzQ7ny; Mon, 13 May 2013 03:33:56 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id E722A21F942B; Mon, 13 May 2013 03:33:55 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4DAXsew029514; Mon, 13 May 2013 12:33:54 +0200 (CEST)
Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4DAWwOT003732; Mon, 13 May 2013 12:33:14 +0200 (CEST)
Message-ID: <5190C159.2050509@cisco.com>
Date: Mon, 13 May 2013 12:32:57 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: "Joel M. Halpern" 
References: <5170722E.2070401@nostrum.com> <5171C416.5070105@joelhalpern.com>
In-Reply-To: <5171C416.5070105@joelhalpern.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-netmod-rfc6021-bis.all@tools.ietf.org, gen-art@ietf.org, "A. Jean Mahoney" , NETMOD Working Group , IETF discussion list 
Subject: Re: [netmod] [Gen-art] Review: draft-ietf-netmod-rfc6021-bis-01
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, 13 May 2013 10:34:00 -0000

Forwarding to the authors and WG

Regards, Benoit
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
>
> .
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
> Document: draft-ietf-netmod-rfc6021-bis-01
>     Common YANG Data Types
> Reviewer: Joel M. Halpern
> Review Date: 19-April-2013
> IETF LC End Date: 1-May-2013
> IESG Telechat date: N/A
>
> Summary: This document is nearly ready for publication as a Standards 
> Track RFC
>
> Major issues:
>     (The following may well be a non-issue.)
>     In the revision of the ietf-inet-types, the patterns for the new 
> ip4-address-no-zone and ipv6-address-no-zone are drastically 
> simplified from the ipv4-address and ipv6-address patterns.  The new 
> ipv4-address-no-zone allows any sequence of decimal digits an periods, 
> while the original was carefully defined as dotted quads of 0..255. 
> Similarly, te ipv6-address-no-zone allows any arbitrary sequence of 
> hex digits and colons.  The original patterns were very careful to 
> match rules for validity.  Is there a reason for the change.
>
> Minor issues:
>
> Nits/editorial comments:
>
>


From bclaise@cisco.com  Mon May 13 03:34:51 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 64BC421F89E2; Mon, 13 May 2013 03:34:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.309
X-Spam-Level: 
X-Spam-Status: No, score=-9.309 tagged_above=-999 required=5 tests=[AWL=1.290,  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 t+1UqbXohvht; Mon, 13 May 2013 03:34:47 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 2044921F84B1; Mon, 13 May 2013 03:34:24 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4DAYNBu029679; Mon, 13 May 2013 12:34:24 +0200 (CEST)
Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4DAXbo4004285; Mon, 13 May 2013 12:33:52 +0200 (CEST)
Message-ID: <5190C181.8020500@cisco.com>
Date: Mon, 13 May 2013 12:33:37 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: "Joel M. Halpern" 
References: <5170722E.2070401@nostrum.com> <5171C416.5070105@joelhalpern.com> <518D0635.7040301@joelhalpern.com>
In-Reply-To: <518D0635.7040301@joelhalpern.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-netmod-rfc6021-bis.all@tools.ietf.org, gen-art@ietf.org, "A. Jean Mahoney" , NETMOD Working Group , IETF discussion list 
Subject: Re: [netmod] [Gen-art]  Review: draft-ietf-netmod-rfc6021-bis-01
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, 13 May 2013 10:34:51 -0000

Forwarding to the authors and WG

Regards, Benoit
> I am guessing that the authors intended the addition of the text 
> emphasizing that the no-zone typedefs are derived general typedef 
> addresses the difference in the patterns.
>
> Is there a YANG rule that says tat if typedef X is derived from 
> typedef Y then the string for X must match the pattern for X and the 
> pattern for Y?  If so, then my concern below is misplaced. (The fact 
> that I find the vague pattern for the child misleading is not a fault 
> with the document, but rather in my head, under that requirement.)
>
> Yours,
> Joel
>
> On 4/19/2013 6:24 PM, Joel M. Halpern wrote:
>> I am the assigned Gen-ART reviewer for this draft. For background on
>> Gen-ART, please see the FAQ at
>>
>> .
>>
>> Please resolve these comments along with any other Last Call comments
>> you may receive.
>>
>> Document: draft-ietf-netmod-rfc6021-bis-01
>>      Common YANG Data Types
>> Reviewer: Joel M. Halpern
>> Review Date: 19-April-2013
>> IETF LC End Date: 1-May-2013
>> IESG Telechat date: N/A
>>
>> Summary: This document is nearly ready for publication as a Standards
>> Track RFC
>>
>> Major issues:
>>      (The following may well be a non-issue.)
>>      In the revision of the ietf-inet-types, the patterns for the new
>> ip4-address-no-zone and ipv6-address-no-zone are drastically simplified
>> from the ipv4-address and ipv6-address patterns.  The new
>> ipv4-address-no-zone allows any sequence of decimal digits an periods,
>> while the original was carefully defined as dotted quads of 0..255.
>> Similarly, te ipv6-address-no-zone allows any arbitrary sequence of hex
>> digits and colons.  The original patterns were very careful to match
>> rules for validity.  Is there a reason for the change.
>>
>> Minor issues:
>>
>> Nits/editorial comments:
>> _______________________________________________
>> Gen-art mailing list
>> Gen-art@ietf.org
>> https://www.ietf.org/mailman/listinfo/gen-art
>>
>
>


From j.schoenwaelder@jacobs-university.de  Mon May 13 03:37: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 342CF21F8E9E; Mon, 13 May 2013 03:37:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.249
X-Spam-Level: 
X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjlUsqc6NlkM; Mon, 13 May 2013 03:37:51 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD2521F9446; Mon, 13 May 2013 03:37:51 -0700 (PDT)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7644320C2C; Mon, 13 May 2013 12:37:50 +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 V-IHdEMKNm7p; Mon, 13 May 2013 12:37:50 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B745420C23; Mon, 13 May 2013 12:37:49 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 13D48263524C; Mon, 13 May 2013 12:37:47 +0200 (CEST)
Date: Mon, 13 May 2013 12:37:47 +0200
From: Juergen Schoenwaelder 
To: Benoit Claise 
Message-ID: <20130513103745.GB8186@elstar.local>
Mail-Followup-To: Benoit Claise , "Joel M. Halpern" , "A. Jean Mahoney" , gen-art@ietf.org, IETF discussion list , NETMOD Working Group , draft-ietf-netmod-rfc6021-bis.all@tools.ietf.org
References: <5170722E.2070401@nostrum.com> <5171C416.5070105@joelhalpern.com> <518D0635.7040301@joelhalpern.com> <5190C181.8020500@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5190C181.8020500@cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: IETF discussion list , NETMOD Working Group , gen-art@ietf.org, draft-ietf-netmod-rfc6021-bis.all@tools.ietf.org, "A. Jean Mahoney" 
Subject: Re: [netmod] [Gen-art]  Review: draft-ietf-netmod-rfc6021-bis-01
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, 13 May 2013 10:37:56 -0000

Joel,

this is specified in the third paragraph of section 9.4.6 of RFC 6020:

9.4.6.  The pattern Statement

   The "pattern" statement, which is an optional substatement to the
   "type" statement, takes as an argument a regular expression string,
   as defined in [XSD-TYPES].  It is used to restrict the built-in type
   "string", or types derived from "string", to values that match the
   pattern.

   If the type has multiple "pattern" statements, the expressions are
   ANDed together, i.e., all such expressions have to match.

   If a pattern restriction is applied to an already pattern-restricted
   type, values must match all patterns in the base type, in addition to
   the new patterns.

/js

On Mon, May 13, 2013 at 12:33:37PM +0200, Benoit Claise wrote:
> Forwarding to the authors and WG
> 
> Regards, Benoit
> >I am guessing that the authors intended the addition of the text
> >emphasizing that the no-zone typedefs are derived general typedef
> >addresses the difference in the patterns.
> >
> >Is there a YANG rule that says tat if typedef X is derived from
> >typedef Y then the string for X must match the pattern for X and
> >the pattern for Y?  If so, then my concern below is misplaced.
> >(The fact that I find the vague pattern for the child misleading
> >is not a fault with the document, but rather in my head, under
> >that requirement.)
> >
> >Yours,
> >Joel
> >
> >On 4/19/2013 6:24 PM, Joel M. Halpern wrote:
> >>I am the assigned Gen-ART reviewer for this draft. For background on
> >>Gen-ART, please see the FAQ at
> >>
> >>.
> >>
> >>Please resolve these comments along with any other Last Call comments
> >>you may receive.
> >>
> >>Document: draft-ietf-netmod-rfc6021-bis-01
> >>     Common YANG Data Types
> >>Reviewer: Joel M. Halpern
> >>Review Date: 19-April-2013
> >>IETF LC End Date: 1-May-2013
> >>IESG Telechat date: N/A
> >>
> >>Summary: This document is nearly ready for publication as a Standards
> >>Track RFC
> >>
> >>Major issues:
> >>     (The following may well be a non-issue.)
> >>     In the revision of the ietf-inet-types, the patterns for the new
> >>ip4-address-no-zone and ipv6-address-no-zone are drastically simplified
> >>from the ipv4-address and ipv6-address patterns.  The new
> >>ipv4-address-no-zone allows any sequence of decimal digits an periods,
> >>while the original was carefully defined as dotted quads of 0..255.
> >>Similarly, te ipv6-address-no-zone allows any arbitrary sequence of hex
> >>digits and colons.  The original patterns were very careful to match
> >>rules for validity.  Is there a reason for the change.
> >>
> >>Minor issues:
> >>
> >>Nits/editorial comments:
> >>_______________________________________________
> >>Gen-art mailing list
> >>Gen-art@ietf.org
> >>https://www.ietf.org/mailman/listinfo/gen-art
> >>
> >
> >
> 

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From jmh@joelhalpern.com  Mon May 13 05:18:02 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 5460921F9579; Mon, 13 May 2013 05:18:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 puEmthCnPPPS; Mon, 13 May 2013 05:17:57 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id A2F4521F9408; Mon, 13 May 2013 05:17:57 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 8B0AB1C08E0; Mon, 13 May 2013 05:17:57 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [10.10.10.104] (pool-70-106-134-119.clppva.east.verizon.net [70.106.134.119]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 1AC461C07C6; Mon, 13 May 2013 05:17:55 -0700 (PDT)
Message-ID: <5190D9E8.7040004@joelhalpern.com>
Date: Mon, 13 May 2013 08:17:44 -0400
From: "Joel M. Halpern" 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Benoit Claise ,  "Joel M. Halpern" , "A. Jean Mahoney" , gen-art@ietf.org,  IETF discussion list , NETMOD Working Group ,  draft-ietf-netmod-rfc6021-bis.all@tools.ietf.org
References: <5170722E.2070401@nostrum.com> <5171C416.5070105@joelhalpern.com> <518D0635.7040301@joelhalpern.com> <5190C181.8020500@cisco.com> <20130513103745.GB8186@elstar.local>
In-Reply-To: <20130513103745.GB8186@elstar.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [netmod] [Gen-art]  Review: draft-ietf-netmod-rfc6021-bis-01
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, 13 May 2013 12:18:02 -0000

Thank you Juergen.  I see that the pattern statement is therefore correct.
And presumably it is a judgment call as to hw to write te new pattern to 
restrict the old one.  Personally, I find a pattern statement that 
covers a whole lot of other things, but that happens when combined with 
the parent patter to give the right result, to be a confusing way to 
document what is needed.  But I can not claim it is technically 
incorrect.  (And I suppose that some would claim that repeating the more 
detailed parent pattern is redundant.)

Yours,
Joel

On 5/13/2013 6:37 AM, Juergen Schoenwaelder wrote:
> Joel,
>
> this is specified in the third paragraph of section 9.4.6 of RFC 6020:
>
> 9.4.6.  The pattern Statement
>
>     The "pattern" statement, which is an optional substatement to the
>     "type" statement, takes as an argument a regular expression string,
>     as defined in [XSD-TYPES].  It is used to restrict the built-in type
>     "string", or types derived from "string", to values that match the
>     pattern.
>
>     If the type has multiple "pattern" statements, the expressions are
>     ANDed together, i.e., all such expressions have to match.
>
>     If a pattern restriction is applied to an already pattern-restricted
>     type, values must match all patterns in the base type, in addition to
>     the new patterns.
>
> /js
>
> On Mon, May 13, 2013 at 12:33:37PM +0200, Benoit Claise wrote:
>> Forwarding to the authors and WG
>>
>> Regards, Benoit
>>> I am guessing that the authors intended the addition of the text
>>> emphasizing that the no-zone typedefs are derived general typedef
>>> addresses the difference in the patterns.
>>>
>>> Is there a YANG rule that says tat if typedef X is derived from
>>> typedef Y then the string for X must match the pattern for X and
>>> the pattern for Y?  If so, then my concern below is misplaced.
>>> (The fact that I find the vague pattern for the child misleading
>>> is not a fault with the document, but rather in my head, under
>>> that requirement.)
>>>
>>> Yours,
>>> Joel
>>>
>>> On 4/19/2013 6:24 PM, Joel M. Halpern wrote:
>>>> I am the assigned Gen-ART reviewer for this draft. For background on
>>>> Gen-ART, please see the FAQ at
>>>>
>>>> .
>>>>
>>>> Please resolve these comments along with any other Last Call comments
>>>> you may receive.
>>>>
>>>> Document: draft-ietf-netmod-rfc6021-bis-01
>>>>      Common YANG Data Types
>>>> Reviewer: Joel M. Halpern
>>>> Review Date: 19-April-2013
>>>> IETF LC End Date: 1-May-2013
>>>> IESG Telechat date: N/A
>>>>
>>>> Summary: This document is nearly ready for publication as a Standards
>>>> Track RFC
>>>>
>>>> Major issues:
>>>>      (The following may well be a non-issue.)
>>>>      In the revision of the ietf-inet-types, the patterns for the new
>>>> ip4-address-no-zone and ipv6-address-no-zone are drastically simplified
>>> >from the ipv4-address and ipv6-address patterns.  The new
>>>> ipv4-address-no-zone allows any sequence of decimal digits an periods,
>>>> while the original was carefully defined as dotted quads of 0..255.
>>>> Similarly, te ipv6-address-no-zone allows any arbitrary sequence of hex
>>>> digits and colons.  The original patterns were very careful to match
>>>> rules for validity.  Is there a reason for the change.
>>>>
>>>> Minor issues:
>>>>
>>>> Nits/editorial comments:
>>>> _______________________________________________
>>>> Gen-art mailing list
>>>> Gen-art@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/gen-art
>>>>
>>>
>>>
>>
>

From ietfc@btconnect.com  Tue May 14 03:49: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 7ECB221F8E9D for ; Tue, 14 May 2013 03:49:11 -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 SwPvcJppHUMH for ; Tue, 14 May 2013 03:49:05 -0700 (PDT)
Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0186.outbound.messaging.microsoft.com [213.199.154.186]) by ietfa.amsl.com (Postfix) with ESMTP id 69C0A21F8E8E for ; Tue, 14 May 2013 03:49:05 -0700 (PDT)
Received: from mail170-db8-R.bigfish.com (10.174.8.242) by DB8EHSOBE012.bigfish.com (10.174.4.75) with Microsoft SMTP Server id 14.1.225.23; Tue, 14 May 2013 10:49:03 +0000
Received: from mail170-db8 (localhost [127.0.0.1])	by mail170-db8-R.bigfish.com (Postfix) with ESMTP id 0C1548C0B98; Tue, 14 May 2013 10:49:03 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.254.181; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0711HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -16
X-BigFish: PS-16(zz98dI9371I542I1432I1418Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275bh8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh304l1d11m1155h)
Received: from mail170-db8 (localhost.localdomain [127.0.0.1]) by mail170-db8 (MessageSwitch) id 1368528540915824_29441; Tue, 14 May 2013 10:49:00 +0000 (UTC)
Received: from DB8EHSMHS013.bigfish.com (unknown [10.174.8.231])	by mail170-db8.bigfish.com (Postfix) with ESMTP id DD3B5B400B6; Tue, 14 May 2013 10:49:00 +0000 (UTC)
Received: from DBXPRD0711HT003.eurprd07.prod.outlook.com (157.56.254.181) by DB8EHSMHS013.bigfish.com (10.174.4.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 14 May 2013 10:48:59 +0000
Received: from DB3PRD0210HT003.eurprd02.prod.outlook.com (157.56.253.69) by pod51017.outlook.com (10.255.178.36) with Microsoft SMTP Server (TLS) id 14.16.305.3; Tue, 14 May 2013 10:48:59 +0000
Message-ID: <006301ce508f$e4f17d60$4001a8c0@gateway.2wire.net>
From: t.petch 
To: , Martin Bjorklund 
References: <9904FB1B0159DA42B0B887B7FA8119CA16A0BF@AZ-FFEXMB04.global.avaya.com><9904FB1B0159DA42B0B887B7FA8119CA16A0F8@AZ-FFEXMB04.global.avaya.com> <20130512.225459.503916152.mbj@tail-f.com>
Date: Tue, 14 May 2013 11:40:40 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.253.69]
X-OriginatorOrg: btconnect.com
Cc: netmod@ietf.org
Subject: Re: [netmod] Last Call:  (A YANG Data Model for Interface Management) to Proposed Standard
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, 14 May 2013 10:49:11 -0000

----- Original Message -----
From: "Martin Bjorklund" 
To: 
Cc: ; ;
; 
Sent: Sunday, May 12, 2013 9:54 PM
> "Romascanu, Dan (Dan)"  wrote:
> >
> > From: Andy Bierman [mailto:andy@yumaworks.com]
> > Sent: Sunday, May 12, 2013 5:01 PM
> > To: Romascanu, Dan (Dan)
> > Cc: Juergen Schoenwaelder; t.petch; Martin Bjorklund;
netmod@ietf.org
> > On Sun, May 12, 2013 at 6:24 AM, Romascanu, Dan (Dan)
> > > wrote:
> > -----Original Message-----
> > > From: Juergen Schoenwaelder
> > > [mailto:j.schoenwaelder@jacobs-
> > > university.de]
> > > Sent: Sunday, May 12, 2013 3:00 PM
> > > To: Romascanu, Dan (Dan)
> > > Cc: Andy Bierman; t.petch; Martin Bjorklund;
> > > netmod@ietf.org
> > > On Sun, May 12, 2013 at 07:18:57AM +0000, Romascanu, Dan (Dan)
wrote:
> > > > Sorry,  I meant:
> > > >
> > > > which one of these two statements is true?
> > > >
> > > >
> > > > (Juergen) My understanding was that on systems that only have
> > > , the  configuration data store is persistent.
> > > >
> > > > (Andy) All NETCONF devices have persistent storage of the
running
> > > configuration.
> > > >
> > >
> > > Both statement can both be true. ;-) The problem is to find the
relevant
> > > pieces of text in the RFCs that talk about persistence since
apparently
> > > this is where some people are confused.
> > >
> > > RFC 6241 says for example:
> > >
> > >    o  configuration datastore: The datastore holding the complete
set of
> > >       configuration data that is required to get a device from its
> > >       initial default state into a desired operational state.
> > >
> > > While this does not say 'persist', one might argue that
persistence is
> > > kind of implied in order to "get a device from its initial default
state
> > > into a desired operational state". And the startup datastore
really is a
> > > special feature:
> > >
> > >    o  startup configuration datastore: The configuration datastore
> > >       holding the configuration loaded by the device when it
boots.
> > >       Only present on devices that separate the startup
configuration
> > >       datastore from the running configuration datastore.
> > >
> > > Even without a startup, your running datastore still persists
since it
> > > is a configuration datastore.
> > >
> > >    o  running configuration datastore: A configuration datastore
holding
> > >       the complete configuration currently active on the device.
The
> > >       running configuration datastore always exists.
> > >
> > > NETCONF was designed to modify configuration data and
configuration data
> > > usually persists (otherwise we would simply talk about writable
> > > operational state, the stuff i2rs people are working on).
> > >
> > > /js
> > >
> >
> > [[DR]] So the practical way to formulate the requirement would be:
> >
> > Any device that supports NETCONF MUST implement the running
configuration
> > datastore in persistent memory.
>
> I would say:
>
>   The startup datastore MUST be persistent.
>
>   If startup is implemented, running MUST NOT be persistent.
>   If startup is not implemented, running MUST be persitent.
>
>   The candidate datastore MUST be persitent.

Martin

Yes, that looks very plausible, but is not what I see in the RFC/I-D:-(

My thoughts were triggered by the comments on persistence, notably that
SNMP and netmod are always going to be different, so I tried to write
down what the differences are, found I knew less than I thought, went
back to RFC/I-D and ended with what I put in my I-D.

It may be obvious to developers what they should implement, but I think
that users need a clearer statement, be it yours, Dan's or whoever's.

Tom Petch





>
> /martin
>



From jernej.tuljak@mg-soft.si  Wed May 15 02:37: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 801E821F85EE for ; Wed, 15 May 2013 02:37:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 nkK61bW26kx6 for ; Wed, 15 May 2013 02:37:54 -0700 (PDT)
Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 126C021F859B for ; Wed, 15 May 2013 02:37:53 -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 r4F9bp1w016287 for ; Wed, 15 May 2013 11:37:51 +0200
Message-ID: <5193576B.8080807@mg-soft.com>
Date: Wed, 15 May 2013 11:37: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: multipart/alternative; boundary="------------090408030908060408020504"
Subject: [netmod] What does unknown-statement2 represent in YANG grammar?
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, 15 May 2013 09:37:58 -0000

This is a multi-part message in MIME format.
--------------090408030908060408020504
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

I'm confused about the unknown-statement2 production in section 12. What 
is the purpose the non-prefixed version of unknown statements in this 
grammar?

This production is never mentioned in the rest of the document directly. 
I think it's supposed to enable usage of standard YANG statements in 
unknown statement (usages of statements defined using extension 
statement) subtrees. But.

7.17. The extension statement

    The substatements of an extension
    are defined by the extension, using some mechanism outside the scope
    of this specification.  Syntactically, the substatements MUST be YANG
    statements, or also defined using "extension" statements.  YANG
    statements in extensions MUST follow the syntactical rules in
    Section 12  .

I don't understand.  If I use a prefix statement inside an unknown 
statement subtree and it doesn't conform to the prefix-stmt rule of the 
grammar, this text makes it valid YANG, since my prefix conforms to 
unknown-statement2 which is also a "syntactical rule in Section 12". It 
is actually the only applicable one.

If the intention was to enable usage of standard YANG statements inside 
subtrees of unknown statements, then this production should contain an 
(alternation)* of all possible standard YANG statements plus 
unknown-statement (or at least a comment about it). I find 
unknown-statement2 redundant. It also unnecessarily complicates 
implementation of lexers/parsers.

BTW, why doesn't the document (RFC6020) use two different words for 
extensions and extension usages? Everything is just an extension which 
at least I find confusing. Consistent usage of ["extension" statement] 
and [extension] would also suffice:

    The "extension" statement allows the definition of new statements
    within the YANG language.  This new statement definition can be
    imported and used by other modules.

    The statement's argument is an identifier that is the new keyword for
    the extension and must be followed by a block of substatements that
    holds detailed extension information.  The purpose of the "extension"
    statement is to define a keyword, so that it can be imported and used
    by other modules.

    The extension can be used like a normal YANG statement, with the
    statement name followed by an argument if one is defined by the
    "extension" statement, and an optional block of substatements.  The statement's
    name is created by combining the prefix of the module in which the
    extension was defined, a colon (":"), and the extension's keyword,
    with no interleaving whitespace.  The substatements of an extension
    are defined by the "extension" statement, using some mechanism outside the scope
    of this specification.  Syntactically, the substatements MUST be YANG
    statements, or also extensions.  YANG statements in extensions MUST follow the
    syntactical rules inSection 12  .

Jernej

--------------090408030908060408020504
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    Hi,

    

    I'm confused about the unknown-statement2 production in section 12.
    What is the purpose the non-prefixed version of unknown statements
    in this grammar? 

    

    This production is never mentioned in the rest of the document
    directly. I think it's supposed to enable usage of standard YANG
    statements in unknown statement (usages of statements defined using
    extension statement) subtrees. But.

    

    7.17. The extension statement

    
   The substatements of an extension
   are defined by the extension, using some mechanism outside the scope
   of this specification.  Syntactically, the substatements MUST be YANG
   statements, or also defined using "extension" statements.  YANG
   statements in extensions MUST follow the syntactical rules in
   Section 12.

    I don't understand.  If I use a prefix statement inside an unknown
    statement subtree and it doesn't conform to the prefix-stmt rule of
    the grammar, this text makes it valid YANG, since my prefix conforms
    to unknown-statement2 which is also a "syntactical rule in Section
    12". It is actually the only applicable one.

    

    If the intention was to enable usage of standard YANG statements
    inside subtrees of unknown statements, then this production should
    contain an (alternation)* of all possible standard YANG statements
    plus unknown-statement (or at least a comment about it). I find
    unknown-statement2 redundant. It also unnecessarily complicates
    implementation of lexers/parsers.

    

    BTW, why doesn't the document (RFC6020) use two different words for
    extensions and extension usages? Everything is just an extension
    which at least I find confusing. Consistent usage of ["extension"
    statement] and [extension] would also suffice:

    
   The "extension" statement allows the definition of new statements
   within the YANG language.  This new statement definition can be
   imported and used by other modules.

   The statement's argument is an identifier that is the new keyword for
   the extension and must be followed by a block of substatements that
   holds detailed extension information.  The purpose of the "extension"
   statement is to define a keyword, so that it can be imported and used
   by other modules.

   The extension can be used like a normal YANG statement, with the
   statement name followed by an argument if one is defined by the
   "extension" statement, and an optional block of substatements.  The statement's
   name is created by combining the prefix of the module in which the
   extension was defined, a colon (":"), and the extension's keyword,
   with no interleaving whitespace.  The substatements of an extension
   are defined by the "extension" statement, using some mechanism outside the scope
   of this specification.  Syntactically, the substatements MUST be YANG
   statements, or also extensions.  YANG statements in extensions MUST follow the 
   syntactical rules in Section 12.


    Jernej

  


--------------090408030908060408020504--

From mbj@tail-f.com  Wed May 15 03:22: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 F078F21F8E56 for ; Wed, 15 May 2013 03:22:41 -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 sT5Le9hTn1nZ for ; Wed, 15 May 2013 03:22: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 5568E21F898A for ; Wed, 15 May 2013 03:22:30 -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 72CF31200AEC; Wed, 15 May 2013 12:22:28 +0200 (CEST)
Date: Wed, 15 May 2013 12:22:28 +0200 (CEST)
Message-Id: <20130515.122228.2163690341458789807.mbj@tail-f.com>
To: jernej.tuljak@mg-soft.si
From: Martin Bjorklund 
In-Reply-To: <5193576B.8080807@mg-soft.com>
References: <5193576B.8080807@mg-soft.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] What does unknown-statement2 represent in YANG grammar?
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, 15 May 2013 10:22:42 -0000

Hi,

Jernej Tuljak  wrote:
> Hi,
> 
> I'm confused about the unknown-statement2 production in section
> 12. What is the purpose the non-prefixed version of unknown statements
> in this grammar?
> 
> This production is never mentioned in the rest of the document
> directly. I think it's supposed to enable usage of standard YANG
> statements in unknown statement (usages of statements defined using
> extension statement) subtrees.

Yes, this is the intention.

> But.
> 
> 7.17. The extension statement
> 
>    The substatements of an extension
>    are defined by the extension, using some mechanism outside the scope
>    of this specification.  Syntactically, the substatements MUST be YANG
>    statements, or also defined using "extension" statements.  YANG
>    statements in extensions MUST follow the syntactical rules in
>    Section 12  .
> 
> I don't understand.  If I use a prefix statement inside an unknown
> statement subtree and it doesn't conform to the prefix-stmt rule of
> the grammar, this text makes it valid YANG, since my prefix conforms
> to unknown-statement2 which is also a "syntactical rule in Section
> 12". It is actually the only applicable one.
> 
> If the intention was to enable usage of standard YANG statements
> inside subtrees of unknown statements, then this production should
> contain an (alternation)* of all possible standard YANG statements
> plus unknown-statement (or at least a comment about it).

Yes, I think an alternation should work (and would be useful).

> I find
> unknown-statement2 redundant. It also unnecessarily complicates
> implementation of lexers/parsers.
> 
> BTW, why doesn't the document (RFC6020) use two different words for
> extensions and extension usages? Everything is just an extension which
> at least I find confusing. Consistent usage of ["extension" statement]
> and [extension] would also suffice:

Sure, it should be consistent.  I don't know where you think it is not
consistent.


/martin


> 
>    The "extension" statement allows the definition of new statements
>    within the YANG language.  This new statement definition can be
>    imported and used by other modules.
> 
>    The statement's argument is an identifier that is the new keyword for
>    the extension and must be followed by a block of substatements that
>    holds detailed extension information.  The purpose of the "extension"
>    statement is to define a keyword, so that it can be imported and used
>    by other modules.
> 
>    The extension can be used like a normal YANG statement, with the
>    statement name followed by an argument if one is defined by the
>    "extension" statement, and an optional block of substatements.  The
>    statement's
>    name is created by combining the prefix of the module in which the
>    extension was defined, a colon (":"), and the extension's keyword,
>    with no interleaving whitespace.  The substatements of an extension
>    are defined by the "extension" statement, using some mechanism outside
>    the scope
>    of this specification.  Syntactically, the substatements MUST be YANG
>    statements, or also extensions.  YANG statements in extensions MUST
>    follow the
>    syntactical rules inSection 12
>    .
> 
> Jernej

From jernej.tuljak@mg-soft.si  Wed May 15 03:31: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 27B8521F8CE9 for ; Wed, 15 May 2013 03:31:38 -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=[AWL=0.001,  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 yL6YFpdYB-WD for ; Wed, 15 May 2013 03:31:34 -0700 (PDT)
Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id D358C21F8CEC for ; Wed, 15 May 2013 03:31:28 -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 r4FAVN2o017378; Wed, 15 May 2013 12:31:23 +0200
Message-ID: <519363F7.7090406@mg-soft.com>
Date: Wed, 15 May 2013 12:31:19 +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: Martin Bjorklund 
References: <5193576B.8080807@mg-soft.com> <20130515.122228.2163690341458789807.mbj@tail-f.com>
In-Reply-To: <20130515.122228.2163690341458789807.mbj@tail-f.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Cc: netmod@ietf.org
Subject: Re: [netmod] What does unknown-statement2 represent in YANG grammar?
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, 15 May 2013 10:31:38 -0000

Dne 15.5.2013 12:22, piše Martin Bjorklund:
> Hi,
>
> Jernej Tuljak  wrote:
>> Hi,
>>
>> I'm confused about the unknown-statement2 production in section
>> 12. What is the purpose the non-prefixed version of unknown statements
>> in this grammar?
>>
>> This production is never mentioned in the rest of the document
>> directly. I think it's supposed to enable usage of standard YANG
>> statements in unknown statement (usages of statements defined using
>> extension statement) subtrees.
> Yes, this is the intention.
>
>> But.
>>
>> 7.17. The extension statement
>>
>>     The substatements of an extension
>>     are defined by the extension, using some mechanism outside the scope
>>     of this specification.  Syntactically, the substatements MUST be YANG
>>     statements, or also defined using "extension" statements.  YANG
>>     statements in extensions MUST follow the syntactical rules in
>>     Section 12  .
>>
>> I don't understand.  If I use a prefix statement inside an unknown
>> statement subtree and it doesn't conform to the prefix-stmt rule of
>> the grammar, this text makes it valid YANG, since my prefix conforms
>> to unknown-statement2 which is also a "syntactical rule in Section
>> 12". It is actually the only applicable one.
>>
>> If the intention was to enable usage of standard YANG statements
>> inside subtrees of unknown statements, then this production should
>> contain an (alternation)* of all possible standard YANG statements
>> plus unknown-statement (or at least a comment about it).
> Yes, I think an alternation should work (and would be useful).
>
>> I find
>> unknown-statement2 redundant. It also unnecessarily complicates
>> implementation of lexers/parsers.
>>
>> BTW, why doesn't the document (RFC6020) use two different words for
>> extensions and extension usages? Everything is just an extension which
>> at least I find confusing. Consistent usage of ["extension" statement]
>> and [extension] would also suffice:
> Sure, it should be consistent.  I don't know where you think it is not
> consistent.
>
>
> /martin
>
>
>>     The "extension" statement allows the definition of new statements
>>     within the YANG language.  This new statement definition can be
>>     imported and used by other modules.
>>
>>     The statement's argument is an identifier that is the new keyword for
>>     the extension and must be followed by a block of substatements that
>>     holds detailed extension information.  The purpose of the "extension"
>>     statement is to define a keyword, so that it can be imported and used
>>     by other modules.
>>
>>     The extension can be used like a normal YANG statement, with the
>>     statement name followed by an argument if one is defined by the
>>     "extension" statement, and an optional block of substatements.  The
>>     statement's
>>     name is created by combining the prefix of the module in which the
>>     extension was defined, a colon (":"), and the extension's keyword,
>>     with no interleaving whitespace.  The substatements of an extension
>>     are defined by the "extension" statement, using some mechanism outside
>>     the scope
>>     of this specification.  Syntactically, the substatements MUST be YANG
>>     statements, or also extensions.  YANG statements in extensions MUST
>>     follow the
>>     syntactical rules inSection 12
>>     .

This text contains fixes where I think inconsistencies exist. All of 
them are in the third paragraph (first, third and fourth sentence).

Jernej

>>
>> Jernej


From internet-drafts@ietf.org  Wed May 15 07:03: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 E3C9C21F905B; Wed, 15 May 2013 07:03:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.474
X-Spam-Level: 
X-Spam-Status: No, score=-102.474 tagged_above=-999 required=5 tests=[AWL=0.126, 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 CdFDWyCgcZGX; Wed, 15 May 2013 07:03:53 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F60921F8FE9; Wed, 15 May 2013 07:03:53 -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.45
Message-ID: <20130515140353.15940.12042.idtracker@ietfa.amsl.com>
Date: Wed, 15 May 2013 07:03:53 -0700
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-interfaces-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: Wed, 15 May 2013 14:03:54 -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 Interface Management
	Author(s)       : Martin Bjorklund
	Filename        : draft-ietf-netmod-interfaces-cfg-11.txt
	Pages           : 44
	Date            : 2013-05-15

Abstract:
   This document defines a YANG data model for the management of network
   interfaces.  It is expected that interface type specific data models
   augment the generic interfaces data model defined in this document.
   The data model includes configuration data, state data and counters
   for the collection of statistics.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-interfaces-cfg

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-11

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-interfaces-cfg-11


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


From mbj@tail-f.com  Wed May 15 07:05: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 428D821F8616 for ; Wed, 15 May 2013 07:05:18 -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 4r5xZwOeHWdc for ; Wed, 15 May 2013 07:05:13 -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 862EB21F84B1 for ; Wed, 15 May 2013 07:05:13 -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 3C9CB1200D2F for ; Wed, 15 May 2013 16:05:12 +0200 (CEST)
Date: Wed, 15 May 2013 16:05:12 +0200 (CEST)
Message-Id: <20130515.160512.1630408467051717643.mbj@tail-f.com>
To: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <20130515140353.15940.12042.idtracker@ietfa.amsl.com>
References: <20130515140353.15940.12042.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
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-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: Wed, 15 May 2013 14:05:18 -0000

Hi,

During the IETF LC, we got quite a few comments on document
draft-ietf-netmod-interfaces-cfg-10.

See for example the threads

http://www.ietf.org/mail-archive/web/ietf/current/msg78801.html
(my reply:
http://www.ietf.org/mail-archive/web/ietf/current/msg78945.html)

and

http://www.ietf.org/mail-archive/web/netmod/current/msg08035.html


Benoit also has similar comments in his AD review (see
http://www.ietf.org/mail-archive/web/netmod/current/msg07863.html)

After discussing these issues with Benoit, David, Juergen and Lada, we
suggest a couple of changes to address the issues:

  o  Separate the operational state from the configuration.

  o  Remove 'location', and instead use the name to identify physical
     interfaces.

There were also some other clarifications and minor changes.

The new version (draft-ietf-netmod-interfaces-cfg-11) addresses these
issues.  Please review and comment!


/martin


From andy@yumaworks.com  Wed May 15 07:12:02 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 F24BE21F8653 for ; Wed, 15 May 2013 07:12:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.782
X-Spam-Level: 
X-Spam-Status: No, score=-0.782 tagged_above=-999 required=5 tests=[AWL=-0.471, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666]
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 dCTV7F5pz0CK for ; Wed, 15 May 2013 07:12:01 -0700 (PDT)
Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id ADBB621F85ED for ; Wed, 15 May 2013 07:12:00 -0700 (PDT)
Received: by mail-ie0-f182.google.com with SMTP id a14so3810040iee.27 for ; Wed, 15 May 2013 07:12:00 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=uaD4mNluzraJt64JzxBbGj+zQGygJDZR5LczVbwn3AE=; b=Vlfaen4RDubn8O3VjX1s0ZSZTtB71vCIRQY5JidufmQcFqfqqLOai74odRDOvRlwDN GNR3fHqYy2pOir6dOAS8vCyxlfljRsj8/rziD6IWDz8UgcHJWGQTvD5BJZI01CBHOaty 1fvNSA9mgazbKvyU9lToF8lxnpONNQAIe48oSsaSFyMTYLZr7XDSeCFGUizCyGVb+2O+ O8k5pvsZ8UHuoi5P28uL/ScD651csFCW0BM0KSkwcotnLrfBgqL6zTfmnAvtlpW+einS lN1Jtbst4x2qjdetKoduHEyx4ZrR4tkydrVohVXgVsHYj9UzAiElEZPWk7yVmyMrf8eU 2qvg==
MIME-Version: 1.0
X-Received: by 10.50.102.67 with SMTP id fm3mr5776837igb.5.1368627120253; Wed, 15 May 2013 07:12:00 -0700 (PDT)
Received: by 10.231.206.71 with HTTP; Wed, 15 May 2013 07:12:00 -0700 (PDT)
In-Reply-To: <519363F7.7090406@mg-soft.com>
References: <5193576B.8080807@mg-soft.com> <20130515.122228.2163690341458789807.mbj@tail-f.com> <519363F7.7090406@mg-soft.com>
Date: Wed, 15 May 2013 07:12:00 -0700
Message-ID: 
From: Andy Bierman 
To: Jernej Tuljak 
Content-Type: multipart/alternative; boundary=047d7b10ca13553f2104dcc255ff
X-Gm-Message-State: ALoCoQmheoo7Jci655LG4KHu5R57AOTrVLYEvnJwNcg7HV+mPm1cjV26xduD+M/aReppgP9qn6c+
Cc: netmod@ietf.org
Subject: Re: [netmod] What does unknown-statement2 represent in YANG grammar?
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, 15 May 2013 14:12:02 -0000

--047d7b10ca13553f2104dcc255ff
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, May 15, 2013 at 3:31 AM, Jernej Tuljak wr=
ote:

> Dne 15.5.2013 12:22, pi=C5=A1e Martin Bjorklund:
>
>> Hi,
>>
>> Jernej Tuljak  wrote:
>>
>>> Hi,
>>>
>>> I'm confused about the unknown-statement2 production in section
>>> 12. What is the purpose the non-prefixed version of unknown statements
>>> in this grammar?
>>>
>>> This production is never mentioned in the rest of the document
>>> directly. I think it's supposed to enable usage of standard YANG
>>> statements in unknown statement (usages of statements defined using
>>> extension statement) subtrees.
>>>
>> Yes, this is the intention.
>>
>

This is a CLR and has unintended consequences.
By definition, an external statement is outside the
YANG language.  Compilers are only required to
properly skip over them.

E.g., if a leaf-stmt is embedded in an external statement,
then it is not a YANG leaf definition.  It is not required
to have a 'type' sub-statement present.  It is not required
to parse and validate to a unique and valid leaf definition.
Only leaf-stmts within the YANG language have these requirements.



Andy



>
>>  But.
>>>
>>> 7.17. The extension statement
>>>
>>>     The substatements of an extension
>>>     are defined by the extension, using some mechanism outside the scop=
e
>>>     of this specification.  Syntactically, the substatements MUST be YA=
NG
>>>     statements, or also defined using "extension" statements.  YANG
>>>     statements in extensions MUST follow the syntactical rules in
>>>     Section 12  
>>> >.
>>>
>>> I don't understand.  If I use a prefix statement inside an unknown
>>> statement subtree and it doesn't conform to the prefix-stmt rule of
>>> the grammar, this text makes it valid YANG, since my prefix conforms
>>> to unknown-statement2 which is also a "syntactical rule in Section
>>> 12". It is actually the only applicable one.
>>>
>>> If the intention was to enable usage of standard YANG statements
>>> inside subtrees of unknown statements, then this production should
>>> contain an (alternation)* of all possible standard YANG statements
>>> plus unknown-statement (or at least a comment about it).
>>>
>> Yes, I think an alternation should work (and would be useful).
>>
>>  I find
>>> unknown-statement2 redundant. It also unnecessarily complicates
>>> implementation of lexers/parsers.
>>>
>>> BTW, why doesn't the document (RFC6020) use two different words for
>>> extensions and extension usages? Everything is just an extension which
>>> at least I find confusing. Consistent usage of ["extension" statement]
>>> and [extension] would also suffice:
>>>
>> Sure, it should be consistent.  I don't know where you think it is not
>> consistent.
>>
>>
>> /martin
>>
>>
>>      The "extension" statement allows the definition of new statements
>>>     within the YANG language.  This new statement definition can be
>>>     imported and used by other modules.
>>>
>>>     The statement's argument is an identifier that is the new keyword f=
or
>>>     the extension and must be followed by a block of substatements that
>>>     holds detailed extension information.  The purpose of the "extensio=
n"
>>>     statement is to define a keyword, so that it can be imported and us=
ed
>>>     by other modules.
>>>
>>>     The extension can be used like a normal YANG statement, with the
>>>     statement name followed by an argument if one is defined by the
>>>     "extension" statement, and an optional block of substatements.  The
>>>     statement's
>>>     name is created by combining the prefix of the module in which the
>>>     extension was defined, a colon (":"), and the extension's keyword,
>>>     with no interleaving whitespace.  The substatements of an extension
>>>     are defined by the "extension" statement, using some mechanism
>>> outside
>>>     the scope
>>>     of this specification.  Syntactically, the substatements MUST be YA=
NG
>>>     statements, or also extensions.  YANG statements in extensions MUST
>>>     follow the
>>>     syntactical rules inSection 12
>>>     
>>> >.
>>>
>>
> This text contains fixes where I think inconsistencies exist. All of them
> are in the third paragraph (first, third and fourth sentence).
>
> Jernej
>
>
>>> Jernej
>>>
>>
> ______________________________**_________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/**listinfo/netmod
>

--047d7b10ca13553f2104dcc255ff
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Wed, May 15, 2013 at 3:31 AM, Jernej =
Tuljak <jernej.tuljak@mg-soft.si> wrote:

Dne 15.5.2013 12:22, pi=C5=A1e Martin Bjorklund:



Hi,



Jernej Tuljak <jernej.tuljak@mg-soft.si> wrote:



Hi,



I'm confused about the unknown-statement2 production in section

12. What is the purpose the non-prefixed version of unknown statements

in this grammar?



This production is never mentioned in the rest of the document

directly. I think it's supposed to enable usage of standard YANG

statements in unknown statement (usages of statements defined using

extension statement) subtrees.



Yes, this is the intention.


This is a CLR and has unintended consequences.
B=
y definition, an external statement is outside the
YANG language.=
 =C2=A0Compilers are only required to


properly skip over them.

E.g., if a leaf-stmt=
 is embedded in an external statement,
then it is not a YANG leaf=
 definition. =C2=A0It is not required
to have a 'type' su=
b-statement present. =C2=A0It is not required


to parse and validate to a unique and valid leaf definition.
Only leaf-stmts within the YANG language have these requirements.


Andy



=C2=A0





But.



7.17. The extension statement



=C2=A0 =C2=A0 The substatements of an extension

=C2=A0 =C2=A0 are defined by the extension, using some mechanism outside th=
e scope

=C2=A0 =C2=A0 of this specification. =C2=A0Syntactically, the substatements=
 MUST be YANG

=C2=A0 =C2=A0 statements, or also defined using "extension" state=
ments. =C2=A0YANG

=C2=A0 =C2=A0 statements in extensions MUST follow the syntactical rules in=


=C2=A0 =C2=A0 Section 12 =C2=A0<https://tools.ietf.org/html/rfc=
6020#section-12>.



I don't understand. =C2=A0If I use a prefix statement inside an unknown=


statement subtree and it doesn't conform to the prefix-stmt rule of

the grammar, this text makes it valid YANG, since my prefix conforms

to unknown-statement2 which is also a "syntactical rule in Section

12". It is actually the only applicable one.



If the intention was to enable usage of standard YANG statements

inside subtrees of unknown statements, then this production should

contain an (alternation)* of all possible standard YANG statements

plus unknown-statement (or at least a comment about it).



Yes, I think an alternation should work (and would be useful).





I find

unknown-statement2 redundant. It also unnecessarily complicates

implementation of lexers/parsers.



BTW, why doesn't the document (RFC6020) use two different words for

extensions and extension usages? Everything is just an extension which

at least I find confusing. Consistent usage of ["extension" state=
ment]

and [extension] would also suffice:



Sure, it should be consistent. =C2=A0I don't know where you think it is=
 not

consistent.





/martin







=C2=A0 =C2=A0 The "extension" statement allows the definition of =
new statements

=C2=A0 =C2=A0 within the YANG language. =C2=A0This new statement definition=
 can be

=C2=A0 =C2=A0 imported and used by other modules.



=C2=A0 =C2=A0 The statement's argument is an identifier that is the new=
 keyword for

=C2=A0 =C2=A0 the extension and must be followed by a block of substatement=
s that

=C2=A0 =C2=A0 holds detailed extension information. =C2=A0The purpose of th=
e "extension"

=C2=A0 =C2=A0 statement is to define a keyword, so that it can be imported =
and used

=C2=A0 =C2=A0 by other modules.



=C2=A0 =C2=A0 The extension can be used like a normal YANG statement, with =
the

=C2=A0 =C2=A0 statement name followed by an argument if one is defined by t=
he

=C2=A0 =C2=A0 "extension" statement, and an optional block of sub=
statements. =C2=A0The

=C2=A0 =C2=A0 statement's

=C2=A0 =C2=A0 name is created by combining the prefix of the module in whic=
h the

=C2=A0 =C2=A0 extension was defined, a colon (":"), and the exten=
sion's keyword,

=C2=A0 =C2=A0 with no interleaving whitespace. =C2=A0The substatements of a=
n extension

=C2=A0 =C2=A0 are defined by the "extension" statement, using som=
e mechanism outside

=C2=A0 =C2=A0 the scope

=C2=A0 =C2=A0 of this specification. =C2=A0Syntactically, the substatements=
 MUST be YANG

=C2=A0 =C2=A0 statements, or also extensions. =C2=A0YANG statements in exte=
nsions MUST

=C2=A0 =C2=A0 follow the

=C2=A0 =C2=A0 syntactical rules inSection 12

=C2=A0 =C2=A0 <https://tools.ietf.org/html/rfc6020#section-12>.





This text contains fixes where I think inconsistencies exist. All of them a=
re in the third paragraph (first, third and fourth sentence).



Jernej







Jernej





_______________________________________________

netmod mailing list

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





--047d7b10ca13553f2104dcc255ff--

From mbj@tail-f.com  Wed May 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 9658921F8F4F for ; Wed, 15 May 2013 07:22:14 -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 AvUXGnWximLX for ; Wed, 15 May 2013 07:22: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 8C45121F871D for ; Wed, 15 May 2013 07:22:04 -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 CB28F1200A35; Wed, 15 May 2013 16:22:02 +0200 (CEST)
Date: Wed, 15 May 2013 16:22:02 +0200 (CEST)
Message-Id: <20130515.162202.311372082160778868.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund 
In-Reply-To: 
References: <20130515.122228.2163690341458789807.mbj@tail-f.com> <519363F7.7090406@mg-soft.com> 
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-15
Content-Transfer-Encoding: quoted-printable
Cc: netmod@ietf.org
Subject: Re: [netmod] What does unknown-statement2 represent in YANG grammar?
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, 15 May 2013 14:22:14 -0000

Andy Bierman  wrote:
> On Wed, May 15, 2013 at 3:31 AM, Jernej Tuljak wrote:
> =

> > Dne 15.5.2013 12:22, pi=A8e Martin Bjorklund:
> >
> >> Hi,
> >>
> >> Jernej Tuljak  wrote:
> >>
> >>> Hi,
> >>>
> >>> I'm confused about the unknown-statement2 production in section
> >>> 12. What is the purpose the non-prefixed version of unknown state=
ments
> >>> in this grammar?
> >>>
> >>> This production is never mentioned in the rest of the document
> >>> directly. I think it's supposed to enable usage of standard YANG
> >>> statements in unknown statement (usages of statements defined usi=
ng
> >>> extension statement) subtrees.
> >>>
> >> Yes, this is the intention.
> >>
> >
> =

> This is a CLR and has unintended consequences.
> By definition, an external statement is outside the
> YANG language.  Compilers are only required to
> properly skip over them.

All extension must be properly defined.

> E.g., if a leaf-stmt is embedded in an external statement,
> then it is not a YANG leaf definition.

Yes it is.

> It is not required
> to have a 'type' sub-statement present.

Yes it is required to have 'type'.

The idea is that you are free to use core YANG statements if and only
if they have the exact same syntax as normal.  If you want to have
different syntax in your 'leaf' statement you would have to define an
extension for it.


/martin

From j.schoenwaelder@jacobs-university.de  Wed May 15 07:25:49 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 CE3AD21F8ED8 for ; Wed, 15 May 2013 07:25:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.249
X-Spam-Level: 
X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2x70cA784+2D for ; Wed, 15 May 2013 07:25:45 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 277A721F8EC1 for ; Wed, 15 May 2013 07:25:44 -0700 (PDT)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 69DD220BED; Wed, 15 May 2013 16:25:42 +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 w-7ppB7R0lDC; Wed, 15 May 2013 16:25:42 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 08B3A20BE0; Wed, 15 May 2013 16:25:42 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id EC185264C392; Wed, 15 May 2013 16:25:40 +0200 (CEST)
Date: Wed, 15 May 2013 16:25:40 +0200
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20130515142540.GB23909@elstar.local>
Mail-Followup-To: netmod@ietf.org
References: <20130515140353.15940.12042.idtracker@ietfa.amsl.com> <20130515.160512.1630408467051717643.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20130515.160512.1630408467051717643.mbj@tail-f.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-11.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: Wed, 15 May 2013 14:25:50 -0000

Hi,

let me add some further context to this in order to address any
procedural questions you might have. While discussing the comments
received during the IETF last call, it became clear that we need to
make changes to the document that go beyond what can reasonably be
done during the IESG processing phase. So we (the chairs) consulted
with Benoit and decided to move this document back into the working
group. Martin has (with the help of others) worked the last few days
on a proposal how we might be able to address the questions that were
raised and this is now in -11. The working group should review this
proposal and raise any questions or concerns. Procedurally, we will
run another WG last call on this document (or a subsequent revision of
it) and then this document goes again to Benoit and we will see
another IETF last call as well.

One of the key changes is that -11 makes a clear separation between
configuration data and operational state data. It does so by creating
two branches, namely /interfaces and /interfaces-state. By having a
clear separation (essentially two interface lists - one for
configuration data and one for operational data), we are able to more
clearly explain how things interact also with other management
interfaces such as SNMP MIBs.

We like to receive feedback about this approach since we have similar
issues with other data models, in particular the IP data model, which
essentially extends the interface list(s). With the two branches, we
can finally distinguish IP addresses configured on an interface from
IP addresses operationally used by an interface.

/js

On Wed, May 15, 2013 at 04:05:12PM +0200, Martin Bjorklund wrote:
> Hi,
> 
> During the IETF LC, we got quite a few comments on document
> draft-ietf-netmod-interfaces-cfg-10.
> 
> See for example the threads
> 
> http://www.ietf.org/mail-archive/web/ietf/current/msg78801.html
> (my reply:
> http://www.ietf.org/mail-archive/web/ietf/current/msg78945.html)
> 
> and
> 
> http://www.ietf.org/mail-archive/web/netmod/current/msg08035.html
> 
> 
> Benoit also has similar comments in his AD review (see
> http://www.ietf.org/mail-archive/web/netmod/current/msg07863.html)
> 
> After discussing these issues with Benoit, David, Juergen and Lada, we
> suggest a couple of changes to address the issues:
> 
>   o  Separate the operational state from the configuration.
> 
>   o  Remove 'location', and instead use the name to identify physical
>      interfaces.
> 
> There were also some other clarifications and minor changes.
> 
> The new version (draft-ietf-netmod-interfaces-cfg-11) addresses these
> issues.  Please review and comment!
> 
> 
> /martin
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
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  Wed May 15 07:55: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 D689D21F86C1 for ; Wed, 15 May 2013 07:55:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.52
X-Spam-Level: 
X-Spam-Status: No, score=-1.52 tagged_above=-999 required=5 tests=[AWL=0.457,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FQZ-LZzB8DE for ; Wed, 15 May 2013 07:55:56 -0700 (PDT)
Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD8311E80A4 for ; Wed, 15 May 2013 07:55:52 -0700 (PDT)
Received: by mail-ie0-f174.google.com with SMTP id 10so3773654ied.5 for ; Wed, 15 May 2013 07:55:52 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=PaWc80UPVadTdJLE0Kx2/E2ich5D54qp5PAMzw3AfIo=; b=OvQSCaeQglS+lINvTcRdVTUMah6h0fdMu2dn3b3eEHpDqxahjs8SBIAKMGSu5RRrId RmzHjrTAKPBF7h513xqNobRXBWqZYC7NzmMQLnGJaVbpnpXEX5ruQrTirbLBKi6o9twE jkpDd2Qj23M0FH3WjzZBLDqw5768W/QaFRTvQkJYkL/j5IuEGeb+vUhbmbwIS6kWqq85 1i+7LK6OfFXchQyI8inPiN47YStt+fZ45v/row+qSYqU9cuQZ7xrkX++no1bf6kJNIi8 XP+lhwdBrIttNlYW2H2ZczCoydpY9Cs3v4fI3UBMTJ9UA00GcAKIMqY1wklNl2OsvEOA habg==
MIME-Version: 1.0
X-Received: by 10.50.27.37 with SMTP id q5mr5533595igg.52.1368629752529; Wed, 15 May 2013 07:55:52 -0700 (PDT)
Received: by 10.231.206.71 with HTTP; Wed, 15 May 2013 07:55:52 -0700 (PDT)
In-Reply-To: <20130515.162202.311372082160778868.mbj@tail-f.com>
References: <20130515.122228.2163690341458789807.mbj@tail-f.com> <519363F7.7090406@mg-soft.com>  <20130515.162202.311372082160778868.mbj@tail-f.com>
Date: Wed, 15 May 2013 07:55:52 -0700
Message-ID: 
From: Andy Bierman 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=047d7b10c8373a979204dcc2f219
X-Gm-Message-State: ALoCoQlmcwNhjFPL7l6aQsTsKjo4islH0vG3MYTD7dwOnP6zr0jpyzhd3HttQkjEPEWPqYpcRCE0
Cc: netmod@ietf.org
Subject: Re: [netmod] What does unknown-statement2 represent in YANG grammar?
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, 15 May 2013 14:55:57 -0000

--047d7b10c8373a979204dcc2f219
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, May 15, 2013 at 7:22 AM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
> > On Wed, May 15, 2013 at 3:31 AM, Jernej Tuljak  >wrote:
> >
> > > Dne 15.5.2013 12:22, pi=C5=A1e Martin Bjorklund:
> > >
> > >> Hi,
> > >>
> > >> Jernej Tuljak  wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> I'm confused about the unknown-statement2 production in section
> > >>> 12. What is the purpose the non-prefixed version of unknown
> statements
> > >>> in this grammar?
> > >>>
> > >>> This production is never mentioned in the rest of the document
> > >>> directly. I think it's supposed to enable usage of standard YANG
> > >>> statements in unknown statement (usages of statements defined using
> > >>> extension statement) subtrees.
> > >>>
> > >> Yes, this is the intention.
> > >>
> > >
> >
> > This is a CLR and has unintended consequences.
> > By definition, an external statement is outside the
> > YANG language.  Compilers are only required to
> > properly skip over them.
>
> All extension must be properly defined.
>
>
RFC 6020, sec 6.3.1, para 3:

   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.


IMO, the ABNF production in section 12 is correct because of this paragraph=
.
The ABNF and meaning of the word "ignored" are clear.  A compiler MAY
skip over extensions it does not support.  This simply requires finding
the end of a well-structured YANG statement, as defined in sec 6.3:

 statement =3D keyword [argument] (";" / "{" *statement "}")


Andy






> > E.g., if a leaf-stmt is embedded in an external statement,
> > then it is not a YANG leaf definition.
>
> Yes it is.
>
> > It is not required
> > to have a 'type' sub-statement present.
>
> Yes it is required to have 'type'.
>
> The idea is that you are free to use core YANG statements if and only
> if they have the exact same syntax as normal.  If you want to have
> different syntax in your 'leaf' statement you would have to define an
> extension for it.
>
>
> /martin
>

--047d7b10c8373a979204dcc2f219
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



On Wed, May 15, 2013 at 7:22 AM, Martin =
Bjorklund <mbj@tail-f.com> wrote:

Andy Bierman <andy@yumaworks.com> wrote:

> On Wed, May 15, 2013 at 3:31 AM, Jernej Tuljak <jernej.tuljak@mg-soft.si>wrote:

>

> > Dne 15.5.2013 12:22, pi=B9e Martin Bjorklund:

> >

> >> Hi,

> >>

> >> Jernej Tuljak <jernej.tuljak@mg-soft.si> wrote:

> >>

> >>> Hi,

> >>>

> >>> I'm confused about the unknown-statement2 production =
in section

> >>> 12. What is the purpose the non-prefixed version of unkno=
wn statements

> >>> in this grammar?

> >>>

> >>> This production is never mentioned in the rest of the doc=
ument

> >>> directly. I think it's supposed to enable usage of st=
andard YANG

> >>> statements in unknown statement (usages of statements def=
ined using

> >>> extension statement) subtrees.

> >>>

> >> Yes, this is the intention.

> >>

> >

>

> This is a CLR and has unintended consequences.

> By definition, an external statement is outside the

> YANG language. =A0Compilers are only required to

> properly skip over them.



All extension must be properly defined.



RFC 6020, sec 6.3.1, para 3:

   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.


IMO, the ABNF production in section 12 is correct=
 because of this paragraph.
The ABNF and meaning of the word &quo=
t;ignored" are clear. =A0A compiler MAY
skip over extensions=
 it does not support. =A0This simply requires finding


the end of a well-structured YANG statement, as defined in sec 6.3:

 statement =3D keyword [argument] (";" / "{" *stat=
ement "}")


Andy




=A0

> E.g., if a leaf-stmt is embedded in an external statement,

> then it is not a YANG leaf definition.



Yes it is.



> It is not required

> to have a 'type' sub-statement present.



Yes it is required to have 'type'.



The idea is that you are free to use core YANG statements if and only

if they have the exact same syntax as normal. =A0If you want to have

different syntax in your 'leaf' statement you would have to define =
an

extension for it.





/martin





--047d7b10c8373a979204dcc2f219--

From lhotka@nic.cz  Wed May 15 08:21: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 E523721F9021 for ; Wed, 15 May 2013 08:21:41 -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 3vhWxo7GC-YO for ; Wed, 15 May 2013 08:21: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 1897B21F8FF2 for ; Wed, 15 May 2013 08:21:41 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 3DBCD13FACF; Wed, 15 May 2013 17:21:40 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1368631300; bh=3vwB/pKxUgIe4CRMd5ttWtzBYyjaU/9M2eBI+pQfGoE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=XIx0dvO7MbfX9T0pCXJS+6YVHX9HlW53v/cG3pG7mXhm8Bh4A6Q2GFHDMwByALW7M Q9tnJBtR8NL813nDOeBwSwQYvwtjS9/Klcpwbntv9kDOSaRa6EcmiIwdD5kCiWDc8Z 37LT1Vp4sSn88ilbewKX9p+Hm7dxxMxd4RzhxqhU=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: <20130515.162202.311372082160778868.mbj@tail-f.com>
Date: Wed, 15 May 2013 17:21:39 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20130515.122228.2163690341458789807.mbj@tail-f.com> <519363F7.7090406@mg-soft.com>  <20130515.162202.311372082160778868.mbj@tail-f.com>
To: Martin Bjorklund 
X-Mailer: Apple Mail (2.1503)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] What does unknown-statement2 represent in YANG grammar?
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, 15 May 2013 15:21:42 -0000

On May 15, 2013, at 4:22 PM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
>> On Wed, May 15, 2013 at 3:31 AM, Jernej Tuljak =
wrote:
>>=20
>>> Dne 15.5.2013 12:22, pi=9Ae Martin Bjorklund:
>>>=20
>>>> Hi,
>>>>=20
>>>> Jernej Tuljak  wrote:
>>>>=20
>>>>> Hi,
>>>>>=20
>>>>> I'm confused about the unknown-statement2 production in section
>>>>> 12. What is the purpose the non-prefixed version of unknown =
statements
>>>>> in this grammar?
>>>>>=20
>>>>> This production is never mentioned in the rest of the document
>>>>> directly. I think it's supposed to enable usage of standard YANG
>>>>> statements in unknown statement (usages of statements defined =
using
>>>>> extension statement) subtrees.
>>>>>=20
>>>> Yes, this is the intention.
>>>>=20
>>>=20
>>=20
>> This is a CLR and has unintended consequences.
>> By definition, an external statement is outside the
>> YANG language.  Compilers are only required to
>> properly skip over them.
>=20
> All extension must be properly defined.

Hmm=85 An extension extends the YANG language, so if it was to be =
properly defined, such a definition should be placed in the ABNF. The =
"extension" statement only serves documentation purposes, and also YIN =
translation - but the latter could be easily done without it, using =
simply the same attribute name for all extension arguments, e.g. "arg".

Lada

>=20
>> E.g., if a leaf-stmt is embedded in an external statement,
>> then it is not a YANG leaf definition.
>=20
> Yes it is.
>=20
>> It is not required
>> to have a 'type' sub-statement present.
>=20
> Yes it is required to have 'type'.
>=20
> The idea is that you are free to use core YANG statements if and only
> if they have the exact same syntax as normal.  If you want to have
> different syntax in your 'leaf' statement you would have to define an
> extension for it.
>=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  Wed May 15 08:39: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 6DB4A1F0D2D for ; Wed, 15 May 2013 08:39:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.597
X-Spam-Level: 
X-Spam-Status: No, score=-1.597 tagged_above=-999 required=5 tests=[AWL=0.380,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXynGAg+7yLQ for ; Wed, 15 May 2013 08:39:24 -0700 (PDT)
Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id C528621F8ED3 for ; Wed, 15 May 2013 08:39:23 -0700 (PDT)
Received: by mail-ie0-f181.google.com with SMTP id x12so3943818ief.40 for ; Wed, 15 May 2013 08:39:18 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=w1ldX0aXFo4hKnVQkvq1vNuD+JTxQxwQmfEWaarWAPM=; b=UedvQTA4gX/Afz/ptcdAOaEJbX+EaZrjGpDSEkuW4pnfbDK3GCkbgcB/2uJqAD/REU qgiY7HCJ3ozldJCgKchb9i4wRnXpgEVKrrOTNWXOylqDFwmC4TjKkOPpr16hHPfgO4P3 l3ww2tUfiNwXLGpWHiadmnMNSsmBmzMbI4tx3KG/VMRnoXFlIpDx0LSDZetSk1ks12/1 v46KAqAutagDfKs3bXvW8Ywq+48pBiw9NY4Iu40YnVsSThTrDJgPquVwToHCrSzgPuQr cKrDVUKUJhmF3SgVosnQKdaa5tHDi5PgSc+mHU37uT422iLjmLxJbgo+ihZvvBc2lnoZ 8qyQ==
MIME-Version: 1.0
X-Received: by 10.50.126.1 with SMTP id mu1mr6076303igb.5.1368632358233; Wed, 15 May 2013 08:39:18 -0700 (PDT)
Received: by 10.231.206.71 with HTTP; Wed, 15 May 2013 08:39:18 -0700 (PDT)
In-Reply-To: 
References: <20130515.122228.2163690341458789807.mbj@tail-f.com> <519363F7.7090406@mg-soft.com>  <20130515.162202.311372082160778868.mbj@tail-f.com> 
Date: Wed, 15 May 2013 08:39:18 -0700
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=047d7b1637b78a79f904dcc38da8
X-Gm-Message-State: ALoCoQnWdNldBl/uj+spIs0EHlxy/B+vMH23+GGfPeD1t1i/5Fp9VRQMUtTQ/my5CrgPrkshRO5B
Cc: netmod@ietf.org
Subject: Re: [netmod] What does unknown-statement2 represent in YANG grammar?
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, 15 May 2013 15:39:25 -0000

--047d7b1637b78a79f904dcc38da8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, May 15, 2013 at 8:21 AM, Ladislav Lhotka  wrote:

>
> On May 15, 2013, at 4:22 PM, Martin Bjorklund  wrote:
>
> > Andy Bierman  wrote:
> >> On Wed, May 15, 2013 at 3:31 AM, Jernej Tuljak <
> jernej.tuljak@mg-soft.si>wrote:
> >>
> >>> Dne 15.5.2013 12:22, pi=C5=A1e Martin Bjorklund:
> >>>
> >>>> Hi,
> >>>>
> >>>> Jernej Tuljak  wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> I'm confused about the unknown-statement2 production in section
> >>>>> 12. What is the purpose the non-prefixed version of unknown
> statements
> >>>>> in this grammar?
> >>>>>
> >>>>> This production is never mentioned in the rest of the document
> >>>>> directly. I think it's supposed to enable usage of standard YANG
> >>>>> statements in unknown statement (usages of statements defined using
> >>>>> extension statement) subtrees.
> >>>>>
> >>>> Yes, this is the intention.
> >>>>
> >>>
> >>
> >> This is a CLR and has unintended consequences.
> >> By definition, an external statement is outside the
> >> YANG language.  Compilers are only required to
> >> properly skip over them.
> >
> > All extension must be properly defined.
>
> Hmm=E2=80=A6 An extension extends the YANG language, so if it was to be p=
roperly
> defined, such a definition should be placed in the ABNF. The "extension"
> statement only serves documentation purposes, and also YIN translation -
> but the latter could be easily done without it, using simply the same
> attribute name for all extension arguments, e.g. "arg".
>
>
The extension (unknown) statement is in the ABNF.
It is correctly defined.  The text "MAY be ignored..."
was put in the RFC for a reason.  A compliant implementation
is allowed to ignore the entire external statement.   By "ignore"
I mean treat it as a comment -- it has no semantic meaning to
the compiler at all and therefore no knowledge of the sub-statements
that are even allowed within the external statement.

The 'arg' sub-statement is the "argment" part of the ABNF,
not the nested sub-statements.

 statement =3D keyword [argument] (";" / "{" *statement "}")


Lada
>
>
Andy

--047d7b1637b78a79f904dcc38da8
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



On Wed, May 15, 2013 at 8:21 AM, Ladisla=
v Lhotka <lhotka@nic.cz> wrote:
mbj@tail-f.com> wrote:



> Andy Bierman <andy@yumaworks.=
com> wrote:

>> On Wed, May 15, 2013 at 3:31 AM, Jernej Tuljak <jernej.tuljak@mg-soft.si>wrote:

>>

>>> Dne 15.5.2013 12:22, pi=B9e Martin Bjorklund:

>>>

>>>> Hi,

>>>>

>>>> Jernej Tuljak <jernej.tuljak@mg-soft.si> wrote:

>>>>

>>>>> Hi,

>>>>>

>>>>> I'm confused about the unknown-statement2 producti=
on in section

>>>>> 12. What is the purpose the non-prefixed version of un=
known statements

>>>>> in this grammar?

>>>>>

>>>>> This production is never mentioned in the rest of the =
document

>>>>> directly. I think it's supposed to enable usage of=
 standard YANG

>>>>> statements in unknown statement (usages of statements =
defined using

>>>>> extension statement) subtrees.

>>>>>

>>>> Yes, this is the intention.

>>>>

>>>

>>

>> This is a CLR and has unintended consequences.

>> By definition, an external statement is outside the

>> YANG language.  Compilers are only required to

>> properly skip over them.

>

> All extension must be properly defined.



Hmm… An extension extends the YANG language, so if it was to be prop=
erly defined, such a definition should be placed in the ABNF. The "ext=
ension" statement only serves documentation purposes, and also YIN tra=
nslation - but the latter could be easily done without it, using simply the=
 same attribute name for all extension arguments, e.g. "arg".




The extension (unknown) statement is i=
n the ABNF.
It is correctly defined.  The text "MAY be =
ignored..."
was put in the RFC for a reason.  A complia=
nt implementation


is allowed to ignore the entire external statement.   By "ig=
nore"
I mean treat it as a comment -- it has no semantic mea=
ning to
the compiler at all and therefore no knowledge of the sub=
-statements


that are even allowed within the external statement.

The 'arg' sub-statement is the "argment" part of =
the ABNF,
not the nested sub-statements.



 statement =
=3D keyword [argument] (";" / "{" *statement "}&qu=
ot;)



Lada



Andy
 


--047d7b1637b78a79f904dcc38da8--

From lhotka@nic.cz  Wed May 15 09:05: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 0682A21F85D6 for ; Wed, 15 May 2013 09:05:25 -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 JTLcuhAwGmuv for ; Wed, 15 May 2013 09:05: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 CA3D221F84DC for ; Wed, 15 May 2013 09:05:23 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id D6B2613FACF; Wed, 15 May 2013 18:05:21 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1368633921; bh=0LAS7oftlgvbDsopEz/ZSTHZWdcp6QkRVceJuMYkfn8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=scCa5bRbEKoZjPd5KvpaYV1IWx7xQC4+aN/x4iTtUJHY+I35tvmHzrNgOl6iXYwO0 hm77yoWtMXv/6L5yNRzual9y9xeSdvx2XELyh6dACioUIrvjp9LEXutCymT8Wm7d3L Z3GoCmX3eaK81iQHter+rYpZ7BXKn5aUBkYLhYO4=
Content-Type: text/plain; charset=windows-1250
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Wed, 15 May 2013 18:05:19 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <19000633-4F04-4FFD-B598-5233DA6D5D17@nic.cz>
References: <20130515.122228.2163690341458789807.mbj@tail-f.com> <519363F7.7090406@mg-soft.com>  <20130515.162202.311372082160778868.mbj@tail-f.com>  
To: Andy Bierman 
X-Mailer: Apple Mail (2.1503)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] What does unknown-statement2 represent in YANG grammar?
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, 15 May 2013 16:05:25 -0000

On May 15, 2013, at 5:39 PM, Andy Bierman  wrote:

>=20
>=20
> On Wed, May 15, 2013 at 8:21 AM, Ladislav Lhotka  =
wrote:
>=20
> On May 15, 2013, at 4:22 PM, Martin Bjorklund  wrote:
>=20
> > Andy Bierman  wrote:
> >> On Wed, May 15, 2013 at 3:31 AM, Jernej Tuljak =
wrote:
> >>
> >>> Dne 15.5.2013 12:22, pi=9Ae Martin Bjorklund:
> >>>
> >>>> Hi,
> >>>>
> >>>> Jernej Tuljak  wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> I'm confused about the unknown-statement2 production in section
> >>>>> 12. What is the purpose the non-prefixed version of unknown =
statements
> >>>>> in this grammar?
> >>>>>
> >>>>> This production is never mentioned in the rest of the document
> >>>>> directly. I think it's supposed to enable usage of standard YANG
> >>>>> statements in unknown statement (usages of statements defined =
using
> >>>>> extension statement) subtrees.
> >>>>>
> >>>> Yes, this is the intention.
> >>>>
> >>>
> >>
> >> This is a CLR and has unintended consequences.
> >> By definition, an external statement is outside the
> >> YANG language.  Compilers are only required to
> >> properly skip over them.
> >
> > All extension must be properly defined.
>=20
> Hmm=85 An extension extends the YANG language, so if it was to be =
properly defined, such a definition should be placed in the ABNF. The =
"extension" statement only serves documentation purposes, and also YIN =
translation - but the latter could be easily done without it, using =
simply the same attribute name for all extension arguments, e.g. "arg".
>=20
>=20
> The extension (unknown) statement is in the ABNF.

Yes, but this will also match statements that are not declared with the =
"extension" statement. For a compiler or any software, the "extension" =
statement provides little added value.

> It is correctly defined.  The text "MAY be ignored..."
> was put in the RFC for a reason.  A compliant implementation
> is allowed to ignore the entire external statement.   By "ignore"
> I mean treat it as a comment -- it has no semantic meaning to
> the compiler at all and therefore no knowledge of the sub-statements
> that are even allowed within the external statement.

Yes, by way of analogy, RELAX NG validators simply ignore any elements =
of a foreign namespace.


> The 'arg' sub-statement is the "argment" part of the ABNF,
> not the nested sub-statements.
>=20
>  statement =3D keyword [argument] (";" / "{" *statement "}")

What I meant was that for any extension like

foo:bar "123";

we could always use



in YIN syntax.

>=20
> Lada
>=20
>=20
> Andy
> =20

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





From andy@yumaworks.com  Wed May 15 09:36:51 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 4AAFE21F8EE3 for ; Wed, 15 May 2013 09:36:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.651
X-Spam-Level: 
X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[AWL=0.326,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89Riv2iQyDsA for ; Wed, 15 May 2013 09:36:50 -0700 (PDT)
Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 1C36621F8F41 for ; Wed, 15 May 2013 09:36:49 -0700 (PDT)
Received: by mail-ie0-f175.google.com with SMTP id s9so4169313iec.34 for ; Wed, 15 May 2013 09:36:49 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=dfYgDeO2UmursCFk6GIRiVrVWeYtzq1wkRE2FtCVZ6E=; b=bml6rHPAiDofesVAEFWmM++fSLg7J3RmDgP7NNqNppaJNHnT/YB5r3wSzs3F443kN9 1IDRj1/6u3HIsCsPcWWc+0iIWIbYFSzPnUvZLsIzE+h+wiBmHm144VFNQ6LPfmaUf4A4 LLV0fOezu65OJwtM8ji8B3197zH28DSCTmOQ+uwJFj9M8/J9FWSDFOGQYZJCUcCxGl1I 4lGLGNCoitNq8R79e+DOttL1LaPI1GLtq+3xPpngGEiFodSijuNcCFVBF7gAT/ZhUPRc CMphieKxxPplQDvX7Eg9+Vw8jBi9Jv48Db4wEULZCrMibvYJeMzGnV4apWI2M62dwLxe afZA==
MIME-Version: 1.0
X-Received: by 10.50.126.1 with SMTP id mu1mr6263765igb.5.1368635809153; Wed, 15 May 2013 09:36:49 -0700 (PDT)
Received: by 10.231.206.71 with HTTP; Wed, 15 May 2013 09:36:49 -0700 (PDT)
In-Reply-To: <19000633-4F04-4FFD-B598-5233DA6D5D17@nic.cz>
References: <20130515.122228.2163690341458789807.mbj@tail-f.com> <519363F7.7090406@mg-soft.com>  <20130515.162202.311372082160778868.mbj@tail-f.com>   <19000633-4F04-4FFD-B598-5233DA6D5D17@nic.cz>
Date: Wed, 15 May 2013 09:36:49 -0700
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=047d7b1637b73ba9ae04dcc45b95
X-Gm-Message-State: ALoCoQmhCu+kQ57eXhh/5hGRWrMrZgLaRac88U886C+UitBg1OQWQOj4csURX5pJKQxgarByBWL8
Cc: netmod@ietf.org
Subject: Re: [netmod] What does unknown-statement2 represent in YANG grammar?
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, 15 May 2013 16:36:51 -0000

--047d7b1637b73ba9ae04dcc45b95
Content-Type: text/plain; charset=ISO-8859-1

...

> >
> > The extension (unknown) statement is in the ABNF.
>
> Yes, but this will also match statements that are not declared with the
> "extension" statement. For a compiler or any software, the "extension"
> statement provides little added value.
>
>
So you are proposing that the ABNF be changed so unknown-statement2 is a
choice between its current value and all possible YANG statements?
So if any arbitrary YANG statement is used out of context, it MUST
be used correctly?

There are no rules wrt/ the proper context in which an unknown-statement is
used
or the sub-statements that are allowed and have meaning within the
unknown-statement.


> It is correctly defined.  The text "MAY be ignored..."
> > was put in the RFC for a reason.  A compliant implementation
> > is allowed to ignore the entire external statement.   By "ignore"
> > I mean treat it as a comment -- it has no semantic meaning to
> > the compiler at all and therefore no knowledge of the sub-statements
> > that are even allowed within the external statement.
>
> Yes, by way of analogy, RELAX NG validators simply ignore any elements of
> a foreign namespace.
>
>

And they probably ignore all nested elements within foreign elements.
That is what the YANG ABNF says now, and it should stay that way.



> > Lada
> >


Andy

--047d7b1637b73ba9ae04dcc45b95
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

...

>

> The extension (unknown) statement is in the ABNF.



Yes, but this will also match statements that are not declared with the &qu=
ot;extension" statement. For a compiler or any software, the "ext=
ension" statement provides little added value.



So you are proposing that the ABNF be =
changed so unknown-statement2 is a
choice between its current val=
ue and all possible YANG statements?
So if any arbitrary YANG sta=
tement is used out of context, it MUST


be used correctly?

There are no rules wrt/ th=
e proper context in which an unknown-statement is used
or the sub=
-statements that are allowed and have meaning within the unknown-statement.=






> It is correctly defined. =A0The text "MAY be ignored..."

> was put in the RFC for a reason. =A0A compliant implementation

> is allowed to ignore the entire external statement. =A0 By "ignor=
e"

> I mean treat it as a comment -- it has no semantic meaning to

> the compiler at all and therefore no knowledge of the sub-statements
> that are even allowed within the external statement.



Yes, by way of analogy, RELAX NG validators simply ignore any elements of a=
 foreign namespace.




And they probably ignor=
e all nested elements within foreign elements.
That is what the Y=
ANG ABNF says now, and it should stay that way.


=A0

> Lada

>

Andy
=A0


--047d7b1637b73ba9ae04dcc45b95--

From andy@yumaworks.com  Wed May 15 09:50: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 B3F9521F8F41 for ; Wed, 15 May 2013 09:50:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.692
X-Spam-Level: 
X-Spam-Status: No, score=-1.692 tagged_above=-999 required=5 tests=[AWL=0.285,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZW19eGwYnpt for ; Wed, 15 May 2013 09:50:22 -0700 (PDT)
Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 658F321F9080 for ; Wed, 15 May 2013 09:50:21 -0700 (PDT)
Received: by mail-ie0-f178.google.com with SMTP id b11so4142418iee.37 for ; Wed, 15 May 2013 09:50:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=jclQ5F1UWa7V54N5kSiFt7e+C4r+7MoxdKHCz9zVVKo=; b=cBIaV3JpCvGyZtH06KHDDr7CVOiNtQly+aNKB0W3a296yAS+V5nKpsWrBNChWla2BJ ov5fIQhHmvA1LtcyUed75GHnxjXbjPHdbNH9LSpAaut9fWDMsZjIzGNDDRpDMsn4XdLR dDINNzmMd6KOrZqAYqMg2S89qjYPhmbVjgHDu5s52CaMIP4hOfZFBOVStsjFKGEINz63 3KR2oQ4QunugrIScbi8JaDVIvOZzM8jPhVtXoPDAGqPJGwA3Dqh5jMRsKKTVyByjG6bO o6+XmNrcWVAdIfiadOU7FFOMPhwOJdCjdodI0jQVxhV5BhVoqML9PE+GTDt5TLpnnKWj eM5w==
MIME-Version: 1.0
X-Received: by 10.50.102.67 with SMTP id fm3mr6303098igb.5.1368636620361; Wed, 15 May 2013 09:50:20 -0700 (PDT)
Received: by 10.231.206.71 with HTTP; Wed, 15 May 2013 09:50:20 -0700 (PDT)
In-Reply-To: <19000633-4F04-4FFD-B598-5233DA6D5D17@nic.cz>
References: <20130515.122228.2163690341458789807.mbj@tail-f.com> <519363F7.7090406@mg-soft.com>  <20130515.162202.311372082160778868.mbj@tail-f.com>   <19000633-4F04-4FFD-B598-5233DA6D5D17@nic.cz>
Date: Wed, 15 May 2013 09:50:20 -0700
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=047d7b10ca1395651004dcc48b05
X-Gm-Message-State: ALoCoQktttfouBEeV4VFHf/kMe6jB8RJdoRjpY9KK8mV8aQhISlRzap+BytZHvkShENA6UqvBGNL
Cc: netmod@ietf.org
Subject: Re: [netmod] What does unknown-statement2 represent in YANG grammar?
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, 15 May 2013 16:50:23 -0000

--047d7b10ca1395651004dcc48b05
Content-Type: text/plain; charset=ISO-8859-1

Hi,

Here is an example of why its better not to define clever little rules
for YANG statements.  Let's say I want an extension that says
what font color to print keywords in a YANG HTML-ify program.
Since the extension argument can only be 1 unstructured string,
nested statements are used to identify the keywords:

extension font-color {
   argument color;
   description
      "Specifies the font color to be used for the keywords
       identified as sub-statement identifiers within this extension.

           acme:font-color red {
               key;
               type;
               revision;
           }
      ";
  }

IMO we should not make rules about YANG sub-statements when they
are used in a foreign context.


Andy

--047d7b10ca1395651004dcc48b05
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

Here is an example of why its better not to define c=
lever little rules
for YANG statements. =A0Let's say I want a=
n extension that says
what font color to print keywords in a YANG=
 HTML-ify program.


Since the extension argument can only be 1 unstructured string,
<=
div>nested statements are used to identify the keywords:

extension font-color {
=A0 =A0argument color;
=
=A0 =A0description


=A0 =A0 =A0 "Specifies the font color to be used for the keywords=

=A0 =A0 =A0 =A0identified as sub-statement identifiers within th=
is extension.

=A0 =A0 =A0 =A0 =A0 =A0acme:font-col=
or red {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0key;


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0type;
=A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0revision;
=A0 =A0 =A0 =A0 =A0 =A0}
=A0 =A0 =A0 =
";
=A0 }

IMO we should not make rul=
es about YANG sub-statements when they

are used in a foreign context.


Andy=





--047d7b10ca1395651004dcc48b05--

From lhotka@nic.cz  Wed May 15 10:03: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 F074C21F9401 for ; Wed, 15 May 2013 10:03:40 -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 8gXonJkEt8G7 for ; Wed, 15 May 2013 10:03:40 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 3229621F93D4 for ; Wed, 15 May 2013 10:03:40 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 4769613FACF; Wed, 15 May 2013 19:03:38 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1368637418; bh=xtDK4RKOnUzRJ9tj8OYTNoGkJPVvin0rIHfcIXxz5mA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Fv3d01Px/j9nBjN4SaW0vNhaLEWLeWUC+YAkBT1A9sKP7oZf5eShj3+MMqOJZ/6v7 5XFXkPPnrRnUCezJMvNkZy5giA3WQIxCt7vm5cZexmTOTijDhfVbcGVHqLbDGXpTIX hxrJx71Tf31BD0BP2ehr3rptNnglmN2ZPc2X++Qo=
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Wed, 15 May 2013 19:03:37 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <1527F112-4A0B-4FD5-9026-103797C91C69@nic.cz>
References: <20130515.122228.2163690341458789807.mbj@tail-f.com> <519363F7.7090406@mg-soft.com>  <20130515.162202.311372082160778868.mbj@tail-f.com>   <19000633-4F04-4FFD-B598-5233DA6D5D17@nic.cz> 
To: Andy Bierman 
X-Mailer: Apple Mail (2.1503)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] What does unknown-statement2 represent in YANG grammar?
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, 15 May 2013 17:03:41 -0000

On May 15, 2013, at 6:50 PM, Andy Bierman  wrote:

> Hi,
>=20
> Here is an example of why its better not to define clever little rules
> for YANG statements.  Let's say I want an extension that says
> what font color to print keywords in a YANG HTML-ify program.
> Since the extension argument can only be 1 unstructured string,
> nested statements are used to identify the keywords:
>=20
> extension font-color {
>    argument color;
>    description
>       "Specifies the font color to be used for the keywords
>        identified as sub-statement identifiers within this extension.
>=20
>            acme:font-color red {
>                key;
>                type;
>                revision;
>            }
>       ";
>   }
>=20
> IMO we should not make rules about YANG sub-statements when they
> are used in a foreign context.

I agree. IMO, the unknown-statement production could allow any content =
instead of "*unknown-statement2".
This would make the parsing much simpler and extensions more flexible, =
without causing any harm to generic YANG software.

Lada

>=20
>=20
> Andy
>=20
>=20

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





From mbj@tail-f.com  Wed May 15 10:21: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 A2BFE21F8F33 for ; Wed, 15 May 2013 10:21:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.747
X-Spam-Level: 
X-Spam-Status: No, score=-0.747 tagged_above=-999 required=5 tests=[AWL=1.299,  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 OxUiXTxVbnmn for ; Wed, 15 May 2013 10:21:32 -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 6BFF421F85ED for ; Wed, 15 May 2013 10:21:31 -0700 (PDT)
Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 8E3991200AEC; Wed, 15 May 2013 19:21:30 +0200 (CEST)
Date: Wed, 15 May 2013 19:21:30 +0200 (CEST)
Message-Id: <20130515.192130.360606148.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund 
In-Reply-To: 
References:  <19000633-4F04-4FFD-B598-5233DA6D5D17@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] What does unknown-statement2 represent in YANG grammar?
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, 15 May 2013 17:21:38 -0000

Andy Bierman  wrote:
> ...
> 
> > >
> > > The extension (unknown) statement is in the ABNF.
> >
> > Yes, but this will also match statements that are not declared with the
> > "extension" statement. For a compiler or any software, the "extension"
> > statement provides little added value.
> >
> >
> So you are proposing that the ABNF be changed so unknown-statement2 is a
> choice between its current value and all possible YANG statements?
> So if any arbitrary YANG statement is used out of context, it MUST
> be used correctly?

Yes.  This is what the current text in 7.17 tried to say:

   Syntactically, the substatements MUST be YANG
   statements, or also defined using "extension" statements.

The first idea was to require that all substatements to an extension
were also extensions.  But that would mean if you define some
extension that need all container / leaf / list ... they would have to
copy almost all core YANG stmts.  (for example, suppose we add a new
"alarm" keyword in an extension module, and an alarm has data nodes as
substmts.)

So we said that it is ok to use core YANG statements, as long as they
are used the way they are defined.  For a reader, it is much easier if
a statement you know always follow the same rules, instead of having
context sensitve syntax.


/martin

From andy@yumaworks.com  Wed May 15 15:40: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 920A911E80D9 for ; Wed, 15 May 2013 15:40:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.723
X-Spam-Level: 
X-Spam-Status: No, score=-1.723 tagged_above=-999 required=5 tests=[AWL=0.254,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0eT2NQhe9o6 for ; Wed, 15 May 2013 15:40:17 -0700 (PDT)
Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id E301911E80E0 for ; Wed, 15 May 2013 15:40:13 -0700 (PDT)
Received: by mail-ie0-f170.google.com with SMTP id aq17so5108162iec.29 for ; Wed, 15 May 2013 15:40:13 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=Q1N4fj/mkNqr/+/xeyp/bIwAiMS8pADkz/Ir8JOg3og=; b=QSeohDTh53pCckQP0tj/f5OSy17cZshHB8vqMV+vSKTgR4ZVu+fN6mhU0JYlYn0RGX uZ1QYCcRl6OGNr/hnTFxPmKbWuPkVpwrWLRWVY9y2QjL5f/m4mgkUGYan58e+S1cIWou FyPLgpkD0ZXXBKvC1lHTQT6gcaRaWU32pRBd0qoa0eax5i9rL0TP+Iqxs6t290vPXalE HLs5JzvlgSqCU6Gmy189JXJrzosf9AvzPM0PVxGipKdQV78S3yYeheMhs0ge+gfUc6/O X81p33GHehjIRcUZffensFdy/IuRTxqLc1XyZjzxLyDbOxYn67qUH4uFkztTOzPz68zU DoGA==
MIME-Version: 1.0
X-Received: by 10.43.91.73 with SMTP id bl9mr10325122icc.17.1368657613455; Wed, 15 May 2013 15:40:13 -0700 (PDT)
Received: by 10.231.120.74 with HTTP; Wed, 15 May 2013 15:40:13 -0700 (PDT)
In-Reply-To: <20130426062142.GA34767@elstar.local>
References:  <20130426062142.GA34767@elstar.local>
Date: Wed, 15 May 2013 15:40:13 -0700
Message-ID: 
From: Andy Bierman 
To: Juergen Schoenwaelder , Andy Bierman , netmod@ietf.org
Content-Type: multipart/alternative; boundary=bcaec51866dcde9bc704dcc96e2b
X-Gm-Message-State: ALoCoQn036AdCeVUVBuIRRlohw/7w1niMUkK/FMzcX7cMXmlT/+xRw7ABtpprnvs63b73ssV4w6f
Subject: Re: [netmod] draft-ietf-netmod-system-mgmt-06
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, 15 May 2013 22:40:18 -0000

--bcaec51866dcde9bc704dcc96e2b
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I hope it was clear 20 days ago from Martin's email that both co-authors
agree
this is ready for another WGLC.  I hope you are not waiting because I did
not
not send an ACK email in addition to Martin's ACK.


Andy


On Thu, Apr 25, 2013 at 11:21 PM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Thu, Apr 25, 2013 at 01:21:58PM -0700, Andy Bierman wrote:
> > Hi,
> >
> > The ietf-system module draft has been updated:
> > http://www.ietf.org/id/draft-ietf-netmod-system-mgmt-06.txt
> >
> > We think all requested changes were addressed except
> > adding additional parameters to control server auto-population
> > of entries. This should be left for future work.
>
> Thanks for the update. Do I understand correctly that the authors
> believe this document is complete and ready for WG last call?
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         
>

--bcaec51866dcde9bc704dcc96e2b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

I hope it was clear 20 days ago from Martin's em=
ail that both co-authors agree
this is ready for another WGLC. =
=A0I hope you are not waiting because I did not
not send an ACK e=
mail in addition to Martin's ACK.




Andy


On Thu, Apr 25, 2013 at 11:21 PM, Juergen Schoenwaelde=
r <j.schoenwaelder@jacobs-university.de> =
wrote:


On Thu, Apr 25, 2013 at 01:21:58PM -0700, An=
dy Bierman wrote:

> Hi,

>

> The ietf-system module draft has been updated:

> http://www.ietf.org/id/draft-ietf-netmod-system-mgmt-06=
.txt

>

> We think all requested changes were addressed except

> adding additional parameters to control server auto-population

> of entries. This should be left for future work.



Thanks for the update. Do I understand correctly that the authors

believe this document is complete and ready for WG last call?



/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>




--bcaec51866dcde9bc704dcc96e2b--

From xiangli@seguesoft.com  Wed May 15 16:06: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 8EA7E11E80D3 for ; Wed, 15 May 2013 16:06:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=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 rAplNRnTLrdv for ; Wed, 15 May 2013 16:06:06 -0700 (PDT)
Received: from p3plsmtpa07-05.prod.phx3.secureserver.net (p3plsmtpa07-05.prod.phx3.secureserver.net [173.201.192.234]) by ietfa.amsl.com (Postfix) with ESMTP id 113FD11E80BA for ; Wed, 15 May 2013 16:06:06 -0700 (PDT)
Received: from [192.168.2.16] ([98.212.151.151]) by p3plsmtpa07-05.prod.phx3.secureserver.net with  id cP641l0023GEayi01P64wJ; Wed, 15 May 2013 16:06:05 -0700
Message-ID: <519414DD.4020907@seguesoft.com>
Date: Wed, 15 May 2013 18:06:05 -0500
From: Xiang Li 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: netmod@ietf.org
References:  <20130426062142.GA34767@elstar.local> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090604040102020200090900"
Subject: Re: [netmod] draft-ietf-netmod-system-mgmt-06
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, 15 May 2013 23:06:10 -0000

This is a multi-part message in MIME format.
--------------090604040102020200090900
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


On 5/15/2013 5:40 PM, Andy Bierman wrote:
> Hi,
>
> I hope it was clear 20 days ago from Martin's email that both 
> co-authors agree
> this is ready for another WGLC.  I hope you are not waiting because I 
> did not
> not send an ACK email in addition to Martin's ACK.

I saw Juergen's email about  the new 
draft-ietf-netmod-interfaces-cfg-11.txt, where
interfaces and interfaces-state are introduced. I actually liked that 
idea since it clearly
separates  config and state.

"We like to receive feedback about this approach since we have similar
issues with other data models..."


Does that approach apply to this model? Or no...

--Xiang


>
> Andy
>
>
> On Thu, Apr 25, 2013 at 11:21 PM, Juergen Schoenwaelder 
>  > wrote:
>
>     On Thu, Apr 25, 2013 at 01:21:58PM -0700, Andy Bierman wrote:
>     > Hi,
>     >
>     > The ietf-system module draft has been updated:
>     > http://www.ietf.org/id/draft-ietf-netmod-system-mgmt-06.txt
>     >
>     > We think all requested changes were addressed except
>     > adding additional parameters to control server auto-population
>     > of entries. This should be left for future work.
>
>     Thanks for the update. Do I understand correctly that the authors
>     believe this document is complete and ready for WG last call?
>
>     /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


--------------090604040102020200090900
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    
On 5/15/2013 5:40 PM, Andy Bierman
      wrote:

    

    
Hi,
      


      

      
I hope it was clear 20 days ago from Martin's email that both
        co-authors agree

      
this is ready for another WGLC.  I hope you are not waiting
        because I did not

      
not send an ACK email in addition to Martin's ACK.

    

    

    I saw Juergen's email about  the new
    draft-ietf-netmod-interfaces-cfg-11.txt, where

    interfaces and interfaces-state are introduced. I actually liked
    that idea since it clearly

    separates  config and state.

    

    
"We like to receive feedback about this approach since we have similar
issues with other data models..."


Does that approach apply to this model? Or no...

--Xiang



    

    

      


      

      
Andy

      


      

      


        
On Thu, Apr 25, 2013 at 11:21 PM,
          Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
          wrote:

          
On Thu,
            Apr 25, 2013 at 01:21:58PM -0700, Andy Bierman wrote:

            > Hi,

            >

            > The ietf-system module draft has been updated:

            > http://www.ietf.org/id/draft-ietf-netmod-system-mgmt-06.txt

            >

            > We think all requested changes were addressed except

            > adding additional parameters to control server
            auto-population

            > of entries. This should be left for future work.

            

            Thanks for the update. Do I understand correctly that the
            authors

            believe this document is complete and ready for WG last
            call?

            

                /js

                

                --

                Juergen Schoenwaelder           Jacobs University Bremen
                gGmbH

                Phone: +49 421 200 3587         Campus Ring 1, 28759
                Bremen, Germany

                Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

              

        

        

      

      

      

      

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


    

    

    

  


--------------090604040102020200090900--

From andy@yumaworks.com  Wed May 15 16:54: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 8C24121F8765 for ; Wed, 15 May 2013 16:54:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.449
X-Spam-Level: 
X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlmSEp80BV2j for ; Wed, 15 May 2013 16:54:11 -0700 (PDT)
Received: from mail-ia0-x232.google.com (mail-ia0-x232.google.com [IPv6:2607:f8b0:4001:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id F0CEA21F871D for ; Wed, 15 May 2013 16:54:10 -0700 (PDT)
Received: by mail-ia0-f178.google.com with SMTP id i9so2776162iad.37 for ; Wed, 15 May 2013 16:54:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=BYTd9lUEj1vT4Iiz3LXA8Uozx1cA8kLpyZI5mTeWn6E=; b=Dlp69Hjn7J/gTaSj4IxNmZI7plsAyHX6wC2rUiu2ozDQNyLEKKUhMbAGy58qlkfhmM Lkur/92RXPWr67Ht5jmVxbFVjgow1DIKRuQgtYFG/bYJvoR3QzD/9gkVmo78Ip4PT9/W qlaE0g9M3Wf9GnPVW4OyDgqJZf9gFqyPLzMzx4HPUgjifDeIaD345MlW8dgkVzfIwpBd 9YJsU5Gu/1tkZIjXb++m1VYMC6fb0SBdBIZM4uuc4b2kiw/pIQSoYfna/sRUeCOHxfev PjDrz8NQN26uXWFquV31ZBYedATLpI7DvMEDI5DtVCshkVIEVp52uWngNkptMCOjjOBb pEYg==
MIME-Version: 1.0
X-Received: by 10.50.73.165 with SMTP id m5mr6958678igv.28.1368662050369; Wed, 15 May 2013 16:54:10 -0700 (PDT)
Received: by 10.231.120.74 with HTTP; Wed, 15 May 2013 16:54:10 -0700 (PDT)
In-Reply-To: <519414DD.4020907@seguesoft.com>
References:  <20130426062142.GA34767@elstar.local>  <519414DD.4020907@seguesoft.com>
Date: Wed, 15 May 2013 16:54:10 -0700
Message-ID: 
From: Andy Bierman 
To: Xiang Li 
Content-Type: multipart/alternative; boundary=089e013a20305486af04dcca779f
X-Gm-Message-State: ALoCoQmPI4BMjJXvuARnhZKXO7pYe/Mm6m3hK8WgUK6gfEMkLgTcLiPxB45pcEhfsDoBCtCASMiK
Cc: netmod@ietf.org
Subject: Re: [netmod] draft-ietf-netmod-system-mgmt-06
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, 15 May 2013 23:54:11 -0000

--089e013a20305486af04dcca779f
Content-Type: text/plain; charset=ISO-8859-1

On Wed, May 15, 2013 at 4:06 PM, Xiang Li  wrote:

>
> On 5/15/2013 5:40 PM, Andy Bierman wrote:
>
> Hi,
>
>  I hope it was clear 20 days ago from Martin's email that both co-authors
> agree
> this is ready for another WGLC.  I hope you are not waiting because I did
> not
> not send an ACK email in addition to Martin's ACK.
>
>
> I saw Juergen's email about  the new
> draft-ietf-netmod-interfaces-cfg-11.txt, where
> interfaces and interfaces-state are introduced. I actually liked that idea
> since it clearly
> separates  config and state.
>
"We like to receive feedback about this approach since we have similar
> issues with other data models..."
>
>
> Does that approach apply to this model? Or no...
>
>

Not sure.  I do not know how much state information real devices
keep for interfaces that do not exist.  I don't think the interfaces
model should be changed.

There are only 3 config=false nodes in the ietf-system module:

   /system/platform container
   /system/clock/current-datetime leaf
   /system/clock/boot-datetime leaf

What if a client deletes the entire /system container?
What if a client deletes the /system/clock container?
IMO, if that's what the operator wants, then these config=false
objects must not be of interest.


> --Xiang
>
>
>
>
>  Andy
>
>
Andy

--089e013a20305486af04dcca779f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Wed, May 15, 2013 at 4:06 PM, Xiang L=
i <xiangli@seguesoft.com> wrote:


 =20
   =20
 =20
  

    

    
On 5/15/2013 5:40 PM, Andy Bierman
      wrote:

    

    
Hi,
      


      

      
I hope it was clear 20 days ago from Martin's email that bot=
h
        co-authors agree

      
this is ready for another WGLC. =A0I hope you are not waiting
        because I did not

      
not send an ACK email in addition to Martin's ACK.

    

    

    I saw Juergen's email about=A0 the new
    draft-ietf-netmod-interfaces-cfg-11.txt, where

    interfaces and interfaces-state are introduced. I actually liked
    that idea since it clearly

    separates=A0 config and state.=A0

    
"We like to receive feedback about this approach since we hav=
e similar
issues with other data models..."


Does that approach apply to this model? Or no...


Not sure. =A0I do not know how much state =
information real devices
keep for interfaces that do not exist. =
=A0I don't think the interfaces


model should be changed.

There are only 3 con=
fig=3Dfalse nodes in the ietf-system module:

=A0 =
=A0/system/platform container
=A0 =A0/system/clock/current-dateti=
me leaf


=A0 =A0/system/clock/boot-datetime leaf

What =
if a client deletes the entire /system container?
What if a clien=
t deletes the /system/clock container?
IMO, if that's what th=
e operator wants, then these config=3Dfalse


objects must not be of interest.

--Xiang



    

    

      


      

      
Andy

An=
dy
=A0


--089e013a20305486af04dcca779f--

From andy@yumaworks.com  Wed May 15 18: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 CA36D11E80E4 for ; Wed, 15 May 2013 18:15:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.742
X-Spam-Level: 
X-Spam-Status: No, score=-1.742 tagged_above=-999 required=5 tests=[AWL=0.235,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAvkbQwIvsdH for ; Wed, 15 May 2013 18:15:16 -0700 (PDT)
Received: from mail-ia0-x22f.google.com (mail-ia0-x22f.google.com [IPv6:2607:f8b0:4001:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3A53111E80E3 for ; Wed, 15 May 2013 18:15:16 -0700 (PDT)
Received: by mail-ia0-f175.google.com with SMTP id m10so2786174iam.6 for ; Wed, 15 May 2013 18:15:15 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=RZWyyNKog+NFIPb46uuNj+8Ux2Oy/opR55H6GjMM73Q=; b=BqMpclbqebtJfV9hUV0ggaHtWiWTaVW/efNcPV0mbET520vG5D3RZdF1ur5ctvX6xz TnmAr+yVvlM8lQkzC1b7c8+sfaMpKdoQc564O/sphTeZeeEJcr+WmVSikaTlkdR0foIz 5lHcT+YDlXdqJqM7qrFNQ8rQypUqF+KzyPMNptr1FFUhKCIA6T5vyopbgsOc1Y0Vi0bl rHrfxHoa6UqY59oSfTBMh6IYJ1kZ+S4PrthECMY4kDQZLAheinHIQYxADWfhFC4cBcVG Kij9VE0+26oM40bzBJyJTS/fiXWQjy/xP+d2W4J0G0FYvvC0PSTycVO6uVIBrPYzoVct poGw==
MIME-Version: 1.0
X-Received: by 10.50.61.232 with SMTP id t8mr7147850igr.37.1368666914213; Wed, 15 May 2013 18:15:14 -0700 (PDT)
Received: by 10.231.120.74 with HTTP; Wed, 15 May 2013 18:15:14 -0700 (PDT)
Date: Wed, 15 May 2013 18:15:14 -0700
Message-ID: 
From: Andy Bierman 
To: netmod@ietf.org
Content-Type: multipart/alternative; boundary=047d7bdc05e83ce4ad04dccb995a
X-Gm-Message-State: ALoCoQmfPu1CfPXVotr6091ZyynkHrrR/GAfeIr809vNylsbK4W0YmyaacoPYeSkPTaJjdpN30Qx
Subject: [netmod] YANG boolean not the same as XSD boolean
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, 16 May 2013 01:15:17 -0000

--047d7bdc05e83ce4ad04dccb995a
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

I just noticed that YANG boolean does not allow "0" or "1" like XSD.
Is this intentional?


9.5.1.  Lexical Representation

   The lexical representation of a boolean value is a string with a
   value of "true" or "false".  These values MUST be in lowercase.


>From http://www.w3.org/TR/xmlschema-2/#boolean:

3.2.2 boolean

[Definition:]  boolean has the =B7value space=B7 required to support the
mathematical concept of binary-valued logic: {true, false}.

3.2.2.1 Lexical representation

An instance of a datatype that is defined as =B7boolean=B7 can have the
following legal literals {true, false, 1, 0}.

3.2.2.2 Canonical representation

The canonical representation for boolean is the set of literals {true,
false}.


Andy

--047d7bdc05e83ce4ad04dccb995a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

I just noticed that YANG boolean does not allow &quo=
t;0" or "1" like XSD.
Is this intentional?


9.5.1.  Lexical Representation

   The lexical representation of a boolean value is a string with a
   value of "true" or "false".  These values MUST be in=
 lowercase.


=

3.2.2 boolean

[Definition:] =
=A0boolean has the =B7value space=B7 required to support the mathematical c=
oncept of binary-valued logic: {true, false}.



3.2.2.1 Lexical representation

An instance of a datatype that is defined as =B7boolean=B7 can have the fo=
llowing legal literals {true, false, 1, 0}.

3.2.2.=
2 Canonical representation



The canonical representation for boolean is the set of =
literals {true, false}.


Andy<=
/div>





--047d7bdc05e83ce4ad04dccb995a--

From jari.arkko@piuha.net  Wed May 15 23:39: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 A83D921F90EB; Wed, 15 May 2013 23:39:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.481
X-Spam-Level: 
X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 qmPlawyUcG4b; Wed, 15 May 2013 23:39:35 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA2721F8EFD; Wed, 15 May 2013 23:39:35 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C3D662CC48; Thu, 16 May 2013 09:39:34 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGGRA4rOVDzr; Thu, 16 May 2013 09:39:34 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 3F7D22CC3C; Thu, 16 May 2013 09:39:34 +0300 (EEST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Jari Arkko 
In-Reply-To: <5190D9E8.7040004@joelhalpern.com>
Date: Thu, 16 May 2013 09:39:34 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <91318B87-41DC-448C-87D3-ABF8C9CF9BC2@piuha.net>
References: <5170722E.2070401@nostrum.com> <5171C416.5070105@joelhalpern.com> <518D0635.7040301@joelhalpern.com> <5190C181.8020500@cisco.com> <20130513103745.GB8186@elstar.local> <5190D9E8.7040004@joelhalpern.com>
To: Joel M. Halpern 
X-Mailer: Apple Mail (2.1503)
Cc: draft-ietf-netmod-rfc6021-bis.all@tools.ietf.org, gen-art@ietf.org, "A. Jean Mahoney" , NETMOD Working Group 
Subject: Re: [netmod] [Gen-art] Review: draft-ietf-netmod-rfc6021-bis-01
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, 16 May 2013 06:39:40 -0000

Thank you Joel for the review. These reviews are very much appreciated, =
and help me decide whether to recommend or not approval in the IESG tele =
chats. I plan to ballot no-objection for this document in today's IESG =
call.

FWIW - regarding the derived types for addresses - I think I would =
probably have had the same question as Joel. Perhaps a comment in the =
derived type would have helped clarify the issue to the readers.

Thanks,

Jari


From jernej.tuljak@mg-soft.si  Wed May 15 23:46: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 7015B21F925A for ; Wed, 15 May 2013 23:46:11 -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=[AWL=0.000,  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 95tHyuKgaIHL for ; Wed, 15 May 2013 23:46:07 -0700 (PDT)
Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id E9F8121F9253 for ; Wed, 15 May 2013 23:46:06 -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 r4G6k45M007787; Thu, 16 May 2013 08:46:05 +0200
Message-ID: <519480AC.5010900@mg-soft.com>
Date: Thu, 16 May 2013 08:46:04 +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: Martin Bjorklund 
References:  <19000633-4F04-4FFD-B598-5233DA6D5D17@nic.cz>  <20130515.192130.360606148.mbj@tail-f.com>
In-Reply-To: <20130515.192130.360606148.mbj@tail-f.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Cc: netmod@ietf.org
Subject: Re: [netmod] What does unknown-statement2 represent in YANG grammar?
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, 16 May 2013 06:46:11 -0000

Dne 15.5.2013 19:21, piše Martin Bjorklund:
> Andy Bierman  wrote:
>> ...
>>
>>>> The extension (unknown) statement is in the ABNF.
>>> Yes, but this will also match statements that are not declared with the
>>> "extension" statement. For a compiler or any software, the "extension"
>>> statement provides little added value.
>>>
>>>
>> So you are proposing that the ABNF be changed so unknown-statement2 is a
>> choice between its current value and all possible YANG statements?
>> So if any arbitrary YANG statement is used out of context, it MUST
>> be used correctly?
> Yes.  This is what the current text in 7.17 tried to say:
>
>     Syntactically, the substatements MUST be YANG
>     statements, or also defined using "extension" statements.
>
> The first idea was to require that all substatements to an extension
> were also extensions.  But that would mean if you define some
> extension that need all container / leaf / list ... they would have to
> copy almost all core YANG stmts.  (for example, suppose we add a new
> "alarm" keyword in an extension module, and an alarm has data nodes as
> substmts.)
>
> So we said that it is ok to use core YANG statements, as long as they
> are used the way they are defined.  For a reader, it is much easier if
> a statement you know always follow the same rules, instead of having
> context sensitve syntax.

IMHO, this might be useful an is definitely easier to implement than 
what Andy suggests. Also, this way all possible statements have an 
implicit or explicit definition of their basic structure (keyword and 
argument at the very least) without having to rely on context.

Jernej

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


From mbj@tail-f.com  Wed May 15 23:50: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 C4EC921F8797 for ; Wed, 15 May 2013 23:50:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.796
X-Spam-Level: 
X-Spam-Status: No, score=-0.796 tagged_above=-999 required=5 tests=[AWL=0.050,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_64=0.6,  J_CHICKENPOX_65=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 usQVGAjJ26eV for ; Wed, 15 May 2013 23:50:00 -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 401F021F924A for ; Wed, 15 May 2013 23:50:00 -0700 (PDT)
Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id AC03E1200D2F; Thu, 16 May 2013 08:49:57 +0200 (CEST)
Date: Thu, 16 May 2013 08:49:57 +0200 (CEST)
Message-Id: <20130516.084957.06537899.mbj@tail-f.com>
To: ietfdbh@comcast.net
From: Martin Bjorklund 
In-Reply-To: <00b101ce51bb$49c84940$dd58dbc0$@comcast.net>
References: <00b101ce51bb$49c84940$dd58dbc0$@comcast.net>
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: draft-ietf-netmod-interfaces-cfg@tools.ietf.org, netmod@ietf.org
Subject: Re: [netmod] draft-ietf-netmod-interfaces-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: Thu, 16 May 2013 06:50:07 -0000

[adding netmod to cc]

Hi David,

Thank you for the fast review and reply!

"ietfdbh"  wrote:
> Hi,
> 
> A few comments on the new draft.
> It looks much better on many of the issues.
> Still a bit of work to do.
> 
> 1) The ifAlias-related text places a new compliance requirement on SNMP
> implementations.
>              Since ifAlias is defined to be stored in non-volatile  
>                   storage, the SNMP implementation MUST map ifAlias to the  
>                   value of 'description' in the persistently stored  
>                   datastore.
> (This really should be specified as the "MIB implementation", not the "SNMP
> implementation", since the MIB should be able to be used by non-SNMP
> protocols, per RFC1052).

Ok.

> To add such a compliance requirement would require stating that this
> document UPDATES RFC2863, something I don't believe this WG is authorized to
> do.

Hmm, that was not the intention.  This document does not change any
semantics of RFC 2863.  On the contrary - it specifies what
implementations that want to have the same underlying instrumentation
for ifAlias and description have to do in order to stay compliant with
both RFC 2863 and NETCONF/YANG requirements.

> I'm not sure whether we can specify a YANG implementation requirement that
> handles this appropriately, Or whether we just need to have an "operational
> considerations" note for admins warning about the different persistence
> models, And advising admins to sync ifAlias (or the underlying shared
> instrumentation) with their persistent NETCONF datastore (:running or
> :startup).
> (since it is designed to be persistent across reboots, this may only need to
> be done once.)

This cannot be controlled by admins; the note is directed to
implementations.  If an implementation chooses to map description to
ifAlias, and follows this requirement, it means that the admin will
see changes done to ifAlias in the 'description', and vice versa.
(As noted, this is how it works today in some vendors implementations
of ifAlias and 'description' in the CLI).

> 2) interfaces-state/name
> s/ This leaf MAY be mapped to ifName by an implementation./ This leaf MAY be
> mapped from ifName by an implementation./
>  interfaces-state/name contains a "MUST restrict the values" clause. Isn't
> this only necessary on config=true objects?
> interfaces-state/name simply must be able to read the ifName (whose value is
> write-restricted by IF-MIB and interfaces/name, and maybe the CLI).
> I suspect this was just a cut-n-paste error.

I will remove this text.

> 3) interfaces-state
> It's been a while since I was actively involved with YANG.
> I assume that config=false applies to all objects in the interfaces list
> within interfaces-state?

Yes, this is correct.  The config property is inherited by the
sub-nodes, recursively.

> I see the objects/leafs are not each stated as
> being config-false.

> 4) "This leaf has the same semantics as ifAdminStatus"
> ifAdminStatus is read-write, interfaces-state/admin-status is config-false,
> so this isn't quite accurate.
> s/ This leaf has the same semantics as ifAdminStatus/ This leaf has the same
> read semantics as ifAdminStatus/

Yes, makes sense.  I will make this change.

> 5) Does section 4 need to be updated to reflect the config versus status
> split?
> The table doesn't separate config versus state. Should it?

I suggest we simply make it clear which one we mean when there's a
risk for confusion.  So I suggest:

| YANG data node                   | IF-MIB object          |
|----------------------------------+------------------------|
| /interfaces-state/interface      | ifEntry                |
| /interfaces-state/name           | ifName                 |


> 6) Section 4 says ifPromiscuousMode is not included because it is not a
> configuration object.
> now that we have interfaces-state, should ifPromiscuousMode be included?

Do you think it should be included?


/martin

From mbj@tail-f.com  Thu May 16 00:00: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 99ED81F0D30 for ; Thu, 16 May 2013 00:00:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.113
X-Spam-Level: 
X-Spam-Status: No, score=-1.113 tagged_above=-999 required=5 tests=[AWL=0.333,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_65=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 kkDVsViXwQ95 for ; Thu, 16 May 2013 00:00:05 -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 B5EB91F0D11 for ; Thu, 16 May 2013 00:00:05 -0700 (PDT)
Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id E57AE1200D5E; Thu, 16 May 2013 09:00:04 +0200 (CEST)
Date: Thu, 16 May 2013 09:00:04 +0200 (CEST)
Message-Id: <20130516.090004.429542011.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund 
In-Reply-To: 
References:  <519414DD.4020907@seguesoft.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] draft-ietf-netmod-system-mgmt-06
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, 16 May 2013 07:00:11 -0000

Andy Bierman  wrote:
> On Wed, May 15, 2013 at 4:06 PM, Xiang Li  wrote:
> 
> >
> > On 5/15/2013 5:40 PM, Andy Bierman wrote:
> >
> > Hi,
> >
> >  I hope it was clear 20 days ago from Martin's email that both co-authors
> > agree
> > this is ready for another WGLC.  I hope you are not waiting because I did
> > not
> > not send an ACK email in addition to Martin's ACK.
> >
> >
> > I saw Juergen's email about  the new
> > draft-ietf-netmod-interfaces-cfg-11.txt, where
> > interfaces and interfaces-state are introduced. I actually liked that idea
> > since it clearly
> > separates  config and state.
> >
> "We like to receive feedback about this approach since we have similar
> > issues with other data models..."
> >
> >
> > Does that approach apply to this model? Or no...
> >
> >
> 
> Not sure.  I do not know how much state information real devices
> keep for interfaces that do not exist.  I don't think the interfaces
> model should be changed.
> 
> There are only 3 config=false nodes in the ietf-system module:
> 
>    /system/platform container
>    /system/clock/current-datetime leaf
>    /system/clock/boot-datetime leaf

Right, and for this reason I also do not think it is necessary to move
these to a separate tree.

> What if a client deletes the entire /system container?
> What if a client deletes the /system/clock container?

Note that these nodes are non-presence containers, which means that
they exist solely for organizational purposes.  Their presence has no
semantic meaning.  So this means that /system/clock/current-datetime
always exists (*) when you do .

(*) actually, it is not mandatory, so this is not true.


/martin

From jernej.tuljak@mg-soft.si  Thu May 16 00:27: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 8ED8921F86CA for ; Thu, 16 May 2013 00:27:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 pImYuoerXhKi for ; Thu, 16 May 2013 00:27:50 -0700 (PDT)
Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 313C211E80EF for ; Thu, 16 May 2013 00:27:49 -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 r4G7Rle1008731; Thu, 16 May 2013 09:27:47 +0200
Message-ID: <51948A73.6060101@mg-soft.com>
Date: Thu, 16 May 2013 09:27: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: Ladislav Lhotka 
References: <20130515.122228.2163690341458789807.mbj@tail-f.com> <519363F7.7090406@mg-soft.com>  <20130515.162202.311372082160778868.mbj@tail-f.com>   <19000633-4F04-4FFD-B598-5233DA6D5D17@nic.cz>  <1527F112-4A0B-4FD5-9026-103797C91C69@nic.cz>
In-Reply-To: <1527F112-4A0B-4FD5-9026-103797C91C69@nic.cz>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Cc: netmod@ietf.org
Subject: Re: [netmod] What does unknown-statement2 represent in YANG grammar?
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, 16 May 2013 07:27:54 -0000

Dne 15.5.2013 19:03, piše Ladislav Lhotka:
> On May 15, 2013, at 6:50 PM, Andy Bierman  wrote:
>
>> Hi,
>>
>> Here is an example of why its better not to define clever little rules
>> for YANG statements.  Let's say I want an extension that says
>> what font color to print keywords in a YANG HTML-ify program.
>> Since the extension argument can only be 1 unstructured string,
>> nested statements are used to identify the keywords:
>>
>> extension font-color {
>>     argument color;
>>     description
>>        "Specifies the font color to be used for the keywords
>>         identified as sub-statement identifiers within this extension.
>>
>>             acme:font-color red {
>>                 key;
>>                 type;
>>                 revision;
>>             }
>>        ";
>>    }
>>
>> IMO we should not make rules about YANG sub-statements when they
>> are used in a foreign context.
> I agree. IMO, the unknown-statement production could allow any content instead of "*unknown-statement2".
> This would make the parsing much simpler and extensions more flexible, without causing any harm to generic YANG software.

I disagree. What's wrong with defining another acme extension, 
acme:yang-statements with a "keywords" argument instead of using YANG 
standard statements directly?

extension yang-statements {
argument keywords;
description "Specifies a space separated list of YANG statement keywords 
and may be used in various contexts";
}

acme:yang-statements "key type revision";

Much more readable (subjective) and well defined (fact). In Andy's 
example "key", "type" and "revision" are extensions and can only be 
extensions. Who provides their definitions? How does the compiler know 
that they are not missing arguments? Does acme:font-color provide this 
information for them? Who provides the same information for their 
substatements?

I think it is essential that each possible YANG statement including ALL 
extensions have their base structure defined with YANG syntax or in some 
other well known way (like RFC text). Possible substatements of 
extensions and their cardinalities might be out of scope of RFC6020, but 
not their signatures (keyword and argument). They shouldn't be.

Jernej

>
> Lada
>
>>
>> Andy
>>
>>
> --
> 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  Thu May 16 00:39:26 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 45A4421F902D for ; Thu, 16 May 2013 00:39:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.496
X-Spam-Level: 
X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[AWL=0.550,  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 Oos2Rc-iNrkr for ; Thu, 16 May 2013 00:39:20 -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 5C41121F8FE3 for ; Thu, 16 May 2013 00:39:19 -0700 (PDT)
Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id EA4A11200AEC; Thu, 16 May 2013 09:39:17 +0200 (CEST)
Date: Thu, 16 May 2013 09:39:17 +0200 (CEST)
Message-Id: <20130516.093917.355394659.mbj@tail-f.com>
To: jernej.tuljak@mg-soft.si
From: Martin Bjorklund 
In-Reply-To: <51948A73.6060101@mg-soft.com>
References:  <1527F112-4A0B-4FD5-9026-103797C91C69@nic.cz> <51948A73.6060101@mg-soft.com>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-15
Content-Transfer-Encoding: quoted-printable
Cc: netmod@ietf.org
Subject: Re: [netmod] What does unknown-statement2 represent in YANG grammar?
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, 16 May 2013 07:39:26 -0000

Jernej Tuljak  wrote:
> Dne 15.5.2013 19:03, pi=A8e Ladislav Lhotka:
> > On May 15, 2013, at 6:50 PM, Andy Bierman  wrot=
e:
> >
> >> Hi,
> >>
> >> Here is an example of why its better not to define clever little r=
ules
> >> for YANG statements.  Let's say I want an extension that says
> >> what font color to print keywords in a YANG HTML-ify program.
> >> Since the extension argument can only be 1 unstructured string,
> >> nested statements are used to identify the keywords:
> >>
> >> extension font-color {
> >>     argument color;
> >>     description
> >>        "Specifies the font color to be used for the keywords
> >>         identified as sub-statement identifiers within this extens=
ion.
> >>
> >>             acme:font-color red {
> >>                 key;
> >>                 type;
> >>                 revision;
> >>             }
> >>        ";
> >>    }
> >>
> >> IMO we should not make rules about YANG sub-statements when they
> >> are used in a foreign context.
> > I agree. IMO, the unknown-statement production could allow any cont=
ent
> > instead of "*unknown-statement2".
> > This would make the parsing much simpler and extensions more flexib=
le,
> > without causing any harm to generic YANG software.
> =

> I disagree. What's wrong with defining another acme extension,
> acme:yang-statements with a "keywords" argument instead of using YANG=
 standard
> statements directly?
> =

> extension yang-statements {
> argument keywords;
> description "Specifies a space separated list of YANG statement keywo=
rds and
> may be used in various contexts";
> }
> =

> acme:yang-statements "key type revision";
> =

> Much more readable (subjective) and well defined (fact). In Andy's ex=
ample
> "key", "type" and "revision" are extensions and can only be extension=
s. Who
> provides their definitions? How does the compiler know that they are =
not
> missing arguments? Does acme:font-color provide this information for =
them? Who
> provides the same information for their substatements?
> =

> I think it is essential that each possible YANG statement including A=
LL
> extensions have their base structure defined with YANG syntax or in s=
ome other
> well known way (like RFC text). Possible substatements of extensions =
and their
> cardinalities might be out of scope of RFC6020, but not their signatu=
res
> (keyword and argument). They shouldn't be.

+1


/martin

From lhotka@nic.cz  Thu May 16 00:47: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 4456C21F913E for ; Thu, 16 May 2013 00:47:20 -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=[AWL=0.000,  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 2GRbrRGKgVbb for ; Thu, 16 May 2013 00:47:19 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5652621F9130 for ; Thu, 16 May 2013 00:47:19 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 6CAC913F989; Thu, 16 May 2013 09:47:17 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1368690437; bh=/AaEzQTWRRTwK3kUIhZkErt3yOShPGjXRU2MuZhPtLs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=FKZo/KOpNIlHjx1uYVTl5282OVN8coC1PO9ez9oJ7sRbC7orMcHOOrY64ZttJLgqb hvwcPx9Mc4kSjcXeNQGleX2Wh/Xz6LM4gdMPVpmdnCO0jUkTyaGr3FQdT3h8MssbWM eD7fwhAP/zsvNvv4DXq/t7Wv6tgfBBggwqktkpmo=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: <51948A73.6060101@mg-soft.com>
Date: Thu, 16 May 2013 09:47:17 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <3C7D104C-BDE7-410E-AB60-557A50B642C3@nic.cz>
References: <20130515.122228.2163690341458789807.mbj@tail-f.com> <519363F7.7090406@mg-soft.com>  <20130515.162202.311372082160778868.mbj@tail-f.com>   <19000633-4F04-4FFD-B598-5233DA6D5D17@nic.cz>  <1527F112-4A0B-4FD5-9026-103797C91C69@nic.cz> <51948A73.6060101@mg-soft.com>
To: Jernej Tuljak 
X-Mailer: Apple Mail (2.1503)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] What does unknown-statement2 represent in YANG grammar?
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, 16 May 2013 07:47:20 -0000

On May 16, 2013, at 9:27 AM, Jernej Tuljak  =
wrote:

> Dne 15.5.2013 19:03, pi=9Ae Ladislav Lhotka:
>> On May 15, 2013, at 6:50 PM, Andy Bierman  wrote:
>>=20
>>> Hi,
>>>=20
>>> Here is an example of why its better not to define clever little =
rules
>>> for YANG statements.  Let's say I want an extension that says
>>> what font color to print keywords in a YANG HTML-ify program.
>>> Since the extension argument can only be 1 unstructured string,
>>> nested statements are used to identify the keywords:
>>>=20
>>> extension font-color {
>>>    argument color;
>>>    description
>>>       "Specifies the font color to be used for the keywords
>>>        identified as sub-statement identifiers within this =
extension.
>>>=20
>>>            acme:font-color red {
>>>                key;
>>>                type;
>>>                revision;
>>>            }
>>>       ";
>>>   }
>>>=20
>>> IMO we should not make rules about YANG sub-statements when they
>>> are used in a foreign context.
>> I agree. IMO, the unknown-statement production could allow any =
content instead of "*unknown-statement2".
>> This would make the parsing much simpler and extensions more =
flexible, without causing any harm to generic YANG software.
>=20
> I disagree. What's wrong with defining another acme extension, =
acme:yang-statements with a "keywords" argument instead of using YANG =
standard statements directly?
>=20
> extension yang-statements {
> argument keywords;
> description "Specifies a space separated list of YANG statement =
keywords and may be used in various contexts";
> }

How is this declaration different from Andy's example with font color?

Lada

>=20
> acme:yang-statements "key type revision";
>=20
> Much more readable (subjective) and well defined (fact). In Andy's =
example "key", "type" and "revision" are extensions and can only be =
extensions. Who provides their definitions? How does the compiler know =
that they are not missing arguments? Does acme:font-color provide this =
information for them? Who provides the same information for their =
substatements?
>=20
> I think it is essential that each possible YANG statement including =
ALL extensions have their base structure defined with YANG syntax or in =
some other well known way (like RFC text). Possible substatements of =
extensions and their cardinalities might be out of scope of RFC6020, but =
not their signatures (keyword and argument). They shouldn't be.
>=20
> Jernej
>=20
>>=20
>> Lada
>>=20
>>>=20
>>> Andy
>>>=20
>>>=20
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>=20

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





From jernej.tuljak@mg-soft.si  Thu May 16 01: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 ECE5021F8EE3 for ; Thu, 16 May 2013 01:00:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.224
X-Spam-Level: 
X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, 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 IBki2fLUqWIz for ; Thu, 16 May 2013 01:00:53 -0700 (PDT)
Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 248E021F8797 for ; Thu, 16 May 2013 01:00:48 -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 r4G80lHR009395; Thu, 16 May 2013 10:00:47 +0200
Message-ID: <5194922F.2000301@mg-soft.com>
Date: Thu, 16 May 2013 10:00: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: Ladislav Lhotka 
References: <20130515.122228.2163690341458789807.mbj@tail-f.com> <519363F7.7090406@mg-soft.com>  <20130515.162202.311372082160778868.mbj@tail-f.com>   <19000633-4F04-4FFD-B598-5233DA6D5D17@nic.cz>  <1527F112-4A0B-4FD5-9026-103797C91C69@nic.cz> <51948A73.6060101@mg-soft.com> <3C7D104C-BDE7-410E-AB60-557A50B642C3@nic.cz>
In-Reply-To: <3C7D104C-BDE7-410E-AB60-557A50B642C3@nic.cz>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Cc: netmod@ietf.org
Subject: Re: [netmod] What does unknown-statement2 represent in YANG grammar?
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, 16 May 2013 08:00:58 -0000

Dne 16.5.2013 9:47, piše Ladislav Lhotka:
> On May 16, 2013, at 9:27 AM, Jernej Tuljak  wrote:
>
>> Dne 15.5.2013 19:03, piše Ladislav Lhotka:
>>> On May 15, 2013, at 6:50 PM, Andy Bierman  wrote:
>>>
>>>> Hi,
>>>>
>>>> Here is an example of why its better not to define clever little rules
>>>> for YANG statements.  Let's say I want an extension that says
>>>> what font color to print keywords in a YANG HTML-ify program.
>>>> Since the extension argument can only be 1 unstructured string,
>>>> nested statements are used to identify the keywords:
>>>>
>>>> extension font-color {
>>>>     argument color;
>>>>     description
>>>>        "Specifies the font color to be used for the keywords
>>>>         identified as sub-statement identifiers within this extension.
>>>>
>>>>             acme:font-color red {
>>>>                 key;
>>>>                 type;
>>>>                 revision;
>>>>             }
>>>>        ";
>>>>    }
>>>>
>>>> IMO we should not make rules about YANG sub-statements when they
>>>> are used in a foreign context.
>>> I agree. IMO, the unknown-statement production could allow any content instead of "*unknown-statement2".
>>> This would make the parsing much simpler and extensions more flexible, without causing any harm to generic YANG software.
>> I disagree. What's wrong with defining another acme extension, acme:yang-statements with a "keywords" argument instead of using YANG standard statements directly?
>>
>> extension yang-statements {
>> argument keywords;
>> description "Specifies a space separated list of YANG statement keywords and may be used in various contexts";
>> }
> How is this declaration different from Andy's example with font color?

It implies nothing about the signature of key, type and revision 
extensions. Andy's example does.

Jernej

>
> Lada
>
>> acme:yang-statements "key type revision";
>>
>> Much more readable (subjective) and well defined (fact). In Andy's example "key", "type" and "revision" are extensions and can only be extensions. Who provides their definitions? How does the compiler know that they are not missing arguments? Does acme:font-color provide this information for them? Who provides the same information for their substatements?
>>
>> I think it is essential that each possible YANG statement including ALL extensions have their base structure defined with YANG syntax or in some other well known way (like RFC text). Possible substatements of extensions and their cardinalities might be out of scope of RFC6020, but not their signatures (keyword and argument). They shouldn't be.
>>
>> Jernej
>>
>>> Lada
>>>
>>>> Andy
>>>>
>>>>
>>> --
>>> 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  Thu May 16 01:26: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 B4C4521F8E84 for ; Thu, 16 May 2013 01:26:06 -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 pkNYsXTBvp9j for ; Thu, 16 May 2013 01:26: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 7FABD21F8E4E for ; Thu, 16 May 2013 01:26:05 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 11B0213FDF0; Thu, 16 May 2013 10:26:04 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1368692764; bh=2Locm/uOHCNd6McUKoSrpx6ns5J9E7ZkjzHDyGmWb7o=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=GipGzt4V6gAw9tfqGQ/SFFIFgjj5JdVYWILvmp+/XPxwRqz8X0MoVmKJQduJfCSVX 7kwYE682rvcxPJFUTl0zafT+iVWhtL9PHM3AVaiQrLJ1FgraWfMQkzMflX+WVSjDKz ADV/Ya7ezQyMEaX1Rpk9Kab/7dsSHGU3yrFjFvDM=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: <5194922F.2000301@mg-soft.com>
Date: Thu, 16 May 2013 10:26:02 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <7A5485A3-64AD-4A83-B64D-F7E38B37AE9A@nic.cz>
References: <20130515.122228.2163690341458789807.mbj@tail-f.com> <519363F7.7090406@mg-soft.com>  <20130515.162202.311372082160778868.mbj@tail-f.com>   <19000633-4F04-4FFD-B598-5233DA6D5D17@nic.cz>  <1527F112-4A0B-4FD5-9026-103797C91C69@nic.cz> <51948A73.6060101@mg-soft.com> <3C7D104C-BDE7-410E-AB60-557A50B642C3@nic.cz> <5194922F.2000301@mg-soft.com>
To: Jernej Tuljak 
X-Mailer: Apple Mail (2.1503)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] What does unknown-statement2 represent in YANG grammar?
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, 16 May 2013 08:26:06 -0000

On May 16, 2013, at 10:00 AM, Jernej Tuljak  =
wrote:

> Dne 16.5.2013 9:47, pi=9Ae Ladislav Lhotka:
>> On May 16, 2013, at 9:27 AM, Jernej Tuljak  =
wrote:
>>=20
>>> Dne 15.5.2013 19:03, pi=9Ae Ladislav Lhotka:
>>>> On May 15, 2013, at 6:50 PM, Andy Bierman  =
wrote:
>>>>=20
>>>>> Hi,
>>>>>=20
>>>>> Here is an example of why its better not to define clever little =
rules
>>>>> for YANG statements.  Let's say I want an extension that says
>>>>> what font color to print keywords in a YANG HTML-ify program.
>>>>> Since the extension argument can only be 1 unstructured string,
>>>>> nested statements are used to identify the keywords:
>>>>>=20
>>>>> extension font-color {
>>>>>    argument color;
>>>>>    description
>>>>>       "Specifies the font color to be used for the keywords
>>>>>        identified as sub-statement identifiers within this =
extension.
>>>>>=20
>>>>>            acme:font-color red {
>>>>>                key;
>>>>>                type;
>>>>>                revision;
>>>>>            }
>>>>>       ";
>>>>>   }
>>>>>=20
>>>>> IMO we should not make rules about YANG sub-statements when they
>>>>> are used in a foreign context.
>>>> I agree. IMO, the unknown-statement production could allow any =
content instead of "*unknown-statement2".
>>>> This would make the parsing much simpler and extensions more =
flexible, without causing any harm to generic YANG software.
>>> I disagree. What's wrong with defining another acme extension, =
acme:yang-statements with a "keywords" argument instead of using YANG =
standard statements directly?
>>>=20
>>> extension yang-statements {
>>> argument keywords;
>>> description "Specifies a space separated list of YANG statement =
keywords and may be used in various contexts";
>>> }
>> How is this declaration different from Andy's example with font =
color?
>=20
> It implies nothing about the signature of key, type and revision =
extensions. Andy's example does.

Sorry, I don't understand. If a compiler, or any generic YANG software, =
sees

acme:font-color red { =85 }

it will just ignore it (treat it as a comment), no matter what's inside =
the braces (*). Software that uses this extension can parse the contents =
inside braces using its own rules, which need not necessarily be the =
same as YANG's. I think it is pretty much the same as "anyxml" in =
instance documents.

(*) The only problem for a YANG parser would be if there are unbalanced =
braces inside { =85 }.

Lada=20

>=20
> Jernej
>=20
>>=20
>> Lada
>>=20
>>> acme:yang-statements "key type revision";
>>>=20
>>> Much more readable (subjective) and well defined (fact). In Andy's =
example "key", "type" and "revision" are extensions and can only be =
extensions. Who provides their definitions? How does the compiler know =
that they are not missing arguments? Does acme:font-color provide this =
information for them? Who provides the same information for their =
substatements?
>>>=20
>>> I think it is essential that each possible YANG statement including =
ALL extensions have their base structure defined with YANG syntax or in =
some other well known way (like RFC text). Possible substatements of =
extensions and their cardinalities might be out of scope of RFC6020, but =
not their signatures (keyword and argument). They shouldn't be.
>>>=20
>>> Jernej
>>>=20
>>>> Lada
>>>>=20
>>>>> Andy
>>>>>=20
>>>>>=20
>>>> --
>>>> Ladislav Lhotka, CZ.NIC Labs
>>>> PGP Key ID: E74E8C0C
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>=20
>>=20
>>=20
>>=20
>=20

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





From jernej.tuljak@mg-soft.si  Thu May 16 01:34: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 0CED121F8FDD for ; Thu, 16 May 2013 01:34:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.179
X-Spam-Level: 
X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=-0.180, 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 oa60abRLu7QG for ; Thu, 16 May 2013 01:34:52 -0700 (PDT)
Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id A6F8621F8F69 for ; Thu, 16 May 2013 01:34:51 -0700 (PDT)
Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id r4G8YoF2010190; Thu, 16 May 2013 10:34:50 +0200
Message-ID: <51949A29.7020206@mg-soft.com>
Date: Thu, 16 May 2013 10:34:49 +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: Ladislav Lhotka 
References: <20130515.122228.2163690341458789807.mbj@tail-f.com> <519363F7.7090406@mg-soft.com>  <20130515.162202.311372082160778868.mbj@tail-f.com>   <19000633-4F04-4FFD-B598-5233DA6D5D17@nic.cz>  <1527F112-4A0B-4FD5-9026-103797C91C69@nic.cz> <51948A73.6060101@mg-soft.com> <3C7D104C-BDE7-410E-AB60-557A50B642C3@nic.cz> <5194922F.2000301@mg-soft.com> <7A5485A3-64AD-4A83-B64D-F7E38B37AE9A@nic.cz>
In-Reply-To: <7A5485A3-64AD-4A83-B64D-F7E38B37AE9A@nic.cz>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Cc: netmod@ietf.org
Subject: Re: [netmod] What does unknown-statement2 represent in YANG grammar?
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, 16 May 2013 08:34:56 -0000

Dne 16.5.2013 10:26, piše Ladislav Lhotka:
> On May 16, 2013, at 10:00 AM, Jernej Tuljak  wrote:
>
>> Dne 16.5.2013 9:47, piše Ladislav Lhotka:
>>> On May 16, 2013, at 9:27 AM, Jernej Tuljak  wrote:
>>>
>>>> Dne 15.5.2013 19:03, piše Ladislav Lhotka:
>>>>> On May 15, 2013, at 6:50 PM, Andy Bierman  wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Here is an example of why its better not to define clever little rules
>>>>>> for YANG statements.  Let's say I want an extension that says
>>>>>> what font color to print keywords in a YANG HTML-ify program.
>>>>>> Since the extension argument can only be 1 unstructured string,
>>>>>> nested statements are used to identify the keywords:
>>>>>>
>>>>>> extension font-color {
>>>>>>     argument color;
>>>>>>     description
>>>>>>        "Specifies the font color to be used for the keywords
>>>>>>         identified as sub-statement identifiers within this extension.
>>>>>>
>>>>>>             acme:font-color red {
>>>>>>                 key;
>>>>>>                 type;
>>>>>>                 revision;
>>>>>>             }
>>>>>>        ";
>>>>>>    }
>>>>>>
>>>>>> IMO we should not make rules about YANG sub-statements when they
>>>>>> are used in a foreign context.
>>>>> I agree. IMO, the unknown-statement production could allow any content instead of "*unknown-statement2".
>>>>> This would make the parsing much simpler and extensions more flexible, without causing any harm to generic YANG software.
>>>> I disagree. What's wrong with defining another acme extension, acme:yang-statements with a "keywords" argument instead of using YANG standard statements directly?
>>>>
>>>> extension yang-statements {
>>>> argument keywords;
>>>> description "Specifies a space separated list of YANG statement keywords and may be used in various contexts";
>>>> }
>>> How is this declaration different from Andy's example with font color?
>> It implies nothing about the signature of key, type and revision extensions. Andy's example does.
> Sorry, I don't understand. If a compiler, or any generic YANG software, sees
>
> acme:font-color red { … }
>
> it will just ignore it (treat it as a comment), no matter what's inside the braces (*). Software that uses this extension can parse the contents inside braces using its own rules, which need not necessarily be the same as YANG's. I think it is pretty much the same as "anyxml" in instance documents.
>
> (*) The only problem for a YANG parser would be if there are unbalanced braces inside { … }.

What if the compiler supports acme:font-color and it doesn't support key 
as an extension? How do you even declare support of such extensions if 
you don't have it's declaration to refer to? What if you have two 
"extension" statements and extensions of both may contain key, type and 
revision as substatements (out of scope), yet you only support them in 
one of the two extensions?

Jernej

>
> Lada
>
>> Jernej
>>
>>> Lada
>>>
>>>> acme:yang-statements "key type revision";
>>>>
>>>> Much more readable (subjective) and well defined (fact). In Andy's example "key", "type" and "revision" are extensions and can only be extensions. Who provides their definitions? How does the compiler know that they are not missing arguments? Does acme:font-color provide this information for them? Who provides the same information for their substatements?
>>>>
>>>> I think it is essential that each possible YANG statement including ALL extensions have their base structure defined with YANG syntax or in some other well known way (like RFC text). Possible substatements of extensions and their cardinalities might be out of scope of RFC6020, but not their signatures (keyword and argument). They shouldn't be.
>>>>
>>>> Jernej
>>>>
>>>>> Lada
>>>>>
>>>>>> Andy
>>>>>>
>>>>>>
>>>>> --
>>>>> 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
>>>
>>>
>>>
>>>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>


From mbj@tail-f.com  Thu May 16 01:40: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 73B4321F90EA for ; Thu, 16 May 2013 01:40:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.606
X-Spam-Level: 
X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[AWL=0.440,  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 bpDUbC0+dPd3 for ; Thu, 16 May 2013 01:40:41 -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 6D45D21F8F0A for ; Thu, 16 May 2013 01:40:41 -0700 (PDT)
Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 7BE5412008D2; Thu, 16 May 2013 10:40:40 +0200 (CEST)
Date: Thu, 16 May 2013 10:40:39 +0200 (CEST)
Message-Id: <20130516.104039.261300424.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: <7A5485A3-64AD-4A83-B64D-F7E38B37AE9A@nic.cz>
References: <3C7D104C-BDE7-410E-AB60-557A50B642C3@nic.cz> <5194922F.2000301@mg-soft.com> <7A5485A3-64AD-4A83-B64D-F7E38B37AE9A@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=utf-8
Content-Transfer-Encoding: base64
Cc: netmod@ietf.org
Subject: Re: [netmod] What does unknown-statement2 represent in YANG grammar?
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, 16 May 2013 08:40:47 -0000

TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+IE9uIE1heSAxNiwg
MjAxMywgYXQgMTA6MDAgQU0sIEplcm5laiBUdWxqYWsgPGplcm5lai50dWxqYWtAbWctc29mdC5z
aT4gd3JvdGU6DQo+IA0KPiA+IERuZSAxNi41LjIwMTMgOTo0NywgcGnFoWUgTGFkaXNsYXYgTGhv
dGthOg0KPiA+PiBPbiBNYXkgMTYsIDIwMTMsIGF0IDk6MjcgQU0sIEplcm5laiBUdWxqYWsgPGpl
cm5lai50dWxqYWtAbWctc29mdC5zaT4gd3JvdGU6DQo+ID4+IA0KPiA+Pj4gRG5lIDE1LjUuMjAx
MyAxOTowMywgcGnFoWUgTGFkaXNsYXYgTGhvdGthOg0KPiA+Pj4+IE9uIE1heSAxNSwgMjAxMywg
YXQgNjo1MCBQTSwgQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0KPiA+
Pj4+IA0KPiA+Pj4+PiBIaSwNCj4gPj4+Pj4gDQo+ID4+Pj4+IEhlcmUgaXMgYW4gZXhhbXBsZSBv
ZiB3aHkgaXRzIGJldHRlciBub3QgdG8gZGVmaW5lIGNsZXZlciBsaXR0bGUgcnVsZXMNCj4gPj4+
Pj4gZm9yIFlBTkcgc3RhdGVtZW50cy4gIExldCdzIHNheSBJIHdhbnQgYW4gZXh0ZW5zaW9uIHRo
YXQgc2F5cw0KPiA+Pj4+PiB3aGF0IGZvbnQgY29sb3IgdG8gcHJpbnQga2V5d29yZHMgaW4gYSBZ
QU5HIEhUTUwtaWZ5IHByb2dyYW0uDQo+ID4+Pj4+IFNpbmNlIHRoZSBleHRlbnNpb24gYXJndW1l
bnQgY2FuIG9ubHkgYmUgMSB1bnN0cnVjdHVyZWQgc3RyaW5nLA0KPiA+Pj4+PiBuZXN0ZWQgc3Rh
dGVtZW50cyBhcmUgdXNlZCB0byBpZGVudGlmeSB0aGUga2V5d29yZHM6DQo+ID4+Pj4+IA0KPiA+
Pj4+PiBleHRlbnNpb24gZm9udC1jb2xvciB7DQo+ID4+Pj4+ICAgIGFyZ3VtZW50IGNvbG9yOw0K
PiA+Pj4+PiAgICBkZXNjcmlwdGlvbg0KPiA+Pj4+PiAgICAgICAiU3BlY2lmaWVzIHRoZSBmb250
IGNvbG9yIHRvIGJlIHVzZWQgZm9yIHRoZSBrZXl3b3Jkcw0KPiA+Pj4+PiAgICAgICAgaWRlbnRp
ZmllZCBhcyBzdWItc3RhdGVtZW50IGlkZW50aWZpZXJzIHdpdGhpbiB0aGlzIGV4dGVuc2lvbi4N
Cj4gPj4+Pj4gDQo+ID4+Pj4+ICAgICAgICAgICAgYWNtZTpmb250LWNvbG9yIHJlZCB7DQo+ID4+
Pj4+ICAgICAgICAgICAgICAgIGtleTsNCj4gPj4+Pj4gICAgICAgICAgICAgICAgdHlwZTsNCj4g
Pj4+Pj4gICAgICAgICAgICAgICAgcmV2aXNpb247DQo+ID4+Pj4+ICAgICAgICAgICAgfQ0KPiA+
Pj4+PiAgICAgICAiOw0KPiA+Pj4+PiAgIH0NCj4gPj4+Pj4gDQo+ID4+Pj4+IElNTyB3ZSBzaG91
bGQgbm90IG1ha2UgcnVsZXMgYWJvdXQgWUFORyBzdWItc3RhdGVtZW50cyB3aGVuIHRoZXkNCj4g
Pj4+Pj4gYXJlIHVzZWQgaW4gYSBmb3JlaWduIGNvbnRleHQuDQo+ID4+Pj4gSSBhZ3JlZS4gSU1P
LCB0aGUgdW5rbm93bi1zdGF0ZW1lbnQgcHJvZHVjdGlvbiBjb3VsZCBhbGxvdyBhbnkgY29udGVu
dA0KPiA+Pj4+IGluc3RlYWQgb2YgIip1bmtub3duLXN0YXRlbWVudDIiLg0KPiA+Pj4+IFRoaXMg
d291bGQgbWFrZSB0aGUgcGFyc2luZyBtdWNoIHNpbXBsZXIgYW5kIGV4dGVuc2lvbnMgbW9yZSBm
bGV4aWJsZSwNCj4gPj4+PiB3aXRob3V0IGNhdXNpbmcgYW55IGhhcm0gdG8gZ2VuZXJpYyBZQU5H
IHNvZnR3YXJlLg0KPiA+Pj4gSSBkaXNhZ3JlZS4gV2hhdCdzIHdyb25nIHdpdGggZGVmaW5pbmcg
YW5vdGhlciBhY21lIGV4dGVuc2lvbiwNCj4gPj4+IGFjbWU6eWFuZy1zdGF0ZW1lbnRzIHdpdGgg
YSAia2V5d29yZHMiIGFyZ3VtZW50IGluc3RlYWQgb2YgdXNpbmcgWUFORw0KPiA+Pj4gc3RhbmRh
cmQgc3RhdGVtZW50cyBkaXJlY3RseT8NCj4gPj4+IA0KPiA+Pj4gZXh0ZW5zaW9uIHlhbmctc3Rh
dGVtZW50cyB7DQo+ID4+PiBhcmd1bWVudCBrZXl3b3JkczsNCj4gPj4+IGRlc2NyaXB0aW9uICJT
cGVjaWZpZXMgYSBzcGFjZSBzZXBhcmF0ZWQgbGlzdCBvZiBZQU5HIHN0YXRlbWVudCBrZXl3b3Jk
cw0KPiA+Pj4gYW5kIG1heSBiZSB1c2VkIGluIHZhcmlvdXMgY29udGV4dHMiOw0KPiA+Pj4gfQ0K
PiA+PiBIb3cgaXMgdGhpcyBkZWNsYXJhdGlvbiBkaWZmZXJlbnQgZnJvbSBBbmR5J3MgZXhhbXBs
ZSB3aXRoIGZvbnQgY29sb3I/DQo+ID4gDQo+ID4gSXQgaW1wbGllcyBub3RoaW5nIGFib3V0IHRo
ZSBzaWduYXR1cmUgb2Yga2V5LCB0eXBlIGFuZCByZXZpc2lvbg0KPiA+IGV4dGVuc2lvbnMuIEFu
ZHkncyBleGFtcGxlIGRvZXMuDQo+IA0KPiBTb3JyeSwgSSBkb24ndCB1bmRlcnN0YW5kLiBJZiBh
IGNvbXBpbGVyLCBvciBhbnkgZ2VuZXJpYyBZQU5HIHNvZnR3YXJlLCBzZWVzDQo+IA0KPiBhY21l
OmZvbnQtY29sb3IgcmVkIHsg4oCmIH0NCj4gDQo+IGl0IHdpbGwganVzdCBpZ25vcmUgaXQgKHRy
ZWF0IGl0IGFzIGEgY29tbWVudCksIG5vIG1hdHRlciB3aGF0J3MgaW5zaWRlIHRoZQ0KPiBicmFj
ZXMgKCopLiBTb2Z0d2FyZSB0aGF0IHVzZXMgdGhpcyBleHRlbnNpb24gY2FuIHBhcnNlIHRoZSBj
b250ZW50cyBpbnNpZGUNCj4gYnJhY2VzIHVzaW5nIGl0cyBvd24gcnVsZXMsIHdoaWNoIG5lZWQg
bm90IG5lY2Vzc2FyaWx5IGJlIHRoZSBzYW1lDQo+IGFzIFlBTkcncy4NCg0KVGhpcyBpcyBub3Qg
aG93IGl0IHdvcmtzLiAgNjAyMCBzYXlzOg0KDQogICBUaGUgc3Vic3RhdGVtZW50cyBvZiBhbiBl
eHRlbnNpb24gYXJlIGRlZmluZWQgYnkgdGhlIGV4dGVuc2lvbiwNCiAgIHVzaW5nIHNvbWUgbWVj
aGFuaXNtIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4NCiAgIFN5bnRh
Y3RpY2FsbHksIHRoZSBzdWJzdGF0ZW1lbnRzIE1VU1QgYmUgWUFORyBzdGF0ZW1lbnRzLCBvciBh
bHNvDQogICBkZWZpbmVkIHVzaW5nICJleHRlbnNpb24iIHN0YXRlbWVudHMuICBZQU5HIHN0YXRl
bWVudHMgaW4NCiAgIGV4dGVuc2lvbnMgTVVTVCBmb2xsb3cgdGhlIHN5bnRhY3RpY2FsIHJ1bGVz
IGluIFNlY3Rpb24gMTINCg0KQSBjb21waWxlciB0aGF0IGRvZXNuJ3QgdW5kZXJzdGFuZCB0aGUg
ZXh0ZW5zaW9ucyBjYW4gc3RpbGwgdmFsaWRhdGUNCnRoYXQgdGhlIGV4dGVuc2lvbiBpcyBkZWZp
bmVkLCBhbmQgdGhhdCB0aGUgYXJndW1lbnQgaXMgdGhlcmUgaWYgdGhlDQpleHRlbnNpb24gbmVl
ZHMgb25lLg0KDQoNCi9tYXJ0aW4NCg==

From jernej.tuljak@mg-soft.si  Thu May 16 01:44: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 5BB7C21F8F9E for ; Thu, 16 May 2013 01:44:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150,  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 rju1r5F7HAaP for ; Thu, 16 May 2013 01:44:19 -0700 (PDT)
Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id E8A9421F8F38 for ; Thu, 16 May 2013 01:44:18 -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 r4G8iIGF010435; Thu, 16 May 2013 10:44:18 +0200
Message-ID: <51949C61.2090402@mg-soft.com>
Date: Thu, 16 May 2013 10:44:17 +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: Martin Bjorklund 
References: <3C7D104C-BDE7-410E-AB60-557A50B642C3@nic.cz> <5194922F.2000301@mg-soft.com> <7A5485A3-64AD-4A83-B64D-F7E38B37AE9A@nic.cz> <20130516.104039.261300424.mbj@tail-f.com>
In-Reply-To: <20130516.104039.261300424.mbj@tail-f.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: netmod@ietf.org
Subject: Re: [netmod] What does unknown-statement2 represent in YANG grammar?
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, 16 May 2013 08:44:24 -0000

Dne 16.5.2013 10:40, piše Martin Bjorklund:
> Ladislav Lhotka  wrote:
>> On May 16, 2013, at 10:00 AM, Jernej Tuljak  wrote:
>>
>>> Dne 16.5.2013 9:47, piše Ladislav Lhotka:
>>>> On May 16, 2013, at 9:27 AM, Jernej Tuljak  wrote:
>>>>
>>>>> Dne 15.5.2013 19:03, piše Ladislav Lhotka:
>>>>>> On May 15, 2013, at 6:50 PM, Andy Bierman  wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Here is an example of why its better not to define clever little rules
>>>>>>> for YANG statements.  Let's say I want an extension that says
>>>>>>> what font color to print keywords in a YANG HTML-ify program.
>>>>>>> Since the extension argument can only be 1 unstructured string,
>>>>>>> nested statements are used to identify the keywords:
>>>>>>>
>>>>>>> extension font-color {
>>>>>>>     argument color;
>>>>>>>     description
>>>>>>>        "Specifies the font color to be used for the keywords
>>>>>>>         identified as sub-statement identifiers within this extension.
>>>>>>>
>>>>>>>             acme:font-color red {
>>>>>>>                 key;
>>>>>>>                 type;
>>>>>>>                 revision;
>>>>>>>             }
>>>>>>>        ";
>>>>>>>    }
>>>>>>>
>>>>>>> IMO we should not make rules about YANG sub-statements when they
>>>>>>> are used in a foreign context.
>>>>>> I agree. IMO, the unknown-statement production could allow any content
>>>>>> instead of "*unknown-statement2".
>>>>>> This would make the parsing much simpler and extensions more flexible,
>>>>>> without causing any harm to generic YANG software.
>>>>> I disagree. What's wrong with defining another acme extension,
>>>>> acme:yang-statements with a "keywords" argument instead of using YANG
>>>>> standard statements directly?
>>>>>
>>>>> extension yang-statements {
>>>>> argument keywords;
>>>>> description "Specifies a space separated list of YANG statement keywords
>>>>> and may be used in various contexts";
>>>>> }
>>>> How is this declaration different from Andy's example with font color?
>>> It implies nothing about the signature of key, type and revision
>>> extensions. Andy's example does.
>> Sorry, I don't understand. If a compiler, or any generic YANG software, sees
>>
>> acme:font-color red { … }
>>
>> it will just ignore it (treat it as a comment), no matter what's inside the
>> braces (*). Software that uses this extension can parse the contents inside
>> braces using its own rules, which need not necessarily be the same
>> as YANG's.
> This is not how it works.  6020 says:
>
>     The substatements of an extension are defined by the extension,
>     using some mechanism outside the scope of this specification.
>     Syntactically, the substatements MUST be YANG statements, or also
>     defined using "extension" statements.  YANG statements in
>     extensions MUST follow the syntactical rules in Section 12
>
> A compiler that doesn't understand the extensions can still validate
> that the extension is defined, and that the argument is there if the
> extension needs one.

Exactly. It actually should do so. If an extension requires an argument, 
but it is missing, it is a syntax error, even if the extension is not 
supported by the compiler.

Jernej

>
>
> /martin


From lhotka@nic.cz  Thu May 16 02:31: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 2FBD621F90EB for ; Thu, 16 May 2013 02:31:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level: 
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_43=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 0SYWEblXL-BF for ; Thu, 16 May 2013 02:31:51 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4F821F90EA for ; Thu, 16 May 2013 02:31:50 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 1D62713F94C; Thu, 16 May 2013 11:31:49 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1368696709; bh=YG1O2suCwZWcfjio1w+f04kvQPclJtO6chXg9YuhulI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=D0FtRL8eFyzQ6uGhc8u8W68emcKMQLvBZ3Z5JgKSRbtkGNRzwYRLzhZuKZhP2c4wY 8RrfGAJ1OkHik7aCITG4PKo6t1EYyzoqgoZST98/1ZjmVgXNfuNaf8RxfMuVvXVgZO 9tPeb1Qw+iBuevPmJrQkj56Te/7TLV/YU2JSW0yo=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: <20130516.104039.261300424.mbj@tail-f.com>
Date: Thu, 16 May 2013 11:31:47 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <3C7D104C-BDE7-410E-AB60-557A50B642C3@nic.cz> <5194922F.2000301@mg-soft.com> <7A5485A3-64AD-4A83-B64D-F7E38B37AE9A@nic.cz> <20130516.104039.261300424.mbj@tail-f.com>
To: Martin Bjorklund 
X-Mailer: Apple Mail (2.1503)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] What does unknown-statement2 represent in YANG grammar?
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, 16 May 2013 09:31:52 -0000

On May 16, 2013, at 10:40 AM, Martin Bjorklund  wrote:

> Ladislav Lhotka  wrote:
>>=20
>> On May 16, 2013, at 10:00 AM, Jernej Tuljak =
 wrote:
>>=20
>>> Dne 16.5.2013 9:47, pi=9Ae Ladislav Lhotka:
>>>> On May 16, 2013, at 9:27 AM, Jernej Tuljak =
 wrote:
>>>>=20
>>>>> Dne 15.5.2013 19:03, pi=9Ae Ladislav Lhotka:
>>>>>> On May 15, 2013, at 6:50 PM, Andy Bierman  =
wrote:
>>>>>>=20
>>>>>>> Hi,
>>>>>>>=20
>>>>>>> Here is an example of why its better not to define clever little =
rules
>>>>>>> for YANG statements.  Let's say I want an extension that says
>>>>>>> what font color to print keywords in a YANG HTML-ify program.
>>>>>>> Since the extension argument can only be 1 unstructured string,
>>>>>>> nested statements are used to identify the keywords:
>>>>>>>=20
>>>>>>> extension font-color {
>>>>>>>   argument color;
>>>>>>>   description
>>>>>>>      "Specifies the font color to be used for the keywords
>>>>>>>       identified as sub-statement identifiers within this =
extension.
>>>>>>>=20
>>>>>>>           acme:font-color red {
>>>>>>>               key;
>>>>>>>               type;
>>>>>>>               revision;
>>>>>>>           }
>>>>>>>      ";
>>>>>>>  }
>>>>>>>=20
>>>>>>> IMO we should not make rules about YANG sub-statements when they
>>>>>>> are used in a foreign context.
>>>>>> I agree. IMO, the unknown-statement production could allow any =
content
>>>>>> instead of "*unknown-statement2".
>>>>>> This would make the parsing much simpler and extensions more =
flexible,
>>>>>> without causing any harm to generic YANG software.
>>>>> I disagree. What's wrong with defining another acme extension,
>>>>> acme:yang-statements with a "keywords" argument instead of using =
YANG
>>>>> standard statements directly?
>>>>>=20
>>>>> extension yang-statements {
>>>>> argument keywords;
>>>>> description "Specifies a space separated list of YANG statement =
keywords
>>>>> and may be used in various contexts";
>>>>> }
>>>> How is this declaration different from Andy's example with font =
color?
>>>=20
>>> It implies nothing about the signature of key, type and revision
>>> extensions. Andy's example does.
>>=20
>> Sorry, I don't understand. If a compiler, or any generic YANG =
software, sees
>>=20
>> acme:font-color red { =85 }
>>=20
>> it will just ignore it (treat it as a comment), no matter what's =
inside the
>> braces (*). Software that uses this extension can parse the contents =
inside
>> braces using its own rules, which need not necessarily be the same
>> as YANG's.
>=20
> This is not how it works.  6020 says:
>=20
>   The substatements of an extension are defined by the extension,
>   using some mechanism outside the scope of this specification.
>   Syntactically, the substatements MUST be YANG statements, or also
>   defined using "extension" statements.  YANG statements in
>   extensions MUST follow the syntactical rules in Section 12

I know, but we are discussing whether this CLR was necessary.

BTW, I wonder if it is only syntactical rules: Is the following allowed =
or not?

  grouping bar {
    container top {
      acme:foo {
        grouping bar {
          leaf bottom {
            type empty;
          }
        }
      }
    }
  }

(the grouping inside the extension shadows the outer one).

>=20
> A compiler that doesn't understand the extensions can still validate
> that the extension is defined, and that the argument is there if the
> extension needs one.

But "some mechanism outside the scope of this specification" still has =
to be used to check the argument value and substatements, so it can also =
catch the missing argument error. The "extension" statement only guards =
against typos in the extension name.

In RELAX NG, foreign-namespace annotations work fine without any =
declaration, though it is true that they rely on the notion of =
well-formed XML.

Lada

>=20
>=20
> /martin

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





From lhotka@nic.cz  Thu May 16 02:35: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 3EA7821F90EA for ; Thu, 16 May 2013 02:35:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level: 
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.050,  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 z-+gtB2sCRZO for ; Thu, 16 May 2013 02:35: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 35C6021F909A for ; Thu, 16 May 2013 02:35:26 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id ECFD413F94C; Thu, 16 May 2013 11:35:22 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1368696923; bh=PBstc2AoeKVcmLIkhqRgocWeIkBpGBdizmp0VQv/YOE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=WKR7uSBVA1DJpSzqAl3ecw1irjNo0B8o4boj+L5S1xt9BVRyPmL1Wabt2LGP/xZ5E IapS5wYnKjW4XmWQNAekmevbK8N/Q7RmueIQsc+xWjaypXOEhqD7WHNW2uX7evldmU TGaUHqyyMr2KKrcMqhDkBrkhuOJIf6Y2ZPfXZzB0=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: <51949A29.7020206@mg-soft.com>
Date: Thu, 16 May 2013 11:35:22 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <13F02060-8CBB-4A5B-B801-071A485F7FD1@nic.cz>
References: <20130515.122228.2163690341458789807.mbj@tail-f.com> <519363F7.7090406@mg-soft.com>  <20130515.162202.311372082160778868.mbj@tail-f.com>   <19000633-4F04-4FFD-B598-5233DA6D5D17@nic.cz>  <1527F112-4A0B-4FD5-9026-103797C91C69@nic.cz> <51948A73.6060101@mg-soft.com> <3C7D104C-BDE7-410E-AB60-557A50B642C3@nic.cz> <5194922F.2000301@mg-soft.com> <7A5485A3-64AD-4A83-B64D-F7E38B37AE9A@nic.cz> <51949A29.7020206@mg-soft.com>
To: Jernej Tuljak 
X-Mailer: Apple Mail (2.1503)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] What does unknown-statement2 represent in YANG grammar?
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, 16 May 2013 09:35:28 -0000

On May 16, 2013, at 10:34 AM, Jernej Tuljak  =
wrote:

> Dne 16.5.2013 10:26, pi=9Ae Ladislav Lhotka:
>> On May 16, 2013, at 10:00 AM, Jernej Tuljak =
 wrote:
>>=20
>>> Dne 16.5.2013 9:47, pi=9Ae Ladislav Lhotka:
>>>> On May 16, 2013, at 9:27 AM, Jernej Tuljak =
 wrote:
>>>>=20
>>>>> Dne 15.5.2013 19:03, pi=9Ae Ladislav Lhotka:
>>>>>> On May 15, 2013, at 6:50 PM, Andy Bierman  =
wrote:
>>>>>>=20
>>>>>>> Hi,
>>>>>>>=20
>>>>>>> Here is an example of why its better not to define clever little =
rules
>>>>>>> for YANG statements.  Let's say I want an extension that says
>>>>>>> what font color to print keywords in a YANG HTML-ify program.
>>>>>>> Since the extension argument can only be 1 unstructured string,
>>>>>>> nested statements are used to identify the keywords:
>>>>>>>=20
>>>>>>> extension font-color {
>>>>>>>    argument color;
>>>>>>>    description
>>>>>>>       "Specifies the font color to be used for the keywords
>>>>>>>        identified as sub-statement identifiers within this =
extension.
>>>>>>>=20
>>>>>>>            acme:font-color red {
>>>>>>>                key;
>>>>>>>                type;
>>>>>>>                revision;
>>>>>>>            }
>>>>>>>       ";
>>>>>>>   }
>>>>>>>=20
>>>>>>> IMO we should not make rules about YANG sub-statements when they
>>>>>>> are used in a foreign context.
>>>>>> I agree. IMO, the unknown-statement production could allow any =
content instead of "*unknown-statement2".
>>>>>> This would make the parsing much simpler and extensions more =
flexible, without causing any harm to generic YANG software.
>>>>> I disagree. What's wrong with defining another acme extension, =
acme:yang-statements with a "keywords" argument instead of using YANG =
standard statements directly?
>>>>>=20
>>>>> extension yang-statements {
>>>>> argument keywords;
>>>>> description "Specifies a space separated list of YANG statement =
keywords and may be used in various contexts";
>>>>> }
>>>> How is this declaration different from Andy's example with font =
color?
>>> It implies nothing about the signature of key, type and revision =
extensions. Andy's example does.
>> Sorry, I don't understand. If a compiler, or any generic YANG =
software, sees
>>=20
>> acme:font-color red { =85 }
>>=20
>> it will just ignore it (treat it as a comment), no matter what's =
inside the braces (*). Software that uses this extension can parse the =
contents inside braces using its own rules, which need not necessarily =
be the same as YANG's. I think it is pretty much the same as "anyxml" in =
instance documents.
>>=20
>> (*) The only problem for a YANG parser would be if there are =
unbalanced braces inside { =85 }.
>=20
> What if the compiler supports acme:font-color and it doesn't support =
key as an extension? How do you even declare support of such extensions =
if you don't have it's declaration to refer to? What if you have two =
"extension" statements and extensions of both may contain key, type and =
revision as substatements (out of scope), yet you only support them in =
one of the two extensions?

If I write software that supports acme:font-color, I'd use a special =
grammar defining the exact syntax of its contents. Then, if =
acme:font-color is encountered, the software will switch to a special =
parsing mode, so it is irrelevant whether the contents breaks any YANG =
rules.

But it is also true that the same can be achieved by embedding the =
foreign contents in the argument. Andy's extension could be used as =
follows:

acme:font-color "name: red; key; type; revision";

Lada

>=20
> Jernej
>=20
>>=20
>> Lada
>>=20
>>> Jernej
>>>=20
>>>> Lada
>>>>=20
>>>>> acme:yang-statements "key type revision";
>>>>>=20
>>>>> Much more readable (subjective) and well defined (fact). In Andy's =
example "key", "type" and "revision" are extensions and can only be =
extensions. Who provides their definitions? How does the compiler know =
that they are not missing arguments? Does acme:font-color provide this =
information for them? Who provides the same information for their =
substatements?
>>>>>=20
>>>>> I think it is essential that each possible YANG statement =
including ALL extensions have their base structure defined with YANG =
syntax or in some other well known way (like RFC text). Possible =
substatements of extensions and their cardinalities might be out of =
scope of RFC6020, but not their signatures (keyword and argument). They =
shouldn't be.
>>>>>=20
>>>>> Jernej
>>>>>=20
>>>>>> Lada
>>>>>>=20
>>>>>>> Andy
>>>>>>>=20
>>>>>>>=20
>>>>>> --
>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>> PGP Key ID: E74E8C0C
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> netmod mailing list
>>>>>> netmod@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>> --
>>>> Ladislav Lhotka, CZ.NIC Labs
>>>> PGP Key ID: E74E8C0C
>>>>=20
>>>>=20
>>>>=20
>>>>=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 andy@yumaworks.com  Thu May 16 03:55: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 D447321F8EED for ; Thu, 16 May 2013 03:55:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.762
X-Spam-Level: 
X-Spam-Status: No, score=-1.762 tagged_above=-999 required=5 tests=[AWL=0.215,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEhh3P2CatR5 for ; Thu, 16 May 2013 03:55:57 -0700 (PDT)
Received: from mail-ia0-x230.google.com (mail-ia0-x230.google.com [IPv6:2607:f8b0:4001:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 461AF21F8EE3 for ; Thu, 16 May 2013 03:55:57 -0700 (PDT)
Received: by mail-ia0-f176.google.com with SMTP id j3so984051iae.7 for ; Thu, 16 May 2013 03:55:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=2rmeT/nASRFpK8bjkNTqU42wRrXjp4haud3yyr24Xtg=; b=BmAS0XDZclRdolW8voS5nSur/+FqEpPh9gZAa5R5c+gnQP0yTE5V1NQfz1y6U2WTsL 6e5MOatBXu4+qdDGHCvNNPDcsI7OgNCs/K8TCesDqPmOt+ADbMU9OpvRyqeXPfxCXftt 0CmzUTtt/jeqVb+mrvkqnEU6el+qcs48YvXXw8A2Xqe75H2erIMplPJJyLdww3hdRZb+ cmxym/NWzIZi4PjtNaZ6YF8AWEZSO+1TKfIe9CC5kbvjnzmAKeXhSrGpv2NwtO5Qmhtb y4b/GF8QOorBavsxUJtWBUKB+rkAwPvV1XRZdw+Z0mVN5zmkpF2359aVDPelqNC/QAlr 8Sxg==
MIME-Version: 1.0
X-Received: by 10.42.65.75 with SMTP id k11mr23014032ici.26.1368701755682; Thu, 16 May 2013 03:55:55 -0700 (PDT)
Received: by 10.231.120.74 with HTTP; Thu, 16 May 2013 03:55:55 -0700 (PDT)
In-Reply-To: <20130516.104039.261300424.mbj@tail-f.com>
References: <3C7D104C-BDE7-410E-AB60-557A50B642C3@nic.cz> <5194922F.2000301@mg-soft.com> <7A5485A3-64AD-4A83-B64D-F7E38B37AE9A@nic.cz> <20130516.104039.261300424.mbj@tail-f.com>
Date: Thu, 16 May 2013 03:55:55 -0700
Message-ID: 
From: Andy Bierman 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=90e6ba3fcd27f3887204dcd3b51c
X-Gm-Message-State: ALoCoQmksNkc0UC5yZd2M+3XUwiAqx8B4pfNmVTALyc/SJ8AJvGisedm6S/di6GSome33OsoBtlA
Cc: netmod@ietf.org
Subject: Re: [netmod] What does unknown-statement2 represent in YANG grammar?
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, 16 May 2013 10:55:57 -0000

--90e6ba3fcd27f3887204dcd3b51c
Content-Type: text/plain; charset=ISO-8859-1

.....

>
> This is not how it works.  6020 says:
>
>    The substatements of an extension are defined by the extension,
>    using some mechanism outside the scope of this specification.
>    Syntactically, the substatements MUST be YANG statements, or also
>    defined using "extension" statements.  YANG statements in
>    extensions MUST follow the syntactical rules in Section 12
>
>
6020 also 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.




> A compiler that doesn't understand the extensions can still validate
> that the extension is defined, and that the argument is there if the
> extension needs one.



Notice the words "the entire unknown-statement".
This clearly includes sub-statements within the entire unknown-statement.

Since any YANG sub-statements present do not actually define any
YANG semantics I fail to see the value in checking the syntax completely.

    extension: An extension attaches non-YANG semantics to statements.
      The extension statement defines new statements to express these
      semantics.

Since the entire extension is clearly non-YANG semantics what is the
point of checking the completeness of the syntax for semantics that do not
apply in the foreign context?  Why is "type-stmt" mandatory for "leaf-stmt"?
Because when defining a real leaf, it is needed.  Used in an arbitrary
foreign context, maybe the 'type' is not needed and therefore not mandatory.



>
> /martin
>

Andy

--90e6ba3fcd27f3887204dcd3b51c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


.....



This is not how it works. =A06020 says:



=A0 =A0The substatements of an extension are defined by the extension,

=A0 =A0using some mechanism outside the scope of this specification.

=A0 =A0Syntactically, the substatements MUST be YANG statements, or also
=A0 =A0defined using "extension" statements. =A0YANG statements i=
n

=A0 =A0extensions MUST follow the syntactical rules in Section 12



6020 also says:


  If =
a YANG compiler does not support a particular extension, which
  appears in a YANG module as an unknown-statement (see Section 12),=A0
  the entire unknown-statement MAY=
 be ignored by the compiler.

=A0


A compiler that doesn't understand the extensions can still validate
that the extension is defined, and that the argument is there if the

extension needs one.


Notice =
the words "the entire unknown-statement".
This clearly =
includes sub-statements within the entire unknown-statement.


Since any YANG sub-statements present do not actually define=
 any
YANG semantics I fail to see the value in checking the synta=
x completely.

    extension: An extension attaches non-YANG semantics to statements.
      The extension statement defines new statements to express these
      semantics.
Since the entire extension is clearly non-=
YANG semantics what is the
point of checking the completeness of =
the syntax for semantics that do not
apply in the foreign context=
? =A0Why is "type-stmt" mandatory for "leaf-stmt"?

Because when defining a real leaf, it is needed. =A0Used in an arbitra=
ry
foreign context, maybe the 'type' is not needed and th=
erefore not mandatory.








/martin

Andy
=A0


--90e6ba3fcd27f3887204dcd3b51c--

From mbj@tail-f.com  Thu May 16 04:02: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 827A321F8F43 for ; Thu, 16 May 2013 04:02:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.679
X-Spam-Level: 
X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[AWL=0.367,  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 H9gF-yRNMt3y for ; Thu, 16 May 2013 04: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 CD96B21F8F33 for ; Thu, 16 May 2013 04:02:06 -0700 (PDT)
Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 836A31200D2F; Thu, 16 May 2013 13:02:05 +0200 (CEST)
Date: Thu, 16 May 2013 13:02:04 +0200 (CEST)
Message-Id: <20130516.130204.348297528.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund 
In-Reply-To: 
References: <7A5485A3-64AD-4A83-B64D-F7E38B37AE9A@nic.cz> <20130516.104039.261300424.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] What does unknown-statement2 represent in YANG grammar?
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, 16 May 2013 11:02:16 -0000

Andy Bierman  wrote:
> .....
> 
> >
> > This is not how it works.  6020 says:
> >
> >    The substatements of an extension are defined by the extension,
> >    using some mechanism outside the scope of this specification.
> >    Syntactically, the substatements MUST be YANG statements, or also
> >    defined using "extension" statements.  YANG statements in
> >    extensions MUST follow the syntactical rules in Section 12
> >
> >
> 6020 also 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.
> 
> 
> 
> 
> > A compiler that doesn't understand the extensions can still validate
> > that the extension is defined, and that the argument is there if the
> > extension needs one.
> 
> 
> 
> Notice the words "the entire unknown-statement".
> This clearly includes sub-statements within the entire unknown-statement.

Yes.  But even if the compiler ignores them they have to follow the
syntactic rules of 'unknown-statement', and Lada suggested that they
didn't have to.

> Since any YANG sub-statements present do not actually define any
> YANG semantics I fail to see the value in checking the syntax completely.
> 
>     extension: An extension attaches non-YANG semantics to statements.
>       The extension statement defines new statements to express these
>       semantics.
> 
> Since the entire extension is clearly non-YANG semantics what is the
> point of checking the completeness of the syntax for semantics that do not
> apply in the foreign context?  Why is "type-stmt" mandatory for "leaf-stmt"?
> Because when defining a real leaf, it is needed.  Used in an arbitrary
> foreign context, maybe the 'type' is not needed and therefore not mandatory.

Then you shouldn't piggy-back on the YANG statement 'leaf', but define
your own extension 'andy:leaf' instead.

You might think that this is too restrictive, but I think it is a
feature.  Also, my experience with the restrictive syntax in 6020 is
that it works pretty well.


/martin

From ietfc@btconnect.com  Thu May 16 04:18: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 42B0C21F8733 for ; Thu, 16 May 2013 04:18:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.203
X-Spam-Level: 
X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=-0.896, BAYES_00=-2.599, MISSING_HEADERS=1.292]
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 flbssSUyU9zm for ; Thu, 16 May 2013 04:18:11 -0700 (PDT)
Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0184.outbound.messaging.microsoft.com [213.199.154.184]) by ietfa.amsl.com (Postfix) with ESMTP id AF08321F8F43 for ; Thu, 16 May 2013 04:18:09 -0700 (PDT)
Received: from mail78-db8-R.bigfish.com (10.174.8.247) by DB8EHSOBE001.bigfish.com (10.174.4.64) with Microsoft SMTP Server id 14.1.225.23; Thu, 16 May 2013 11:18:09 +0000
Received: from mail78-db8 (localhost [127.0.0.1])	by mail78-db8-R.bigfish.com (Postfix) with ESMTP id 3F5A4160177	for ; Thu, 16 May 2013 11:18:09 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.249.85; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0710HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -12
X-BigFish: PS-12(zz9371I936eI542I1432Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1724k304l1d11m1155h)
Received: from mail78-db8 (localhost.localdomain [127.0.0.1]) by mail78-db8 (MessageSwitch) id 1368703086545972_2469; Thu, 16 May 2013 11:18:06 +0000 (UTC)
Received: from DB8EHSMHS020.bigfish.com (unknown [10.174.8.225])	by mail78-db8.bigfish.com (Postfix) with ESMTP id 8274140004B	for ; Thu, 16 May 2013 11:18:06 +0000 (UTC)
Received: from AMSPRD0710HT003.eurprd07.prod.outlook.com (157.56.249.85) by DB8EHSMHS020.bigfish.com (10.174.4.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 16 May 2013 11:18:06 +0000
Received: from DB3PRD0511HT004.eurprd05.prod.outlook.com (157.56.254.213) by pod51017.outlook.com (10.255.160.166) with Microsoft SMTP Server (TLS) id 14.16.311.1; Thu, 16 May 2013 11:17:51 +0000
Message-ID: <002901ce5226$412fa740$4001a8c0@gateway.2wire.net>
From: t.petch 
CC: 
References: <20130515140353.15940.12042.idtracker@ietfa.amsl.com>
Date: Thu, 16 May 2013 12:10:21 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.254.213]
X-OriginatorOrg: btconnect.com
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-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: Thu, 16 May 2013 11:18:16 -0000

Mmmm

Separate lists for configutation and state is a big change and I am not
sure whom it benefits.

Being able to set/get/view a table row with most if not all the relevant
information for an interface is so simple that it seems perverse to
split it into two with two separate keys with seemingly no required
relationship between them.

Likewise, having the information together in the YANG module makes it
easier to find, whatever tool is used to view the module.

This split seems more like a political statement, state and
configuration are different and the appearance of this must override
other considerations.

Tom Petch

----- Original Message -----
From: 
To: 
Cc: 
Sent: Wednesday, May 15, 2013 3:03 PM
Subject: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-11.txt


>
> 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.
>
> Title           : A YANG Data Model for Interface Management
> Author(s)       : Martin Bjorklund
> Filename        : draft-ietf-netmod-interfaces-cfg-11.txt
> Pages           : 44
> Date            : 2013-05-15
>
> Abstract:
>    This document defines a YANG data model for the management of
network
>    interfaces.  It is expected that interface type specific data
models
>    augment the generic interfaces data model defined in this document.
>    The data model includes configuration data, state data and counters
>    for the collection of statistics.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-interfaces-cfg
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-11
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-interfaces-cfg-11
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>



From ietfc@btconnect.com  Thu May 16 04:18: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 ECE2C21F8930 for ; Thu, 16 May 2013 04:18:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.55
X-Spam-Level: 
X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049,  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 3nF-sIEYiRua for ; Thu, 16 May 2013 04:18:11 -0700 (PDT)
Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0184.outbound.messaging.microsoft.com [213.199.154.184]) by ietfa.amsl.com (Postfix) with ESMTP id AF01F21F8EBC for ; Thu, 16 May 2013 04:18:09 -0700 (PDT)
Received: from mail141-db8-R.bigfish.com (10.174.8.249) by DB8EHSOBE022.bigfish.com (10.174.4.85) with Microsoft SMTP Server id 14.1.225.23; Thu, 16 May 2013 11:18:08 +0000
Received: from mail141-db8 (localhost [127.0.0.1])	by mail141-db8-R.bigfish.com (Postfix) with ESMTP id 12F661E09FC; Thu, 16 May 2013 11:18:08 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.249.85; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0710HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -15
X-BigFish: PS-15(zz98dI9371I542I1432Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275bh8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh304l1d11m1155h)
Received: from mail141-db8 (localhost.localdomain [127.0.0.1]) by mail141-db8 (MessageSwitch) id 1368703086345131_31208; Thu, 16 May 2013 11:18:06 +0000 (UTC)
Received: from DB8EHSMHS020.bigfish.com (unknown [10.174.8.249])	by mail141-db8.bigfish.com (Postfix) with ESMTP id 51E7E3600AF; Thu, 16 May 2013 11:18:06 +0000 (UTC)
Received: from AMSPRD0710HT003.eurprd07.prod.outlook.com (157.56.249.85) by DB8EHSMHS020.bigfish.com (10.174.4.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 16 May 2013 11:18:05 +0000
Received: from DB3PRD0511HT004.eurprd05.prod.outlook.com (157.56.254.213) by pod51017.outlook.com (10.255.160.166) with Microsoft SMTP Server (TLS) id 14.16.311.1; Thu, 16 May 2013 11:17:51 +0000
Message-ID: <002801ce5226$40dbbae0$4001a8c0@gateway.2wire.net>
From: t.petch 
To: , Martin Bjorklund 
References: <9904FB1B0159DA42B0B887B7FA8119CA16A0BF@AZ-FFEXMB04.global.avaya.com><9904FB1B0159DA42B0B887B7FA8119CA16A0F8@AZ-FFEXMB04.global.avaya.com> <20130512.225459.503916152.mbj@tail-f.com>
Date: Thu, 16 May 2013 12:00:10 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.254.213]
X-OriginatorOrg: btconnect.com
Cc: netmod@ietf.org
Subject: [netmod] datastore persistence was Re: Last Call: 
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, 16 May 2013 11:18:17 -0000

I see this as important to clarify but fear it will fade away only to be
resurrected some months later, not the first such occurrence on this
list:-(

I see Martin's position as very reasonable,

> I would say:
>
>   The startup datastore MUST be persistent.
>
>   If startup is implemented, running MUST NOT be persistent.
>   If startup is not implemented, running MUST be persitent.
>
>   The candidate datastore MUST be persitent.
>
> /martin

just that it is not what the RFC say.  Rather, I see

:running not writable
not very interesting

:running :writable-running
edits can be made to :running [8.2.1]
how the rest of it got there is undefined
what happens when the device shuts down is undefined

:startup :running :writable-running
edits can be made to :running these will be lost on shutdown [8.7.1]
the initial state of :running is taken from :startup [8.7.1]
:startup cannot be edited but can be replaced by a copy from
:running[8.7.1]

:candidate :startup :running :writable-running
edits can be made to :running these will be lost on shutdown [8.7.1]
the initial state of :running is taken from :startup [8.7.1]
:startup cannot be edited but can be replaced by a copy from
:running[8.7.1]
edits can be made to :candidate [8.3.5.1]
:candidate can be committed to :running [8.3.4.1]
:candidate can be copied to :startup [8.3.5.1]
:startup can be copied to :candidate [8.7.5.1]
:candidate persistence across shutdowns is undefined

I believe that this should be resolved, agreed and documented, as it
affects interoperability.

Tom Petch

----- Original Message -----
From: "Martin Bjorklund" 
To: 
Cc: ; ;
; 
Sent: Sunday, May 12, 2013 9:54 PM

> "Romascanu, Dan (Dan)"  wrote:
> >
> >
> >
> > From: Andy Bierman [mailto:andy@yumaworks.com]
> > Sent: Sunday, May 12, 2013 5:01 PM
> > To: Romascanu, Dan (Dan)
> > Cc: Juergen Schoenwaelder; t.petch; Martin Bjorklund;
netmod@ietf.org
> > Subject: Re: [netmod] Last Call:
 (A
> > YANG Data Model for Interface Management) to Proposed Standard
> >
> >
> > On Sun, May 12, 2013 at 6:24 AM, Romascanu, Dan (Dan)
> > > wrote:
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Juergen Schoenwaelder
> > > [mailto:j.schoenwaelder@jacobs-
> > > university.de]
> > > Sent: Sunday, May 12, 2013 3:00 PM
> > > To: Romascanu, Dan (Dan)
> > > Cc: Andy Bierman; t.petch; Martin Bjorklund;
> > > netmod@ietf.org
> > > Subject: Re: [netmod] Last Call:
 > > 10.txt> (A YANG Data Model for Interface Management) to Proposed
> > > Standard
> > >
> > > On Sun, May 12, 2013 at 07:18:57AM +0000, Romascanu, Dan (Dan)
wrote:
> > > > Sorry,  I meant:
> > > >
> > > > which one of these two statements is true?
> > > >
> > > >
> > > > (Juergen) My understanding was that on systems that only have
> > > , the  configuration data store is persistent.
> > > >
> > > > (Andy) All NETCONF devices have persistent storage of the
running
> > > configuration.
> > > >
> > >
> > > Both statement can both be true. ;-) The problem is to find the
relevant
> > > pieces of text in the RFCs that talk about persistence since
apparently
> > > this is where some people are confused.
> > >
> > > RFC 6241 says for example:
> > >
> > >    o  configuration datastore: The datastore holding the complete
set of
> > >       configuration data that is required to get a device from its
> > >       initial default state into a desired operational state.
> > >
> > > While this does not say 'persist', one might argue that
persistence is
> > > kind of implied in order to "get a device from its initial default
state
> > > into a desired operational state". And the startup datastore
really is a
> > > special feature:
> > >
> > >    o  startup configuration datastore: The configuration datastore
> > >       holding the configuration loaded by the device when it
boots.
> > >       Only present on devices that separate the startup
configuration
> > >       datastore from the running configuration datastore.
> > >
> > > Even without a startup, your running datastore still persists
since it
> > > is a configuration datastore.
> > >
> > >    o  running configuration datastore: A configuration datastore
holding
> > >       the complete configuration currently active on the device.
The
> > >       running configuration datastore always exists.
> > >
> > > NETCONF was designed to modify configuration data and
configuration data
> > > usually persists (otherwise we would simply talk about writable
> > > operational state, the stuff i2rs people are working on).
> > >
> > > /js
> > >
> >
> > [[DR]] So the practical way to formulate the requirement would be:
> >
> > Any device that supports NETCONF MUST implement the running
configuration
> > datastore in persistent memory.
>
> I would say:
>
>   The startup datastore MUST be persistent.
>
>   If startup is implemented, running MUST NOT be persistent.
>   If startup is not implemented, running MUST be persitent.
>
>   The candidate datastore MUST be persitent.
>
>
> /martin
>



From j.schoenwaelder@jacobs-university.de  Thu May 16 04:30: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 7DFAB21F8EBC for ; Thu, 16 May 2013 04:30:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.949
X-Spam-Level: 
X-Spam-Status: No, score=-102.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_15=0.6, 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 M57NIKHPGkAA for ; Thu, 16 May 2013 04:30:37 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5438A21F8F43 for ; Thu, 16 May 2013 04:30:37 -0700 (PDT)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4976F20C09; Thu, 16 May 2013 13:30:36 +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 5HMux_8AJP8h; Thu, 16 May 2013 13:30:36 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D3FE620C06; Thu, 16 May 2013 13:30:35 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id F41FB264F520; Thu, 16 May 2013 13:30:33 +0200 (CEST)
Date: Thu, 16 May 2013 13:30:33 +0200
From: Juergen Schoenwaelder 
To: "t.petch" 
Message-ID: <20130516113033.GA27666@elstar.local>
Mail-Followup-To: "t.petch" , netmod@ietf.org
References: <20130515140353.15940.12042.idtracker@ietfa.amsl.com> <002901ce5226$412fa740$4001a8c0@gateway.2wire.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <002901ce5226$412fa740$4001a8c0@gateway.2wire.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-11.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: Thu, 16 May 2013 11:30:42 -0000

On Thu, May 16, 2013 at 12:10:21PM +0100, t.petch wrote:
> Mmmm
> 
> Separate lists for configutation and state is a big change and I am not
> sure whom it benefits.
> 
> Being able to set/get/view a table row with most if not all the relevant
> information for an interface is so simple that it seems perverse to
> split it into two with two separate keys with seemingly no required
> relationship between them.
> 
> Likewise, having the information together in the YANG module makes it
> easier to find, whatever tool is used to view the module.
> 
> This split seems more like a political statement, state and
> configuration are different and the appearance of this must override
> other considerations.
> 

Tom,

I think you are drawing a picture that is overly simplified given
today's hardware. For example, routers and switches have often hot
swappable interface hardware and as such configuration state and
operational state can be quite different. We need to be able to
properly express that. Furthermore, some interfaces are related to
physical interfaces (that come and og when the physical hardware
changes) and logical interfaces (that come and go as part of
configuration changes). This all needs to be dealt with properly and
the -10 approach did not really allow to do this properly.

As another example, consider the IP configuration extension. There is
a clear difference between IP addresses configured on an interface and
the IP addresses operationally present on an interface. Having two
separate trees allows to deal with this properly.

Given this, as technical contributor, I completely disagree with your
statement that "this split seems more like a political statement".

/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  Thu May 16 04:41: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 F408221F8F43 for ; Thu, 16 May 2013 04:41:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.216
X-Spam-Level: 
X-Spam-Status: No, score=-103.216 tagged_above=-999 required=5 tests=[AWL=0.033, 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 yvuQH0jpSgGa for ; Thu, 16 May 2013 04:41:19 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C256D21F905F for ; Thu, 16 May 2013 04:41:19 -0700 (PDT)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0D61B20C09; Thu, 16 May 2013 13:41:19 +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 89M-XNPL_O1K; Thu, 16 May 2013 13:41:18 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9B7532090B; Thu, 16 May 2013 13:41:18 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 50621264F665; Thu, 16 May 2013 13:41:17 +0200 (CEST)
Date: Thu, 16 May 2013 13:41:17 +0200
From: Juergen Schoenwaelder 
To: Andy Bierman 
Message-ID: <20130516114117.GA27759@elstar.local>
Mail-Followup-To: Andy Bierman , netmod@ietf.org
References:  <20130426062142.GA34767@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] draft-ietf-netmod-system-mgmt-06
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: Thu, 16 May 2013 11:41:25 -0000

On Wed, May 15, 2013 at 03:40:13PM -0700, Andy Bierman wrote:
> Hi,
> 
> I hope it was clear 20 days ago from Martin's email that both
> co-authors agree this is ready for another WGLC.  I hope you are not
> waiting because I did not not send an ACK email in addition to
> Martin's ACK.

Yes, Andy, I understood Martin's message that way.

I wanted to give this document a detailed read before starting WGLC.
But then I got somewhat sidetracked because the discussions around the
other NETMOD documents we did send towards the IESG did keep me quite
busy (and the NETCONF over TLS revision I worked on last week as
well). I apologize for this delay and will focus on the systems-mgmt
document 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 ietfc@btconnect.com  Thu May 16 04:49: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 7C47B21F8E96 for ; Thu, 16 May 2013 04:49:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.37
X-Spam-Level: 
X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=-0.371,  BAYES_00=-2.599, J_CHICKENPOX_15=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 gQ2WFpWuwWUv for ; Thu, 16 May 2013 04:49:19 -0700 (PDT)
Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0251.outbound.messaging.microsoft.com [213.199.154.251]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC0121F8E4C for ; Thu, 16 May 2013 04:49:18 -0700 (PDT)
Received: from mail24-db9-R.bigfish.com (10.174.16.254) by DB9EHSOBE022.bigfish.com (10.174.14.85) with Microsoft SMTP Server id 14.1.225.23; Thu, 16 May 2013 11:49:17 +0000
Received: from mail24-db9 (localhost [127.0.0.1])	by mail24-db9-R.bigfish.com (Postfix) with ESMTP id 0895B220B48; Thu, 16 May 2013 11:49:17 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.253.197; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0710HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -16
X-BigFish: PS-16(zz98dI9371I542I1432I1418Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275bh8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh304l1d11m1155h)
Received: from mail24-db9 (localhost.localdomain [127.0.0.1]) by mail24-db9 (MessageSwitch) id 1368704954390344_1441; Thu, 16 May 2013 11:49:14 +0000 (UTC)
Received: from DB9EHSMHS002.bigfish.com (unknown [10.174.16.237])	by mail24-db9.bigfish.com (Postfix) with ESMTP id 5269B2400D9; Thu, 16 May 2013 11:49:14 +0000 (UTC)
Received: from DBXPRD0710HT003.eurprd07.prod.outlook.com (157.56.253.197) by DB9EHSMHS002.bigfish.com (10.174.14.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 16 May 2013 11:49:13 +0000
Received: from AMXPRD0111HT002.eurprd01.prod.exchangelabs.com (157.56.250.117) by pod51017.outlook.com (10.255.79.166) with Microsoft SMTP Server (TLS) id 14.16.311.1; Thu, 16 May 2013 11:49:13 +0000
Message-ID: <003d01ce522a$a288c720$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Juergen Schoenwaelder 
References: <20130515140353.15940.12042.idtracker@ietfa.amsl.com> <002901ce5226$412fa740$4001a8c0@gateway.2wire.net> <20130516113033.GA27666@elstar.local>
Date: Thu, 16 May 2013 12:43:37 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.250.117]
X-OriginatorOrg: btconnect.com
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-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: Thu, 16 May 2013 11:49:24 -0000

----- Original Message -----
From: "Juergen Schoenwaelder" 
To: "t.petch" 
Cc: 
Sent: Thursday, May 16, 2013 12:30 PM
Subject: Re: [netmod] I-D Action:
draft-ietf-netmod-interfaces-cfg-11.txt


> On Thu, May 16, 2013 at 12:10:21PM +0100, t.petch wrote:
> > Mmmm
> >
> > Separate lists for configutation and state is a big change and I am
not
> > sure whom it benefits.
> >
> > Being able to set/get/view a table row with most if not all the
relevant
> > information for an interface is so simple that it seems perverse to
> > split it into two with two separate keys with seemingly no required
> > relationship between them.
> >
> > Likewise, having the information together in the YANG module makes
it
> > easier to find, whatever tool is used to view the module.
> >
> > This split seems more like a political statement, state and
> > configuration are different and the appearance of this must override
> > other considerations.
> >
>
> Tom,
>
> I think you are drawing a picture that is overly simplified given
> today's hardware. For example, routers and switches have often hot
> swappable interface hardware and as such configuration state and
> operational state can be quite different. We need to be able to
> properly express that. Furthermore, some interfaces are related to
> physical interfaces (that come and og when the physical hardware
> changes) and logical interfaces (that come and go as part of
> configuration changes). This all needs to be dealt with properly and
> the -10 approach did not really allow to do this properly.
>
> As another example, consider the IP configuration extension. There is
> a clear difference between IP addresses configured on an interface and
> the IP addresses operationally present on an interface. Having two
> separate trees allows to deal with this properly.

I agree with your characterisation of the complexity but fail to see how
separate trees helps.  You seem to be changing the basic meaning of an
interface so that there will be configuration interfaces and state
interfaces with a loose (undefined?) coupling between them.  I think
that there is a lack of some analysis of the data, the like of third
normal form, which needs clarifying.

Tom Petch





>
> Given this, as technical contributor, I completely disagree with your
> statement that "this split seems more like a political statement".
>
> /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 May 16 04:49: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 57BB521F8FED for ; Thu, 16 May 2013 04:49:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.356
X-Spam-Level: 
X-Spam-Status: No, score=-1.356 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=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 f9rMmSXej6Pu for ; Thu, 16 May 2013 04:49:34 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 88CBA21F90EA for ; Thu, 16 May 2013 04:49:34 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 882541408D0; Thu, 16 May 2013 13:49:33 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1368704973; bh=+u1kr84HIN8pvKu/l/TJcI2UFk86n8D2nm11KO+k7kg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=vVIeraPmmyM1FSseEEyWMuQdJclzRauQfGRKI3CzS0PNPCHX8/ne7HtXe2fCB70E0 bey87AJ6OI+CqFOe87Os5oo82u/m/0fmPdmt8wV9Sl9ZT8GEBEyC6FWkiehj03ZKYx CjLD80AMK+cBsMHPy1/tVvIkShxJUWjdET7K6A7c=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: <20130516.130204.348297528.mbj@tail-f.com>
Date: Thu, 16 May 2013 13:49:33 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <7A5485A3-64AD-4A83-B64D-F7E38B37AE9A@nic.cz> <20130516.104039.261300424.mbj@tail-f.com>  <20130516.130204.348297528.mbj@tail-f.com>
To: Martin Bjorklund 
X-Mailer: Apple Mail (2.1503)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] What does unknown-statement2 represent in YANG grammar?
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, 16 May 2013 11:49:35 -0000

On May 16, 2013, at 1:02 PM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
>> .....
>>=20
>>>=20
>>> This is not how it works.  6020 says:
>>>=20
>>>   The substatements of an extension are defined by the extension,
>>>   using some mechanism outside the scope of this specification.
>>>   Syntactically, the substatements MUST be YANG statements, or also
>>>   defined using "extension" statements.  YANG statements in
>>>   extensions MUST follow the syntactical rules in Section 12
>>>=20
>>>=20
>> 6020 also says:
>>=20
>>=20
>>  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.
>>=20
>>=20
>>=20
>>=20
>>> A compiler that doesn't understand the extensions can still validate
>>> that the extension is defined, and that the argument is there if the
>>> extension needs one.
>>=20
>>=20
>>=20
>> Notice the words "the entire unknown-statement".
>> This clearly includes sub-statements within the entire =
unknown-statement.
>=20
> Yes.  But even if the compiler ignores them they have to follow the
> syntactic rules of 'unknown-statement', and Lada suggested that they
> didn't have to.
>=20
>> Since any YANG sub-statements present do not actually define any
>> YANG semantics I fail to see the value in checking the syntax =
completely.
>>=20
>>    extension: An extension attaches non-YANG semantics to statements.
>>      The extension statement defines new statements to express these
>>      semantics.
>>=20
>> Since the entire extension is clearly non-YANG semantics what is the
>> point of checking the completeness of the syntax for semantics that =
do not
>> apply in the foreign context?  Why is "type-stmt" mandatory for =
"leaf-stmt"?
>> Because when defining a real leaf, it is needed.  Used in an =
arbitrary
>> foreign context, maybe the 'type' is not needed and therefore not =
mandatory.
>=20
> Then you shouldn't piggy-back on the YANG statement 'leaf', but define
> your own extension 'andy:leaf' instead.
>=20
> You might think that this is too restrictive, but I think it is a
> feature.  Also, my experience with the restrictive syntax in 6020 is
> that it works pretty well.

OK, let's have some fun after lunch:

$ cat acme.yang
module acme {
  namespace "http://example.com/acme";
  prefix "acme";
  extension foo;
  acme:foo {
    identity bar;
    identity baz {
      base bar;
    }
  }
}

$ pyang acme.yang
acme.yang:8: error: identity "bar" not found in module acme

So pyang checks the definition of identity "baz" but ignores the =
definition of "bar".=20

IMO, this "restrictive" approach would need a whole bunch of other CLRs =
in order to be sound and well-defined.

Lada

>=20
>=20
> /martin

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





From mbj@tail-f.com  Thu May 16 04:55: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 8F67321F8D31 for ; Thu, 16 May 2013 04:55:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.132
X-Spam-Level: 
X-Spam-Status: No, score=-1.132 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=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 oqLjxrLPAsaL for ; Thu, 16 May 2013 04:55: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 AC6A821F8B33 for ; Thu, 16 May 2013 04:55:31 -0700 (PDT)
Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id D0A711200AEC; Thu, 16 May 2013 13:55:30 +0200 (CEST)
Date: Thu, 16 May 2013 13:55:29 +0200 (CEST)
Message-Id: <20130516.135529.196380910.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References:  <20130516.130204.348297528.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] What does unknown-statement2 represent in YANG grammar?
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, 16 May 2013 11:55:37 -0000

Ladislav Lhotka  wrote:
> 
> On May 16, 2013, at 1:02 PM, Martin Bjorklund  wrote:
> 
> > Andy Bierman  wrote:
> >> .....
> >> 
> >>> 
> >>> This is not how it works.  6020 says:
> >>> 
> >>>   The substatements of an extension are defined by the extension,
> >>>   using some mechanism outside the scope of this specification.
> >>>   Syntactically, the substatements MUST be YANG statements, or also
> >>>   defined using "extension" statements.  YANG statements in
> >>>   extensions MUST follow the syntactical rules in Section 12
> >>> 
> >>> 
> >> 6020 also 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.
> >> 
> >> 
> >> 
> >> 
> >>> A compiler that doesn't understand the extensions can still validate
> >>> that the extension is defined, and that the argument is there if the
> >>> extension needs one.
> >> 
> >> 
> >> 
> >> Notice the words "the entire unknown-statement".
> >> This clearly includes sub-statements within the entire unknown-statement.
> > 
> > Yes.  But even if the compiler ignores them they have to follow the
> > syntactic rules of 'unknown-statement', and Lada suggested that they
> > didn't have to.
> > 
> >> Since any YANG sub-statements present do not actually define any
> >> YANG semantics I fail to see the value in checking the syntax completely.
> >> 
> >>    extension: An extension attaches non-YANG semantics to statements.
> >>      The extension statement defines new statements to express these
> >>      semantics.
> >> 
> >> Since the entire extension is clearly non-YANG semantics what is the
> >> point of checking the completeness of the syntax for semantics that do not
> >> apply in the foreign context?  Why is "type-stmt" mandatory for "leaf-stmt"?
> >> Because when defining a real leaf, it is needed.  Used in an arbitrary
> >> foreign context, maybe the 'type' is not needed and therefore not mandatory.
> > 
> > Then you shouldn't piggy-back on the YANG statement 'leaf', but define
> > your own extension 'andy:leaf' instead.
> > 
> > You might think that this is too restrictive, but I think it is a
> > feature.  Also, my experience with the restrictive syntax in 6020 is
> > that it works pretty well.
> 
> OK, let's have some fun after lunch:
> 
> $ cat acme.yang
> module acme {
>   namespace "http://example.com/acme";
>   prefix "acme";
>   extension foo;
>   acme:foo {
>     identity bar;
>     identity baz {
>       base bar;
>     }
>   }
> }
> 
> $ pyang acme.yang
> acme.yang:8: error: identity "bar" not found in module acme
> 
> So pyang checks the definition of identity "baz" but ignores the definition of
> "bar".

Bug in pyang then.   It shouldn't check the "baz" identity.


/martin

From j.schoenwaelder@jacobs-university.de  Thu May 16 05:07: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 C9D1A21F8F07 for ; Thu, 16 May 2013 05:07:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.919
X-Spam-Level: 
X-Spam-Status: No, score=-102.919 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_15=0.6, 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 Mnz9TqyuH+Uw for ; Thu, 16 May 2013 05:07:09 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3F85021F8556 for ; Thu, 16 May 2013 05:07:09 -0700 (PDT)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4D91120BF7; Thu, 16 May 2013 14:07:02 +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 G9eirdfLJOi8; Thu, 16 May 2013 14:07:02 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CFD3820BED; Thu, 16 May 2013 14:07:01 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id E0ABB264F879; Thu, 16 May 2013 14:06:59 +0200 (CEST)
Date: Thu, 16 May 2013 14:06:59 +0200
From: Juergen Schoenwaelder 
To: "t.petch" 
Message-ID: <20130516120659.GA27915@elstar.local>
Mail-Followup-To: "t.petch" , netmod@ietf.org
References: <20130515140353.15940.12042.idtracker@ietfa.amsl.com> <002901ce5226$412fa740$4001a8c0@gateway.2wire.net> <20130516113033.GA27666@elstar.local> <003d01ce522a$a288c720$4001a8c0@gateway.2wire.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <003d01ce522a$a288c720$4001a8c0@gateway.2wire.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-11.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: Thu, 16 May 2013 12:07:14 -0000

On Thu, May 16, 2013 at 12:43:37PM +0100, t.petch wrote:
> 
> I agree with your characterisation of the complexity but fail to see how
> separate trees helps.  You seem to be changing the basic meaning of an
> interface so that there will be configuration interfaces and state
> interfaces with a loose (undefined?) coupling between them.  I think
> that there is a lack of some analysis of the data, the like of third
> normal form, which needs clarifying.
> 

Please read the document and then we can discuss on the basis of what
is in the document.

/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 May 16 05:08: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 BD70B21F8D00 for ; Thu, 16 May 2013 05:08:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.587
X-Spam-Level: 
X-Spam-Status: No, score=-1.587 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 6J+R-RwtvuBX for ; Thu, 16 May 2013 05:08:25 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A5F2C21F8CE9 for ; Thu, 16 May 2013 05:08:24 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id DCECE140342; Thu, 16 May 2013 14:08:23 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1368706104; bh=xXKSAkVTjcKs9Uwf99UoyKvJFwynuOB/XYGW54oZ9vw=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=T2nYpidWuhFqBIYqIxWAwJ96TCrSj29XMlSNxJfOgWVJ61q6GXz08bFYu9wyxwO0h zLebzrD2/k9G8mZ71iJZilyHDwiNXRRZqWGkcxWXyYCwJM7Fa74baPsHJVejAczaMm WlfPqmk13xEoTvhTFtvjXGRY9zcAyU90a8gswS9E=
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Content-Type: text/plain; charset=us-ascii
From: Ladislav Lhotka 
X-Priority: 3
In-Reply-To: <002801ce5226$40dbbae0$4001a8c0@gateway.2wire.net>
Date: Thu, 16 May 2013 14:08:23 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <9904FB1B0159DA42B0B887B7FA8119CA16A0BF@AZ-FFEXMB04.global.avaya.com><9904FB1B0159DA42B0B887B7FA8119CA16A0F8@AZ-FFEXMB04.global.avaya.com> <20130512.225459.503916152.mbj@tail-f.com> <002801ce5226$40dbbae0$4001a8c0@gateway.2wire.net>
To: t.petch 
X-Mailer: Apple Mail (2.1503)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] datastore persistence was Re: Last Call: 
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, 16 May 2013 12:08:25 -0000

On May 16, 2013, at 1:00 PM, t.petch  wrote:

> I see this as important to clarify but fear it will fade away only to =
be
> resurrected some months later, not the first such occurrence on this
> list:-(
>=20
> I see Martin's position as very reasonable,
>=20
>> I would say:
>>=20
>>  The startup datastore MUST be persistent.
>>=20
>>  If startup is implemented, running MUST NOT be persistent.
>>  If startup is not implemented, running MUST be persitent.
>>=20
>>  The candidate datastore MUST be persitent.
>>=20
>> /martin
>=20
> just that it is not what the RFC say.  Rather, I see
>=20
> :running not writable
> not very interesting
>=20
> :running :writable-running
> edits can be made to :running [8.2.1]
> how the rest of it got there is undefined
> what happens when the device shuts down is undefined
>=20
> :startup :running :writable-running
> edits can be made to :running these will be lost on shutdown [8.7.1]
> the initial state of :running is taken from :startup [8.7.1]
> :startup cannot be edited but can be replaced by a copy from
> :running[8.7.1]
>=20
> :candidate :startup :running :writable-running
> edits can be made to :running these will be lost on shutdown [8.7.1]
> the initial state of :running is taken from :startup [8.7.1]
> :startup cannot be edited but can be replaced by a copy from
> :running[8.7.1]
> edits can be made to :candidate [8.3.5.1]
> :candidate can be committed to :running [8.3.4.1]
> :candidate can be copied to :startup [8.3.5.1]
> :startup can be copied to :candidate [8.7.5.1]
> :candidate persistence across shutdowns is undefined
>=20
> I believe that this should be resolved, agreed and documented, as it
> affects interoperability.

I agree.

Also, the idea of sharing some persistent data between NETCONF and SNMP =
leads to the question whether the server is allowed to write to any =
config datastore and, if yes, under what circumstances and rules. It =
should certainly observe locks, but there can be other problems. For =
instance, if the server modifies candidate on its own, it could happen =
that a low-privileged client won't be able to perform a commit.

Lada

>=20
> Tom Petch
>=20
> ----- Original Message -----
> From: "Martin Bjorklund" 
> To: 
> Cc: ; ;
> ; 
> Sent: Sunday, May 12, 2013 9:54 PM
>=20
>> "Romascanu, Dan (Dan)"  wrote:
>>>=20
>>>=20
>>>=20
>>> From: Andy Bierman [mailto:andy@yumaworks.com]
>>> Sent: Sunday, May 12, 2013 5:01 PM
>>> To: Romascanu, Dan (Dan)
>>> Cc: Juergen Schoenwaelder; t.petch; Martin Bjorklund;
> netmod@ietf.org
>>> Subject: Re: [netmod] Last Call:
>  (A
>>> YANG Data Model for Interface Management) to Proposed Standard
>>>=20
>>>=20
>>> On Sun, May 12, 2013 at 6:24 AM, Romascanu, Dan (Dan)
>>> > wrote:
>>>=20
>>>=20
>>>=20
>>>=20
>>>> -----Original Message-----
>>>> From: Juergen Schoenwaelder
>>>> [mailto:j.schoenwaelder@jacobs-
>>>> university.de]
>>>> Sent: Sunday, May 12, 2013 3:00 PM
>>>> To: Romascanu, Dan (Dan)
>>>> Cc: Andy Bierman; t.petch; Martin Bjorklund;
>>>> netmod@ietf.org
>>>> Subject: Re: [netmod] Last Call:
> >>> 10.txt> (A YANG Data Model for Interface Management) to Proposed
>>>> Standard
>>>>=20
>>>> On Sun, May 12, 2013 at 07:18:57AM +0000, Romascanu, Dan (Dan)
> wrote:
>>>>> Sorry,  I meant:
>>>>>=20
>>>>> which one of these two statements is true?
>>>>>=20
>>>>>=20
>>>>> (Juergen) My understanding was that on systems that only have
>>>> , the  configuration data store is persistent.
>>>>>=20
>>>>> (Andy) All NETCONF devices have persistent storage of the
> running
>>>> configuration.
>>>>>=20
>>>>=20
>>>> Both statement can both be true. ;-) The problem is to find the
> relevant
>>>> pieces of text in the RFCs that talk about persistence since
> apparently
>>>> this is where some people are confused.
>>>>=20
>>>> RFC 6241 says for example:
>>>>=20
>>>>   o  configuration datastore: The datastore holding the complete
> set of
>>>>      configuration data that is required to get a device from its
>>>>      initial default state into a desired operational state.
>>>>=20
>>>> While this does not say 'persist', one might argue that
> persistence is
>>>> kind of implied in order to "get a device from its initial default
> state
>>>> into a desired operational state". And the startup datastore
> really is a
>>>> special feature:
>>>>=20
>>>>   o  startup configuration datastore: The configuration datastore
>>>>      holding the configuration loaded by the device when it
> boots.
>>>>      Only present on devices that separate the startup
> configuration
>>>>      datastore from the running configuration datastore.
>>>>=20
>>>> Even without a startup, your running datastore still persists
> since it
>>>> is a configuration datastore.
>>>>=20
>>>>   o  running configuration datastore: A configuration datastore
> holding
>>>>      the complete configuration currently active on the device.
> The
>>>>      running configuration datastore always exists.
>>>>=20
>>>> NETCONF was designed to modify configuration data and
> configuration data
>>>> usually persists (otherwise we would simply talk about writable
>>>> operational state, the stuff i2rs people are working on).
>>>>=20
>>>> /js
>>>>=20
>>>=20
>>> [[DR]] So the practical way to formulate the requirement would be:
>>>=20
>>> Any device that supports NETCONF MUST implement the running
> configuration
>>> datastore in persistent memory.
>>=20
>> I would say:
>>=20
>>  The startup datastore MUST be persistent.
>>=20
>>  If startup is implemented, running MUST NOT be persistent.
>>  If startup is not implemented, running MUST be persitent.
>>=20
>>  The candidate datastore MUST be persitent.
>>=20
>>=20
>> /martin
>>=20
>=20
>=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  Thu May 16 05:17: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 1BAC321F92F5 for ; Thu, 16 May 2013 05:17:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.266
X-Spam-Level: 
X-Spam-Status: No, score=-1.266 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=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 IyVwdsBSJtO5 for ; Thu, 16 May 2013 05:17:15 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 1F43421F92EC for ; Thu, 16 May 2013 05:17:15 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 3C354140342; Thu, 16 May 2013 14:17:13 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1368706633; bh=RgUmxNaQRxgglRZfV6klYipoqL+X5LlvjLVRmQSL9kA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=YcglDPbSrfVkhPBeBTuln4IwMOI3J7F/rqxj2ndqHBOSy/5gKHUh0dvS3hkz3oYCX R8QE6fUihaR1SFXT8jeggv1KyOggD/JNuq+6xoBdrkAvHAjtO7T6vXNc7bPIUVSr5e CP5NWinjEEqMZKHM2yQRJPVjhlHNUmy3cVSo/OhQ=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: <20130516.135529.196380910.mbj@tail-f.com>
Date: Thu, 16 May 2013 14:17:12 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <20130516.130204.348297528.mbj@tail-f.com>  <20130516.135529.196380910.mbj@tail-f.com>
To: Martin Bjorklund 
X-Mailer: Apple Mail (2.1503)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] What does unknown-statement2 represent in YANG grammar?
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, 16 May 2013 12:17:16 -0000

On May 16, 2013, at 1:55 PM, Martin Bjorklund  wrote:

> Ladislav Lhotka  wrote:
>>=20
>> On May 16, 2013, at 1:02 PM, Martin Bjorklund  wrote:
>>=20
>>> Andy Bierman  wrote:
>>>> .....
>>>>=20
>>>>>=20
>>>>> This is not how it works.  6020 says:
>>>>>=20
>>>>>  The substatements of an extension are defined by the extension,
>>>>>  using some mechanism outside the scope of this specification.
>>>>>  Syntactically, the substatements MUST be YANG statements, or also
>>>>>  defined using "extension" statements.  YANG statements in
>>>>>  extensions MUST follow the syntactical rules in Section 12
>>>>>=20
>>>>>=20
>>>> 6020 also says:
>>>>=20
>>>>=20
>>>> 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.
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>> A compiler that doesn't understand the extensions can still =
validate
>>>>> that the extension is defined, and that the argument is there if =
the
>>>>> extension needs one.
>>>>=20
>>>>=20
>>>>=20
>>>> Notice the words "the entire unknown-statement".
>>>> This clearly includes sub-statements within the entire =
unknown-statement.
>>>=20
>>> Yes.  But even if the compiler ignores them they have to follow the
>>> syntactic rules of 'unknown-statement', and Lada suggested that they
>>> didn't have to.
>>>=20
>>>> Since any YANG sub-statements present do not actually define any
>>>> YANG semantics I fail to see the value in checking the syntax =
completely.
>>>>=20
>>>>   extension: An extension attaches non-YANG semantics to =
statements.
>>>>     The extension statement defines new statements to express these
>>>>     semantics.
>>>>=20
>>>> Since the entire extension is clearly non-YANG semantics what is =
the
>>>> point of checking the completeness of the syntax for semantics that =
do not
>>>> apply in the foreign context?  Why is "type-stmt" mandatory for =
"leaf-stmt"?
>>>> Because when defining a real leaf, it is needed.  Used in an =
arbitrary
>>>> foreign context, maybe the 'type' is not needed and therefore not =
mandatory.
>>>=20
>>> Then you shouldn't piggy-back on the YANG statement 'leaf', but =
define
>>> your own extension 'andy:leaf' instead.
>>>=20
>>> You might think that this is too restrictive, but I think it is a
>>> feature.  Also, my experience with the restrictive syntax in 6020 is
>>> that it works pretty well.
>>=20
>> OK, let's have some fun after lunch:
>>=20
>> $ cat acme.yang
>> module acme {
>>  namespace "http://example.com/acme";
>>  prefix "acme";
>>  extension foo;
>>  acme:foo {
>>    identity bar;
>>    identity baz {
>>      base bar;
>>    }
>>  }
>> }
>>=20
>> $ pyang acme.yang
>> acme.yang:8: error: identity "bar" not found in module acme
>>=20
>> So pyang checks the definition of identity "baz" but ignores the =
definition of
>> "bar".
>=20
> Bug in pyang then.   It shouldn't check the "baz" identity.

OK, next one:

  acme:foo {
    extension bar;
    acme:bar;
  }

It is exactly as Andy said: inside an extension, we have to give up the =
standard semantics of YANG statements, so it makes very little sense to =
insist on their syntax.

Lada

>=20
>=20
> /martin

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





From j.schoenwaelder@jacobs-university.de  Thu May 16 05:18: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 181A421F92B2 for ; Thu, 16 May 2013 05:18:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.894
X-Spam-Level: 
X-Spam-Status: No, score=-102.894 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_15=0.6, 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 nLRVw-SeE3HH for ; Thu, 16 May 2013 05:18:03 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id AB68921F9223 for ; Thu, 16 May 2013 05:18:02 -0700 (PDT)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1146A20BEF; Thu, 16 May 2013 14:18:02 +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 dBrHFyzwqdy6; Thu, 16 May 2013 14:18: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 964E120BE8; Thu, 16 May 2013 14:18:01 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 763B9264F940; Thu, 16 May 2013 14:18:00 +0200 (CEST)
Date: Thu, 16 May 2013 14:18:00 +0200
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20130516121800.GA27961@elstar.local>
Mail-Followup-To: Ladislav Lhotka , "t.petch" , netmod@ietf.org
References: <9904FB1B0159DA42B0B887B7FA8119CA16A0BF@AZ-FFEXMB04.global.avaya.com>  <9904FB1B0159DA42B0B887B7FA8119CA16A0F8@AZ-FFEXMB04.global.avaya.com> <20130512.225459.503916152.mbj@tail-f.com> <002801ce5226$40dbbae0$4001a8c0@gateway.2wire.net> 
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] datastore persistence was Re: Last Call: 
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: Thu, 16 May 2013 12:18:08 -0000

On Thu, May 16, 2013 at 02:08:23PM +0200, Ladislav Lhotka wrote:
> 
> On May 16, 2013, at 1:00 PM, t.petch  wrote:
> 
> > I see this as important to clarify but fear it will fade away only to be
> > resurrected some months later, not the first such occurrence on this
> > list:-(
> > 
> > I see Martin's position as very reasonable,
> > 
> >> I would say:
> >> 
> >>  The startup datastore MUST be persistent.
> >> 
> >>  If startup is implemented, running MUST NOT be persistent.
> >>  If startup is not implemented, running MUST be persitent.
> >> 
> >>  The candidate datastore MUST be persitent.
> >> 
> >> /martin
> > 
> > just that it is not what the RFC say.  Rather, I see
> > 
> > :running not writable
> > not very interesting
> > 
> > :running :writable-running
> > edits can be made to :running [8.2.1]
> > how the rest of it got there is undefined
> > what happens when the device shuts down is undefined
> > 
> > :startup :running :writable-running
> > edits can be made to :running these will be lost on shutdown [8.7.1]
> > the initial state of :running is taken from :startup [8.7.1]
> > :startup cannot be edited but can be replaced by a copy from
> > :running[8.7.1]
> > 
> > :candidate :startup :running :writable-running
> > edits can be made to :running these will be lost on shutdown [8.7.1]
> > the initial state of :running is taken from :startup [8.7.1]
> > :startup cannot be edited but can be replaced by a copy from
> > :running[8.7.1]
> > edits can be made to :candidate [8.3.5.1]
> > :candidate can be committed to :running [8.3.4.1]
> > :candidate can be copied to :startup [8.3.5.1]
> > :startup can be copied to :candidate [8.7.5.1]
> > :candidate persistence across shutdowns is undefined
> > 
> > I believe that this should be resolved, agreed and documented, as it
> > affects interoperability.
> 
> I agree.
> 
> Also, the idea of sharing some persistent data between NETCONF and SNMP leads to the question whether the server is allowed to write to any config datastore and, if yes, under what circumstances and rules. It should certainly observe locks, but there can be other problems. For instance, if the server modifies candidate on its own, it could happen that a low-privileged client won't be able to perform a commit.
> 

With 'server' you mean 'SNMP agent'? If so, I would assume that the
SNMP agent simply acts like any other NETCONF client. Implementations
may use short-cuts as long as they lead to the same behaviour.

That said, I think this whole discussion belongs to the NETCONF
working group more than the NETMOD working group.

/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  Thu May 16 05:34: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 8529621F8EC6 for ; Thu, 16 May 2013 05:34:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.096
X-Spam-Level: 
X-Spam-Status: No, score=-1.096 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=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 N52A1ZQdizwk for ; Thu, 16 May 2013 05:34:23 -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 5146921F8F6D for ; Thu, 16 May 2013 05:34:22 -0700 (PDT)
Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 4D8F21200D2F; Thu, 16 May 2013 14:34:21 +0200 (CEST)
Date: Thu, 16 May 2013 14:34:20 +0200 (CEST)
Message-Id: <20130516.143420.347593051.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References:  <20130516.135529.196380910.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] What does unknown-statement2 represent in YANG grammar?
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, 16 May 2013 12:34:29 -0000

Ladislav Lhotka  wrote:
> 
> On May 16, 2013, at 1:55 PM, Martin Bjorklund  wrote:
> 
> > Ladislav Lhotka  wrote:
> >> 
> >> On May 16, 2013, at 1:02 PM, Martin Bjorklund  wrote:
> >> 
> >>> Andy Bierman  wrote:
> >>>> .....
> >>>> 
> >>>>> 
> >>>>> This is not how it works.  6020 says:
> >>>>> 
> >>>>>  The substatements of an extension are defined by the extension,
> >>>>>  using some mechanism outside the scope of this specification.
> >>>>>  Syntactically, the substatements MUST be YANG statements, or also
> >>>>>  defined using "extension" statements.  YANG statements in
> >>>>>  extensions MUST follow the syntactical rules in Section 12
> >>>>> 
> >>>>> 
> >>>> 6020 also 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.
> >>>> 
> >>>> 
> >>>> 
> >>>> 
> >>>>> A compiler that doesn't understand the extensions can still validate
> >>>>> that the extension is defined, and that the argument is there if the
> >>>>> extension needs one.
> >>>> 
> >>>> 
> >>>> 
> >>>> Notice the words "the entire unknown-statement".
> >>>> This clearly includes sub-statements within the entire unknown-statement.
> >>> 
> >>> Yes.  But even if the compiler ignores them they have to follow the
> >>> syntactic rules of 'unknown-statement', and Lada suggested that they
> >>> didn't have to.
> >>> 
> >>>> Since any YANG sub-statements present do not actually define any
> >>>> YANG semantics I fail to see the value in checking the syntax completely.
> >>>> 
> >>>>   extension: An extension attaches non-YANG semantics to statements.
> >>>>     The extension statement defines new statements to express these
> >>>>     semantics.
> >>>> 
> >>>> Since the entire extension is clearly non-YANG semantics what is the
> >>>> point of checking the completeness of the syntax for semantics that do not
> >>>> apply in the foreign context?  Why is "type-stmt" mandatory for
> >>>> "leaf-stmt"?
> >>>> Because when defining a real leaf, it is needed.  Used in an arbitrary
> >>>> foreign context, maybe the 'type' is not needed and therefore not
> >>>> mandatory.
> >>> 
> >>> Then you shouldn't piggy-back on the YANG statement 'leaf', but define
> >>> your own extension 'andy:leaf' instead.
> >>> 
> >>> You might think that this is too restrictive, but I think it is a
> >>> feature.  Also, my experience with the restrictive syntax in 6020 is
> >>> that it works pretty well.
> >> 
> >> OK, let's have some fun after lunch:
> >> 
> >> $ cat acme.yang
> >> module acme {
> >>  namespace "http://example.com/acme";
> >>  prefix "acme";
> >>  extension foo;
> >>  acme:foo {
> >>    identity bar;
> >>    identity baz {
> >>      base bar;
> >>    }
> >>  }
> >> }
> >> 
> >> $ pyang acme.yang
> >> acme.yang:8: error: identity "bar" not found in module acme
> >> 
> >> So pyang checks the definition of identity "baz" but ignores the definition
> >> of
> >> "bar".
> > 
> > Bug in pyang then.   It shouldn't check the "baz" identity.
> 
> OK, next one:
> 
>   acme:foo {
>     extension bar;
>     acme:bar;
>   }

I don't see the problem.  If 'bar' is not defined as an extension in
the acme module, this is an error.  If 'bar' is defined, it is fine.

> It is exactly as Andy said: inside an extension, we have to give up the
> standard semantics of YANG statements, so it makes very little sense to insist
> on their syntax.

Let's agree to disagree maybe.


/martin


From lhotka@nic.cz  Thu May 16 05:43: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 3CC5C21F8BDE for ; Thu, 16 May 2013 05:43:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.519
X-Spam-Level: 
X-Spam-Status: No, score=-1.519 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 q470LJBxYpKT for ; Thu, 16 May 2013 05:43:13 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 40D9C21F8BBC for ; Thu, 16 May 2013 05:43: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 510BB140342; Thu, 16 May 2013 14:43:12 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1368708192; bh=YTIeJhmYprlgZYDO7S6ax1oWzYPUPEHUj52wOQw3zXE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=mgd0uJSgHiV2+CY0pAYJVotfW6bBU/Y5wud23ik9mYAklCwxqTHwZBpxa/gmiypSN /T/GxMYy2HoVzyk+3xRUta8STrQeeHN36nzEkxGHrYP75AHxSIrzz6SixhkxLPntFi xU//OnaGw6dO/NYfQ1iBj3Pnjqu3NFlqDroaAlEk=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: <20130516121800.GA27961@elstar.local>
Date: Thu, 16 May 2013 14:43:10 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <3935F43F-331E-4F9E-9A80-86EB2957B64F@nic.cz>
References: <9904FB1B0159DA42B0B887B7FA8119CA16A0BF@AZ-FFEXMB04.global.avaya.com>  <9904FB1B0159DA42B0B887B7FA8119CA16A0F8@AZ-FFEXMB04.global.avaya.com> <20130512.225459.503916152.mbj@tail-f.com> <002801ce5226$40dbbae0$4001a8c0@gateway.2wire.net>  <20130516121800.GA27961@elstar.local>
To: Juergen Schoenwaelder 
X-Mailer: Apple Mail (2.1503)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] datastore persistence was Re: Last Call: 
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, 16 May 2013 12:43:14 -0000

On May 16, 2013, at 2:18 PM, Juergen Schoenwaelder =
 wrote:

> On Thu, May 16, 2013 at 02:08:23PM +0200, Ladislav Lhotka wrote:
>>=20
>> On May 16, 2013, at 1:00 PM, t.petch  wrote:
>>=20
>>> I see this as important to clarify but fear it will fade away only =
to be
>>> resurrected some months later, not the first such occurrence on this
>>> list:-(
>>>=20
>>> I see Martin's position as very reasonable,
>>>=20
>>>> I would say:
>>>>=20
>>>> The startup datastore MUST be persistent.
>>>>=20
>>>> If startup is implemented, running MUST NOT be persistent.
>>>> If startup is not implemented, running MUST be persitent.
>>>>=20
>>>> The candidate datastore MUST be persitent.
>>>>=20
>>>> /martin
>>>=20
>>> just that it is not what the RFC say.  Rather, I see
>>>=20
>>> :running not writable
>>> not very interesting
>>>=20
>>> :running :writable-running
>>> edits can be made to :running [8.2.1]
>>> how the rest of it got there is undefined
>>> what happens when the device shuts down is undefined
>>>=20
>>> :startup :running :writable-running
>>> edits can be made to :running these will be lost on shutdown [8.7.1]
>>> the initial state of :running is taken from :startup [8.7.1]
>>> :startup cannot be edited but can be replaced by a copy from
>>> :running[8.7.1]
>>>=20
>>> :candidate :startup :running :writable-running
>>> edits can be made to :running these will be lost on shutdown [8.7.1]
>>> the initial state of :running is taken from :startup [8.7.1]
>>> :startup cannot be edited but can be replaced by a copy from
>>> :running[8.7.1]
>>> edits can be made to :candidate [8.3.5.1]
>>> :candidate can be committed to :running [8.3.4.1]
>>> :candidate can be copied to :startup [8.3.5.1]
>>> :startup can be copied to :candidate [8.7.5.1]
>>> :candidate persistence across shutdowns is undefined
>>>=20
>>> I believe that this should be resolved, agreed and documented, as it
>>> affects interoperability.
>>=20
>> I agree.
>>=20
>> Also, the idea of sharing some persistent data between NETCONF and =
SNMP leads to the question whether the server is allowed to write to any =
config datastore and, if yes, under what circumstances and rules. It =
should certainly observe locks, but there can be other problems. For =
instance, if the server modifies candidate on its own, it could happen =
that a low-privileged client won't be able to perform a commit.
>>=20
>=20
> With 'server' you mean 'SNMP agent'? If so, I would assume that the

I mean general rules for changes in any configuration datastore that =
take place outside a client's session.

> SNMP agent simply acts like any other NETCONF client. Implementations
> may use short-cuts as long as they lead to the same behaviour.

Sure, if this was the rule and no other changes were allowed, then it =
would be fine. It could still expose the known problems with shared =
candidate though.

>=20
> That said, I think this whole discussion belongs to the NETCONF
> working group more than the NETMOD working group.

Oh yes, I didn't notice it was in NETCONF.

Lada

>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         

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





From lhotka@nic.cz  Thu May 16 05:51: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 947BB21F937B for ; Thu, 16 May 2013 05:51:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.208
X-Spam-Level: 
X-Spam-Status: No, score=-1.208 tagged_above=-999 required=5 tests=[AWL=-0.409, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_64=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 sdGOyWbfsbIc for ; Thu, 16 May 2013 05:51: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 7E51621F9375 for ; Thu, 16 May 2013 05:51:42 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id A1C21140342; Thu, 16 May 2013 14:51:41 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1368708701; bh=pch9D8SE3zC+OfolGqD1sG7wliYW+ZQP6Y922+oyXdo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=xyQDPTnLIEY8D3kAfynO4X3NAW2tCPAqzpJvjwWx1/604zg5bwMpCK3KGus2fHgFD rozlWVuweAZ6SijjqEHUYYotbRDFEHzQvtbISCp7JKNHkp7dwLbQKKSR+1pg6vtsYi vxJKlKOj4xDfKz0aC2su74lYn0ScKOO+sOAqXf+U=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: <20130516113033.GA27666@elstar.local>
Date: Thu, 16 May 2013 14:51:41 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <8BFCB9EE-B248-457B-8AB2-653461C02717@nic.cz>
References: <20130515140353.15940.12042.idtracker@ietfa.amsl.com> <002901ce5226$412fa740$4001a8c0@gateway.2wire.net> <20130516113033.GA27666@elstar.local>
To: Juergen Schoenwaelder 
X-Mailer: Apple Mail (2.1503)
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-interfaces-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: Thu, 16 May 2013 12:51:43 -0000

On May 16, 2013, at 1:30 PM, Juergen Schoenwaelder =
 wrote:

> On Thu, May 16, 2013 at 12:10:21PM +0100, t.petch wrote:
>> Mmmm
>>=20
>> Separate lists for configutation and state is a big change and I am =
not
>> sure whom it benefits.
>>=20
>> Being able to set/get/view a table row with most if not all the =
relevant
>> information for an interface is so simple that it seems perverse to
>> split it into two with two separate keys with seemingly no required
>> relationship between them.
>>=20
>> Likewise, having the information together in the YANG module makes it
>> easier to find, whatever tool is used to view the module.
>>=20
>> This split seems more like a political statement, state and
>> configuration are different and the appearance of this must override
>> other considerations.
>>=20
>=20
> Tom,
>=20
> I think you are drawing a picture that is overly simplified given
> today's hardware. For example, routers and switches have often hot
> swappable interface hardware and as such configuration state and
> operational state can be quite different. We need to be able to
> properly express that. Furthermore, some interfaces are related to
> physical interfaces (that come and og when the physical hardware
> changes) and logical interfaces (that come and go as part of
> configuration changes). This all needs to be dealt with properly and
> the -10 approach did not really allow to do this properly.
>=20
> As another example, consider the IP configuration extension. There is
> a clear difference between IP addresses configured on an interface and
> the IP addresses operationally present on an interface. Having two
> separate trees allows to deal with this properly.
>=20
> Given this, as technical contributor, I completely disagree with your
> statement that "this split seems more like a political statement".

I agree with Juergen, it was not a political statement but a technical =
necessity, given the current state of affairs. It the state data and =
statistics for physical interfaces are under a config=3Dtrue list entry =
then either

(i) they are not present until a client creates the config entry for the =
particular interface,

or

(ii) the server writes this entry on its own.

I don't think (ii) should be allowed, and even if it was, what happens =
if a client deletes the entry?

Lada
=20
>=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 ietfc@btconnect.com  Thu May 16 06:54: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 5338421F91B8 for ; Thu, 16 May 2013 06:54:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.292
X-Spam-Level: 
X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=-0.293, BAYES_00=-2.599, J_CHICKENPOX_15=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 mzWXkMGAwtAX for ; Thu, 16 May 2013 06:54:19 -0700 (PDT)
Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0252.outbound.messaging.microsoft.com [213.199.154.252]) by ietfa.amsl.com (Postfix) with ESMTP id 4F84121F9133 for ; Thu, 16 May 2013 06:54:16 -0700 (PDT)
Received: from mail104-db9-R.bigfish.com (10.174.16.240) by DB9EHSOBE031.bigfish.com (10.174.14.94) with Microsoft SMTP Server id 14.1.225.23; Thu, 16 May 2013 13:54:15 +0000
Received: from mail104-db9 (localhost [127.0.0.1])	by mail104-db9-R.bigfish.com (Postfix) with ESMTP id 45997240B69; Thu, 16 May 2013 13:54:15 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.249.213; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0710HT002.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -15
X-BigFish: PS-15(zz98dI9371I542I1432Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275bh8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh304l1d11m1155h)
Received: from mail104-db9 (localhost.localdomain [127.0.0.1]) by mail104-db9 (MessageSwitch) id 1368712453233539_17292; Thu, 16 May 2013 13:54:13 +0000 (UTC)
Received: from DB9EHSMHS003.bigfish.com (unknown [10.174.16.253])	by mail104-db9.bigfish.com (Postfix) with ESMTP id 90E0E34005C; Thu, 16 May 2013 13:54:11 +0000 (UTC)
Received: from AM2PRD0710HT002.eurprd07.prod.outlook.com (157.56.249.213) by DB9EHSMHS003.bigfish.com (10.174.14.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 16 May 2013 13:54:10 +0000
Received: from AMXPRD0111HT004.eurprd01.prod.exchangelabs.com (157.56.250.117) by pod51017.outlook.com (10.255.165.37) with Microsoft SMTP Server (TLS) id 14.16.311.1; Thu, 16 May 2013 13:54:07 +0000
Message-ID: <009901ce523c$15ae8f80$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Juergen Schoenwaelder 
References: <20130515140353.15940.12042.idtracker@ietfa.amsl.com> <002901ce5226$412fa740$4001a8c0@gateway.2wire.net> <20130516113033.GA27666@elstar.local> <003d01ce522a$a288c720$4001a8c0@gateway.2wire.net> <20130516120659.GA27915@elstar.local>
Date: Thu, 16 May 2013 14:48:35 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.250.117]
X-OriginatorOrg: btconnect.com
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-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: Thu, 16 May 2013 13:54:25 -0000

----- Original Message -----
From: "Juergen Schoenwaelder" 
To: "t.petch" 
Cc: 
Sent: Thursday, May 16, 2013 1:06 PM
> On Thu, May 16, 2013 at 12:43:37PM +0100, t.petch wrote:
>
> Please read the document and then we can discuss on the basis of what
> is in the document.

I did, which means that I don't understand it.

One example.  If I may hark back to SNMP, then a reference to ifName is
unique whereas in YANG, a reference to 'name' is not.  Thus this I-D
defines two name objects, with no relationship defined in the model
between them, so when it says

       | name                             | ifName                 |

does it mean one, or the other or both or sometimes?  In YANG, you
really SHOULD say
/if:interfaces/if:interface/if:name
or some such, and not just name

Or,
  "An interface is identified by its name, which is unique within the
   server.  "
well there are two name objects, so this does not make sense to me.

Or
/if:interfaces/if:interface/if:name
is rw while
/if:interfaces-state/if:interface/if:name
is ro and there is a "separate list for the operational state of all
interfaces".  All interfaces, I note, so what happens when I make a typo
and write to
/if:interfaces/if:interface/if:name
a name that is not in
/if:interfaces-state/if:interface/if:name

'name' is key, literally and metaphorically, so not understanding that,
well, I don't understand:-(

Tom Petch

> /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  Thu May 16 07:45: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 B834C21F8F87 for ; Thu, 16 May 2013 07:45:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.857
X-Spam-Level: 
X-Spam-Status: No, score=-102.857 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_15=0.6, 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 ReOXsaJZ9Ccb for ; Thu, 16 May 2013 07:44:55 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 47E6721F8F43 for ; Thu, 16 May 2013 07:44:55 -0700 (PDT)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4F47B20D03; Thu, 16 May 2013 16:44:54 +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 2UHp_Us49-Aq; Thu, 16 May 2013 16:44:54 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BEB9F20CFA; Thu, 16 May 2013 16:44:53 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 2F1F9264FEA9; Thu, 16 May 2013 16:44:50 +0200 (CEST)
Date: Thu, 16 May 2013 16:44:50 +0200
From: Juergen Schoenwaelder 
To: "t.petch" 
Message-ID: <20130516144450.GA28294@elstar.local>
Mail-Followup-To: "t.petch" , netmod@ietf.org
References: <20130515140353.15940.12042.idtracker@ietfa.amsl.com> <002901ce5226$412fa740$4001a8c0@gateway.2wire.net> <20130516113033.GA27666@elstar.local> <003d01ce522a$a288c720$4001a8c0@gateway.2wire.net> <20130516120659.GA27915@elstar.local> <009901ce523c$15ae8f80$4001a8c0@gateway.2wire.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <009901ce523c$15ae8f80$4001a8c0@gateway.2wire.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-11.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: Thu, 16 May 2013 14:45:00 -0000

On Thu, May 16, 2013 at 02:48:35PM +0100, t.petch wrote:
> ----- Original Message -----
> From: "Juergen Schoenwaelder" 
> To: "t.petch" 
> Cc: 
> Sent: Thursday, May 16, 2013 1:06 PM
> > On Thu, May 16, 2013 at 12:43:37PM +0100, t.petch wrote:
> >
> > Please read the document and then we can discuss on the basis of what
> > is in the document.
> 
> I did, which means that I don't understand it.
> 
> One example.  If I may hark back to SNMP, then a reference to ifName is
> unique whereas in YANG, a reference to 'name' is not.  Thus this I-D
> defines two name objects, with no relationship defined in the model
> between them, so when it says
> 
>        | name                             | ifName                 |
> 
> does it mean one, or the other or both or sometimes?  In YANG, you
> really SHOULD say
> /if:interfaces/if:interface/if:name
> or some such, and not just name

That ambiguity was already mentioned and will be fixed.

In SNMP, an ifName may refer to multiple interfaces. See RFC 2863. Hence
I do not understand your uniqueness question.
 
> Or,
>   "An interface is identified by its name, which is unique within the
>    server.  "
> well there are two name objects, so this does not make sense to me.

I think the relationship is explained in the description statement of
/interfaces/name:

         For physical interfaces, this leaf is the device-specific
         name of the interface.  The 'config false' list
         /interfaces-state/interface contains the currently
         existing interfaces on the device.

         When a configured logical interface is created by the
         system, it is instantiated in the
         /interface-state/interface list.  Since the name in that
         list MAY be mapped to ifName by an implementation, such an
         implementation MUST restrict the allowed values for this
         leaf so that it matches the restrictions of ifName.

Perhaps the 1st sentence in the second paragraph can be made clearer
by saying:

         When a configured logical interface is created by the
         system, it is instantiated with the same name in the
         /interface-state/interface list.

> Or
> /if:interfaces/if:interface/if:name
> is rw while
> /if:interfaces-state/if:interface/if:name
> is ro and there is a "separate list for the operational state of all
> interfaces".  All interfaces, I note, so what happens when I make a typo
> and write to
> /if:interfaces/if:interface/if:name
> a name that is not in
> /if:interfaces-state/if:interface/if:name
>
> 'name' is key, literally and metaphorically, so not understanding that,
> well, I don't understand:-(

Again, I think this situation is explained in the description
statement of /interfaces/name.

        If a client tries to create configuration for a physical
        interface that is not present, the server MAY reject the
        request, if the implementation does not support
        pre-provisioning of interfaces, or if the name refers to
        an interface that can never exist in the system.
        A NETCONF server MUST reply with an rpc-error with the
        error-tag 'invalid-value' in this case.

/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  Thu May 16 09:05:39 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 2B57A21F9227 for ; Thu, 16 May 2013 09:05:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.155
X-Spam-Level: 
X-Spam-Status: No, score=-103.155 tagged_above=-999 required=5 tests=[AWL=0.094, 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 SS2pjIrA3Krz for ; Thu, 16 May 2013 09:05:34 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C536A21F90DF for ; Thu, 16 May 2013 09:05:33 -0700 (PDT)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id A43F720C09; Thu, 16 May 2013 18:05:32 +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 9wX8HZLjlpWm; Thu, 16 May 2013 18:05:32 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DB63820C08; Thu, 16 May 2013 18:05:31 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id CBD0326502F4; Thu, 16 May 2013 18:05:28 +0200 (CEST)
Date: Thu, 16 May 2013 18:05:28 +0200
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20130516160528.GB28482@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] comments on draft-ietf-netmod-system-mgmt-06
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: Thu, 16 May 2013 16:05:39 -0000

Hi,

here is a review of draft-ietf-netmod-system-mgmt-06.

a) The abstract needs work. I do not think the current sentence is
   correct nor do I think this is a useful description of the scope
   covered.

b) The same applies to the Introduction - this does not seem to be
   about a "management system". The bullets listed also do not line up
   well with what is now in the document, perhaps it should be

   o  system identification configuration and monitoring

   o  system time-of-day configuration and monitoring

   o  user authentication configuration

   o  local users configuration

   o  dns resolver configuration

   o  system control operations (shutdown, restart, setting time)

   (not sure monitoring is a good word but I have no better proposal)

   I also do not see what the definition of a term requires a new
   subsubsection (just get rid of the section header
   '1.1.1. Terms'). 

   The definition of 'system' is also rather unclear to me: "the
   embodiment of the entire set of management interfaces". Nor does
   the I-D do anything with managing physical entities. I think there
   should be a better definition or no definition at all.

   Any other terms that need to be 'imported' from other documents?

c) Update section 1.2 to the new format which supports * for lists and
   regenerate the tree figures. (Martin knows what I mean.)

d) sec 2.1:

   s/operational data/operational state data/ (perhaps consider
   importing a definition for operational state)

e) Should section 2 not also have a subsection talking about DNS
   resolver configuration and a subsection talking about basic system
   control operations?

f) Even though there are only a few config false data nodes, I would
   seriously consider to move them to separate them from the config
   true data nodes.

g) Why are algorithm and key-data optional for an SSH key?

h) sec 3.5.2:

   s/system\/ auth/system\/auth/

i) First sentence of the module description may need improvements.

j) p12:

   s/correct/accepted/

k) What kind of device would not announce the feature "authentication"?
   Do not all NETCONF transports require some form of authentication?

l) The feature local-users is bound to password authentication. Can I
   not have a system with local user accounts that only permits SSH
   public key authentication? (This is actually how I run all my
   servers - we completely disable password authentication. I guess
   this is not uncommon.)

m) Note that system/contact and system/location only map to SNMP if
   you are lucky due to the different character sets involved. With
   UTF8, also the size restriction does not mean the same. Perhaps
   remove the size restriction completely and add explicit text that
   implementations mapping this to SNMP objects may restrict the size
   and the allowed set of characters. (In fact DisplayString has even
   more details.)

n) Should boot-datetime really be the time the NETCONF server last
   restarted? I would be more interested to know when the system last
   restarted. The NETCONF restart time (if ever needed) should really
   be part of the netconf-state data model (i.e. RFC 6022 bis).

o) The ntp objects allow to configure multiple IP addresses and each
   one can be disabled individually. Is this really needed? If so, why
   is this not needed for DNS resolvers?

p) The ntp objects do not allow me to configure a port number. Should
   we not generally allow to configure complete transport layer
   endpoints?

q) Should the dns container be called resolver or dns-resolver?

r) The model does not allow me to configure a DNS server using a
   non-standard port number. Should we not generally allow to
   configure complete transport layer endpoints?

s) I think timeout and attempts are not clear enough defined. Consider
   a server that never responds. With N attempts and a timeout t, do I
   get N attempts with a timeout of t for each attempt or a timeout of
   t with N attempts? Looking at the bind header files (the man pages
   are also unclear), it seems bind does N attempts with a timeout of
   t for each attempt.
   
   The same applies to the timeout and attempts definitions for radius.

t) The radius server list is keyed by an address. Now with Radius,
   there is the official default port number and there was a different
   port number widely used before the official got allocated. Hence,
   in practice, both are used. So I like to be able to configure
   things such that the system tries both. However, this won't work
   because the list is keyed by the address. I can't have this:

   
     
1.1.1.1

     
       1812
     
   
   
     
1.1.1.1

     
       1645
     
   

   Note that this also applies to the other lists keyed by simply an
   address. (We may have to introduce names to refer to the endpoints
   if we want a simple key and transport extensibility).

   I also find the separation of the udp port from the address
   strange.  I can't have something like this either (if I want to add
   tcp support):

   
     
1.1.1.1

     
       1812
     
   
   
     
1.1.1.1

     
       1645
     
   

   For me, it would make more sense leave the address and port number
   together and to support something like this.

   
     
       
         
1.1.1.1

         1812
       
       
         
1.1.1.1

         1645
       
       
         
1.1.1.1

         1645
       
     
   
       
u) Please update the security considerations boilerplate so that we
   have an explicit reference to the access control model.

v) Where you list readable subtrees, I think it is fair to explicitly
   mention the local users subtree and the passwords contained in that
   subtree.

w) Are really all references normative? For example, RFC 6557 or RFC
   3688?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From andy@yumaworks.com  Thu May 16 09:08: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 6241511E8100 for ; Thu, 16 May 2013 09:08:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.178
X-Spam-Level: 
X-Spam-Status: No, score=-1.178 tagged_above=-999 required=5 tests=[AWL=-0.401, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6c0JZjan-Sqf for ; Thu, 16 May 2013 09:08:07 -0700 (PDT)
Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id BAAC011E80FB for ; Thu, 16 May 2013 09:08:07 -0700 (PDT)
Received: by mail-ie0-f180.google.com with SMTP id ar20so6674092iec.25 for ; Thu, 16 May 2013 09:08:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=tePBBHCVNIAWgdOIyPRgIYJLRgxWRI31wca+S8102DE=; b=W2mQYB/Yir1DaY57gyle9aFgencKIUN6cXyJzwsvjSKxf+wJjiyJU5aMI21Rx5+Vw+ 8fHn4+vkp+rjyWRW63cu9DfWxG2UzyA7/2/tugXBlgljyarkGa6qa5BKCX7x5V2qWrYR faC8l+10IU/QP9NnCTH6vcp1lR2LRMBjMCRYeLtA7XtzWrlgQ+jYkillVEczDIt7z8Qo QWwyv0bRbpiq3BAOkU1m56vLzcjm8vNJIggPcmUQuiHS/MxdS2tQw4EQj/ynzKvvdJO+ QV35h2tvcYVfXZbyea7A7QBSvzoc5XpP6ArFOGoEkY5nV5hERTtOHUwg+y+mvrJ793J3 BEHw==
MIME-Version: 1.0
X-Received: by 10.42.164.193 with SMTP id h1mr20227111icy.56.1368720487149; Thu, 16 May 2013 09:08:07 -0700 (PDT)
Received: by 10.231.120.74 with HTTP; Thu, 16 May 2013 09:08:06 -0700 (PDT)
In-Reply-To: <20130516.135529.196380910.mbj@tail-f.com>
References:  <20130516.130204.348297528.mbj@tail-f.com>  <20130516.135529.196380910.mbj@tail-f.com>
Date: Thu, 16 May 2013 09:08:06 -0700
Message-ID: 
From: Andy Bierman 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=90e6ba6e8b5e6f071e04dcd81279
X-Gm-Message-State: ALoCoQketum1uvfN6wkKrY0q2gw826pVJS7RvIWFz8FYiLEwDbTQ26TvLCfKaJYbi7Jjw/z50iQx
Cc: netmod@ietf.org
Subject: Re: [netmod] What does unknown-statement2 represent in YANG grammar?
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, 16 May 2013 16:08:08 -0000

--90e6ba6e8b5e6f071e04dcd81279
Content-Type: text/plain; charset=ISO-8859-1

...

> > $ cat acme.yang
> > module acme {
> >   namespace "http://example.com/acme";
> >   prefix "acme";
> >   extension foo;
> >   acme:foo {
> >     identity bar;
> >     identity baz {
> >       base bar;
> >     }
> >   }
> > }
> >
> > $ pyang acme.yang
> > acme.yang:8: error: identity "bar" not found in module acme
> >
> > So pyang checks the definition of identity "baz" but ignores the
> definition of
> > "bar".
>
> Bug in pyang then.   It shouldn't check the "baz" identity.
>
>
Technically, identity-stmt is only allowed as a body-stmt and not allowed
within any other context, so there are no identities actually defined.

module acme {
  namespace "http://example.com/acme";
  prefix "acme";
  extension foo;
  acme:foo {
    identity bar;
    identity baz {
      base bar;
    }
  }
  acme:foo {
    extension bar;
    acme:bar;
  }
}

yangdump-pro generates an error:

Warning: no revision statements for module 'acme'
Error: Local module extension 'bar' not found
acme.yang:13.5: error(250): definition not found

The compiler does not ignore the contents.
It follows the ABNF and checks that each nested statement
is either YANG or a known extension.  Missing right brace
would be an error as well.

IMO, parsing the generic 'statement' structure is all
that is required of a compiler.  The extension-stmt is
capable of defining a generic leaf (type empty if no argument
and type string if argument present).  All the disputed mechanics
are actually defined by the statement separator, not the
extension-stmt.




>
> /martin
>


Andy

--90e6ba6e8b5e6f071e04dcd81279
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

...

> $ cat acme.yang

> module acme {

> =A0 namespace "http://example.com/acme";

> =A0 prefix "acme";

> =A0 extension foo;

> =A0 acme:foo {

> =A0 =A0 identity bar;

> =A0 =A0 identity baz {

> =A0 =A0 =A0 base bar;

> =A0 =A0 }

> =A0 }

> }

>

> $ pyang acme.yang

> acme.yang:8: error: identity "bar" not found in module acme<=
br>
>

> So pyang checks the definition of identity "baz" but ignores=
 the definition of

> "bar".



Bug in pyang then. =A0 It shouldn't check the "baz" identity.=




Technically, identity-stmt is only allowed as a body=
-stmt and not allowed
within any other context, so there are no i=
dentities actually defined.



module acme {
=A0 namespace "http://example.com/acme";
=
=A0 prefix "acme";
=A0 extension foo;
=A0 acm=
e:foo {


=A0 =A0 identity bar;
=A0 =A0 identity baz {
=A0 =
=A0 =A0 base bar;
=A0 =A0 }
=A0 }
=A0 acme:fo=
o {
=A0 =A0 extension bar;
=A0 =A0 acme:bar;
=
=A0 }
}



yangdump-pro generates an error:

Warning: no revision statements for module 'acme'
Error: Local module extension 'bar' not found
acme.yang:=
13.5: error(250): definition not found



The compiler does not ignore the contents.
<=
div>It follows the ABNF and checks that each nested statement
is =
either YANG or a known extension. =A0Missing right brace
would be=
 an error as well.



IMO, parsing the generic 'statement' structure =
is all
that is required of a compiler. =A0The extension-stmt is
capable of defining a generic leaf (type empty if no argument

and type string if argument present). =A0All the disputed mechanics
are actually defined by the statement separator, not the
=
extension-stmt.=A0


=A0




/martin




Andy


--90e6ba6e8b5e6f071e04dcd81279--

From xiangli@seguesoft.com  Thu May 16 18:19: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 4BA4B11E80D9 for ; Thu, 16 May 2013 18:19:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=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 ub3jqEgFbeRf for ; Thu, 16 May 2013 18:19:42 -0700 (PDT)
Received: from p3plsmtpa06-04.prod.phx3.secureserver.net (p3plsmtpa06-04.prod.phx3.secureserver.net [173.201.192.105]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC5A11E80D3 for ; Thu, 16 May 2013 18:19:41 -0700 (PDT)
Received: from [192.168.2.16] ([98.212.151.151]) by p3plsmtpa06-04.prod.phx3.secureserver.net with  id cpKe1l00r3GEayi01pKfC7; Thu, 16 May 2013 18:19:40 -0700
Message-ID: <519585AC.8060107@seguesoft.com>
Date: Thu, 16 May 2013 20:19:40 -0500
From: Xiang Li 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: netmod@ietf.org
References: <20130515140353.15940.12042.idtracker@ietfa.amsl.com> <002901ce5226$412fa740$4001a8c0@gateway.2wire.net> <20130516113033.GA27666@elstar.local> <003d01ce522a$a288c720$4001a8c0@gateway.2wire.net> <20130516120659.GA27915@elstar.local> <009901ce523c$15ae8f80$4001a8c0@gateway.2wire.net> <20130516144450.GA28294@elstar.local>
In-Reply-To: <20130516144450.GA28294@elstar.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-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, 17 May 2013 01:19:48 -0000

On 5/16/2013 9:44 AM, Juergen Schoenwaelder wrote:
> On Thu, May 16, 2013 at 02:48:35PM +0100, t.petch wrote:
>> ----- Original Message -----
>> From: "Juergen Schoenwaelder" 
>> To: "t.petch" 
>> Cc: 
>> Sent: Thursday, May 16, 2013 1:06 PM
>>> On Thu, May 16, 2013 at 12:43:37PM +0100, t.petch wrote:
>>>
>>> Please read the document and then we can discuss on the basis of what
>>> is in the document.
>> I did, which means that I don't understand it.
>>
>> One example.  If I may hark back to SNMP, then a reference to ifName is
>> unique whereas in YANG, a reference to 'name' is not.  Thus this I-D
>> defines two name objects, with no relationship defined in the model
>> between them, so when it says
>>
>>         | name                             | ifName                 |
>>
>> does it mean one, or the other or both or sometimes?  In YANG, you
>> really SHOULD say
>> /if:interfaces/if:interface/if:name
>> or some such, and not just name
> That ambiguity was already mentioned and will be fixed.
>
> In SNMP, an ifName may refer to multiple interfaces. See RFC 2863. Hence
> I do not understand your uniqueness question.
>   
>> Or,
>>    "An interface is identified by its name, which is unique within the
>>     server.  "
>> well there are two name objects, so this does not make sense to me.
> I think the relationship is explained in the description statement of
> /interfaces/name:
>
>           For physical interfaces, this leaf is the device-specific
>           name of the interface.  The 'config false' list
>           /interfaces-state/interface contains the currently
>           existing interfaces on the device.
>
>           When a configured logical interface is created by the
>           system, it is instantiated in the
>           /interface-state/interface list.  Since the name in that
>           list MAY be mapped to ifName by an implementation, such an
>           implementation MUST restrict the allowed values for this
>           leaf so that it matches the restrictions of ifName.
>
> Perhaps the 1st sentence in the second paragraph can be made clearer
> by saying:
>
>           When a configured logical interface is created by the
>           system, it is instantiated with the same name in the
>           /interface-state/interface list.


+1.

To make things clearer, I think it should worth pointing out  that for 
physical interfaces,
the /interfaces/interface/name has the same value as 
/interfaces-state/interface/name.
This should help clarify that there aren't two different keys for 
configured interfaces, be it
logical or physical.


>> Or
>> /if:interfaces/if:interface/if:name
>> is rw while
>> /if:interfaces-state/if:interface/if:name
>> is ro and there is a "separate list for the operational state of all
>> interfaces".  All interfaces, I note, so what happens when I make a typo
>> and write to
>> /if:interfaces/if:interface/if:name
>> a name that is not in
>> /if:interfaces-state/if:interface/if:name


The description of /interfaces container also says something about this.

      container interfaces {
        description
          "Interface configuration parameters.";

        list interface {
          key "name";

          description
            "The list of configured interfaces on the device.

             The operational state of an interface is available in the
             /interfaces-state/interface list.  If the configuration of a
             physical interface cannot be used by the system (e.g., the
             physical interface present is not matching the interface
             type), then the configuration is not applied to the physical
             interface shown in the /interfaces-state/interface list. If
             the the configuration of a logical interface cannot be used
             by the system, the configured interface is not instantiated
             in the /interfaces-state/interface list.";



>> 'name' is key, literally and metaphorically, so not understanding that,
>> well, I don't understand:-(
> Again, I think this situation is explained in the description
> statement of /interfaces/name.
>
>          If a client tries to create configuration for a physical
>          interface that is not present, the server MAY reject the
>          request, if the implementation does not support
>          pre-provisioning of interfaces, or if the name refers to
>          an interface that can never exist in the system.
>          A NETCONF server MUST reply with an rpc-error with the
>          error-tag 'invalid-value' in this case.


The draft11  says:

  container interfaces-state {
        config false;
        description
          "Data nodes for the operational state of interfaces.";

        list interface {
          key "name";

          description
            "The list of interfaces on the device.

             Physical interfaces detected by the system are always
             present in this list, if they are configured or not.";



first, should the last sentence end with:

..., whether they are configured or not." ?


Another question:
Will /interfaces-state/interface possibly also contain entries that are neither physical interfaces nor
logical interfaces explicitly configured? Like some routing entries injected by system? If yes
pointing that out may also help.


--Xiang
  



>
> /js
>

From lhotka@nic.cz  Fri May 17 02:30: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 DE90A21F9347 for ; Fri, 17 May 2013 02:30:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.774
X-Spam-Level: 
X-Spam-Status: No, score=-1.774 tagged_above=-999 required=5 tests=[AWL=0.225,  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 xSoQSBhH5SPA for ; Fri, 17 May 2013 02:30:33 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 2F60A21F9154 for ; Fri, 17 May 2013 02:30:32 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id B0D2D13FB13; Fri, 17 May 2013 11:30:31 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1368783031; bh=UZfZPXmNgDJVxxI5HU/SZnxE35WvXs/5byPKQFIv/bM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=I7Vf0IrBiT0S+kLr6gN65LVVr0J9aPZBpFtCeGoDHqK1yZolh2SyZCpDGaPD0HRHY JaDiqedVBbyVFtcdWKG8BG6sz1a4fUMmmGrSu01NmWv1yxDAOJJ75WdG474AKIWVN1 Tl3KfbfRy+OTUGHOH6EFQwoF7ezQki5bi2X2Z8jY=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: <519585AC.8060107@seguesoft.com>
Date: Fri, 17 May 2013 11:30:35 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20130515140353.15940.12042.idtracker@ietfa.amsl.com> <002901ce5226$412fa740$4001a8c0@gateway.2wire.net> <20130516113033.GA27666@elstar.local> <003d01ce522a$a288c720$4001a8c0@gateway.2wire.net> <20130516120659.GA27915@elstar.local> <009901ce523c$15ae8f80$4001a8c0@gateway.2wire.net> <20130516144450.GA28294@elstar.local> <519585AC.8060107@seguesoft.com>
To: Xiang Li 
X-Mailer: Apple Mail (2.1503)
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-interfaces-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, 17 May 2013 09:30:34 -0000

On May 17, 2013, at 3:19 AM, Xiang Li  wrote:

> Another question:
> Will /interfaces-state/interface possibly also contain entries that =
are neither physical interfaces nor
> logical interfaces explicitly configured? Like some routing entries =
injected by system? If yes
> pointing that out may also help.

Routing entries should go into routing tables. I plan to restructure the =
routing data model slightly along similar lines as ietf-interfaces, but =
IMO ietf-ip should go first.

Lada

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





From j.schoenwaelder@jacobs-university.de  Fri May 17 03:17: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 8756A21F93EB for ; Fri, 17 May 2013 03:17:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.161
X-Spam-Level: 
X-Spam-Status: No, score=-103.161 tagged_above=-999 required=5 tests=[AWL=0.088, 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 fb3aFCJ3CDnp for ; Fri, 17 May 2013 03:17:01 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id BE42021F93B7 for ; Fri, 17 May 2013 03:17:00 -0700 (PDT)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 875E120BF4; Fri, 17 May 2013 12:16:59 +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 E5GoGWc1xGPi; Fri, 17 May 2013 12:16: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 020FF20BEB; Fri, 17 May 2013 12:16:58 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id E095A26525DA; Fri, 17 May 2013 12:16:56 +0200 (CEST)
Date: Fri, 17 May 2013 12:16:56 +0200
From: Juergen Schoenwaelder 
To: Xiang Li 
Message-ID: <20130517101656.GA31958@elstar.local>
Mail-Followup-To: Xiang Li , netmod@ietf.org
References: <20130515140353.15940.12042.idtracker@ietfa.amsl.com> <002901ce5226$412fa740$4001a8c0@gateway.2wire.net> <20130516113033.GA27666@elstar.local> <003d01ce522a$a288c720$4001a8c0@gateway.2wire.net> <20130516120659.GA27915@elstar.local> <009901ce523c$15ae8f80$4001a8c0@gateway.2wire.net> <20130516144450.GA28294@elstar.local> <519585AC.8060107@seguesoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <519585AC.8060107@seguesoft.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-11.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: Fri, 17 May 2013 10:17:06 -0000

On Thu, May 16, 2013 at 08:19:40PM -0500, Xiang Li wrote:
> 
> >Perhaps the 1st sentence in the second paragraph can be made clearer
> >by saying:
> >
> >          When a configured logical interface is created by the
> >          system, it is instantiated with the same name in the
> >          /interface-state/interface list.
> 
> 
> +1.
> 
> To make things clearer, I think it should worth pointing out  that
> for physical interfaces,
> the /interfaces/interface/name has the same value as
> /interfaces-state/interface/name.
> This should help clarify that there aren't two different keys for
> configured interfaces, be it
> logical or physical.
> 

Yep. We thought this is already clear but perhaps we can make it even
clearer.
 
> The draft11  says:
> 
>  container interfaces-state {
>        config false;
>        description
>          "Data nodes for the operational state of interfaces.";
> 
>        list interface {
>          key "name";
> 
>          description
>            "The list of interfaces on the device.
> 
>             Physical interfaces detected by the system are always
>             present in this list, if they are configured or not.";
> 
> 
> 
> first, should the last sentence end with:
> 
> ..., whether they are configured or not." ?

yes 
 
> Another question:
> Will /interfaces-state/interface possibly also contain entries that are neither physical interfaces nor
> logical interfaces explicitly configured? Like some routing entries injected by system? If yes
> pointing that out may also help.

Not sure what you mean with 'routing entries'. But yes, I do assume
that /interface-state/interface contains all physical and logical
interfaces present on the box. And if interfaces appear as side
effects of say turning on other services, I would expect that they
also become visible in the /interface-state/interface list. If other
share this view, we may need to clarify this as well.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From ietfc@btconnect.com  Fri May 17 06:37: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 958B921F93EB for ; Fri, 17 May 2013 06:37:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level: 
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=2.300,  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 4vT636pi1m1e for ; Fri, 17 May 2013 06:37:49 -0700 (PDT)
Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id 6C40221F93E8 for ; Fri, 17 May 2013 06:37:49 -0700 (PDT)
Received: from mail138-co9-R.bigfish.com (10.236.132.237) by CO9EHSOBE024.bigfish.com (10.236.130.87) with Microsoft SMTP Server id 14.1.225.23; Fri, 17 May 2013 13:37:41 +0000
Received: from mail138-co9 (localhost [127.0.0.1])	by mail138-co9-R.bigfish.com (Postfix) with ESMTP id 30DEB2005E6; Fri, 17 May 2013 13:37:41 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.253.85; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0710HT002.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -14
X-BigFish: PS-14(zz9371I542I1432Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275bh8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh19f0h1ad9h1b0ah1d0ch1d2eh1d3fh304l1d11m1155h)
Received: from mail138-co9 (localhost.localdomain [127.0.0.1]) by mail138-co9 (MessageSwitch) id 1368797858642385_27083; Fri, 17 May 2013 13:37:38 +0000 (UTC)
Received: from CO9EHSMHS029.bigfish.com (unknown [10.236.132.250])	by mail138-co9.bigfish.com (Postfix) with ESMTP id 7D932140087; Fri, 17 May 2013 13:37:38 +0000 (UTC)
Received: from DB3PRD0710HT002.eurprd07.prod.outlook.com (157.56.253.85) by CO9EHSMHS029.bigfish.com (10.236.130.39) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 17 May 2013 13:37:38 +0000
Received: from pc6 (86.173.197.168) by pod51017.outlook.com (10.255.75.37) with Microsoft SMTP Server (TLS) id 14.16.311.1; Fri, 17 May 2013 13:37:16 +0000
Message-ID: <03c901ce5302$e4038900$4001a8c0@gateway.2wire.net>
From: t.petch 
To: , Martin Bjorklund 
References: <20130515140353.15940.12042.idtracker@ietfa.amsl.com> <20130515.160512.1630408467051717643.mbj@tail-f.com>
Date: Fri, 17 May 2013 14:31:31 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [86.173.197.168]
X-OriginatorOrg: btconnect.com
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-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, 17 May 2013 13:37:54 -0000

----- Original Message -----
From: "Martin Bjorklund" 
To: 
Sent: Wednesday, May 15, 2013 3:05 PM
Subject: Re: [netmod] I-D Action:
draft-ietf-netmod-interfaces-cfg-11.txt


> Hi,
>
> During the IETF LC, we got quite a few comments on document
> draft-ietf-netmod-interfaces-cfg-10.
>
> See for example the threads
>
> http://www.ietf.org/mail-archive/web/ietf/current/msg78801.html
> (my reply:
> http://www.ietf.org/mail-archive/web/ietf/current/msg78945.html)
>
> and
>
> http://www.ietf.org/mail-archive/web/netmod/current/msg08035.html

Martin

One of the comments in this review was

'It is interesting that these design criteria do not call out the
applicability to "physical" and "virtual" interfaces. Moreover, the text
above seems to imply that the only "dynamic creation and deletion" of
interfaces happens with the "addition and removal of physical
interfaces" and does not call out tunnels, loopbacks, virtuals, and
other logical entities instantiated as "interfaces".'

which I do not think was addressed and which in turn left me uncertain
what you mean by physical and logical.

>From elsewhere, I have the sense that physical is there for interfaces
where the system has an idea of the relevant information, such as naming
it ser2, whether or not it is something physical or distinct, so that
the act of configuration is constrained by what the system has already
done - if a system with an X.25 card predefines 4000 VC, are they then
physical? - whereas if the agent can choose the details to suit itself
"If the device supports arbitrarily named logical interfaces,"
then does that make them logical?

Likewise, in
'   For physical interfaces, the "name" is the device-specific name of
   the interface.  It is used to identify the physical hardware
   interface.  The 'config false' list "/interfaces-state/interface"
   contains all currently existing interfaces on the device.'
the last sentence omits physical or logical so I read that as applying
to all interfaces, VPN, VC, ser3 and so on.

While
"When a configured logical interface is created by the  system, it is
instantiated in the interface-state/interface list"
puzzles me further.  Are logical interfaces always configured?  And what
does it mean for system to create an interface as opposed to the agent
configuring it?

I do not understand physical v logical v what goes in
interface-state/interface list
when:-(

I think it not enough just to use the terms without either defining
them, or else using them in such a way that the definition is implicit.
Like so much in this work, it seems obvious until you think about it:-(

Tom Petch








From xiangli@seguesoft.com  Fri May 17 06:52: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 9EDFB21F949D for ; Fri, 17 May 2013 06:52:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level: 
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075,  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 ReG5v+FCl4N0 for ; Fri, 17 May 2013 06:52:04 -0700 (PDT)
Received: from m1plsmtpa01-04.prod.mesa1.secureserver.net (m1plsmtpa01-04.prod.mesa1.secureserver.net [64.202.165.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6E53E21F93F1 for ; Fri, 17 May 2013 06:52:04 -0700 (PDT)
Received: from [192.168.2.13] ([98.212.151.151]) by m1plsmtpa01-04.prod.mesa1.secureserver.net with  id d1s21l0083GEayi011s28N; Fri, 17 May 2013 06:52:03 -0700
Message-ID: <51963604.9030407@seguesoft.com>
Date: Fri, 17 May 2013 08:52:04 -0500
From: Xiang Li 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: netmod@ietf.org
References: <20130515140353.15940.12042.idtracker@ietfa.amsl.com> <002901ce5226$412fa740$4001a8c0@gateway.2wire.net> <20130516113033.GA27666@elstar.local> <003d01ce522a$a288c720$4001a8c0@gateway.2wire.net> <20130516120659.GA27915@elstar.local> <009901ce523c$15ae8f80$4001a8c0@gateway.2wire.net> <20130516144450.GA28294@elstar.local> <519585AC.8060107@seguesoft.com> <20130517101656.GA31958@elstar.local>
In-Reply-To: <20130517101656.GA31958@elstar.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-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, 17 May 2013 13:52:10 -0000

>   
>> The draft11  says:
>>
>>   container interfaces-state {
>>         config false;
>>         description
>>           "Data nodes for the operational state of interfaces.";
>>
>>         list interface {
>>           key "name";
>>
>>           description
>>             "The list of interfaces on the device.
>>
>>              Physical interfaces detected by the system are always
>>              present in this list, if they are configured or not.";
>>
>>
>>
>> first, should the last sentence end with:
>>
>> ..., whether they are configured or not." ?
> yes
>   
>> Another question:
>> Will /interfaces-state/interface possibly also contain entries that are neither physical interfaces nor
>> logical interfaces explicitly configured? Like some routing entries injected by system? If yes
>> pointing that out may also help.
> Not sure what you mean with 'routing entries'. But yes, I do assume
> that /interface-state/interface contains all physical and logical
> interfaces present on the box. And if interfaces appear as side
> effects of say turning on other services, I would expect that they
> also become visible in the /interface-state/interface list. If other
> share this view, we may need to clarify this as well.


I just meant if /interfaces-state/interface will contain entries that 
are neither  physical interface nor 'logical interfaces' explicitly 
configured, but are somehow inserted by the 'netconf server' 
automatically, like the temporal/dynamic/ephemeral routing entries that 
have been discussed in the routing draft.

If there is no such thing, i.e.,  /interfaces-state/interface =
the physical interfaces on the device + the logical interface 
configured, then this should be
clarified.



--Xiang



From xiangli@seguesoft.com  Fri May 17 06:56: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 2925321F95DB for ; Fri, 17 May 2013 06:56:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.239
X-Spam-Level: 
X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_15=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 jIFD16HoCMWf for ; Fri, 17 May 2013 06:56:36 -0700 (PDT)
Received: from p3plsmtpa11-07.prod.phx3.secureserver.net (p3plsmtpa11-07.prod.phx3.secureserver.net [68.178.252.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD0821F95C4 for ; Fri, 17 May 2013 06:56:36 -0700 (PDT)
Received: from [192.168.2.13] ([98.212.151.151]) by p3plsmtpa11-07.prod.phx3.secureserver.net with  id d1wZ1l00G3GEayi011waNW; Fri, 17 May 2013 06:56:34 -0700
Message-ID: <51963714.1020009@seguesoft.com>
Date: Fri, 17 May 2013 08:56:36 -0500
From: Xiang Li 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: "t.petch" 
References: <20130515140353.15940.12042.idtracker@ietfa.amsl.com> <20130515.160512.1630408467051717643.mbj@tail-f.com> <03c901ce5302$e4038900$4001a8c0@gateway.2wire.net>
In-Reply-To: <03c901ce5302$e4038900$4001a8c0@gateway.2wire.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-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, 17 May 2013 13:56:41 -0000

On 5/17/2013 8:31 AM, t.petch wrote:
> ----- Original Message -----
> From: "Martin Bjorklund" 
> To: 
> Sent: Wednesday, May 15, 2013 3:05 PM
> Subject: Re: [netmod] I-D Action:
> draft-ietf-netmod-interfaces-cfg-11.txt
>
>
>> Hi,
>>
>> During the IETF LC, we got quite a few comments on document
>> draft-ietf-netmod-interfaces-cfg-10.
>>
>> See for example the threads
>>
>> http://www.ietf.org/mail-archive/web/ietf/current/msg78801.html
>> (my reply:
>> http://www.ietf.org/mail-archive/web/ietf/current/msg78945.html)
>>
>> and
>>
>> http://www.ietf.org/mail-archive/web/netmod/current/msg08035.html
> Martin
>
> One of the comments in this review was
>
> 'It is interesting that these design criteria do not call out the
> applicability to "physical" and "virtual" interfaces. Moreover, the text
> above seems to imply that the only "dynamic creation and deletion" of
> interfaces happens with the "addition and removal of physical
> interfaces" and does not call out tunnels, loopbacks, virtuals, and
> other logical entities instantiated as "interfaces".'
>
> which I do not think was addressed and which in turn left me uncertain
> what you mean by physical and logical.
>
>  From elsewhere, I have the sense that physical is there for interfaces
> where the system has an idea of the relevant information, such as naming
> it ser2, whether or not it is something physical or distinct, so that
> the act of configuration is constrained by what the system has already
> done - if a system with an X.25 card predefines 4000 VC, are they then
> physical? - whereas if the agent can choose the details to suit itself
> "If the device supports arbitrarily named logical interfaces,"
> then does that make them logical?
>
> Likewise, in
> '   For physical interfaces, the "name" is the device-specific name of
>     the interface.  It is used to identify the physical hardware
>     interface.  The 'config false' list "/interfaces-state/interface"
>     contains all currently existing interfaces on the device.'
> the last sentence omits physical or logical so I read that as applying
> to all interfaces, VPN, VC, ser3 and so on.
>
> While
> "When a configured logical interface is created by the  system, it is
> instantiated in the interface-state/interface list"
> puzzles me further.  Are logical interfaces always configured?  And what
> does it mean for system to create an interface as opposed to the agent
> configuring it?

I had the same question so I think some clarification here should help...


> I do not understand physical v logical v what goes in
> interface-state/interface list
> when:-(
>
> I think it not enough just to use the terms without either defining
> them, or else using them in such a way that the definition is implicit.
> Like so much in this work, it seems obvious until you think about it:-(
+1

--Xiang

> Tom Petch
>
>
>
>
> 
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From j.schoenwaelder@jacobs-university.de  Fri May 17 07:20: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 049B721F937B for ; Fri, 17 May 2013 07:20:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.866
X-Spam-Level: 
X-Spam-Status: No, score=-102.866 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_15=0.6, 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 y3X7CxT8VqeH for ; Fri, 17 May 2013 07:19:59 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF7521F92F0 for ; Fri, 17 May 2013 07:19:48 -0700 (PDT)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 61DD020BEA; Fri, 17 May 2013 16:19:47 +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 O9hKBuJfPXMK; Fri, 17 May 2013 16:19:47 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 91A4F20BE9; Fri, 17 May 2013 16:19:46 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 610ED2652FA2; Fri, 17 May 2013 16:19:43 +0200 (CEST)
Date: Fri, 17 May 2013 16:19:43 +0200
From: Juergen Schoenwaelder 
To: "t.petch" 
Message-ID: <20130517141943.GA32530@elstar.local>
Mail-Followup-To: "t.petch" , netmod@ietf.org, Martin Bjorklund 
References: <20130515140353.15940.12042.idtracker@ietfa.amsl.com> <20130515.160512.1630408467051717643.mbj@tail-f.com> <03c901ce5302$e4038900$4001a8c0@gateway.2wire.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <03c901ce5302$e4038900$4001a8c0@gateway.2wire.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-11.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: Fri, 17 May 2013 14:20:05 -0000

On Fri, May 17, 2013 at 02:31:31PM +0100, t.petch wrote:
> 
> I do not understand physical v logical v what goes in
> interface-state/interface list
> when:-(
> 
> I think it not enough just to use the terms without either defining
> them, or else using them in such a way that the definition is implicit.
> Like so much in this work, it seems obvious until you think about it:-(
> 

I think I clarified when things get instantiated and removed before.
Concerning the term 'logical interface', this is borrowed from the
IF-MIB and its RFC, latest version being RFC 2863. Perhaps we need to
have a more explicit definitions these days.

/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  Fri May 17 07:20: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 0AC6821F925A for ; Fri, 17 May 2013 07:20:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.491
X-Spam-Level: 
X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 bogge8jHxEaY for ; Fri, 17 May 2013 07:20:31 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 950EF21F93A5 for ; Fri, 17 May 2013 07:20:30 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 5293B13FCB8; Fri, 17 May 2013 16:20:28 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1368800428; bh=mohxDpWkpDvajFxmOOEioRCMe6a3WMzfaFP7Ccsvj+g=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=pcg1ZbRrSjVCFSCj33KQxSvYQXbWNDnoa3SoIUbm155s02tYkkZYMf4+ZamT1+K1Z AMgnNiOTS8rEdQMkL8z6vd1P7CynbSwGxicsHHJlDgRUin12r/rRwyUr4TYMP/NvaD nCnnMs0q6VqRXhq5/dx1tJb58GOBG3ni5RgRU6ZI=
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Content-Type: text/plain; charset=us-ascii
From: Ladislav Lhotka 
X-Priority: 3
In-Reply-To: <03c901ce5302$e4038900$4001a8c0@gateway.2wire.net>
Date: Fri, 17 May 2013 16:20:27 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <232D1627-3861-45E8-BF51-A7191BD15477@nic.cz>
References: <20130515140353.15940.12042.idtracker@ietfa.amsl.com> <20130515.160512.1630408467051717643.mbj@tail-f.com> <03c901ce5302$e4038900$4001a8c0@gateway.2wire.net>
To: t.petch 
X-Mailer: Apple Mail (2.1503)
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-interfaces-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, 17 May 2013 14:20:32 -0000

On May 17, 2013, at 3:31 PM, t.petch  wrote:

> ----- Original Message -----
> From: "Martin Bjorklund" 
> To: 
> Sent: Wednesday, May 15, 2013 3:05 PM
> Subject: Re: [netmod] I-D Action:
> draft-ietf-netmod-interfaces-cfg-11.txt
>=20
>=20
>> Hi,
>>=20
>> During the IETF LC, we got quite a few comments on document
>> draft-ietf-netmod-interfaces-cfg-10.
>>=20
>> See for example the threads
>>=20
>> http://www.ietf.org/mail-archive/web/ietf/current/msg78801.html
>> (my reply:
>> http://www.ietf.org/mail-archive/web/ietf/current/msg78945.html)
>>=20
>> and
>>=20
>> http://www.ietf.org/mail-archive/web/netmod/current/msg08035.html
>=20
> Martin
>=20
> One of the comments in this review was
>=20
> 'It is interesting that these design criteria do not call out the
> applicability to "physical" and "virtual" interfaces. Moreover, the =
text
> above seems to imply that the only "dynamic creation and deletion" of
> interfaces happens with the "addition and removal of physical
> interfaces" and does not call out tunnels, loopbacks, virtuals, and
> other logical entities instantiated as "interfaces".'
>=20
> which I do not think was addressed and which in turn left me uncertain
> what you mean by physical and logical.
>=20
> =46rom elsewhere, I have the sense that physical is there for =
interfaces
> where the system has an idea of the relevant information, such as =
naming
> it ser2, whether or not it is something physical or distinct, so that
> the act of configuration is constrained by what the system has already
> done - if a system with an X.25 card predefines 4000 VC, are they then
> physical? - whereas if the agent can choose the details to suit itself
> "If the device supports arbitrarily named logical interfaces,"
> then does that make them logical?

My understanding is that physical interfaces are those that the device =
creates on its own, gives them a name and initialises them to some =
default state. These interfaces appear originally as entries under =
/interfaces-state. Now, if a client wants to reconfigure such an =
interface (which may include activating it), he has to create an entry =
with the same name under /interfaces (i.e., configuration) and specify =
the changes.

In contrast, the originator for a logical interface is a client who =
creates first a config entry for it under /interfaces. If the server =
accepts this configuration, it then creates the corresponding entry with =
the same name under /interfaces-state.

If the device supports arbitrarily named logical interfaces, then the =
client may configure the entry with any name as its key, otherwise the =
client has to pick a name according to the device's naming scheme.

Perhaps the adjectives "physical" and "logical" are somewhat misleading =
and something more neutral could be chosen instead.

Lada

>=20
> Likewise, in
> '   For physical interfaces, the "name" is the device-specific name of
>   the interface.  It is used to identify the physical hardware
>   interface.  The 'config false' list "/interfaces-state/interface"
>   contains all currently existing interfaces on the device.'
> the last sentence omits physical or logical so I read that as applying
> to all interfaces, VPN, VC, ser3 and so on.
>=20
> While
> "When a configured logical interface is created by the  system, it is
> instantiated in the interface-state/interface list"
> puzzles me further.  Are logical interfaces always configured?  And =
what
> does it mean for system to create an interface as opposed to the agent
> configuring it?
>=20
> I do not understand physical v logical v what goes in
> interface-state/interface list
> when:-(
>=20
> I think it not enough just to use the terms without either defining
> them, or else using them in such a way that the definition is =
implicit.
> Like so much in this work, it seems obvious until you think about =
it:-(
>=20
> Tom Petch
>=20
>=20
>=20
>=20
> 
>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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





From ietfc@btconnect.com  Fri May 17 10:26: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 A1E7311E80F9 for ; Fri, 17 May 2013 10:26:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.256
X-Spam-Level: 
X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_15=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 cVHk1H7JeNwU for ; Fri, 17 May 2013 10:26:13 -0700 (PDT)
Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0185.outbound.messaging.microsoft.com [213.199.154.185]) by ietfa.amsl.com (Postfix) with ESMTP id 372FC11E80F4 for ; Fri, 17 May 2013 10:26:12 -0700 (PDT)
Received: from mail215-db8-R.bigfish.com (10.174.8.226) by DB8EHSOBE010.bigfish.com (10.174.4.73) with Microsoft SMTP Server id 14.1.225.23; Fri, 17 May 2013 17:26:10 +0000
Received: from mail215-db8 (localhost [127.0.0.1])	by mail215-db8-R.bigfish.com (Postfix) with ESMTP id A138842029D; Fri, 17 May 2013 17:26:10 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.250.69; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0711HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -15
X-BigFish: PS-15(zz98dI9371I542I1432Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275bh8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh304l1d11m1155h)
Received: from mail215-db8 (localhost.localdomain [127.0.0.1]) by mail215-db8 (MessageSwitch) id 1368811563774163_1335; Fri, 17 May 2013 17:26:03 +0000 (UTC)
Received: from DB8EHSMHS003.bigfish.com (unknown [10.174.8.240])	by mail215-db8.bigfish.com (Postfix) with ESMTP id A4898300055; Fri, 17 May 2013 17:26:03 +0000 (UTC)
Received: from AMXPRD0711HT003.eurprd07.prod.outlook.com (157.56.250.69) by DB8EHSMHS003.bigfish.com (10.174.4.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 17 May 2013 17:26:02 +0000
Received: from DB3PRD0511HT003.eurprd05.prod.outlook.com (157.56.254.213) by pod51017.outlook.com (10.242.9.164) with Microsoft SMTP Server (TLS) id 14.16.311.1; Fri, 17 May 2013 17:26:01 +0000
Message-ID: <005801ce5322$d91be300$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Ladislav Lhotka 
References: <20130515140353.15940.12042.idtracker@ietfa.amsl.com> <20130515.160512.1630408467051717643.mbj@tail-f.com> <03c901ce5302$e4038900$4001a8c0@gateway.2wire.net> <232D1627-3861-45E8-BF51-A7191BD15477@nic.cz>
Date: Fri, 17 May 2013 18:20:15 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.254.213]
X-OriginatorOrg: btconnect.com
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-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, 17 May 2013 17:26:19 -0000

----- Original Message -----
From: "Ladislav Lhotka" 
To: "t.petch" 
Cc: ; "Martin Bjorklund" 
Sent: Friday, May 17, 2013 3:20 PM

On May 17, 2013, at 3:31 PM, t.petch  wrote:

> ----- Original Message -----
> From: "Martin Bjorklund" 
> To: 
> Sent: Wednesday, May 15, 2013 3:05 PM
> Subject: Re: [netmod] I-D Action:
> draft-ietf-netmod-interfaces-cfg-11.txt
>
>
>> Hi,
>>
>> During the IETF LC, we got quite a few comments on document
>> draft-ietf-netmod-interfaces-cfg-10.
>>
>> See for example the threads
>>
>> http://www.ietf.org/mail-archive/web/ietf/current/msg78801.html
>> (my reply:
>> http://www.ietf.org/mail-archive/web/ietf/current/msg78945.html)
>>
>> and
>>
>> http://www.ietf.org/mail-archive/web/netmod/current/msg08035.html
>
> Martin
>
> One of the comments in this review was
>
> 'It is interesting that these design criteria do not call out the
> applicability to "physical" and "virtual" interfaces. Moreover, the
text
> above seems to imply that the only "dynamic creation and deletion" of
> interfaces happens with the "addition and removal of physical
> interfaces" and does not call out tunnels, loopbacks, virtuals, and
> other logical entities instantiated as "interfaces".'
>
> which I do not think was addressed and which in turn left me uncertain
> what you mean by physical and logical.
>
> From elsewhere, I have the sense that physical is there for interfaces
> where the system has an idea of the relevant information, such as
naming
> it ser2, whether or not it is something physical or distinct, so that
> the act of configuration is constrained by what the system has already
> done - if a system with an X.25 card predefines 4000 VC, are they then
> physical? - whereas if the agent can choose the details to suit itself
> "If the device supports arbitrarily named logical interfaces,"
> then does that make them logical?

My understanding is that physical interfaces are those that the device
creates on its own, gives them a name and initialises them to some
default state. These interfaces appear originally as entries under
/interfaces-state. Now, if a client wants to reconfigure such an
interface (which may include activating it), he has to create an entry
with the same name under /interfaces (i.e., configuration) and specify
the changes.

In contrast, the originator for a logical interface is a client who
creates first a config entry for it under /interfaces. If the server
accepts this configuration, it then creates the corresponding entry with
the same name under /interfaces-state.

If the device supports arbitrarily named logical interfaces, then the
client may configure the entry with any name as its key, otherwise the
client has to pick a name according to the device's naming scheme.

Perhaps the adjectives "physical" and "logical" are somewhat misleading
and something more neutral could be chosen instead.



Lada

As ever, thank you for a clear explanation.

Martin
I propose changing 3.1
OLD
" The data model for interfaces presented in this document uses a flat
   list of interfaces.  Each interface in the list is identified by its
   name.  Furthermore, each interface has a mandatory "type" leaf.

   There is one list of configured interfaces ("/interfaces/interface"),
   and a separate list for the operational state of all interfaces
   ("/interfaces-state/interface")."

NEW
" The data model for interfaces presented in this document uses two flat
   lists of interfaces.  An interface in a list is identified by its
   name; each entry has a mandatory "type" leaf.  One list consists of
   state, the other of configured information.

One list, /interfaces-state/interface, is initially populated by the
server, creating entries therein.  Subsequently, the client may create
an entry with the same name in the other list, /interfaces/interface,
and then edit that entry in order to amend the configuration of that
interface.

If the client creates an entry with a different name in
/interfaces/interface, and that entry is acceptable to the server, then
the server creates a corresponding entry in /interfaces-state/interface
Thus the entries in /interfaces/interface are a strict subset of
/interfaces-state/interface (apart from any transient conditions when an
entry is being created or deleted).
"

Not quite the right style but I am focussed on the semantics at present

Tom Petch

Lada

>



From andy@yumaworks.com  Fri May 17 12:09: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 3BAEF21F971A for ; Fri, 17 May 2013 12:09:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.15
X-Spam-Level: 
X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=-0.373,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_65=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSwJNCDHOx8m for ; Fri, 17 May 2013 12:09:10 -0700 (PDT)
Received: from mail-ia0-x234.google.com (mail-ia0-x234.google.com [IPv6:2607:f8b0:4001:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id A58DA21F970A for ; Fri, 17 May 2013 12:09:10 -0700 (PDT)
Received: by mail-ia0-f180.google.com with SMTP id l27so5077945iae.25 for ; Fri, 17 May 2013 12:09:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=JS5/lBAyF1mZyxpF4+wgoslLxPmGqyGLUQNghEcnbpI=; b=oUJTFBIVQd4bEc4L+UOvcWgM5+9Hb4NNlXPFCSpO32WDiWHA98T03mRn++50XEIsmP 9vTAJQkWDzTUToLMgbkNmraLDIzR+BrSIgzWBMKppznZAFkQgeDlVq/L+ZmNXYVxuWEv g/D+CYkHzdVP7J5Oa4YU4im4M0Cz1/0xLq7XW0CcvZDIWUZLPwoHcpDdd0SWY6XBsNO6 /8QQ3joXzpy8IkMxYBCEBJMtBNI5rgVdR27CR2BtGdTqDe8TZoTgQrFiyOuMkAkQpa2o gXit9LO7ZZVbSTl7FEgwmJ97WFjYVzCZ534gJEZ2cixb99gtVILwTbnQ9vEEnFxQIF00 yAaw==
MIME-Version: 1.0
X-Received: by 10.50.97.7 with SMTP id dw7mr13232206igb.37.1368817749999; Fri, 17 May 2013 12:09:09 -0700 (PDT)
Received: by 10.231.120.74 with HTTP; Fri, 17 May 2013 12:09:09 -0700 (PDT)
In-Reply-To: <20130516160528.GB28482@elstar.local>
References: <20130516160528.GB28482@elstar.local>
Date: Fri, 17 May 2013 12:09:09 -0700
Message-ID: 
From: Andy Bierman 
To: Juergen Schoenwaelder , netmod@ietf.org
Content-Type: multipart/alternative; boundary=047d7b10c853c0528a04dceeb7b0
X-Gm-Message-State: ALoCoQn9h36W7ltBk07G7+9vvkzh8AiJsn+GRxMFFepjdnX8bCIicnHZZ5xd2mEFgk4sWwesjVHV
Subject: Re: [netmod] comments on draft-ietf-netmod-system-mgmt-06
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, 17 May 2013 19:09:12 -0000

--047d7b10c853c0528a04dceeb7b0
Content-Type: text/plain; charset=ISO-8859-1

Hi,

Thanks for your review.  Comments in-line.
Summary:
  - all fixed except:
       (c, l, s) left for Martin
       (f, o, p, r, t) need WG to decide


Andy



On Thu, May 16, 2013 at 9:05 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> Hi,
>
> here is a review of draft-ietf-netmod-system-mgmt-06.
>
> a) The abstract needs work. I do not think the current sentence is
>    correct nor do I think this is a useful description of the scope
>    covered.
>
>
fixed


> b) The same applies to the Introduction - this does not seem to be
>

fixed


>    about a "management system". The bullets listed also do not line up
>    well with what is now in the document, perhaps it should be
>
>    o  system identification configuration and monitoring
>
>    o  system time-of-day configuration and monitoring
>
>    o  user authentication configuration
>
>    o  local users configuration
>
>    o  dns resolver configuration
>
>    o  system control operations (shutdown, restart, setting time)
>
>
fixed


>    (not sure monitoring is a good word but I have no better proposal)
>
>    I also do not see what the definition of a term requires a new
>    subsubsection (just get rid of the section header
>    '1.1.1. Terms').
>
>
fixed


>    The definition of 'system' is also rather unclear to me: "the
>    embodiment of the entire set of management interfaces". Nor does
>    the I-D do anything with managing physical entities. I think there
>    should be a better definition or no definition at all.
>
>
removed


>    Any other terms that need to be 'imported' from other documents?
>
>
not sure -- none added


> c) Update section 1.2 to the new format which supports * for lists and
>    regenerate the tree figures. (Martin knows what I mean.)
>
>
left for Martin


> d) sec 2.1:
>
>    s/operational data/operational state data/ (perhaps consider
>    importing a definition for operational state)
>
>
fixed; no RFC to import this term from.  I changed this term
to "non-configuration data" in the  draft.  IMO, extra
classifications beyond config=false are not needed for
current NETCONF/YANG features.


> e) Should section 2 not also have a subsection talking about DNS
>    resolver configuration and a subsection talking about basic system
>    control operations?
>
>
fixed


> f) Even though there are only a few config false data nodes, I would
>    seriously consider to move them to separate them from the config
>    true data nodes.
>


I think you are right.  There should not have to be a couple NP containers
in the running config just to hold non-config sub-trees.  If I have a
completely
default system configuration then the /system sub-tree does not need
to exist.  I should still be able to read the time and platform info in any
case.

I could move the 3 nodes if there is WG consensus to do so:

   /system-state/platform
   /system-state/current-datetime
   /system-state/boot-datetime

IMO, we should even move these objects to a new module.
We want to make sure that every NETCONF server supports
the read-only /system-state objects (especially current-datetime).
Currently, a server has to implement 3 rpc statements
and a lot of config objects in order to provide this information
and advertise the YANG module.

(IMO we should not have 2 top-level objects in the same module anyway).



>
> g) Why are algorithm and key-data optional for an SSH key?
>
>
made them mandatory



> h) sec 3.5.2:
>
>    s/system\/ auth/system\/auth/
>
>
fixed


> i) First sentence of the module description may need improvements.
>
>
fixed


> j) p12:
>
>    s/correct/accepted/
>

fixed


>
> k) What kind of device would not announce the feature "authentication"?
>    Do not all NETCONF transports require some form of authentication?
>
>

It means configuration of authentication -- fixed



> l) The feature local-users is bound to password authentication. Can I
>    not have a system with local user accounts that only permits SSH
>    public key authentication? (This is actually how I run all my
>    servers - we completely disable password authentication. I guess
>    this is not uncommon.)
>


Left for Martin to answer


>
> m) Note that system/contact and system/location only map to SNMP if
>    you are lucky due to the different character sets involved. With
>    UTF8, also the size restriction does not mean the same. Perhaps
>    remove the size restriction completely and add explicit text that
>    implementations mapping this to SNMP objects may restrict the size
>    and the allowed set of characters. (In fact DisplayString has even
>    more details.)
>
>
fixed


> n) Should boot-datetime really be the time the NETCONF server last
>    restarted? I would be more interested to know when the system last
>    restarted. The NETCONF restart time (if ever needed) should really
>    be part of the netconf-state data model (i.e. RFC 6022 bis).
>
>

fixed


> o) The ntp objects allow to configure multiple IP addresses and each
>    one can be disabled individually. Is this really needed? If so, why
>    is this not needed for DNS resolvers?
>
>

I think these extra settings were added to match how NTP is configured on
Linux.
I don't think they were requested for DNS.  (no change)



> p) The ntp objects do not allow me to configure a port number. Should
>    we not generally allow to configure complete transport layer
>    endpoints?
>
>
There is only a port number for RADIUS over UDP.
Not sure if these are needed or not.
(no changes)


> q) Should the dns container be called resolver or dns-resolver?
>

changed to dns-resolver so it won't be confused with DNS server
configuration.


> r) The model does not allow me to configure a DNS server using a
>    non-standard port number. Should we not generally allow to
>    configure complete transport layer endpoints?
>

same answer as (p)


>
> s) I think timeout and attempts are not clear enough defined. Consider
>    a server that never responds. With N attempts and a timeout t, do I
>    get N attempts with a timeout of t for each attempt or a timeout of
>    t with N attempts? Looking at the bind header files (the man pages
>    are also unclear), it seems bind does N attempts with a timeout of
>    t for each attempt.
>
>    The same applies to the timeout and attempts definitions for radius.
>
>
left for Martin to edit



> t) The radius server list is keyed by an address. Now with Radius,
>    there is the official default port number and there was a different
>    port number widely used before the official got allocated. Hence,
>    in practice, both are used. So I like to be able to configure
>    things such that the system tries both. However, this won't work
>    because the list is keyed by the address. I can't have this:
>
>    
>      
1.1.1.1

>      
>        1812
>      
>    
>    
>      
1.1.1.1

>      
>        1645
>      
>    
>
>    Note that this also applies to the other lists keyed by simply an
>    address. (We may have to introduce names to refer to the endpoints
>    if we want a simple key and transport extensibility).
>
>

I agree.  Named entries are better IMO anyway.
Should there be a unique-stmt for the addr:port pair?
(no changes)



>    I also find the separation of the udp port from the address
>    strange.  I can't have something like this either (if I want to add
>    tcp support):
>
>    
>      
1.1.1.1

>      
>        1812
>      
>    
>    
>      
1.1.1.1

>      
>        1645
>      
>    
>
>    For me, it would make more sense leave the address and port number
>    together and to support something like this.
>
>    
>      
>        
>          
1.1.1.1

>          1812
>        
>        
>          
1.1.1.1

>          1645
>        
>        
>          
1.1.1.1

>          1645
>        
>      
>    
>
>
I agree. Need WG to decide. I will leave for Martin to fix.



> u) Please update the security considerations boilerplate so that we
>    have an explicit reference to the access control model.
>
>
fixed



> v) Where you list readable subtrees, I think it is fair to explicitly
>    mention the local users subtree and the passwords contained in that
>    subtree.
>

fixed


>
> w) Are really all references normative? For example, RFC 6557 or RFC
>    3688?
>
>
fixed


> /js
>
>
Andy

--047d7b10c853c0528a04dceeb7b0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

Thanks for your review. =A0Comments in-line.
Summary:
=A0 - all fixed except:
=A0 =A0 =A0 =A0(c, =
l, s) left for Martin
=A0 =A0 =A0 =A0(f, o, p, r, t) need WG to d=
ecide




Andy



On Thu, May 16, 2013 at 9:05 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote=
:



Hi,



here is a review of draft-ietf-netmod-system-mgmt-06.



a) The abstract needs work. I do not think the current sentence is

=A0 =A0correct nor do I think this is a useful description of the scope

=A0 =A0covered.



fixed
=A0

b) The same applies to the Introduction - this does not seem to be

fixed
=A0



=A0 =A0about a "management system". The bullets listed also do no=
t line up

=A0 =A0well with what is now in the document, perhaps it should be



=A0 =A0o =A0system identification configuration and monitoring



=A0 =A0o =A0system time-of-day configuration and monitoring



=A0 =A0o =A0user authentication configuration



=A0 =A0o =A0local users configuration



=A0 =A0o =A0dns resolver configuration



=A0 =A0o =A0system control operations (shutdown, restart, setting time)



fixed
=A0

=A0 =A0(not sure monitoring is a good word but I have no better proposal)


=A0 =A0I also do not see what the definition of a term requires a new

=A0 =A0subsubsection (just get rid of the section header

=A0 =A0'1.1.1. Terms').



fixed
=A0

=A0 =A0The definition of 'system' is also rather unclear to me: &qu=
ot;the

=A0 =A0embodiment of the entire set of management interfaces". Nor doe=
s

=A0 =A0the I-D do anything with managing physical entities. I think there
=A0 =A0should be a better definition or no definition at all.



removed
=A0

=A0 =A0Any other terms that need to be 'imported' from other docume=
nts?



not sure -- none added
=A0

c) Update section 1.2 to the new format which supports * for lists and

=A0 =A0regenerate the tree figures. (Martin knows what I mean.)



left for Martin
=A0

d) sec 2.1:



=A0 =A0s/operational data/operational state data/ (perhaps consider

=A0 =A0importing a definition for operational state)



fixed; no RFC to import this term from=
. =A0I changed this term
to "non-configuration data" in=
 the <get2> draft. =A0IMO, extra
classifications beyond con=
fig=3Dfalse are not needed for


current NETCONF/YANG features.
=A0

e) Should section 2 not also have a subsection talking about DNS

=A0 =A0resolver configuration and a subsection talking about basic system
=A0 =A0control operations?



fixed
=A0

f) Even though there are only a few config false data nodes, I would

=A0 =A0seriously consider to move them to separate them from the config

=A0 =A0true data nodes.


=
I think you are right. =A0There should not have to be a couple NP container=
s
in the running config just to hold non-config sub-trees. =A0If =
I have a completely


default system configuration then the /system sub-tree does not need
to exist. =A0I should still be able to read the time and platform =
info in any case.

I could move the 3 nodes if ther=
e is WG consensus to do so:



=A0 =A0/system-state/platform
=A0 =A0/system-=
state/current-datetime
=A0 =A0/system-state/boot-datetime

IMO, we should even move these objects to a new module.

We want to make sure that every NETCONF server supports
the read-=
only /system-state objects (especially current-datetime).
Current=
ly, a server has to implement 3 rpc statements
and a lot of confi=
g objects in order to provide this information


and advertise the YANG module.

(IMO we should=
 not have 2 top-level objects in the same module anyway).

=A0




g) Why are algorithm and key-data optional for an SSH key?



made them mandatory

=A0

h) sec 3.5.2:



=A0 =A0s/system\/ auth/system\/auth/



fixed
=A0

i) First sentence of the module description may need improvements.



fixed
=A0

j) p12:



=A0 =A0s/correct/accepted/

fixed
<=
div>=A0



k) What kind of device would not announce the feature "authentication&=
quot;?

=A0 =A0Do not all NETCONF transports require some form of authentication?



It means configuration =
of authentication -- fixed

=A0


l) The feature local-users is bound to password authentication. Can I

=A0 =A0not have a system with local user accounts that only permits SSH

=A0 =A0public key authentication? (This is actually how I run all my

=A0 =A0servers - we completely disable password authentication. I guess

=A0 =A0this is not uncommon.)


Left for Martin to answer
=A0




m) Note that system/contact and system/location only map to SNMP if

=A0 =A0you are lucky due to the different character sets involved. With

=A0 =A0UTF8, also the size restriction does not mean the same. Perhaps

=A0 =A0remove the size restriction completely and add explicit text that
=A0 =A0implementations mapping this to SNMP objects may restrict the size
=A0 =A0and the allowed set of characters. (In fact DisplayString has even
=A0 =A0more details.)



fixed
=A0

n) Should boot-datetime really be the time the NETCONF server last

=A0 =A0restarted? I would be more interested to know when the system last
=A0 =A0restarted. The NETCONF restart time (if ever needed) should really
=A0 =A0be part of the netconf-state data model (i.e. RFC 6022 bis).




fixed
=A0

o) The ntp objects allow to configure multiple IP addresses and each

=A0 =A0one can be disabled individually. Is this really needed? If so, why<=
br>
=A0 =A0is this not needed for DNS resolvers?




I think these extra set=
tings were added to match how NTP is configured on Linux.
I don&#=
39;t think they were requested for DNS. =A0(no change)



=A0

p) The ntp objects do not allow me to configure a port number. Should

=A0 =A0we not generally allow to configure complete transport layer

=A0 =A0endpoints?



There is only a port number for RADIUS=
 over UDP.
Not sure if these are needed or not.
(no cha=
nges)
=A0


q) Should the dns container be called resolver or dns-resolver?

changed to dns-resolver so it won't be confuse=
d with DNS server
configuration.=A0





r) The model does not allow me to configure a DNS server using a

=A0 =A0non-standard port number. Should we not generally allow to

=A0 =A0configure complete transport layer endpoints?
<=
br>
same answer as (p)
=A0




s) I think timeout and attempts are not clear enough defined. Consider

=A0 =A0a server that never responds. With N attempts and a timeout t, do I<=
br>
=A0 =A0get N attempts with a timeout of t for each attempt or a timeout of<=
br>
=A0 =A0t with N attempts? Looking at the bind header files (the man pages
=A0 =A0are also unclear), it seems bind does N attempts with a timeout of
=A0 =A0t for each attempt.



=A0 =A0The same applies to the timeout and attempts definitions for radius.=




left for Martin to edit

=

=A0

t) The radius server list is keyed by an address. Now with Radius,

=A0 =A0there is the official default port number and there was a different<=
br>
=A0 =A0port number widely used before the official got allocated. Hence,
=A0 =A0in practice, both are used. So I like to be able to configure

=A0 =A0things such that the system tries both. However, this won't work=


=A0 =A0because the list is keyed by the address. I can't have this:



=A0 =A0<server>

=A0 =A0 =A0<address>1.1.1.1</address>

=A0 =A0 =A0<udp>

=A0 =A0 =A0 =A0<authentication-port>1812</authentication-port><=
br>
=A0 =A0 =A0</udp>

=A0 =A0</server>

=A0 =A0<server>

=A0 =A0 =A0<address>1.1.1.1</address>

=A0 =A0 =A0<udp>

=A0 =A0 =A0 =A0<authentication-port>1645</authentication-port><=
br>
=A0 =A0 =A0</udp>

=A0 =A0</server>



=A0 =A0Note that this also applies to the other lists keyed by simply an
=A0 =A0address. (We may have to introduce names to refer to the endpoints
=A0 =A0if we want a simple key and transport extensibility).




I agree. =A0Named entri=
es are better IMO anyway.
Should there be a unique-stmt for the a=
ddr:port pair?
(no changes)

=A0


=A0 =A0I also find the separation of the udp port from the address

=A0 =A0strange. =A0I can't have something like this either (if I want t=
o add

=A0 =A0tcp support):



=A0 =A0<server>

=A0 =A0 =A0<address>1.1.1.1</address>

=A0 =A0 =A0<udp>

=A0 =A0 =A0 =A0<authentication-port>1812</authentication-port><=
br>
=A0 =A0 =A0</udp>

=A0 =A0</server>

=A0 =A0<server>

=A0 =A0 =A0<address>1.1.1.1</address>

=A0 =A0 =A0<tcp>

=A0 =A0 =A0 =A0<authentication-port>1645</authentication-port><=
br>
=A0 =A0 =A0</tcp>

=A0 =A0</server>



=A0 =A0For me, it would make more sense leave the address and port number
=A0 =A0together and to support something like this.



=A0 =A0<server>

=A0 =A0 =A0<authentication>

=A0 =A0 =A0 =A0<udp>

=A0 =A0 =A0 =A0 =A0<address>1.1.1.1</address>

=A0 =A0 =A0 =A0 =A0<port>1812</port>

=A0 =A0 =A0 =A0</udp>

=A0 =A0 =A0 =A0<udp>

=A0 =A0 =A0 =A0 =A0<address>1.1.1.1</address>

=A0 =A0 =A0 =A0 =A0<port>1645</port>

=A0 =A0 =A0 =A0</udp>

=A0 =A0 =A0 =A0<tcp>

=A0 =A0 =A0 =A0 =A0<address>1.1.1.1</address>

=A0 =A0 =A0 =A0 =A0<port>1645</port>

=A0 =A0 =A0 =A0</tcp>

=A0 =A0 =A0<authentication>

=A0 =A0</server>



I agree. Need WG to decide. I will lea=
ve for Martin to fix.

=A0


u) Please update the security considerations boilerplate so that we

=A0 =A0have an explicit reference to the access control model.



fixed

=A0

v) Where you list readable subtrees, I think it is fair to explicitly

=A0 =A0mention the local users subtree and the passwords contained in that<=
br>
=A0 =A0subtree.

fixed
=A0



w) Are really all references normative? For example, RFC 6557 or RFC

=A0 =A03688?



fixed
=A0

/js



Andy





--047d7b10c853c0528a04dceeb7b0--

From j.schoenwaelder@jacobs-university.de  Fri May 17 13:09: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 E51D021F8F38 for ; Fri, 17 May 2013 13:09:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.854
X-Spam-Level: 
X-Spam-Status: No, score=-102.854 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_15=0.6, 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 nsmPNApoX1aX for ; Fri, 17 May 2013 13:09:48 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0250F21F8E49 for ; Fri, 17 May 2013 13:09:43 -0700 (PDT)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3A6FD20BFB; Fri, 17 May 2013 22:09:42 +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 IzwOPOpGd8vA; Fri, 17 May 2013 22:09:42 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2F6F720BEC; Fri, 17 May 2013 22:09:40 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 27AC82653664; Fri, 17 May 2013 22:09:39 +0200 (CEST)
Date: Fri, 17 May 2013 22:09:39 +0200
From: Juergen Schoenwaelder 
To: "t.petch" 
Message-ID: <20130517200939.GC33350@elstar.local>
Mail-Followup-To: "t.petch" , Ladislav Lhotka , netmod@ietf.org
References: <20130515140353.15940.12042.idtracker@ietfa.amsl.com> <20130515.160512.1630408467051717643.mbj@tail-f.com> <03c901ce5302$e4038900$4001a8c0@gateway.2wire.net> <232D1627-3861-45E8-BF51-A7191BD15477@nic.cz> <005801ce5322$d91be300$4001a8c0@gateway.2wire.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <005801ce5322$d91be300$4001a8c0@gateway.2wire.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-11.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: Fri, 17 May 2013 20:09:54 -0000

On Fri, May 17, 2013 at 06:20:15PM +0100, t.petch wrote:
> 
> I propose changing 3.1
> OLD
> " The data model for interfaces presented in this document uses a flat
>    list of interfaces.  Each interface in the list is identified by its
>    name.  Furthermore, each interface has a mandatory "type" leaf.
> 
>    There is one list of configured interfaces ("/interfaces/interface"),
>    and a separate list for the operational state of all interfaces
>    ("/interfaces-state/interface")."
> 
> NEW
> " The data model for interfaces presented in this document uses two flat
>    lists of interfaces.  An interface in a list is identified by its
>    name; each entry has a mandatory "type" leaf.  One list consists of
>    state, the other of configured information.
> 
> One list, /interfaces-state/interface, is initially populated by the
> server, creating entries therein.  Subsequently, the client may create
> an entry with the same name in the other list, /interfaces/interface,
> and then edit that entry in order to amend the configuration of that
> interface.

I think the word 'amend' is wrong because the config data is not
amending the state data.

> If the client creates an entry with a different name in
> /interfaces/interface, and that entry is acceptable to the server, then
> the server creates a corresponding entry in /interfaces-state/interface
> Thus the entries in /interfaces/interface are a strict subset of
> /interfaces-state/interface (apart from any transient conditions when an
> entry is being created or deleted).
> "

Strict subset is wrong because I can pre-provision config for physical
interfaces that are not there yet, for example.

/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  Sun May 19 13:15: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 1E64121F8EAE for ; Sun, 19 May 2013 13:15:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.368
X-Spam-Level: 
X-Spam-Status: No, score=-1.368 tagged_above=-999 required=5 tests=[AWL=0.078,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_15=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 fn+qhmb2BmJY for ; Sun, 19 May 2013 13:15:36 -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 5B1EF21F8E46 for ; Sun, 19 May 2013 13:15:36 -0700 (PDT)
Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 7ACE21200050; Sun, 19 May 2013 22:15:34 +0200 (CEST)
Date: Sun, 19 May 2013 22:15:34 +0200 (CEST)
Message-Id: <20130519.221534.518464544.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: <232D1627-3861-45E8-BF51-A7191BD15477@nic.cz>
References: <20130515.160512.1630408467051717643.mbj@tail-f.com> <03c901ce5302$e4038900$4001a8c0@gateway.2wire.net> <232D1627-3861-45E8-BF51-A7191BD15477@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-interfaces-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: Sun, 19 May 2013 20:15:41 -0000

Ladislav Lhotka  wrote:
> 
> On May 17, 2013, at 3:31 PM, t.petch  wrote:
> 
> > ----- Original Message -----
> > From: "Martin Bjorklund" 
> > To: 
> > Sent: Wednesday, May 15, 2013 3:05 PM
> > Subject: Re: [netmod] I-D Action:
> > draft-ietf-netmod-interfaces-cfg-11.txt
> > 
> > 
> >> Hi,
> >> 
> >> During the IETF LC, we got quite a few comments on document
> >> draft-ietf-netmod-interfaces-cfg-10.
> >> 
> >> See for example the threads
> >> 
> >> http://www.ietf.org/mail-archive/web/ietf/current/msg78801.html
> >> (my reply:
> >> http://www.ietf.org/mail-archive/web/ietf/current/msg78945.html)
> >> 
> >> and
> >> 
> >> http://www.ietf.org/mail-archive/web/netmod/current/msg08035.html
> > 
> > Martin
> > 
> > One of the comments in this review was
> > 
> > 'It is interesting that these design criteria do not call out the
> > applicability to "physical" and "virtual" interfaces. Moreover, the text
> > above seems to imply that the only "dynamic creation and deletion" of
> > interfaces happens with the "addition and removal of physical
> > interfaces" and does not call out tunnels, loopbacks, virtuals, and
> > other logical entities instantiated as "interfaces".'
> > 
> > which I do not think was addressed and which in turn left me uncertain
> > what you mean by physical and logical.
> > 
> > From elsewhere, I have the sense that physical is there for interfaces
> > where the system has an idea of the relevant information, such as naming
> > it ser2, whether or not it is something physical or distinct, so that
> > the act of configuration is constrained by what the system has already
> > done - if a system with an X.25 card predefines 4000 VC, are they then
> > physical? - whereas if the agent can choose the details to suit itself
> > "If the device supports arbitrarily named logical interfaces,"
> > then does that make them logical?
> 
> My understanding is that physical interfaces are those that the device creates
> on its own, gives them a name and initialises them to some default state. These
> interfaces appear originally as entries under /interfaces-state. Now, if a
> client wants to reconfigure such an interface (which may include activating
> it), he has to create an entry with the same name under /interfaces (i.e.,
> configuration) and specify the changes.
> 
> In contrast, the originator for a logical interface is a client who creates
> first a config entry for it under /interfaces. If the server accepts this
> configuration, it then creates the corresponding entry with the same name under

Yes.  The property of being physical or logical is tied to the
interface type.  I agree that the term "physical" might be misleading,
esp. these days with virtualization.  A device might have a "virtual
physical" ethernet interface...  But it behaves as a proper physical
interface.

A logical interface is really not(physical).


/martin

From j.schoenwaelder@jacobs-university.de  Sun May 19 16:12: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 E8FFC21F842F for ; Sun, 19 May 2013 16:12:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.844
X-Spam-Level: 
X-Spam-Status: No, score=-102.844 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_15=0.6, 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 JmDLaq3vaFmt for ; Sun, 19 May 2013 16:12: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 352CE21F8EA5 for ; Sun, 19 May 2013 16:12:31 -0700 (PDT)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1091220BDB; Mon, 20 May 2013 01:12:30 +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 g0dM-5Myy6GV; Mon, 20 May 2013 01:12:29 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 781C920BD6; Mon, 20 May 2013 01:12:29 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 6DC712657C97; Mon, 20 May 2013 01:12:28 +0200 (CEST)
Date: Mon, 20 May 2013 01:12:28 +0200
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20130519231228.GB3961@elstar.local>
Mail-Followup-To: Martin Bjorklund , lhotka@nic.cz, netmod@ietf.org
References: <20130515.160512.1630408467051717643.mbj@tail-f.com> <03c901ce5302$e4038900$4001a8c0@gateway.2wire.net> <232D1627-3861-45E8-BF51-A7191BD15477@nic.cz> <20130519.221534.518464544.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20130519.221534.518464544.mbj@tail-f.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-11.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: Sun, 19 May 2013 23:12:36 -0000

On Sun, May 19, 2013 at 10:15:34PM +0200, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
> > 
> > On May 17, 2013, at 3:31 PM, t.petch  wrote:
> > 
> > > ----- Original Message -----
> > > From: "Martin Bjorklund" 
> > > To: 
> > > Sent: Wednesday, May 15, 2013 3:05 PM
> > > Subject: Re: [netmod] I-D Action:
> > > draft-ietf-netmod-interfaces-cfg-11.txt
> > > 
> > > 
> > >> Hi,
> > >> 
> > >> During the IETF LC, we got quite a few comments on document
> > >> draft-ietf-netmod-interfaces-cfg-10.
> > >> 
> > >> See for example the threads
> > >> 
> > >> http://www.ietf.org/mail-archive/web/ietf/current/msg78801.html
> > >> (my reply:
> > >> http://www.ietf.org/mail-archive/web/ietf/current/msg78945.html)
> > >> 
> > >> and
> > >> 
> > >> http://www.ietf.org/mail-archive/web/netmod/current/msg08035.html
> > > 
> > > Martin
> > > 
> > > One of the comments in this review was
> > > 
> > > 'It is interesting that these design criteria do not call out the
> > > applicability to "physical" and "virtual" interfaces. Moreover, the text
> > > above seems to imply that the only "dynamic creation and deletion" of
> > > interfaces happens with the "addition and removal of physical
> > > interfaces" and does not call out tunnels, loopbacks, virtuals, and
> > > other logical entities instantiated as "interfaces".'
> > > 
> > > which I do not think was addressed and which in turn left me uncertain
> > > what you mean by physical and logical.
> > > 
> > > From elsewhere, I have the sense that physical is there for interfaces
> > > where the system has an idea of the relevant information, such as naming
> > > it ser2, whether or not it is something physical or distinct, so that
> > > the act of configuration is constrained by what the system has already
> > > done - if a system with an X.25 card predefines 4000 VC, are they then
> > > physical? - whereas if the agent can choose the details to suit itself
> > > "If the device supports arbitrarily named logical interfaces,"
> > > then does that make them logical?
> > 
> > My understanding is that physical interfaces are those that the device creates
> > on its own, gives them a name and initialises them to some default state. These
> > interfaces appear originally as entries under /interfaces-state. Now, if a
> > client wants to reconfigure such an interface (which may include activating
> > it), he has to create an entry with the same name under /interfaces (i.e.,
> > configuration) and specify the changes.
> > 
> > In contrast, the originator for a logical interface is a client who creates
> > first a config entry for it under /interfaces. If the server accepts this
> > configuration, it then creates the corresponding entry with the same name under
> 
> Yes.  The property of being physical or logical is tied to the
> interface type.

You mean type as /interfaces/interface/type? If so, are you sure this
statement would generally be true?

> I agree that the term "physical" might be misleading,
> esp. these days with virtualization.  A device might have a "virtual
> physical" ethernet interface...  But it behaves as a proper physical
> interface.
> 
> A logical interface is really not(physical).

RFC 2863 actually has this piece of text:

   While some interfaces, for example, most physical interfaces, cannot
   be created via network management, other interfaces such as logical
   interfaces sometimes can be.

I think this is important: physical interface are simply there (or
appear/disappear by installing/removing pieces of hardware) while
logical interfaces are instantiated (created and deleted) via
configuration.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From lhotka@nic.cz  Mon May 20 01:59:17 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 E491321F8618 for ; Mon, 20 May 2013 01:59:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level: 
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0NJ++pFGWrS for ; Mon, 20 May 2013 01:59:15 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 66BF221F919D for ; Mon, 20 May 2013 01:22:00 -0700 (PDT)
Received: from [IPv6:2001:1488:ac14:1400:6c3e:510b:a2e:39d6] (unknown [IPv6:2001:1488:ac14:1400:6c3e:510b:a2e:39d6]) by mail.nic.cz (Postfix) with ESMTPSA id 1449413FA1F; Mon, 20 May 2013 10:21:22 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1369038082; bh=BQFKH/LFANe/RDyYeL4P87Zw6pxe1xxmbloZoWACVfc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=SZ4p59S3AcsrbBoX1h5DZgEeK2fzV7F0+ZE3f4vsLOwz7BYPUJhVMzFJeIa8iRVxM zQ0jBObPzzHdG7pNwe9x+Zk2LPuNhLioGOmHn3hXbbkOvyIS6OgSsoKY/TaxMPQTp+ csM/Soia1SCX1AxdPe0eivGL3imTP9prQXx6GI5o=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: <20130519231228.GB3961@elstar.local>
Date: Mon, 20 May 2013 10:21:24 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20130515.160512.1630408467051717643.mbj@tail-f.com> <03c901ce5302$e4038900$4001a8c0@gateway.2wire.net> <232D1627-3861-45E8-BF51-A7191BD15477@nic.cz> <20130519.221534.518464544.mbj@tail-f.com> <20130519231228.GB3961@elstar.local>
To: Juergen Schoenwaelder 
X-Mailer: Apple Mail (2.1503)
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-interfaces-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: Mon, 20 May 2013 08:59:18 -0000

On May 20, 2013, at 1:12 AM, Juergen Schoenwaelder =
 wrote:

> On Sun, May 19, 2013 at 10:15:34PM +0200, Martin Bjorklund wrote:
>> Ladislav Lhotka  wrote:
>>>=20
>>> On May 17, 2013, at 3:31 PM, t.petch  wrote:
>>>=20
>>>> ----- Original Message -----
>>>> From: "Martin Bjorklund" 
>>>> To: 
>>>> Sent: Wednesday, May 15, 2013 3:05 PM
>>>> Subject: Re: [netmod] I-D Action:
>>>> draft-ietf-netmod-interfaces-cfg-11.txt
>>>>=20
>>>>=20
>>>>> Hi,
>>>>>=20
>>>>> During the IETF LC, we got quite a few comments on document
>>>>> draft-ietf-netmod-interfaces-cfg-10.
>>>>>=20
>>>>> See for example the threads
>>>>>=20
>>>>> http://www.ietf.org/mail-archive/web/ietf/current/msg78801.html
>>>>> (my reply:
>>>>> http://www.ietf.org/mail-archive/web/ietf/current/msg78945.html)
>>>>>=20
>>>>> and
>>>>>=20
>>>>> http://www.ietf.org/mail-archive/web/netmod/current/msg08035.html
>>>>=20
>>>> Martin
>>>>=20
>>>> One of the comments in this review was
>>>>=20
>>>> 'It is interesting that these design criteria do not call out the
>>>> applicability to "physical" and "virtual" interfaces. Moreover, the =
text
>>>> above seems to imply that the only "dynamic creation and deletion" =
of
>>>> interfaces happens with the "addition and removal of physical
>>>> interfaces" and does not call out tunnels, loopbacks, virtuals, and
>>>> other logical entities instantiated as "interfaces".'
>>>>=20
>>>> which I do not think was addressed and which in turn left me =
uncertain
>>>> what you mean by physical and logical.
>>>>=20
>>>> =46rom elsewhere, I have the sense that physical is there for =
interfaces
>>>> where the system has an idea of the relevant information, such as =
naming
>>>> it ser2, whether or not it is something physical or distinct, so =
that
>>>> the act of configuration is constrained by what the system has =
already
>>>> done - if a system with an X.25 card predefines 4000 VC, are they =
then
>>>> physical? - whereas if the agent can choose the details to suit =
itself
>>>> "If the device supports arbitrarily named logical interfaces,"
>>>> then does that make them logical?
>>>=20
>>> My understanding is that physical interfaces are those that the =
device creates
>>> on its own, gives them a name and initialises them to some default =
state. These
>>> interfaces appear originally as entries under /interfaces-state. =
Now, if a
>>> client wants to reconfigure such an interface (which may include =
activating
>>> it), he has to create an entry with the same name under /interfaces =
(i.e.,
>>> configuration) and specify the changes.
>>>=20
>>> In contrast, the originator for a logical interface is a client who =
creates
>>> first a config entry for it under /interfaces. If the server accepts =
this
>>> configuration, it then creates the corresponding entry with the same =
name under
>>=20
>> Yes.  The property of being physical or logical is tied to the
>> interface type.
>=20
> You mean type as /interfaces/interface/type? If so, are you sure this
> statement would generally be true?
>=20
>> I agree that the term "physical" might be misleading,
>> esp. these days with virtualization.  A device might have a "virtual
>> physical" ethernet interface...  But it behaves as a proper physical
>> interface.
>>=20
>> A logical interface is really not(physical).
>=20
> RFC 2863 actually has this piece of text:
>=20
>   While some interfaces, for example, most physical interfaces, cannot
>   be created via network management, other interfaces such as logical
>   interfaces sometimes can be.

Even this formulation indicates that physical/logical interfaces are =
only typical examples of two distinct classes of interfaces (which are =
not given names).

Lada

>=20
> I think this is important: physical interface are simply there (or
> appear/disappear by installing/removing pieces of hardware) while
> logical interfaces are instantiated (created and deleted) via
> configuration.
>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         

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





From mbj@tail-f.com  Mon May 20 03:26: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 8A83321F9080 for ; Mon, 20 May 2013 03:26:19 -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 DN0YqRlSc-dh for ; Mon, 20 May 2013 03:26:13 -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 355EF21F869A for ; Mon, 20 May 2013 03:26:13 -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 47E931200CB1; Mon, 20 May 2013 12:26:11 +0200 (CEST)
Date: Mon, 20 May 2013 12:26:11 +0200 (CEST)
Message-Id: <20130520.122611.344934490839637266.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: <232D1627-3861-45E8-BF51-A7191BD15477@nic.cz>
References: <20130515.160512.1630408467051717643.mbj@tail-f.com> <03c901ce5302$e4038900$4001a8c0@gateway.2wire.net> <232D1627-3861-45E8-BF51-A7191BD15477@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-interfaces-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: Mon, 20 May 2013 10:26:19 -0000

Ladislav Lhotka  wrote:
> My understanding is that physical interfaces are those that the device
> creates on its own, gives them a name and initialises them to some
> default state. These interfaces appear originally as entries under
> /interfaces-state. Now, if a client wants to reconfigure such an
> interface (which may include activating it), he has to create an entry
> with the same name under /interfaces (i.e., configuration) and specify
> the changes.
> 
> In contrast, the originator for a logical interface is a client who
> creates first a config entry for it under /interfaces. If the server
> accepts this configuration, it then creates the corresponding entry
> with the same name under /interfaces-state.

I think that logical interfaces can appear in the
/interfaces-state/interface list also in other cases; i.e., in cases
where there is no explcit configuration for the logical interface in
/interfaces/interface.  This could be as a side-effect from some other
configuration, or from some dynamic event.  In any case, I think it
would be wrong to state that the /interfaces-state/interface list
contains the physical interfaces detected by the system, plus a strict
subset of the logical interfaces in /interfaces/interface.

> Perhaps the adjectives "physical" and "logical" are somewhat
> misleading and something more neutral could be chosen instead.

Do you have any suggestions?


/martin

From lhotka@nic.cz  Mon May 20 03:33: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 209B221F90D2 for ; Mon, 20 May 2013 03:33:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=0.300, 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 qPAVAQbI5ICw for ; Mon, 20 May 2013 03:33:44 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7F321F90CD for ; Mon, 20 May 2013 03:33:44 -0700 (PDT)
Received: from [10.1.34.249] (nat-simple10.ntkcz.cz [195.113.241.226]) by mail.nic.cz (Postfix) with ESMTPSA id 903BC13FB0D; Mon, 20 May 2013 12:33:42 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1369046022; bh=Wm3SWVE2nbtNF9zVXT844krAXkuFrwL2JZs3liZuxDU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=fHU+9uSAXKKN+s3HB/RvhsQSi/ed+h5UhSjAuzfnI4L6HahL4YRkRD3W3w0HQye0g jefgxwU+xJXlHWfq69QdPWrLm/7RyGwouZQRW1WIK39gFwAqwcMWkVYXb271uXjd1C PbPDgjWbg4yJWKjraHRftNUbRlEAn2wzRhitJtME=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: <20130520.122611.344934490839637266.mbj@tail-f.com>
Date: Mon, 20 May 2013 12:33:41 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20130515.160512.1630408467051717643.mbj@tail-f.com> <03c901ce5302$e4038900$4001a8c0@gateway.2wire.net> <232D1627-3861-45E8-BF51-A7191BD15477@nic.cz> <20130520.122611.344934490839637266.mbj@tail-f.com>
To: Martin Bjorklund 
X-Mailer: Apple Mail (2.1503)
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-interfaces-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: Mon, 20 May 2013 10:33:46 -0000

On May 20, 2013, at 12:26 PM, Martin Bjorklund  wrote:

> Ladislav Lhotka  wrote:
>> My understanding is that physical interfaces are those that the =
device
>> creates on its own, gives them a name and initialises them to some
>> default state. These interfaces appear originally as entries under
>> /interfaces-state. Now, if a client wants to reconfigure such an
>> interface (which may include activating it), he has to create an =
entry
>> with the same name under /interfaces (i.e., configuration) and =
specify
>> the changes.
>>=20
>> In contrast, the originator for a logical interface is a client who
>> creates first a config entry for it under /interfaces. If the server
>> accepts this configuration, it then creates the corresponding entry
>> with the same name under /interfaces-state.
>=20
> I think that logical interfaces can appear in the
> /interfaces-state/interface list also in other cases; i.e., in cases
> where there is no explcit configuration for the logical interface in
> /interfaces/interface.  This could be as a side-effect from some other
> configuration, or from some dynamic event.  In any case, I think it
> would be wrong to state that the /interfaces-state/interface list
> contains the physical interfaces detected by the system, plus a strict
> subset of the logical interfaces in /interfaces/interface.
>=20
>> Perhaps the adjectives "physical" and "logical" are somewhat
>> misleading and something more neutral could be chosen instead.
>=20
> Do you have any suggestions?

Most technical terms will probably have unwanted connotations, so I am =
thinking about something really simple, like "outer" for physical and =
"inner" for logical.

Lada
=20
>=20
>=20
> /martin

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





From j.schoenwaelder@jacobs-university.de  Mon May 20 03:49: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 6054B21F8721 for ; Mon, 20 May 2013 03:49:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.135
X-Spam-Level: 
X-Spam-Status: No, score=-103.135 tagged_above=-999 required=5 tests=[AWL=0.114, 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 2-RBpWIDfiq8 for ; Mon, 20 May 2013 03:49:28 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D34C521F90F1 for ; Mon, 20 May 2013 03:49:25 -0700 (PDT)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D726820C01; Mon, 20 May 2013 12:49:24 +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 rz7Ovo4BI5wm; Mon, 20 May 2013 12:49:24 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4921A20BFF; Mon, 20 May 2013 12:49:24 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 92D9F2658D53; Mon, 20 May 2013 12:49:21 +0200 (CEST)
Date: Mon, 20 May 2013 12:49:21 +0200
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20130520104921.GA5578@elstar.local>
Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , netmod@ietf.org
References: <20130515.160512.1630408467051717643.mbj@tail-f.com> <03c901ce5302$e4038900$4001a8c0@gateway.2wire.net> <232D1627-3861-45E8-BF51-A7191BD15477@nic.cz> <20130520.122611.344934490839637266.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-interfaces-cfg-11.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: Mon, 20 May 2013 10:49:33 -0000

On Mon, May 20, 2013 at 12:33:41PM +0200, Ladislav Lhotka wrote:
> 
> Most technical terms will probably have unwanted connotations, so I
> am thinking about something really simple, like "outer" for physical
> and "inner" for logical.

Then I prefer foo and bar since people will speculate what is outer
and inner.

We used physical and logical because that is what IF-MIB is using.
Back in a day, this classification likely was easy to understand.

Physical interface: A network interface represented by a piece of
hardware (with a connector or an antenna) and forming the bottom
of an interface stack.

Logical interface: A network interface layered on top of a physical
interface or another logical interface typically created by network
management configuration.

Since the world have moved on, we have logical interfaces created by
other software services as side effects (that is not necessarily
explicitely configured as a network interface) and we have software
interfaces that are treated as physical interfaces say by a virtual
machine even though there is no physical hardware (e.g. a port of an
emulated Ethernet bridge). The question is how we factor these things
into the definitions. Lets start some wordsmithing:

Physical interface: A network interface represented by a piece of
hardware (with a connector or an antenna) and forming the bottom of an
interface stack. This may include virtual physical interfaces that
behave like physical interfaces even though they are provided by some
virtualization layer. Physical interfaces usually appear when
interface hardware is added/removed or when a virtualization system
is reconfigured.

Logical interface: A network interface layered on top of a physical
interface or another logical interface typically created by network
management configuration. Logical interfaces may also be introduced as
side effects of enabling certain services on a system. Logical
interfaces is that they usually appear and disappear related to their
configuration or a service enablement.

Now bash this quick proposal. ;-)

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From jonathan@hansfords.net  Mon May 20 03:54: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 37EC021F9029 for ; Mon, 20 May 2013 03:54:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 2sm7Eb82SqIH for ; Mon, 20 May 2013 03:54:35 -0700 (PDT)
Received: from avasout04.plus.net (avasout04.plus.net [212.159.14.19]) by ietfa.amsl.com (Postfix) with ESMTP id 954E521F9075 for ; Mon, 20 May 2013 03:54:34 -0700 (PDT)
Received: from webmail.plus.net ([84.93.237.98]) by avasout04 with smtp id eAuW1l006283uBY01AuY0n; Mon, 20 May 2013 11:54:32 +0100
X-CM-Score: 0.00
X-CNFS-Analysis: v=2.1 cv=TZ6v63gh c=1 sm=1 tr=0 a=BJaFPv9AyABFDM2hXLRoEA==:117 a=MEK23cO9Z3nTrtfM1ievvA==:17 a=0Bzu9jTXAAAA:8 a=lxldWUwtbAkA:10 a=dYCPD3cKDi0A:10 a=7RFjRx2dmFgA:10 a=0B8HqoTn75oA:10 a=IkcTkHD0fZMA:10 a=6bkCdLdQAAAA:8 a=f0uUZFObAAAA:8 a=Rmb-P1IsjlIA:10 a=sqQzhjMx1Cd25IzJyFgA:9 a=QEXdDO2ut3YA:10
X-AUTH: hansfords+us:2500
Received: from host-212-159-134-100.static.as13285.net ([212.159.134.100]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Mon, 20 May 2013 11:54:30 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Date: Mon, 20 May 2013 11:54:30 +0100
From: Jonathan Hansford 
To: Ladislav Lhotka , Martin Bjorklund , 
In-Reply-To: <20130520104921.GA5578@elstar.local>
References: <20130515.160512.1630408467051717643.mbj@tail-f.com> <03c901ce5302$e4038900$4001a8c0@gateway.2wire.net> <232D1627-3861-45E8-BF51-A7191BD15477@nic.cz> <20130520.122611.344934490839637266.mbj@tail-f.com>  <20130520104921.GA5578@elstar.local>
Message-ID: 
X-Sender: Jonathan@hansfords.net
User-Agent: Roundcube Webmail/0.7.4
X-Originating-IP: [212.159.134.100]
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-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: Mon, 20 May 2013 10:54:41 -0000

On 2013-05-20 11:49, Juergen Schoenwaelder wrote:

> On Mon, May 20, 2013 at 12:33:41PM +0200, Ladislav Lhotka wrote:
>
>> Most technical terms will probably have unwanted connotations, so I 
>> am
>> thinking about something really simple, like "outer" for physical 
>> and
>> "inner" for logical.
>
> Then I prefer foo and bar since people will speculate what is outer
> and inner.
>
> We used physical and logical because that is what IF-MIB is using.
> Back in a day, this classification likely was easy to understand.
>
> Physical interface: A network interface represented by a piece of
> hardware (with a connector or an antenna) and forming the bottom
> of an interface stack.
>
> Logical interface: A network interface layered on top of a physical
> interface or another logical interface typically created by network
> management configuration.
>
> Since the world have moved on, we have logical interfaces created by
> other software services as side effects (that is not necessarily
> explicitely configured as a network interface) and we have software
> interfaces that are treated as physical interfaces say by a virtual
> machine even though there is no physical hardware (e.g. a port of an
> emulated Ethernet bridge). The question is how we factor these things
> into the definitions. Lets start some wordsmithing:
>
> Physical interface: A network interface represented by a piece of
> hardware (with a connector or an antenna) and forming the bottom of 
> an
> interface stack. This may include virtual physical interfaces that
> behave like physical interfaces even though they are provided by some
> virtualization layer. Physical interfaces usually appear when
> interface hardware is added/removed or when a virtualization system
> is reconfigured.
>
> Logical interface: A network interface layered on top of a physical
> interface or another logical interface typically created by network
> management configuration. Logical interfaces may also be introduced 
> as
> side effects of enabling certain services on a system. Logical
> interfaces is that they usually appear and disappear related to their
> configuration or a service enablement.

I struggle to make sense of this last sentence. Are there some words 
missing?

Jonathan

>
> Now bash this quick proposal. ;-)
>
> /js

From lhotka@nic.cz  Mon May 20 03:58: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 8C6EC21F9121 for ; Mon, 20 May 2013 03:58:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.849
X-Spam-Level: 
X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.150,  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 txeW1FB07nNr for ; Mon, 20 May 2013 03:58:57 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 45D6021F90D2 for ; Mon, 20 May 2013 03:58:57 -0700 (PDT)
Received: from [10.1.34.249] (nat-simple10.ntkcz.cz [195.113.241.226]) by mail.nic.cz (Postfix) with ESMTPSA id 8D39913FA1F; Mon, 20 May 2013 12:58:56 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1369047536; bh=08vM3N4kEd81pLUaNU9OfgpUWxFOCOiG3pJ458cGHE4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=A37o/rOzzQ52WtPEZNOSzLLHFNFHicxFYntGC1z6UpYgw0BzF5lIp1YZPjPmHXwQk JXWLrK5SeefHz4z57tM7tXPQ1B4s/SqDvukHEDR3aSRslJumA87dXqjbksII2nFoND 9U1zk6bUbfCecuk+FYV6sfPDUDrcjzsUQv44GeSI=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: <20130520104921.GA5578@elstar.local>
Date: Mon, 20 May 2013 12:58:56 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20130515.160512.1630408467051717643.mbj@tail-f.com> <03c901ce5302$e4038900$4001a8c0@gateway.2wire.net> <232D1627-3861-45E8-BF51-A7191BD15477@nic.cz> <20130520.122611.344934490839637266.mbj@tail-f.com>  <20130520104921.GA5578@elstar.local>
To: Juergen Schoenwaelder 
X-Mailer: Apple Mail (2.1503)
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-interfaces-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: Mon, 20 May 2013 10:58:58 -0000

On May 20, 2013, at 12:49 PM, Juergen Schoenwaelder =
 wrote:

> On Mon, May 20, 2013 at 12:33:41PM +0200, Ladislav Lhotka wrote:
>>=20
>> Most technical terms will probably have unwanted connotations, so I
>> am thinking about something really simple, like "outer" for physical
>> and "inner" for logical.
>=20
> Then I prefer foo and bar since people will speculate what is outer
> and inner.

=46rom the point of view of NETCONF, an outer interface comes from =
outside whereas an inner one has to be configured. But I think we have =
to provide definitions and not guarantee a truly intuitive meaning.

Lada

>=20
> We used physical and logical because that is what IF-MIB is using.
> Back in a day, this classification likely was easy to understand.
>=20
> Physical interface: A network interface represented by a piece of
> hardware (with a connector or an antenna) and forming the bottom
> of an interface stack.
>=20
> Logical interface: A network interface layered on top of a physical
> interface or another logical interface typically created by network
> management configuration.
>=20
> Since the world have moved on, we have logical interfaces created by
> other software services as side effects (that is not necessarily
> explicitely configured as a network interface) and we have software
> interfaces that are treated as physical interfaces say by a virtual
> machine even though there is no physical hardware (e.g. a port of an
> emulated Ethernet bridge). The question is how we factor these things
> into the definitions. Lets start some wordsmithing:
>=20
> Physical interface: A network interface represented by a piece of
> hardware (with a connector or an antenna) and forming the bottom of an
> interface stack. This may include virtual physical interfaces that
> behave like physical interfaces even though they are provided by some
> virtualization layer. Physical interfaces usually appear when
> interface hardware is added/removed or when a virtualization system
> is reconfigured.
>=20
> Logical interface: A network interface layered on top of a physical
> interface or another logical interface typically created by network
> management configuration. Logical interfaces may also be introduced as
> side effects of enabling certain services on a system. Logical
> interfaces is that they usually appear and disappear related to their
> configuration or a service enablement.
>=20
> Now bash this quick proposal. ;-)
>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         

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





From j.schoenwaelder@jacobs-university.de  Mon May 20 04:20:26 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 BF7E421F913E for ; Mon, 20 May 2013 04:20:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.14
X-Spam-Level: 
X-Spam-Status: No, score=-103.14 tagged_above=-999 required=5 tests=[AWL=0.109, 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 qUN6D423LJOi for ; Mon, 20 May 2013 04:20:20 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4F66821F9121 for ; Mon, 20 May 2013 04:20:18 -0700 (PDT)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id AB44D20C03; Mon, 20 May 2013 13:20:17 +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 nC-jvm6IRsio; Mon, 20 May 2013 13:20:17 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E0CAD20BEB; Mon, 20 May 2013 13:20:16 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id D1FE32658FC7; Mon, 20 May 2013 13:20:15 +0200 (CEST)
Date: Mon, 20 May 2013 13:20:15 +0200
From: Juergen Schoenwaelder 
To: Jonathan Hansford 
Message-ID: <20130520112015.GB5722@elstar.local>
Mail-Followup-To: Jonathan Hansford , Ladislav Lhotka , Martin Bjorklund , netmod@ietf.org
References: <20130515.160512.1630408467051717643.mbj@tail-f.com> <03c901ce5302$e4038900$4001a8c0@gateway.2wire.net> <232D1627-3861-45E8-BF51-A7191BD15477@nic.cz> <20130520.122611.344934490839637266.mbj@tail-f.com>  <20130520104921.GA5578@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-interfaces-cfg-11.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: Mon, 20 May 2013 11:20:26 -0000

On Mon, May 20, 2013 at 11:54:30AM +0100, Jonathan Hansford wrote:
> On 2013-05-20 11:49, Juergen Schoenwaelder wrote:
> 
> >On Mon, May 20, 2013 at 12:33:41PM +0200, Ladislav Lhotka wrote:
> >
> >>Most technical terms will probably have unwanted connotations,
> >>so I am
> >>thinking about something really simple, like "outer" for
> >>physical and
> >>"inner" for logical.
> >
> >Then I prefer foo and bar since people will speculate what is outer
> >and inner.
> >
> >We used physical and logical because that is what IF-MIB is using.
> >Back in a day, this classification likely was easy to understand.
> >
> >Physical interface: A network interface represented by a piece of
> >hardware (with a connector or an antenna) and forming the bottom
> >of an interface stack.
> >
> >Logical interface: A network interface layered on top of a physical
> >interface or another logical interface typically created by network
> >management configuration.
> >
> >Since the world have moved on, we have logical interfaces created by
> >other software services as side effects (that is not necessarily
> >explicitely configured as a network interface) and we have software
> >interfaces that are treated as physical interfaces say by a virtual
> >machine even though there is no physical hardware (e.g. a port of an
> >emulated Ethernet bridge). The question is how we factor these things
> >into the definitions. Lets start some wordsmithing:
> >
> >Physical interface: A network interface represented by a piece of
> >hardware (with a connector or an antenna) and forming the bottom
> >of an
> >interface stack. This may include virtual physical interfaces that
> >behave like physical interfaces even though they are provided by some
> >virtualization layer. Physical interfaces usually appear when
> >interface hardware is added/removed or when a virtualization system
> >is reconfigured.
> >
> >Logical interface: A network interface layered on top of a physical
> >interface or another logical interface typically created by network
> >management configuration. Logical interfaces may also be
> >introduced as
> >side effects of enabling certain services on a system. Logical
> >interfaces is that they usually appear and disappear related to their
> >configuration or a service enablement.
> 
> I struggle to make sense of this last sentence. Are there some words
> missing?
> 

s/is that they//

/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  Mon May 20 04:30:17 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 20E6021F9029 for ; Mon, 20 May 2013 04:30:17 -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 YpICPh4RSvbK for ; Mon, 20 May 2013 04:30:11 -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 5D95321F9223 for ; Mon, 20 May 2013 04:30:04 -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 53ED91200174; Mon, 20 May 2013 13:30:03 +0200 (CEST)
Date: Mon, 20 May 2013 13:30:03 +0200 (CEST)
Message-Id: <20130520.133003.1693188198827685068.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20130520104921.GA5578@elstar.local>
References: <20130520.122611.344934490839637266.mbj@tail-f.com>  <20130520104921.GA5578@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-interfaces-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: Mon, 20 May 2013 11:30:17 -0000

Juergen Schoenwaelder  wrote:
> On Mon, May 20, 2013 at 12:33:41PM +0200, Ladislav Lhotka wrote:
> > 
> > Most technical terms will probably have unwanted connotations, so I
> > am thinking about something really simple, like "outer" for physical
> > and "inner" for logical.
> 
> Then I prefer foo and bar since people will speculate what is outer
> and inner.
> 
> We used physical and logical because that is what IF-MIB is using.
> Back in a day, this classification likely was easy to understand.
> 
> Physical interface: A network interface represented by a piece of
> hardware (with a connector or an antenna) and forming the bottom
> of an interface stack.
> 
> Logical interface: A network interface layered on top of a physical
> interface or another logical interface typically created by network
> management configuration.
> 
> Since the world have moved on, we have logical interfaces created by
> other software services as side effects (that is not necessarily
> explicitely configured as a network interface) and we have software
> interfaces that are treated as physical interfaces say by a virtual
> machine even though there is no physical hardware (e.g. a port of an
> emulated Ethernet bridge). The question is how we factor these things
> into the definitions. Lets start some wordsmithing:

I like this idea, and I perfer to use the terms "physical" and
"logical".

> Physical interface: A network interface represented by a piece of
> hardware (with a connector or an antenna) and forming the bottom of an
> interface stack. This may include virtual physical interfaces that
> behave like physical interfaces even though they are provided by some
> virtualization layer. Physical interfaces usually appear when
                                                    ^^^^^^

What does this mean?  I think it means that it is detected by the
system and instantiated in /interfaces-state/interface.

> interface hardware is added/removed or when a virtualization system
> is reconfigured.
>
> Logical interface: A network interface layered on top of a physical
> interface or another logical interface typically created by network
> management configuration.

A loopback interface is not layered on top of another interface.

> Logical interfaces may also be introduced as
> side effects of enabling certain services on a system. Logical
> interfaces is that they usually appear and disappear related to their
> configuration or a service enablement.

I think the last sentence is redundant and can be removed.

I think it would also be useful to allow logical interfaces to appear
not only as a result of some management action - I don't think we
should unnecessarily constrain the defintion.


/martin

From j.schoenwaelder@jacobs-university.de  Mon May 20 06:12: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 A4F6921F9133 for ; Mon, 20 May 2013 06:12:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.145
X-Spam-Level: 
X-Spam-Status: No, score=-103.145 tagged_above=-999 required=5 tests=[AWL=0.104, 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 nom0jxCBZUOA for ; Mon, 20 May 2013 06:12:17 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D8BF521F9223 for ; Mon, 20 May 2013 06:12:16 -0700 (PDT)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 417E020BDD; Mon, 20 May 2013 15:12:16 +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 rAmZdcvD9VYl; Mon, 20 May 2013 15:12:16 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DDDC1205A3; Mon, 20 May 2013 15:12:14 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 28660265922F; Mon, 20 May 2013 15:12:12 +0200 (CEST)
Date: Mon, 20 May 2013 15:12:12 +0200
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20130520131212.GA5942@elstar.local>
Mail-Followup-To: Martin Bjorklund , lhotka@nic.cz, netmod@ietf.org
References: <20130520.122611.344934490839637266.mbj@tail-f.com>  <20130520104921.GA5578@elstar.local> <20130520.133003.1693188198827685068.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20130520.133003.1693188198827685068.mbj@tail-f.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-11.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: Mon, 20 May 2013 13:12:25 -0000

On Mon, May 20, 2013 at 01:30:03PM +0200, Martin Bjorklund wrote:
> 
> I like this idea, and I perfer to use the terms "physical" and
> "logical".
> 
> > Physical interface: A network interface represented by a piece of
> > hardware (with a connector or an antenna) and forming the bottom of an
> > interface stack. This may include virtual physical interfaces that
> > behave like physical interfaces even though they are provided by some
> > virtualization layer. Physical interfaces usually appear when
>                                                     ^^^^^^
> 
> What does this mean?  I think it means that it is detected by the
> system and instantiated in /interfaces-state/interface.

yes
 
> > interface hardware is added/removed or when a virtualization system
> > is reconfigured.

Trying to improve the text below.

> > Logical interface: A network interface layered on top of a physical
> > interface or another logical interface typically created by network
> > management configuration.
> 
> A loopback interface is not layered on top of another interface.
> 
> > Logical interfaces may also be introduced as
> > side effects of enabling certain services on a system. Logical
> > interfaces is that they usually appear and disappear related to their
> > configuration or a service enablement.
> 
> I think the last sentence is redundant and can be removed.
> 
> I think it would also be useful to allow logical interfaces to appear
> not only as a result of some management action - I don't think we
> should unnecessarily constrain the defintion.

This is why I include service enablement (which you suggested to
remove). Trying again:

  Physical interface: A network interface representing a piece of
  hardware and forming the bottom of an interface stack (e.g., an
  Ethernet interface). This may include virtual physical interfaces
  that behave like physical interfaces even though they are provided
  by some virtualization layer. Physical interfaces are usually
  detected by the system when they appear and removed by the system
  when they disappear. As such, the lifetime of the operational state
  of physical interfaces is typically determined by the system.

  Logical interface: A network interface which is either a pure
  software interface or an interface layered on top of a physical
  interface or another logical interface. Logical interfaces are
  either created and deleted by explicit configuration (e.g., VLAN
  interfaces on top of an Ethernet interface) or by enabling certain
  services (e.g., enabling an IP stack typically introduces a loopback
  interface). As such, the lifetime of the operational state of
  logical interfaces is typically determined by the configuration of
  the system. Of course, certain logical interfaces can only be
  instantiated successfully by the system if the underlying physical
  interfaces are present.

/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  Mon May 20 13:44: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 0BE6421F967F for ; Mon, 20 May 2013 13:44:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.676
X-Spam-Level: 
X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=0.370,  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 pjYZCQHzoj8o for ; Mon, 20 May 2013 13:44:19 -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 3927321F9674 for ; Mon, 20 May 2013 13:44:18 -0700 (PDT)
Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 6FACB1200043; Mon, 20 May 2013 22:44:16 +0200 (CEST)
Date: Mon, 20 May 2013 22:44:16 +0200 (CEST)
Message-Id: <20130520.224416.317396391.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20130520131212.GA5942@elstar.local>
References: <20130520104921.GA5578@elstar.local> <20130520.133003.1693188198827685068.mbj@tail-f.com> <20130520131212.GA5942@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-interfaces-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: Mon, 20 May 2013 20:44:24 -0000

Juergen Schoenwaelder  wrote:
> On Mon, May 20, 2013 at 01:30:03PM +0200, Martin Bjorklund wrote:
> > 
> > I like this idea, and I perfer to use the terms "physical" and
> > "logical".
> > 
> > > Physical interface: A network interface represented by a piece of
> > > hardware (with a connector or an antenna) and forming the bottom of an
> > > interface stack. This may include virtual physical interfaces that
> > > behave like physical interfaces even though they are provided by some
> > > virtualization layer. Physical interfaces usually appear when
> >                                                     ^^^^^^
> > 
> > What does this mean?  I think it means that it is detected by the
> > system and instantiated in /interfaces-state/interface.
> 
> yes
>  
> > > interface hardware is added/removed or when a virtualization system
> > > is reconfigured.
> 
> Trying to improve the text below.
> 
> > > Logical interface: A network interface layered on top of a physical
> > > interface or another logical interface typically created by network
> > > management configuration.
> > 
> > A loopback interface is not layered on top of another interface.
> > 
> > > Logical interfaces may also be introduced as
> > > side effects of enabling certain services on a system. Logical
> > > interfaces is that they usually appear and disappear related to their
> > > configuration or a service enablement.
> > 
> > I think the last sentence is redundant and can be removed.
> > 
> > I think it would also be useful to allow logical interfaces to appear
> > not only as a result of some management action - I don't think we
> > should unnecessarily constrain the defintion.
> 
> This is why I include service enablement (which you suggested to
> remove).

I just suggested to remove the last sentence; the sentence before also
mentioned "enabling certain services".  But anyway - I think your
proposal below is good, and I think it should be included in the
document.


/martin

 Trying again:
> 
>   Physical interface: A network interface representing a piece of
>   hardware and forming the bottom of an interface stack (e.g., an
>   Ethernet interface). This may include virtual physical interfaces
>   that behave like physical interfaces even though they are provided
>   by some virtualization layer. Physical interfaces are usually
>   detected by the system when they appear and removed by the system
>   when they disappear. As such, the lifetime of the operational state
>   of physical interfaces is typically determined by the system.
> 
>   Logical interface: A network interface which is either a pure
>   software interface or an interface layered on top of a physical
>   interface or another logical interface. Logical interfaces are
>   either created and deleted by explicit configuration (e.g., VLAN
>   interfaces on top of an Ethernet interface) or by enabling certain
>   services (e.g., enabling an IP stack typically introduces a loopback
>   interface). As such, the lifetime of the operational state of
>   logical interfaces is typically determined by the configuration of
>   the system. Of course, certain logical interfaces can only be
>   instantiated successfully by the system if the underlying physical
>   interfaces are present.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         
> 

From ietfc@btconnect.com  Tue May 21 01:11:22 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 5CDF321F979A for ; Tue, 21 May 2013 01:11:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.227
X-Spam-Level: 
X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, J_CHICKENPOX_15=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 Kpv5Uho5q3bP for ; Tue, 21 May 2013 01:11:16 -0700 (PDT)
Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0187.outbound.messaging.microsoft.com [213.199.154.187]) by ietfa.amsl.com (Postfix) with ESMTP id EC10D21F9795 for ; Tue, 21 May 2013 01:11:11 -0700 (PDT)
Received: from mail86-db8-R.bigfish.com (10.174.8.249) by DB8EHSOBE018.bigfish.com (10.174.4.81) with Microsoft SMTP Server id 14.1.225.23; Tue, 21 May 2013 08:11:10 +0000
Received: from mail86-db8 (localhost [127.0.0.1])	by mail86-db8-R.bigfish.com (Postfix) with ESMTP id 3C81F8C09F7; Tue, 21 May 2013 08:11:10 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.254.197; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0711HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -16
X-BigFish: PS-16(zz98dI9371I542I1432I1418Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275bh8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh304l1d11m1155h)
Received: from mail86-db8 (localhost.localdomain [127.0.0.1]) by mail86-db8 (MessageSwitch) id 1369123867277853_1914; Tue, 21 May 2013 08:11:07 +0000 (UTC)
Received: from DB8EHSMHS008.bigfish.com (unknown [10.174.8.230])	by mail86-db8.bigfish.com (Postfix) with ESMTP id 413A5300053; Tue, 21 May 2013 08:11:07 +0000 (UTC)
Received: from DB3PRD0711HT001.eurprd07.prod.outlook.com (157.56.254.197) by DB8EHSMHS008.bigfish.com (10.174.4.18) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 21 May 2013 08:11:05 +0000
Received: from AMXPRD0111HT003.eurprd01.prod.exchangelabs.com (157.56.250.117) by pod51017.outlook.com (10.255.183.34) with Microsoft SMTP Server (TLS) id 14.16.311.1; Tue, 21 May 2013 08:11:05 +0000
Message-ID: <006601ce55f9$f93c0140$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Juergen Schoenwaelder 
References: <20130515140353.15940.12042.idtracker@ietfa.amsl.com> <002901ce5226$412fa740$4001a8c0@gateway.2wire.net> <20130516113033.GA27666@elstar.local> <003d01ce522a$a288c720$4001a8c0@gateway.2wire.net> <20130516120659.GA27915@elstar.local> <009901ce523c$15ae8f80$4001a8c0@gateway.2wire.net> <20130516144450.GA28294@elstar.local>
Date: Tue, 21 May 2013 08:49:14 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.250.117]
X-OriginatorOrg: btconnect.com
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-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: Tue, 21 May 2013 08:11:22 -0000

----- Original Message -----
From: "Juergen Schoenwaelder" 
To: "t.petch" 
Cc: 
Sent: Thursday, May 16, 2013 3:44 PM
> On Thu, May 16, 2013 at 02:48:35PM +0100, t.petch wrote:
> > ----- Original Message -----
> > From: "Juergen Schoenwaelder" 
> > To: "t.petch" 
> > Cc: 
> > Sent: Thursday, May 16, 2013 1:06 PM
> > > On Thu, May 16, 2013 at 12:43:37PM +0100, t.petch wrote:
> > >
> > > Please read the document and then we can discuss on the basis of
what
> > > is in the document.
> >
> > I did, which means that I don't understand it.
> >
> > One example.  If I may hark back to SNMP, then a reference to ifName
is
> > unique whereas in YANG, a reference to 'name' is not.  Thus this I-D
> > defines two name objects, with no relationship defined in the model
> > between them, so when it says
> >
> >        | name                             | ifName                 |
> >
> > does it mean one, or the other or both or sometimes?  In YANG, you
> > really SHOULD say
> > /if:interfaces/if:interface/if:name
> > or some such, and not just name
>
> That ambiguity was already mentioned and will be fixed.
>
> In SNMP, an ifName may refer to multiple interfaces. See RFC 2863.
Hence
> I do not understand your uniqueness question.

Juergen

A reference to ifName is unique in the sense that that identifier is
unique in the namespace of objects in the mib.  By contrast, name in
'netconf' is something beyond ambiguous.  I think that users will have
to get used to using
 /interfaces/interface/name
or whatever the relevant path is, clumsy as I think that that is.

The other issue, from below, is that you are quoting from the
description clause whereas my expectation, set from reading many RFC
containing MIB modules, is that I will be able to get a good
understanding of  the module from sections 3 and 4.  Of course, the YANG
module will be extracted and needs to make sense by itself, so there
needs to be some duplication between the introductory sections and the
module itself (something that has long been the case with SNMP).  For
me,
it is not enough if you have to read the description clauses in order to
understand the broad thrust of the module.

Tom Petch

> > Or,
> >   "An interface is identified by its name, which is unique within
the
> >    server.  "
> > well there are two name objects, so this does not make sense to me.
>
> I think the relationship is explained in the description statement of
> /interfaces/name:
>
>          For physical interfaces, this leaf is the device-specific
>          name of the interface.  The 'config false' list
>          /interfaces-state/interface contains the currently
>          existing interfaces on the device.
>
>          When a configured logical interface is created by the
>          system, it is instantiated in the
>          /interface-state/interface list.  Since the name in that
>          list MAY be mapped to ifName by an implementation, such an
>          implementation MUST restrict the allowed values for this
>          leaf so that it matches the restrictions of ifName.
>
> Perhaps the 1st sentence in the second paragraph can be made clearer
> by saying:
>
>          When a configured logical interface is created by the
>          system, it is instantiated with the same name in the
>          /interface-state/interface list.
>
> > Or
> > /if:interfaces/if:interface/if:name
> > is rw while
> > /if:interfaces-state/if:interface/if:name
> > is ro and there is a "separate list for the operational state of all
> > interfaces".  All interfaces, I note, so what happens when I make a
typo
> > and write to
> > /if:interfaces/if:interface/if:name
> > a name that is not in
> > /if:interfaces-state/if:interface/if:name
> >
> > 'name' is key, literally and metaphorically, so not understanding
that,
> > well, I don't understand:-(
>
> Again, I think this situation is explained in the description
> statement of /interfaces/name.
>
>         If a client tries to create configuration for a physical
>         interface that is not present, the server MAY reject the
>         request, if the implementation does not support
>         pre-provisioning of interfaces, or if the name refers to
>         an interface that can never exist in the system.
>         A NETCONF server MUST reply with an rpc-error with the
>         error-tag 'invalid-value' in this case.
>
> /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 May 21 01:37: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 6893C21F96FC for ; Tue, 21 May 2013 01:37:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.849
X-Spam-Level: 
X-Spam-Status: No, score=-102.849 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_15=0.6, 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 szIIPsaqH3rN for ; Tue, 21 May 2013 01:36:58 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3FCC021F970A for ; Tue, 21 May 2013 01:36:58 -0700 (PDT)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1BF2120C0B; Tue, 21 May 2013 10:36:57 +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 LTwPpD9kxRz0; Tue, 21 May 2013 10:36:56 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1020420BFC; Tue, 21 May 2013 10:36:55 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 2DE53265B47B; Tue, 21 May 2013 10:36:52 +0200 (CEST)
Date: Tue, 21 May 2013 10:36:52 +0200
From: Juergen Schoenwaelder 
To: "t.petch" 
Message-ID: <20130521083652.GA8637@elstar.local>
Mail-Followup-To: "t.petch" , netmod@ietf.org
References: <20130515140353.15940.12042.idtracker@ietfa.amsl.com> <002901ce5226$412fa740$4001a8c0@gateway.2wire.net> <20130516113033.GA27666@elstar.local> <003d01ce522a$a288c720$4001a8c0@gateway.2wire.net> <20130516120659.GA27915@elstar.local> <009901ce523c$15ae8f80$4001a8c0@gateway.2wire.net> <20130516144450.GA28294@elstar.local> <006601ce55f9$f93c0140$4001a8c0@gateway.2wire.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <006601ce55f9$f93c0140$4001a8c0@gateway.2wire.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-11.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, 21 May 2013 08:37:03 -0000

On Tue, May 21, 2013 at 08:49:14AM +0100, t.petch wrote:

> The other issue, from below, is that you are quoting from the
> description clause whereas my expectation, set from reading many RFC
> containing MIB modules, is that I will be able to get a good
> understanding of  the module from sections 3 and 4.  Of course, the YANG
> module will be extracted and needs to make sense by itself, so there
> needs to be some duplication between the introductory sections and the
> module itself (something that has long been the case with SNMP).  For
> me, it is not enough if you have to read the description clauses in 
> order to understand the broad thrust of the module.

Perhaps you can send concrete text you think is missing since this
will help us finishing the document.

/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 May 21 02:06: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 7AA3121F97C2 for ; Tue, 21 May 2013 02:06:15 -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 BMjHeeGG6k+r for ; Tue, 21 May 2013 02:06:14 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE5721F97D0 for ; Tue, 21 May 2013 02:06:14 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 61B7C13F636; Tue, 21 May 2013 11:06:13 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1369127173; bh=5InmWCan3kPJHDYGAjIOPel3Vc2divY9h4huJ09iR6g=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=rZPwsN5EFUaHga3fuToBWOCi3L0BtXwwbsa1Sux1nqbeWP591zQEyB9pqb6qApEJs lBDiAHkv29uQlnuikzVA60SY0sQUDLTNirDZp0SVv79kyp7DcL+eDaYClomp4E6Ttw 5lz9UxLOBCJUKUvvIT8UB041+RcJW3xMzFswiyng=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: <20130520131212.GA5942@elstar.local>
Date: Tue, 21 May 2013 11:06:04 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20130520.122611.344934490839637266.mbj@tail-f.com>  <20130520104921.GA5578@elstar.local> <20130520.133003.1693188198827685068.mbj@tail-f.com> <20130520131212.GA5942@elstar.local>
To: Juergen Schoenwaelder 
X-Mailer: Apple Mail (2.1503)
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-interfaces-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: Tue, 21 May 2013 09:06:15 -0000

On May 20, 2013, at 3:12 PM, Juergen Schoenwaelder =
 wrote:

> On Mon, May 20, 2013 at 01:30:03PM +0200, Martin Bjorklund wrote:
>>=20
>> I like this idea, and I perfer to use the terms "physical" and
>> "logical".
>>=20
>>> Physical interface: A network interface represented by a piece of
>>> hardware (with a connector or an antenna) and forming the bottom of =
an
>>> interface stack. This may include virtual physical interfaces that
>>> behave like physical interfaces even though they are provided by =
some
>>> virtualization layer. Physical interfaces usually appear when
>>                                                    ^^^^^^
>>=20
>> What does this mean?  I think it means that it is detected by the
>> system and instantiated in /interfaces-state/interface.
>=20
> yes
>=20
>>> interface hardware is added/removed or when a virtualization system
>>> is reconfigured.
>=20
> Trying to improve the text below.
>=20
>>> Logical interface: A network interface layered on top of a physical
>>> interface or another logical interface typically created by network
>>> management configuration.
>>=20
>> A loopback interface is not layered on top of another interface.
>>=20
>>> Logical interfaces may also be introduced as
>>> side effects of enabling certain services on a system. Logical
>>> interfaces is that they usually appear and disappear related to =
their
>>> configuration or a service enablement.
>>=20
>> I think the last sentence is redundant and can be removed.
>>=20
>> I think it would also be useful to allow logical interfaces to appear
>> not only as a result of some management action - I don't think we
>> should unnecessarily constrain the defintion.
>=20
> This is why I include service enablement (which you suggested to
> remove). Trying again:
>=20
>  Physical interface: A network interface representing a piece of
>  hardware and forming the bottom of an interface stack (e.g., an
>  Ethernet interface). This may include virtual physical interfaces
>  that behave like physical interfaces even though they are provided
>  by some virtualization layer. Physical interfaces are usually
>  detected by the system when they appear and removed by the system
>  when they disappear. As such, the lifetime of the operational state
>  of physical interfaces is typically determined by the system.

I am not sure that the line can be drawn based on any properties or type =
of an interface, it may also depend on the purpose or scope of the data =
model. Consider a device where NETCONF is used for configuring only a =
certain service, and is expected to *use* any interfaces that are =
provided by the operating system in the same way, be it a physical =
interface or VLAN or a tunnel. The client may be able to configure IP =
addresses on such interfaces etc., but neither create new (logical) =
interfaces nor delete existing ones.=20

We are currently implementing NETCONF for a DNS server monitoring =
application and it is designed to work exactly like this.=20

So what IMO really matters is whether an interface entry is present in =
/interfaces-state even before any configuration is written. The client =
then has to deal with such an interface as if it was provided by "vis =
maior", very much like a real physical interface.

Lada

>=20
>  Logical interface: A network interface which is either a pure
>  software interface or an interface layered on top of a physical
>  interface or another logical interface. Logical interfaces are
>  either created and deleted by explicit configuration (e.g., VLAN
>  interfaces on top of an Ethernet interface) or by enabling certain
>  services (e.g., enabling an IP stack typically introduces a loopback
>  interface). As such, the lifetime of the operational state of
>  logical interfaces is typically determined by the configuration of
>  the system. Of course, certain logical interfaces can only be
>  instantiated successfully by the system if the underlying physical
>  interfaces are present.
>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         

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





From j.schoenwaelder@jacobs-university.de  Tue May 21 02:50: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 1AE9C21F882A for ; Tue, 21 May 2013 02:50:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.145
X-Spam-Level: 
X-Spam-Status: No, score=-103.145 tagged_above=-999 required=5 tests=[AWL=0.104, 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 futjVkHnfjVD for ; Tue, 21 May 2013 02:50:41 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id A687521F88AC for ; Tue, 21 May 2013 02:50:40 -0700 (PDT)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id AD69020BD5; Tue, 21 May 2013 11:50:38 +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 FzCt-heiehdM; Tue, 21 May 2013 11:50:38 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 120272062F; Tue, 21 May 2013 11:50:38 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id C480E265B8B6; Tue, 21 May 2013 11:50:35 +0200 (CEST)
Date: Tue, 21 May 2013 11:50:34 +0200
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20130521095034.GA8891@elstar.local>
Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , netmod@ietf.org
References: <20130520.122611.344934490839637266.mbj@tail-f.com>  <20130520104921.GA5578@elstar.local> <20130520.133003.1693188198827685068.mbj@tail-f.com> <20130520131212.GA5942@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-interfaces-cfg-11.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, 21 May 2013 09:50:48 -0000

On Tue, May 21, 2013 at 11:06:04AM +0200, Ladislav Lhotka wrote:
> 
> >  Physical interface: A network interface representing a piece of
> >  hardware and forming the bottom of an interface stack (e.g., an
> >  Ethernet interface). This may include virtual physical interfaces
> >  that behave like physical interfaces even though they are provided
> >  by some virtualization layer. Physical interfaces are usually
> >  detected by the system when they appear and removed by the system
> >  when they disappear. As such, the lifetime of the operational state
> >  of physical interfaces is typically determined by the system.
> 
> I am not sure that the line can be drawn based on any properties or type of an interface, it may also depend on the purpose or scope of the data model. Consider a device where NETCONF is used for configuring only a certain service, and is expected to *use* any interfaces that are provided by the operating system in the same way, be it a physical interface or VLAN or a tunnel. The client may be able to configure IP addresses on such interfaces etc., but neither create new (logical) interfaces nor delete existing ones. 
> 
> We are currently implementing NETCONF for a DNS server monitoring application and it is designed to work exactly like this. 
> 
> So what IMO really matters is whether an interface entry is present in /interfaces-state even before any configuration is written. The client then has to deal with such an interface as if it was provided by "vis maior", very much like a real physical interface.

I hear you saying that systems might have non-physical (that is
logical) interfaces that are kind of permanent or whose lifetime is
outside the control of NETCONF. Correct? Are you saying that the
distinction really is "system controlled interfaces" versus "config
controlled interfaces"? And where to interfaces belong that are
created as side effects, e.g. tun/tap interfaces created by an
application dynamically whenever that application is runing? Do we
have direct and indirect config controlled interfaces? Or is such a
tun/tap interface what you consider "system controlled" even though I
might be disable the function that creates such tun/tap interfaces?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From ietfc@btconnect.com  Tue May 21 02:55: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 EF64721F8956 for ; Tue, 21 May 2013 02:55:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.504
X-Spam-Level: 
X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[AWL=2.095,  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 c4EYcn6u6u+g for ; Tue, 21 May 2013 02:55:36 -0700 (PDT)
Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id A06E121F8D2E for ; Tue, 21 May 2013 02:55:36 -0700 (PDT)
Received: from mail150-co9-R.bigfish.com (10.236.132.235) by CO9EHSOBE011.bigfish.com (10.236.130.74) with Microsoft SMTP Server id 14.1.225.23; Tue, 21 May 2013 09:55:35 +0000
Received: from mail150-co9 (localhost [127.0.0.1])	by mail150-co9-R.bigfish.com (Postfix) with ESMTP id A7440360899; Tue, 21 May 2013 09:55:35 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.249.85; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0710HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -16
X-BigFish: PS-16(zz98dI9371I542I1432I1418Idb82hzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL8275bh8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh304l1d11m1155h)
Received: from mail150-co9 (localhost.localdomain [127.0.0.1]) by mail150-co9 (MessageSwitch) id 1369130133866236_19804; Tue, 21 May 2013 09:55:33 +0000 (UTC)
Received: from CO9EHSMHS026.bigfish.com (unknown [10.236.132.250])	by mail150-co9.bigfish.com (Postfix) with ESMTP id D1A0F32008A; Tue, 21 May 2013 09:55:33 +0000 (UTC)
Received: from AMSPRD0710HT003.eurprd07.prod.outlook.com (157.56.249.85) by CO9EHSMHS026.bigfish.com (10.236.130.36) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 21 May 2013 09:55:32 +0000
Received: from AMXPRD0111HT001.eurprd01.prod.exchangelabs.com (157.56.250.117) by pod51017.outlook.com (10.255.160.166) with Microsoft SMTP Server (TLS) id 14.16.311.1; Tue, 21 May 2013 09:54:54 +0000
Message-ID: <033c01ce5608$7a2204e0$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Martin Bjorklund 
References: <20130520104921.GA5578@elstar.local><20130520.133003.1693188198827685068.mbj@tail-f.com><20130520131212.GA5942@elstar.local> <20130520.224416.317396391.mbj@tail-f.com>
Date: Tue, 21 May 2013 10:45:06 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.250.117]
X-OriginatorOrg: btconnect.com
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-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: Tue, 21 May 2013 09:55:43 -0000

----- Original Message -----
From: "Martin Bjorklund" 
To: 
Cc: 
Sent: Monday, May 20, 2013 9:44 PM
> Juergen Schoenwaelder  wrote:
> > On Mon, May 20, 2013 at 01:30:03PM +0200, Martin Bjorklund wrote:
> > >
> > > I like this idea, and I perfer to use the terms "physical" and
> > > "logical".
> > >
> > > > Physical interface: A network interface represented by a piece
of
> > > > hardware (with a connector or an antenna) and forming the bottom
of an
> > > > interface stack. This may include virtual physical interfaces
that
> > > > behave like physical interfaces even though they are provided by
some
> > > > virtualization layer. Physical interfaces usually appear when
> > >                                                     ^^^^^^
> > >
> > > What does this mean?  I think it means that it is detected by the
> > > system and instantiated in /interfaces-state/interface.
> >
> > yes
> >
> > > > interface hardware is added/removed or when a virtualization
system
> > > > is reconfigured.
> >
> > Trying to improve the text below.
> >
> > > > Logical interface: A network interface layered on top of a
physical
> > > > interface or another logical interface typically created by
network
> > > > management configuration.
> > >
> > > A loopback interface is not layered on top of another interface.
> > >
> > > > Logical interfaces may also be introduced as
> > > > side effects of enabling certain services on a system. Logical
> > > > interfaces is that they usually appear and disappear related to
their
> > > > configuration or a service enablement.
> > >
> > > I think the last sentence is redundant and can be removed.
> > >
> > > I think it would also be useful to allow logical interfaces to
appear
> > > not only as a result of some management action - I don't think we
> > > should unnecessarily constrain the defintion.
> >
> > This is why I include service enablement (which you suggested to
> > remove).
>
> I just suggested to remove the last sentence; the sentence before also
> mentioned "enabling certain services".  But anyway - I think your
> proposal below is good, and I think it should be included in the
> document.

Martin

Something seems to happen when turning comments on the list into source
for the I-D:-(

Thus
"> > > What does this mean?  I think it means that it is detected by the
> > > system and instantiated in /interfaces-state/interface."

To me, that is a clear statement of what is fundamental to understanding
this I-D, what is 'physical' what is 'logical' - perhaps not ideal
terms, but no problem if well-defined.

"physical interfaces are those that the device creates on its own, gives
them a name and initialises them to some default state. These interfaces
appear originally as entries under /interfaces-state."

Again, clear and helpful.  Either statement would  much clarify the I-D.

By contrast,

"A network interface representing a piece of
 hardware and forming the bottom of an interface stack (e.g., an
 Ethernet interface."

"Physical interfaces are usually
 detected by the system when they appear and removed by the system
 when they disappear."

I find unhelpful.  The key, overwhelming, fundamental
point, in the context of netmod, is not that this is hardware, nor that
it is at the bottom of the stack.  It is that the system will
instantiate
it in
 /interfaces-state/interface/
I think that a user, to have any hope of understanding this module,
must grasp this and I do not think that they will with the sentences in
the order that they are and with the key point weakened by
'usually'.

If you know what definition means, then yes, you can read the meaning
into text; if you are unclear or uncertain, then I think you will
struggle.

Tom Petch

> /martin
>
>  Trying again:
> >
> >   Physical interface: A network interface representing a piece of
> >   hardware and forming the bottom of an interface stack (e.g., an
> >   Ethernet interface). This may include virtual physical interfaces
> >   that behave like physical interfaces even though they are provided
> >   by some virtualization layer. Physical interfaces are usually
> >   detected by the system when they appear and removed by the system
> >   when they disappear. As such, the lifetime of the operational
state
> >   of physical interfaces is typically determined by the system.
> >
> >   Logical interface: A network interface which is either a pure
> >   software interface or an interface layered on top of a physical
> >   interface or another logical interface. Logical interfaces are
> >   either created and deleted by explicit configuration (e.g., VLAN
> >   interfaces on top of an Ethernet interface) or by enabling certain
> >   services (e.g., enabling an IP stack typically introduces a
loopback
> >   interface). As such, the lifetime of the operational state of
> >   logical interfaces is typically determined by the configuration of
> >   the system. Of course, certain logical interfaces can only be
> >   instantiated successfully by the system if the underlying physical
> >   interfaces are present.
> >
> > /js
> >



From lhotka@nic.cz  Tue May 21 03:33:22 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 9334121F8CF4 for ; Tue, 21 May 2013 03:33:22 -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 a2Ur9QPsLXTx for ; Tue, 21 May 2013 03:33:21 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9E521F8CA0 for ; Tue, 21 May 2013 03:33:20 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id BF8EF13F636; Tue, 21 May 2013 12:33:19 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1369132399; bh=BvD7uUmTrWfXlFS8rYCxIL31hoFjM8lI1hhj2MGZRgg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=OjwsFolDH+EdlSXJz8X9FbicRtm41iwhBzpPgSNt3kbCWmOkTHrwkfGDCwlR4pdto 4L34b53/2olmsheCTUPZcj3MwxE9eqdRQZjOZ+sJ+5jJtJX5zcnd2GDoV6IoaE6aLf BMKRL950JL/409AIhU+kkR6vhDPW84CvI+TacTPg=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: <20130521095034.GA8891@elstar.local>
Date: Tue, 21 May 2013 12:33:19 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <5B49D298-C5DB-4745-9C56-A225DBCB16A5@nic.cz>
References: <20130520.122611.344934490839637266.mbj@tail-f.com>  <20130520104921.GA5578@elstar.local> <20130520.133003.1693188198827685068.mbj@tail-f.com> <20130520131212.GA5942@elstar.local>  <20130521095034.GA8891@elstar.local>
To: Juergen Schoenwaelder 
X-Mailer: Apple Mail (2.1503)
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-interfaces-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: Tue, 21 May 2013 10:33:22 -0000

On May 21, 2013, at 11:50 AM, Juergen Schoenwaelder =
 wrote:

> On Tue, May 21, 2013 at 11:06:04AM +0200, Ladislav Lhotka wrote:
>>=20
>>> Physical interface: A network interface representing a piece of
>>> hardware and forming the bottom of an interface stack (e.g., an
>>> Ethernet interface). This may include virtual physical interfaces
>>> that behave like physical interfaces even though they are provided
>>> by some virtualization layer. Physical interfaces are usually
>>> detected by the system when they appear and removed by the system
>>> when they disappear. As such, the lifetime of the operational state
>>> of physical interfaces is typically determined by the system.
>>=20
>> I am not sure that the line can be drawn based on any properties or =
type of an interface, it may also depend on the purpose or scope of the =
data model. Consider a device where NETCONF is used for configuring only =
a certain service, and is expected to *use* any interfaces that are =
provided by the operating system in the same way, be it a physical =
interface or VLAN or a tunnel. The client may be able to configure IP =
addresses on such interfaces etc., but neither create new (logical) =
interfaces nor delete existing ones.=20
>>=20
>> We are currently implementing NETCONF for a DNS server monitoring =
application and it is designed to work exactly like this.=20
>>=20
>> So what IMO really matters is whether an interface entry is present =
in /interfaces-state even before any configuration is written. The =
client then has to deal with such an interface as if it was provided by =
"vis maior", very much like a real physical interface.
>=20
> I hear you saying that systems might have non-physical (that is
> logical) interfaces that are kind of permanent or whose lifetime is
> outside the control of NETCONF. Correct? Are you saying that the

Correct.

> distinction really is "system controlled interfaces" versus "config
> controlled interfaces"? And where to interfaces belong that are

Yes, but only in the context of the interfaces module. That is:

- system-controlled interfaces are those that appear in =
/interfaces-state
  before the corresponding entry has been created in /interfaces.

- config-controlled interfaces are those that have to be configured as =
an entry under /interfaces, otherwise they don't exist.

This distinction is important because it affects the relationship =
between the "name" leaves, i. e. the keys of the lists =
/interfaces-state/interface and /interfaces/interface.

> created as side effects, e.g. tun/tap interfaces created by an
> application dynamically whenever that application is runing? Do we
> have direct and indirect config controlled interfaces? Or is such a
> tun/tap interface what you consider "system controlled" even though I
> might be disable the function that creates such tun/tap interfaces?

Yes, if a logical interface is created as a side effect of other =
configuration, then, from the point of view of the interfaces module, is =
a system-controlled interface. So perhaps a more appropriate name would =
be "elsewhere-controlled".

Lada


>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         

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





From j.schoenwaelder@jacobs-university.de  Tue May 21 03:57: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 B533121F964C for ; Tue, 21 May 2013 03:57:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.149
X-Spam-Level: 
X-Spam-Status: No, score=-103.149 tagged_above=-999 required=5 tests=[AWL=0.100, 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 BngTp2kVcvSk for ; Tue, 21 May 2013 03:57:38 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6E00421F9670 for ; Tue, 21 May 2013 03:57:36 -0700 (PDT)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D977C20BFF; Tue, 21 May 2013 12:57:35 +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 F_7yvVmCfcVo; Tue, 21 May 2013 12:57:35 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1236E20BFD; Tue, 21 May 2013 12:57:34 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id D1F6D265BBCD; Tue, 21 May 2013 12:57:33 +0200 (CEST)
Date: Tue, 21 May 2013 12:57:33 +0200
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20130521105733.GA9110@elstar.local>
Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , netmod@ietf.org
References: <20130520.122611.344934490839637266.mbj@tail-f.com>  <20130520104921.GA5578@elstar.local> <20130520.133003.1693188198827685068.mbj@tail-f.com> <20130520131212.GA5942@elstar.local>  <20130521095034.GA8891@elstar.local> <5B49D298-C5DB-4745-9C56-A225DBCB16A5@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5B49D298-C5DB-4745-9C56-A225DBCB16A5@nic.cz>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-11.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, 21 May 2013 10:57:43 -0000

On Tue, May 21, 2013 at 12:33:19PM +0200, Ladislav Lhotka wrote:
> 
> > I hear you saying that systems might have non-physical (that is
> > logical) interfaces that are kind of permanent or whose lifetime is
> > outside the control of NETCONF. Correct? Are you saying that the
> 
> Correct.
> 
> > distinction really is "system controlled interfaces" versus "config
> > controlled interfaces"? And where to interfaces belong that are
> 
> Yes, but only in the context of the interfaces module. That is:
>
> - system-controlled interfaces are those that appear in /interfaces-state
>   before the corresponding entry has been created in /interfaces.

And here it is already getting wrong because we want to support
preprovisioning.
 
> - config-controlled interfaces are those that have to be configured as an entry under /interfaces, otherwise they don't exist.
> 
> This distinction is important because it affects the relationship between the "name" leaves, i. e. the keys of the lists /interfaces-state/interface and /interfaces/interface.

But then I think the text in the description clauses (with the minor
tweaks discussed here) is actually explaining this reasonably well,
no?

> > created as side effects, e.g. tun/tap interfaces created by an
> > application dynamically whenever that application is runing? Do we
> > have direct and indirect config controlled interfaces? Or is such a
> > tun/tap interface what you consider "system controlled" even though I
> > might be disable the function that creates such tun/tap interfaces?
> 
> Yes, if a logical interface is created as a side effect of other configuration, then, from the point of view of the interfaces module, is a system-controlled interface. So perhaps a more appropriate name would be "elsewhere-controlled".
>

We can perhaps define system-controlled in such a way that these
elsewhere-controlled interfaces are included. So we have
system-controlled interfaces vs interface-config-controlled
interfaces?

/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 May 21 04:30: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 B778421F969F for ; Tue, 21 May 2013 04:30:46 -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 BQpOlkoshCJd for ; Tue, 21 May 2013 04:30: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 C056221F911B for ; Tue, 21 May 2013 04:30: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 0D2D213F636; Tue, 21 May 2013 13:30:45 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1369135845; bh=aLnZq8w5pAoi52kyVgQ+/OZCk1Ywq+ot72I4Ik5Mm54=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=jpoCfjntKsDY2yIenZulzLvsQipIdwegS0lml0ArjcfHiplFxlxKKaFOzBuQGQVE7 5xss+opykFEbeTt/nvqk4pgjId3KeO2FECRHYNfHAXWXOD5ac7Ed0tak43NKrtBAvr AfvkCBiNC2t2aQGIsL4FGF+hD2SM0jhNCaNxggj0=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: <20130521105733.GA9110@elstar.local>
Date: Tue, 21 May 2013 13:30:34 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <3B70300A-9B75-44E8-8DE3-4B19B38E41BC@nic.cz>
References: <20130520.122611.344934490839637266.mbj@tail-f.com>  <20130520104921.GA5578@elstar.local> <20130520.133003.1693188198827685068.mbj@tail-f.com> <20130520131212.GA5942@elstar.local>  <20130521095034.GA8891@elstar.local> <5B49D298-C5DB-4745-9C56-A225DBCB16A5@nic.cz> <20130521105733.GA9110@elstar.local>
To: Juergen Schoenwaelder 
X-Mailer: Apple Mail (2.1503)
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-interfaces-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: Tue, 21 May 2013 11:30:46 -0000

On May 21, 2013, at 12:57 PM, Juergen Schoenwaelder =
 wrote:

> On Tue, May 21, 2013 at 12:33:19PM +0200, Ladislav Lhotka wrote:
>>=20
>>> I hear you saying that systems might have non-physical (that is
>>> logical) interfaces that are kind of permanent or whose lifetime is
>>> outside the control of NETCONF. Correct? Are you saying that the
>>=20
>> Correct.
>>=20
>>> distinction really is "system controlled interfaces" versus "config
>>> controlled interfaces"? And where to interfaces belong that are
>>=20
>> Yes, but only in the context of the interfaces module. That is:
>>=20
>> - system-controlled interfaces are those that appear in =
/interfaces-state
>>  before the corresponding entry has been created in /interfaces.
>=20
> And here it is already getting wrong because we want to support
> preprovisioning.

I don't think so. The configuration can still be pre-provisioned, but =
the point is that the config entry has to have the same name as the =
future operational state entry will have after it is provided by the =
system, otherwise the configuration won't be applied. The sequence of =
events is:

1. The interface is independently created and named elsewhere and =
appears in /interfaces-state.

2. The NETCONF server then looks whether there is any configuration for =
this new interface.

>=20
>> - config-controlled interfaces are those that have to be configured =
as an entry under /interfaces, otherwise they don't exist.
>>=20
>> This distinction is important because it affects the relationship =
between the "name" leaves, i. e. the keys of the lists =
/interfaces-state/interface and /interfaces/interface.
>=20
> But then I think the text in the description clauses (with the minor
> tweaks discussed here) is actually explaining this reasonably well,
> no?

Yes, what's missing is the definition of (the replacements of) the terms =
"physical" and "logical".=20

>=20
>>> created as side effects, e.g. tun/tap interfaces created by an
>>> application dynamically whenever that application is runing? Do we
>>> have direct and indirect config controlled interfaces? Or is such a
>>> tun/tap interface what you consider "system controlled" even though =
I
>>> might be disable the function that creates such tun/tap interfaces?
>>=20
>> Yes, if a logical interface is created as a side effect of other =
configuration, then, from the point of view of the interfaces module, is =
a system-controlled interface. So perhaps a more appropriate name would =
be "elsewhere-controlled".
>>=20
>=20
> We can perhaps define system-controlled in such a way that these
> elsewhere-controlled interfaces are included. So we have
> system-controlled interfaces vs interface-config-controlled
> interfaces?

The latter seems pretty clumsy. How about system-originated and =
config-originated? Neither of these terms is completely precise, but =
they are going to be used only locally in this document, and their =
definition will be provided.

Lada
=20
>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         

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





From j.schoenwaelder@jacobs-university.de  Tue May 21 05:12: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 E14BE21F88AC for ; Tue, 21 May 2013 05:12:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.153
X-Spam-Level: 
X-Spam-Status: No, score=-103.153 tagged_above=-999 required=5 tests=[AWL=0.096, 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 1ZaisCYqBO45 for ; Tue, 21 May 2013 05:12:24 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 77FFF21F96B6 for ; Tue, 21 May 2013 05:12:24 -0700 (PDT)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B3BCB20BDF; Tue, 21 May 2013 14:12:23 +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 2aBS0q6PiWIW; Tue, 21 May 2013 14:12:23 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3AFB720A1F; Tue, 21 May 2013 14:12:23 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 509C5265BEB2; Tue, 21 May 2013 14:12:20 +0200 (CEST)
Date: Tue, 21 May 2013 14:12:19 +0200
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20130521121219.GA9332@elstar.local>
Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , netmod@ietf.org
References: <20130520.122611.344934490839637266.mbj@tail-f.com>  <20130520104921.GA5578@elstar.local> <20130520.133003.1693188198827685068.mbj@tail-f.com> <20130520131212.GA5942@elstar.local>  <20130521095034.GA8891@elstar.local> <5B49D298-C5DB-4745-9C56-A225DBCB16A5@nic.cz> <20130521105733.GA9110@elstar.local> <3B70300A-9B75-44E8-8DE3-4B19B38E41BC@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3B70300A-9B75-44E8-8DE3-4B19B38E41BC@nic.cz>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-11.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, 21 May 2013 12:12:30 -0000

On Tue, May 21, 2013 at 01:30:34PM +0200, Ladislav Lhotka wrote:
> 
> > 
> > We can perhaps define system-controlled in such a way that these
> > elsewhere-controlled interfaces are included. So we have
> > system-controlled interfaces vs interface-config-controlled
> > interfaces?
> 
> The latter seems pretty clumsy. How about system-originated and config-originated? Neither of these terms is completely precise, but they are going to be used only locally in this document, and their definition will be provided.
> 

To be honest, this distinction might show up in other contexts as
well. But that does not matter. So we have system-controlled vs.
system-originated and on the other side config-controlled vs.
interface-config-controlled vs. config-originated. Since it is not
just about when interfaces appear but also when they disappear, I do
not like '-originated' that much.

  system-controlled interface: An interface is said to be
  system-controlled if the system creates and deletes the interface.
  Examples are interfaces representing physical hardware that appear
  and disappear when hardware (e.g., a line card) is added or
  removed. System-controlled interfaces may also appear if a certain
  functionality is enabled (e.g, a loopback interface appears if the
  IP protocol stack is enabled).

  config-controlled interface: An interface is said to be
  config-controlled if the creation of the interface is controlled by
  adding interface configuration to the configuration datastore and
  the removal of the interface is controlled by removing interface
  configuration from the configuration datastore. Examples are VLAN
  interfaces configured on a system-controlled Ethernet interface.

Explanation to merge somewhere later into the document:

  When a system-controlled interface is created, the runtime system
  tries to apply the interface configuration matching the name of the
  new interfaces. When a config-controlled interface is created, then
  the configuration determines the name of the interface. Some systems
  may support arbitrary interface names while others require that the
  names of config-controlled interfaces matches certain naming
  conventions.

Would something like this work better than physical/logical?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From jonathan@hansfords.net  Tue May 21 05:19: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 DB43721F8CB4 for ; Tue, 21 May 2013 05:19:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 JX9P-2RHJwJZ for ; Tue, 21 May 2013 05:19:47 -0700 (PDT)
Received: from avasout08.plus.net (avasout08.plus.net [212.159.14.20]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDFE21F8CA0 for ; Tue, 21 May 2013 05:19:47 -0700 (PDT)
Received: from webmail.plus.net ([84.93.237.194]) by avasout08 with smtp id ecKh1l0024CLSd801cKirj; Tue, 21 May 2013 13:19:42 +0100
X-CM-Score: 0.00
X-CNFS-Analysis: v=2.1 cv=IqQnLtPg c=1 sm=1 tr=0 a=VrPob/PGR4vzCiwW53VWbQ==:117 a=zvOXFpZrtIe2DiqMBxawyA==:17 a=0Bzu9jTXAAAA:8 a=jkFKeVsF5M4A:10 a=dYCPD3cKDi0A:10 a=7RFjRx2dmFgA:10 a=0B8HqoTn75oA:10 a=IkcTkHD0fZMA:10 a=6bkCdLdQAAAA:8 a=f0uUZFObAAAA:8 a=Rmb-P1IsjlIA:10 a=d6Bo5Hv0ZbnG7tfxNhwA:9 a=QEXdDO2ut3YA:10
X-AUTH: hansfords+us:2500
Received: from host-212-159-131-154.static.as13285.net ([212.159.131.154]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Tue, 21 May 2013 13:19:41 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Date: Tue, 21 May 2013 13:19:41 +0100
From: Jonathan Hansford 
To: Ladislav Lhotka , Martin Bjorklund , 
In-Reply-To: <20130521121219.GA9332@elstar.local>
References: <20130520.122611.344934490839637266.mbj@tail-f.com>  <20130520104921.GA5578@elstar.local> <20130520.133003.1693188198827685068.mbj@tail-f.com> <20130520131212.GA5942@elstar.local>  <20130521095034.GA8891@elstar.local> <5B49D298-C5DB-4745-9C56-A225DBCB16A5@nic.cz> <20130521105733.GA9110@elstar.local> <3B70300A-9B75-44E8-8DE3-4B19B38E41BC@nic.cz> <20130521121219.GA9332@elstar.local>
Message-ID: <9e09b4d3ca71f7313350a55f3f7393d8@imap.plus.net>
X-Sender: Jonathan@hansfords.net
User-Agent: Roundcube Webmail/0.7.4
X-Originating-IP: [212.159.131.154]
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-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: Tue, 21 May 2013 12:19:54 -0000

On 2013-05-21 13:12, Juergen Schoenwaelder wrote:

> On Tue, May 21, 2013 at 01:30:34PM +0200, Ladislav Lhotka wrote:
>
>>> We can perhaps define system-controlled in such a way that these
>>> elsewhere-controlled interfaces are included. So we have
>>> system-controlled interfaces vs interface-config-controlled
>>> interfaces?
>> The latter seems pretty clumsy. How about system-originated and
>> config-originated? Neither of these terms is completely precise, but
>> they are going to be used only locally in this document, and their
>> definition will be provided.
>
> To be honest, this distinction might show up in other contexts as
> well. But that does not matter. So we have system-controlled vs.
> system-originated and on the other side config-controlled vs.
> interface-config-controlled vs. config-originated. Since it is not
> just about when interfaces appear but also when they disappear, I do
> not like '-originated' that much.
>
> system-controlled interface: An interface is said to be
> system-controlled if the system creates and deletes the interface.
> Examples are interfaces representing physical hardware that appear
> and disappear when hardware (e.g., a line card) is added or
> removed. System-controlled interfaces may also appear if a certain
> functionality is enabled (e.g, a loopback interface appears if the
> IP protocol stack is enabled).
>
> config-controlled interface: An interface is said to be
> config-controlled if the creation of the interface is controlled by
> adding interface configuration to the configuration datastore and
> the removal of the interface is controlled by removing interface
> configuration from the configuration datastore. Examples are VLAN
> interfaces configured on a system-controlled Ethernet interface.

So, an interface that is config-controlled by another protocol but not 
config-controlled via this data model would, for this data model, be a 
system-controlled interface? If so, should that be more explicitly 
stated?

Jonathan

>
> Explanation to merge somewhere later into the document:
>
> When a system-controlled interface is created, the runtime system
> tries to apply the interface configuration matching the name of the
> new interfaces. When a config-controlled interface is created, then
> the configuration determines the name of the interface. Some systems
> may support arbitrary interface names while others require that the
> names of config-controlled interfaces matches certain naming
> conventions.
>
> Would something like this work better than physical/logical?
>
> /js

From j.schoenwaelder@jacobs-university.de  Tue May 21 05:27: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 174BD21F96F6 for ; Tue, 21 May 2013 05:27:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.156
X-Spam-Level: 
X-Spam-Status: No, score=-103.156 tagged_above=-999 required=5 tests=[AWL=0.093, 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 Xm17-zTc7VKd for ; Tue, 21 May 2013 05:27:28 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id E673421F96B6 for ; Tue, 21 May 2013 05:27:27 -0700 (PDT)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 24F3620BDF; Tue, 21 May 2013 14:27:27 +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 jCzoPpAAUYyh; Tue, 21 May 2013 14:27:27 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9811E20BD5; Tue, 21 May 2013 14:27:26 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 7D8AC265C02D; Tue, 21 May 2013 14:27:25 +0200 (CEST)
Date: Tue, 21 May 2013 14:27:25 +0200
From: Juergen Schoenwaelder 
To: Jonathan Hansford 
Message-ID: <20130521122725.GC9407@elstar.local>
Mail-Followup-To: Jonathan Hansford , Ladislav Lhotka , Martin Bjorklund , netmod@ietf.org
References: <20130520104921.GA5578@elstar.local> <20130520.133003.1693188198827685068.mbj@tail-f.com> <20130520131212.GA5942@elstar.local>  <20130521095034.GA8891@elstar.local> <5B49D298-C5DB-4745-9C56-A225DBCB16A5@nic.cz> <20130521105733.GA9110@elstar.local> <3B70300A-9B75-44E8-8DE3-4B19B38E41BC@nic.cz> <20130521121219.GA9332@elstar.local> <9e09b4d3ca71f7313350a55f3f7393d8@imap.plus.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9e09b4d3ca71f7313350a55f3f7393d8@imap.plus.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-11.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, 21 May 2013 12:27:33 -0000

On Tue, May 21, 2013 at 01:19:41PM +0100, Jonathan Hansford wrote:
> 
> So, an interface that is config-controlled by another protocol but
> not config-controlled via this data model would, for this data
> model, be a system-controlled interface? If so, should that be more
> explicitly stated?

Do you have an example? But I guess the answer is 'yes' so far.

/js 

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From jeffrey.K.lange@ge.com  Tue May 21 05:34:01 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 4A8CB21F8C23 for ; Tue, 21 May 2013 05:34:01 -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 wFwefgvt+lEM for ; Tue, 21 May 2013 05:33:55 -0700 (PDT)
Received: from exprod5og110.obsmtp.com (exprod5og110.obsmtp.com [64.18.0.20]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFB821F885A for ; Tue, 21 May 2013 05:33:55 -0700 (PDT)
Received: from cinmlip12.e2k.ad.ge.com ([165.156.4.1]) (using TLSv1) by exprod5ob110.postini.com ([64.18.4.12]) with SMTP ID DSNKUZtpsikIPP3lY7x90kHXhIhDAgvj/WMA@postini.com; Tue, 21 May 2013 05:33:55 PDT
Received: from unknown (HELO ALPMLEF02.e2k.ad.ge.com) ([3.159.18.11]) by cinmlip12.e2k.ad.ge.com with ESMTP; 21 May 2013 08:33:53 -0400
Received: from cinmlef16.e2k.ad.ge.com ([3.159.213.85]) by ALPMLEF02.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 21 May 2013 08:33:53 -0400
Received: from CINMLCH02.e2k.ad.ge.com ([3.159.212.51]) by cinmlef16.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 21 May 2013 08:33:45 -0400
Received: from CINURCNA07.e2k.ad.ge.com (3.159.212.124) by CINMLCH02.e2k.ad.ge.com (3.159.212.51) with Microsoft SMTP Server (TLS) id 14.3.136.1; Tue, 21 May 2013 08:33:40 -0400
Received: from CINURCNA15.e2k.ad.ge.com ([169.254.3.88]) by CINURCNA07.e2k.ad.ge.com ([169.254.1.192]) with mapi id 14.02.0318.004; Tue, 21 May 2013 08:33:39 -0400
From: "Lange, Jeffrey K (GE Energy Management)" 
To: Juergen Schoenwaelder , "Ladislav Lhotka" 
Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-11.txt
Thread-Index: AQHOUwLXNDcEqta8YUyNcD5v+mCHXZkJsGOAgAR1ioCAAAIZgIAABGCAgAALX4CAAByLAIABTZAAgAAMbwCAAAvxgIAAjOKA//+DHQCAAAuqgP//wfjA
Date: Tue, 21 May 2013 12:33:39 +0000
Message-ID: 
References: <20130520.122611.344934490839637266.mbj@tail-f.com>  <20130520104921.GA5578@elstar.local> <20130520.133003.1693188198827685068.mbj@tail-f.com> <20130520131212.GA5942@elstar.local>  <20130521095034.GA8891@elstar.local> <5B49D298-C5DB-4745-9C56-A225DBCB16A5@nic.cz> <20130521105733.GA9110@elstar.local> <3B70300A-9B75-44E8-8DE3-4B19B38E41BC@nic.cz> <20130521121219.GA9332@elstar.local>
In-Reply-To: <20130521121219.GA9332@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [3.159.212.192]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 21 May 2013 12:33:45.0988 (UTC) FILETIME=[6FCB1C40:01CE561F]
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-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: Tue, 21 May 2013 12:34:01 -0000

>   system-controlled interface: An interface is said to be
>   system-controlled if the system creates and deletes the interface.
>   Examples are interfaces representing physical hardware that appear
>   and disappear when hardware (e.g., a line card) is added or
>   removed. System-controlled interfaces may also appear if a certain
>   functionality is enabled (e.g, a loopback interface appears if the
>   IP protocol stack is enabled).
>=20

The example given of a loopback interface seems to contradict the definitio=
n of system controlled.=20
If the device is created via "configuring" the IP protocol stack, wouldn't =
it by definition be "config-controlled"?

-Jeff

>   config-controlled interface: An interface is said to be
>   config-controlled if the creation of the interface is controlled by
>   adding interface configuration to the configuration datastore and
>   the removal of the interface is controlled by removing interface
>   configuration from the configuration datastore. Examples are VLAN
>   interfaces configured on a system-controlled Ethernet interface.
>=20
> Explanation to merge somewhere later into the document:
>=20
>   When a system-controlled interface is created, the runtime system
>   tries to apply the interface configuration matching the name of the
>   new interfaces. When a config-controlled interface is created, then
>   the configuration determines the name of the interface. Some systems
>   may support arbitrary interface names while others require that the
>   names of config-controlled interfaces matches certain naming
>   conventions.
>=20
> Would something like this work better than physical/logical?
>=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

From jonathan@hansfords.net  Tue May 21 05:35: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 7674421F94F5 for ; Tue, 21 May 2013 05:35:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 7-Him-vl2-wM for ; Tue, 21 May 2013 05:34:57 -0700 (PDT)
Received: from avasout08.plus.net (avasout08.plus.net [212.159.14.20]) by ietfa.amsl.com (Postfix) with ESMTP id D608621F8F27 for ; Tue, 21 May 2013 05:34:56 -0700 (PDT)
Received: from webmail.plus.net ([84.93.237.194]) by avasout08 with smtp id ecav1l0024CLSd801cawpo; Tue, 21 May 2013 13:34:56 +0100
X-CM-Score: 0.00
X-CNFS-Analysis: v=2.1 cv=IqQnLtPg c=1 sm=1 tr=0 a=VrPob/PGR4vzCiwW53VWbQ==:117 a=zvOXFpZrtIe2DiqMBxawyA==:17 a=0Bzu9jTXAAAA:8 a=jkFKeVsF5M4A:10 a=dYCPD3cKDi0A:10 a=7RFjRx2dmFgA:10 a=0B8HqoTn75oA:10 a=IkcTkHD0fZMA:10 a=6bkCdLdQAAAA:8 a=f0uUZFObAAAA:8 a=Rmb-P1IsjlIA:10 a=xaJNFLZsOB7EvojUxGAA:9 a=QEXdDO2ut3YA:10
X-AUTH: hansfords+us:2500
Received: from host-212-159-131-154.static.as13285.net ([212.159.131.154]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Tue, 21 May 2013 13:34:55 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Date: Tue, 21 May 2013 13:34:55 +0100
From: Jonathan Hansford 
To: Jonathan Hansford , Ladislav Lhotka , Martin Bjorklund , 
In-Reply-To: <20130521122725.GC9407@elstar.local>
References: <20130520104921.GA5578@elstar.local> <20130520.133003.1693188198827685068.mbj@tail-f.com> <20130520131212.GA5942@elstar.local>  <20130521095034.GA8891@elstar.local> <5B49D298-C5DB-4745-9C56-A225DBCB16A5@nic.cz> <20130521105733.GA9110@elstar.local> <3B70300A-9B75-44E8-8DE3-4B19B38E41BC@nic.cz> <20130521121219.GA9332@elstar.local> <9e09b4d3ca71f7313350a55f3f7393d8@imap.plus.net> <20130521122725.GC9407@elstar.local>
Message-ID: <15d1261727c9e610468861d24700c021@imap.plus.net>
X-Sender: Jonathan@hansfords.net
User-Agent: Roundcube Webmail/0.7.4
X-Originating-IP: [212.159.131.154]
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-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: Tue, 21 May 2013 12:35:03 -0000

On 2013-05-21 13:27, Juergen Schoenwaelder wrote:

> On Tue, May 21, 2013 at 01:19:41PM +0100, Jonathan Hansford wrote:
>
>> So, an interface that is config-controlled by another protocol but 
>> not
>> config-controlled via this data model would, for this data model, be 
>> a
>> system-controlled interface? If so, should that be more explicitly
>> stated?
>
> Do you have an example? But I guess the answer is 'yes' so far.

No, nor would I consider myself an expert on interfaces, so I'm happy 
for this to be ignored if others more in the know do not believe this is 
relevant. It just struck me as a corner case that could potentially lead 
to confusion.

Jonathan

>
> /js

From ietfc@btconnect.com  Tue May 21 06:07:17 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 E225E21F9731 for ; Tue, 21 May 2013 06:07:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.895
X-Spam-Level: 
X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[AWL=0.104,  BAYES_00=-2.599, 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 CW+Iwnb0ICjS for ; Tue, 21 May 2013 06:07:13 -0700 (PDT)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 52A1521F9725 for ; Tue, 21 May 2013 06:07:05 -0700 (PDT)
Received: from mail127-ch1-R.bigfish.com (10.43.68.248) by CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id 14.1.225.23; Tue, 21 May 2013 13:07:04 +0000
Received: from mail127-ch1 (localhost [127.0.0.1])	by mail127-ch1-R.bigfish.com (Postfix) with ESMTP id 317EE220404; Tue, 21 May 2013 13:07:04 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.250.69; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0711HT002.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -14
X-BigFish: PS-14(zz542I1432I1418Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh304l1d11m1155h)
Received: from mail127-ch1 (localhost.localdomain [127.0.0.1]) by mail127-ch1 (MessageSwitch) id 1369141622517721_19104; Tue, 21 May 2013 13:07:02 +0000 (UTC)
Received: from CH1EHSMHS018.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.250])	by mail127-ch1.bigfish.com (Postfix) with ESMTP id 7C32A20023E;	Tue, 21 May 2013 13:07:02 +0000 (UTC)
Received: from AMXPRD0711HT002.eurprd07.prod.outlook.com (157.56.250.69) by CH1EHSMHS018.bigfish.com (10.43.70.18) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 21 May 2013 13:07:00 +0000
Received: from AMXPRD0310HT005.eurprd03.prod.outlook.com (157.56.248.133) by pod51017.outlook.com (10.242.9.163) with Microsoft SMTP Server (TLS) id 14.16.311.1; Tue, 21 May 2013 13:06:50 +0000
Message-ID: <007401ce5623$4a35b180$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Ladislav Lhotka 
References: <20130520.122611.344934490839637266.mbj@tail-f.com><20130520104921.GA5578@elstar.local><20130520.133003.1693188198827685068.mbj@tail-f.com><20130520131212.GA5942@elstar.local><20130521095034.GA8891@elstar.local><5B49D298-C5DB-4745-9C56-A225DBCB16A5@nic.cz><20130521105733.GA9110@elstar.local> <3B70300A-9B75-44E8-8DE3-4B19B38E41BC@nic.cz>
Date: Tue, 21 May 2013 13:57:34 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.248.133]
X-OriginatorOrg: btconnect.com
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-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: Tue, 21 May 2013 13:07:18 -0000

----- Original Message -----
From: "Ladislav Lhotka" 
To: "Juergen Schoenwaelder" 
Cc: 
Sent: Tuesday, May 21, 2013 12:30 P

> The latter seems pretty clumsy. How about system-originated and
config-originated? Neither of these terms is completely precise, but
they are going to be used only locally in this document, and their
definition will be provided.
>

Lada

That I think is complicating the future:-(

You said you would hold off on routing since there were parallel issues
there, and thought that ip-cfg should come in-between.  I think that
there will be many more such, so calling them logical and physical in
one I-D, static and dynamic in another, etc. etc. can only confuse.

The concept is not local (which is why we have been discussing it for so
many years:-) and we could do worse than build on RFC6244, which is the
most recent description of this I have seen, and come up with global
terms that can then be used in all I-Ds; no problem with the definition
appearing here and being the normative reference for everyone else.

The best terms would be ones that are close to those then used in the
paths
/interfaces-system/interface/
/interfaces-config/interface/
for example

Tom Petch

> Lada
>
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> > Fax:   +49 421 200 3103         
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>



From j.schoenwaelder@jacobs-university.de  Tue May 21 06:17: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 DC57421F977F for ; Tue, 21 May 2013 06:17:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.859
X-Spam-Level: 
X-Spam-Status: No, score=-102.859 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_15=0.6, 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 L9NPUYTs1m4c for ; Tue, 21 May 2013 06:17:36 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id A60AE21F9784 for ; Tue, 21 May 2013 06:17:33 -0700 (PDT)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id F21AB20C10; Tue, 21 May 2013 15:17:32 +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 ixQROOeXWFSA; Tue, 21 May 2013 15:17:32 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7CA6020C08; Tue, 21 May 2013 15:17:32 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 5B87B265C291; Tue, 21 May 2013 15:17:31 +0200 (CEST)
Date: Tue, 21 May 2013 15:17:31 +0200
From: Juergen Schoenwaelder 
To: "t.petch" 
Message-ID: <20130521131731.GA9666@elstar.local>
Mail-Followup-To: "t.petch" , Ladislav Lhotka , netmod@ietf.org
References:  <20130520104921.GA5578@elstar.local> <20130520.133003.1693188198827685068.mbj@tail-f.com> <20130520131212.GA5942@elstar.local>  <20130521095034.GA8891@elstar.local> <5B49D298-C5DB-4745-9C56-A225DBCB16A5@nic.cz> <20130521105733.GA9110@elstar.local> <3B70300A-9B75-44E8-8DE3-4B19B38E41BC@nic.cz> <007401ce5623$4a35b180$4001a8c0@gateway.2wire.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <007401ce5623$4a35b180$4001a8c0@gateway.2wire.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-11.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, 21 May 2013 13:17:42 -0000

On Tue, May 21, 2013 at 01:57:34PM +0100, t.petch wrote:
 
> The concept is not local (which is why we have been discussing it for so
> many years:-) and we could do worse than build on RFC6244, which is the
> most recent description of this I have seen, and come up with global
> terms that can then be used in all I-Ds; no problem with the definition
> appearing here and being the normative reference for everyone else.
> 
> The best terms would be ones that are close to those then used in the
> paths
> /interfaces-system/interface/
> /interfaces-config/interface/
> for example

The distinction between config state and operational state is well
understood and not the main subject of this discussion. We are talking
here about how config applies to operational state objects whose
lifetime is either controlled by the system or controlled by the
config itself. For me, these are two separate things and your
suggestion does not make much sense compared to what we have (since
config-controlled interfaces leads to operational state that is
similar to the operational state of system-controlled interfaces).

/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 May 21 08:07: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 0D24F21F8B65 for ; Tue, 21 May 2013 08:07:06 -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=[AWL=0.000,  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 x4YfUmh2o2wi for ; Tue, 21 May 2013 08:07: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 E077E21F90CD for ; Tue, 21 May 2013 08:07:04 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id DD0E013F636; Tue, 21 May 2013 17:07:01 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1369148821; bh=5Tr+xsmu+C8VG40EJvnFA2Q3zt9LFPXbUtWafK7ojoo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=dJCrgInIuheOTToapuxs0mAyEy2vHJMIAqfjpKPbFFoDMCoh5cnClPo2cfcqZOfdT fNoEKKaMCu8ezRJsaZhNE5ClvmO6DoewDG6jtHUcbs+CiNLiR3b4CqtlGYuJGeuEzL 34QAUB956j+uMJ3owsHFwxACApH8UG0JoXNrL6EU=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: <9e09b4d3ca71f7313350a55f3f7393d8@imap.plus.net>
Date: Tue, 21 May 2013 17:07:01 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <86155444-7F74-4D27-A03B-3B9B8F462DD3@nic.cz>
References: <20130520.122611.344934490839637266.mbj@tail-f.com>  <20130520104921.GA5578@elstar.local> <20130520.133003.1693188198827685068.mbj@tail-f.com> <20130520131212.GA5942@elstar.local>  <20130521095034.GA8891@elstar.local> <5B49D298-C5DB-4745-9C56-A225DBCB16A5@nic.cz> <20130521105733.GA9110@elstar.local> <3B70300A-9B75-44E8-8DE3-4B19B38E41BC@nic.cz> <20130521121219.GA9332@elstar.local> <9e09b4d3ca71f7313350a55f3f7393d8@imap.plus.net>
To: Jonathan Hansford 
X-Mailer: Apple Mail (2.1503)
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-interfaces-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: Tue, 21 May 2013 15:07:06 -0000

On May 21, 2013, at 2:19 PM, Jonathan Hansford  =
wrote:

> On 2013-05-21 13:12, Juergen Schoenwaelder wrote:
>=20
>> On Tue, May 21, 2013 at 01:30:34PM +0200, Ladislav Lhotka wrote:
>>=20
>>>> We can perhaps define system-controlled in such a way that these
>>>> elsewhere-controlled interfaces are included. So we have
>>>> system-controlled interfaces vs interface-config-controlled
>>>> interfaces?
>>> The latter seems pretty clumsy. How about system-originated and
>>> config-originated? Neither of these terms is completely precise, but
>>> they are going to be used only locally in this document, and their
>>> definition will be provided.
>>=20
>> To be honest, this distinction might show up in other contexts as
>> well. But that does not matter. So we have system-controlled vs.
>> system-originated and on the other side config-controlled vs.
>> interface-config-controlled vs. config-originated. Since it is not
>> just about when interfaces appear but also when they disappear, I do
>> not like '-originated' that much.
>>=20
>> system-controlled interface: An interface is said to be
>> system-controlled if the system creates and deletes the interface.
>> Examples are interfaces representing physical hardware that appear
>> and disappear when hardware (e.g., a line card) is added or
>> removed. System-controlled interfaces may also appear if a certain
>> functionality is enabled (e.g, a loopback interface appears if the
>> IP protocol stack is enabled).
>>=20
>> config-controlled interface: An interface is said to be
>> config-controlled if the creation of the interface is controlled by
>> adding interface configuration to the configuration datastore and
>> the removal of the interface is controlled by removing interface
>> configuration from the configuration datastore. Examples are VLAN
>> interfaces configured on a system-controlled Ethernet interface.
>=20
> So, an interface that is config-controlled by another protocol but not =
config-controlled via this data model would, for this data model, be a =
system-controlled interface? If so, should that be more explicitly =
stated?

Yes, that's my view. It should be explicitly stated but we first have to =
agree on how it is supposed to work.

Lada

>=20
> Jonathan
>=20
>>=20
>> Explanation to merge somewhere later into the document:
>>=20
>> When a system-controlled interface is created, the runtime system
>> tries to apply the interface configuration matching the name of the
>> new interfaces. When a config-controlled interface is created, then
>> the configuration determines the name of the interface. Some systems
>> may support arbitrary interface names while others require that the
>> names of config-controlled interfaces matches certain naming
>> conventions.
>>=20
>> Would something like this work better than physical/logical?
>>=20
>> /js

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





From lhotka@nic.cz  Tue May 21 08:19:17 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 6BC8921F985D for ; Tue, 21 May 2013 08:19:17 -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 zI2WUH6EDgxr for ; Tue, 21 May 2013 08:19:16 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id D2A6621F987B for ; Tue, 21 May 2013 08:19: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 1E05A13F636; Tue, 21 May 2013 17:19:13 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1369149553; bh=ZECAKxA3WqpICgHzJrYV4mN5/C90yiI/iAvENoG0wc0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=IMHrOsepDuWUV8ElOfy/eqIjyomgDfK+O6gWy2SLFoyr4JxbpqavAUlXSyuQUE4Qw q6ZLvYn8mdJDu9tGtQFHhkE9GZZUOPnVGlxULtsfnrwy2cR3HK7JQImhtZrMR2g7Ox HRxKejGSY0h1x5FuCmCWf65sBxcS7HVlraz3k2/A=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Tue, 21 May 2013 17:19:12 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <34299C96-1062-437A-9898-9DA20BFC732E@nic.cz>
References: <20130520.122611.344934490839637266.mbj@tail-f.com>  <20130520104921.GA5578@elstar.local> <20130520.133003.1693188198827685068.mbj@tail-f.com> <20130520131212.GA5942@elstar.local>  <20130521095034.GA8891@elstar.local> <5B49D298-C5DB-4745-9C56-A225DBCB16A5@nic.cz> <20130521105733.GA9110@elstar.local> <3B70300A-9B75-44E8-8DE3-4B19B38E41BC@nic.cz> <20130521121219.GA9332@elstar.local> 
To: "Lange, Jeffrey K (GE Energy Management)" 
X-Mailer: Apple Mail (2.1503)
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-interfaces-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: Tue, 21 May 2013 15:19:17 -0000

On May 21, 2013, at 2:33 PM, "Lange, Jeffrey K (GE Energy Management)" =
 wrote:

>>  system-controlled interface: An interface is said to be
>>  system-controlled if the system creates and deletes the interface.
>>  Examples are interfaces representing physical hardware that appear
>>  and disappear when hardware (e.g., a line card) is added or
>>  removed. System-controlled interfaces may also appear if a certain
>>  functionality is enabled (e.g, a loopback interface appears if the
>>  IP protocol stack is enabled).
>>=20
>=20
> The example given of a loopback interface seems to contradict the =
definition of system controlled.=20
> If the device is created via "configuring" the IP protocol stack, =
wouldn't it by definition be "config-controlled"?

Not by this definition. The config entry for a loopback interface under =
/interfaces has to use the name that's already present under =
/interfaces-state (or, if it is pre-provisioned, will be present after =
the IP stack is enabled).

Lada

>=20
> -Jeff
>=20
>>  config-controlled interface: An interface is said to be
>>  config-controlled if the creation of the interface is controlled by
>>  adding interface configuration to the configuration datastore and
>>  the removal of the interface is controlled by removing interface
>>  configuration from the configuration datastore. Examples are VLAN
>>  interfaces configured on a system-controlled Ethernet interface.
>>=20
>> Explanation to merge somewhere later into the document:
>>=20
>>  When a system-controlled interface is created, the runtime system
>>  tries to apply the interface configuration matching the name of the
>>  new interfaces. When a config-controlled interface is created, then
>>  the configuration determines the name of the interface. Some systems
>>  may support arbitrary interface names while others require that the
>>  names of config-controlled interfaces matches certain naming
>>  conventions.
>>=20
>> Would something like this work better than physical/logical?
>>=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

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





From j.schoenwaelder@jacobs-university.de  Tue May 21 08:46: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 D34E621F9669 for ; Tue, 21 May 2013 08:46:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.152
X-Spam-Level: 
X-Spam-Status: No, score=-103.152 tagged_above=-999 required=5 tests=[AWL=0.097, 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 IpLmoxLOjV+V for ; Tue, 21 May 2013 08:46: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 A28B021F974B for ; Tue, 21 May 2013 08:46:05 -0700 (PDT)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id CE09620BEF; Tue, 21 May 2013 17:46:04 +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 n0YK8SK4DVCm; Tue, 21 May 2013 17:46:04 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 10F0F20BCD; Tue, 21 May 2013 17:46:03 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id A6E65265CC55; Tue, 21 May 2013 17:46:02 +0200 (CEST)
Date: Tue, 21 May 2013 17:46:02 +0200
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20130521154602.GA10216@elstar.local>
Mail-Followup-To: Ladislav Lhotka , "Lange, Jeffrey K (GE Energy Management)" , "netmod@ietf.org" 
References: <20130520.133003.1693188198827685068.mbj@tail-f.com> <20130520131212.GA5942@elstar.local>  <20130521095034.GA8891@elstar.local> <5B49D298-C5DB-4745-9C56-A225DBCB16A5@nic.cz> <20130521105733.GA9110@elstar.local> <3B70300A-9B75-44E8-8DE3-4B19B38E41BC@nic.cz> <20130521121219.GA9332@elstar.local>  <34299C96-1062-437A-9898-9DA20BFC732E@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <34299C96-1062-437A-9898-9DA20BFC732E@nic.cz>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-11.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, 21 May 2013 15:46:11 -0000

On Tue, May 21, 2013 at 05:19:12PM +0200, Ladislav Lhotka wrote:
> 
> Not by this definition. The config entry for a loopback interface under /interfaces has to use the name that's already present under /interfaces-state (or, if it is pre-provisioned, will be present after the IP stack is enabled).
> 

The loopback interface is probably not a good example since there is
typically not much to configure...

/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 May 21 08:46: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 8171221F9763 for ; Tue, 21 May 2013 08:46:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level: 
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 TY88+pWzkaSj for ; Tue, 21 May 2013 08:46:45 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0C621F974B for ; Tue, 21 May 2013 08:46: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 2D6FC13F636; Tue, 21 May 2013 17:46:43 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1369151203; bh=Jjvi1i/IJER6xHVzPX26OatnlkvxwvbwaWydcqKu/IU=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=c6NU3/s54xxnDpH+81gjmjkOkezUE5mELA079IENyxKKIsYdhojXbW6r7JlzX3N+Q meSahC2Ln7DpP1wfIrcGg7xZoHHzqWMpQvGZ1xOukLcWG7kQmnASAm5dCmi+UZzKQQ KiTGAyQIyUEu+X6LOvVgNvMyDLScJwv/fgwkDnk8=
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Content-Type: text/plain; charset=iso-8859-1
From: Ladislav Lhotka 
X-Priority: 3
In-Reply-To: <007401ce5623$4a35b180$4001a8c0@gateway.2wire.net>
Date: Tue, 21 May 2013 17:46:42 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20130520.122611.344934490839637266.mbj@tail-f.com><20130520104921.GA5578@elstar.local><20130520.133003.1693188198827685068.mbj@tail-f.com><20130520131212.GA5942@elstar.local><20130521095034.GA8891@elstar.local><5B49D298-C5DB-4745-9C56-A225DBCB16A5@nic.cz><20130521105733.GA9110@elstar.local> <3B70300A-9B75-44E8-8DE3-4B19B38E41BC@nic.cz> <007401ce5623$4a35b180$4001a8c0@gateway.2wire.net>
To: t.petch 
X-Mailer: Apple Mail (2.1503)
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-interfaces-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: Tue, 21 May 2013 15:46:46 -0000

On May 21, 2013, at 2:57 PM, t.petch  wrote:

> ----- Original Message -----
> From: "Ladislav Lhotka" 
> To: "Juergen Schoenwaelder" 
> Cc: 
> Sent: Tuesday, May 21, 2013 12:30 P
> 
>> The latter seems pretty clumsy. How about system-originated and
> config-originated? Neither of these terms is completely precise, but
> they are going to be used only locally in this document, and their
> definition will be provided.
>>=20
>=20
> Lada
>=20
> That I think is complicating the future:-(
>=20
> You said you would hold off on routing since there were parallel =
issues
> there, and thought that ip-cfg should come in-between.  I think that
> there will be many more such, so calling them logical and physical in
> one I-D, static and dynamic in another, etc. etc. can only confuse.

You are right, it is not limited to this draft, so we should come up =
with terms suitable for describing the same situation in other contexts.

For example, in the routing draft, the main/default routing table for an =
address family, which is always present, will be system-controlled, and =
any additional routing tables will be config-controlled.=20

>=20
> The concept is not local (which is why we have been discussing it for =
so
> many years:-) and we could do worse than build on RFC6244, which is =
the
> most recent description of this I have seen, and come up with global
> terms that can then be used in all I-Ds; no problem with the =
definition
> appearing here and being the normative reference for everyone else.

Hmm, I don't think it is a good time to open RFC 6244 now and make it a =
downref of all other I-Ds, if it is what you mean. After we agree on a =
definition, it will probably be better to have a copy of it in the =
terminology section of every I-D where this issue arises.

>=20
> The best terms would be ones that are close to those then used in the
> paths
> /interfaces-system/interface/
> /interfaces-config/interface/
> for example

So system-something and config-something seem to satisfy this. I am fine =
with "system-controlled" and "config-controlled", if we can agree on it.

Thanks, Lada

>=20
> Tom Petch
>=20
>> Lada
>>=20
>>>=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         
>>=20
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>=20
>=20
>=20

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





From ietfc@btconnect.com  Tue May 21 09:05:01 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 8C48021F911B for ; Tue, 21 May 2013 09:05:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.603
X-Spam-Level: 
X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 Ohq+fL0mi5Rp for ; Tue, 21 May 2013 09:04:55 -0700 (PDT)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 65E5F21F8FDB for ; Tue, 21 May 2013 09:04:50 -0700 (PDT)
Received: from mail198-va3-R.bigfish.com (10.7.14.239) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Tue, 21 May 2013 16:04:49 +0000
Received: from mail198-va3 (localhost [127.0.0.1])	by mail198-va3-R.bigfish.com (Postfix) with ESMTP id 6072320083; Tue, 21 May 2013 16:04:49 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.250.69; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0711HT002.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -23
X-BigFish: PS-23(zz98dI9371I542I1432I1418I4015I179dNzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL8275bh8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh304l1d11m1155h)
Received: from mail198-va3 (localhost.localdomain [127.0.0.1]) by mail198-va3 (MessageSwitch) id 1369152287709037_14115; Tue, 21 May 2013 16:04:47 +0000 (UTC)
Received: from VA3EHSMHS033.bigfish.com (unknown [10.7.14.230])	by mail198-va3.bigfish.com (Postfix) with ESMTP id 97C58420251; Tue, 21 May 2013 16:04:47 +0000 (UTC)
Received: from AMXPRD0711HT002.eurprd07.prod.outlook.com (157.56.250.69) by VA3EHSMHS033.bigfish.com (10.7.99.43) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 21 May 2013 16:04:43 +0000
Received: from AMXPRD0310HT001.eurprd03.prod.outlook.com (157.56.248.133) by pod51017.outlook.com (10.242.9.163) with Microsoft SMTP Server (TLS) id 14.16.311.1; Tue, 21 May 2013 16:04:39 +0000
Message-ID: <019401ce563c$217eaee0$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Ladislav Lhotka 
References: <20130520.122611.344934490839637266.mbj@tail-f.com><20130520104921.GA5578@elstar.local><20130520.133003.1693188198827685068.mbj@tail-f.com><20130520131212.GA5942@elstar.local><20130521095034.GA8891@elstar.local><5B49D298-C5DB-4745-9C56-A225DBCB16A5@nic.cz><20130521105733.GA9110@elstar.local> <3B70300A-9B75-44E8-8DE3-4B19B38E41BC@nic.cz> <007401ce5623$4a35b180$4001a8c0@gateway.2wire.net> 
Date: Tue, 21 May 2013 16:58:15 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.248.133]
X-OriginatorOrg: btconnect.com
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-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: Tue, 21 May 2013 16:05:01 -0000

In line twice

----- Original Message -----
From: "Ladislav Lhotka" 
To: "t.petch" 
Cc: 
Sent: Tuesday, May 21, 2013 4:46 PM
On May 21, 2013, at 2:57 PM, t.petch  wrote:
> ----- Original Message -----
> From: "Ladislav Lhotka" 
> To: "Juergen Schoenwaelder" 
> Cc: 
> Sent: Tuesday, May 21, 2013 12:30 P
> 
>> The latter seems pretty clumsy. How about system-originated and
> config-originated? Neither of these terms is completely precise, but
> they are going to be used only locally in this document, and their
> definition will be provided.
>>
> Lada
>
> That I think is complicating the future:-(
>
> You said you would hold off on routing since there were parallel
issues
> there, and thought that ip-cfg should come in-between.  I think that
> there will be many more such, so calling them logical and physical in
> one I-D, static and dynamic in another, etc. etc. can only confuse.

You are right, it is not limited to this draft, so we should come up
with terms suitable for describing the same situation in other contexts.

For example, in the routing draft, the main/default routing table for an
address family, which is always present, will be system-controlled, and
any additional routing tables will be config-controlled.

> The concept is not local (which is why we have been discussing it for
so
> many years:-) and we could do worse than build on RFC6244, which is
the
> most recent description of this I have seen, and come up with global
> terms that can then be used in all I-Ds; no problem with the
definition
> appearing here and being the normative reference for everyone else.

Hmm, I don't think it is a good time to open RFC 6244 now and make it a
downref of all other I-Ds, if it is what you mean. After we agree on a
definition, it will probably be better to have a copy of it in the
terminology section of every I-D where this issue arises.


Whoops, no way did I mean open RFC6244; rather, in "definition appearing
here",
here = draft-ietf-netmod-interfaces-cfg
I have no problem with this particular I-D being the normative reference
for the terminology for all the other modules we create.



> The best terms would be ones that are close to those then used in the
> paths
> /interfaces-system/interface/
> /interfaces-config/interface/
> for example

So system-something and config-something seem to satisfy this. I am fine
with "system-controlled" and "config-controlled", if we can agree on it.


Works for me

Tom Petch


Thanks, Lada

>
> Tom Petch
>
>> Lada
>> >> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>> --
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C







From mbj@tail-f.com  Tue May 21 11:28: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 7BE3611E80A5 for ; Tue, 21 May 2013 11:28:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.086
X-Spam-Level: 
X-Spam-Status: No, score=-0.086 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_BL_SPAMCOP_NET=1.96]
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 apAx3yiYK8vu for ; Tue, 21 May 2013 11:28:19 -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 9A5EA21F88BF for ; Tue, 21 May 2013 11:28:19 -0700 (PDT)
Received: from localhost (unknown [88.128.80.7]) by mail.tail-f.com (Postfix) with ESMTPSA id C68AB1200174; Tue, 21 May 2013 20:28:09 +0200 (CEST)
Date: Tue, 21 May 2013 20:28:01 +0200 (CEST)
Message-Id: <20130521.202801.170074099.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20130521121219.GA9332@elstar.local>
References: <20130521105733.GA9110@elstar.local> <3B70300A-9B75-44E8-8DE3-4B19B38E41BC@nic.cz> <20130521121219.GA9332@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-interfaces-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: Tue, 21 May 2013 18:28:25 -0000

Hi,

Juergen Schoenwaelder  wrote:
> To be honest, this distinction might show up in other contexts as
> well. But that does not matter. So we have system-controlled vs.
> system-originated and on the other side config-controlled vs.
> interface-config-controlled vs. config-originated. Since it is not
> just about when interfaces appear but also when they disappear, I do
> not like '-originated' that much.

I think system-controlled is fine.  In YANG we have ordered-by system
and ordered-by user so I wonder if we should use user-controlled
instead of config-controlled or interface-config-controlled?  It is
not perfect, but maybe consistent.

>   system-controlled interface: An interface is said to be
>   system-controlled if the system creates and deletes the interface.

Ok, but in my view the system creates all interfaces - who would
otherwise create them?

For example, when the system detects that a new user-controlled
interface is created in /interfaces/interface, the system creates (*)
the interface (in the kernel typically) and (conceptually)
instantiates an entry in /interface-state/interface.

(*) if it is not pre-configured...

The system creates/deletes an interface <=> an entry is conceptually
instantiated/removed from /interfaces-state/interface.

So maybe say:

   system-controlled interface: An interface is said to be
   system-controlled if the system creates and deletes the interface
   independently of what has been configured.

>   Examples are interfaces representing physical hardware that appear
>   and disappear when hardware (e.g., a line card) is added or
>   removed. System-controlled interfaces may also appear if a certain
>   functionality is enabled (e.g, a loopback interface appears if the

s/appear/might appear/  ?

>   IP protocol stack is enabled).

[should this be added to the ip config document?]

>   config-controlled interface: An interface is said to be
>   config-controlled if the creation of the interface is controlled by
>   adding interface configuration to the configuration datastore and

I think we must be even more explicit:

  ... to the /interfaces/interface list in the running configuration
  datastore ...

>   the removal of the interface is controlled by removing interface
>   configuration from the configuration datastore. Examples are VLAN
>   interfaces configured on a system-controlled Ethernet interface.
> 
> Explanation to merge somewhere later into the document:
> 
>   When a system-controlled interface is created, the runtime system
>   tries to apply the interface configuration matching the name of the

the interface configuration in /interfaces/interface ...

>   new interfaces. When a config-controlled interface is created, then
>   the configuration determines the name of the interface. Some systems
>   may support arbitrary interface names while others require that the
>   names of config-controlled interfaces matches certain naming
>   conventions.
> 
> Would something like this work better than physical/logical?

Yes.


/martin

From j.schoenwaelder@jacobs-university.de  Tue May 21 11:58:39 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 14A0D21F972E for ; Tue, 21 May 2013 11:58:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.155
X-Spam-Level: 
X-Spam-Status: No, score=-103.155 tagged_above=-999 required=5 tests=[AWL=0.094, 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 t-z4ZTANlG4W for ; Tue, 21 May 2013 11:58:29 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB9421F9603 for ; Tue, 21 May 2013 11:58:29 -0700 (PDT)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E657020BFD; Tue, 21 May 2013 20:58:28 +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 aAA0-ZPv6jVy; Tue, 21 May 2013 20:58:28 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7235B20BFC; Tue, 21 May 2013 20:58:28 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 1310E265D6AE; Tue, 21 May 2013 20:58:23 +0200 (CEST)
Date: Tue, 21 May 2013 20:58:23 +0200
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20130521185822.GA13034@elstar.local>
Mail-Followup-To: Martin Bjorklund , lhotka@nic.cz, netmod@ietf.org
References: <20130521105733.GA9110@elstar.local> <3B70300A-9B75-44E8-8DE3-4B19B38E41BC@nic.cz> <20130521121219.GA9332@elstar.local> <20130521.202801.170074099.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20130521.202801.170074099.mbj@tail-f.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-11.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, 21 May 2013 18:58:39 -0000

On Tue, May 21, 2013 at 08:28:01PM +0200, Martin Bjorklund wrote:

[...]
 
> I think we must be even more explicit:
> 
>   ... to the /interfaces/interface list in the running configuration
>   datastore ...

I tried to define the concept without refering to the structure of the
data model where the general concept is defined. Perhaps that is too
difficult? My idea was to have a concise definition right up in the
terminology section and to have somewhere later text that explain how
the two lists interact for system-controlled and config-controlled
interfaces.

/js (once we can configure interfaces, the rest will be easy ;-)

-- 
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 May 21 12:55: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 D973411E8126 for ; Tue, 21 May 2013 12:55:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level: 
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.050,  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 S40yic1v+cHJ for ; Tue, 21 May 2013 12:55: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 F361011E810F for ; Tue, 21 May 2013 12:55:23 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id E70C213F63D; Tue, 21 May 2013 21:55:20 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1369166121; bh=SEW9UYXLTmSM39no2Ckl3o2q8O8eL97jaestocq6dDI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=hRpWUdqj/gkDAGmB1kNXi6w71+bzBu0sJg8f1mGjXi1Q/KQv7Jo3V0wct/qtsV4uW wiiDmW9I9lNj2jK6OnFZwFgz2+jblYOoK3361zm7ukeUsaFfCOLiCkyL0Tukm9D3s9 +FlZqcKs/AWzgKgeQ+fgUCsIqC2wMWZ+pSlBUwb0=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: <20130521.202801.170074099.mbj@tail-f.com>
Date: Tue, 21 May 2013 21:55:19 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20130521105733.GA9110@elstar.local> <3B70300A-9B75-44E8-8DE3-4B19B38E41BC@nic.cz> <20130521121219.GA9332@elstar.local> <20130521.202801.170074099.mbj@tail-f.com>
To: Martin Bjorklund 
X-Mailer: Apple Mail (2.1503)
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-interfaces-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: Tue, 21 May 2013 19:55:25 -0000

On May 21, 2013, at 8:28 PM, Martin Bjorklund  wrote:

> Hi,
>=20
> Juergen Schoenwaelder  wrote:
>> To be honest, this distinction might show up in other contexts as
>> well. But that does not matter. So we have system-controlled vs.
>> system-originated and on the other side config-controlled vs.
>> interface-config-controlled vs. config-originated. Since it is not
>> just about when interfaces appear but also when they disappear, I do
>> not like '-originated' that much.
>=20
> I think system-controlled is fine.  In YANG we have ordered-by system
> and ordered-by user so I wonder if we should use user-controlled
> instead of config-controlled or interface-config-controlled?  It is
> not perfect, but maybe consistent.

Makes sense.

>=20
>>  system-controlled interface: An interface is said to be
>>  system-controlled if the system creates and deletes the interface.
>=20
> Ok, but in my view the system creates all interfaces - who would
> otherwise create them?

What about something like this: "User-controlled interface is created as =
a direct consequence of the creation of the corresponding configuration =
entry. In all other cases, the interface is called system-controlled." =
Some examples could then illustrate the other cases.

>=20
> For example, when the system detects that a new user-controlled
> interface is created in /interfaces/interface, the system creates (*)
> the interface (in the kernel typically) and (conceptually)
> instantiates an entry in /interface-state/interface.
>=20
> (*) if it is not pre-configured=85

What do you mean by pre-configured?
>=20
> The system creates/deletes an interface <=3D> an entry is conceptually
> instantiated/removed from /interfaces-state/interface.
>=20
> So maybe say:
>=20
>   system-controlled interface: An interface is said to be
>   system-controlled if the system creates and deletes the interface
>   independently of what has been configured.

Or maybe better: "=85 creates and deletes the interface independently of =
the corresponding configuration entry (which also needn't be present at =
all)."

As we discussed earlier, it is possible that a system-controlled =
interface is created or deleted as a side effect of a change elsewhere =
in the configuration.

>=20
>>  Examples are interfaces representing physical hardware that appear
>>  and disappear when hardware (e.g., a line card) is added or
>>  removed. System-controlled interfaces may also appear if a certain
>>  functionality is enabled (e.g, a loopback interface appears if the
>=20
> s/appear/might appear/  ?
>=20
>>  IP protocol stack is enabled).
>=20
> [should this be added to the ip config document?]


How is the IP stack globally enabled - just by supporting the ietf-ip =
module?
The "enabled" flags are per interface.

>=20
>>  config-controlled interface: An interface is said to be
>>  config-controlled if the creation of the interface is controlled by
>>  adding interface configuration to the configuration datastore and
>=20
> I think we must be even more explicit:
>=20
>  ... to the /interfaces/interface list in the running configuration
>  datastore =85

+1

>=20
>>  the removal of the interface is controlled by removing interface
>>  configuration from the configuration datastore. Examples are VLAN
>>  interfaces configured on a system-controlled Ethernet interface.
>>=20
>> Explanation to merge somewhere later into the document:
>>=20
>>  When a system-controlled interface is created, the runtime system
>>  tries to apply the interface configuration matching the name of the
>=20
> the interface configuration in /interfaces/interface ...
>=20
>>  new interfaces. When a config-controlled interface is created, then
>>  the configuration determines the name of the interface. Some systems
>>  may support arbitrary interface names while others require that the
>>  names of config-controlled interfaces matches certain naming
>>  conventions.
>>=20
>> Would something like this work better than physical/logical?
>=20
> Yes.

+1

However, I agree with Tom that we should probably aim at a more general =
formulation. Which makes me wonder: Is it only about the relationship =
between identically keyed entries in a pair of "coupled" lists - one in =
operational state and the other in configuration? Or something else as =
well?

Lada
>=20
>=20
> /martin

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





From mbj@tail-f.com  Tue May 21 21:20:04 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 4A18021F91CB for ; Tue, 21 May 2013 21:20:04 -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 Hw8bw1h4X6ck for ; Tue, 21 May 2013 21:19: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 60CDB21F8607 for ; Tue, 21 May 2013 21:19:57 -0700 (PDT)
Received: from localhost (adsl-69-108-218-178.dsl.pltn13.pacbell.net [69.108.218.178]) by mail.tail-f.com (Postfix) with ESMTPSA id CB8C31200174; Wed, 22 May 2013 06:19:55 +0200 (CEST)
Date: Wed, 22 May 2013 06:19:52 +0200 (CEST)
Message-Id: <20130522.061952.311188366.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References: <20130521121219.GA9332@elstar.local> <20130521.202801.170074099.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=iso-2022-jp
Content-Transfer-Encoding: 7bit
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-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: Wed, 22 May 2013 04:20:04 -0000

Ladislav Lhotka  wrote:
> 
> On May 21, 2013, at 8:28 PM, Martin Bjorklund  wrote:
> 
> > Hi,
> > 
> > Juergen Schoenwaelder  wrote:
> >> To be honest, this distinction might show up in other contexts as
> >> well. But that does not matter. So we have system-controlled vs.
> >> system-originated and on the other side config-controlled vs.
> >> interface-config-controlled vs. config-originated. Since it is not
> >> just about when interfaces appear but also when they disappear, I do
> >> not like '-originated' that much.
> > 
> > I think system-controlled is fine.  In YANG we have ordered-by system
> > and ordered-by user so I wonder if we should use user-controlled
> > instead of config-controlled or interface-config-controlled?  It is
> > not perfect, but maybe consistent.
> 
> Makes sense.
> 
> > 
> >>  system-controlled interface: An interface is said to be
> >>  system-controlled if the system creates and deletes the interface.
> > 
> > Ok, but in my view the system creates all interfaces - who would
> > otherwise create them?
> 
> What about something like this: "User-controlled interface is created as a
> direct consequence of the creation of the corresponding configuration
> entry. In all other cases, the interface is called system-controlled." Some
> examples could then illustrate the other cases.
> 
> > 
> > For example, when the system detects that a new user-controlled
> > interface is created in /interfaces/interface, the system creates (*)
> > the interface (in the kernel typically) and (conceptually)
> > instantiates an entry in /interface-state/interface.
> > 
> > (*) if it is not pre-configured$B!D(B
> 
> What do you mean by pre-configured?

I meant that if you configure a vlan on a pre-provisioned ethernet
interface, the system will not create the vlan interface until the
hardare is present.

> > The system creates/deletes an interface <=> an entry is conceptually
> > instantiated/removed from /interfaces-state/interface.
> > 
> > So maybe say:
> > 
> >   system-controlled interface: An interface is said to be
> >   system-controlled if the system creates and deletes the interface
> >   independently of what has been configured.
> 
> Or maybe better: "$B!D(B creates and deletes the interface independently of the
> corresponding configuration entry (which also needn't be present at all)."

Ok.

> As we discussed earlier, it is possible that a system-controlled interface is
> created or deleted as a side effect of a change elsewhere in the
> configuration.

Yes.

> >> Would something like this work better than physical/logical?
> > 
> > Yes.
> 
> +1
> 
> However, I agree with Tom that we should probably aim at a more general
> formulation.

I would be very happy if we could solve this for the current
document(s).  I am not sure what a more general formulation would be?


/martin

From lhotka@nic.cz  Wed May 22 05:30: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 2AACB21F96AC for ; Wed, 22 May 2013 05:30:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.956
X-Spam-Level: 
X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[AWL=0.043,  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 pe6vE+Gq5A7o for ; Wed, 22 May 2013 05:30: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 5D5D221F96AB for ; Wed, 22 May 2013 05:30:42 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 5D48D13F8CF; Wed, 22 May 2013 14:30:41 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1369225841; bh=OnOn97I3R8bYn5hUU/CLgd/ur9znvDaH034q0rhJpj0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=U7ckDfY7b6oQZyqBzmiJ4s6mAhpkjtrLkVk2CuojLU6fThdM400k6LKIAf09thNmQ SWw3IBXizwLDUc7YbWwSmRoYXFcIy5pWy58BQiWwyDQEPMiUf0Yra79TUE+GciwYCo bxsuheev3xABV5CreGlnqpmtDnw0OaHv5b0EEbe8=
Content-Type: text/plain; charset=iso-2022-jp
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: <20130522.061952.311188366.mbj@tail-f.com>
Date: Wed, 22 May 2013 14:30:36 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <0E3AC84A-4400-45F9-8059-D9B50BB19880@nic.cz>
References: <20130521121219.GA9332@elstar.local> <20130521.202801.170074099.mbj@tail-f.com>  <20130522.061952.311188366.mbj@tail-f.com>
To: Martin Bjorklund 
X-Mailer: Apple Mail (2.1503)
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-interfaces-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: Wed, 22 May 2013 12:30:43 -0000

On May 22, 2013, at 6:19 AM, Martin Bjorklund  wrote:

> Ladislav Lhotka  wrote:
>>=20
>> On May 21, 2013, at 8:28 PM, Martin Bjorklund  wrote:
>>=20
>>> Hi,
>>>=20
>>> Juergen Schoenwaelder  wrote:
>>>> To be honest, this distinction might show up in other contexts as
>>>> well. But that does not matter. So we have system-controlled vs.
>>>> system-originated and on the other side config-controlled vs.
>>>> interface-config-controlled vs. config-originated. Since it is not
>>>> just about when interfaces appear but also when they disappear, I =
do
>>>> not like '-originated' that much.
>>>=20
>>> I think system-controlled is fine.  In YANG we have ordered-by =
system
>>> and ordered-by user so I wonder if we should use user-controlled
>>> instead of config-controlled or interface-config-controlled?  It is
>>> not perfect, but maybe consistent.
>>=20
>> Makes sense.
>>=20
>>>=20
>>>> system-controlled interface: An interface is said to be
>>>> system-controlled if the system creates and deletes the interface.
>>>=20
>>> Ok, but in my view the system creates all interfaces - who would
>>> otherwise create them?
>>=20
>> What about something like this: "User-controlled interface is created =
as a
>> direct consequence of the creation of the corresponding configuration
>> entry. In all other cases, the interface is called =
system-controlled." Some
>> examples could then illustrate the other cases.
>>=20
>>>=20
>>> For example, when the system detects that a new user-controlled
>>> interface is created in /interfaces/interface, the system creates =
(*)
>>> the interface (in the kernel typically) and (conceptually)
>>> instantiates an entry in /interface-state/interface.
>>>=20
>>> (*) if it is not pre-configured=1B$B!D=1B(B
>>=20
>> What do you mean by pre-configured?
>=20
> I meant that if you configure a vlan on a pre-provisioned ethernet
> interface, the system will not create the vlan interface until the
> hardare is present.

OK, right.

>>=20
>> However, I agree with Tom that we should probably aim at a more =
general
>> formulation.
>=20
> I would be very happy if we could solve this for the current
> document(s).  I am not sure what a more general formulation would be?


Maybe just "system/user-controlled list entry", because I will most =
likely have to deal with system/user-controlled routing tables in the =
routing draft.

Lada

>=20
>=20
> /martin

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





From mbj@tail-f.com  Wed May 22 07:50: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 3491A21F896D for ; Wed, 22 May 2013 07:50:32 -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 r8AkL3m269jx for ; Wed, 22 May 2013 07:50:26 -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 4DDE921F889C for ; Wed, 22 May 2013 07:50:25 -0700 (PDT)
Received: from localhost (adsl-69-108-218-178.dsl.pltn13.pacbell.net [69.108.218.178]) by mail.tail-f.com (Postfix) with ESMTPSA id 290701200A35; Wed, 22 May 2013 16:50:22 +0200 (CEST)
Date: Wed, 22 May 2013 07:50:21 -0700 (PDT)
Message-Id: <20130522.075021.510632113.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: <0E3AC84A-4400-45F9-8059-D9B50BB19880@nic.cz>
References:  <20130522.061952.311188366.mbj@tail-f.com> <0E3AC84A-4400-45F9-8059-D9B50BB19880@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-interfaces-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: Wed, 22 May 2013 14:50:32 -0000

Hi,

I tried to merge the various text snippets we discussed into full
paragraphs.  This is what I came up with:

In "Terminology":

- system-controlled interface: An interface is said to be
  system-controlled if the system creates and deletes the interface
  independently of what has been explicitly configured.  Examples are
  interfaces representing physical hardware that appear and disappear
  when hardware (e.g., a line card) is added or removed.
  System-controlled interfaces may also appear if a certain
  functionality is enabled (e.g., a loopback interface might appear if
  the IP protocol stack is enabled).

- user-controlled interface: An interface is said to be
  user-controlled if the creation of the interface is controlled by
  adding explicit interface configuration to the running configuration
  datastore and the removal of the interface is controlled by removing
  explicit interface configuration from the running configuration
  datastore.  Examples are VLAN interfaces configured on a
  system-controlled Ethernet interface.


In "The interface Lists":

For system-controlled interfaces, the "name" is the device-specific
name of the interface.  The 'config false' list
"/interfaces-state/interface" contains all existing interfaces on the
device.

If the device supports arbitrarily named user-controlled interfaces,
the NETCONF server advertises the feature "arbitrary-names".  If the
device does not advertise this feature, the names of user-controlled
interfaces MUST match the device's naming scheme.  How a client can
learn the naming scheme of such devices is outside the scope of this
document.

When a system-controlled interface is created by the system, the
system tries to apply the interface configuration in
/interfaces/interface with the same name as the new interface.  If no
such interface configuration is found, or if the configured type does
not match the real interface type, the system creates the interface
without applying explicit configuration.

When a user-controlled interface is created, the configuration
determines the name of the interface.




/martin

From andy@yumaworks.com  Wed May 22 08:23: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 EC06021F8FA5 for ; Wed, 22 May 2013 08:23:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.754
X-Spam-Level: 
X-Spam-Status: No, score=-1.754 tagged_above=-999 required=5 tests=[AWL=0.223,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oyfIv6rz+-Q for ; Wed, 22 May 2013 08:23:06 -0700 (PDT)
Received: from mail-da0-x230.google.com (mail-da0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF8821F9008 for ; Wed, 22 May 2013 08:23:02 -0700 (PDT)
Received: by mail-da0-f48.google.com with SMTP id h32so1212926dak.7 for ; Wed, 22 May 2013 08:23:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=lobl3tO0op7GUdxHtULXIK3rqQy3kNu4nAsI+LfGR+8=; b=mrGOU1uq/kqL8HcjTtDePcYUxqtn7AW5v93L3GQr+R+GtsXs10GorDWFJnlCjw6cvy IZR+4pi+gcax3hbWTWBngpFMuRZnsmF+9bF5WYBJHMeOqaLkxvGN2yyhd5/btXGd+Go6 8sYDEhjG0iZl4JQfWL+tTbS785AOz3lP1e7Ad9Yqqa9SOg4IzPHbV9Q7yyFewqPrpVVF moi018KCnNsPtCaPyvyXQ1RzKJIkIF9hgYHpi41cmDzuCG1nQ+JIe47VcR+57NM08b1j 6225jjEGhSVP5NEDcH7Tp2WeRIRwqbuC1fuDFavkgVarmY34Vj6clSxCeZ/LlFqddtuf 1gKg==
MIME-Version: 1.0
X-Received: by 10.68.71.129 with SMTP id v1mr8501084pbu.136.1369236182039; Wed, 22 May 2013 08:23:02 -0700 (PDT)
Received: by 10.70.66.7 with HTTP; Wed, 22 May 2013 08:23:01 -0700 (PDT)
In-Reply-To: <20130522.075021.510632113.mbj@tail-f.com>
References:  <20130522.061952.311188366.mbj@tail-f.com> <0E3AC84A-4400-45F9-8059-D9B50BB19880@nic.cz> <20130522.075021.510632113.mbj@tail-f.com>
Date: Wed, 22 May 2013 08:23:01 -0700
Message-ID: 
From: Andy Bierman 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=bcaec544ecfe3e908104dd5024f7
X-Gm-Message-State: ALoCoQlx85f1SqBLGJAU//18SrAtvXqJ0Q9q1RvCfEtz3anRTajqdCT0eZIBrfz/jRAZH4kp4sOE
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-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: Wed, 22 May 2013 15:23:07 -0000

--bcaec544ecfe3e908104dd5024f7
Content-Type: text/plain; charset=ISO-8859-1

On Wed, May 22, 2013 at 7:50 AM, Martin Bjorklund  wrote:

> Hi,
>
> I tried to merge the various text snippets we discussed into full
> paragraphs.  This is what I came up with:
>
> In "Terminology":
>
> - system-controlled interface: An interface is said to be
>   system-controlled if the system creates and deletes the interface
>   independently of what has been explicitly configured.  Examples are
>   interfaces representing physical hardware that appear and disappear
>   when hardware (e.g., a line card) is added or removed.
>   System-controlled interfaces may also appear if a certain
>   functionality is enabled (e.g., a loopback interface might appear if
>   the IP protocol stack is enabled).
>


These system-created nodes are not limited to interfaces.
We use a YANG extension to control these objects automatically:
http://www.netconfcentral.org/modules/yuma-ncx/2012-11-10#user-write.652
(I need to upload the version w/ corrected description).

Do you think the ad-hoc approach of having each object
define this property independently is the best general solution,
or is some sort of generalized solution (such as a
YANG extension) needed to solve this problem?



>
> - user-controlled interface: An interface is said to be
>   user-controlled if the creation of the interface is controlled by
>   adding explicit interface configuration to the running configuration
>   datastore and the removal of the interface is controlled by removing
>   explicit interface configuration from the running configuration
>   datastore.  Examples are VLAN interfaces configured on a
>   system-controlled Ethernet interface.
>
>
> In "The interface Lists":
>
>
sorry I missed it, but what field indicates
whether the interface is system or user controlled?



> For system-controlled interfaces, the "name" is the device-specific
> name of the interface.  The 'config false' list
> "/interfaces-state/interface" contains all existing interfaces on the
> device.
>
> If the device supports arbitrarily named user-controlled interfaces,
> the NETCONF server advertises the feature "arbitrary-names".  If the
> device does not advertise this feature, the names of user-controlled
> interfaces MUST match the device's naming scheme.  How a client can
> learn the naming scheme of such devices is outside the scope of this
> document.
>
> When a system-controlled interface is created by the system, the
> system tries to apply the interface configuration in
> /interfaces/interface with the same name as the new interface.  If no
> such interface configuration is found, or if the configured type does
> not match the real interface type, the system creates the interface
> without applying explicit configuration.
>
> When a user-controlled interface is created, the configuration
> determines the name of the interface.
>
>
>
>
> /martin
>

Andy

--bcaec544ecfe3e908104dd5024f7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Wed, May 22, 2013 at 7:50 AM, Martin =
Bjorklund <mbj@tail-f.com> wrote:

Hi,



I tried to merge the various text snippets we discussed into full

paragraphs. =A0This is what I came up with:



In "Terminology":



- system-controlled interface: An interface is said to be

=A0 system-controlled if the system creates and deletes the interface

=A0 independently of what has been explicitly configured. =A0Examples are
=A0 interfaces representing physical hardware that appear and disappear

=A0 when hardware (e.g., a line card) is added or removed.

=A0 System-controlled interfaces may also appear if a certain

=A0 functionality is enabled (e.g., a loopback interface might appear if
=A0 the IP protocol stack is enabled).

=

These system-created nodes are not limited to interfaces.
We use a YANG extension to control these objects automatically:

(I need to upload the version w/ corrected descr=
iption).



Do you think the ad-hoc approach of having each object<=
/div>
define this property independently is the best general solution,<=
/div>
or is some sort of generalized solution (such as a

YANG extension) needed to solve this problem?

=A0<=
/div>



- user-controlled interface: An interface is said to be

=A0 user-controlled if the creation of the interface is controlled by

=A0 adding explicit interface configuration to the running configuration
=A0 datastore and the removal of the interface is controlled by removing
=A0 explicit interface configuration from the running configuration

=A0 datastore. =A0Examples are VLAN interfaces configured on a

=A0 system-controlled Ethernet interface.





In "The interface Lists":



sorry I missed it, but what field indi=
cates
whether the interface is system or user controlled?

=A0


For system-controlled interfaces, the "name" is the device-specif=
ic

name of the interface. =A0The 'config false' list

"/interfaces-state/interface" contains all existing interfaces on=
 the

device.



If the device supports arbitrarily named user-controlled interfaces,

the NETCONF server advertises the feature "arbitrary-names". =A0I=
f the

device does not advertise this feature, the names of user-controlled

interfaces MUST match the device's naming scheme. =A0How a client can
learn the naming scheme of such devices is outside the scope of this

document.



When a system-controlled interface is created by the system, the

system tries to apply the interface configuration in

/interfaces/interface with the same name as the new interface. =A0If no

such interface configuration is found, or if the configured type does

not match the real interface type, the system creates the interface

without applying explicit configuration.



When a user-controlled interface is created, the configuration

determines the name of the interface.









/martin

Andy
=A0


--bcaec544ecfe3e908104dd5024f7--

From mbj@tail-f.com  Wed May 22 08:38: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 6266B21F91BC for ; Wed, 22 May 2013 08:38:27 -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 m83u10Mn6aRI for ; Wed, 22 May 2013 08:38:22 -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 3A5B921F93B7 for ; Wed, 22 May 2013 08:38:21 -0700 (PDT)
Received: from localhost (adsl-69-108-218-178.dsl.pltn13.pacbell.net [69.108.218.178]) by mail.tail-f.com (Postfix) with ESMTPSA id 433CB1200A32; Wed, 22 May 2013 17:38:19 +0200 (CEST)
Date: Wed, 22 May 2013 08:38:17 -0700 (PDT)
Message-Id: <20130522.083817.336589153.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund 
In-Reply-To: 
References: <0E3AC84A-4400-45F9-8059-D9B50BB19880@nic.cz> <20130522.075021.510632113.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-interfaces-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: Wed, 22 May 2013 15:38:27 -0000

Andy Bierman  wrote:
> On Wed, May 22, 2013 at 7:50 AM, Martin Bjorklund  wrote:
> 
> > Hi,
> >
> > I tried to merge the various text snippets we discussed into full
> > paragraphs.  This is what I came up with:
> >
> > In "Terminology":
> >
> > - system-controlled interface: An interface is said to be
> >   system-controlled if the system creates and deletes the interface
> >   independently of what has been explicitly configured.  Examples are
> >   interfaces representing physical hardware that appear and disappear
> >   when hardware (e.g., a line card) is added or removed.
> >   System-controlled interfaces may also appear if a certain
> >   functionality is enabled (e.g., a loopback interface might appear if
> >   the IP protocol stack is enabled).
> >
> 
> 
> These system-created nodes are not limited to interfaces.
> We use a YANG extension to control these objects automatically:
> http://www.netconfcentral.org/modules/yuma-ncx/2012-11-10#user-write.652
> (I need to upload the version w/ corrected description).
> 
> Do you think the ad-hoc approach of having each object
> define this property independently is the best general solution,
> or is some sort of generalized solution (such as a
> YANG extension) needed to solve this problem?

Note that system-controlled vs. user-controlled refers to the
*operational state* interfaces.  (or actually, the underlying objects
in the system (typically in the kernel)).

The configuration is always created, modified and deleted by the
NETCONF client.

So I believe your extension does not apply to this case.

> > - user-controlled interface: An interface is said to be
> >   user-controlled if the creation of the interface is controlled by
> >   adding explicit interface configuration to the running configuration
> >   datastore and the removal of the interface is controlled by removing
> >   explicit interface configuration from the running configuration
> >   datastore.  Examples are VLAN interfaces configured on a
> >   system-controlled Ethernet interface.
> >
> >
> > In "The interface Lists":
> >
> >
> sorry I missed it, but what field indicates
> whether the interface is system or user controlled?

There is no field for this.  Would it make sense to add one?

  // in /interfaces-state/interface:
  leaf controlled-by {
    type enumeration {
      enum system;
      enum user;
    }
  }


/martin

From andy@yumaworks.com  Wed May 22 09:01: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 DE41821F901B for ; Wed, 22 May 2013 09:01:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.767
X-Spam-Level: 
X-Spam-Status: No, score=-1.767 tagged_above=-999 required=5 tests=[AWL=0.210,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31zrYX-V4sQz for ; Wed, 22 May 2013 09:01:05 -0700 (PDT)
Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 26FA521F91A0 for ; Wed, 22 May 2013 09:00:44 -0700 (PDT)
Received: by mail-pb0-f53.google.com with SMTP id un4so1845979pbc.12 for ; Wed, 22 May 2013 09:00:41 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Jo0AZvTTRsnh1jrmm+7pEnGhSZBzZ827Oe+pEfS6Q5M=; b=nAClRd8h0nhdx9RRSpXufWI6QKAmAMEiV6P7Ax9Ql4aGm5v3cYAriPONDw4inLWRUM LBvrvbB2tz23EqUoI1oeQVqNIzf8d0m9IZXMNGK7e3ekDic/s+e4oDDT7mGNGIoLf26o VDgz+ue/PxwwAODQw+hxB0aRRcRV7Ku9znhs1usZT542BfgXaJFjceox9rclMyvRvQT6 PaM0X6hd/sQkecSfCZM97bym9vdXR4OxJ3hFHmuCZFzw2Sib2buORPIoivEHiTVGeVBE UZ0NzsXvecW08H9dnBT0T3bOsOYG+aNcQlTYs205pB98idHSLMti3DEif9S99JPgS/Ld yr+A==
MIME-Version: 1.0
X-Received: by 10.66.190.234 with SMTP id gt10mr9151797pac.136.1369238441607;  Wed, 22 May 2013 09:00:41 -0700 (PDT)
Received: by 10.70.66.7 with HTTP; Wed, 22 May 2013 09:00:41 -0700 (PDT)
In-Reply-To: <20130522.083817.336589153.mbj@tail-f.com>
References: <0E3AC84A-4400-45F9-8059-D9B50BB19880@nic.cz> <20130522.075021.510632113.mbj@tail-f.com>  <20130522.083817.336589153.mbj@tail-f.com>
Date: Wed, 22 May 2013 09:00:41 -0700
Message-ID: 
From: Andy Bierman 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=047d7bdc8c3eecd33c04dd50aaaa
X-Gm-Message-State: ALoCoQk/HoHarYtdZ6T0B6Gnc0ah6cIvX0S9zv3FiB7FmN2qKQm01AeamFu4jk/K030VkUY8qN7A
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-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: Wed, 22 May 2013 16:01:08 -0000

--047d7bdc8c3eecd33c04dd50aaaa
Content-Type: text/plain; charset=ISO-8859-1

On Wed, May 22, 2013 at 8:38 AM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
> > On Wed, May 22, 2013 at 7:50 AM, Martin Bjorklund 
> wrote:
> >
> > > Hi,
> > >
> > > I tried to merge the various text snippets we discussed into full
> > > paragraphs.  This is what I came up with:
> > >
> > > In "Terminology":
> > >
> > > - system-controlled interface: An interface is said to be
> > >   system-controlled if the system creates and deletes the interface
> > >   independently of what has been explicitly configured.  Examples are
> > >   interfaces representing physical hardware that appear and disappear
> > >   when hardware (e.g., a line card) is added or removed.
> > >   System-controlled interfaces may also appear if a certain
> > >   functionality is enabled (e.g., a loopback interface might appear if
> > >   the IP protocol stack is enabled).
> > >
> >
> >
> > These system-created nodes are not limited to interfaces.
> > We use a YANG extension to control these objects automatically:
> > http://www.netconfcentral.org/modules/yuma-ncx/2012-11-10#user-write.652
> > (I need to upload the version w/ corrected description).
> >
> > Do you think the ad-hoc approach of having each object
> > define this property independently is the best general solution,
> > or is some sort of generalized solution (such as a
> > YANG extension) needed to solve this problem?
>
> Note that system-controlled vs. user-controlled refers to the
> *operational state* interfaces.  (or actually, the underlying objects
> in the system (typically in the kernel)).
>
> The configuration is always created, modified and deleted by the
> NETCONF client.
>
> So I believe your extension does not apply to this case.
>
>
OK -- I guess 2 copies of everything works.
It supports pre-provisioning in a nice way.



> > > - user-controlled interface: An interface is said to be
> > >   user-controlled if the creation of the interface is controlled by
> > >   adding explicit interface configuration to the running configuration
> > >   datastore and the removal of the interface is controlled by removing
> > >   explicit interface configuration from the running configuration
> > >   datastore.  Examples are VLAN interfaces configured on a
> > >   system-controlled Ethernet interface.
> > >
> > >
> > > In "The interface Lists":
> > >
> > >
> > sorry I missed it, but what field indicates
> > whether the interface is system or user controlled?
>
> There is no field for this.  Would it make sense to add one?
>
>   // in /interfaces-state/interface:
>   leaf controlled-by {
>     type enumeration {
>       enum system;
>       enum user;
>     }
>   }
>
>

not sure --  it may help but I haven't tried
to write an app using this module.



> /martin
>


Andy

--047d7bdc8c3eecd33c04dd50aaaa
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Wed, May 22, 2013 at 8:38 AM, Martin =
Bjorklund <mbj@tail-f.com> wrote:

Andy Bierman <andy@yumaworks.com> wrote:

> On Wed, May 22, 2013 at 7:50 AM, Martin Bjorklund <mbj@tail-f.com> wrote:

>

> > Hi,

> >

> > I tried to merge the various text snippets we discussed into full=


> > paragraphs. =A0This is what I came up with:

> >

> > In "Terminology":

> >

> > - system-controlled interface: An interface is said to be

> > =A0 system-controlled if the system creates and deletes the inter=
face

> > =A0 independently of what has been explicitly configured. =A0Exam=
ples are

> > =A0 interfaces representing physical hardware that appear and dis=
appear

> > =A0 when hardware (e.g., a line card) is added or removed.

> > =A0 System-controlled interfaces may also appear if a certain

> > =A0 functionality is enabled (e.g., a loopback interface might ap=
pear if

> > =A0 the IP protocol stack is enabled).

> >

>

>

> These system-created nodes are not limited to interfaces.

> We use a YANG extension to control these objects automatically:

> http://www.netconfcentral.org/modules/yuma=
-ncx/2012-11-10#user-write.652

> (I need to upload the version w/ corrected description).

>

> Do you think the ad-hoc approach of having each object

> define this property independently is the best general solution,

> or is some sort of generalized solution (such as a

> YANG extension) needed to solve this problem?



Note that system-controlled vs. user-controlled refers to the

*operational state* interfaces. =A0(or actually, the underlying objects

in the system (typically in the kernel)).



The configuration is always created, modified and deleted by the

NETCONF client.



So I believe your extension does not apply to this case.



OK -- I guess 2 copies of everything w=
orks.
It supports pre-provisioning in a nice way.

<=
/div>
=A0


> > - user-controlled interface: An interface is said to be

> > =A0 user-controlled if the creation of the interface is controlle=
d by

> > =A0 adding explicit interface configuration to the running config=
uration

> > =A0 datastore and the removal of the interface is controlled by r=
emoving

> > =A0 explicit interface configuration from the running configurati=
on

> > =A0 datastore. =A0Examples are VLAN interfaces configured on a
> > =A0 system-controlled Ethernet interface.

> >

> >

> > In "The interface Lists":

> >

> >

> sorry I missed it, but what field indicates

> whether the interface is system or user controlled?



There is no field for this. =A0Would it make sense to add one?



=A0 // in /interfaces-state/interface:

=A0 leaf controlled-by {

=A0 =A0 type enumeration {

=A0 =A0 =A0 enum system;

=A0 =A0 =A0 enum user;

=A0 =A0 }

=A0 }




not sure -- =A0it may help but I have=
n't tried
to write an app using this module.







/martin




Andy


--047d7bdc8c3eecd33c04dd50aaaa--

From j.schoenwaelder@jacobs-university.de  Wed May 22 11:14: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 B01AF21F9631 for ; Wed, 22 May 2013 11:14:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.161
X-Spam-Level: 
X-Spam-Status: No, score=-103.161 tagged_above=-999 required=5 tests=[AWL=0.088, 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 yQZFLDAN8kVK for ; Wed, 22 May 2013 11:14:40 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 631BB21F9350 for ; Wed, 22 May 2013 11:14:39 -0700 (PDT)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 103D820BE9; Wed, 22 May 2013 20:14: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 Ns3nHVIQXtkN; Wed, 22 May 2013 20:14:38 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0DF7F2096B; Wed, 22 May 2013 20:14:38 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id B709B266D3F6; Wed, 22 May 2013 20:14:36 +0200 (CEST)
Date: Wed, 22 May 2013 20:14:36 +0200
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20130522181435.GA30425@elstar.local>
Mail-Followup-To: Martin Bjorklund , lhotka@nic.cz, netmod@ietf.org
References:  <20130522.061952.311188366.mbj@tail-f.com> <0E3AC84A-4400-45F9-8059-D9B50BB19880@nic.cz> <20130522.075021.510632113.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20130522.075021.510632113.mbj@tail-f.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-11.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: Wed, 22 May 2013 18:14:45 -0000

On Wed, May 22, 2013 at 07:50:21AM -0700, Martin Bjorklund wrote:
> Hi,
> 
> I tried to merge the various text snippets we discussed into full
> paragraphs.  This is what I came up with:

[...]

Looks OK to me (but then I am bad judge because I know what the text
is supposed to describe).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From ietfc@btconnect.com  Thu May 23 08:36:02 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 0092721F96C1 for ; Thu, 23 May 2013 08:36:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.688
X-Spam-Level: 
X-Spam-Status: No, score=-4.688 tagged_above=-999 required=5 tests=[AWL=1.911,  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 gLVw5Gun8iaM for ; Thu, 23 May 2013 08:35:57 -0700 (PDT)
Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 678F921F9718 for ; Thu, 23 May 2013 08:35:53 -0700 (PDT)
Received: from mail146-tx2-R.bigfish.com (10.9.14.235) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.23; Thu, 23 May 2013 15:35:52 +0000
Received: from mail146-tx2 (localhost [127.0.0.1])	by mail146-tx2-R.bigfish.com (Postfix) with ESMTP id 9CEDA20363; Thu, 23 May 2013 15:35:52 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.254.197; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0711HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -15
X-BigFish: PS-15(zz98dI9371I542I1432Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275bh8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh304l1d11m1155h)
Received: from mail146-tx2 (localhost.localdomain [127.0.0.1]) by mail146-tx2 (MessageSwitch) id 1369323306271956_8311; Thu, 23 May 2013 15:35:06 +0000 (UTC)
Received: from TX2EHSMHS034.bigfish.com (unknown [10.9.14.233])	by mail146-tx2.bigfish.com (Postfix) with ESMTP id 3C5314C0183; Thu, 23 May 2013 15:35:06 +0000 (UTC)
Received: from DB3PRD0711HT001.eurprd07.prod.outlook.com (157.56.254.197) by TX2EHSMHS034.bigfish.com (10.9.99.134) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 23 May 2013 15:35:05 +0000
Received: from AMXPRD0310HT001.eurprd03.prod.outlook.com (157.56.248.133) by pod51017.outlook.com (10.255.183.34) with Microsoft SMTP Server (TLS) id 14.16.311.1; Thu, 23 May 2013 15:35:00 +0000
Message-ID: <00a101ce57ca$50c19fc0$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Andy Bierman , Martin Bjorklund 
References: <0E3AC84A-4400-45F9-8059-D9B50BB19880@nic.cz><20130522.075021.510632113.mbj@tail-f.com><20130522.083817.336589153.mbj@tail-f.com> 
Date: Thu, 23 May 2013 16:29:11 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.248.133]
X-OriginatorOrg: btconnect.com
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-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: Thu, 23 May 2013 15:36:02 -0000

----- Original Message -----
From: "Andy Bierman" 
To: "Martin Bjorklund" 
Cc: 
Sent: Wednesday, May 22, 2013 5:00 PM
> On Wed, May 22, 2013 at 8:38 AM, Martin Bjorklund 
wrote:
>
> > Andy Bierman  wrote:
> > > On Wed, May 22, 2013 at 7:50 AM, Martin Bjorklund 
> > wrote:
> > >
> > > > Hi,
> > > >
> > > > I tried to merge the various text snippets we discussed into
full
> > > > paragraphs.  This is what I came up with:
> > > >
> > > > In "Terminology":
> > > >
> > > > - system-controlled interface: An interface is said to be
> > > >   system-controlled if the system creates and deletes the
interface
> > > >   independently of what has been explicitly configured.
Examples are
> > > >   interfaces representing physical hardware that appear and
disappear
> > > >   when hardware (e.g., a line card) is added or removed.
> > > >   System-controlled interfaces may also appear if a certain
> > > >   functionality is enabled (e.g., a loopback interface might
appear if
> > > >   the IP protocol stack is enabled).
> > > >
> > > These system-created nodes are not limited to interfaces.
> > > We use a YANG extension to control these objects automatically:
> > >
http://www.netconfcentral.org/modules/yuma-ncx/2012-11-10#user-write.652
> > > (I need to upload the version w/ corrected description).
> > >
> > > Do you think the ad-hoc approach of having each object
> > > define this property independently is the best general solution,
> > > or is some sort of generalized solution (such as a
> > > YANG extension) needed to solve this problem?
> >
> > Note that system-controlled vs. user-controlled refers to the
> > *operational state* interfaces.  (or actually, the underlying
objects
> > in the system (typically in the kernel)).
> >
> > The configuration is always created, modified and deleted by the
> > NETCONF client.
> >
> > So I believe your extension does not apply to this case.
> >
> OK -- I guess 2 copies of everything works.
> It supports pre-provisioning in a nice way.

Andy

Could you be more specific about how you see it happening?

I had thought that pre-provisioning, say configuring eth0 to HDX
100Mbit/s where the card eth0 has yet to be plugged in, would create
entries in both /interfaces/ and /interface-state/ but the sense I now
have is the the latter entry must wait until the card appears.  Which
means that both /interfaces/ and /interface-state/ must be gotten in
order to understand where the box is at, that the absence of an entry in
/interface-state/ means that the card has yet to appear (which seems a
bit clumsy).  And it means that the server must not stop me from
configuring a name such as eth0 even though that has a specific meaning
to the server.

And if I create vlan0 to run over eth1 which does not yet exist but will
carry it when it does, then since vlan0 specifies eth1 as a carrier I
must configure eth1 even if there is nothing I wish to configure on it,
and even then, I cannot use an interface-state-ref until the card has
appeared which may mean going back and reconfiguring vlan0.

Do I understand this correctly?

Tom Petch

>
> > > > - user-controlled interface: An interface is said to be
> > > >   user-controlled if the creation of the interface is controlled
by
> > > >   adding explicit interface configuration to the running
configuration
> > > >   datastore and the removal of the interface is controlled by
removing
> > > >   explicit interface configuration from the running
configuration
> > > >   datastore.  Examples are VLAN interfaces configured on a
> > > >   system-controlled Ethernet interface.
> > > >
> > > >
> > > > In "The interface Lists":
> > > >
> > > >
> > > sorry I missed it, but what field indicates
> > > whether the interface is system or user controlled?
> >
> > There is no field for this.  Would it make sense to add one?
> >
> >   // in /interfaces-state/interface:
> >   leaf controlled-by {
> >     type enumeration {
> >       enum system;
> >       enum user;
> >     }
> >   }
> >
> >
>
> not sure --  it may help but I haven't tried
> to write an app using this module.
>
>
>
> > /martin
> >
>
>
> Andy
>


------------------------------------------------------------------------
--------


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



From mbj@tail-f.com  Thu May 23 09:32:21 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 D028921F96D5 for ; Thu, 23 May 2013 09:32:19 -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 H86Hy00p+qHh for ; Thu, 23 May 2013 09:32: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 A996B21F973B for ; Thu, 23 May 2013 09:31:12 -0700 (PDT)
Received: from localhost (unknown [75.103.8.98]) by mail.tail-f.com (Postfix) with ESMTPSA id 72E661200A35; Thu, 23 May 2013 18:31:10 +0200 (CEST)
Date: Thu, 23 May 2013 09:31:09 -0700 (PDT)
Message-Id: <20130523.093109.289996257.mbj@tail-f.com>
To: ietfc@btconnect.com
From: Martin Bjorklund 
In-Reply-To: <00a101ce57ca$50c19fc0$4001a8c0@gateway.2wire.net>
References: <20130522.083817.336589153.mbj@tail-f.com>  <00a101ce57ca$50c19fc0$4001a8c0@gateway.2wire.net>
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-interfaces-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: Thu, 23 May 2013 16:32:21 -0000

Hi,

t.petch  wrote:
> I had thought that pre-provisioning, say configuring eth0 to HDX
> 100Mbit/s where the card eth0 has yet to be plugged in, would create
> entries in both /interfaces/ and /interface-state/ but the sense I now
> have is the the latter entry must wait until the card appears.  Which
> means that both /interfaces/ and /interface-state/ must be gotten in
> order to understand where the box is at, that the absence of an entry in
> /interface-state/ means that the card has yet to appear (which seems a
> bit clumsy).

To some extent I agree with you.  My first thought was that the
pre-provisioned interface would show up in /interfaces-state/interface
with status 'not-present'.  But then Juergen pointed out that this is
not how devices work today.  If you configure a new interafce in
/etc/... on linux for non-existing hardware, it does not show in
ifconfig output.  Seems to be the same on popular routers as well.

It is also a bit unclear what exactly the problem is with the current
approach.  If you want to learn the status of an interface, you look
it up in /interfaces-state/interface.  If it is not there, it means
that there is no interface with this name created in the system.


/martin

From j.schoenwaelder@jacobs-university.de  Thu May 23 11:49:22 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 29F9321F9412 for ; Thu, 23 May 2013 11:49:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.87
X-Spam-Level: 
X-Spam-Status: No, score=-102.87 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_15=0.6, 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 OV+sQ5OqguZN for ; Thu, 23 May 2013 11:49:01 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 982BF21F940D for ; Thu, 23 May 2013 11:25:58 -0700 (PDT)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 491B020BED; Thu, 23 May 2013 20:25:57 +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 b7uukDSBUwBn; Thu, 23 May 2013 20:25:57 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 35CBC20B6C; Thu, 23 May 2013 20:25:55 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 2CA2B2670BFF; Thu, 23 May 2013 20:25:54 +0200 (CEST)
Date: Thu, 23 May 2013 20:25:54 +0200
From: Juergen Schoenwaelder 
To: "t.petch" 
Message-ID: <20130523182554.GB34233@elstar.local>
Mail-Followup-To: "t.petch" , Andy Bierman , Martin Bjorklund , netmod@ietf.org
References: <0E3AC84A-4400-45F9-8059-D9B50BB19880@nic.cz> <20130522.075021.510632113.mbj@tail-f.com>  <20130522.083817.336589153.mbj@tail-f.com>  <00a101ce57ca$50c19fc0$4001a8c0@gateway.2wire.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <00a101ce57ca$50c19fc0$4001a8c0@gateway.2wire.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-11.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: Thu, 23 May 2013 18:49:22 -0000

On Thu, May 23, 2013 at 04:29:11PM +0100, t.petch wrote:
 
> I had thought that pre-provisioning, say configuring eth0 to HDX
> 100Mbit/s where the card eth0 has yet to be plugged in, would create
> entries in both /interfaces/ and /interface-state/ but the sense I now
> have is the the latter entry must wait until the card appears.  Which
> means that both /interfaces/ and /interface-state/ must be gotten in
> order to understand where the box is at, that the absence of an entry in
> /interface-state/ means that the card has yet to appear (which seems a
> bit clumsy).

The /interface-state tree reports operational state. If there is no
interface eth0, there hardly can be any operational state for it. It
simply does not exist. I do not see why this would be clumsy.

> And it means that the server must not stop me from configuring a
> name such as eth0 even though that has a specific meaning to the
> server.

Yes, if the system ever can have eth0, you can pre-configure it.

> And if I create vlan0 to run over eth1 which does not yet exist but will
> carry it when it does, then since vlan0 specifies eth1 as a carrier I
> must configure eth1 even if there is nothing I wish to configure on it,

Yes, you may want to enable that interface by configuring it. This is
a feature, not a bug.

> and even then, I cannot use an interface-state-ref until the card has
> appeared which may mean going back and reconfiguring vlan0.

I am not sure I understand what the problem is. Yes, if you plug in a
card that pops up as eth4, then yes, your configuration needs to match
that. The same applies if you plug the cable into 4 instead of port 8,
you need to update the config. There is no AI here.

/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 May 23 15:22: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 3BC9E21F996E for ; Thu, 23 May 2013 15:22:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.662
X-Spam-Level: 
X-Spam-Status: No, score=-1.662 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 DAXB5GSHNzDo for ; Thu, 23 May 2013 15:22: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 BC66821F9916 for ; Thu, 23 May 2013 14:37:36 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id EC04F13F890; Thu, 23 May 2013 23:37:30 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1369345051; bh=tuohOGRbWVCGWG85Y3wT2ukfQgXxAwcdgrLUh3b24PA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=HN3Rp4oH435+3JFIHahZ2zAIYggX3OVPpCRgQqcvzZIamWE503R6RKbXl0dArorTC XfgSbUIJiu1EjON19dBk0kAx6gfcsCG+B4OyucjBOeglgLrtHs5VAN2YNpF0mSbA6S MraFkftciMwPlsiZYQ1B6l9YvJo8A8fSsRBHLsjE=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: <20130523182554.GB34233@elstar.local>
Date: Thu, 23 May 2013 23:37:30 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <0E3AC84A-4400-45F9-8059-D9B50BB19880@nic.cz> <20130522.075021.510632113.mbj@tail-f.com>  <20130522.083817.336589153.mbj@tail-f.com>  <00a101ce57ca$50c19fc0$4001a8c0@gateway.2wire.net> <20130523182554.GB34233@elstar.local>
To: Juergen Schoenwaelder 
X-Mailer: Apple Mail (2.1503)
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-interfaces-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: Thu, 23 May 2013 22:22:52 -0000

On May 23, 2013, at 8:25 PM, Juergen Schoenwaelder =
 wrote:

> On Thu, May 23, 2013 at 04:29:11PM +0100, t.petch wrote:
>=20
>> I had thought that pre-provisioning, say configuring eth0 to HDX
>> 100Mbit/s where the card eth0 has yet to be plugged in, would create
>> entries in both /interfaces/ and /interface-state/ but the sense I =
now
>> have is the the latter entry must wait until the card appears.  Which
>> means that both /interfaces/ and /interface-state/ must be gotten in
>> order to understand where the box is at, that the absence of an entry =
in
>> /interface-state/ means that the card has yet to appear (which seems =
a
>> bit clumsy).
>=20
> The /interface-state tree reports operational state. If there is no
> interface eth0, there hardly can be any operational state for it. It
> simply does not exist. I do not see why this would be clumsy.

Yes, and moreover: we cannot be sure that the pre-provisioned config =
will be applied at all after the interface is installed (e.g., there may =
be mismatch in type).

>=20
>> And it means that the server must not stop me from configuring a
>> name such as eth0 even though that has a specific meaning to the
>> server.
>=20
> Yes, if the system ever can have eth0, you can pre-configure it.
>=20
>> And if I create vlan0 to run over eth1 which does not yet exist but =
will
>> carry it when it does, then since vlan0 specifies eth1 as a carrier I
>> must configure eth1 even if there is nothing I wish to configure on =
it,
>=20
> Yes, you may want to enable that interface by configuring it. This is
> a feature, not a bug.
>=20
>> and even then, I cannot use an interface-state-ref until the card has
>> appeared which may mean going back and reconfiguring vlan0.

Note that a leafref from config cannot refer to a leaf in operational =
state (YANG rule).
So interface-state-ref is confined to operational state data.

>=20
> I am not sure I understand what the problem is. Yes, if you plug in a
> card that pops up as eth4, then yes, your configuration needs to match
> that. The same applies if you plug the cable into 4 instead of port 8,
> you need to update the config. There is no AI here.

This goes back to the discussion of using opaque IDs as keys in the =
configuration list instead of the real interface names, and having the =
real name as another (non-key) leaf in the list entry. The VLAN entries =
would then refer to the opaque ID of the physical interface and this =
won't change. So, the only necessary change would be to update the name =
of the main interface (eth4) in *one* place. I still believe this would =
be a far better solution, because a very complex stack of interfaces =
could be preprovisioned without the risk of being forced to rewrite the =
name of the physical interface in many places.

Lada=20

>=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 ietfc@btconnect.com  Fri May 24 09:56: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 712A721F9413 for ; Fri, 24 May 2013 09:56:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.516
X-Spam-Level: 
X-Spam-Status: No, score=-4.516 tagged_above=-999 required=5 tests=[AWL=1.483,  BAYES_00=-2.599, J_CHICKENPOX_15=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 dyuiIkOXD8v8 for ; Fri, 24 May 2013 09:56:45 -0700 (PDT)
Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8278A21F9418 for ; Fri, 24 May 2013 09:56:45 -0700 (PDT)
Received: from mail101-tx2-R.bigfish.com (10.9.14.226) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.23; Fri, 24 May 2013 16:56:44 +0000
Received: from mail101-tx2 (localhost [127.0.0.1])	by mail101-tx2-R.bigfish.com (Postfix) with ESMTP id 60A981E09C5; Fri, 24 May 2013 16:56:44 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.250.181; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0711HT002.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -15
X-BigFish: PS-15(zz98dI9371I542I1432Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275bh8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh304l1d11m1155h)
Received: from mail101-tx2 (localhost.localdomain [127.0.0.1]) by mail101-tx2 (MessageSwitch) id 1369414546408445_18572; Fri, 24 May 2013 16:55:46 +0000 (UTC)
Received: from TX2EHSMHS023.bigfish.com (unknown [10.9.14.244])	by mail101-tx2.bigfish.com (Postfix) with ESMTP id 569C54027B; Fri, 24 May 2013 16:55:46 +0000 (UTC)
Received: from AMSPRD0711HT002.eurprd07.prod.outlook.com (157.56.250.181) by TX2EHSMHS023.bigfish.com (10.9.99.123) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 24 May 2013 16:55:45 +0000
Received: from pc6 (86.173.197.168) by pod51017.outlook.com (10.242.14.163) with Microsoft SMTP Server (TLS) id 14.16.311.1; Fri, 24 May 2013 16:55:43 +0000
Message-ID: <05f401ce589e$c1324fa0$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Juergen Schoenwaelder 
References: <0E3AC84A-4400-45F9-8059-D9B50BB19880@nic.cz> <20130522.075021.510632113.mbj@tail-f.com>  <20130522.083817.336589153.mbj@tail-f.com>  <00a101ce57ca$50c19fc0$4001a8c0@gateway.2wire.net> <20130523182554.GB34233@elstar.local>
Date: Fri, 24 May 2013 17:49:42 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [86.173.197.168]
X-OriginatorOrg: btconnect.com
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-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, 24 May 2013 16:56:58 -0000

----- Original Message -----
From: "Juergen Schoenwaelder" 
To: "t.petch" 
Cc: "Andy Bierman" ; "Martin Bjorklund"
; 
Sent: Thursday, May 23, 2013 7:25 PM


> On Thu, May 23, 2013 at 04:29:11PM +0100, t.petch wrote:
>
> > I had thought that pre-provisioning, say configuring eth0 to HDX
> > 100Mbit/s where the card eth0 has yet to be plugged in, would create
> > entries in both /interfaces/ and /interface-state/ but the sense I
now
> > have is the the latter entry must wait until the card appears.
Which
> > means that both /interfaces/ and /interface-state/ must be gotten in
> > order to understand where the box is at, that the absence of an
entry in
> > /interface-state/ means that the card has yet to appear (which seems
a
> > bit clumsy).
>
> The /interface-state tree reports operational state. If there is no
> interface eth0, there hardly can be any operational state for it. It
> simply does not exist. I do not see why this would be clumsy.

Juergen

I was using clumsy as the antithesis of elegant.

Elegant would be having an object that I could query to find out what is
currently going on, plus perhaps a notification of a significant change,
such as the card being plugged in, and so appearing in /interface-state.

Clumsy was querying /interface-state and having to use a failure,
because the object does not yet exist, to infer what is currently going
on - or not.

Perhaps it is no different to SNMP polling every 30 seconds in order to
find out.

Tom Petch


> > And it means that the server must not stop me from configuring a
> > name such as eth0 even though that has a specific meaning to the
> > server.
>
> Yes, if the system ever can have eth0, you can pre-configure it.
>
> > And if I create vlan0 to run over eth1 which does not yet exist but
will
> > carry it when it does, then since vlan0 specifies eth1 as a carrier
I
> > must configure eth1 even if there is nothing I wish to configure on
it,
>
> Yes, you may want to enable that interface by configuring it. This is
> a feature, not a bug.
>
> > and even then, I cannot use an interface-state-ref until the card
has
> > appeared which may mean going back and reconfiguring vlan0.
>
> I am not sure I understand what the problem is. Yes, if you plug in a
> card that pops up as eth4, then yes, your configuration needs to match
> that. The same applies if you plug the cable into 4 instead of port 8,
> you need to update the config. There is no AI here.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         
>



From ietfc@btconnect.com  Tue May 28 02:39: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 85FB321F944C for ; Tue, 28 May 2013 02:39:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.201
X-Spam-Level: 
X-Spam-Status: No, score=0.201 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_15=0.6, 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 sdg+WrXY+e+Y for ; Tue, 28 May 2013 02:39:38 -0700 (PDT)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 9C59821F943A for ; Tue, 28 May 2013 02:39:38 -0700 (PDT)
Received: from mail144-ch1-R.bigfish.com (10.43.68.233) by CH1EHSOBE001.bigfish.com (10.43.70.51) with Microsoft SMTP Server id 14.1.225.23; Tue, 28 May 2013 09:39:37 +0000
Received: from mail144-ch1 (localhost [127.0.0.1])	by mail144-ch1-R.bigfish.com (Postfix) with ESMTP id 0868740287; Tue, 28 May 2013 09:39:35 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.249.213; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0710HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -17
X-BigFish: PS-17(zz98dI9371I148cI542I1432I1418Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275bh8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh304l1d11m1155h)
Received: from mail144-ch1 (localhost.localdomain [127.0.0.1]) by mail144-ch1 (MessageSwitch) id 1369733973894945_8347; Tue, 28 May 2013 09:39:33 +0000 (UTC)
Received: from CH1EHSMHS043.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.242])	by mail144-ch1.bigfish.com (Postfix) with ESMTP id B058B2E007E;	Tue, 28 May 2013 09:39:33 +0000 (UTC)
Received: from AM2PRD0710HT001.eurprd07.prod.outlook.com (157.56.249.213) by CH1EHSMHS043.bigfish.com (10.43.69.252) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 28 May 2013 09:39:30 +0000
Received: from AMXPRD0111HT004.eurprd01.prod.exchangelabs.com (157.56.250.117) by pod51017.outlook.com (10.255.165.36) with Microsoft SMTP Server (TLS) id 14.16.311.1; Tue, 28 May 2013 09:39:20 +0000
Message-ID: <019d01ce5b86$71d43140$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Ladislav Lhotka 
References: <0E3AC84A-4400-45F9-8059-D9B50BB19880@nic.cz> <20130522.075021.510632113.mbj@tail-f.com>  <20130522.083817.336589153.mbj@tail-f.com>  <00a101ce57ca$50c19fc0$4001a8c0@gateway.2wire.net> <20130523182554.GB34233@elstar.local> 
Date: Tue, 28 May 2013 09:33:03 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.250.117]
X-OriginatorOrg: btconnect.com
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-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: Tue, 28 May 2013 09:39:43 -0000

----- Original Message -----
From: "Ladislav Lhotka" 
To: "Juergen Schoenwaelder" 
Cc: "t.petch" ; 
Sent: Thursday, May 23, 2013 10:37 PM
On May 23, 2013, at 8:25 PM, Juergen Schoenwaelder
 wrote:

> On Thu, May 23, 2013 at 04:29:11PM +0100, t.petch wrote:
>

>
>> And if I create vlan0 to run over eth1 which does not yet exist but
will
>> carry it when it does, then since vlan0 specifies eth1 as a carrier I
>> must configure eth1 even if there is nothing I wish to configure on
it,
>
> Yes, you may want to enable that interface by configuring it. This is
> a feature, not a bug.
>
>> and even then, I cannot use an interface-state-ref until the card has
>> appeared which may mean going back and reconfiguring vlan0.

Note that a leafref from config cannot refer to a leaf in operational
state (YANG rule).
So interface-state-ref is confined to operational state data.



Lada, thanks for  putting me right - another of those ... Little Rules
that I forget.

Forgetting preconfiguration, looking at just configuration, this also
means

- I want to confgure vlan0 to run over something, say eth0
- I must link vlan0 to eth0
- I use a leafref to link the two
- since vlan0 is config, then I must also configure eth0, even though
everything the system has done for itself for eth0 is fine and I do not
need to change anything, yet I must create the entry in
/if:interfaces/if:interface else I cannot link to it.

Have I got it right?

>
> I am not sure I understand what the problem is. Yes, if you plug in a
> card that pops up as eth4, then yes, your configuration needs to match
> that. The same applies if you plug the cable into 4 instead of port 8,
> you need to update the config. There is no AI here.

This goes back to the discussion of using opaque IDs as keys in the
configuration list instead of the real interface names, and having the
real name as another (non-key) leaf in the list entry. The VLAN entries
would then refer to the opaque ID of the physical interface and this
won't change. So, the only necessary change would be to update the name
of the main interface (eth4) in *one* place. I still believe this would
be a far better solution, because a very complex stack of interfaces
could be preprovisioned without the risk of being forced to rewrite the
name of the physical interface in many places.


Yes. Trouble is, the current SNMP key has been used outside SNMP and is
taken to be the best reference to use to refer to an interface so moving
to /if:interfaces/if:interface/if:name or
/if:interfaces-state/if:interface/if:name will be one hurdle and then
having an opaque ID might be too great a one.  I think that people will
use name (or ifIndex) in other protocols, and then have to jump through
a few hoops when that property is not as good as they would like it to
be, as happens at present with the inconstancy of ifIndex.

The best databases I know have opaque IDs as keys, which I am fine with,
but see my fellow users, who have not had to wrestle with issues such as
these, struggle with, thinking that what is intuitively obvious to them
as the unique identifier is not actually unique or an identifier.

Tom Petch

Lada

>
> /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

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







From lhotka@nic.cz  Tue May 28 09:56: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 B142321F98A1 for ; Tue, 28 May 2013 09:56:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 0fcxYIlEsFkD for ; Tue, 28 May 2013 09:56:33 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 7B90E21F9467 for ; Tue, 28 May 2013 09:56:32 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 9746C140411; Tue, 28 May 2013 18:56:31 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1369760191; bh=oBLFAPDFUy020chXJAhXvKIXIfUgDc65Hu9ezRYCMoo=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Q3AHk7wVj3cBbhWuF40/gZQzlCBfTbKEi7C3ZZPBMecUM3W7XrVsZBKeeALykk3PR 3V8te5wtH0j8UMlJlppbRUD45EV+vI92o8PemSYSqHwhhm2w6243Y4PPofbdrVujFY VWTzE09jKDJJkaBDvQBJGi93WZMwTYCysANM7nV8=
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Content-Type: text/plain; charset=iso-8859-1
From: Ladislav Lhotka 
X-Priority: 3
In-Reply-To: <019d01ce5b86$71d43140$4001a8c0@gateway.2wire.net>
Date: Tue, 28 May 2013 18:56:31 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <5AB07445-A5EA-4105-B5CE-85B14D3BF397@nic.cz>
References: <0E3AC84A-4400-45F9-8059-D9B50BB19880@nic.cz> <20130522.075021.510632113.mbj@tail-f.com>  <20130522.083817.336589153.mbj@tail-f.com>  <00a101ce57ca$50c19fc0$4001a8c0@gateway.2wire.net> <20130523182554.GB34233@elstar.local>  <019d01ce5b86$71d43140$4001a8c0@gateway.2wire.net>
To: t.petch 
X-Mailer: Apple Mail (2.1503)
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-interfaces-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: Tue, 28 May 2013 16:56:34 -0000

On May 28, 2013, at 10:33 AM, t.petch  wrote:

> ----- Original Message -----
> From: "Ladislav Lhotka" 
> To: "Juergen Schoenwaelder" 
> Cc: "t.petch" ; 
> Sent: Thursday, May 23, 2013 10:37 PM
> On May 23, 2013, at 8:25 PM, Juergen Schoenwaelder
>  wrote:
>=20
>> On Thu, May 23, 2013 at 04:29:11PM +0100, t.petch wrote:
>>=20
> 
>>=20
>>> And if I create vlan0 to run over eth1 which does not yet exist but
> will
>>> carry it when it does, then since vlan0 specifies eth1 as a carrier =
I
>>> must configure eth1 even if there is nothing I wish to configure on
> it,
>>=20
>> Yes, you may want to enable that interface by configuring it. This is
>> a feature, not a bug.
>>=20
>>> and even then, I cannot use an interface-state-ref until the card =
has
>>> appeared which may mean going back and reconfiguring vlan0.
>=20
> Note that a leafref from config cannot refer to a leaf in operational
> state (YANG rule).
> So interface-state-ref is confined to operational state data.
>=20
> 
>=20
> Lada, thanks for  putting me right - another of those ... Little Rules
> that I forget.
>=20
> Forgetting preconfiguration, looking at just configuration, this also
> means
>=20
> - I want to confgure vlan0 to run over something, say eth0
> - I must link vlan0 to eth0
> - I use a leafref to link the two
> - since vlan0 is config, then I must also configure eth0, even though
> everything the system has done for itself for eth0 is fine and I do =
not
> need to change anything, yet I must create the entry in
> /if:interfaces/if:interface else I cannot link to it.
>=20
> Have I got it right?

Yes, that's correct, though somewhat unfortunate. For every =
interface-ref, even from other modules, the corresponding entry in =
/if:interfaces/if:interface has to be present. If it isn't, it has to be =
created just for this purpose, provided that the client has write access =
to the interface list.

>=20
>>=20
>> I am not sure I understand what the problem is. Yes, if you plug in a
>> card that pops up as eth4, then yes, your configuration needs to =
match
>> that. The same applies if you plug the cable into 4 instead of port =
8,
>> you need to update the config. There is no AI here.
>=20
> This goes back to the discussion of using opaque IDs as keys in the
> configuration list instead of the real interface names, and having the
> real name as another (non-key) leaf in the list entry. The VLAN =
entries
> would then refer to the opaque ID of the physical interface and this
> won't change. So, the only necessary change would be to update the =
name
> of the main interface (eth4) in *one* place. I still believe this =
would
> be a far better solution, because a very complex stack of interfaces
> could be preprovisioned without the risk of being forced to rewrite =
the
> name of the physical interface in many places.
>=20
> 
> Yes. Trouble is, the current SNMP key has been used outside SNMP and =
is
> taken to be the best reference to use to refer to an interface so =
moving
> to /if:interfaces/if:interface/if:name or
> /if:interfaces-state/if:interface/if:name will be one hurdle and then
> having an opaque ID might be too great a one.  I think that people =
will
> use name (or ifIndex) in other protocols, and then have to jump =
through
> a few hoops when that property is not as good as they would like it to
> be, as happens at present with the inconstancy of ifIndex.
>=20
> The best databases I know have opaque IDs as keys, which I am fine =
with,
> but see my fellow users, who have not had to wrestle with issues such =
as
> these, struggle with, thinking that what is intuitively obvious to =
them
> as the unique identifier is not actually unique or an identifier.

Yes, I am afraid you are right. Interestingly, it is not a problem for =
software, such as MongoDB. It takes some time to get used to the proper =
ways of dealing with object IDs, but users have no choice, and then, =
after a period of huffing and puffing, one can eventually take advantage =
of their approach. On the other hand, for a standard, such a hurdle =
seems to be a non-starter.

Lada
=20
>=20
> Tom Petch
>=20
> Lada
>=20
>>=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
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20
>=20
>=20
>=20

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





From jeffrey.K.lange@ge.com  Wed May 29 10:53: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 0C70821F95FD for ; Wed, 29 May 2013 10:53:52 -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 nypFPQL1viHm for ; Wed, 29 May 2013 10:53:44 -0700 (PDT)
Received: from exprod5og104.obsmtp.com (exprod5og104.obsmtp.com [64.18.0.178]) by ietfa.amsl.com (Postfix) with ESMTP id 9438421F95EC for ; Wed, 29 May 2013 10:53:29 -0700 (PDT)
Received: from cinmlip10.e2k.ad.ge.com ([165.156.4.1]) (using TLSv1) by exprod5ob104.postini.com ([64.18.4.12]) with SMTP ID DSNKUaZAmBeTufyvA04aIz1rHgH31bLq03pO@postini.com; Wed, 29 May 2013 10:53:29 PDT
Received: from unknown (HELO cinmlef06.e2k.ad.ge.com) ([3.159.213.37]) by cinmlip10.e2k.ad.ge.com with ESMTP; 29 May 2013 13:53:26 -0400
Received: from cinmlef17.e2k.ad.ge.com ([3.159.213.93]) by cinmlef06.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 29 May 2013 13:53:26 -0400
Received: from CINMLCH02.e2k.ad.ge.com ([3.159.212.51]) by cinmlef17.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 29 May 2013 13:53:22 -0400
Received: from CINURCNA14.e2k.ad.ge.com (3.159.212.151) by CINMLCH02.e2k.ad.ge.com (3.159.212.51) with Microsoft SMTP Server (TLS) id 14.3.136.1; Wed, 29 May 2013 13:53:19 -0400
Received: from CINURCNA15.e2k.ad.ge.com ([169.254.3.88]) by CINURCNA14.e2k.ad.ge.com ([169.254.2.14]) with mapi id 14.02.0309.002; Wed, 29 May 2013 13:53:19 -0400
From: "Lange, Jeffrey K (GE Energy Management)" 
To: "netmod@ietf.org" 
Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-11.txt
Thread-Index: AQHOW4dLUBA/OLs9O0iVXdskZBMKdZkbFJqAgAFUMvA=
Date: Wed, 29 May 2013 17:53:19 +0000
Message-ID: 
References: <0E3AC84A-4400-45F9-8059-D9B50BB19880@nic.cz> <20130522.075021.510632113.mbj@tail-f.com>  <20130522.083817.336589153.mbj@tail-f.com>  <00a101ce57ca$50c19fc0$4001a8c0@gateway.2wire.net> <20130523182554.GB34233@elstar.local>  <019d01ce5b86$71d43140$4001a8c0@gateway.2wire.net> <5AB07445-A5EA-4105-B5CE-85B14D3BF397@nic.cz>
In-Reply-To: <5AB07445-A5EA-4105-B5CE-85B14D3BF397@nic.cz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [3.159.212.192]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 29 May 2013 17:53:22.0461 (UTC) FILETIME=[692AACD0:01CE5C95]
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-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: Wed, 29 May 2013 17:53:59 -0000

Martin asked that I provide my $0.02 on this draft as we've created an impl=
ementation against the -08 version. So here we go...

In general I like having the interface-state separate from the interface co=
nfiguration, it provides an easy way for a user to see what devices are cur=
rently in the system and are available for configuration.  In our -08 imple=
mentation we created a /interfaces/physical-interfaces table that would be =
pre-populated by the factory with the interfaces that are available for tha=
t particular product.  Note that our product is not customer expandable, so=
 the interfaces that ship with the unit are the only ones that the customer=
 can configure (ignoring logical interfaces).  By having this config false =
list of interfaces we could achieve the same thing in a more standard way.

However there is one sticking point that prevents us from using -11 (or -08=
) as is.. that is the mandatory requirement of "type"  We have many proprie=
tary interface types (primarily different types of in-house radio interface=
s) that do not fit into the categories defined by iana-if-type.  Sure you c=
ould use the argument "well then get them added via iana".  But that will n=
ever happen.  So that leaves us with a few choices.  What we did with our -=
08 implementation was to create our own interface type identity that we cou=
ld extend with different types of interfaces (which by the inherent beauty =
of identities is also works well for splitting out our different interface =
types into separate yang files).  We then removed the existing type and rep=
laced it with ours.  While I agree this is not in the spirit of using an op=
en-standard, in my mind, end-user usability comes first.

So that being said here are my suggestions, which may be taken with a grain=
 of salt, but I can guarantee that our products will not be able to 100% im=
plement the proposed standard as-is without them.

1) change if-iana-type to an identity.  I know this was brought up in the p=
ast.. by me if I recall =3D) By making this an identity the ability to exte=
nd it with vendor specific types would make things far easier for vendors t=
hat create custom interface types.  If there is strong opposition to this, =
then I would propose a secondary leaf vendor-specific-type or something lik=
e that which is an identity, and _can_ be extended by vendors in a standard=
 way.  Perhaps with a must statement that states that if "type" is "other" =
 Then the vendor specific type must be set.

2) If a user is creating a configuration entry in /interfaces/interface, an=
d that name matches the name of one of the interfaces in /interfaces/interf=
ace-state the value of "type" should not be mandatory.  This is redundant c=
onfiguration information which can be implied by the config-false type defi=
ned in the corresponding interface-state. By this node being mandatory you =
are introducing the possibility of a configuration mismatch.  What happens =
if /interfaces/interface-state{eth0}/type =3D=3D Ethernet and /interfaces/i=
nterface{eth0} =3D=3D wifi? I believe that if the names match, the value in=
 interface-state should win.  This also eases the burden on user who is con=
figuring the system, they don't care what the underlying type of cellular l=
ink on a radio is. They just know that the screen-print on the front box sa=
ys "cell", and they want to configure the "cell" interface.

-Jeff


From mbj@tail-f.com  Wed May 29 13:16: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 5009F21F8459 for ; Wed, 29 May 2013 13:16:22 -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 r9t4YV5CmQI9 for ; Wed, 29 May 2013 13:16: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 8890121F8E76 for ; Wed, 29 May 2013 13:16:15 -0700 (PDT)
Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id A39271200AEC; Wed, 29 May 2013 22:16:10 +0200 (CEST)
Date: Wed, 29 May 2013 22:16:10 +0200 (CEST)
Message-Id: <20130529.221610.235271948.mbj@tail-f.com>
To: jeffrey.K.lange@ge.com
From: Martin Bjorklund 
In-Reply-To: 
References: <019d01ce5b86$71d43140$4001a8c0@gateway.2wire.net> <5AB07445-A5EA-4105-B5CE-85B14D3BF397@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-interfaces-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: Wed, 29 May 2013 20:16:24 -0000

Hi Jeff,

Thanks for your comments.  My responses inline.

"Lange, Jeffrey K (GE Energy Management)"  wrote:
> 1) change if-iana-type to an identity.  I know this was brought up in the
> past.. by me if I recall =) By making this an identity the ability to extend it
> with vendor specific types would make things far easier for vendors that create
> custom interface types.

It was also my first idea to use an identity; it was later changed to
the current enumeration b/c of WG feedback.  I think the major
argument is that everyone benefits from having standard interface
types, instead of each vendor defining their own flavor of
ethernet etc.

> If there is strong opposition to this, then I would
> propose a secondary leaf vendor-specific-type or something like that which is
> an identity, and _can_ be extended by vendors in a standard way.  Perhaps with
> a must statement that states that if "type" is "other" Then the vendor specific
> type must be set.

This can already be done by a vendor.  Note that you could do this,
and since you are allowed to fill in the 'type' when the user creates
the interface, you could always fill in 'other' (and maybe your own
vendor-type).  However, this solution is not optimal.

> 2) If a user is creating a configuration entry in /interfaces/interface, and
> that name matches the name of one of the interfaces in
> /interfaces/interface-state the value of "type" should not be mandatory.  This
> is redundant configuration information which can be implied by the config-false
> type defined in the corresponding interface-state.

So an implementation can fill in the type in this case.

The reason for the type is that we want to achieve conditional
augment, based on the type.  In current YANG, this means the type must
be config.

> By this node being mandatory
> you are introducing the possibility of a configuration mismatch.  What happens
> if /interfaces/interface-state{eth0}/type == Ethernet and
> /interfaces/interface{eth0} == wifi?

In this case the configuration is not applied to the interface.  This
is the text (with the new terms system-controlled and user-controlled):

         If the configuration of a
         system-controlled interface cannot be used by the system
         (e.g., the interface hardware present does not match the
         interface type), then the configuration is not applied to
         the system-controlled interface shown in the
         /interfaces-state/interface list.

> I believe that if the names match, the
> value in interface-state should win.  This also eases the burden on user who is
> configuring the system, they don't care what the underlying type of cellular
> link on a radio is. They just know that the screen-print on the front box says
> "cell", and they want to configure the "cell" interface.

Note again that this can be done today - you can fill in the type for
the user (and in a human-oriented interface you may chose to not make
the type leaf available at all).


/martin



> 
> -Jeff
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 

From j.schoenwaelder@jacobs-university.de  Wed May 29 16:52: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 2E60921F9206 for ; Wed, 29 May 2013 16:52:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.249
X-Spam-Level: 
X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1J1msDeHzF0x for ; Wed, 29 May 2013 16:52:10 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D640A21F90EE for ; Wed, 29 May 2013 16:52:09 -0700 (PDT)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D970A20BDD; Thu, 30 May 2013 01:52:08 +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 7qSdCcjtICdP; Thu, 30 May 2013 01:52:08 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 68F1E20A13; Thu, 30 May 2013 01:52:08 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 56F0E268B31C; Thu, 30 May 2013 01:52:05 +0200 (CEST)
Date: Thu, 30 May 2013 01:52:04 +0200
From: Juergen Schoenwaelder 
To: "Lange, Jeffrey K (GE Energy Management)" 
Message-ID: <20130529235204.GA58491@elstar.local>
Mail-Followup-To: "Lange, Jeffrey K (GE Energy Management)" ,  "netmod@ietf.org" 
References: <20130522.075021.510632113.mbj@tail-f.com>  <20130522.083817.336589153.mbj@tail-f.com>  <00a101ce57ca$50c19fc0$4001a8c0@gateway.2wire.net> <20130523182554.GB34233@elstar.local>  <019d01ce5b86$71d43140$4001a8c0@gateway.2wire.net> <5AB07445-A5EA-4105-B5CE-85B14D3BF397@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-interfaces-cfg-11.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: Wed, 29 May 2013 23:52:15 -0000

On Wed, May 29, 2013 at 05:53:19PM +0000, Lange, Jeffrey K (GE Energy Management) wrote:
> Martin asked that I provide my $0.02 on this draft as we've created
> an implementation against the -08 version. So here we go...
> 
> In general I like having the interface-state separate from the
> interface configuration, it provides an easy way for a user to see
> what devices are currently in the system and are available for
> configuration.  In our -08 implementation we created a
> /interfaces/physical-interfaces table that would be pre-populated by
> the factory with the interfaces that are available for that
> particular product.  Note that our product is not customer
> expandable, so the interfaces that ship with the unit are the only
> ones that the customer can configure (ignoring logical interfaces).
> By having this config false list of interfaces we could achieve the
> same thing in a more standard way.

This is _very_ welcome feedback. Implementation experience is always
very welcome - if others implement things as well, please consider to
share your experiences. This helps a lot.

> We have many proprietary interface types (primarily different types
> of in-house radio interfaces) that do not fit into the categories
> defined by iana-if-type.  Sure you could use the argument "well then
> get them added via iana".  But that will never happen.

I have to ask this so I do better understand. Why will this never
happen?

- Is the procedure to register your interface type too complex?

- Is the interface type kind of secret and hence you do not want to
  have it registered somewhere?

- Is it that developers simply would not know how to register a new
  interface type and choose a random value anyway?

- Something else?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103